I would not give this advice to junior engineers at medium to large tech companies. I’d consider it dangerous advice [1]. Caveat: I’ve never been a hiring manager, but I have been a team lead that’s onboarded and coached junior engineers, before and after AI.
Identifying a high impact idea and rapidly prototyping, particularly with 0 company context, is often hard. But even then, getting from prototype to product is very hard. There are often very good reasons why things are the way they are, and these are hard to identify as a new and junior engineers. Generally, this is the kind of thing bigger companies want from newly hired staff+ engineers, not juniors. For better or for worse, people are going to treat something innovative from a junior engineer with far more skepticism. Not to mention, there can very often be politics involved. My experience is that the most palatable good ideas are those most grounded in data, like saving money on infrastructure spend.
My advice to junior engineers is basically the same as it always has been: work enthusiastically, volunteer for as much as you can, watch what senior people are doing and why, ask questions, be useful to your manager and your teammates, focus on smaller, team-local (but still useful!) innovations.
There’s a lot that AI makes possible to do, and to do rapidly, but it adds many traps around not understanding the big picture, missing requirements, being too narrowly focused, or not grounding claims, all of which make it challenging to know that you’re working on the right thing as a junior engineer. That’s not to say one shouldn’t, but I’d be very careful and not get sucked into spending too much time on these kinds of things.
This is basically a dunk piece. Scott’s and gwern’s posts are often long because they contain arguments, which ironically the author does not use, other to point to one gwern post. He says that rationalists substitute thoroughness for verbosity when gwern’s post does the exact opposite!
It’s easy to dismiss the argument with “lol nicotine bad”, but I think it’s good to examine studies on the addictiveness of nicotine when not smoked, and not assume it would be just like smoking. There are plenty of things that seem obvious but are not and it’s always good to be rigorous.
I think Scott in particular just really enjoys writing. He is very articulate and obviously just brimming with clever connections and turns of phrase. And he can generate a lot of words very easily.
When I was younger, sometimes I would just get carried away by the splendor and awe of it all and soak in the 25,000 word articles (or whatever they are.)
Today I would say that either he has fallen off a little, or I've just grown a little weary of the form, but I don't really get the same rush out of his writing anymore; and I notice more of the motivated reasoning and cheap tricks.
Still, sometimes I'll come across one of his posts and think 'damn, Scott's still got it.'
What the author here misses is that the verbosity is often a signal of work done.
It's like the "alternatives considered" section in a design doc or RFC: it shows you've thought through different approaches, considered trade-offs, etc. It's a little like showing your work combined with taking the reader on a journey.
Also literally the post he links to for "its bad actually" is a blog about how it's great and not very addictive and just has some tweets from people who apparently didn't pay attention to the nicotine gum/patch/pouch recommendation in gwern's post and instead started using various forms of tobacco. Very sloppy all around.
Identifying a high impact idea and rapidly prototyping, particularly with 0 company context, is often hard. But even then, getting from prototype to product is very hard. There are often very good reasons why things are the way they are, and these are hard to identify as a new and junior engineers. Generally, this is the kind of thing bigger companies want from newly hired staff+ engineers, not juniors. For better or for worse, people are going to treat something innovative from a junior engineer with far more skepticism. Not to mention, there can very often be politics involved. My experience is that the most palatable good ideas are those most grounded in data, like saving money on infrastructure spend.
My advice to junior engineers is basically the same as it always has been: work enthusiastically, volunteer for as much as you can, watch what senior people are doing and why, ask questions, be useful to your manager and your teammates, focus on smaller, team-local (but still useful!) innovations.
There’s a lot that AI makes possible to do, and to do rapidly, but it adds many traps around not understanding the big picture, missing requirements, being too narrowly focused, or not grounding claims, all of which make it challenging to know that you’re working on the right thing as a junior engineer. That’s not to say one shouldn’t, but I’d be very careful and not get sucked into spending too much time on these kinds of things.
[1] https://www.seangoedecke.com/dangerous-advice/