A lot to pick through in the article. I have my own reasons as to why professional development went to shit and I began to be unhappy in the industry — natural

A lot to pick through in the article. I have my own reasons as to why professional development went to shit and I began to be unhappy in the industry — naturally I looked in the article for validation. For me the reason I started out loving developing software and came to loathe it has everything to do with the environment within which we code. By this I guess I mean specifically management and expectations? I was never unhappy with my Apple salary (although you were often very aware that other engineers at Apple were being rewarded an order of magnitude more than you were) and the issue of "Technical Debt" I would cast differently than the article did. Did I hate technical debt? Not at all — if I was allowed to go in and "own" the code I was expected to fix/maintain. And this hints at one of the bigger changes that I saw over my career: when I started out at Apple in the 90's, engineers got their own "sandbox", got their own code they owned. If you wanted to, you could rewrite it from scratch — and we essentially did just that every two years or so with ColorSync (just as an example). Now I won't deny that "things were simpler back then" and rewriting an entire framework was something a pair of engineers could do in a release. I would not have been rewriting all of PDFKit a decade or so later (but I may have gone in and rewritten entire sections of it, like rewritten the PDF annotations for example). I still paint "technical debt" as a problem of "ownership" though. If I am free to rewrite as I see fit (perhaps in sections at a time) an entire framework, then I say bring on the technical debt. Hustle culture, bureaucracy — again, in the early days of my development career at Apple the engineers owned the schedule as well, owned the scheduling of the meetings.... "What do you think your team can deliver this OS release?" a marketing type might ask our tech lead. "We talked about that in a recent meeting," they might respond, "we have engineers already working on feature A and B and another engineer that wants to explore rewriting C on top of our new framework for some performance gains." The tech lead had made suggestions to the team, team had countered with their own requests or agreed, engineers had volunteered to take on the tasks... It goes without saying there was no scrum, etc. in those days. (And we liked it that way!) I know this is already long, but I think I want to jump off here with a comment on things like "agile" development, unit tests and code reviews — things that I personally think made the job miserable. All of these things that were brought on, that we suffered, didn't seem to have anything to do with improving development. Instead they seemed all about giving management cold comfort that "progress was being made" (or not). Management live in a world of dates and numbers, engineers live in a world of tasks, code robustness, error handling. Various efforts over the years seem to have been devised to burden the engineer with crap that give management the illusion of numbers and dates that they can take back to their own management. I guess to end this I'll just say it boils down to engineer autonomy, agency. There was a golden time when the engineers were steering the ship, and I liked it. > Despite being unhappy at work, most developers code outside of work as a hobby (68%) I think that one line from the article is the most telling.