This is not to say that computer science (CS) skills aren't important -- they are! But far too many companies base their hiring process around "are you a recent graduate from a top-tier CS school" rather than "can you do the work that needs to be done here?"
Being a software engineer is about way more than just knowing what algorithm to apply to solve a clearly-stated problem. You need to know how to build automated test suites, how to make software which is easy to deploy and maintain, and how to deal with the real world, where Things Go Wrong All The Time.
Having worked as a consultant for many years, with a large number of teams, I can say with some certainty that I would rather hire a person that had mediocre-at-best CS skills, but was otherwise a rock-solid software engineer.
Because the amount of time they will spend implementing graph-traversal algorithms is asymptotically close to zero.
They will instead spend pretty much all of their time needing to write code that other people can maintain.
Why would I spend the majority of the interview process focused on the former, rather than the latter?
Admittedly, this has given me quite an edge as a manager when it comes to hiring.
Because my hiring process focuses on "can this person do real-world work in a real-world context", I usually manage to find rather excellent engineers that other companies overlook.
Actually I think this is exactly what a software engineer is. Knowing what datastructure to use in which situation because of its implementation details is important! Yes, it's not the only aspect of the job, but it's hugely important.
It can be as simple as Arrays vs. LinkedLists; where Arrays have zero cost access and LinkedLists have high indexing costs, but low constant time insertion costs where you don't know the content length. This can have huge effects on the performance of an application.
This is important to applications, and no, you don't have to implement the datastructure, but knowing which to use when and why can save you the time later from having to find all your performance problems.
In the binary education system in The Netherlands there are two types of universities, that which prepare people for industry jobs and that which prepare people for research. I went to both, the former has only a small focus on algorithms, complexity and datastructures. The latter has specific courses about those topics.
I think in practice you can often reach good enough performance without worrying about which algorithm or datastructure to use or what the complexity of your code is. There are many exceptions where those kind of skills are actually required, but it's easy to forget that software is a huge market and that a large portion of that market is people developing fairly uncomplicated applications.
You can create an incredible amount of value in the software industry without knowing much of computer science, but you are dependent on people who actually have that knowledge to create your tools, dependent libraries, used services, etc.
If you don't know whether to do CS or business administration, you might be able to do something in between, e.g. business administration with a IT specialisation.
(I got master degrees in Computer Science and Business Information Technology from the University of Twente and am currently a PhD student in Empowerment Informatics at the University of Tsukuba in Japan)
It's far more important that the code be simple, readable, and integrate easily with other teams' work.
Yeah, sure, in some domains latency isn't terribly important, but there certainly are a number of domains where it is.
I didn't read it as derision. I read it as an indication of a different focus between two areas of development. Microseconds don't matter in most cases. Milliseconds matter more often. Something optimized for microsecond-ish timing will make a tradeoff somewhere else (like code readability, generalness, etc).
Are you sure you don't mean 10 microseconds?
[0] http://stackoverflow.com/questions/17256040/how-fast-is-stat...
But then in the real world, arrays can still be faster than lists even when you're inserting a lot...
My point was more that understanding the semantics of the two types is important to how the program will run.
Ah, if only we could know how well the people do at the jobs they are hired to do.
9 times out of 10 that requires gut feel, subjectivity, biases, etc. Inverting binary trees is measurable and objective.
I give 60 minute programming exercise in a language of choice as the first part of the interview.
I do that part first because it separates the doers from talkers quickly. Measurable and objective.
Yes. Definitely.
Depending on the nature of the work I could see expanding this statement to include writing any part of the software. In other words, "the time they will spend writing code is asymptotically close to zero". This, BTW, is also the reason I don't care for discussions about text editor efficiency. In certain domains these can be rounding errors in the accounting of the totality of the work surrounding the production of solid, reliable and well documented software and the tools required to test, deploy, support, configure and sometimes port it.
I can't remember the last time I asked a candidate how they would detect a palindrome or traverse a tree. I could not care less. There are books and google for that. I want to know how they think, how they organize projects, what they prioritize, how they approach new problems, etc. I also want to know they understand how business works. I prefer people with entrepreneurial experience, even if they failed...particularly if they failed.
Depending on project type a team can easily spend 10x more time doing things other than actually typing code. In fact, they should spend 10x more time doing those things, for example, architecture, design, documentation, testing, etc.
There is no such thing in this day and age as a "best possible" developer for all situations. Going through this list will definitely let you understand the underlying principles and the implementations of the code you write, and the systems its running on - I'm not downplaying the value of learning here. It does frequently feel like its a high horse thing.
A sysadmin or someone in devops, for example, obviously there's minimal benefit for them to understand the ECDSA protocol, and to an extent you don't even need to know how SSH key exchange works. But being aware of them: the role of the private key and the public key, what purpose they serve and the generic high-level overview of their role in SSH - that is information someone in that position would benefit from.
For a systems/app developer, yeah, you probably don't need to understand the theory behind how GC works in Java/Python/Go or the intricacies of DNS records, but when you start seeing heap size errors, weird pause times, or network connectivity issues, simply being aware of all of those things means that you know where to start looking.
I'm 100% with you - there's a limit, and as with all things, you have to prioritize. But every time I see this discussion come up, there's always this push back: "street skills over book smarts!" And there's always this undercurrent that the book smarts matter but ugh why do people care so much and there's never any talk of a balance: knowing what book smarts you might one day need to supplement those street skills.
People that know what they don't know are far more valuable than those that think they know everything. The first class can educate themselves when necessary to fill a gap. The second class is lost. They'll often spin in ignorance for entirety, never finding a solution to the problem, probably without ever once asking for help to someone nearby that is more knowledgeable.
I enjoy having a pretty big network of people to postulate problems at and get new areas of research when I come against a stuck problem.
I think there are 2 fundamental indications of indication of success in software development/engineering: 1. an eagerness and desire for continued learning. 2. passion for the quality of the product. Sure, there may be other factors, but I think if you don't have these 2, they're probably not going to be a positive net contribution on a project.
UIs can be ugly and still get the job done. If your compiler or interpreter doesn't work, you're hosed. If TCP doesn't work, you're hosed. If your OS can't properly schedule processes... You get it.
The people who make things work are demonstrably more important than those who make things pretty and pleasing to us. I would give up either, but if I had to, the UI can shove off. Computers were changing the world long before we even had UIs.
If they don't work, we're hosed - but they do work. They have worked for decades. So what are you saying all these people are doing presently?
Without the mountain of abstractions they sit upon nothing works.
Because Linux Audio sure is better with a mountain of abstractions, so is Wayland, so are the several unstable competing high level filesystems, and cramming applications in the browser is such a delightful experience to develop and use compared to fast, local, platform-integrated, more simple native applications. Because pulling down 30 dependencies like 'pad string' from github to get a HTTP listener running for a Ruby based IRC chatbot is such an improvement. Because everyone needs Bash on Ubuntu running on translated syscalls on the NT kernel and Microsoft SQL Server running on an OS abstraction layer so SQL Server Operating System provides 'robust memory management, thread scheduling, and IO services' on Linux because what - Linux can't do that already? And Docker definitely isn't just 'installing your application and all dependencies in a folder where the libraries never get patched' and a security nightmare in progress. These things are important, necessary, and without them sending text and taking digital pictures wouldn't be possible.
And hundreds of thousands of password hashes were just leaked because MongoDB installs insecurely by default, and hundreds of thousands of web pages through Cloudflare had memory leak data in them because a compiler layer had a bounds checking error. Problems that were solved ages ago by compiler writers and type system theorists and still haven't made it everywhere in production because $reasons.
Is that what they're doing? Writing scheduling engines on scheduling engines, writing GCs for more and more niche languages? Half-finishing more and more filesystems that can't deliver? Writing more and more enterprise broken-XML parsers? If I had to, that lot can shove off. Leave the rudimentary UI and the CLI and the text based protocols (and TLS).
Do you really think no one is currently working on compilers, thread schedulers, standard libraries, etc? Do you think your javascript runs faster today than it did five years ago solely due to hardware improvements?
I'm not even sure how to interpret the rest of your argument. Your middle paragraph seems to agree with me in spirit (I'm not a fan of hugely abstracted 'magical' systems either, UI or no UI.) That said, if you really think we wrote all of the lower level, technically complex code we'll ever need 20 years ago... I don't even know what to say.
No. Do you really think all the work on compilers, thread schedulers, standard libraries, etc. is forward progress? Is reimplementing list sorting for a standard library for Python and for Lua and for Perl and for Java and for Clojure and for .Net and for Go and for Ruby and for JS and for Rust and for ... really the kind of progress you mean when you say "without this, nothing works"? Is this not sideways movement instead of forwards movement?
Are there really improvements in thread schedulers in the last 10 years, that justify "without this progress, nothing works"?
Do you think your javascript runs faster today than it did five years ago solely due to hardware improvements?
Pages are more bloated, load slower, call more dependencies, have more fluff, have worse UIs. Javascript engine improvements haven't brought me better quality of life, they've turned fast desktop apps into slow web apps. Fast desktop CRUD into slow web CRUD.
That said, if you really think we wrote all of the lower level, technically complex code we'll ever need 20 years ago... I don't even know what to say.
I didn't think that until it came out in my comment, and 20 years is a bit of a stretch, but 10 years ago - ok, why not? What exactly is so much better in low level worlds that nothing modern would work without it? ~10 years ago you could have Java and C# and Python and Perl and Lua runtimes, ZFS storage, Linux or BSD schedulers memory management, Varnish cache, memcached, LLVM/Clang, ACLs, SELinux, Virtualization, IPv6, TLS 1.1, MP3s, DVDs, 3D graphics, Mozilla, and on and on.
When you say "without the last ten years of low level code, nothing works" what exactly doesn't work? Drivers for new hardware. No CUDA? No JS frameworks? No Roslyn? Less capable compilers and JITs, no Go-Lang?
Right right, some things run a bit slower, and others would have to be written in different languages. But what ... can't you do? Actual things you can do now that would be impossible? Go back to a CLI only and there's a lot you can't do. Drop hardware video decoding and you can't usefully play video. Drop all the GC/RAD languages completely and there's a lot of apps you can't economically write at all. Go far enough back and there is no storage with checksumming or storage which can do software RAID or storage with multi-TB support, no independent processes - but this doesn't go that far back, not at all.
Sure there's newer, faster hardware, and there are benefits. Sure things are being worked on, but there's a huge amount of towering tech stacks now abandoned, duplication and triplication of the same effort, and general sideways churn and reinvention of wheels that isn't forward progress.
I guess I'm saying that C -> high level GC'd languages was a hell of a change. Two high level languages -> twenty high level languages isn't. It's more human-hours but less progress. Mainframe TUI programs to localizable high res desktop apps was a hell of a change. Desktop CRUD to Web CRUD isn't. No web server to a web server to PHP and maybe to RoR was a hell of a change. One dynamic web framework to a hundred wasn't.
I agree with this sentiment and what's even more frustrating as a old (and since I'm over 35, rapidly aging) developer I find it incredibly sorry state of affairs that even the Type 1 kind of engineers mentioned in the article have to put in the off work hours in learning the newest buzz word language /framework /rehash of the day, to be able to keep doing what they love doing.
The other thing also is the frustration that those of us who actually love to learn, love to learn more than just technology. One of my friends actually choose to not give into the hype and not trading his time improving as a jazz musician, graphic artist and whatever else takes his fancy for learning the latest tech-du-jour. My own imposter syndrome keeps me from being able to take that kind of a risk. This is sad.
> someone that appreciates aesthetic, design, and people
> [can] create a frontend
> someone who can write a compiler from scratch
I've also found it doesn't matter; no one cares. This combination isn't valued.
The only thing that's valued (per revealed, not stated, preference) is your skill at solving homework problems on a whiteboard with an interviewer breathing down your neck and hoping to prove you're an idiot.
Recently I've been getting more and more eager to move into development, however. Now perhaps it's just a personality thing, but I'm very keen to learn CS basics and get a good grasp of maths whilst I make this transition. I think this is important for me simply because I want to be able to utilise CS level maths to solve certain CS problems. As I never went to university, I'm losing out on some efficient solutions.
All this being said, I could stumble around without this knowledge and do just fine ($200k a year, in fact) as a contractor. I just personally feel the CS level knowledge is important to become good at what I want to do.
I work in any fields that need me, excluding gambling or anything immoral or unethical.
EDIT: forgot to say that I work for multiple companies, yeah. I love around once every 3-6 months, essentially.
I say this as someone that is very much in that Type 2 category and only encounters the Type 2 developer on a regular basis. I deal in ERP systems, a subject which generally doesn't draw many Type 1's to either creating them or running them for their companies. That's not to say there aren't smart people involved in this area, nor are they underachievers. Still, by and large many of my colleagues have a certain very practical, but shallow understanding, of technology generally and simply aren't equipped for more challenging, real engineering scenario.
I disagree with the website in that somehow becoming more Type 1 is necessarily the only way to bolster your competitiveness as a programmer. I do pretty good compared to many of my peers in my area of expertise not because I strive to be an engineer (which I end up doing anyway), but rather because I have gained substantial knowledge of accounting, warehouse operations, logistics support, etc. that allow me to use my modest technical skills (by comparison to the Type 1s) to achieve not just any program for my clients, but often times the right one. Sure, it may not be as efficient as it could be, or as clean, etc. but it matches the actual need better than many of my peers can achieve. The value of that domain knowledge also makes it so I don't compete directly with the Type 2s that "just program" on a global scale. It's helped with age bias, too.
Anyway, I still look up to many of my Type 1 friends and (occasional) colleagues for their often times more accomplished technical skills.
Just as an aside, your comment was among the most complete I've ever seen. It addressed almost every caveat that I could have though up!
I didn't see the OP was judging anyone but describing a type they perceived was only interested in development as a stepping stone to something else.
In fact you yourself seem to be completely judgmental and also condescending telling someone:
>" ... you haven't met a huge amount of people to make that assumption, or have interacted with people in other great places to work"
You seem to have no issue passing your own judgement however by telling someone that their opinion is "degrading this forum." That's a pretty rotten thing to say.
But for the sake of argument, while I don't deny that India has some star developers, I think it's incorrect to suggest that there isn't a huge section in it for reasons _other_ than a pure love of computers. Many do it because they need the money, or need a stopgap before they go on to do other things etc. I stand by what I said.
Finally, I'm not sure why you're implying that maybe _I'm_ a feet dragger and that I need to work on improving the company I keep. I thought my comment was fairly mild and inoffensive.
You're not paid for doing that. Please stop.
It's only a problem if the employer starts treating this as the norm, and expects to sacrifice their personal time. Then it's time to find a new employer.
The fastest way to get promoted when you are young or low on the ladder is to leave your company, not to climb up.
Your future companies won't know and won't care what time you put in.
The (good) reason to take work home is not to suck up. That's crappy strategy. The good reason to take work home is that it's practice. The sooner you put in the hours, the sooner you can get-and-keep the better jobs. Obviously there's a limit to personal endurance, and so just pushing yourself to grind out 80 low-quality hours per week is insanity. But taking work home, selected with the intention of improving your own skills, is often good advice for getting ahead. Hustle correlates with prosperity.
You're right, though, that if _I_ take work home, that you, user5994461, are thereby disadvantaged in the market. Thus I assume that your imperious demand that others not pursue career success is a cynical ploy to improve your position.
Since career success is linked firsts and foremost to negotiating offers and following a career plan, I demand that you negotiate better and follow a more aggressive growth plan! It will give you more returns for less efforts than long hours.
I am on the high end of the spectrum, I actually need others to pursue their career success better in a cynical ploy to improve my position. ;)
Disclosure: I am probably a Type 1-aspiring Type 2 developer
The more important thing though is that it's a line of thinking that enables people and gives them confidence to get going earlier, rather than wait until they've checked a bunch of checkboxes and have been cosigned by an institution. I think all the fears and ego-issues around not knowing enough before you get started are a bad thing, an inhibitor.
That said, I now wish I had done those 4 years. It would be amazing to be able to take 4 years off just for school at 31 than to have to struggle to find time to learn in the middle of projects. But it just was never gonna be any other way for me than diving in. And after all, a mindset of continual learning is what it's all about.
I think diving in and building something--regardless if you start out early with a CS degree--should be the primary focus.
If you jump straight to a CS degree before even building a simple website or simple whatever, it's a mistake. And ideally develop a minor level proficiency and achieve some wins where you start feeling yourself for your growing skillset. If you jump into a CS degree without at least having that, ur making a huge bet on something you know nothing about, that you might not even enjoy.
Now I feel silly. Thanks.
Can you post the explanation of these terms?
Both call themselves software engineers, and both tend to earn similar salaries in their early careers. But Type 1 engineers grow in to more fullfilling and well-remunerated work over time, whether that’s valuable commercial work or breakthrough open-source projects, technical leadership or high-quality individual contributions.
Type 1 engineers find ways to learn computer science in depth, whether through conventional means or by relentlessly learning throughout their careers. Type 2 engineers typically stay at the surface, learning specific tools and technologies rather than their underlying foundations, only picking up new skills when the winds of technical fashion change.
Currently, the number of people entering the industry is rapidly increasing, while the number of CS grads is essentially static. This oversupply of Type 2 engineers is starting to reduce their employment opportunities and keep them out of the industry’s more fulfilling work. Whether you’re striving to become a Type 1 engineer or simply looking for more job security, learning computer science is the only reliable path."
That said, I think it is a mistake to assume that lots of Type 2 developers wander around in a perpetual state of under-achievement. Most of these people are indeed a different class of developer (I think the word engineer is positively abused), but many of them really have almost no professional requirement to understand fundamentals. Any more than they need to understand particle physics.
These developers are a class of systems integrators and they produce a lot of usable systems, at a quality level that represents appropriate trade-offs to the business case they are employed to address.
Yes, many will say this is a less elevated pursuit. It has its own challenges and mindset. It lives at a particular level of abstraction and its very existence assumes stability of that layer of abstraction. The fact that this breaks down sometimes is besides the point.
The reality is most developers probably do Type 2 work, though very many may have or aspire to have a Type 1 level of knowledge and insight. However I think it's unfair to portray a contented Type 2 developer as lacking in some essential.