Maximizing Efficiency in Software Development - Individual, Small, and Large Teams

Welcome to Building Better Developers, the Developer Nord podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season and we are talking about the developer journey. My name is Rob Broadhead. I am one of the founders of Developer Nord, Building Better Developers. And on the other side is Michael. You go ahead and introduce yourself because you do it so much better than I do. Hey everyone. My name is Michael Mollage. I'm one of the founders of Developer Nord and I'm also the founder of Envision QA. So if you need custom software or testing, call out to us. So this episode we're going to look at sort of the next step that we've sort of been working our way through the developer journey and some of those things. We're going to look at a little bit into, we'll look at it like implementation, but it's really about implementation, about like whether you're within a team and how do you work within that team and what's the difference, not necessarily the difference, but some of the things that may come up, such as whether it's an agile shop or a waterfall model or we'll talk a little bit, I think we'll see how this goes about things like whether you're remote or you're not. All of the things that you may run into that you would not have hit probably while you were in school or while you were on a boot camp or going through an online course or whatever it was that you were doing, however you got your basic skills. Now this is when the skills hit the real world, when the rubber meets the road and you get out there and talk a little bit about that. And so my thought with this, first thing that came to mind as we were talking through this concept or this idea, this topic, is the difference between team sizes, is basically whether it's you, which sometimes happens, particularly if it's a side hustle or something, it may be really you are really the only developer working on it, or it's something where you're in a small team and usually it can be a small team with small, high communication kind of team because it's usually two or three of you, everybody's got to really has to communicate or else it's going to fall apart. And then I think another big step is when you get into a team that's a, and people think of more of an actual team where you've got half dozen, dozen or more people that there's different roles and things like that. So really the three places are individual where it's your chief cook, bottle washer, small team where everybody is basically wearing all the hats and they're just sort of working together in a very tight knit group. And then when you get into something a little bigger where you do have defined roles, which could be number wise, I guess you could have a team of like five people where you have a dedicated, you know, maybe a QA person, a dedicated database developer, a dedicated API developer. I want to talk a little bit about those and what you need to think about in order to make the most of the team. The one that will be really quick and easy or at least quick and I'm going to sort of fly through it is individually. Individually, I think when you step into a project, and this is most important if you're doing a side hustle or something like that where you or maybe you've got assigned by your boss to go do a proof concept or a demo or something where it's like, hey, go build this thing and then come back when you're done or something along those lines. We've talked about it before. I cannot emphasize enough. Use that as an opportunity to practice the common development things like committing code, putting decent comments on your commits, commenting your code, having a reproducible build process of some sort. It is easy as an individual to sort of just skirt those things and just like write code and then you just build it and you copy it and all that. But you're this a great place for you to cut your teeth on having like processes and reproducible, repeatable things that you do as part of your process that you can be a better developer. For example, I think I've mentioned before that I use Antscripts a lot. That's just something I've had for a long time. I like them. I've been able to make them do all kinds of cool stuff, including like I can rebuild my databases. I can copy files out. I can restart stuff on servers, all of that. And while I don't really technically need those things, and I just air quoted for those of you that are can't see me visually, but they are very valuable. It is amazing over time how much those little scripts will save you. Now, it may be a minute here or a minute there, but it'll save you typos. It'll make it reproducible. And that time does, it does add up as you go day after day and build after build and push after push. Over time, that stuff adds up. And so utilize that, make the most of the tools that are out there. Small teams. A small team really, I think if you have not introduced yourself to Slack or Teams or something where there's a chat, some sort of instant messaging thing, you really need to do that. I currently have a small team I'm working on. We've got and we do have defined roles of more or less as we've got sort of front end, middle API back in kind of developers. But because we are building something that is, you know, we're working towards a version one, we'll call it. We need to there's a lot of changes going on. So it's not like the API is stable. It's not like the UI is stable. It's not like anything is stable. We're constantly changing and adding features, those kinds of situations. You need to have a way set up that you can communicate and make sure that everybody is on board with that communication style. So if it's a Slack channel or Slack, make sure that everybody has Slack up and that they know when it's, you know, we all know when we're working because that can also be a big problem when you get into bigger teams as well. But especially small teams, if you're waiting on the database developer and they only work 2 a.m. to 6 a.m. your time, then you can lose days sometimes because you're waiting for them and you got to go send them something. You got to make sure that you've got a very good communication structure, that you understand that timing. And it may be something where, you know, some people may have to get a little bit out of their comfort zone and check things outside of their normal schedule just to help you. If not, know that that's going to be a blocker at some point. You know, if you've got somebody that doesn't show up on a Thursday, that they always take Thursdays off and they're not there, inevitably, there's going to be a point where their code change is required on a Thursday. And that means you're going to have to wait till Friday. So make sure that you're clear on those things. Last thing, and then I'm going to kick it over to you, Michael, is the big team stuff. All of the things I've talked about in these other two instances are really important in the big team stuff. But the biggest thing that I think I have seen that's a gap or a flaw in larger teams is ownership, is making sure when you line up your project and you say, here's the requirements and here's what we're going to do, and this is the structure and this is the architecture and all that stuff, all of the pieces, all of the steps within the software development lifecycle, all of the main, we'll call it like feature, you know, feature points and stuff like that. There needs to be somebody somewhere that owns those things. And by own, I mean, there's somebody that is a decision maker of some sort. And if they aren't, that you can go to them and you can say, hey, we need to have, we have a question about this. And they need to be able to go to the person that can answer that. And also somebody that's when you get towards the end in particular, they're going to be able to do things like test it and validate it and say, yes, that is correct. Or if a test fails, they need to be the person that can override that and say, oh, no, that's OK, we've changed it. Or say, yes, that's critical. And particularly when you get into the go, no-go meetings of is this going to be, you know, is this production worthy? You've got to have those people there. And so often that is a gap as you get into larger teams where there's something that's not just nobody owns it. And that may include the project plan itself, deadlines, all kinds of stuff that is critical to declaring something done, which is probably the most basic of that. When you go into a project, particularly with the team, we need to all agree. What does done look like? What does that mean? Because done is different to everybody else. And now I am done. And my definition is I want to let you throw your your two cents and actually due to inflation is now your forty five bucks into the conversation. Mike. So you've touched on the three different types of teams. You talked about the independent person working on a team could be a contract, could be a startup, whatever. But it's essentially a team of one. You talked about the small and midsize teams, small development teams, communication, and you talked about the large teams. Now, the running theme with all three of those, at least between the midsize and large, is communication. Now, even if you're an individual of one, communication is still important, but the communication typically is more important between you and the customer or you and the vendor, because you have to make sure that what you're working on is done right. Now, with all three of those, the types of ways you work on the projects or you develop software typically can follow the same type of pattern. You have things like waterfall where you build the entire project in one go, and then you have small deliverables as you go out and get user feedback as you're building the application. Typically, you see a little bit more of that with individual or even startup mentalities. But typically in today's environment, it's more agile driven. You do things in small sprints. You get things out the door quickly. This really is tailored for any type of team or environment. You typically want to start quickly. You define your requirements and you start chipping away at it in small iterations and deliverables. As you're doing this, regardless of what size team you're working on, make sure you follow some simple steps. One, make sure that you understand the requirements that you need. You understand the software that you're building. Make sure you have good documentation skills. Make sure you comment your code and you follow some best practices. Make sure you write test cases for your code. Make sure you have the user stories defined as you're building this software. Now, circle back around as you're communicating this. If you're dealing with offshore or different time zones with teams, this type of strategy really can hit home because if you're doing small deliverables, no one should be working on anything that isn't related to the current sprint. So you really should be working on requirements in such a way that you don't have too many blockers. Now, this can happen, but if you're in this agile environment, when you're communicating, you hit a blocker. Everyone's on the same page. It's like, whoops, hey, we've got this problem. Let's kind of circle the fences and work through it. Now, that's kind of the development style. Now, as Rob said, if you're a standalone, regardless of what team, code backup, code repositories are critical. Make sure that you define and keep backing up your code. This can also help with that documentation. It can also help with testing. So we've talked about testing before in past podcasts, but what we really haven't hit home is if you build out that deployment process, that continuous integration, continuous deployment. One of the things you can also build into that, like Rob uses Anscripts to help do his builds, his deploys and things of that nature. You can also write in to your continuous integration pipeline testing. So you can kick off like Jenkins or Bamboo. So when you deploy your software, it automatically kicks off the tests to run against your software. Now, as you're compiling your code, you can run unit tests against your code to make sure that the white box testing of your code works, that the functions work the way they're supposed to. When you're deploying it through the continuous integration process, you're looking at more kind of like black box testing. You're testing things on the back end. So you can write those integration tests, those regression tests, those smoke testing, and even system and load testing. All that can be built into the process as you're going through your software development process. This really works in any environment. It could be waterfall. It could be agile. But typically you want to think agile. Try to get away from that monolithic application. Now, you could be in that situation if you did a proof of concept and oops, you're now in production. You kind of have to backtrack a little bit. So if you run into situations like that, again, work with the tools you have. If you don't have good tools or good software development processes in place, look at project management tools like Microsoft Project, Jira, Bugzilla. You even have some, I believe, issue tracking tools in GitLab now. So look at using these to help manage your process, to manage the project and make sure everyone's on the same page. And finally, the last point I'd like to hit on is while you're working in teams. Now, if you're working in a silo, it's you. You have to hold yourself accountable. So time management becomes critical. You should be keeping track of what you're working on so things don't get off the rails. Again, that falls into that agile process. Now, when you're dealing with small to mid-sized teams or even larger teams, time management kind of gets a little managed by the team environment. You have like your daily scrums. You have your standups. You have your team collabs, which kind of keeps everyone moving in the same direction and keep things on track. So if something's falling behind, you call it out and people, you know, again, help circle the wagons. And we can work together and keep things moving forward. So I'll pass that back to you now, Rob, since I've kind of rambled on for a bit. I think that the one thing I wanted to point out to this that I have seen a change in this. There are going to be times when it is all hands on deck. There are if you're in any kind of a real software development, whether it is you doing some sort of side hustle thing or whether you're doing something with your team. There is a point where there is a push where there are going to be deadlines. There are milestones or deadlines or costs related to them. There's all kinds of things like that. One of the things you want to do as much as possible with these pieces, the reason that we do this testing and that is to try to level those out as much as possible, to try to take early on the where we don't have this usually the urgency of the team. And sometimes there's some stuff that can get done very easily that we take the the buffer that gets built into that and we pull into that some of the things that are a little tougher. This is where agile actually becomes very useful because you have things like you have a you have a sprint. You have a short period of time. Everything has essentially sort of a critical level to it. To some extent, we want to get it done, get it in this sprint. The two things I'll say is one within your sprints. Yes, you probably are going to have stuff in any given sprint that is going to get pushed to the next one. Make sure that you're not just push, push, push, push, and that you're suddenly building up. You're building more and more each time that you're just saying we're going to put it to the next sprint. We're going to put to the next sprint. There is a point where these things come, you know, it come do and you need to get it done. And that also means that there are going to be times that if you are a developer, this to me is very much a difference when you become a developer. As there's a point where you're going to have late nights, you're going to have weekends, you're going to have times when things just don't work. You're going to have the worst or probably the configuration type things where I'm setting up a server or building this little piece of code that should be done in 30 seconds. And it's not. And you can lose an insane amount of time. One, suck it up, buttercup. You're going to have to do that. But two, the good and the bad news, I guess it's mostly bad news that never ends. There will be times like Michael and I have been doing this for decades and we've still had times. I know both of us, even in the last few months, where something like that happens and it's, you know, something is the upper case instead of lower case. Or like I had one I chased down the other day. It was literally a nine versus an 11 in two lines of code that were in a configuration file. And it was like buried deep in a, you know, took a while to find it kind of thing. Those things happen. Just realize that is part of why they, you know, as they say, you get paid the big bucks or whatever it is, even if you're not getting paid the big bucks, this is like part of what we we do have to struggle through. And so the more that we communicate, the more that we put all of these, I will call them for lack of a better term, best practices into practice. The more likely we are that we're not going to hit those kinds of things because we're going to test earlier. We're going to see the bugs earlier. We're going to have repeatable processes and all the things that often contribute to those typos and those kinds of errors. It costs a lot of time and causes a lot of headaches and cost, you know, night all nighters and things like that. We will get those things out of way. There's a reason for this. This is done by people. And if if you do it often enough, you will do it yourself because you will be a believer because you'll realize that darn it. If I had written a little script, if I'd taken, you know, five minutes and written a little shell script to do that, then I would not have had that typo that cost me three hours to do that. Closing thoughts on you and then we'll wrap this one up. Yes, I'd like to add one additional thing to the idea of stuff getting kicked down the road like, you know, tasks taking more than one sprint. One thing that can occur and it does occur a lot in software development is someone comes up with an idea, sales talks to a customer and with the idea of a product, you tend to get what's called scope creep. You get new things added that are not necessarily thought out and it can cause things to really start going off the rails, which causes the backup. If you start encountering that, if you can push back and try to get that into the next release cycle so you can finish the current level of work, sometimes you can't. But if you can, that will help keep a divide between the different areas of work being done. Otherwise, scope creep, a really big problem could potentially derail an application or it could really push your deliverables off track. The other thing I'd like to touch on just slightly. So we talked about the idea of projects, you know, those late night, you know, the late night, you know, the night before the release cycle. Those late nights and having to be all hands on deck. Sometimes that is the fault of the software. Sometimes a bug gets found, but sometimes this could be something that is totally unintentional and in kind of a side effect of something else going on somewhere else in the company. A real quick example of that is years ago, we both worked at a company. This was before Rob came on, but we were going through a major systems upgrade behind the scenes and they had it all ready to go, all tested, and they were about to turn it on when we found out it did not work with our current web applications software. They forgot to test it literally 10 days before they went live because they had to go live for a federal requirement. We had to completely overhaul our application server and so a brand new updated server to work with everything. And literally we were working almost 24 hours for 10 days to make this happen. We were talking to support in every time zone from Germany to Japan to California. I mean, it happens. Don't panic when that happens. You're going to have a lot of anxiety. Trust me. But just understand what the problem is. Make sure you have the numbers of who you need to talk to, the support people and work together. You know, basically it's not necessarily one person's problem to solve unless you're a one person shop, but it's the help of the team. It takes a community to kind of get you through this these kind of problems. So use that and don't, you know, don't fall on your sword and be the only person that, oh my God, I have to figure this out. Work as a team. I think that's probably the parting thought that I want to put into this is it. Yes, this sounds, you know, we're painting not a very happy picture, but these are also the times that you bond with your team. These are like these are the foxhole moments and stuff like that where you go through this stuff and you will come out of it on the other side. I think a little closer, tighter. It is really a good team building kind of experience. So don't, you know, don't freak out. It happens. Life continues. You're going to be able to do it. It happens. Life continues. You're going to have you will sleep again. You know, stuff like that. Unless it's a death march and that's a whole different problem. We'll talk about those another time because when we're just want to have another cheery discussion like this. That being said, if you're feeling really cheery right now and want to give us some feedback, please shoot us an email info develop an order dot com. You can request things that you want us to talk about. You can give us feedback. You can trade war stories, whatever it is. We'll read it. We probably will actually at some point refer to it on on the YouTube channel or out on the podcast. You can also check us out on developing or dot com. You can enter information in our forms. There's a contact. There's a contact us form there. You can send us stuff on Twitter X. You can leave us comments here. You can leave us comments on YouTube. You can check us out on YouTube if you're not. And if you're on YouTube and you're then you can check us out on our podcast. All of that being said, we are not done. I know that's a shocker. We're coming back. We're going to have more information, more things to discuss next time around. So until the next time, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to building better developers to develop a new podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.