John Crickett

@johncrickett.bsky.social

Author of CodingChallenges.fyi Helping you become a better software engineer through coding challenges that build real applications.

"Forget 10x programmers. 1,000x programmers really exist, we just don't fully acknowledge it." Naval Ravikant He's right. The difference isn't speed or talent. It's direction. I have spent weeks building features that nobody used. Asking "should we build this?" would have created more value.

GitHub Copilot will beat Claude Code. Not because it's better. Copilot is the new IBM. Checks the enterprise box. Microsoft is already on the PLS. If it under-delivers, everyone else bought it too. "You won't get fired for buying X" really means "you won't get blamed for buying X." Big difference

An OpenAI forward deployed engineer is coming on my podcast tomorrow. FDEs sit between the models and the companies using them. They see what works, what breaks, and what surprises everyone. I've got my questions ready, but what would you ask?

Every programmer should learn C. Implement a linked list, hash table, and binary tree. Then build a simple CLI program and a basic network server. Not because you'll use it daily, but because it strips away the abstractions and shows you what's really beneath whatever language you use daily.

What AI newsletters are you actually reading? Not the ones covering the latest model. The ones writing about AI in healthcare, manufacturing, logistics, defense, energy. Drones, autonomous vehicles, robotics. The applied stuff. The "boring" stuff. The stuff that's actually changing industries.

Who are the people writing about applying AI to real-world problems? Not the next coding agent, not the latest LLM wrapper. What about AI for robotics, logistics, healthcare, manufacturing? The other 99% of AI. Drop names below. I want to follow them.

In any new role you should always seek to understand before you act. Make sure you understand not just the what, but also the why. Only then should you start changing the what, if the why is no longer valid. Exception: if you've been hired to put out a raging fire.

There's a take going around that not knowing how to code is an advantage when using AI. It’s wrong. The more you understand coding and software engineering, the better your prompts, the better you manage the context, the better your feedback, and the better the product you ship.

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 in its training data. When use the bleeding edge, it hallucinates.

Tips for AI-Assisted software development: Work in small batch sizes. Humans and AI have limited short term memory. Ensure the task you're working on fits within your and AI's short-term memory. When switching tasks start a new session, clear the context of you and the AI.

If you code with AI, and don't do Test-Driven Development, have you tried or are you going to try doing Spec-Driven Development? What is the attraction? What do you see as being a blocker to doing it?

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"

Bild

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.

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. 🧵👇

Bild

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. 🧵👇

Bild

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.