In tech, young people can complain.
Us, the older folks, are not allowed to complain, lest we get branded as old fashioned, unable to adapt, etc.
HN user
In tech, young people can complain.
Us, the older folks, are not allowed to complain, lest we get branded as old fashioned, unable to adapt, etc.
True
EDIT: Speaking as a European.
It's not that '... developers ... are lazy, and prefer to write as few lines of code as possible, sticking rigidly to the principle of "not reinventing the wheel"'.
They don't do that because they are lazy. They do that because of competitive pressure. In SW development, in most cases, particularly in enterprise development, "the fastest person wins". Whoever moves fast and delivers fast will get to do more projects and have more influence over direction of projects. "Not reinventing the wheel" is of course in vast majority of cases faster than reinventing it.
Because in most cases it's not important to write the best possible code, it's to write "good enough" code, on time and on budget. Insecure code is of course not "good enough", so competitive pressures will adjust accordingly.
I regret to inform you that this is a normal situation. In economy, you have to do what's useful for other people and not neccessarily what's fun.
Of course there are jobs at the intersection of those sets, but also there is much competition for them. It's harder to find them and you might have to accept lower pay for them.
You also mention "corporate world": larger teams impose their tax on participants. "The Mythical Man-Month" book (by Frederick Brooks) says that for a team of size n you have n(n−1)/2 possible communication paths between participants, which means that the communication and coordination overhead rises much faster than the team size. This accounts for half of your time being taken by "process".
So small companies migth be more interesting, but also riskier (because small companies are tipically start-ups which haven't yet confirmed the validity of their business model). Of course there are exceptions, but on average this also means you get paid less.
One case study for fun job is id Software at the beginning - the guys who developed Doom, the first significant 1st person shooter game. In early 1990ties it was the most installed software on computers by one Microsoft study (googling for details left as an exercise for the reader). The game was technological breaktrough, something new, it had massive impact and was financially successful. And you bet they had a lot of fun doing it.
Edit: corrected the group intercommunication formula
The bloat is simply a side effect of the evolution. Software is not as much designed as evolved.
You make a name for yourself in SW development by adding features that others deem useful. You get money (in commercial setting) or prestige (in freely distributed software) if you seem to be producing something useful. It's trivially easy to recognize a contribution that adds code, but it's hard to recognize a contribution that means absence of something (e.g. absence of bloat, absence of memory hogging, ...). You get inclusion in newer, larger or more important projects easier the more you make yourself recognized.
So any useful software gains more contributors that add things than those who remove things. Commercial code can and does gain developers if it earns money, open source software gains developers if it is deemed useful by programmers.
This is a force that shapes both the group of involved developers and the resulting software in a process akin to evolution. In both cases the selection is biased towards adders of code. There's also always possible to add improvements that help some use cases and audiences. On the other hand, arguing for removing something or limiting might make you unpopular (you are seen as an obstacle to everlasting progress) and removed from the group of developers. Rare people have enough recognition and clout to prevent inclusion of something (Linus Torvalds is one of them - he can get away with rejecting patches to Linux kernel and he can play the role of the kernel guardian).
On the whole, software expands until it fills the resources available.