back

by padolsey·1y ago·view on hn ↗
Perhaps the meaningful axis is not around seniority, per se, but instead around experimentation as OP alludes to.

By virtue of being a junior, as you're just picking things up, you have to be flexible, malleable and open to new things. Anything that seems to work is amazing. Then you start to form the "it works" vs. "it's built well" intuition. Then your skills and opinions start to calcify. Your beliefs become firmer, prescriptive, pedantic, maybe petty. Good code becomes a fixed definition in your head. And yes, you can be very productive within your niche, but there's a quick fall-off outside of it. But then, as you grow even more, you realize the beliefs you held dear are actually fluid. You start to foster an experimental side, trying things, dabbling, hacking, building little proofs-of-concept and many half-finished seedlings of ideas. This, which the OP identifies as 'Staff level', is for me just a kind of blossoming of the programming and hacking mindset.

With LLMs, you have to be open to learning their language, their biases. You have to be able to figure out how to get the best out of them, as they will almost never slot easily into how you currently work. You have to grow strong intuitions about context, linguistics, even a kind of theory-of-mind. The latest "Wait" paper from stanford shows us how such tiny inflections or insertions can lead to drastically superior results. These little learnings are borne of experimentation. Trying new tools and workflows, is as well, utterly vital, but per every emacs/vim or tabs/spaces debate, we see that people don't do well to branch outside of their workflows. They have their chosen way, and don't want to give others the time of day.

2 comments
It might be referring to job role rather than "age." A Staff Engineer is supposed to be inspiring (both up and down,) so doing quick tests fits the bill, and that's something LLMs are great at supporting. Mid-level is mostly about delivering reliably.

The question is if LLMs/tools could drag mid-level earlier into senior level, or if it's a phase one has to go through. Ultimately, the tangible promise of LLMs is to push the entire timeline up, so that junior tasks are automated and you go in and control the LLMs. Expectations on what it means to be a software engineer are sure to change, at some point. (I like the software craft as-is, but fact is most of our lumber is straighter now that we have automatic saws. And I've never heard a carpenter pleading to split a log manually.)

> I've never heard a carpenter pleading to split a log manually

Log splitting is a lumber mills job which has been around for nearly 2000 years. Maybe a better analogy is a nail gun? Which is actually insteresting because some of the old timers I met are actually as fast or faster with a hammer and nail as a nail gun. And hammers are still used everywhere daily by woodworkers and carpenters.

But the challenges of a carpenter are more about problem solving than brute force. How you join and the order you join can make your life a pita if you don’t have the experience. So a junior carpenter might be implementing repetive tasks or follow directions but you need experience to know how to implement a unique solution correctly on the first try and not waste hundreds of dollars of material or the clients time. Afterall “measure twice cut once” has to be learned.

Thanks. I had not seen the wait paper yet. That is crazy.

s1: Simple test-time scaling https://arxiv.org/pdf/2501.19393