Engineering Practices that Resonate

In revisiting some prior writings, I came across a post I made in another forum back in 2016 that still resonates today with how I approach software engineering. I was compelled to share here again as I believe these are timely messages:

As I read through various articles and blog posts across the internet, I often come across common platitudes and a lot of regurgitated common sense. At times though, its good to remind ourselves of core principles, the *right* way to do things, or to just re-learn something we knew a long time ago that may have new relevance in our current role or project. Today I read a blog by Bill Jordan, a seasoned veteran of software development and management titled "The Quiet Crisis unfolding in Software Development". He highlighted a number of things that resonated with my current role, and so I wanted to share some of the key takeaways. Sticking to my rule of three, here is my list:

1. Technical debt cannot be avoided, but it can be managed better through continuous improvement. I.e. have code reviews with engaged peers; be wary of rushing through architecture/design planning; and Agile is a framework for delivery, not an excuse to not follow good development practices.

2. Team leaders often don't have a distinguishing title, but are people who are highly engaged and others come to when they need guidance or to talk through a challenge. Similarly, high performers are not simply delivering the most widgets, stories or writing the most code. They are people who are dedicated to quality, looking to make the larger team more productive and good at helping foster communication and understanding across the team.

3. Interruptions are productivity killers. As engineers, its critically important to have the time necessary to focus on the task at hand in order to deliver the best quality. Invoking a "cone of silence" for a period of the day is critically important to good software development. This means minimize the number of meetings any one person attends in a day - if any particular engineer is in meetings for more than 2 hours of their day, an opportunity is missed. In Agile, we have daily stand ups (they should be brief, 15 min or less!), we do grooming, planning and retrospectives - all usually about an hour each per sprint - if you do this continually and the product owner is regularly engaged, the planning and grooming sessions can be much more effective. There are initiatives, cross product integrations, and the inevitable production/support issues that can also require time and attention, for these we should make sure no one person is overburdened with involvement in too many at one time. Balance is key!

In summary, these are just a few thoughts that were triggered in my daily reading today. While these are not new concepts or ideas, I believe they apply to the things that are happening around us today in the Tech Industry. As we continue as engineers on our collective journey to deliver value to our business/customer, its important to revisit key practices to ensure we have not forgotten the value of the old tricks generations before us have helped discover and improve on over time.