John Crickett
Author of CodingChallenges.fyi
Helping you become a better software engineer through coding challenges that build real applications.
- Reposted by John CrickettJoined @johncrickett.bsky.social's Coding Chats podcast, if you like podcasts Youtube: www.youtube.com/watch?v=z9Rr... Spotify: lnkd.in/eNJw955r Apple Podcasts: lnkd.in/epZnMjZz Overcast: lnkd.in/eFNPGVvS
- 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.
- “AI is incapable of programming well thought out and complex code” This is both true and irrelevant. The goal is to write well thought out and simple code (which may solve a complex problem).
- If you use AI to help you build software professionally, has your organisation provided any training? If so, what did it cover? What was missing? If not, why not?
- Software Engineers - need a project for the weekend? How about building your own LLM powered chatbot? codingchallenges.fyi/challenges/c... Or one of the 80+ other real-world projects you can build to level up your coding skills: codingchallenges.fyi/challenges/i...
- 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?
- Why do people feel the need to post stuff like this: "So far only the uninformed and b-players are using LLM" LLMs are way over-hyped, but attacking people is a weak argument.
- If you use AI to develop software, do you vibe code or do you do AI assisted engineering?
- In today's Coding Challenges I used Augment Code to develop a project in Gleam: codingchallenges.substack.com/p/using-ai-t...
- If this doesn't look like an AI bubble, what does?
- 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"
- 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. 🧵👇
- 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.
- 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.
-
View full threadFinally, 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.
- Is anyone using Zig in production? If so, what and why did you pick it?
- 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. 🧵👇
- 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.
- 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!
-
View full threadIf you want to check out the Coding Challenges and level up as software developer you can find it here: codingchallenges.substack.com
- 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.
- 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:
- 📈 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.
- 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...
- 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.
- 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.
- Who do you turn to when you're the most senior engineering leader in the room? When your team looks to you for clarity, vision, and direction, but you aren’t sure what to do. It can feel like there's no one you can turn to. That’s why I’m building a peer community of engineering leaders.
- The conversations are honest. The problems are familiar. If you're navigating complex leadership challenges, don't do it in isolation. There’s a whole room of people like you, they’re just not in your org chart.
- If you’d like to join the peer community for software engineering leaders that I’m building, let me know!
