it used to be that i pay your due at some enterpise and learn some corner of codebase really well and become go to person. that would give you job security.
Now I’m basically expected to do what my boss wants me to do every minute of the day, it’s gotten much more micromanaged.
Before: "I learned very little this year, because I was placed in charge of the same stuff, and I've already learned most of what I could from tinkering with that code, stepping through its architecture, and dealing with those recurring problems."
Soon: "I learned very little this year, because I don't deeply interact with anything, I just pull the lever on the babbling slot-machine until I get lucky and things seems to quiet down."
If you believe Claude makes you a good engineer and you previously weren't, I am saying that's not true and you still are not a good engineer even with the latest-and-greatest Claude model.
The difference is between "helps" (in your comment) or "you are". Sure, it helps a good engineer do more, do better, etc — but the thread was on being a good engineer.
It's "just another tool", sure. But one that is so powerful that some things that used to take a day now take minutes, or ones that used to take a week now take a day. And I get even more praises now, along with more time to focus on understanding the needs and controlling quality. For me it's not really about stuffing as much features as possible, but providing better software.
I'm glad this happened after 25 years in my career. I believe I'm in a privileged position where I can benefit from LLMs and still have the knowledge to effectively correct the machine or go back to "manual mode" if anything goes wrong.
But also to the original Simon's point that using LLM does not a good engineer make — how we make one is still on us with 10+ years (I've got "only" 20) of experience to figure out now that LLMs are here!
Implicit definition of a good engineer is the one who chooses the right balance between effort, complexity, performance to build a working software system for a business need that can be evolved according to (unforeseen!) future business needs at reasonable cost.
This describes the expectation my managers had of me at every software job I've had, and I've been doing this for a decade and a half
It's definitely not a new thing since LLMs came around, if that is what you were implying
It is on a scale that it is required now. Previously you could say "it'll take me a week to decipher the mess", now they can just say "can't you use an agent to make it fast?".
I had the displeasure of working with those types. One of them replies to any question or challenge to a technical problem emerging from the PRs they posted with variants of "I've worked here for over a decade, this is how we do things". And then proceeds to argue things like defensive programming is a code smell because it means developers don't trust themselves.
I cannot envision any healthy, effective engineering environment where developers don't periodically switch between projects.