About

In this episode, we are going to talk about strategies you can implement to increase productivity and decrease complexity using systems and frameworks. Welcome to Stack Bytes, your source for industry news, insights, and strategies to level up your software engineering and leadership skills. These strategies and approaches will give you a fast track into building better teams, becoming a better leader, and leveraging emergent technology to impact your business byte by byte. Let's get at it. Welcome to the Stack Bytes podcast. This episode we're going to talk about decreasing complexity to increase productivity with systems and frameworks. It's really important that as you're building your teams that you understand that the sooner you have systems and frameworks in place, the easier it will be for them to function and to work at a higher level. You want to have these systems and frameworks to guide them as they go through their day-to-day development and to give them clarity on how to work and function within a group. Automate Tasks One of the first things you really want to automate is the simple and the complex tasks. So, when you're developing and you have, let's say a Git pull request, a way to automate something simple would be during the push process to hook into the Git Hooks and to actually run unit tests, right? In doing that, you're able to simplify the process of unit testing by forcing unit tests to always run when they try to make any change, whether it's pushing code or trying to do a pull request. You want to make sure that that's completely out of their mind and be able to just run fluently. As part of your culture, you want to make sure that your team is unit testing and has that unit testing running in watch mode while they're developing, but realistically, sometimes those simple things get in the way. And that can easily boost productivity by decreasing the stress of having a pull request or a push that goes up where code wasn't checked or unit tests weren't run and things are breaking. Then you're wasting multiple developers time, and we don't want to do that. We want to increase productivity. A example of a complex task might be deployment. There are so many different ways to deploy code now. There are so many services. GitHub has a lot of services that you can look into. AWS has a lot of services that you can hook into. Let's increase our productivity by pushing off a lot of the tasks into an automated sequence, right? That includes the unit testing, the end to end testing, the integration tests. You should be able to do a pull request into a staging environment or really this should work on any environment. Run your tests either in a sync or sequential and be able to test out the code works. Then run through your unit test, your integration tests, and any other tests that you need to run and do that all in parallel while simultaneously alerting anyone that needs to know about how those changes will affect them. So, if it's a developer and they're pushing into their own isolated sandbox, if they push code out, the unit tests fail, some end to end test fail, they should be alerted right away. That shouldn't allow them to then try to do a pull request into a master or into another staging environment. You want to take those complex tasks and just automate it, so the moment they push their code, they get an email notifying them whether or not it's succeeded or failed and some action steps to then take after that, right? It's very important. You don't want to just tell them something went wrong. You want to give them action steps, right? Having those systems and frameworks in place will boost productivity immensely. Framework For Meetings A real, big time saver is meeting agendas. The second thing I want to talk about is how you can boost productivity by simply having a great framework for meetings. Your meetings should be at best 20 to maybe 40 minutes, right? We don't want to go into an hour, hour-and-a-half-long meetings because you have to remember, just as human beings, our attention span start to go down, right? After 40 minutes, our attention span starts to go down dramatically. So, the longer your meetings are, the less likely and the less productive your developers will be, right? People start forgetting things. People get annoyed. People just in general stop paying attention because it just takes too long. And the way you do that is have a framework in place where any time a meeting is set that you have agendas. Attach an agenda to each meeting. If the meeting does not have an agenda, anybody on the team can then push back the meeting because if you didn't take as the meeting organizer the time to write a simple agenda, then the question is how long are we really going to spend in this meeting, and how prepared are you for this particular meeting? Have an agenda and also only invite the bare minimum people that are required for this meeting to be successful. Having a framework that simplifies the meeting structure will definitely take most of the day and give it back to your developers because that's what… Meetings end up eating up so much time. So, let's stay on topic focused and determined to get our meetings down to the bare minimum. It's going to help your team tremendously. Just focus on what needs to be done, and if it's not, give everyone the authority to push that meeting back because then it's going to make it a team-wide Understanding that no one should be wasting anyone's time because all of our times are equally important. It's important that you have a system and various frameworks set up to handle your daily communications, and make sure that you're not bottle-necking all of that information down into one central location where one person needs to then disperse that information throughout the whole team. So, a good example would be your production errors. Code is live and in production, and there are various errors that are happening. Who gets called first and subsequently who gets called next, and what's considered a high, medium or low severity? Something that is that important should be understood by the whole team. It shouldn't be a mystery to who should be handling what errors and what should be done when it happens. There's one of our clients who had a massive production error, and it's in their peak season. They have a eCommerce website, and their website went down. I was contacted, and the moment I was contacted I knew, “All right, here's who needs to jump on this call. Let's figure this out.” Within 10 minutes we were able to get the right people on the projects and checking out the various error points and identifying whether or not their point of failure was the reason why the site went down. From the moment the call happened, within 30 minutes we identified what the issue was. Between deploying and testing, it gave us another 15, 20 minutes. Then we let them know that the site was up and running, and we would monitor the site for the next two hours and make sure things were running. But there was no question about what needed to be done, who needed to be called, and what systems did we need to check. The whole entire framework was already set up. Yes, I got the phone call and boom, from there, system gets into place. Everybody who needs to be on this get to work on your sections, and let's find this problem, and let's solve it right away. That's the power of having a framework and a system in place for when something goes wrong. Now, it could also be something for bugs and feature requests. Especially when you have multiple units, whenever a new bug comes in, who needs to work on it? Is this something that needs to be escalated right away? Your team should be able to… And anyone on a team. That includes your product team, your C-suites, if anyone has a input that needs to be a system in place to move that data along to the right people. If a feature request comes in, you need a developer as well as maybe a designer product lead to sit and talk about it. What's the objectives? Does it meet your organization's KPIs? Is this something that's doable, and if it is doable, what kind of resources will it require? Now that could be the CTO, it could be you the lead developer, or it could be one of your top software engineers and architects, right? Everything doesn't have to flow through the CTOs and leads. Some of the daily changes and productivity enhancements can happen at a lower level, and if it happens earlier on in a process, it's less needs to be escalated and more time that can be focused in solving your problems. Daily communication is very important, and it's something that with the right frameworks in place, the right systems in place, you can boost productivity in your team immensely. Our goal is to boost productivity so that our developers can function the way they need to function. As leads, as CTOs and top level software engineers, you are here to serve the team, right? You're building leadership, you are leadership, and it's all about helping the team grow and get to where they need to get to. If that means setting up a system, teaching them how to function within a system, or altering a system to make it work with your team, that's what you're here for. That's our jobs is to help the team grow and get things done. The Recap To recap, we talked about automating the simple and the complex tasks. Doing that will allow your team to focus more on making decisions on the most important tasks. Take all the things that you can automate and get it out of the way. Let the automations take care of all the headaches, all of the error finding, all of the testing, and let the automation be your heavy lifting because it's easier to put an EC2 instance up or to run some kind of lambda function than it is to constantly have your developers do something over and over and over again. Two, it's having meeting agendas, making sure that there's some type of framework in place to make sure that meetings are effective and are streamlined. Super duper important. And then of course we want to create defined systems for dealing with production errors, new bugs and feature requests, and just daily communication. You want to make sure that regardless of the type of communication that needs to happen, that the team knows that there is somewhere there they can find a system or a framework to complete that particular communication request. Thanks for listening to this episode of Stack Bytes. Subscribe now on your favorite podcast platform to get instant access to our weekly episodes. Looking for even more content and a community of like-minded individuals? Be sure to check out edithsonablard.com/podcasts for even more information, and don't forget to check out the show notes for the transcript as well as more details about this podcast. More Resources Empowering Developers to Make Better Decisions 5 Tips for Refactoring Code Can You Use Vue.js For Enterprise Applications What You Need to Know About Unit Testing