>Is like an athlete winning a medal and saying that those years of training were useless. That time is where you learn, grow, and get prepared for the next jump. If that's not the case, you are setting yourself up for failure.
I don't think this comparison works at all. An athlete is attuning both their body and mind for years for an increase in the exact same activity. An employee is largely waiting for their time to shine hitting a challenging breakpoint, and practicing repetition of that challenge will have diminishing returns kick in very, very quickly. At the same time, the payoff for going beyond that diminishing returns is highly arguable.
As an example, in most companies, the far majority of employees will spend months doing ridiculously similar, low scope issues. These low scope issues frequently have very, very little to do with what is expected in the next tier. Changing a few variables every day has much less in common with making a basic tool after analyzing requirements. Comparatively, a runner practicing for years is directly practicing to run faster, it's the same toolset more carefully honed.
The far majority of us are waiting for those challenges to come up while doing those low scope, low pay-off issues. The common advice is to "seek those challenges yourself" or to "do the low stuff faster so you can get more challenging things quicker" is cute, but doesn't nearly apply in practice as often as the frequency of this advice makes one think. Think of bureaucracy, managers getting in the way, petty office politics, bottlenecks, and more. Which only leaves practicing in one's own time.
From the way I read it, OP is saying that there's far more of a difference between what one learns during those small challenging periods of time than the downtime of repetition compared to other fields. Which shouldn't be a surprise as software dev is largely a field of practicing mental challenges and logic puzzles, not honing physical skills.
For me, I always incorporated something interesting and new into the small projects.
While maybe not necessary to use Pandas or an ARG parse framework, or even Redis caching, I found by adding little things like these to smaller projects I was able to maintain interest and motivation. While counterintuitive, I also usually delivered a better product even though a tool I wanted to learn was a bit shoehorned in.
Now I'm about four years in, competent and confident. 100% worth it.
I don't think this comparison works at all. An athlete is attuning both their body and mind for years for an increase in the exact same activity. An employee is largely waiting for their time to shine hitting a challenging breakpoint, and practicing repetition of that challenge will have diminishing returns kick in very, very quickly. At the same time, the payoff for going beyond that diminishing returns is highly arguable.
As an example, in most companies, the far majority of employees will spend months doing ridiculously similar, low scope issues. These low scope issues frequently have very, very little to do with what is expected in the next tier. Changing a few variables every day has much less in common with making a basic tool after analyzing requirements. Comparatively, a runner practicing for years is directly practicing to run faster, it's the same toolset more carefully honed.
The far majority of us are waiting for those challenges to come up while doing those low scope, low pay-off issues. The common advice is to "seek those challenges yourself" or to "do the low stuff faster so you can get more challenging things quicker" is cute, but doesn't nearly apply in practice as often as the frequency of this advice makes one think. Think of bureaucracy, managers getting in the way, petty office politics, bottlenecks, and more. Which only leaves practicing in one's own time.
From the way I read it, OP is saying that there's far more of a difference between what one learns during those small challenging periods of time than the downtime of repetition compared to other fields. Which shouldn't be a surprise as software dev is largely a field of practicing mental challenges and logic puzzles, not honing physical skills.