Software Engineering Foundations

These are the articles that cover my systems for building products and helping teams.

These articles are interlinked and all related to one another forming a complete system.

I update these articles regularly as I learn and improve.

List of article summaries

#management

Hiring engineers in a candidate-driven marketplace

I’m writing this at the start of 2022 and it’s never been tougher to hire engineers. There is a very strong candidate market in software engineering at the moment.

There are roughly 1 million open software engineering roles in the USA and somewhere around 200,000 candidates. The rest of the world is having similar issues hiring engineers. Most people seem to think it will be this way for quite some time. There just aren’t enough engineers as software becomes more important to every industry.

When I started my career getting hired was skewed in favour of the hiring organisation. A candidate had to have a degree and there was no remote work so your choices for where to work were limited.

Now, in 2022 candidates with a couple of years of experience are in high demand and practises for hiring have changed significantly. You can work anywhere across a few time zones and university degrees thankfully aren’t necessary any more.

I’m mostly on the other side of interviews these days, so my are tips for other folks trying to hire engineers during these tricky times!

#developer-experience

How engineers can help deliver software effectively

Delivery managers and team leads have the responsibility to deliver a software system via an engineering team.

Your customer wants every feature to work perfectly and they want it delivered yesterday. Your team wants to learn and grow.

It’s a tough role managing all the stakeholders and creators in a project.

Engineers can help drive great delivery by empathising with and supporting the delivery manager or leads in a project team.

#engineering

Engineering systems for consistency and impact

Your most impactful engineering is done before you write any code.

It’s important to have some systems around how you approach problems to make sure you’re consistent every time.

These are some of the techniques I use to make sure I’m covering as many angles as possible when doing my pre-coding engineering.

#developer-experience

How to identify a great tech organisation before you join

No one wants to waste time working for an organisation that’s a bad fit. But how do you know a good place from a bad place until you actually work there?

It’s important to spend the same amount of time analysing a potential organisation as they spend analysing you!

During an interview process an organisation has personality testing, resumes, tech testing, behavioural testing, reference checks, bank checks, police checks and more.

If it sounds like a very one-sided process that’s because it is! But there are ways you can bring more balance and here are some important things to research before accepting any engineering job offer.

#engineering

How software engineers can avoid commoditisation

Engineers spend most of their learning time on technical implementation content. Things like new frameworks, languages or cloud platforms.

But turning solutions into code is a tiny part of what you do and it’s getting less valuable year by year.

As we’ve seen with “no-code” and tools like GitHub Copilot, the implementation part of our role is increasingly becoming commoditised.

You could generalise that the value an engineer brings to a team is their ability to analyse problems and synthesise context. The part of your role as an engineer that will never be replaced by “no-code” or AI is this high level cognition.

The true human aspect of being an engineer is working in a team and considering other people’s ideas, emotions and thoughts while solving these problems.

So shouldn’t you train these meta-cognition skills as much as you train the specific technologies?

Every engineer should spend time learning and applying general tools for thinking. These tools are applicable to almost all problems so the compounded payback on your invested time is huge.

Clearer thinking will amplify all the other skills you have and any frameworks or tools you learn will give you results for the rest of your career.

Like any skill, improving the way you think takes deliberate study and practice.

These are some of the tools and systems for thinking that I refer back to all the time.

#engineering

20 questions for a valuable code review

I recently had an interesting discussion around the value of doing code reviews and the value of mandatory code reviews.

I think code reviews are extremely valuable and should be done by most organisations and teams.

A valuable code review will

  • pass institutional knowledge around the org
  • help all engineers grow their skills
  • maintain quality in the face of all the other time pressures your team faces

But how do you keep a code review valuable?

#engineering

10 Useful product-thinking lessons for engineers

Have you ever struggled to explain the business value of a piece of engineering? Like why a particular piece of tech debt needs to be paid down now?

Engineers can learn from the techniques and rigour that product management practice has created in the past few years to

  1. To show business value in their own engineering work where it’s not easy to articulate
  2. To empathise better with customers of the software their building
  3. To understand the business context you’re in

For example, how can you know that you’re building something useful for your customer? How can you convince others that you’re not ahead of your time with an engineering solution?

For engineers there are some product development lessons that will improve your empathy and communication with non-engineers in your org.

#engineering

Minimum viable discovery and software estimation for engineering work

I recently had to estimate 6 months of work for a new product after just 2 hours of discovery. This is a short deadline for an accurate estimate and I felt uncomfortable providing a number.

I ultimately gave a gut feeling estimate for the work because that’s my job and we needed one by the next day. I did specify it was at least 20-30% wrong and highlighted the major risk I saw - a new third party integration that we had never integrated with before.

The whole scenario got me thinking about what works and doesn’t work for me when estimating larger pieces of work. Here are some of the thoughts, tips, tricks and learnings from 10 years of providing dodgy software estimates!

#management

Are tools like GitHub and Jira artificially restricting improvements to your practices?

Just like modern product development, the best practices for your team also come from learning, iterating and adapting to changing requirements. There are no “best practices” that can be applied to all teams and the way you work will likely be unique to your team’s requirements and outcomes.

Applying a software tool like Jira or GitHub PRs locks a team in to the tool’s practices. The team’s practices become tightly coupled to the tool’s prescription.

The danger here is that the tool accidentally becomes “the way we do it here”. The original reasons the tool was chosen are forgotten and it’s more difficult to experiment with better practices when your team is artificially bounded by a mandatory tool.

#management

How to prioritize too many feature requests

There’s always more work to do than time available to do it. Effective prioritisation is very important to provide the focus to be successful at work.

In general prioritisation is some product of effort x cost x time or value x complexity applied to possible tasks. The tasks should be aligned to your strategy.

There are some well known frameworks for prioritisation that I find useful. I’ll describe them here and talk about how to choose one with your team.