Comment by nomel
2 days ago
Code was malleable only to a developer with great code comprehension. In my experience, this was actually very rare. I think part of the reason is, you don't get any recognition for modifying a few lines of someone else's code compared to "I created this new library/app to solve this problem for our org!".
> Code was malleable only to a developer with great code comprehension
This used to be what being a dev was, if I recall. It's been a few years.
I think we romanticise the old days of coding now that agents are doing it.
Regarding the average developer as an imbecile was a cottage industry from Djikstra to FizzBuzz.
I romanticized even before, because there is a reason why society's view of developers shifted from geek losers to rich in the past 15 years. I remember when 15 years ago a girl told me that I'm different, because I'm not as looser as how she imagined developers.
Sure, but it was certainly a difference between those projects you authored and those you inherited, at least in time-to-productiveness.
The ability to understand and maintain inherited projects is more valuable than the ability to create new greenfield projects.
2 replies →
Not just comprehension, but authority.
We tend to forget in tech-oriented forums that most of us are bound to those who pay our salaries, and for many developers that payment is to be focused on revenue-generating, or client-focused work.
Developing advanced comprehension and being able to use it for long-term system stability are unfortunately not always paired in the daily work.
The problem has always been that code is malleable for all including those that think that have great code comprehension but actually don't.
People with poor comprehension have been changing code for years, and in great numbers. Doesn't mean it goes well, mind you.
The big trick always was to limit your scope. If you can't do that or if your tooling doesn't help you with that then very quickly you will run into the limits of what you can still keep in your head.