Helping you become a better software engineer through coding challenges that build real applications.

I’ve built and scaled high-performing teams of software engineers, shaped engineering culture, and driven technical strategy in VC-backed startups and multi-billion-dollar enterprises. I’m known for taking on underperforming teams and turning them into confident, capable, and effective engineering organisations.

I combine deep technical expertise with a pragmatic, commercially driven approach to leadership. My MBA, along with experience as a founder and startup executive, enables me to align technology strategy with business objectives and deliver measurable commercial outcomes. A servant leader at heart, I focus on mentoring, coaching, and enabling teams to deliver software that drives growth and business success.

I bring:
- 25+ years of software engineering experience across a range of technology stacks. 
- 20+ years of software engineering leadership experience from Engineering Manager to VP Engineering/CTO.
- 5+ years of experience representing software engineering at board level.

I don’t mind if you let an LLM write all your code, as long as you understand all your code.

Treat it the same way you’d treat a teammate’s pull request. Read it. Question it. Make sure it fits your team’s standards and can be understood by the people who will maintain it.

If it’s good, ship it. If it’s not, refine it or rewrite it. Simple.

AI should accelerate you, not replace your judgement. The quality of your work still depends on how well you can read, reason about, and explain the code you ship.

The rule stays the same: you own what goes to production, no matter who typed it.

John Crickett

CTO / VP Engineering / Head of Software Engineering

Here's my problem with people claiming they use AI to write 13,000 lines of production code per day and who suggest it is a repeatable process.

I can't write a clear enough specification for enough functionality to fill 13,000 lines of code per day, every single day.

And I've never met anyone else who can either.

The bottleneck isn't writing code, it's knowing what code to write.

Let's discuss how we tackle that bottleneck, with or without AI.

19 books on Software Architecture - that you can get for around 4% of the cover price right now!

👉 Modern Software Engineering
👉 Understanding Software Dynamics
👉 Software Requirements Essentials
👉 Righting Software
👉 Balancing Coupling in Software Design
👉 Architecture for Flow
👉 Effective Software Architecture
👉 Software Architecture and Decision-Making
👉 Domain Driven Design Distilled
👉 Functional and Concurrent Programming
👉 Software Architecture in Practice
👉 Practical Object-Oriented Design
👉 Serverless as a Game Changer
👉 The Async-First Playbook
👉 Principles of Web API Design
👉 Strategic Monoliths and Microservices
👉 Domain Storytelling
👉 Continuous Architecture in Practice
👉 Patterns for API Design

You get all of these worth over £618 for around £25 right now through Humble’s Book Bundle and support charity, details here: https://lnkd.in/en2eN_kG

Unskilled and inexperienced software engineers take simple requirements and create complex code.

Skilled and experienced software engineers take complex requirements and create simple code.

The difference is that experience maintaining a complex system, teaches them the benefits of simple code and gives them the skills to do so.

This is also why skilled, experienced software engineers are best positioned to leverage AI-assisted software engineering: they know how to turn a complex set of high level requirements into a simple set of low-level requirements that can be used to prompt and AI-agent and have it build simple code.

We were told there would be a tidal wave of new software the moment AI learned to code. So where is it?

Where are the one person billion dollar companies we kept hearing about?

Sure, the cost of writing code has dropped to almost nothing. Yet the tidal wave has not arrived.

The simple reason is they confused coding with engineering. Syntax got cheaper, clarity did not.

The bottleneck moved upstream. Our own ability to explain what we want.

Sure, AI works like the world’s fastest software engineer. It never sleeps, it knows almost every library, and it types faster than you can think. It just has no intuition. 

Give it a fuzzy instruction and you get a fuzzy product.

The real barrier to entry isn’t writing code. It is:

👉 The What, your product vision. AI can build almost anything, but it can’t tell you what matters. 

👉 The translation layer, your requirements. This is the hard skill. Can you turn a loose idea into small, logical instructions an LLM can follow? “Make it like Uber” isn’t a requirement, it’s a wish.

The truth is coding was never the bottleneck. Thinking and communicating was.   And it still is.

Coding was never the bottleneck.

Typing code has rarely been the slowest part of software development. Thinking has.

AI makes code cheaper and faster, and that’s useful. But it doesn’t touch the hardest parts of the job.

👨🏽‍💻We still have to decide what problem is worth solving.
👨🏽‍💻We still have to turn fuzzy needs into clear requirements.
👨🏽‍💻We still have to judge whether the thing we built actually works, for users and for the business.

AI can help across the lifecycle, not just at the keyboard:

👀 Explore problem spaces and edge cases.
🙋🏼‍♀️ Challenge assumptions in designs and APIs.
💡Generate test ideas and failure modes.
👓 Review trade-offs, not just syntax.

But none of that removes responsibility. It shifts it upstream.

If you don’t know what “good” looks like, AI will happily produce a lot of very confident nonsense. Faster.

The leverage isn’t replacing engineers with AI.  It’s using AI to amplify good engineering judgement.

Code was never the bottleneck. Clarity was.

Years ago an engineer was asked: “What’s the best thing about working here? And what’s the worst thing about working here?”

He responded instantly: “The people!”

That engineer was my Dad.

Whether you work in real engineering (actual physical things) like he did, or software engineering like I do, the most important and impactful part of the work is working with other people.

Here’s the secret to finding time to learn to be a better software engineer.

It’s surprisingly simple.

👉 Decide that learning is your top priority.

It’s that simple.

Because when you truly decide that it is, you prioritise it. I did that years ago and now it’s a habit that I don’t even notice.

📚 First thing in the morning I read for a few minutes.

🎧 During the day, I often listen to podcasts when I’m travelling / walking / have some time that would otherwise be ‘wasted’.

👨‍🎓 If the company I’m working for has learning and development material I go through it. It’s always open in a browser tab on my work computer. I use gaps between meetings that are too small to do focused work to fit in a few minutes of it.

🙋‍♂️ When I’ve managed a team I set aside an hour each week for some group learning - we get the time back because we learn to do better and share our knowledge.

📚 In the evening I read for a few minutes before bed.

Have you prioritised learning?

Tips for AI-Assisted software development:

If you don’t get it, don’t ship it.

AI can write code fast, but it can’t think about the future. Pasting code you don’t fully understand leads to tech debt, surprises, and skills that get rusty. 

Understanding the code keeps your skills sharp and your product reliable.

Read every bit of code before it hits your repo. If you can’t explain it, rewrite it or prompt the AI to try again.

Want to write better software?

Then embrace the Unix Philosophy as described in The Art of Unix Programming. It provides 17 great rules for writing better software.

With AI-assisted software development rules 1, 2, 5, 6, 7, 8 and 15 are even more important and using AI to generate code satisfies rule 14!

The rules are:

1. Rule of Modularity: Write simple parts connected by clean interfaces.
2. Rule of Clarity: Clarity is better than cleverness.
3. Rule of Composition: Design programs to be connected to other programs.
4. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
5. Rule of Simplicity: Design for simplicity; add complexity only where you must.
6. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
7. Rule of Transparency: Design for visibility to make inspection and debugging easier.
8. Rule of Robustness: Robustness is the child of transparency and simplicity.
9. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
10. Rule of Least Surprise: In interface design, always do the least surprising thing.
11. Rule of Silence: When a program has nothing surprising to say, it should say nothing.
12. Rule of Repair: When you must fail, fail noisily and as soon as possible.
13. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
14. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
16. Rule of Diversity: Distrust all claims for “one true way”.
17. Rule of Extensibility: Design for the future, because it will be here sooner than you think.

Embrace the UNIX Philosophy

Tips for AI-assisted software development:

All code is a liability. Don't add code unless the value is greater than the liability.

Every line of code you add carries a future cost. Code needs maintenance, upgrades, debugging, and shared team context. More code also increases complexity, raises the risk of bugs, and slows you down over time.

Key points to remember:

⃗→ Every line of code you write needs ongoing maintenance.
⃗→ The best code is the code you never have to write - leverage existing tools or libraries.
⃗→ More code creates more places for bugs to hide.
⃗→ Code starts aging the moment you ship it.
⃗→ Deleting code often delivers real value.
⃗→ Code you don’t add to the product can never break in production.
⃗→ Team cognitive load is limited so keep things simple.
⃗→ Dependencies bring hidden risk and extra upkeep.
⃗→ Code is expensive to change but cheap to defer.

Tips for AI-Assisted software development:

Stay out of the dumb zone

LLMs are stateless, so they only work with whatever you’ve packed into the current conversation. When your context window gets bloated, the model starts to lose precision. Once you creep past roughly forty percent of that window, or the agent starts drifting down the wrong path, quality tends to slide. That’s the dumb zone.

Most bad AI-assisted coding sessions happen because the agent is drowning in file reads, build logs, JSON blobs, tool details, tool output, and long chains of old messages. Even worse, the model can lock onto the wrong details and keep reinforcing them.

The fix is simple. Keep your context tight and refresh it often. Summaries, trimmed code snippets, and clean handoffs give you sharper results and a smoother workflow.

Do this: when the session starts wandering or the context window crosses forty percent, pause and compact. Create a short markdown summary of the intent, constraints, key decisions, and the exact files or line numbers that matter. Start your next request from that compact snapshot and stay well clear of the dumb zone.

Hat tip to Dex Horthy for the "dumb zone".

If you think communication skills are optional in software engineering, you’re already behind.

In an AI-assisted world, they matter even more.

AI can help you build software faster, but it can’t read minds. It can’t resolve ambiguity, spot hidden assumptions, or guess what you meant when your prompt is vague. That’s your job. Clear thinking and clear communication now sit right at the core of modern engineering work.

Strong engineers explain intent. They shape good prompts. They give crisp feedback. They write documentation that people can trust. Weak communication turns AI into a chaos machine, and it turns teams into slow, frustrated groups that never quite land the thing they planned.

A quick reminder from research into soft skills in software engineering:

📌 “Effective communication is critical to the success of a software development project.” 
📌 “Good communication skills are vitally important to being an effective engineer.”

If you want to level up as an engineer, invest in your communication skills. They’re not secondary. They’re the multiplier that makes everything else work.

Let’s take a break from AI. I want to talk about something far more important.
The Atlantic Forest in Brazil has been reduced to 13 percent of its original size. When a forest that once generated its own rain starts to disappear, people lose their water, farms fail, and entire ecosystems begin to collapse.

That’s why I’m supporting Forests4Water Brazil: Community Climate Action. Their goal is simple and ambitious. Plant one million trees by 2030. 

One tree at a time, they’re restoring the Atlantic Rainforest as a working water source for local communities.

Here’s what I love about their approach:

🌱 They plant where it matters. Trees go into water catchment areas and degraded hillsides where they stabilise soil and restore springs.
 🌱 They work with the community. Smallholder farmers learn agroforestry techniques that improve their land and protect their water.
 🌱 They run a full seed to forest pipeline. Seed collection, nursery care, and on-site planting create long term, local impact.
 🌱 They focus on resilience. Rebuilding forest cover helps bring back the region’s natural rain cycle and protects biodiversity in one of the world’s most important hotspots.

So far they’ve planted more than 250,000 trees. They’re aiming for a million. It’s the kind of goal that only gets met when enough people chip in.

Right now their partners at GlobalGiving are adding matching funds to every donation until December 3, 2025 at noon EST. Your contribution goes further, and the forest grows faster.

If you care about climate action, water security, biodiversity, or simply doing something meaningful today, this is a chance to help.

If you’d like to support them here’s the link: https://lnkd.in/ejWAqR-W 

Every donation plants another tree, supports another farm, and moves the Atlantic Forest one step closer to recovery. Let’s help them hit a million.

If you’d like to know more about Iracambi Rainforest Research and Conservation, follow them on LinkedIn or via their website: https://iracambi.com/ and follow Forests4Water via the project’s website: https://lnkd.in/eEjpXrDq

Tips for AI-assisted software development:

Boring tech gives AI superpowers.

AI coding agents performs best with tools, languages, and frameworks that have been around long enough to show up consistently in its training data. 

When you push it onto the bleeding edge, it starts hallucinating, and the quality drops. You’ll see odd patterns, missing steps, or advice that just doesn’t hold up.

To get the best results, pick a well-established framework or language. Pick 'boring' tech! Ten tell the AI exactly what you’re using.

Tips for AI-Assisted software development:

Don't ask AI to build the house, ask it to make the bricks.

People struggle with AI coding tools because they're asking for too much at once. They want entire features, complete apps, full systems. The AI generates something massive, half of it doesn't work, and now you're debugging spaghetti code you didn't write.

Flip the approach. Ask AI to generate small, well-defined components. A single function. A reusable component. One API endpoint. You architect how they fit together.

Think LEGO, not construction. AI is incredible at fabricating pieces to spec. 

You're still the one building something meaningful from them.

Tips for AI-assisted software development:

Be clear about the outcome you want.

When AI gets code wrong, it’s often because we didn’t explain the desired outcome clearly. If we can’t describe what we’re trying to build in precise, clear and unambiguous way, the model fills in the blanks and guesses. That leads to surprises and disappointment. 

The same happens when we give unclear instructions to human software engineers.

Try these tips for writing clear requirements:

✅ Write a two to three sentence description of the outcome you want. Keep it short and concrete.
✅ Break complex features into smaller, specific tasks so each part is easier to understand.
✅ Use examples or sample inputs/outputs to clarify exactly what success looks like.
✅ Avoid ambiguous terms. Use precise language that leaves little room for interpretation.
✅ Review your description as if you were the AI or a teammate who has never seen the project before; revise until it’s crystal clear.

Clear requirements lead to better code, well documented thinking leads to better outcomes.

Tips for AI-Assisted software development:

Use AI to question your assumptions and challenge your ideas.

AI is great at poking holes in your thinking. It can highlight blind spots, point out edge cases, and remind you of things you forgot to factor in. Think of it as a second pair of eyes that never gets tired.

Try this:
→ Ask the model to challenge your design, approach, or plan. 
→ Prompt it with questions like “What am I missing?” or “What risks haven’t I considered yet?”
→ Use the feedback to refine your idea before you write a line of code.

Tips for AI-Assisted software development:

Beware of context poisoning.

Coding agents don’t just fail because of bad models. Often they fail because their context gets polluted. Too many code files, loads of logs, retries, stale assumptions, past mistakes, old prompts, hallucinations and verbose tool outputs pile up until the agent’s context is filled with noise - polluted with irrelevant or incorrect instructions, code and examples. 

It’s like trying to think clearly in a room full of people shouting half-relevant facts. As noise grows, reasoning quality drops, costs rise, and latency creeps in.

What to do:

͕͕→ Summarise tool outputs before adding them to context.
͕͕→ Prune or reset stale information aggressively.
͕͕→ Split contexts by task or phase.
͕͕→ Design tools to return minimal, structured results.
͕͕→ Leverage fine-grained skills instead of tools.
͕͕→ Restart with a clean context when things go sideways or when starting a new task.

More context feels safer, but it’s often a trap. Relevance beats volume when you want agents that actually reason well.

29 great books on AI Algorithms and LLMs - that you can get for around 3% of the cover price right now!

This looks like a great deal, in particular I recommend Emmanuel Maggiori’s book: The AI Pocket Book. I'm looking forward to reading several others!

👉 Build A Large Language Model
👉 AI Agents In Action
👉 Grokking Artificial Intelligence Algorithms
👉 AI-Powered Search
👉 Generative AI In Action
👉 AI For Everyday IT
👉 Causal AI
👉 The Art of AI Product Development
👉 Starting Data Analytics with Generative AI and Python
👉 Learn AI-Assisted Python Programming
👉 AI as a Service
👉 Interpretable AI
👉 Software Testing with Generative AI
👉 Learn Generative AI With PyTorch
👉 Time Series Forecasting Using Foundation Models
👉 Effective Conversational AI
👉 How Large Language Models Work
👉 Succeeding With AI
👉 Introduction to Generative AI
👉 AI-Powered Developer
👉 Inside AI
👉 Build Financial Software With Generative AI
👉 Data Storytelling With Altair and AI
👉 Coding With AI
👉 Prompt Engineering For AI Systems
👉 Zero To AI
👉 The Complete Obsolete Guide to Generative AI
👉 The AI Pocket Book
👉 Regular Expression Puzzled and AI Coding Assistants

You get all of these worth over £1155 for around £35 right now through Humble’s Book Bundle and support charity, details here: https://lnkd.in/eAwEJAiu

taplio

John Crickett's Linkedin Analytics

John Crickett

Performance ScoreJohn Crickett's LinkedIn Performance

What is John talking about?

John Crickett's Best Posts (last 30 days)

Ready to grow your LinkedIn presence?

taplio

.css-6ytdur{background-image:linear-gradient(284deg, rgba(39, 43, 72, 1) 0%, rgba(33, 47, 183, 1) 100%);color:transparent;-webkit-background-clip:text;background-clip:text;}John Crickett's Linkedin Analytics

John Crickett

Performance Score.css-goub6s{font-size:var(--chakra-fontSizes-md);font-weight:500;color:var(--chakra-colors-gray-600);display:block;margin-top:var(--chakra-space-1);}John Crickett's LinkedIn Performance

What is John talking about?

John Crickett's Best Posts .css-1emoo84{font-size:var(--chakra-fontSizes-md);font-weight:400;color:var(--chakra-colors-gray-600);}(last 30 days)

Ready to grow your LinkedIn presence?

John Crickett's Linkedin Analytics

Performance ScoreJohn Crickett's LinkedIn Performance

John Crickett's Best Posts (last 30 days)