by Stephen McLean
Five important lessons from four years as a software developer
It’s been almost four years since I graduated with a degree in CS and began my career as a Software Developer. In this post, I’d like to share some of the lessons I have learned along the way.
Table of Contents
- Never Assume
- The non-technical problems are the most difficult
- Think first, code later
- What you create is more important than the tools used to create it
- Every role is equally important
- Conclusion
Never Assume
After starting my first job, my first project was a short-term assignment on a long-running project. The project had seen many sprints and many developers. The codebase was large, complex, and with many integrations to external services.
My first task was to fix some unit tests that were failing intermittently. The code being tested was relatively old and had been written by a senior developer. Since the functionality worked fine from the UI and had been tested thoroughly by QA, I made the assumption that the issue must be with the tests themselves.
I spent nearly three days trying to fix tests that weren’t broken. When I explained to my team lead why the fix had taken so long, he taught me my first major lesson. He told me to never assume that someone else’s code is correct just because it looks like it.
It’s probably the most important lesson I have learned and can be applied to many situations, not just involving code. Here are a few:
- Never assume that someone will do something just because you’ve asked them to. Always get an explicit agreement. Haven’t received a reply from someone you asked to check something? Send a follow-up. If something is important, it’s important enough to follow-up on.
- Never assume someone understands what you’ve told them, even if they say they do. This is one I learned after progressing in my career to the point where I was helping to mentor more junior developers. I found that I would rifle through instructions, and follow up the next day to find the developer in question hadn’t made much progress even though they had said they understood perfectly what was required. Instead, get the person to give you a walkthrough of what’s been discussed so you can be certain they understand. This applies to more than just mentoring developers, such as explaining something to BA’s/QA’s etc.
- Never assume the other party is wrong. I think developers have a tendency to blame everyone else for their code not working. You become protective over the code you write, to the point where you are convinced it can’t be wrong. If QA tells you they’ve run into an issue, they have a reason for doing so. It won’t cost you much to give them the benefit of the doubt, and they’ll appreciate it more than being shut down.
The non-technical problems are the most difficult
In college all of the problems were technical. Figuring out how to make a piece of code work was almost always the issue at hand. In professional life, however, I have found that that’s rarely the case.
Ensuring communication is clear on a large team working across multiple time-zones. Ensuring processes work, and are clearly documented. Figuring out how to help on-board or mentor new team members. Trying to smoothly introduce something new to the development process. Convincing project management to focus on long term code health when the numbers are pressing their agenda in the present.
These are just a handful of examples showing the kinds of things you can run into on a project. In my opinion, they are infinitely more difficult than tracking down that null-pointer that’s been troubling you.
Think first, code later
You spot a process that can be improved. You immediately decide to automate it. You spend every spare hour developing something that will completely change the way your team works.
Sounds familiar, right? Developers, myself included, love automated solutions.
What have I learned? Don’t immediately go for the code. Stop, and think about the problem, not the solution. Talk to a range of people, not just developers. Figure out if the problem is a technical problem or a process problem first. Then you can figure out the solution.
Sure, coming up with some intricate solution using Docker and perfectly written scripts would be cool, and you’d probably learn a good deal, but proposing a technical solution for a non-technical problem probably won’t help the team in the long run. It might just mask the bigger problem.
What you create is more important than the tools used to create it
When I graduated I loved writing code, learning new languages and frameworks, and anything that involved a technical element.
Don’t get me wrong, I still do. But, I have come to realize that as long as the tools we use as developers enable us to get our job done, it doesn’t matter what those tools are. In front-end development, there is a new framework every other day. And while it’s important as a developer to keep up, the end users (the important people), don’t care how something works, just that it does.
Every role is equally important
I have already mentioned the importance of not automatically assuming that everyone who isn’t a developer is wrong. As well as that, I have learned that each member that makes up your team (BA, QA, project manager, other stakeholders, and so on) is just as important as any developer.
A project doesn’t work without representation from each role and similarly doesn’t work if resourcing isn’t shared equally amongst the different resource types.
I have learned that even though it’s the developer who writes the actual code, there would be no need for code without stakeholders, and there would be no stakeholders without quality assurance of what they stand over.
Conclusion
I hope you can learn something from these lessons. If you have some lessons you have learned, that you would like to share, I would love to hear them in the responses.
Thanks for reading!