What I wish I’d known as a rookie software engineer
Your early years of software development need not be a nightmare
Software Engineering is a process
Seems obvious, but hear me out. College programming culture is still very much based on the mindset of reading a question and writing an answer. Be it examination questions, proof-of-concept projects or competitive coding. It’s just that medium is now the computer instead of paper. Years of mental conditioning of students make them treat software requirements as questions they must answer. The problem is, engineering doesn’t work that way.
Engineers aren’t just expected to solve problems, they are expected to create maintainable, extensible solutions for the problems and maintain and extend those solutions as needed. Unless, for example, you are trying to formulate a new machine learning algorithm for image processing, you are probably working on already solved problems, which means much of your focus should be on software maintenance.
At a time when the responsibilities of a ‘software engineer’ is in a state of flux and expansion, it becomes imperative to be aware of what’s going on in your organisation. Talk to your fellow developers, product experts, marketing and sales teams and try to get an idea of the current state of the projects and their outcome in the future. The number of design/product meetings in which engineers come up with ideas that nobody else does is far from negligible.
When you see something that intrigues you, technical or otherwise, ask why. Contrary to what you may think, senior engineers don’t mind taking time to clear your doubts. They know that it is part of their job to address your concerns and that doing so is ultimately a good investment for the team.
Set a quality standard for your work
Engineers in other disciplines, for example, Civil Engineering, have to absolutely account for and ensure the safety of the public when they design a structure. Such structures have to last for many decades and they should be designed in a way that they can be repaired easily if they get damaged. This level of care is rarely present among software engineers, especially the inexperienced ones, which is unfortunate because software products, virtual as they may be, impact real people in the real world. That 15-line function you wrote may just make or break someone’s business.
There are two main reasons for bugs and tech debt to creep into your code — carelessness and unrealistic deadlines. Carelessness is not something an engineer can afford to have, however the other reason is much more nuanced. Business concerns may sometimes force you to push your partially ‘cooked’ code into production, and these are the cases in which the engineer can choose to take a stand, and negotiate with the management for more time.
The management hates surprises
Promise that you’d finish a task in 3 days, but do it in 4 days. Bad. Promise that you’d finish a task in 4 days, but do it in 2 days. Also bad. It’s bad because it means the estimate you gave to the management was wrong. The management makes plans well in advance and assigns pipelines of tasks to team members based on each member’s estimates; any unexpected change may cause confusion and may cause the team to operate in a suboptimal manner.
And it’s not just task estimates. It’s when you check in and check out every day, whether you keep your team informed when you take leaves or work from home, and even where you sit in the office. In your professional life, predictability is good. Personally, the most discomfort I’ve faced when working with fellow developers is not when they code poorly, it’s when they don’t show up when they have agreed to.
This is not a rant against creativity and innovation, not at all. It’s just that for your creativity to matter, it has to create value for your organisation, not jeopardise its functioning. For your talent to truly benefit you and your organisation, make sure that it operates on top of a strong foundation of professional discipline and work ethics.
Your carefully calculated estimates are often wrong
Estimating the time taken for a task is one of the hardest things in software engineering. Period. Over time you’ll get better and better at it, but you’ll still rarely be correct. This is because it’s highly likely that, despite your best efforts to make the process predictable, something untoward will come up. (When you think about it, that’s probably why you need a human being to do the job in the first place.) This is why you should always have a cushion. If your estimate says 3 days, declare 3 and a half. Trust me, you’ll be thanking the heavens you did that.
Lastly, never stop learning. It doesn’t matter what technology stack you are working on or whether you’re front end or back end or infrastructure. Try to get a grasp of everything. And if you have enough time, go deep. You never know what the next trend is going to be. You never know what your next interest is going to be. Any job is about creating value, for your organisation and for yourself. And learning ensures that you are creating value for yourself.
I learnt much of the above in a not so easy way and it’s unfortunate that so much of this is just passed down by word of mouth or through blog posts and not through standard curriculum in colleges. Anyhow, good luck, I wish you all a good, enriching software engineering career.