[nmehner]

> Besides that: find small (2-3 day) project ideas that require you to learn max. 1 new technology or idea, and build lots of such projects.

That's how you learn programming. It's not a bad idea, but at least for me software development is more about long term issues coming up, team communication, features that create short term value but long term problems. How to organize big piles of code.

A lot of abstractions don't make any sense in a 2-3 days project and you are better of hacking away a script than looking into "properly" modelling things.

My impression is always that as a junior you learn how to do stuff. Then you learn to do complicated stuff. And becoming a senior you learn how not to do complicated stuff.

This takes some of the fun out of it as well. Deploying a feature that is simple and that just works without any issues does not create nearly as much excitement as "saving the company" with a big hack and high risk deployments, although it is much better to not have to "save the company" in the first place.

[aleph_minus_one]

> Deploying a feature that is simple and that just works without any issues does not create nearly as much excitement as "saving the company" with a big hack and high risk deployments, although it is much better to not have to "save the company" in the first place.

Some people are more risk-affine, and some are more risk-averse.

The fact that such things work rather kindles a desire to do new interesting, experimental stuff in risk-affine people - something that a corporate environment often prohibits, which frustrates risk-affine people.