[madlynormal]

There is a significant difference within different roles in I.T. As someone who's worked in the cost center side of the industry, I can relate with the author. It's a problem not limited to Oakland or San Jose. Helpdesk, Desktop Support, and related jobs are commonly temp to perm with horrible pay for the amount of stress.

[ChuckMcM]

Exactly, the role of the 'IT person' as the system administrator and keeper of updates on things like the Novell server, has given way to Google Apps and Microsoft's Office 365. Small businesses who could barely afford to pay someone before can now eliminate that role and still have email, shared files, back end inventory management and accounts management, and the occasional web developer contract to keep the web site up to date.

Personal services IT is still alive and well and a number of people I know have made a living out of helping older people manage passwords, upgrade their systems, move their phone plans or transfer their data when they get a new phone etc. But to be successful at that you also need to talk to people and be able to maintain a business relationship with them, not a skill that everyone has in addition to their deep knowledge of IT.

As tm2d mentions devops is still a hot job market. But it is not the small business 'tech' role so there are fewer actual slots for that role.

There was also a comment in the article about H1-B visas and employers wanting "younger and less expensive" workers. I try to remind my older friends that if someone can spend 6 months learning to do what you do and do it well enough to meet the needs of the job, then you are only "worth" what a company would pay that person they just hired. If you want to have a larger salary and better job security, then you need to be able to do things that can't be trained in 6 months. The days of 'too few programmers to go around' are long past, there is now a surplus and they are coming fast and furious out of college.

[chrisweekly]

> "The days of 'too few programmers to go around' are long past, there is now a surplus..."

Some of your other points were insightful, but this assertion contradicts my experience and intuition, and -- I believe -- labor market statistics.

[ChuckMcM]

The last time I listed a $120K job opening I had hundreds of resumes thrown at me, over 10[1] of them were completely qualified and So perhaps it would be more accurate to say "$80K/yr programmers are scarce."

In 1999 when I was hiring programmers and offering above market starting salaries I wouldn't get any qualified resumes.

It is from that experience that would assert it is a 'pricing' issue rather than a 'selection' issue.

[1] After 10 qualified I had my first interview round, 3 were brought back for secondary interviews and one hired. I expect there were easily 20 - 30 engineers in there that could have done the job.

[ori_b]

The last time I put my resume out ( about 3 months ago), my big problem was who to interview with, since I was flooded with requests.

It seems that there might be plenty of churn overall.

[gozur88]

Mine too. We're having real problems filling contract positions. People are juggling multiple offers, and if we don't jump on a candidate right away they take another offer and we have to restart the process.

We've gone through surplus years before, and they don't look like this.

[jorblumesea]

I think there's a misconception about performance some perception issues about the ability to do the job. In 6 months of training you might get someone who can sort of do the job, but probably not very well and not at the level of a "real" professional. A good example of this is code camps. They churn out a ton of programmers but very few people that are actual engineers or can carry out actual projects.

But to management/high ups, they "can do the job" and are cheaper. It's like outsourcing. You save in costs but there are hidden downsides and risks.

I'd probably argue that very few engineer jobs can be done competently with a few months of training.

[user5994461]

> They churn out a ton of programmers but very few people that are actual engineers or can carry out actual projects.

Coding is a cheap easy skill that 15-20 years old can do.

Executing and managing a project from start to finish is a rare skill that cannot be acquired in school or the internet.

Coding Monkey => Cheap and easy to find.

Coder who has successfully led and executed projects => Expensive and rare.

[toomuchtodo]

For sure. As a sysadmin/network admin/IT manager, it's a buyers market. As a DevOps/infrastructure engineer, it's a seller's market.

I think training is part of the problem. More importantly, workers need consulting help around how to take existing skills and use them to apply to upmarket jobs with higher pay.

[woah]

DevOps/infrastructure engineer is basically a programming position, which sysadmin/IT types may not have strong skills in.

[cat199]

So what were sysadmins before the term DevOps was invented ~5y ago?

Unless you are arguing that people never did large scale automation of processes around deploying systems and software until this term existed...

In my personal vocabulary - there were always 2 kinds of sysadmins:

- Real sysadmins- which is now the term 'DevOps'

- IT System Technicians - which is what sysadmin is being perverted into

The old-style breakdown typically depended on how systems/development minded the company was - with more forward looking companies seeing their sysadmins as the former category and people who "administered" e.g. 'tended to' the IT "system", and the reactive companies who viewed IT as some foreign expense to be managed viewing their sysadmins as advanced IT techs who were 'admins' (in the administrative assistant sense) for the various 'systems' (e.g. computers) that they purchased.

As someone who always operated in the mindset of the former category, but unfortunately has operated mostly in the latter type of company, it is difficult to make the transition into 'DevOps' roles since this term has been subsequently invented to describe the work that I always did, using tools that I would have written from scratch myself in the old days, or deployed myself in the current days, but unfortunately due to crappy management and backwards modes of thinking, don't have the proper 'current' job-title on my resume (e.g. sysadmin)

[Spooky23]

Its easy to spot the difference.

If you talk to someone about their day and it revolves around tickets, they are the techs that you're talking about. The real "sysadmins"/devops understand systems and own things.

It's ok to realign your title with function. Every company handles this sort of thing differently. I was a "Computer Systems Programmer 3" for two years. In that organization, that rank was roughly equivalent to a Staff Engineer. My resume says "Lead DBA", as that was my primary function... the formal title assigned was just whatever was available when I was promoted... the title description was written for mainframe people!

[sulam]

No one is going to check that your title matched at most companies I've worked. Yes if you list yourself as VP of Finance and you were actually an Accounts Payable administrator, you will have some trouble. But that trouble will start far before the background check. If you're in a DevOps role that happens to be called System Administrator, simply change what you call yourself. You will still have to interview as a DevOps person of course -- titles are not reality -- but you'll get far more inbound interest, guaranteed. And according to what you've written here, you won't be lying or even misleading the people who want to talk to you.

[toomuchtodo]

I wouldn't call Ansible and Terraform programming languages. In two and a half years at a well known startup, I've written less than 1000 lines of code in a senior DevOps/Infra role.

DevOps/infrastructure is knowing how to glue together off the shelf tools and understanding how everything works. Great that as a dev you can probably bolt these tools together with docs, but your lack of context with the underlying fundamentals will eventually bite you.

[jacquesm]

> DevOps/infrastructure is knowing how to glue together off the shelf tools and understanding how everything works.

That's actually not that much removed from quite a few programming jobs. It's mostly different manuals and the occasional plug to fit into a socket but other than that the differences are smaller than the similarities and debugging skills are important for both of them.

[toomuchtodo]

Agreed.

[Rapzid]

Some of the more junior/limited roles amount to that. Higher-end roles involve a much, much broader skillet including development.

[toomuchtodo]

Higher end roles are architecture. If it's development, you're a developer.

[ex_amazon_sde]

Google and Amazon have plenty of SRE / System engineers and roles with "developer" in it. All of them write code.

And, thankfully, no architects.

[user5994461]

> workers need consulting help around how to take existing skills and use them to apply to upmarket jobs with higher pay.

> DevOps/infrastructure engineer is basically a programming position

sysadmin/network admin ==>> DevOps

IT manager => Manager or lead.

DevOps is not a programming position at all. It is usually cheap system administration (that replace the term sysadmin) and it does NOT require coding. Pay attention to the name and the place you joins, you're can easily be burnt by joining a team of operations monkeys while thinking they were the dev and system type persons.

[johansch]

Unpopular opinion:

Nah, it's an IQ issue. It's really not a (short-term) training issue, at least.

[bante]

It's weird that people who claim unpopular opinions, often at the expense of others, so rarely can find the time to argue their excellent ideas. I have a number of friends that works in "IT" in Europe. The difference between working for a US and European "IT" company is night and day. It simply has very little status as a field in the US. If you had ever seen the things a systems administrators have to deal with from highly educated engineers, you would know that it has less to do with "IQ" and everything to do with domain knowledge.

[planteen]

I've had the pleasure of working with some great a Linux sysadmins. I had a great relationship with them as a developer. Another developer hated them and treated them poorly. Do you think they would help him out after hours if they weren't on call? Same thing for EEs who treat technicians poorly. A tech might tell them a rework is impossible. If they like you and you buy them a beer from time to time, they might say, "That's going to be really tough, but I'll give it a shot and we'll see what happens."

I think a great piece of advice for life is, "Never assume you are the smartest person in the room." Remember that everyone brings something to the table.

[psyc]

Not that I agree with the specific opinion in question, but when it comes to cause-effect questions with a moral angle, you're going to convince literally nobody by arguing. I never take the time, because it doesn't bother me in the slightest whether others agree with me, or are wrong.

[johansch]

I agree. The sysadmin people I have worked with in Europe in have generally been very clever people that I loved to have on my team. The IT/sysadmin people I experienced in Silicon Valley in my next company though.. meh.

[neom]

For that to be true I suspect you'd also have to believe near zero nuance in the bell.

[johansch]

Now I'm really curious. What bell are you talking about and why is it relevant?

[danans]

This was true even 14 years ago, especially after the dot-com bust when many former developers took jobs as help desk techs when the job market fell apart. I was one of them.

I eventually figured out there were very limited opportunities for someone with my skills and interests in that role so I studied and worked to build the skills to get a software engineering job.

I think that Helpdesk roles in general should be seen as stepping stones toward careers in more advanced roles. I actually think my experience doing that work has made me a better engineer and coworker.

[snuxoll]

Helpdesk was my stepping stone as a degree less high school dropout getting into a software development role. They can certainly serve a purpose, but I wouldn't stay there longer than I had too given a choice.