Software Developer | Building web experiences with code | Sharing dev insights, bugs & banter lockedIn....
Earth
Joined May 2026
- Tweets1.4K
- Following618
- Followers660
- Likes6.8K
Pinned Tweet
I've been a little quiet on here for a few days because work has been keeping me busy.
But I'm back now, fully active and ready to connect, share ideas, learn, and talk tech again.
Let's get back to building!
Unpopular opinion:
Knowing how to read someone else's code is just as important as knowing how to write your own.
Real-world software development isn't a blank editor and a fresh project.
Sometimes, your biggest task is understanding a decision someone made five years ago.
Race conditions are a reminder that code doesn't always execute in the order you expect.
Two operations can interfere with each other simply because their timing overlaps.
Sometimes, the bug isn't what your code does. It's WHEN it does it.
Imagine you inherit a codebase with:
- No documentation
- 300+ dependencies
- Almost no tests
- One developer who understands everything
What's the FIRST thing you'd do?
I'd be interested in how different engineers approach this situation.
A monolith isn't automatically bad architecture.
A well-structured monolith can be easier to develop, test, deploy, and maintain than a poorly designed microservices system.
Don't introduce distributed-system complexity just because microservices sound impressive.
A password should never be stored as plain text.
Not in your database.
Not in your logs.
Not in a backup.
Use a dedicated password-hashing algorithm such as Argon2id or bcrypt, with proper configuration.
Security decisions made early can prevent very expensive mistakes later.
Your favourite framework is not your engineering identity.
React, Vue, Angular, Svelte, Next.js...
They're tools. The real skill is understanding the problem well enough to know which tool makes sense—and when none of them is necessary.
One of the most underrated programming skills is knowing when NOT to write code.
Sometimes the best engineering decision is deleting a complicated solution, using an existing tool, or simplifying the entire approach.
More code doesn't automatically mean better software.
Francis Dubem retweeted
The fragility runs deeper when you add redirects and URL normalization. A server that silently canonicalizes /path/ to /path is making a promise that clients depend on, but the HTTP spec does not require it, so the agreement is implicit and easily broken during migrations.
