From The Challenges - HTTP Load Tester

Exploring the software engineering lessons we can learn from the solutions I've seen.

Hi this is John with this week’s Coding Challenge.

🙏 Thank you for being one of the 92, 182 software developers who have subscribed, I’m honoured to have you as a reader. 🎉

If there is a Coding Challenge you’d like to see, please let me know by replying to this email📧

Welcome To Coding Challenges - From The Challenges!

In this Coding Challenges “from the challenges” newsletter I’m sharing some of the common mistakes I see software engineers make when tackling the Coding Challenges.

I’m sharing both the mistakes people make and some thoughts on how you can you avoid making the same mistakes when taking on the coding challenges or when writing software professionally. Sometimes we have to make mistakes to learn from them, somethings we can learn from other people’s mistakes, then make our own new ones! 😀

Recapping The HTTP Load Tester Coding Challenge

In the build your own HTTP Load Tester coding challenge the goal was to write a load tester for a website / API delivered over HTTP(S).

It’s a useful tool for tasks such as checking your system handles concurrent load, scales correctly under load and to verify that your rate limiting software works correctly.

🚨 NEWS - New Monthly Live Workshops For Paid Subscribers

I’m now running live, workshops for paid subscribers. Yesterday we covered AI-assisted software engineering.

I answered the following questions:

1. Are LLMs AI?

2. What is an LLM?

3. What is an AI coding assistant?

4. Why do we care what an AI coding assistant is?

5. How can we use that knowledge to get the most from them?

6. There must be more to it than that! How can we leverage AI to build better software?

So those who attended can make better use of AI when developing software.

The next one will run early February, paid subscribers get to suggest the topics and will have access to the archive of past workshops.

If You Enjoy Coding Challenges Here Are Four Ways You Can Help Support It

1. Refer a friend or colleague to the newsletter. 🙏

2. Sign up for a paid subscription - think of it as buying me a coffee ☕️, with the bonus that you get access to a monthly AMA and 20% off any of my courses.

3. Buy one of my self-paced courses that walk you through a Coding Challenge.

4. Join one of my live courses where I personally teach you Go by building five of the coding challenges or systems software development by building a Redis clone.

Five Common Mistakes Software Engineers Make Solving The HTTP Load Tester Coding Challenge

I’ve pulled together this list of common mistakes from the hundreds of submissions I’ve been sent privately and the many shared in the Coding Challenges Shared Solutions GitHub Repo.

Mistake 1 - Non-Idiomatic Code

Writing non-idiomatic code is a mistake because it creates unnecessary friction for everyone who touches your codebase. When you ignore the established conventions of your programming language or framework, you’re essentially speaking with an accent that makes you harder to understand, even if your logic is technically correct.

Following idioms matters for two key reasons. First, it makes your code instantly recognisable to other engineers familiar with the programming language / library / framework. They can scan through it quickly, spot patterns they know, and understand your intent without mental gymnastics. Second, modern AI tools are trained on vast amounts of idiomatic code. When you write Python that looks like Java, or React that fights against its conventions, you’re making it harder for AI assistants to help you debug, refactor, or extend your work.

Think of idioms as the shortcuts and common phrases of programming. Just like saying “kick the bucket” is more natural than “cease biological functions,” using a list comprehension in Python or destructuring in JavaScript signals that you understand the language’s culture. Code that fights its own language becomes a maintenance burden; code that embraces it becomes a pleasure to work with.

Mistake 2 - Error Handling And Testing

Writing tests is how you prove your code actually works. Without tests, you’re crossing your fingers and hoping nothing breaks. Tests catch bugs before they hit production. They document how the code should behave. They give you confidence to refactor later.

Error handling deserves more care than most of us give it. When we treat errors as an afterthought, or assume they won’t happen.

For a load tester. If it can’t connect to a server, that might look like a error. But often it’s the signal you’re actually looking for. The system under test is buckling under pressure.

If you abort on connection failures, you miss the point entirely. Instead:

• record the failures

• track them over time

• report them clearly

That data tells the real story.

Good error handling means asking what each error means in context. Should you retry? Log and continue? Abort? There’s no universal answer. It depends on what you’re building and why.

Mistake 3 - Building Your Own Installer / Package Manager

Building your own installer or package manager is almost always a mistake because you’re solving a problem that’s already been solved. Every ecosystem has established tools that developers already know. Use them!

When you create something custom, you’re asking users to learn your specific tooling instead of letting them use the muscle memory they’ve built up over years. That’s friction they don’t need. Beyond the learning curve, you inherit a massive maintenance burden. Package managers need to handle dependency resolution, version conflicts, security updates, uninstallation, and edge cases you haven’t thought of yet. The standard tools have been battle-tested by millions of users and have communities fixing bugs and adding features.

And here’s something often overlooked: you should be learning the tools everyone else uses too. When you work with standard package managers, you’re building skills that transfer to other projects and make you more effective when collaborating with other developers. Creating a custom tool isolates you from the broader community and the knowledge that comes with it.

Mistake 4 - Commented Out Code In Repo

Committing commented-out code creates several problems:

1. Loss of clarity: It clutters your codebase and makes it harder to understand what’s actually running. Readers waste time wondering if the commented code is important, outdated, or broken.

2. False sense of safety: People often leave commented code “just in case,” but that’s what version control is for. If you need old code, you can always retrieve it from git history. Keeping it around suggests you don’t trust your version control system.

3. Maintenance burden: When you refactor or update your code, you’ll need to decide whether to update the commented sections too. This creates extra cognitive load and increases the chance of inconsistencies.

4. Code rot: Commented code becomes stale quickly. It doesn’t get tested, doesn’t get updated with API changes, and eventually becomes useless. Six months later, no one remembers why it’s there or if it even works anymore.

5. AI context poisoning: This is a growing concern. When you’re using AI coding assistants like, commented-out code pollutes the context window. The AI sees both the active code and the commented code, which can confuse it about your actual intentions. It might suggest completions based on the wrong patterns or mix approaches from dead code with your current implementation. Clean, uncommented code gives AI tools much better signal about what you’re actually trying to accomplish.

The simple rule: if you’re not using it, delete it. Git remembers everything so you can always recover it later.

Mistake 5 - Executable In The Repo

It’s a bad practice for several reasons:

1. Binary bloat: Executables are large binary files that don’t compress well. Every time you recompile and commit a new version, Git stores the entire file again, not just the differences. Your repository size balloons quickly.

2. Merge conflicts: You can’t meaningfully merge binary files. If two people commit different versions of the same executable, Git can’t help resolve the conflict. Someone just has to pick one version or the other.

3. Not cross-platform: An executable compiled on Windows won’t run on Mac or Linux. If your team uses different operating systems, the binary is useless to most people anyway.

4. Security and trust issues: Executables can contain malware. Most people won’t want to run a random binary from a repo without rebuilding it from source themselves. It’s a security risk.

5. Redundant: The whole point of version control is to track source code. Anyone can generate the executable by compiling the source. You’re storing something that can be recreated on demand.

6. Build reproducibility: Committing executables can hide problems with your build process. If the build works on your machine but not others, you might not notice if you’re just sharing the binary.

7. Better alternatives: Use a package manager, artifact repository, or release system (like GitHub Releases) for distributing binaries. Keep your Git repo focused on source code, configuration, and documentation.

Some exceptions exist, like small tools or dependencies that can’t be easily rebuilt, but those are rare. For your own code, keep executables out of Git/source control.

Request for Feedback

I’m writing these coding challenges and this new from the challenges series to help you develop your skills as a software engineer based on how I’ve approached my own personal learning and development.

What works for me, might not be the best way for you - so if you have suggestions for how I can make these challenges more useful to you and others, please get in touch and let me know. All feedback greatly appreciated.

You can reach me on Bluesky, LinkedIn or through SubStack

Thanks and happy coding!

John

P.S. If You Enjoy Coding Challenges Here Are Four Ways You Can Help Support It

1. Refer a friend or colleague to the newsletter. 🙏

2. Sign up for a paid subscription - think of it as buying me a coffee ☕️ twice a month, with the bonus that you also get 20% off any of my courses.

3. Buy one of my courses that walk you through a Coding Challenge.

4. Subscribe to the Coding Challenges YouTube channel!