Preparing a talk "Agentic coding - A Systems Perspective", and along the way realized that cognitive/comprehension debt didn't arrive with the advent of agentic coding. Most teams doing work in isolation (individually), already heavily experienced it.
What a time to be alive for people who have been pushing the systems perspective in software.
I retired in March, but today's React vuln should remind everyone that @charity.wtf has always been right: if you have a holiday code freeze, your build-test-deploy-rollback process is completely broken and you should not work on anything else until that's fixed.
Impact-driven promotions almost always (eventually) lead to promotion-driven development. Little wonder it's so widespread throughout Big Tech and larger companies. Full: newsletter.pragmaticengineer.com/p/preparing-...
I tell this story periodically, but it seems like it's time again: General Motors ran an automobile manufacturing plant in Fremont, California, that was one of the worst in the country. Accident rates and defects were astronomical. Absenteeism was through the roof. 1/12
The meaning of pragmatism as a term has been hijacked to mean subjectively justified hacking and piling up a mountain of cruft. A "just dump it under the rug while no one is looking" development.
Wild to me that a CEO sets goals about outcomes that have nothing to do with the business (are customers more satisfied? Is the product more reliable? Etc.) Setting the goal of what % of code should be AI-generated is as useful as setting the goal of how many lines of code devs should write per day
Working in high-quality code improves development speed by as much as 7x. Mob/Ensemble programming can give you a 3x improvement. Getting rid of bottlenecks also yields major improvement. You get the idea. None of the above impacts outcomes. 4/5
Workarounds are easy to see in a code base. When you're looking at one, you instantly know. It's a big code smell.
Have you ever sat down with a couple of workmates to track down a bug or solve a tricky problem? Congratulations—you've done Ensemble Programming. Worked pretty well, didn't it? So why not work that way all the time?
Messy code and fancy code are two sides of the same coin. Code can become confusing and deceitful by either neglect or ornamentation. *Clean*/*good*/*expert*/*professional* code--call it what you may--isn't opulent, decorated, fancy, high-concept stuff. It's profoundly ordinary.
From deadline to *deadlock* in 3 simple steps: 1. We do not use deadlines. 2. For this particular super critical thing we can try introducing a deadline. 3. Wow! that was a success. Probably the deadline is the reason. Let's introduce deadlines for every single meaningless task.
