Slashdot Mirror
Why Do So Many Tech Workers Dislike Their Jobs?
Nerval's Lobster writes: So what if you work for a tech company that offers free lunch, in-house gym, and dry cleaning? A new survey suggests that a majority of software engineers, developers, and sysadmins are miserable. Granted, the survey in question only involved 5,000 respondents, so it shouldn't be viewed as comprehensive (it was also conducted by a company that deals in employee engagement), but it's nonetheless insightful into the reasons why a lot of tech pros apparently dislike their jobs. Apparently perks don't matter quite so much if your employees have no sense of mission, don't have a clear sense of how they can get promoted, and don't interact with their co-workers very well. While that should be glaringly obvious, a lot of companies are still fixated on the idea that minor perks will apparently translate into huge morale boosts; but free smoothies in the cafeteria only goes so far.
I can't speak for anyone else, but most "tech jobs" I've held were with companies whose futures and business I had no stake in, nor interest in having stake in, and the work to be routinely uninteresting where creativity was actively discouraged (for good reasons, many times), individuality was suppressed, and I was treated as a replaceable cog (and I was). I'm fortunate in that I have many other outlets for my creative needs, but dealing with corporate bureaucracy, idiot bosses, etc does take its toll. The paychecks are nice and allow me to have a comfortable life outside of work, but I will say that after 2 decades, I'm ready to throw in the towel and do something else, even if it means downsizing again.
If you were me, you'd be good lookin'. - six string samurai
Autonomy, Mastery, Purpose: you'll be happy with your job to the extent it has these qualities. How much autonomy do most engineering jobs give you? Not much I imagine. How much mastery? Well you're certainly not going to be exploring many new skills, or even masterting particularly difficult ones on average; it's mostly repetitive scaffolding with glue.
Purpose is pretty much the only one that technology work has plenty of. Everything runs on information technology now, so if you're interested in tech, which you probably are, you'll find lots of purpose in developing or administering information systems. This only goes so far before the lack of autonomy gets to you, or you hit the mastery ceiling pretty quickly at any given job.
Higher Logics: where programming meets science.
Basically tech jobs are closer to blue collar than white collar
A peer and I once made the same comparison. We called ourselves digital maintenance men, because by and large that's what it is.
I've never worked for a company that had a significant manufacturing component, but I kind of wonder how the blue/white collar split works there for the people who setup, maintain and manage seriously complicated factory systems. I think they might have been called millwrights at one time.
Are they treated like blue collar people (probably, if the job involves any serious mechanical tools), or because of the sophistication of the equipment (all computer driven and complicated) are they treated like dirt, like other blue collar jobs, with all the usual management/labor hostility, clock punching, etc.
And why do "office" jobs seem to escape a lot of that labor/management hostility? Even the lowly marketing associate seems to get treated better than the most skilled blue collar worker. I've known some electricians who were really intelligent and used to sort out cabling issues in my data center better than I could, even though he didn't know how to configure the equipment. He'd make suggestions via some kind of intuition that never dawned on me.
Agile...without actually establishing any direction.
That's the point of Agile! If you can't do it in one sprint then you cannot do it. We've promised a lot of features to customers that development could not work on because they can't be completed in two weeks. Agile has made my life much easier. You only plan and work on one small, well-defined task at a time. In the six years since our board voted to require Agile and hired a certified scrum master, the work we've done has all been very well-defined and we have met every single sprint deadline for every single developer. We have completed 120 sprints with around twenty developers on average. That means we succeeded 2,400 successful dev-sprint units, and with an average of 2.5 user stories completed per sprint per dev, we're at over 6,000 completed user stories all delivered on time! It makes the developers and management look awesome. The only downside of Agile is that we've lost our three largest customers because we can't deliver, and it looks like we're going to have to layoff most of the team before the end of the year.
This. Lots of tech workers spend 60 hours at work, get paid for 40 of them, and do useful work for 30 of them, mainly because of mental fatigue.
An ideal tech company would split the company in half—a M–W shift and a W–F shift. Employees would work 24–27 hours per week, and Wednesdays would be spent on meetings and other soul-sucking tasks that require everybody to be present at the same time. It would then pay 60% of the salary for 60% of the work. Workers would be happier because they would have more free time, and the company would be happier because actual work per dollar spent would increase by up to 33%.
> The only downside of Agile is that we've lost our three largest customers...
My last startup was Agiled out of existence like it sounds like yours is headed to. We had a sixty person team between devs, product, project management, and QA. To story point every task, it usually took us longer to explain and estimate about 1/4 of the tasks as it took to do them. That meant instead of spending one man-hour to do a task, we spent sixty-man hours. For example, most of the web-related web tasks, like changing a stylesheet or wording, took about twenty minutes to do and test while they took at least five minutes to explain in sprint planning. That means a simple task takes about 5.5 total man hours instead of 0.5. At $100 per hour per employee (including benefits and other costs and since we're in the Bay area), that meant, for example, changing the size of text on a web page cost us $5,500. Agile is a great way to waste time and money.
I work for a "mom and pop" shop, as you call it, and I can sympathize with what you're saying. But it goes both ways. We built an application for a company that I am sure you heard of. Let's call it "Acme Inc." One of the application's requirements was that it support SAML authentication. That's fine, we could handle that. All we asked for was some particulars about Acme Inc's environment.
Could we have a sample SAML token, to see what kind of assertions Acme would be requiring? Could we have the SAML version, 1 or 2, that Acme uses? The responsibility for providing us with any of this was "delegated" to people who already have too much on their plate, don't really know what is going on themselves, and who lack the mojo to get a quick response from the various systems administrators at Acme who could help. A couple of weeks later, the stakeholders at Acme are crying, "Come on, come on, come on! We want the product!" Of course, none of these preliminaries have been attended to.
Then, when the product is finally delivered, the guy at Acme charged with putting the product through its paces has no idea how SAML works, and is asking me to walk him through it. (Remember, this was their idea.) We come to find out that he has no test server to use as an "Identity Provider" (don't ask!), and he wants to know if can I help him there.
Granted, this is all ultimately a managerial screw-up. But, my point is that even if a mom-and-pop does code up an LDAP, who's to say the customer has it together on its end?
quiquid id est, timeo puellas et oscula dantes.