A software engineer shares two costly mistakes: building a generic abstraction nobody used, and adding process steps that lost tasks. His fix: understand requirements first, make concrete plans, simplify processes, prioritize user value, and protect focus time.
In the world of engineering, the term complexity may sound like a good thing, right? The more complex a certain thing is, the more wow effect it has. Well, all of that complexity comes with a cost, and that cost can be huge. The more complex a certain thing is, the costlier it is for the business to ensure it works correctly. So is complexity a good thing or a bad thing? We will break it down in this video. So it's quite common in our industry that a technically complex solution may get approval or praise from others, especially other engineers. And being clever or trying to solve all of the future problems ahead of time may seem like a good thing, but this may provide more problems than actually good things. Complex technical solutions should not be praised because they are hard to maintain, hard to understand, or just too complex overall. It's really important to understand that we as engineers are here to provide as much business value as possible. That is our purpose. Amazing technical solution may not contribute to that. I have made many mistakes thinking that complexity is a good thing in my career, both as engineer and as a manager, and I'll share one mistake I made as an engineer and one as a manager. Let's start with the mistake I made as an engineer first. I thought that complexity is a good thing in my early days as an engineer, and when I became a bit more confident in my skill set, I thought that I could build anything that I wish to. Therefore, I thought that if I put a bit more effort in the beginning, I could solve all the future problems. Well, I was very wrong. For example, I built an abstraction, a reusable component, that was only used one time in the whole application. It kept being used only once until there was the need to adjust it for the second time. I tried to make all of different possibilities in the abstraction and it started to become very complex. Well, what happened next was that there was a requirement to use it for a third time and it was completely different again. That's where I needed to refactor and split this abstraction into 3 different cases, and it took a lot of time to do that. So I would avoid this completely if I would keep it simple in the beginning with no abstractions, or if I didn't try to predict or solve different problems that might not even exist. Now let's get to the mistake I made as a manager next. So when I first became a manager, I thought that I could change so many different things for the better. With the best intentions in mind, I added some additional steps to our software development process. Well, what happened was that in our case it was a bit over-engineering and there wasn't a good way to visualize the progress. We ended up losing some important tasks because of the visibility issues, and that contributed to more issues than actually good things. So yeah, similar learnings than before: if something works, don't change it. Try to keep the process as simple as possible. The more steps and the more complexity you add, the harder it is for people to remember all the steps, and also onboarding new people is tougher as well. Processes should be introduced to help, not to add complexity. As you can see from both of my mistakes as an engineer and a manager, I would have avoided those issues if I would try to simplify things as much as possible and not introduce additional complexity. Therefore, my recommendation is to always have this in mind. Let's give some practical examples where you can focus on simplifying. The first one: as an engineer, you get certain requirements for a new functionality. Try to really understand the requirements and propose simpler solutions before starting with implementation. Your first instinct might be to jump straight into implementation, but that is wrong. Let's go to the second one. Always create a plan before starting with implementation. If you just try to wing it, you will introduce unnecessary complexity. With a good plan, you can avoid that. The next one: there is a certain problem in the software development process. Try to really understand the problem and where it is, and try to simplify the process before introducing additional steps. The fourth one, always think what would be the best for our users. If you provide a simple solution, you would spend less time building it and the users would receive value faster and you would also receive feedback faster. And the last one, but not least, simplify your calendar as much as possible. Combine your meetings together and block out the focus time for yourself. Just this alone will make your day-to-day work a lot easier. I'm curious to hear what are your thoughts on simplifying versus complexity. Make sure to share them in the comments. To learn more, you you can subscribe to my newsletter. It's called Engineering Leadership, where I share similar tips and advice on how to be a great engineering leader. There are more than 102,000 people already reading it, and I publish 2 new articles every week. Thank you for watching, and I'll see you on the next one.
How I Grew My Newsletter Engineering Leadership to 165k Subscribers in 3 Years
