I have been thinking about writing this post for a while, but couldn't find the right words. Writing code comes easier to me. Is all about patterns, logic, and inference.
And yet I decided to write about what it means to me to be a Software Engineer and how I balance my own values with pragmatism, in order to be efficient.
Some of the things I am going to write about I understood quite early in my career. Some of them I resisted to understand and some of them I missed because I was oblivious, inflexible or just didn't want to admit them. It doesn't matter now, I got there in the end!
Being replaceable is a good thing
Years ago, when I was working as a Principal Engineer, my mentor told me something on these lines: If you are doing your job right, your team doesn't need you.
It was counter-intuitive for me at that time - so if the team doesn't need me how am I adding value? It took me a while to realise that all the value I am adding is actually to get the team to that point, when they don't need me at all. When I am completely replaceable. That also means that I have to constantly find new ways to add value, and sometimes that means moving on.
That's a principle that I always stick to, and it reflects in my day-to-day job because:
- I always discuss issues and findings on public channels - my knowledge is valuable when is shared
- I document every important decision I make through ADRs
- I prioritize readability of my code
- Everything that I do can be picked up by a member of my team
In the current tech landscape where everyone talks about being replaced by AI, or cheaper workforce, I am very relaxed about this.
Being replaceable is not a bad thing, is just time to move on to something where you can add more value and you can employ your skills and creativity.
There is always work to do and problems to be solved!
Your software is good only if it adds value to the business
As Software Engineers, we love a good problem. And more than that, we love it when we find a clean and scalable solution. And sometimes we put our heads down and dive so deep into it that by the time we get back up to get some air, we lost perspective, we forgot what we were sailing towards.
You should always sail towards the point where the business wants to be. Your technical expertise has value only if you can provide a solution to a business problem. Your code could be beautiful, extensible and have all the capabilities that you dreamt off. But sadly, that is not good enough. Truly amazing software is actually the minimal software that does all the job required by the business.
And if you are not pragmatic about this, you won't be efficient for the business that pays you.
Before accepting solutions, ask what the problem is
It's tempting, especially after hour long meetings with the product owners, to take a solution disguised as a requirement straight to heart. But when you are in the middle of writing the code for it you'll realise your mistake. You'll find that there are other solutions that could be simpler, and you will probably even question yourself if you fully understand the problem.
Go back to the product owners, kindly ask them again to re-iterate the problem that they are having and maybe mention to them that if they are expecting you to just implement the solution they thought through, than maybe you are massively overpaid. Ok, maybe this last part needs to be mentioned lightly, as a half-joke. But in your heart, you know that is true.
Pragmatism is a key skill for moving forward
Knowing the right thing to do when building software is an essential skill. We are all working on that:
- we gain proficiency in multiple software languages
- we learn best testing practices
- we automate everything that we can find
- we become proficient in software development lifecycle
- we do platform engineering and think about platform development lifecycle
- we constantly improve our ways of working
But when we know what good looks like, and yet we don't have the time to implement that, we face a problem. It feels like we are compromising on our own personal values to get something out there that the business needs. And we continue to feel bad for it.
But it shouldn't always be this way. Is ok to be pragmatic. Is not always possible to do everything by the book.
I sometimes go with the 20/80 rule: I make it clear to the business that I can get them 80% of the value with 20% of the efforts but I am also very thorough in documenting assumptions, risks and basically everything that was missed in the 20%. And sometimes that is ok. Maybe you don't get to automate to 100%, but you make some calculated risks on what couldn't be automated, or tested, or covered.
In my opinion you should always be prepared to present options in terms of value, risks and assumptions. Once you do that, the business can move forward and you can move forward.
Things are not as personal as you think
I saved this as the last point, not because is not important, is actually because I want this to be the last thing on your mind when you read this post.
I did pair programming for years and in the beginning I was shy and stressed about it. I did more typos that I would want. I felt like I was personally assessed, or judged. I focused on the things I didn't know, rather than the ones I know.
It took me a while to realise that I was just not that important. The colleagues that paired with me were focused on getting a solution out there, that works well, and far less focused on what I agonised about. I had to work hard with myself to comprehend that the whole exercise was not about me! It was not about my typing or programming skills! It was about working together to find the way to resolve a problem. And once I realised that, I took myself out of the equation and I focused on what's important.
I actually apply this principle to this day and is the most important thing I grasped as a Software Engineer. I am totally pragmatic about it - nothing is about me, let's focus on the problem!