The Seven Voyages Of SteveOne of the things I loved about software development was that we were always trying to get better at it, and there was no ceiling in sight for that. Using LLMs to make code is the opposite of that - learning to use them is more akin to learning rituals than it is to intellectual development. And don’t give me that nonsense about it being like using a compiler to move up an abstraction level; it’s not, any more than becoming a manager is coding at another level of abstraction.
I lived through the era in the noughties when the only promotion available outside management was to become a “software architect”. This was supposedly another level of abstraction over development and these experienced developers would level up the whole process by being dedicated architects. And you know what happened if those architects didn’t still actively write code too? Their designs were absolute garbage.
Martin Weber@sinbad no software architecture survives the first contact with code.
The fun thing is that when I was talking to guys at construction sites about the plans they receive from architects, they always needed to “compensate” to be able to actually build the thing.
We saw the same thing when doing architectural visualisation based on 2d plans. And 99% of architectural plans were only 2d.
So it’s not just a software issue.
@martinweber when we renovated our house I deliberately hired an architect who was also an engineer, so he didn’t just do the high level stuff but all the structural/technical engineering detail as well. There were still detail things to resolve but I think it was far more practical
Robert Kist 🇦🇹🇩🇪@sinbad @martinweber at a certain size you NEED an architect. I've seen so many "organic" codebases that were never refactored, but also where nobody had a clue about the big picture. Every engineer just had a view of their own specialized sub-domain, with nobody to effectively coordinate them and plan the systems evolution for 6, 12, 24 months onwards.
Those folk were all very clever people. But the lacked the overview but also sometimes interest for the big picture
@kwramm @sinbad sure, you need to plan for the big picture. It often is more of a social exercise than a technical one.
This also requires constant refactoring to adapt for changing and growing requirements.
It is a hard sell though. Why rewriting code that is not even 3 years old?
With my previous team we improved overall comprehension, reduced build times and increased decoupling to avoid side effects of changes. Delivered major features faster.
Engineering. Not just programming.