You know, as a former academic, I was reading this list and I immediately knew: This is written by someone in academia (and sure enough, you find out at the bottom it is).
I don't have a problem with this list per se. For all I know, it may be a good list and the designation of Type 1 and Type 2 engineers may be accurate.
But I wish I read a post from a Type 1 engineer in industry that mirrored what academics often write. I hardly find one. Why the disconnect? If the academics are so right, why is it mostly academics who preach this? There are more Type 1 engineers than academics, I'm sure.
Take my story: Was pursuing a PhD in physics/engineering and dropped out. Heavy on mathematics. And programming was always a hobby/passion. Went into industry in my discipline (not programming). Then decided to change careers into software.
Going in, I had the impostor syndrome. I had read quite a bit of CLRS in grad school on my own, but remembered little. So I took a bunch of Coursera courses to review all the basic algorithms, graph theory, etc.
My goal was that this was the bare minimum to survive, and I would work for a while and figure out what to focus on next (architecture? networking, OS? databases?).
Well, I've been working a bunch of years now, and there is no "next thing". Even the algorithms courses I took, while a lot of fun and interesting, play little role beyond what most Type 2 engineers will know!
That's just the reality: Most software jobs do not require you to know much beyond the basic data structures (hash, sets, lists, etc) and the complexity of their storage/operations. I looked for ways to use all the extra stuff I had learned (in essentially introductory algorithms courses), and did not find opportunities. I'm facing the inverse problem: Someone who knows some of this (or wants to), and having trouble finding a job where this knowledge actually leads to more robust systems.
And it's hard to find the jobs where these things matter, and it is rare that they are paid more. Difficulty and complexity does not equate to higher pay. Market rules do. Trust me, I know. I was doing more challenging work before I became a software engineer, but I get paid more now because there were few challenging jobs.
I know people say it often, but I'll say it too: Communication and negotiation skills are more valuable than the topics on the page. Why spend your nights on diminishing returns when you can get pretty far with just the basics of negotiation? Most engineers are overeducated in terms of what they need to know when it comes to technical skills. But other important skills? We're very undereducated. Why work hard to be even more overeducated, while ignoring the deficiencies?
Having a strong background in math and algorithms is very useful because it opens up the number of problems you can solve. However, knowing these things doesn't mean you will face problems that require them.
I've had jobs where I've used fancy math all the time. I've also had jobs where there was no fancy math required at all.
> You know, as a former academic, I was reading this list and I immediately knew: This is written by someone in academia (and sure enough, you find out at the bottom it is).
What defines academic here? The author is not a professor nor a phd in CS as far as I can tell. I would argue this list is more broad than an academic would write necessarily. Also I argue this article emphasizes "vocabulary" over an ability to apply and connect this knowledge.
>Well, I've been working a bunch of years now, and there is no "next thing". Even the algorithms courses I took, while a lot of fun and interesting, play little role beyond what most Type 2 engineers will know!
That's just the reality: Most software jobs do not require you to know much beyond the basic data structures (hash, sets, lists, etc) and the complexity of their storage/operations. I looked for ways to use all the extra stuff I had learned (in essentially introductory algorithms courses), and did not find opportunities. I'm facing the inverse problem: Someone who knows some of this (or wants to), and having trouble finding a job where this knowledge actually leads to more robust systems.
I believe I'm going to have to disagree (and I really mean this to have a conversation rather than an argument)
Summary: Why?
I agree in that many jobs are Type 2 engineers. But I argue a lot of the new technology-driving things that are made, are not made by Type 2 engineers as well. I would argue many of the new "wow" things that are coming forward in tech require a quite strong Type 1 background - similar if you're trying to work in finance.
E.g. Alexa the device alone requires a lot of hw, os, fs, nlp, ai, networking work.
> And it's hard to find the jobs where these things matter, and it is rare that they are paid more. Difficulty and complexity does not equate to higher pay. Market rules do. Trust me, I know. I was doing more challenging work before I became a software engineer, but I get paid more now because there were few challenging jobs.
I both disagree and agree. Most jobs look pretty type 2 to me as well. But even at a google/fb/amazon/microsoft there are opportunities for type 1 work. At Apple for example there is the Core OS and Networking Teams. At Google there are quite a few OS, networking, SDN, algo, distributed sys, file store, ...etc teams.
And in terms of core skills I would argue there are people who get paid /quite a bit/ more for their abilities. E.g. if you look at very top-tier devs at (for argument) Citadel, or Memsql or similar, their pay tends to be quite better than most other places. Similarly phd's in $specific-topic are frequently very highly valued. E.g. AirBnB is paying quite a premium on PhD economists right now.
I would argue you need to have something in mind as well in order to have these be useful, and that won't necessarily spring to you.
E.g. Understanding FSs is very useful when setting up booting for new embedded devices (e.g. at Cisco).
>What defines academic here? The author is not a professor nor a phd in CS as far as I can tell.
True - I did not realize that. But what I mean by academic is someone who is not in industry and mostly has teaching or research experience.
>I would argue this list is more broad than an academic would write necessarily.
Pretty much everything listed is part of the CS curriculum - either as a required course or as an elective.
>But I argue a lot of the new technology-driving things that are made, are not made by Type 2 engineers as well. I would argue many of the new "wow" things that are coming forward in tech require a quite strong Type 1 background - similar if you're trying to work in finance. E.g. Alexa the device alone requires a lot of hw, os, fs, nlp, ai, networking work.
No disagreement here. But how easy is it to get a job in these even if you have a Type 1 background?
It's the same story in other disciplines, like my own background in physics/electrical engineering. When looking for a job that utilized the skills I had learned, I found very few. Most listed a minimum of a PhD (even if the job really didn't need that much knowledge), which I didn't have as I dropped out of my PhD program. What's more, once I was "inside" with a job, I found out most people doing jobs that required a PhD were doing work that required even less technical skills than the job I was doing (and my job required knowledge of one somewhat advanced topic, but no heavy mathematics).
Yes, I accept the jobs you write about exist. But it is hard to get them even when you have the skills. The supply vastly exceeds the demand. So why spend time honing these skills (beyond personal curiosity)?
>But even at a google/fb/amazon/microsoft there are opportunities for type 1 work. At Apple for example there is the Core OS and Networking Teams. At Google there are quite a few OS, networking, SDN, algo, distributed sys, file store, ...etc teams.
Same is true at the large company I work in. And again, the majority of software jobs at my company are Type 2.
>And in terms of core skills I would argue there are people who get paid /quite a bit/ more for their abilities.
My argument is not that these people do not exist. My argument is that when you look at the typical person who has Type 2 knowledge, they are not paid that much more (I suspect it is true even when restricting to jobs that need that knowledge).
Look at web development. I know some people really get paid a lot for it. But most of the people I know in it who do network programming (and not trivial network programming) get paid less than I do. And my salary is not high. The web is a particularly notable example. I routinely bump into software developers doing web work that requires a lot more ingenuity than my boring business logic work. Few get paid more than me.
I don't have a problem with this list per se. For all I know, it may be a good list and the designation of Type 1 and Type 2 engineers may be accurate.
But I wish I read a post from a Type 1 engineer in industry that mirrored what academics often write. I hardly find one. Why the disconnect? If the academics are so right, why is it mostly academics who preach this? There are more Type 1 engineers than academics, I'm sure.
Take my story: Was pursuing a PhD in physics/engineering and dropped out. Heavy on mathematics. And programming was always a hobby/passion. Went into industry in my discipline (not programming). Then decided to change careers into software.
Going in, I had the impostor syndrome. I had read quite a bit of CLRS in grad school on my own, but remembered little. So I took a bunch of Coursera courses to review all the basic algorithms, graph theory, etc.
My goal was that this was the bare minimum to survive, and I would work for a while and figure out what to focus on next (architecture? networking, OS? databases?).
Well, I've been working a bunch of years now, and there is no "next thing". Even the algorithms courses I took, while a lot of fun and interesting, play little role beyond what most Type 2 engineers will know!
That's just the reality: Most software jobs do not require you to know much beyond the basic data structures (hash, sets, lists, etc) and the complexity of their storage/operations. I looked for ways to use all the extra stuff I had learned (in essentially introductory algorithms courses), and did not find opportunities. I'm facing the inverse problem: Someone who knows some of this (or wants to), and having trouble finding a job where this knowledge actually leads to more robust systems.
And it's hard to find the jobs where these things matter, and it is rare that they are paid more. Difficulty and complexity does not equate to higher pay. Market rules do. Trust me, I know. I was doing more challenging work before I became a software engineer, but I get paid more now because there were few challenging jobs.
I know people say it often, but I'll say it too: Communication and negotiation skills are more valuable than the topics on the page. Why spend your nights on diminishing returns when you can get pretty far with just the basics of negotiation? Most engineers are overeducated in terms of what they need to know when it comes to technical skills. But other important skills? We're very undereducated. Why work hard to be even more overeducated, while ignoring the deficiencies?