Code that expresses intent, but doesn't work has _more_ value than code that works, but is unintelligible.

Any piece of code will break/be fixed/be changed many times during its life. Meaning over the long term cost of changing the code will usually dominate over the cost of initial development.

In a project I tried to argue to remove code. Stuff that already had alternate implementations in the codebase, plus some things that are not used anymore. I couldn't get it across. Why do I want to remove working code? "What if" we need it? Why change processes?

Iterating is not about getting things perfect. It is about making things better, sometimes significantly, but more often just slightly. I had many PR reviews drag on for days, in which time I could have added 2 or 3 iterations, improving the code significantly.

Developers! Having data is not a responsibility. Returning internal state is not a behavior. Making internal state private, but having public accessors is not encapsulation.

You guys experience that situation, when there was 1 decision way back in the project by someone to use a tool slightly wrong. And that led to all sorts of workarounds and additional bad decisions. Now there's code and infra built on those bad decisions and you can't reverse it.

"Fear leads to anger, anger leads to hate, hate leads to CRUD, CRUD leads to suffering."

In programming, simple != easy For example, it's easy to add a Transactional annotation to a Spring app, but the underlying transaction manager is anything but simple - it handles distributed transactions, is pluggable and configurable via tons of annotations. You never want to

Saw a Java presentation: cool, fast paced, lots of stuff done, magic stitched with annotations. Total opposite of building a maintainable product. Maintenance is boring, things must be predictable and obvious rather than flashy and cool. Total opposite of flashy presentation

"No code" is not automatically better. If you still have similar complexity of the process itself, but now with less control, less automation, less testing, you're potentially much worse off.

Oh no, I tried to define a new project in our repo and it doesn't work. I'm in sbt hell again.

Documentation in an internal project is basically saying: I didn't know how to solve this properly, so this is what I did, you figure it out!

AI will eventually replace developers. There's just no argument against that. I personally see that as a low bar though. Humans are hilariously bad at complex problem solving. Just imagine what we could have, if "software" is essentially zero cost and immediate.

I find this attitude, that computers can never become "truly" intelligent (whatever that means), utterly bizarre. The human brain is a computer. It's just made of different stuff than microchips. Of course it is possible to re-engineer intelligence. x.com/VbcApologetics…

I had a boss once who literally said I should stop helping other departments' projects, because it is not in my yearly objectives, I should instead spend my time writing documents and presentations about how well we support projects and how invaluable we are. For real.

“Manager”, “Builder”, “Factory”, or another technical name in your code structure isn’t Screaming Architecture or Vertical Slices. codeopinion.com/screaming-arch…

It's 2025. Customer (a tech startup!) does not have automated tests, deploy to kubernetes, but only semi-automatically. No CI/CD. No stable deploys. No way to revert. Tweaking prod from local machine normal, including schema changes. Changes take days, so are resisted heavily.

I really don't like sbt. It's slow, cumbersome, with entirely cryptic abstractions. It isn't even normal scala code. It's really a shame it's the de-facto standard for scala projects, when much better alternatives exist.