Software architect and developer with a passion for simple, effective solutions.
Focus on software design and backend development.
Tech: #typescript #kotlin #java
| Web page | https://henko.net/ |
| Blog | https://henko.net/blog/ |
Ever been handed a legacy system whose dependencies haven’t been touched in a decade—and then been asked to upgrade it?
My latest blog post is a survival guide.
Software survives by being easy to replace.
This may sound counterintuitive, but if there’s one thing we know, it’s that things change. Technology evolves. Requirements shift. Sooner or later your system, or parts of it, will be replaced. Often sooner than you think.
My latest blog post discusses some helpful guidelines.
A professional job is one that leaves the system ready for the next task.
We shouldn’t mark an issue as “done” until the codebase has been restored to a maintainable state. Feel free to reduce the scope if the deadline approaches, but make sure to complete the work you commit to.
https://henko.net/blog/leaving-code-messy-is-unprofessional/
If you look at the source code of a typical application, you will likely find business logic tangled with database calls, HTTP requests firing off in the middle of validation rules, and try/catch blocks sprinkled here and there. The biggest casualty of this coupling is testability…
If you look at the source code of a typical application, you will likely find business logic tangled with database calls, HTTP requests firing off in the middle of validation rules, and try/catch blocks sprinkled here and there. The biggest casualty of this coupling is testability…
A good architect builds the system that the client needs, not the one they want to build.
You cannot judge an architecture as good or bad without considering the context for which it was created. My latest blog post provides advice on how you can take context into account and make architectural decisions that truly matter.
https://henko.net/blog/good-architecture-depends-on-the-context/
AI-generated code often looks impressive at first, but then it drifts: it ignores conventions, duplicates logic, breaks architectural constraints, and assumes things that aren’t true.
To control this code drift you need to make AI take small, well-defined steps. Learn how in my latest blog post.
https://henko.net/blog/avoid-ai-code-drift-with-small-well-defined-steps/
AI promises to make us all 10x programmers, but if you stop reading the code, you aren’t speeding up; you’re creating instant legacy code.
Once the agents have written the code, the code becomes the ground truth. Either you understand the code well enough to verify and adjust it, or you rely on the AI to safely modify it. The latter means outsourcing correctness to a non-deterministic system with unknown failure modes.
Read more on my blog.
https://henko.net/blog/are-you-using-ai-to-generate-instant-legacy-code/
Good point by @jasongorman.
> It’s quite clear that the factors that make code easier for us to wrap our heads around also make LLM performance on it better (less unreliable).
This means that even if you think you will be able to vibe code your way to success without ever reading the source cdoe, it is _still_ important that the generated code is understandable by a human. 🙃
Aycan Gulez
Tanya Janca | SheHacksPurple 
