Videos
Development - Where the Plan is Put Into Place
[00:00:00] Josh: Welcome to another episode of Dev Shop Stories. My name is Josh and I have Tanner here with me as well as Spencer. So thank you for coming on. Today we're gonna share a story about dev shop tools. So common tools that we use, and the story begins with kind of the infancy of a developer. A lot of times when you're first starting off, you just kind of code and just.
Hope for the best that you know, you make terrible assumptions that your software's never gonna get corrupted. Your hard drive's never gonna die.
And this actually happened with me at one of my previous employment where we actually kept no version controlling system. And I was kind of taught by one of the senior mentors, oh, you just actually just change the file name, you know, every now and then.
So you'd add version three or V3 at the end, and then when you update it, you go V4 and. Also, he taught me, put your change notes at the very top of the file. And so they just actually grow and grow and grow at the very top. And it just is, it just becomes a mess. And so finally, some of these small files that had maybe 20, 30 lines of code would actually have a hundred lines of comments at the top possibly.
So it got pretty ridiculous. And so over time, Red Sky Engineering, we actually have developed the tools that we've used to kind of help better enforce. And so, Spencer, have you had any kind of experiences like that?
[00:01:29] Spencer: Yeah, I've been in a few other companies and teams where we've had, lack processes where you know, there's no processes, there's no code reviews that are done, and it kind of works okay when you're a sole developer. But what starts to happen is as soon as you add a second person onto your team, changes start happening that you're not always aware of.
Somebody may fundamentally re-architect the program and then maybe a day or two later, you start to look at it and you're. I don't know what I'm looking at. I don't know how to make changes or, this could have been done better or this was unnecessary. And it's just, it's really hard to be in a collaborative environment when, when somebody's able to just make changes without any kind of feedback or peer reviews.
[00:02:05] Josh: Right. What about you, Tanner?
[00:02:07] Tanner: Yeah. We've, I mean, we've done it just internally grown from that. when we started with Redsky, before it was Redsky. It was, you know, just a few of us working on private label VR stuff, one of our other companies. And, we didn't have any processes, any tooling. We were still trying to figure out what we wanted to do and what worked and what didn't work.
What works on teams, what works for a sole developer, what that kind of composition and dynamics gonna look like. And we'd grown from. Not doing really anything. I mean, everybody used GitHub right out the gate, cuz that's what everybody used at first. and that's morphed into using, you know, other tools we use, still git under the hood, but we're trying to use GitLab for different purposes.
We have different documentation tools. We have other pieces that we've developed and worked across. To really help check all of the boxes in the other areas. But it all kind of started with, I think, the shift from GitHub to GitLab for us.
[00:03:02] Josh: Right. And, and actually, let me take a step back. And for those who are not, you know, in the thick of code all, all day long, so.
What my history went was going from kind of changing files by file name to actually using something called cvs, which is Concurrent Versioning System, which essentially was kind of a, a server that you would, when you make file changes, you would actually upload those changes and it would be saved there.
And I actually remember one scenario where I wasn't checking in code. Often enough, and I actually went a full week without actually checking in any code. And what happened was, I, I, I did some, I think I, I went and I got so quick at like, you know, right click and Windows Explorer and delete all your files.
Right? And then I would just, You could also do you hold down, shift, delete when you actually went to delete. And that would not just be put in the recycling bin that I would like to permanently delete. And I actually grabbed the wrong folder one time, deleted all those files, and lost over a week's worth of work.
You know, just in one, one swipe. So, oh, that's awful. but continuing on, so. One CVS to SVN subversion to get is what we're kind of, you know, the popular thing that is there. And there's been other versioning systems. I think Mercurial is one of 'em. Have you ever used that?
[00:04:18] Spencer: I'm not using mercurial.
Bitbucket or not bitbucket. There's, what is it? Bit keep or
[00:04:23] Tanner: No, no, it's, yeah, I used mercurial at my last place. Definitely more cumber. Then git Git is just, it's done very well. Right. You know, they checked a lot of the right boxes.
[00:04:33] Josh: Yeah. So what we're gonna do for the rest of this episode is actually go through the actual tools that we use at Red Sky Engineering.
And so for example, for our source code control, we use GitLab. And the reason why we use GitLab is actually, it has a lot of features out of the box. Now I would say GitHub is actually caught up with a lot of the features that GitLab has. And so now it's just kind of, You know, historical, you know, we know how to use it.
We've got a lot of our scripts written to use GitLab, but it would be pretty easy to switch between GitLab to GitHub if we needed to. So for example, GitLab, we use continuous integration and continuous development, C I C D and Spencer's actually written a lot of our scripts that actually do that. So any comments there?
[00:05:16] Spencer: Yeah. One of the things yeah, we like to use the CI within our code repositories. It helps, we can automate a lot of. Checking as, as people make changes and, for the project, we can make sure the project's still builds. We have automated tests we can run that ensure some, some level of regression of things that we've written in the past.
Still work so that we have the confidence going forward. Things aren't just breaking without us knowing.
[00:05:37] Tanner: Well, we set those up too to run on our own custom runners as well. Right? We don't use the shared runners that GitLab provides. There is a limit on the resources there. So we set up, you specifically converted the runners from that old.
Alienware right over to the, to the newer nice machine.
[00:05:54] Josh: Yeah. So we have a computer that's sitting at our office that we actually use onsite. And so whenever somebody pushes some code in it sends a signal to one of the computers in our office to say, Hey, take this code, download it, and check it all out. Right?
[00:06:07] Tanner: Yep. Yep. Run the executions, run those regression tests, do all of those things that we tell it to do in those those script files, so,
[00:06:14] Josh: mm-hmm. , we also in GitLab use their issue tracking for quite a while and we don't use it anymore. We've switched to, you know, other software and we'll get to that in a second.
But, so we use that to kind of record our bugs, our new features, our sprint planning.
[00:06:28] Tanner: Yeah, we used Theone system for quite a while there, inside of GitLab. I think that was like one of the primary drivers on why we switched that in the C I C D for the most part. But yeah, we use the kanban system for quite a while there.
And then, came to find out we needed some more tooling, that GitLab didn't quite offer. he Hence the move on that system, but we still use it for. A lot of the internal pieces. We did use it for documentation for a while, if you remember that
[00:06:52] Josh: right? Yeah. in GitLab they have, you know, milestones.
So you can kind of say, Hey, we're gonna, you know, by this date, have these issues either solved or these features implemented. And they also had a wiki where you can kind of do documentation there. So it was, it was pretty good. But, we've actually switched from using GitLab kind of Wiki to store information about it, to different documentation schemes.
In. Previous employments, we used Media Wiki. So if you think about Wikipedia, everybody out there has used Wikipedia before and Media Wiki is kind of the open source version of that. You can host it yourself and do that. Do you remember using that at the previous work spencer?
[00:07:30] Spencer: Yeah. I remember using that.
[00:07:30] Josh: Uh Huh . And so you get to, especially doing things like tables, you get a, we use this weird syntax and try to,
[00:07:37] Spencer: yeah, it's like on Wikipedia every, if you wanna do anything, you have to know the syntax. , you kind of have to know the tool really well, which, yeah. Which you really don't want to, you wanna be doing other things. Right.
[00:07:46] Josh: And I think we even like creating articles about, well, if you want to do a table, here's what the code looks like from a table inside the media Wiki . So you can just copy and paste that. Right?
[00:07:55] Tanner: Yeah. From a UI standpoint, it is rough though. Yeah. Mm-hmm. It is, it is old. Yeah. And,
[00:08:01] Spencer: But, but at the same time, people could just make changes to an article or its formatting and there was no.
no standardization, there's all, you know, there's five different ways maybe to make a table in, in media Wiki, and
[00:08:10] Josh: And then, we went from a kind of media wiki to GitLab Wiki to now what we're doing is Confluence. confluence is made by Atlassian and they've, they've got a number of other tools, and we'll talk about some of them, but confluences, like Google Docs on steroids, it's, it's really easy to, edit it, to add headers, to add tables, to just insert.
But it keeps everything organized in a nice, cohesive way. You can add new articles, you can do links, you can do images just by adding them there. And then it's, you know, Spencer's favorite thing about it is searchability, right?
[00:08:43] Spencer: Oh yeah. They have a good search tool, and especially when somebody else has already written an article and you're not. You're trying to keyword search something, right?
[00:08:48] Tanner: And then yeah, you, it lets you leverage tagging systems and stuff like that quite a bit and a lot of organization on top of it. And then, yeah, the benefit is that you can find things actually with the different spaces and restrict people down.
There's a good permission set in there too that's kind of baked in.
[00:09:03] Josh: Yeah, I mean, a lot of companies I know personally, they just. Google Drive, and they just have a number of Google Docs and spreadsheets all throughout, you know, all these different folders and everything, and, and it just becomes kind of difficult.
And it's, what I find so funny is that Google is a search engine company, but they make one of the worst searches ever for Google Drive. You know?
[00:09:25] Tanner: Yeah. Google Drive is a pain in the butt.
[00:09:28] Spencer: Or, or even if you have a file share with folders, with documents, with words like Word documents and Excel sheets, those are hard to search through.
when you name actually search the content.
[00:09:37] Tanner: Yeah, you don't get any content searching really unless you explicitly search for that file, right. Or inside that file.
[00:09:43] Josh: And so Confluence can be hosted, you can be self-hosted, so you can run your own server. And that's what we did for a number of years. And, but then you have to worry about uptime.
I've had it words crash before and I had to go in and do repairing of files and just all that. Now their big push is the cloud. And what really got me hooked is you can do 10 people for free in, in one space. And so, we had users one through nine with people's real names, and then we had developer Johnson as the 10th user, you know, and everybody that was new after we added more people to the company was Developer Johnson.
Right. For, for quite a while, you know?
[00:10:21] Tanner: Yeah. It was a long time too.
[00:10:23] Spencer: Well, and going back to that self-hosted option, I think Confluence only. That's only an option now, I think for enterprise companies.
[00:10:28] Tanner: Yeah. They deprecated this, the one that we did before. The self-host.
[00:10:32] Spencer: Yeah. For, especially for smaller companies, they don't even wanna support that anymore.
[00:10:35] Josh: They wanna push everybody to a SaaS model, which can't blame 'em. And, and it, and so we have obviously switched over to cloud. It was seamless. We were able to import everything and then, Now, you know, pay for everybody and we actually now have actually added it so that our requirements for a project are outlined inside of Confluence and we give our customers one free login. Right?
[00:10:59] Tanner: Yeah. We merged some of the resourcing that we've done inside of Confluence into our PM process and utilize that as kind of one of our PM tools. Because we like the permission set. We like how the interaction is there. And then, like you said, we parted. The offering for one of the clients is, Hey, we're gonna have all of this completely documented, all of the acceptance criteria, all of the features set inside of here, and we're gonna provide a user for you to that space so you can see all of this detail and you know exactly what you're gonna get on those projects so.
[00:11:29] Josh: And if they want more than one user, we just charge 'em the difference. Seven bucks a month or whatever it is.
[00:11:35] Tanner: Yep. Yeah. They can have whatever they want. Like we've added whole QA teams so they can go through and verify the acceptance criteria on tickets and such. As that correlates over to the, you know, the ticketing system.
[00:11:45] Josh: And so that's documentation. to kind of recap, we use Confluence there. For source code control, we use GitLab, but project management tools are kind of, you know, there's a lot of them out there. A long time ago, when I was doing a lot of software development, it didn't seem like there were many options that people used.
You know, you could. Microsoft Project was kind of one of the popular ones that I know PMs would use. And I remember we would use Redmine at a previous company. You remember Redmine Spencer?
[00:12:16] Spencer: Yeah, I remember Redmine.
[00:12:17] Josh: Yep. So you know, create issues, create tickets. You can do stuff. It's open source.
We actually. Used redmine, not only for developers, but they actually used it for manufacturing processes too, to actually see what's in the queue to be created. What was, you know, next up in the, in the job, work orders and stuff. But we've now gone from Redmine to GitLab where we're using that to kind of manage, you know, what our sprints were to finally, now we've landed on Jira.
And Jira is another software package by the people that make Confluence Atlassian. And the reason why we didn't stick with GitLab specifically was that Jira is kind of the industry standard, one of the top project project management tools and it gives you a lot of flexibility. And I know Tanner, you've spent quite a bit of time with Jira. Your thoughts there?
[00:13:05] Tanner: yeah. I love it. it's pretty daunting at first to get into, cuz it. Everything you could imagine, there's so much there. But after you get the kind of setup running, it actually works really well. So for us, you can set up projects in a couple of different ways. You can set up a company project or a team project, and the real distinction there is how permissions work.
And for us with third party clients, when they have stuff come in, we set them up as a team, right? so we can set that permission set and we actually give the client access to that Jira instance, to that team project. And restricted down with a group and, you know, all of the permission sets there.
But it's, it's phenomenal. It allows us a full, kind of agile methodology, with the milestones and epics and sprints and all of that stuff that we can set up inside of the project. and then we have a whole process that I know we've talked about before, where we have how the ticket life cycle is, how that goes into the QA process.
It really manages things in a very elegant way And then we can directly tie that back to Confluence tickets and the acceptance criteria there. So it's bidirectionally linked. It's really convenient.
[00:14:09] Josh: Yeah. Spencer, your thoughts on Jira?
[00:14:11] Spencer: What I like about Jira too is, it reflects a process of what we actually do.
So it's customizable in a way where you can make your flows, actually match what you're, how things are really working. You know, like The, the process of taking it goes through right, of where it gets reported, when, when's it gonna be done, which sprints it gonna be done in. so you could plan out the next one, two months of work if you wanted to go that far ahead.
yeah. And it's a very good tool for managing what's, what's going on. So everyone, from the developers to the project managers have a clear. What's coming down?
[00:14:39] Tanner: Yeah, no, I will say one negative to it is their API is horrendous
[00:14:44] Josh: trying to pull data out. And that is, well, and
[00:14:46] Spencer: Well, going back to the possibility of it too, if you're, if you don't set up your flows just right, you could really make a mess of your projects too. So there's you, you've gotta know what you're doing in there.
[00:14:55] Josh: And that is one of the things that we actually do. Do like about Jira is being able to extract data out of it. But we've just had to settle on doing CSV dumps to a kind of a, a text file and then our project managers will take those dumps of, of data and drop it into a spreadsheet and that's where it calculates developer efficiency, time on task, average time per ticket, all that kind of stuff.
[00:15:17] Tanner: Yep. Yeah, we extract a lot of the information. From the Jira tickets and tasks where we track what stage it's in, who's doing what, all the way through the QA process, how many times, direct issues have come up. We can extract all of that data and then run a bunch of analytics across it. It's really nice.
[00:15:35] Josh: So, to kind of recap, JIRA again is a great tool. It's difficult to set up, but once you have it set up, it's, it's flowing and, and it works well going on to design tools. The next one is, how do you have a UI designer, you know, show to a developer what needs to be created? And we, our progression at Red Sky Engineering has gone through a number of different steps.
One is, There is no design . Yeah. Just kind of code it. And we had some coders that were better at design and than others. Right. Yeah. Developers just, just make it look reasonable. Yep.
[00:16:08] Tanner: Developer design is a huge negative. Don't do that. Yeah, yeah,
[00:16:12] Josh: yeah,
[00:16:12] Spencer: yeah. You should see some of my UI's.
[00:16:13] Josh: Which is . Let me go on a side tangent here real quick.
We used to do a developer test that they had to do before they'd come in and we would give 'em this, this challenge of, Hey, make a website that shows a list of users and a table on an ad. User delete. Users change. And, but we gave 'em zero design to work off. We just said, Hey, just, you know, do what you want. and the designs we got back were so horrendous, you know?
[00:16:39] Tanner: Yeah. Some of them. Okay. Yeah, nothing was ever good. Yeah, they were okay, but some of 'em, man, oh, my eyes still burned from the colors.
[00:16:47] Josh: And, and I remember, you know, Spencer working together at our previous company, you love to use just the primary colors, just like bright red, bright green, bright blue.
[00:16:57] Spencer: Oh. Especially if I was just working out a UI for functionality. And I clearly wanted to see, you know, margins and boundaries. Like, all right, this is gonna be green. This one's gonna be blue. That's very clear. I kind of wanted to make it ugly so that, because I didn't have a design, I'm like, well, I need something and let's, you know, nobody's gonna ever like, Give a thumbs up on this.
Right. Make it so ugly that you have to change it.
[00:17:17] Tanner: Yeah. Hopefully they change it.
[00:17:18] Spencer: At least that was my philosophy.
[00:17:20] Josh: So once we started contracting designers, we went through a number of different tools. So we first started with Sketch, which was, all right, it's a, A Mac application that only runs on Mac, can't run on Windows or any other os.
they would design it in there and then they'd push it to kind of their sketch cloud. And that was kind of nice cuz then. Developers don't need to have a Mac, they don't need to have that software installed. They can click on the elements, see the margins and, and the paddings and, and everything like that.
Then we needed other people to kind of sometimes work on the designs and so they, they actually transitioned from Sketch to Adobe xd cuz you know, obviously Adobe, they're huge and they're gonna make the best tools in the world. Well, guess what? This tool was terrible.
[00:18:04] Tanner: yeah, it was good after it loaded, it just took 10 minutes to load. Yeah, it was awful.
[00:18:09] Josh: Yep. And they were trying to do their Adobe XD cloud to kind of compete with Sketch and it felt like that was kind of terrible because the designers, they had to. Individually, click on certain elements and say, export. And if they forgot about it, and they had to remember to do it every time too It was just, it, it just did not work. and so then we got word of Figure and Figma is a fully in the cloud design solution. So no desktop application is completely done in the cloud. They use, I think, like Wasome to actually generate really fast code that runs on their surface.
Although we'll have future talks where we don't think Wasome is as fast as it should be. it, it is a. A really nice tool. And so right away developers can get into it and they can navigate around, they can zoom in, zoom out and stuff. The only challenge that we had with Figma is that it didn't do versioning.
And so we wouldn't like to lockdown and say, Hey, this is mvp. Now the designer's gonna go on and work with the customer and kind of start working on, you know, the next version, you know?
[00:19:10] Tanner: And it's crucial for us, particularly with Fixed bid, to have a locked version right that way. The client signed off on this.
Anything else is outta scope. It's not in this project, it's not on this, this work order. it was locked here. The nice thing too that we didn't mention on Figma, that is the collaborative nature of it right? If you do have multiple people working on the same document at the same time, right? There's a lot of nice things about it.
[00:19:33] Spencer: I kinda wanna interject here a little bit. So what's the advantage these tools give developers or the whole process versus just getting a PNG out from a graphics designer. Again, in our previous company, that's how we got our graphics design.
I was just, here's a PDF or here's some PNGs, make,
[00:19:47] Josh: make it look and match and stuff.
[00:19:48] Tanner: We've, we've had clients who have done that same thing. Yeah. They just wanted a picture.
[00:19:51] Josh: what, what, what are the advantages? Yeah. What are the advantages of these tools? For me, it's the capability of seeing.
Pixel accurate representations of what you need. And so for that, what I mean is you can actually go into these tools and you can click on a button and you can hold your, you have that button highlight and select it, and you move your mouse over to the left side or the right side, and it'll say, well, you need a 16 pixel margin.
This Exactly. And you need that. Whereas what I found a lot with a PNG of, here's what the design looks like, is that developers try their best, but they're not. They're not the greatest at seeing patterns and, and, consistency. And so they just, you know, they're like, oh, it looks close enough, you know, kind of thing.
[00:20:35] Tanner: Yeah. Yeah. Well, and it's, it's, you know, you get the consistency out of the design where it's like, Hey, for us, we standardize on like our AP pixel margins. Right. Or, or variables of that. Variance of that. So, To, to have that standardization. Cause like you said, I can't see three pixels, versus four pixels, right.
I mean, some people can't, you know.
[00:20:55] Spencer: Well, I'm going back to the images or, You end up starting to use ruler tools and now it's like, and you know, it could be a difference of three or four and it depends on where you click on your ruler.
[00:21:03] Tanner: Yeah, it's highly, highly subjective.
[00:21:05] Josh: Yeah. And so these tools make it nice. The other thing that they'd allow you to do is easily export. And so a designer might put in a number of different icons and for the developer to actually get those icons out, they might, you know, with a PNG, they'd either have to go back to the designers, say, Hey, send these separate files and do that.
With these tools like Figma and Sketch, you can actually click on 'em and say, you know, export the assets and for that you'll get a zip file that'll have your icons or whatever you need specifically from that.
[00:21:34] Tanner: Yeah. But that didn't give us everything. Right. We had mentioned it didn't give us versioning.
So for us, our designer, Caitlin actually found a tool that she really liked that helped kind of bridge the gap between design and development, where there can be a lot of conversation, annotations on behavior. Things like that. It's called Zeppelin. We use a combination currently of Figma and Zeppelin, to really bridge that gap.
Figma is phenomenal for a design tool. And then Zeppelin lets us stamp versions and have dialogue on interactions, behavior, expectations, and what the designer was thinking at the time on how this is supposed to function and the intention behind it.
[00:22:14] Spencer: And I like to go right there in Zeppelin. And if I have a question on the behavior, Or maybe, maybe something doesn't make sense in the design.
I could just comment right there and our designer, Caitlin, she's, she's answering within like five minutes. It's great. She's, she's great. She's phenomen.
[00:22:27] Josh: Yep. I mean, all these tools, they'll, Figma and Zeppelin, they'll have tie-ins to Slack. So that is one of the things we had n't mentioned.
We, our communication tools, use Slack for our. Developers and designers to communicate, but you will add a, you know, question in Zeppelin and then Caitlin would respond and all of a sudden you get a slack message saying, you know, so-and-so responded. And so it's really fast, tight feedback loops there.
The other thing with Zeppelin, I believe is, like you're saying, the annotations and the behaviors. With Figma, you can do comments, you can leave, you know, little comments. But Caitlin can specifically tag certain things as, here's the behavior when you click this button, I want to have a slide in animation and I want to have this new page come in, or whatever, you know?
and then annotations would just kind of give more context to. the developer sees what needs to happen there.
[00:23:16] Tanner: Yeah. And then for me, I like the thing, one of the nice things about Zeppelin is it gives me that whole flow. So it's just laid out a little differently. Now, there are nice things about Figma where I can kind of zoom in and out and go wherever I want.
but Zeppelin constraints a little bit more to specific flows. So if I'm going through the account creation flow, right, I get that entire process. step-by-step process of what those pages look like. So,
[00:23:39] Josh: to kind of recap design tools, we use Figma Plus Zeppelin, but then we have a QA team.
And so we have a lead QA person, quality assurance, when I say qa, and then we have, you know, some other people that help out there and possibly automated tests and somebody that's writing those. But the tools that we use, we, we started off with just Google Sheets. right. Write Every single page, every single interaction.
We wanted to test everything, right?
[00:24:04] Tanner: Yep. Yeah. And it's. It's cumbersome. There's a ton of work to keep those sheets up to date. Anytime they had to do regression testing, I just, I remember every time with one of our old systems, they would just shake their head and it's like, oh man, okay, we gotta go replicate this whole thing and go through this, a hundred plus column.
Or a hundred plus rows of test cases and it, it's just a big, heavy thing.
[00:24:27] Spencer: Well, and then trying to keep that up to date with the new designs or as things actually change, it's, oh yeah. It's nice to start to have disconnects between what you are testing and what you actually want.
[00:24:34] Tanner: Features and functionality as they change.
There's no direct correlation unless you hyperlink some ticket, somewhere. So it was, it was bad. Yeah.
[00:24:43] Josh: So we moved on from Google Sheets and we still use 'em first. I'd say kind of some smaller projects we might, we might use that. But Jira has paid plugins that you can actually get. And X-Ray is one of the ones that our lead QA person landed on was X-ray.
And that allows you to kind of associate. Jira tasks, tickets, features, user stories, two, kind of a specific test and, and have the actions that are gonna have to take place to test this out. The test results and all that's kind of contained nicely in Jira.
[00:25:16] Tanner: Yep. Yep. And it represents the development tickets like That's how it interacts. is just like one of the feature tickets or a task or a bug or whatever.
And then it keeps the history of completion and successes and failures and you can annotate why, and it basically gives you what Google Sheets had come to give everybody just in a very nice, clean, elegant way and easy to access. And then it's directly already tied to the tickets.
[00:25:42] Josh: So X-ray is kind of our QA tool. I would say in addition to X-ray. The thing that really makes QA shine is having an awesome QA person, and we have somebody named Dan that is phenomenal at it. And, and it's kind of like the developer's kind of nightmare of like, well, Dan's gonna catch that and he's gonna come over and, and make you fix it and stuff.
[00:26:03] Tanner: Oh yeah. And so yeah, he is, he is top shelf. I mean, Dan is phenomenal at both function and design. I think he takes some pride in nailing people on some of those items.
[00:26:15] Spencer: Well, and, and I think he has some sense to him too because anytime you start dealing, when you have a project that's dealing with calendars and timekeeping, you always run in a class of bugs dealing with time zones and daylight savings.
Just this last week, he was trying to log something from a month ago and it's like, oh, what do you know? It happened to go through daylight savings and it created an interesting bug in the ui. If you always assume 24 hours a day and it's like, well, yeah, not always.
[00:26:39] Tanner: Not always. And that's the thing that, is really valuable from the a personal standpoint as being kind of in that mindset, is having somebody who really understands and looks at it from the client's perspective on usability of it, not just function and, yeah, does this do what it's supposed to do and look like?
I'm supposed to think, is this nice to use?
[00:26:58] Josh: So recap QA tools. We're using X-ray. Sometimes Google Sheets have a really great QA tester, on your team as well. So now we're gonna go into dev tools, and these are gonna be highly subjective to the developer, right? the ones that you use. But we find certain commonalities and we kind of try to teach them to new employees that come in.
So, with an ideal, integrated debugger environment. We have some popular ones in the web world. There's VS code. And there's JetBrains line of ideas. And so the one that we've landed on that we use quite a bit is PHPStorm, which is funny because we're not PHP developers at all. we, we can go in there and we can do PHP work.
We have a couple of clients, but we don't, we don't like it. It's not our cup of tea, but we use PHPStorm and the reason. Is Jet Brains the company that made all these IDs? They have WebStorm, PHPStorm, they've got pie charm, they've got, you know, Android studio, all these kinds of things.
[00:27:59] Spencer: I think they even have one called WebStorm too. That's for.
[00:28:01] Josh: Yeah, they do WebStorm. Yeah. Yeah. Yep. And so what WebStorm, the reason why we didn't go with WebStorm, you know, it does your JavaScript and your node js, but it doesn't have the database tools. In it, they, they, they've made a separate product called Data Grip that has some kind of database tools, but PHPStorm integrated that all because a lot of PHP developers are doing front end and backend and so they're doing database design work all the time.
So we use PHPStorm cuz it has all those parts to it.
[00:28:30] Tanner: Yeah, it's like, it feels like a super set to WebStorm. Yeah.
[00:28:33] Spencer: Yeah. Cuz it still lets us do our JavaScript typescript. HTML
[00:28:37] Josh: and, and, and it's, you know, it's a hundred bucks a year and it's, you know, just a payment that the company makes, for the employees and stuff.
so a lot of people, they, actually navigate towards vs code because it's a hundred percent free open source. But what you get with VS code is you get to build your ID essentially, is the way I look at it, you know? Yeah. They've got plugins for everything. Yep. You get to find the plugins, you get to configure the plugins, you get to, you know, Make sure they're up to date and, and do all that kind of stuff.
And it just, it doesn't feel like it's all inclusive and you know, you don't have a company that's making money that puts it all together in a nice package.
[00:29:13] Tanner: Yeah. It's, for me, kind of funny too. It's, developers are funny, we use it every single day, right? Like it is, it is our tool.
If I, if I'm a farmer, it's my hammer, right? It is what I do every day. but we're so cheap and don't want to pay a hundred dollars a year for a, you know, what is a phenomenal tool.
[00:29:30] Spencer: Or, if you go to Visual Studio, like they're charging more than a hundred dollars a year for that.
[00:29:35] Tanner: Oh, yeah. Yeah. Anything that's, you're dotting that stuff.
[00:29:38] Josh: And then so. Again, when we get to database tools where you're kind of looking at data or changing the structure of a database, popular tools are kinda like Mys Q Workbench and I think there's like tiger database tools. But again, since PHPStorm has a built-in, that's what I typically use.
You know what, what are, I know Spencer, you've jumped around a little bit.
[00:30:00] Spencer: Yeah. I would say I probably use PHPStorm for most of the database things. Sometimes there are some inefficiencies with this database, so I might use my school work bunch or, if that one tool I use, I could probably do 90% of my work just with that one ID.
[00:30:13] Tanner: The thing I really like about the PHP storm database tool or data grip is that I can connect to a ton of different database types so I can connect to my Mongo database. I don't have to go into, you know, Mongo shell, I can connect to my SQL or Maria db. I can connect. Microsoft, you know, MYSQLI can, whatever I want.
They have, I mean, what, probably 30 plus, drivers to connect to the different databases. So I get everything that I need, all in that one tool.
[00:30:41] Josh: Then there's other tools and other plugins that you usually get with the PHP storm. One of them was Redis. Redis is a great kind of memory caching, software technology.
And we would just, there was a, there was no. Initial built into php Storm Redis capability. And so we'd always buy them, it was like one or $2 a year plugin, Redis plugin and, and some developers so cheap they don't, won't even want to pay that. You know, they'd rather use the command line and log into the Redis server and, and do stuff like that.
[00:31:11] Spencer: I don't even think Redis makes a good gooey for their own.
[00:31:14] Tanner: They don't either. It's its command line, which is fine, but again, the value of having it all in your side, I can just use shortcuts and I can get to whatever I want it just speeds up the development cycle quite a bit.
[00:31:27] Josh: However, with that said, PHPStorm just released their new version just a week ago, and it has built in Redis support now into it. I guess you can't complain about the $2 anymore, right?
[00:31:38] Spencer: The funny thing about the $2, it's, I think people just didn't want to go through the effort of making it like this. An account like a, well, like a purchase order, an account just to buy this like a $5 a year piece of software, right?
Yeah. Like there's just an annoyance to that.
[00:31:51] Josh: The next big topic is operating systems. You got people that are windows. Mac Linux. Right. and then at our dev shop, we have a mixture there. We have a lot of people. I'd say 90, 95% of people are Windows users. A few Mac users. And we had one guy for a while that was just pure Gen two Linux, gen two, built it from scratch for spending his first two days building his operating system.
[00:32:17] Tanner: Yes. It was so long.
[00:32:19] Josh: But we use Linux quite often in our servers, in our, you know, GitLab runners that we're talking about there. And it just becomes, it's almost necessary if you're in the open source world, you need to have Linux and Linux knowledge. Right.
[00:32:32] Spencer: Well, yeah. And even our Windows developers, they're still developing within wsl, which is just a Linux subsystem for Windows.
And, Mac is very similar to that Linux ecosystem too. It's a lot of the same commands.
[00:32:43] Josh: Yeah, so we have actually taught classes, so we try to do continued education with our developers and so we wanna make sure that they're very comfortable in Linux. And so we have video resources and tooling and teaching and, and stuff where we go over the Linux command line.
[00:33:02] Tanner: Yep. Yeah, it's, it's important to know, I mean, if you're gonna do, like you had mentioned anything in open source and web development. , I mean, you have to know the Linux command line.
[00:33:11] Josh: and so like Spencer had mentioned, there is WSL and now there's actually WSL two, which is the one that I'd definitely recommend because it runs a true Linux kernel inside of it.
But before that, we actually ran Git Bash, which was somebody that took Bash as one of the command line programs that runs there and somebody had ported it to Windows, and so you'd actually bring up a terminal in Windows, but you're always still on the Windows file system. You couldn't use, you know, every package that you wanted to use had to have been ported over to Windows.
You weren't actually using Native Linux software there.
[00:33:42] Tanner: Yeah, there were some nuances with that, that we kept coming across. , when we would try to, you know, like you said, have a new package that we wanted to use or just some of the runtime issues that we were coming across, between the Windows OS and the Linux OS specifically, like, case sensitivity and stuff like that.
[00:33:57] Josh: Yeah. Yep. WSL two is definitely recommended at Red Sky Engineering. And then we kind of get into other tools and scripts that kind of run. So Prettier is one of the ones that we actually use quite often, and what that does is whenever you go to Save or if you run a command line, it just takes the code formatting out of the equation of arguments, essentially.
Yeah. Is the way I look at it. We basically set up and say, Hey, prettier is gonna take your file and however you type it, it's gonna format it to the way Prettier wants it. And we just said accept it.
[00:34:29] Spencer: And then developers aren't fighting over, do we how we indent in or how, you know, it's just like, well, the formatter just does it for us.
[00:34:36] Tanner: Yeah. Well, and we took it a step further and put that on, a pre-commit, as part of one of our continuous hooks, for C I C D, where it will run that formatter. Before your code even gets committed,
[00:34:47] Spencer: right? So you don't even have to think about running it. So just,
[00:34:49] Tanner: yep. It's outta sight outta mind. It just is all the same.
[00:34:52] Josh: Now, here's the thing: sometimes those hooks could be bypassed and somebody could still submit a code . And so what we did was we actually put it as one of our GitLab, C I C D checks that says, run across the files that they just committed. Does it still pass? If not, actually put it as a failure. So you can't even merge that code into our dev branch.
So, and then you also have liters and liters are things that will, basically inspect your code as you're typing in, and then kind of give you warnings or, status about, Hey, you're not following the proper procedures, or you're not, you know, it's not necessarily the code formatting, it's kind of the code that you actually have in there, whether it, it follows the standard that you have there.
After that we have a kind of type script versus JavaScript. And this is kind of a funny one because, you know, obviously a lot of people learn JavaScript first, and so that becomes the language that they're really comfortable with. And especially if they didn't come from a strongly typed background, they, if they didn't do, you know, strong C or C++ or C Sharp, those, those types of languages, First language that they learned on.
They, they don't get the, the whole reason of like, why do you need to say something as a number or an int or a boon or a floating point number? And, and so they don't, they don't feel that, you know, kind of thing. They're like, why can't I just say var? You know, VAR. Name, you know, equals Josh. Yeah. And, and, and so when you start introducing TypeScript to them, they get, they feel like they're being handcuffed, you know, they feel like they're only typing on the keyboard with one hand, right?
[00:36:16] Tanner: Yeah. Well, cuz I mean, JavaScript for all intended purposes is the Wild West, right? You can do anything you want.
[00:36:22] Spencer: And you can start making changes. And now, Do you still have code that even has compatible interfaces with it? You know, is it, are your turn types compatible? not everything's a string or a number. You can have a complex return object.
[00:36:32] Tanner: Oh, absolutely. Well it's funny, we were talking about this yesterday or like, back in the day we would have to, the only way with JavaScript is really see what is going on, is to learn your debugger, right? So you had to put in a breakpoint to see what that object actually was.
Cause there's nothing that tells you what it is. other than at runtime. So it was, it was crazy. I remember, when we were first transitioning over to typescript, right, you had played with it and we're like, all right, we're gonna do this, man. I fought tooth and nail over the fact that I did not want to do typescript.
[00:37:05] Josh: Yeah. And, and so much so that McKay, my partner, came to you and said, Hey, we need to quickly spin up this new project. And so you spun it up as JavaScript. And when I started looking at it, I'm like, wait, this is JavaScript, this is not type script . Yeah. I tried to see, I came over, pulled over and said, well, let's redo it again and let me, let me help you, you know, through the pains of type script and stuff.
And now you're a huge typescript advocate.
[00:37:26] Tanner: Oh yeah. I love it. I, I would, I wish all of our stuff was time script at this point. But yeah, it's that initial ramp up time of like, okay, how does this work? What is it, what are the nuances compared to JavaScript? And coming to that realization that, hey, it's not actually handcuffing you, it's really actually liberating and convenient.
It saves you a tremendous amount of time, especially on a team.
[00:37:46] Spencer: Yeah. And it's, and it's a project. The project gets larger and. You start making changes in a larger project, it's like, how's this actually gonna propagate through the code? And, with type plus languages, like, JavaScript, Python, like you said, the only way to know what's going on is with a debugger.
It's like, okay, what, what is this actual object? because yeah, your parameter is just, the parameter. It's arbitrary, right? It's arbitrary. It could change and you don't know it.
[00:38:05] Josh: Well, that's a good lead in because the next topic is debuggers. And so you can go from not using any debugger, which sadly that's how a lot of developers have been taught.
You know, they, they, you use, council logs, so they just kind of print out certain states or they just guess and check, But us at Reds Engineering, we strongly, basically force, you have to use a debugger, you have to become efficient with the dev tools that are in Chrome. You have to be good with PHP storm debugging or vs code debugging.
It just has to be part of your nature.
[00:38:38] Tanner: Oh yeah, I Do you remember, we had a contract before and, we were cross-training one of their new developers that they were bringing on and
[00:38:46] Josh: who, who, who had been working for a while.
[00:38:47] Tanner: Yeah. Like industry for six years. Yeah, in the industry and our first question to him was like, Hey, like let's set up your debugger.
And he's like, wait, what? hold on. You've developed, you've coded for six years and don't know how to use a debugger. Like, no wonder you're slow. Yeah. . Yeah.
[00:39:02] Spencer: Well, it goes wild cuz it's, it's really a required tool. You can't just, I don't think, you can't not use a debugger and, I think even need go step further knowing how to remote, remote debug things, It may be, you know, if you have a microcontroller, how to, how do you debug that? You know, anytime I work on those projects, like, all right, how do I debug this thing?
[00:39:20] Josh: Yeah. That's the first thing you wanna solve, right?
[00:39:21] Spencer: Before I even start having a bug. And then, but same thing on servers. It's okay, we've got this thing running in production.
How do I debug that in that production environment, not just on my local desktop? So I think that's learning how to work your debuggers. Is a incredibly valuable tool.
[00:39:36] Tanner: Em, And it's not just your IDE debugger, right? For web, you have the browsers that have a whole debugger built into 'em and all the, all of the dev tools inside of there as well.
So it's, it's a fair amount of information that you have to know.
[00:39:48] Josh: Yeah, I honestly wish that universities or boot camps the very first day. They just show them how to use a debugger. Like we're , like we're gonna take the time out and before we even teach you how to code, we're gonna show you how to put a breakpoint in what is a breakpoint, how to continue, how to step over, step into, and then they start teaching 'em how to code using that debugger as, as how they're learning. Right?
[00:40:11] Tanner: Absolutely. Well, it'll, it would help you understand a lot of those, those logical controls and, you know, things like, a lot more cuz you could actually do it. You know, you step through it and see what it's doing. They do a huge disservice in not teaching it.
[00:40:23] Spencer: My, my first CS professor, he actually did teach with the debugger.
first day in class. It's like, Here's what this line of code does. We're gonna go to the next one. And you know, he didn't even call out that it was a debugger, but it's just right away he was showing like we could just start stepping through the code.
[00:40:36] Josh: That's, that's powerful. Yeah. Okay, so now the hot topic is ai, right?
You hear about it everywhere where it's chat, g p t, you hear it with, you know, others. You know, AI generated imagery and I was, you know, skeptical quite a bit as far as AI that would actually help you write code and generate code. GitHub co-pilot came out over a year ago and I remember seeing videos about it, hear and talk about it.
But I never tried it myself. Cause I'm like, oh, you know, I think that's gonna be kind of terrible and, and it's just whatever. I was pretty dismissive of it until I actually tried it out, and once I tried it, I was blown away. By, I mean, how much time it saves, how much, you know, the repetitive keyboarding that you would do, it actually just figures it out.
So much so that I, I bought into it, you know, I, I taught, you know, I showed it to Tanner and to spencer and we all now pay for it, you know, the 10 bucks a month and, and stuff, and it's just, it, it is amazing.
[00:41:33] Tanner: Yeah. Now, I will say it, it doesn't replace the developer right there, there are certain classifications of developers that I don't want to use.
they don't have enough experience to not become dependent on it, but it. I am astonished at how incredible it is. It is amazing.
[00:41:51] Spencer: and sometimes it's, especially when it comes to trivial code or you know, a lot, most, I would say most of our code is just moving data around and, you, you name your function in a certain way and you already know how it's gonna write it.
And the Co-pilot just gives you a suggestion. You're like, yeah, that's what I was gonna write.
[00:42:04] Tanner: Absolutely. Particularly unlike a lot of your crud or pass through methods, in a service layer or something like, whether it writes it or I do it, it's gonna be the exact same thing since, yeah.
[00:42:14] Spencer: One, one area I really like is in unit test cases, cuz historically those kinds of, they're kind of terrible to write because. It's like, okay, now I've gotta write all these lines of codes where I'm just checking things. It's pretty mundane. But, with co-pilot, it's just like, it suggests a bunch of tests and you're like, yeah, that looks good.
That's great. Or it suggests things that maybe you didn't quite think of, but, or you would've been too lazy to write.
[00:42:36] Josh: Yeah, that's, that is true. where I, where it first shined on me was, Sometimes you created an array of the month names. January, February, March, April, and I just started typing, you know, let months equals and I just started typing j a n and then it just auto completed the entire rest of the things, so I didn't have to type out specifically January, February, March, April, you know, it just auto completed it and it was amazing.
[00:43:01] Tanner: Yeah. Well, and that's to the point of like the, kind of the trivial, mundane stuff. It's like, man, like it's gonna be the same thing either way. Like, just let it do it.
[00:43:10] Spencer: I, I will say when you start to actually write interesting code or code that's a bit unique, then it starts to get a little infuriating. Cause it starts suggesting things that are not in line with what, what's actually going on or makes sense. And you just gotta turn it off. It's like, it's like going away.
[00:43:22] Josh: It can get annoying. you hit escape and it hides it. , but then you type the next letter and it shows it again, and stuff. So I wish there was a little bit more control to say, okay, ignore it for the rest of this line.
[00:43:33] Spencer: You can just turn it off.
Yeah. You just turn the whole plugin off, but yeah.
[00:43:36] Josh: Yeah, you can, but then I have to remember to turn it back on. Oh, yeah. Yeah. But yeah. Yeah. For
[00:43:40] Spencer: Us then you start to feel naked when it stops adjusting things later. Yeah.
[00:43:43] Tanner: Yeah. For us, it's a, it's been a, I think we all could agree that it has, is a good tool and should be part of the tool set for most developers. beyond a certain skill set.
[00:43:53] Josh: Mid, mid-range, senior kind of developers for sure. Okay. So to kind of summarize, let me just go over these tools again for source code control. We use GitLab for documentation. We use Confluence for PM tools. We use Jira. For design tools, we use Figma Plus Zeppelin.
For QA tools, we use X-ray with Jira and sometimes Google sheets for dev tools in a, this is up for debate. PHPStorm is the winner there. the database tools and PHP storm, we use Windows for a lot of people. Some people use Mac and that's fine. We use WSL two, prettier. Typescripts a big one.
Use your debuggers and if you're above a certain level, use GitHub co-pilot. So those are kind of all the tools. Thank you again for listening to our story. We'll be back next week with more stories, personal experiences, and advice on running a dev shop.
[00:44:47] Tanner: Sweet. Thanks guys.
[00:44:48] Spencer: Thank you.
