I am always surprised when I overhear a conversation about what makes an engineer senior, and the most important virtue is completely left out.
It’s not that people forget, or that it’s an unknown trait.
In fact, I think it’s the opposite: it’s something so well known, that we often take it for granted.
It becomes an overlooked part of software engineering, and because it’s overlooked, it makes the truly great engineers stand out.
What is that virtue? It’s patience.
Your work may take twice as long, but it will cost those working with it ten times less in the future
I remember at my first internship, each project assigned to me would cause a sense of urgency. Always get your work done on time or early, right?
Sure, you should always aim to get your work done before the deadline, or push back if you think the deadline isn’t reasonable. I’m not advocating for late work.
What I am advocating for, however, is patience. Instead of hopping on your laptop and creating a new file/project, take a deep breath, a short walk, or a pause for a glass of water or snack.
While you’re taking a short pause, take your time to think about the project. Approximately how long will each piece of the project take? How common are mistakes in the platform you’re going to be working on, and how long can those take?
Walk yourself through the flow of the design or spec. See if you can play devil’s advocate for edge cases or something the project manager and/or designer may have missed.
Once you’ve spent some time asking yourself these questions, start writing out a rough plan for you or with your colleagues. How will the project be broken up? Who will complete each set of tasks? How can you minimize overstepping and potential merge conflicts?
If the task at hand is simple, now might be a good time to start digging into existing code and seeing how your new project will fit in. Otherwise, it may be beneficial to create an RFC (Request for Comments) or an architectural plan on how to execute the project.
Have your colleagues look over and critique your RFC. Welcome the criticism, and use it to make your code cleaner, and life easier. Create a map of the project, using the questions you’ve asked yourself as directions along the road.
At this point, you may have spent a few hours, or up to a few days, thinking about and designing the project you will be working on. While you can’t foresee every bump in the road, you’ve got a basic direction of how to execute the project, who will take which tasks, and pain points that could arise. You’ve taken these points in account for your deadline, and even added a few hours or days on top to give yourself padding for unforeseen incidents.
Now you can start writing some code. Since you’ve created a well thought out plan, the task at hand will become a lot easier, and you’ll be able to push out well-architected code at a quick pace.
Meanwhile, the engineer who started coding after the project meeting is rewriting their implementation for the third time after running into some problems. Problems you thought about after the first half hour of planning. Don’t be that engineer.
After working with a diverse set of engineers, across multiple companies, in a wide age range, there’s one trait amongst the best that stood out to me:
It can be hard to push the urgency to start coding immediately back, but doing so will propel your progress and quality of work leaps and bounds ahead of other engineers.
You’ll produce cleaner code, easier code for others to work with, and code that requires less maintenance. You’ll not only become more responsible, but your external perception will be that of a more responsible and reasonable person.
Think. Debate. Plan. Take your time, and create a map and direction of your project before taking a dead-end road.