3 ms·

The thing I hate the most about the tech industry is that there is very little correlation between skill and reward and because everyone who has an economic voi

The thing I hate the most about the tech industry is that there is very little correlation between skill and reward and because everyone who has an economic voice believes that there is a correlation, we get led down all sorts of crazy fickle paths littered with anti-patterns and overengineered tools... And the narrative keeps changing randomly depending on which nerds happen to stumble upon a successful business case at which point they are given the platform to impose their technology ideas on everyone else... Nevermind that they had 100x the budget of an average company and solved all their tech problems via brute force and dirty hacks. IMO, there was a time maybe 15 to 20 years ago when the software industry knew what it was doing and there was a concerted effort to produce optimal, maintainable code but it seems that most companies just gave up and software became cheap, fragile and disposable.

groestl 3y ago
This list, as presented in the blog post, is a great list though. Succinct and to the point. And in fact, just how I went to become a hopefully decent enough SE.
rco8786 3y ago
There was never a time when the industry “knew what it was doing”. Everything you described was exactly the same 20 years ago. Nor is any of it specific to the software industry. It’s just normal experimentation and churn, driven by capitalism chasing profit at the macro and individualistic drive for more influence at the micro. Same as it ever was.
seanhunter 3y ago
This is not just a problem with the tech industry. In society in general there is only a weak correlation between skill and reward in lots of places and the variance in outcomes is very high and is dominated by factors like the socioeconomic background of your parents, race, gender etc that you don’t control. However since you don’t control those factors you are better off improving your skill, which you do control. Maybe later you will be put in a position of importance where you can make optimal decisions that end up widening the funnel and reduce the importance of those things by hiring and promoting the best people for the job and caring about good dev practise. I’m not buying your idea that 10/15 years ago the industry knew what it was doing and cared about quality though. I’ve been a professional software engineer for 25 years now and software quality as a whole has always been dire. There definitely is a minority of folks who care about it as there always has been so gravitate towards them.
sebastianconcpt 3y ago
I feel you about this issue of skill/reward ratio. And I've kept meditating a bit for some reason. What came to mind now is that, for making it "work better"(improve that ratio) the software engineer could try to see himself as a bulldozer operator where he is the skilled one, of course, but the software he makes is the bulldozer. The reward is neither on them but in the outcome produced by the combination of them. How much material he could remove or push from here to there. That's why the STAR method is necessary in resumes or in interviews for example. We're so passionate about software that we could be easily become myopic about results and forget to talk about what's the outcome of the things we produce and use.
swader999 3y ago
15 to 20 years ago a lot of systems didn't have to be distributed, multiprocess, run in the cloud and deal with as much data. Of course there were some then, but the trend has moved this way. Also, the leet coders have taken over, back then they weren't as influential.
- drewcoo 3y ago
  15-20 years ago, you'd run a tightly-coupled monolith in a colo and do scheduled downtime every few weeks to deploy everything. Everything was more error-prone and fixing errors could mean a physical trip to the colo or downtime in the middle of customers' workdays. We probably have the same amount of seat-of-pants, spit-and-bailing-wire problem-solving happening today, but the problems have moved.

groestl 3y ago

This list, as presented in the blog post, is a great list though. Succinct and to the point. And in fact, just how I went to become a hopefully decent enough SE.

rco8786 3y ago

There was never a time when the industry “knew what it was doing”. Everything you described was exactly the same 20 years ago. Nor is any of it specific to the software industry. It’s just normal experimentation and churn, driven by capitalism chasing profit at the macro and individualistic drive for more influence at the micro. Same as it ever was.

seanhunter 3y ago

This is not just a problem with the tech industry. In society in general there is only a weak correlation between skill and reward in lots of places and the variance in outcomes is very high and is dominated by factors like the socioeconomic background of your parents, race, gender etc that you don’t control. However since you don’t control those factors you are better off improving your skill, which you do control. Maybe later you will be put in a position of importance where you can make optimal decisions that end up widening the funnel and reduce the importance of those things by hiring and promoting the best people for the job and caring about good dev practise. I’m not buying your idea that 10/15 years ago the industry knew what it was doing and cared about quality though. I’ve been a professional software engineer for 25 years now and software quality as a whole has always been dire. There definitely is a minority of folks who care about it as there always has been so gravitate towards them.

sebastianconcpt 3y ago

I feel you about this issue of skill/reward ratio. And I've kept meditating a bit for some reason. What came to mind now is that, for making it "work better"(improve that ratio) the software engineer could try to see himself as a bulldozer operator where he is the skilled one, of course, but the software he makes is the bulldozer. The reward is neither on them but in the outcome produced by the combination of them. How much material he could remove or push from here to there. That's why the STAR method is necessary in resumes or in interviews for example. We're so passionate about software that we could be easily become myopic about results and forget to talk about what's the outcome of the things we produce and use.

swader999 3y ago

15 to 20 years ago a lot of systems didn't have to be distributed, multiprocess, run in the cloud and deal with as much data. Of course there were some then, but the trend has moved this way. Also, the leet coders have taken over, back then they weren't as influential.

drewcoo 3y ago
15-20 years ago, you'd run a tightly-coupled monolith in a colo and do scheduled downtime every few weeks to deploy everything. Everything was more error-prone and fixing errors could mean a physical trip to the colo or downtime in the middle of customers' workdays. We probably have the same amount of seat-of-pants, spit-and-bailing-wire problem-solving happening today, but the problems have moved.