41–50 of 190 posts
> Say No Getting junior devs to do this is like pulling teeth. Trying to get a feature stopped after they've built it is soul crushing for them. It's a problem. At this point I've all but given up beyond minimizing the blast radius in code review.
> Say No Getting junior devs to do this is like pulling teeth. Trying to get a feature stopped after they've built it is soul crushing for them. It's a problem. At this point I've all but given up beyond minimizing the blast radius in code review.
Is there no planning flow where you work/have worked? I understand giving developers freedom to build, but some sort of oversight by someone with a view of everything that's going on is also necessary.
Typically there are entire planning exercises that happen before stuff even hits a JIRA board.
These are usually conducted by Product Managers, Project Managers, analysts, and often in startups the CEO themselves.
The fact that people are off building features willy nilly sounds like it would contribute to messy code base.
Knowing what's next helps plan the work on the developer side as well which also minimizes the blast radius.
Would be curious to know what strategies other people apply in order to keep complexity down over time!
Would be curious to know what strategies other people apply in order to keep complexity down over time!
I'm a big fan of the "IO Sandwich". This is where you keep complex computation as pure functions as much as possible. And push the IO to the edges of the system. So you might have read-compute-write. This keeps the computation functions testable and composable.
In my experience people refactor code to their own understanding of the problem and not all refactorings improve the code. People abstract before an abstraction is necessary. I find single file dense leetcode style code easier to understand and follow the flow. Algorithmic code I can reason around. A large mature codebase is far harder to get to know. One of the first things I do when I study a new codebase is find a…
Where I'm definitely weird is that I have a higher verbal score than your typical developer, and I'm not afraid to use a thesaurus to find a better word for something. Too often we end up recycling jargon in situations where they are not quite doing the same thing but nobody could be arsed to open thesaurus.com and find a word that telegraphs, "B is like A but is not actually A."
Would be curious to know what strategies other people apply in order to keep complexity down over time!
> Minimize Dependencies ... Consider doing it yourself. This is terrible advice! Maximize your dependencies. Adopt as much external code as possible. Build what you can with it. Then, as you reach the limits of those dependencies, and you absolutely understand what needs to get done replace them as you need to. The vast majority of what people write will be trashed and/or changed radically. You should adopt whatever…
The libraries attempt to "dumb down" TCP, HTTP, etc and treat them as an abstraction that you don't need to know the details of. But it ends up biting people in the a$$ because networking isn't a perfect world where every request succeeds, terminates cleanly, or goes to the destination you expect. Whisking away all the complexity makes developers dumber as they eschew solving low-level problems with over-engineered high-level solutions that paper over the underlying issue, e.g. using mTLS to get around the fact that you're using DHCP to assign address space to nodes incorrectly, or making every API request a POST because the designer didn't understand HTTP caching, and so on. You get these endless problems that were solved decades ago because people keep trying to reinvent the wheel.
Would be curious to know what strategies other people apply in order to keep complexity down over time!
There's a great section in The Practice of Programming where the book describes how you should structure your code to not just be structured nicely now, but to plan for the future; to structure it so that changes are easy, organized, and don't break anything. It's not exhaustive but it's a powerful general idea and I always like introducing developers to it for the first time.