I don't envy young people who get into the business now. A lot of them will probably never get the chance to work on something uninterrupted for a long time. Instead they are being micromanaged daily, have to justify every little thing they do and don't get much opportunity to make mistakes and learn from them.
I guess most industries get boring once they mature. Working on cars between 1900 and 1950 was probably much more fun than working on modern cars in a modern car dealership.
I agree about unions. The older I get the more they make sense to me. The tech industry is living off exploiting young people's enthusiasm with the promise of a big payoff that materializes only for a few.
Can't agree more with this. When I rail against the tech industry, it isn't as a Luddite, but as someone rallying against exploitation and subjugation.
Which was precisely what the Luddites were doing too. They weren't anti-tech. They were anti-exploitation. In these days, such exploitation often involved use of weaving machines, so the latter got destroyed in the process, but it was never about technology itself.
Also a shelf life, just how much abuse your body can take.
The cost of maintenance and construction must be going to skyrocket in the next ten years.
So, what, you've literally never met anyone over the age of 40? 50? 60? in IT? I'll bet if you think about it for a moment you probably have. But if you haven't you need to look no farther than Pike and Thompson working at Google for two examples of older people working on interesting problems at a top tier company.
Regardleas I don't share in the cynicism and burn out that some have shared in this thread.
Even if I see some ideas recycled from 20-30 years ago I'd argue the implementations are novel. Frankly the fact that IT keeps changing is what makes it fun for me.
Well, there are 60 year old exotic dancers too.
I don't think most of us can follow the example of some superstars.
That could be an illusion caused by the fact that the number of programmers in the world have been observed to double every five years. It may be that all the older programmers actually do stay programmers, but there are always more and more new young programmers around, which makes old programmers seem like anomalies.
Another anecdotal point; we are rolling a new app; the lead tech is 64 y/o and uses React Native and Node (different company than the above so different tech choices; not my choice). He does the app and the API almost all by himself (I do code reviews on them). He gets paid well, works from home and is fast.
I guess what I’m saying is: Maybe it’s time to revisit the blackboard. Rethink how a neural net or intelligent model should be implemented. Retry and rethink the “set in stone” basics. Also, throw out the entire discipline and try to come up with novel, new approaches.
OTOH, certainly worth the watch even if just from this point to the end, easy listen at 1.5x speed.
But as soon as there were new fresh CS degree graduates, companies preferred to hire those since they were cheaper. This produced two effects: 1. The CS graduates were, for some reason or other, mostly young men, so the gender balance tanked. 2. The new CS graduates, fresh out of school, were neither disciplined nor mature, and so required a lot of micro-managing. Both these effects were made more or less permanent by the steady growth which you summarized, and the second of these two effects is the change which user MrTonyD lamented above.
No need to double-negate this word.
This is not directly in response to your comment, but I see three types of people.
Some people don’t know better or care to know better or weren’t paying attention or don’t mind because they know what I meant.
Some people care enough about language to debate usage.
Some people just want you to follow “The One True Way”, which is coincidentally whatever they think.
You do the 24 hour call outs with 15 min response times for key business processes a live monthly billing run for example.
But that's not always true, especially at smaller dev shops. However, smaller shops sometimes like to imitate the big corporations, it makes them feel more important, even though it's not necessary.
In both cases having broken builds in your production pipeline are an indication of a process or policy problem more than anything else, especially in 2018 when build hardware is cheap and CI platforms are everywhere.
(P.S. I've worked in both types of orgs. Ones where the builds had several teams of people working on them, where broken builds could mean huge amounts of lost or blocked work hour by hour and fixing builds was a very high priority task, and where there were huge systems and extensive policies designed to forestall build breaks getting checked into important branches. All of those systems and policies were built out of a history of chaos, where builds were almost always broken (if you have thousands of devs, and none of them take build breaks seriously, then there will almost always be one break checked in every day), schedules were unreliable, etc. So much so that it was burning people out. On the other hand I've also worked in places where a build break can be handled by filing a bug and letting it go through the normal process of triage and fix over a period of many days. Which process is appropriate is entirely dependent on context.)
They still are unreliable. the only difference I see is that I spend a lot of time on reporting status instead of doing actual work.
This way master can be always green, because build errors will crop up in branches - only once the tests pass and review is complete, the bot can push to master. Because builds are generally done from master, this prevents landing broken code that could break others' development flow.
The end result is that all build failures have been addressed in the development branches. Bot will refuse to merge code that fails tests - and the workflow itself will guide towards a desirable process.
Humans need to be involved in the code review step. Even if everything is green and covered it still can be wrong or unmaintainable.