The non programming side of software

I think the soft skills related portion of engineering grows in importance as we no longer write code. Having a strong technical foundation is still important as we need to understand the output of AI, to provide it the right context, to correct its direction or to solve problems that AI cannot crack. This also depends on the organisation structure and size but you have to remember the role of an Engineer is to solve problems that ultimately provide value to the customer whether is explaining to product why we should invest in a feature or aligning across the team on a shared technical direction.

Avoiding arguments

We have all been in meetings where it turns into mostly an argument where each party is just concerned with getting their idea across instead of working towards a solution. Most of these discussions are inconsequential and just waste time. It’s best to avoid adding to it and let it dissolve on its own. You may wonder if this is bad practice to let individuals with strong opinions to always have their way. However it’s one thing to agree but often it also requires follow up action which often they lack the follow through. Common arguments are stylistic coding patterns like class based or functional or whether linting rules are helpful. There may also be issues with project management whether to spend a lot of time planning or not or if there should be pair programming. I think the answer usually depends on the situation and it’s very difficult to say a certain rule is always correct.

It’s best to focus on outcomes instead of how you achieve the outcome. If projects are delivered on time at the agreed upon scope at a high quality from the perception of external engineers and customers then whatever method you used to achieve that is the right one. This takes experience and effort to achieve.

Aligning the right way

Instead of long winded arguments in zoom calls the right way to achieve alignment is to lead with data where possible and provide examples. This often takes form in RFCs or DACIs or LDRs. A well written technical document is short and concise on the problem and solution but also goes into technicals if needed. For example if you are considering using a certain framework and performance is important you carry out a load test to see the impact. Or if you should develop a certain feature you could look at customer usage patterns and measure the impact it could have on that. I would avoid things where is unclear the impact or if I can’t clearly define it. Thats a signal to me it’s not worth our time.