So, I’ve only been a “professional” (read: paid) software engineer for about 6 years. However, since the number of software engineers doubles every 5 years I can derive that I have more experience than 50% of all software engineers 🤯.
This is hyperbole, of course, but still I’d like to share the habits I picked up that make me a better professional software engineer.
Plan your day
I start each morning with a planning session for the day, setting specific and measurable goals that I want to achieve. From these goals, I derive a set of specific and actionable tasks you can work on that day. Setting goals every morning can help you keep focus throughout the work day as you will be less inclined to go on crazy tangents when you know what still needs to be done. Defining goals that fit into one day is not trivial. They need to fit into one day but still be ambitious. In my experience it’s best to start with goals that are too ambitious and dialling them down over time.
Example
- Finish user story X
- Fix bug Y
- Prepare meeting Z
Be prepared
This one is easy: Prepare for every meeting. Think of pros & cons for architectural meetings. Prepare your talking (?)points for retros. I once worked with a guy who would always prepare a written statement for the daily stand-up meeting. Me and other devs always fired these “from the hip” and it showed. You can save a lot of time when you prepare for each and every meeting.
Example
For the daily meeting:
“I finished the API CRUD methods yesterday and will work on front-end integration today. My goal is having a working version and I could use help from a GraphQL specialist”
Draw it first
Changing diagrams on excalidraw or on a whiteboard is much cheaper than changing code. This is because the diagrams are on a higher level of abstraction. Therefore you should - wherever possible - start with sketching your code with diagrams. This has the added benefit of documenting your code. My tool of choice here is excalidraw. You can even save .excalidraw files in your codebase and check them out directly in VSCode
Example
Give proof
Every change of code you make should come with a reasonable proof of correctness. Of course, unit tests can only show the presence of bugs but not their absence. But still, you should prove (e.g., with unit tests) that the most obvious bugs are not present in your code. When fixing a bug, you should always start with a failing test that reproduces the bug. This again has the added benefit of providing documentation of your code. Or, as the legendary Edgsger Dijkstra put it so well:
- I shall argue that our programs should be correct
- I shall argue that debugging is an inadequate means for achieving that goal and that we must prove the correctness of programs
- I shall argue that we must tailor our programs to the proof requirements
- I shall argue that programming will become more and more an activity of mathematical nature.
In my experience it’s unrealistic to provide actual mathematical proof of correctness, but it is possible to cover the most important cases with a test.
Keep logs
Keep a record of the things you’ve worked on. I do this on a weekly basis. It’s easy to forget things you’ve worked on, things you achieved, and things you learned over the years. A weekly log will help you remember these things and enable you to learn from them. It has the added benefit of making your - and your manager’s - life much easier when it comes to performance reviews.
Example
Calendar week X
- Fixed memory leak in application
- Increased throughput of payment API by 20%
- Fixed front-end bug
Look back
Similar to retrospectives in Scrum, it’s important to look back and reflect on your performance, habits, and processes. Ask yourself what went well, what helped you reach your goals, what could be improved, etc.? I do this on a daily basis. It’s enough to take 5-10 minutes at the end of your work day and reflect on the goals you set for that day.
Do you have any habits that have made you a better professional? Don’t be shy, leave a comment! I would love to hear some insight from my peers.
Thanks to my beautiful wife for proofreading this article ❤️
so long
comments powered by Disqus