John Crickett

There aren’t enough good software engineering managers in most companies.

And this problem is getting worse.

The biggest, hardest and most common problems we have with software delivery are not technical, they're people problems.

AI won't fix that.

In software engineering, “it depends” often sounds like a smart answer.

But if it’s the only answer, it’s useless.

It suggests enough experienced to know that context matters, but not enough to be able to articulate why.

Next time you are tempted to say “it depends”, complete the sentence.

“If someone was a very good communicator but a terrible software engineer would you hire them?”

This is a false dilemma.

To be a good communicator, you need to understand the domain that you are communicating about.

"If you can't explain it simply, you don't understand it well enough"

Exactly, we now need to really focus on that loop - getting the specs, which has always been the hard bit that people try to avoid doing (because it's hard).

The hardest part of software engineering has always been writing good clear requirements in a natural language.

Using current AI requires we do more of the hard bit to automate the easier bit of writing code.

Finally, be prepared to replace members of the team who are not able or willing to learn and adapt to deliver quality software.

If your software engineering team is not delivering, a rewrite is not going the change that.

They can identify those areas that need most immediate attention and prioritise the changes, processes and procedures you need to turn around the development and keep your business moving!

That will only be fixed by developing the team's skillset. Find someone who can lead, mentor or coach your team and have them work with the team to incrementally improve your software.

It wasn’t the language, library, platform or architecture that was wrong – after all they managed to deliver something and you have customers getting value from the software – it was the people, processes or procedures that resulted in poor quality, late software.

It’s not true. If you throw away your product and start again, you’re setting your business back months, maybe years, all whilst losing revenue and market leadership.

And there’s no reason to believe that your team is going to do a better job this time around.

I’ve met many tech executives frustrated that their software teams were failing to deliver.

In each case they’ve been advised by their software engineers that the answer was to rewrite all their software with some awesome new approach, technology, language, library, platform or architecture.

🧵👇

Is anyone using Zig in production?

If so, what and why did you pick it?

Coding Challenges | John Crickett | Substack A weekly Coding Challenge to help software engineers level up. Click to read Coding Challenges, by John Crickett, a Substack publication with tens of thousands of subscribers.

If you want to check out the Coding Challenges and level up as software developer you can find it here: codingchallenges.substack.com

29. COBOL is fairly readable - yes someone has used COBOL to do some of Coding Challenges!
30. Docusaurus is an amazing tool for building documentation websites, it powers the Coding Challenge website.
31. All the skills mention are best learned by doing!

25. There are far more algorithms than I imagined.
26. A lot of software developers don’t know how to read or write binary files.
27. A lot of software developers still struggle with internationalisation and unicode formats in text files.
28. I’m one of them.

20. Writing a README file for your repo makes it so much easier for someone else to understand.
21. Yet most don’t write one.
22. Go’s testing support is fantastic.
23. Go’s compiler is fast!
24. I’ve learned several new algorithms, i.e Meyers for longest common subsequence.

16. Many software engineerings don’t know how to handle application protocols written on top of TCP.
17. How to solve many of the challenges in Go.
18. Go.
19. Rust doesn’t natively support parameterised tests - my first disappointment with Rust. Fortunately there is a parameterized crate.

11. git diff supports four different diffing algorithms. Try saying that fast several times!
12. How to solve many of the challenges in Rust.
13. Rust.
14. Clear acceptance criteria is important and hard.
15. Writing that acceptance criteria get’s better with practice too.

7. And it had no version number, but was later versioned 0.9, so it could be distinguished from 1.0.
8. The original Redis version was around 300 lines of TCL.
9. Software engineers love building real projects - I am not uniq!
10. Many people don’t get my humour - comment below if you do!

4. The good news is that it drastically improves with practice.
5. Man pages are incredibly good and often underutilised by software engineers.
6. Some key projects started off tiny! The originally HTTP specification was just a page.

31 things I’ve learned writing 91 coding challenges over the last 27 months:

1. You can build some amazing software in less than 8 hours of focused time.
2. Breaking projects down into steps is a skill that many software engineers don’t have.
3. And one that many want to learn.

🧵👇

Coding Challenge #91 - Monkeytype This challenge is to build your own online typing test tool.

Software Engineers - need a project for the weekend?

How about building your own Monkeytype?

open.substack.com/pub/codingch...

Or one of the 90+ other real-world projects you can build to level up your coding skills:
codingchallenges.fyi/challenges/i...

Networking tip: lead with curiosity, not your job title.

Curious leaders ask better questions, build stronger relationships, and spot opportunities others miss.

That’s where the good stuff starts.

If you’re a senior engineering leader, I’m building a community — DM me if you’re curious.

Software Engineers - need a project for the weekend?

How about building your own ELIZA chatbot?

codingchallenges.substack.com/p/coding-cha...

Or one of the 80+ other real-world projects you can use to level up your coding skills:

[https://codingchallenges.fyi/challenges/intro](t.co/jZPvdDtBt1)

Networking tip: just talk to the other awkward person at the event.

You have actual data on both the CLV of your customers and how many customers report the bug. Plus it’s easy to ask customers who are leaving, why they’re leaving.

Whereas, you’re only estimating the new revenue and the cost to build, sell and market the feature.

Real prioritisation means weighing both.
If you can’t do that, you’re not managing a roadmap. You’re just guessing.

And the real kicker...

📈 Feature ROI = expected new revenue – cost to build.
📉 Bug fix ROI = expected reduction in churn × customer lifetime value.

One might bring in new money.
The other protects the money you’re already making.

If you say you can’t prioritise a bug fix over a feature because “features generate revenue,” what you’re really saying is: you lack the judgment, experience, or data to prioritise effectively.

Here’s how you do it:

Q: How do you find open source projects to contribute to?

A: Use Google to find a site that covers issues marked "good first issue" then look through those to find a project that interests you.