
What every computer science major should know (2011) - rspivak
http://matt.might.net/articles/what-cs-majors-should-know/
======
glangdale
These kind of lists are always hilariously overstuffed, like a big comfortable
rhetorical couch.

It's not all that hard to make up a giant list of 8-10 years worth of
material, which if anyone took seriously would also lead to a monoculture i.e.
we didn't have any time to do anything aside from computer science and this
giant-ass list of requirements like "physics up to electromagnetism".

I'd say I was close to hitting, for about the year 1997 or so, these
requirements or their equivalents as they existed then, after (a) a pretty
decent prep at high school level (Australian high schools allowed a heavy
math/science concentration), (b) 4 years of undergrad with - nominally CS as 1
subject in 4 in first year, 1 in 3 in second year, 1 in 2 in third year and
full-time in honours (but actually way more focus on CS vs other subjects),
and (c) completing the 8 graduate courses required to move on to the rest of
the PhD at CMU.

Even then I'd have a long list of gaps in his definition. And that's off 7-8
years of prep, not 4, and an Australian honours CS degree allowed a lot more
specialization than a lot of 4-year degrees in the US at the time.

It would be a more interesting approach to try to define a minimal set. Anyone
can spam out 8-10 years of study and everyone will agree that, sure, someone
who knew all that would be Pretty Good (better have 11 programming languages
under your belt, hey). But a far more interesting task is - what do you
_need_?

And, perhaps, in a class of 100 people, why should everyone come out with the
same laundry list? Maybe it's good to have 20 really good statisticians there,
as well as 20 people who could design the processor they are programming on,
etc etc (obviously an overlapping set).

~~~
toper-centage
This list was surprisingly sane and almost exactly the programme of my 5-year
degree.

~~~
meuk
I can't help but think that you can only do a very shallow treatment of
everything in this list in a CS program. It seems like the author basically
put down his own CS program as a requirements list. The style the author uses
reinforces this thought, since the sections are very shallow and very closely
match what I would expect from someone who did an introductory course on every
subject in the list. And I'll be damned if the 11(!) programming languages
"every CS major should know" aren't exactly the programming languages that the
author happens to know. It would be a surprising achievement to even know just
C and C++.

This post may be influenced a little by the irritation that after seven years
of study and two years of work experience (and many time spent on this stuff
as a hobby in my free time), I still don't match nearly 50% of the
'requirements' in this list. But hey, these lists should be taken with a lot
of salt. It's pretty fun to make one and reflect on all the things you've
learned. In my list, there would be more numerical analysis and less
languages.

------
pinacarlos90
I come from a CS background and learned a lot from studying CS, it definitely
gave me a strong foundation and changed the way I view and understand
computing. I learned most of the topics mentioned in this document while in
school, and although they are all valid, they are not enough for real world
needs.

~90% of CS undergraduates will end working as or with engineers, and in 2019
here are the skills that are indispensable:

1) understand popular protocols used in WWW (http, ssh, ftp, etc)

2) version control (Git). Understand pull-requests and the process of
collaboration in a team

3) problem solving - how to breakdown problems, and how to overcome them when
you reach a wall (use known algorithms when possible)

4) design patterns (learn as many as you can)

5) frameworks: MVC, angular, dependency injection, etc

6) communication skills

7) how to organize work, how breakdown big tasks into small easier-to-
accomplish pieces

8) understand deadlines

9) write tests (unit-test, integration-test, etc)

10) understand that “good enough” sometimes is all you need (still try to fix
it later :) )

~~~
burlesona
This is a great list. I would add _estimating_ , although it's implied in a
few of your points.

As an engineering manager I find that a consistent difference between good
engineers and great engineers is that great engineers can tell me how long
something will take even when they haven't done something just like it before.
That doesn't mean they can perfectly forecast how the hours will be spent --
no one could do that -- but they know how to figure things out, know how to
build in some buffer, and know how to go heads down and crank when absolutely
necessary, and as a result they can consistently hit deadlines.

~~~
drieddust
Don't you think estimation is a management job? What if Engineer decides to
over estimate and enjoy the freetime?

~~~
hamburglar
A manager with an attitude that engineers would pad their estimates to "enjoy
the free time" is a guaranteed way to get good engineers to quit a team. Not
only does it betray a complete lack of trust, but it means engineers are going
to be pressured to lower their estimates, which never turns out well.

------
commandlinefan
> must practice persuasively and clearly communicating their ideas to non-
> programmers

If you’re a CS major, panicking over this sort of “technical skills aren’t
enough, you have to be a persuasive public speaker and effectively do
management’s job for them”, people have been saying this since at least I
started coding 30 years ago, and I don’t see any evidence that it’s actually
true any more than it was back then - focus on technical ability, that’s a
hell of a lot harder to come by than “powerpoint skills”.

~~~
ergothus
> focus on technical ability, that’s a hell of a lot harder to come by than
> “powerpoint skills”.

I'll agree and disagree:

Yes, the target audience here SHOULD focus on technical ability. Not because
it's "harder", but because that will be the primary decider in getting hired.

That said, I'd say my communication skills have been a central part of my
success. Not "powerpoint", so much as being able to distill down ideas,
translate abstractions, and of late, learning how to examine other people's
ideas without coming across as I'm attacking them. My personal impression and
the reaction my managers have given me is that these skills are both rare and
valued in the field. But you do of course need technical ability or they are
worthless.

I definitely think I've achieved more success than my technical ability alone
would grant me. It could be Imposter Syndrome talking, but I'm not actually
all that great at this. Just good enough, and my communication skills ensure
that the "good enough" is applied where it's needed and to the degree it is
needed.

Ultimately, coding is communication, and maintainable/extendable/flexible code
is a lot of communication to other devs (including your future self). Even
outside of the role of managers, and even outside of planning and architecting
with your peers, communication is a valuable skill for a programmer to have.

~~~
nostrademons
Junior developers get hired on their technical skills. Mid-career developers
get hired on their communications, interpersonal, and domain understanding
skills. Founders and executives get "hired" on their strategic skills.

If it's your first job out of college, don't worry too much about the
communications skills _yet_. Your technical abilities will be your
differentiator, and your daily job will largely consist of implementing
things.

But if you don't pick up communication skills within the first 10-15 years of
your career, it will limit you. You'll be stuck implementing things forever,
which may be what you want, but it will shut you out of some higher-
compensated and higher-impact jobs.

Unless you just want to go the founder route and hand your company off to a
professional CEO that the VCs hire once you've proven out product/market fit.
If you have both technical and strategic skills you can do that, but the lack
of communication skills will still keep you from running your own company.

~~~
mucholove
Too young to know for sure...but seems right. Can you help me understand what
strategic skills are? Resource management?

~~~
nostrademons
Strategic skills are understanding the context and constraints that you
operate under and acting to maximize the advantage that things you do not
control give you. Things like positioning yourself in the right market within
the right industry; understanding how the market will change and how you can
capitalize on that change; knowing who the other players are; predicting what
they're likely to do based on their incentives; building alliances; making
trade-offs; and identifying underutilized resources that you can capitalize
on.

------
bigred100
To me, this sounds more like what a good CS Ph.D who spent his free time
filling in every general CS knowledge gap he could come up with would know.

I don’t know why he says learn real analysis and linear algebra to talk to
engineers when I doubt 90% of engineers took one analysis course unless
they’re Ph.Ds.

~~~
jstewartmobile
Judging by the Wikipedia article, "Real analysis" is freshman-level math for
most branches of engineering.

Pretty shocking how little math most CS programs require in comparison.

~~~
bigred100
In the US universities I’ve attended, it’s a senior level mathematics major
course. Second semester freshman calculus will teach you similar material in a
much more glossed over fashion and apply it to very simple examples.

~~~
jstewartmobile
Matt brought up RA in the context of " _speak the same language_ ". In that
context, freshman calc ticks the box.

His standards are high, but fair.

~~~
bigred100
There’s no reason to call it RA as no one including almost all the engineers
took that class. They’ll just call it all calculus

------
acbart
> Racket, as a full-featured dialect of Lisp, has an aggressively simple
> syntax. For a small fraction of students, this syntax is an impediment. To
> be blunt, if these students have a fundamental mental barrier to accepting
> an alien syntactic regime even temporarily, they lack the mental dexterity
> to survive a career in computer science. Racket's powerful macro system and
> facilities for higher-order programming thoroughly erase the line between
> data and code. If taught correctly, Lisp liberates.

What a rude paragraph. I think this viewpoint is very unfortunate. I love
functional programming, and I think everyone benefits from learning it, but
this garbage attitude is toxic to students. The author cannot imagine a
successful computer scientist who doesn't love the same PL paradigms as him. I
would prefer to keep them away from my learners.

~~~
Gene_Parmesan
> who doesn't love the same PL paradigms as him.

I don't see that at all. It's not about enjoying it, it's about having the
ability to adjust to the Lisp syntax, full stop. Given that Lisp is just about
as close to programming directly in an AST as you can get, I'm not sure that
claim of his is too far from the truth. Remember, we're talking about computer
science, not programmers generally.

~~~
namenotrequired
I don’t know why you’re being downvoted, you are correctly pointing out the
GPs fallacious argumentation.

------
WalterBright
It's a good list, and I always recommend these:

1\. Public Speaking. If you can't talk coherently in front of a group of
people and sell your ideas, your career will be stunted.

2\. Accounting. Accounting is the language of business. If you don't
understand double entry bookkeeping, you can't be a manager. You can't run a
startup. You can't talk to investors. If you misuse terms like "gross margin"
you'll be overlooked as someone not worthy of doing business with. And worst
of all, your feathers will get plucked by people who do, and you may never
even realize it.

Neither of these are particularly hard to do, but like flossing one's teeth,
avoiding them will be costly to your future.

~~~
Dextro
And I've spent far too much of my time in my last project explaining double
entry bookkeeping to coworkers to little effect. I had to watch has they re-
invented the wheel.

Sadly I'm not that good point 1 (actually terrible at it).

~~~
WalterBright
> Sadly I'm not that good point 1

It gets better each time you do it. Taking a class in public speaking helps a
lot. I've seen engineers stand with their back to the audience and mumble -
it's not hard to do better than that.

> And I've spent far too much of my time in my last project explaining double
> entry bookkeeping to coworkers to little effect. I had to watch has they re-
> invented the wheel.

Yah, reinventing that is certainly cringe-worthy.

I took a 2 week class in it at the local community college one summer. It's
paid off well for me ever since. A very high return on time invested.

The other huge ROI for me was I took a 2 week summer school in 8th grade on
touch typing. Considering how much typing I've done since, that had a heluva
huge return.

I sometimes shake my head in astonishment at professional programmers hunt-
peck with just their forefingers as they resolutely refuse to learn touch
typing. What a waste of time.

~~~
WalterBright
BTW, I've looked for a voice coach to improve my public speaking. All I could
find was people who'd teach singing. Sigh. Most people could enunciate better,
and that makes it easier for your audience to understand you and hence they're
more likely to pay attention.

It's especially important in the modern world where a large part of your
audience will be non-native English speakers.

------
vages
Is there anyone who ever knew all of this when they graduated?

I think maybe the top student through my five years at university might have
known all of this. I sure as hell did not check all the boxes when I graduated
two years ago.

If you're nervous after reading this, just know that the "should" probably
means "in an ideal world".

~~~
glangdale
If you covered all this in a 4-5 year program, you either worked 90 hours a
week and didn't take any other courses ("major" doesn't mean full time) or
each of these courses was covered in an "edited highlights" fashion. It's a
preposterous list.

~~~
mrep
Agreed. My program had 9 different tracks you could focus on [0] with many of
his titles having their own dedicated track.

[0]:
[https://www.cs.purdue.edu/undergraduate/curriculum/bachelor....](https://www.cs.purdue.edu/undergraduate/curriculum/bachelor.html)

------
_hardwaregeek
Eh, skimming through this list, I see what's essentially a bunch of courses.
While all of the listed topics are fairly important, it's highly unlikely
there exists a curriculum that covers all of them. I'd even venture that no
matter which school, which curriculum, which professors, there will be
something absolutely and obviously essential omitted from one's education.
There's certainly topics left out from this list that are undeniably crucial.
In some schools there will be far more than one thing omitted (reading the
list, I'd say my school teaches maybe half of this to the good students, and
less than a quarter to the mediocre students). in others, it'll be one or two
topics. Regardless, the answer is not to cram more into the curriculum.

The answer, as trite as it is, is to teach a man to fish. If you want people
to learn a wide breadth of topics, provide them with a set of _qualities_ like
curiosity, determination, problem solving skills, etc. Don't just give them
what you deem to be a wide breadth of topics. I see far too many fellow
students who just want a list, a guide such as this to follow so that they can
be the best student and get the best job and live the best life (not that
that's a bad goal). But in their attempt to live by a list, they ignore
anything and everything else. I find it really sad when I talk about using
OCaml or the fun of playing with Emacs, they shrug and insist that it's not
"useful", that it's not on the list.

------
quickthrower2
In my experience no one cares about the portfolio. They want your CV, some
references and to pass some coding tests. Now to be fair I am not going for
the highest paid jobs or jobs required deep computer science knowledge, but
for the ordinary job I have found that recruiters and employers alike look at
CV. They might look at github if you are lucky.

~~~
kasey_junk
If you aren’t using your network (you have a network right?). You’ve already
failed.

No one in tech knows how to hire so its all network based. This isn’t a good
thing but it’s where we are.

~~~
Balero
I didn't use my network to get a job. I moved to a new country with no
network. I have a well paying job and am quite happy. I have not failed.

I can see the benefit of having a network, and even leveraging it. But it is
not everything.

~~~
kasey_junk
How did you get your job?

------
archagon
This is tangential, but HOW, HOW, HOW does someone have the time to do all
this stuff? [http://matt.might.net/materials/matthew-might-
cv.pdf](http://matt.might.net/materials/matthew-might-cv.pdf)

I'd love to see a timeline of how some of these super-productive academics are
able to fit so many activities into their lives. I doubt I've done 1/10th of
what Matt has done in the same amount of time. (And all this while
researching, publicizing, and treating his son's rare genetic disorder, in an
entirely separate field from the one he got his PhD in:
[http://matt.might.net/articles/my-sons-
killer/](http://matt.might.net/articles/my-sons-killer/))

~~~
felipap
Related: should I also be including my Twitter and Google+ followers in my CV?

~~~
titanomachy
Do you have a lot of them?

~~~
felipap
Afraid not. :'(

------
tracer4201
My day job is engineering at one of the big tech companies whose search
services most of the people I know use almost every day.

In the 100+ interviews I’ve done for engineers, I’ve never cared for their
portfolio. It’s hard for me to know if it really is their portfolio or if they
actually wrote the code, etc.

I’m going to ask you design and coding questions.

~~~
mieseratte
If someone has a portfolio I will certainly ask about those projects. Gives an
opportunity to demonstrate technical acumen and communication skills at the
same time.

------
dang
Thread from 2015:
[https://news.ycombinator.com/item?id=9490723](https://news.ycombinator.com/item?id=9490723)

and originally:
[https://news.ycombinator.com/item?id=2921440](https://news.ycombinator.com/item?id=2921440)

------
llamaz
Differential equations and electromagnetism?

Maybe 30 years ago, but these days electrical engineers know how to code

~~~
chrisseaton
Isn't modern ML based on differential equations?

~~~
tcgv
Sure, but only a handful of people really employ advanced calculus for
building ML, while the vast majority of Data Scientist only use the ML
algorithms implementations as a black box, without diving into its inner
workings.

~~~
mcguire
I realize that there is a certain conflict here, since I'm happy to program
computers without understanding the physics of transistors, but your comment
makes me nervous.

------
swframe2
It is easier to just list the meta skills regardless of major:

1) You should always be learning.

2) You should mostly do interesting work you love.

3) You should foster good friendships with your highly ranked coworkers; at
least having dinner once a month.

4) You should regularly look for and fix your weaknesses.

5) You should balance work and play. Exercise. Travel as much as possible.

------
hermitdev
One thing that surprises me that Python wasn't mentioned as a language of
interest. It's used in a lot of scientific computing, financial spaces and
others. Ive been using it in finance for 15 years. 15 years ago, there was
little traction, but now the quants I work with only want to use it. The
quants aren't really programmers, but numpy, scipy and pandas make them
productive without a lot of dev experience.

~~~
analog31
I'm a huge Python fan, and introduced it to my workplace, where it is now
heavily used by about a half dozen scientists and engineers. But... I think a
person who has mastered the other languages and general concepts of computer
science can pick up Python in a jiffy. And they will probably pick it up by
osmosis, if it's used in their vicinity.

I'm saying this as a physicist who has not studied CS formally, but worked
with a lot of CS'ists.

~~~
hermitdev
I totally agree.

I think what really helps is Python has really great documentation. Probably
best I've seen in a large community project. Also, the great standard lib
(batteries included).

Doesn't help either that Python has a great tutorial at the main project site
with loads of examples, and it starts slow. Very helpful for non programmers
to get started. Using it to get my 10 year old daughter into programming. I
used the same tutorial around the v2.2 days to get accustomed with it. I
already had a number of years of programming experience and had the help of
knowledgeable coworkers to learn, but it quickly became apparent to me the
value of the language.

I actually found out yesterday I'm being partially transferred to my companies
quant team to help mentor and develop best practices. I'm really excited about
it, given the opportunity to share my knowledge but also absorb knowledge from
the; finally learn what all the data Ive been pushing around actually means
(and maybe dusting off my rusty math skills from college that ive barely used
since).

------
supernova87a
As a manager, I'll tell you what is more important than almost any of these
technical skills (although they are important):

1)

The ability to communicate what needs to be done, and how it is to be done,
_before_ diving into the work. I work with tons of people who, sure, can get
the work done, but I have little to no visibility about what they're going to
do and when they think it will be done. I'm never going to be in the code as
deep as you -- the purpose of my management is to help make sure the thing you
do fits into the rest of the plan and doesn't waste time and resources. What
good does it do our team if I don't find out how long it was going to take
until you finished?

Inability to do this is generally an indication that they've not done the task
before, can't tell you how they're going to solve it before they actually do,
or are generally unable to plan their work at a higher level that is useful
for a manager. And I don't even mean that the answer has to be a rock-solid
time estimate -- if they can raise and communicate the uncertainties, that
already is an important piece of information and next level thinking -- what
do you know you don't know.

You can tell a more experienced person by whether they can give you plans and
estimates for how long and what approach they will take, before they
immediately start the work. The work isn't just a coding puzzle to be solved
-- they understand it's a project to be managed properly and are working at
your level to plan it. Versus you having to painfully extract that info from
them.

2)

The ability to self-assess whether their approach is the right/best approach,
or what compromises or missing elements their approach adopts. Rarely do I
find that people who dive right in because they "know how it needs to be done"
are doing it because that is really the right way among all possible
solutions. More like, it's the first thing that popped into their mind.

You can tell an experienced person by whether they take some time at the
beginning to debate / discuss with you what approach optimizes for what
outcome (whether time, resources, maintainability, scalability, data
integrity, etc).

The person who does even these 2 things (or similar indicators of self-
reflection and considering the problem) is -- almost unfortunately -- the
standout these days.

~~~
crispyambulance
I think those two abilities which you cite are developed ONLY with experience
in solving real-world work problems.

These are not skills which can be taught in a school. They have to be learned
through work, through mentorship and through the experience of failures and
successes. Internships certainly help, but it takes years.

It's OK if hires fresh out of school aren't able to do these things. These
need to be cultivated by you, the manager.

~~~
supernova87a
All those things are true. Perhaps I write out of frustration that people I
have seen working for 5 years still do not have these skills, or even realize
they are the next step.

------
ben509
A small point on your portfolio:

Your portfolio should show _products_ rather than _projects_. Not everything
needs to be complete, but you should be able to show that it does something.

Ideally, your resume is linking straight to a live demo, and that page links
back to the repository. Besides the fact that many devs will be too busy/lazy
to read your source, everyone will be more impressed and interested in an
actual thing they can play with.

If you wrote a library that doesn't do much by itself, at least give it a
README and documentation, and publish it to a repository. I'd rather see a
link to a package repository than a git repo. (And, of course, fill in the
metadata so I can get back to your git repo.)

(And, really, if you set up a lambda in AWS running your library, your page
can just have some input fields and a button to call the functions and show
what your code does.)

The point of all this is to take the time to put in some extra polish that
shows that you not only have ideas, but execute on them.

------
irundebian
I don't think it's that valuable to improve IDE-less software development
skills. Just because some Unix nerds find it cool to play with text files,
avoid modern software development tools or program in date languages like C it
shouldn't be desirable for a computer science major. Computer science should
focus on long-live principles, the Unix philosophy may have a lot of good
worth to keep principles, but kinda nothing in the software engineering space
should suggest we've already approximated perfect solutions and nothing could
be improved.

~~~
JustSomeNobody
Your comment shows a lot of naivety. Text is near universal, C still makes the
world go ‘round and modern doesn’t mean graphical.

~~~
jcranmer
Text is not universal. Instead, there is a nearly infinite variety of output
formats which consists of 96 printable ASCII characters (or perhaps a superset
of those characters), that may be unstructured, structured, or semi-
structured, using a variety of often ad-hoc and poorly documented formatting
for values, and a (sometimes surprisingly small) subset of the outputs can
even be read in again as inputs.

A great example of this is CSV. It's a wonderfully simple format... so simple
that there is considerable variety in things such as "how do you quote a
field," "how do you delimit fields" (considering its name is _Comma_
-Separated Values, you'd think everyone would agree it's a comma), and "what
characters are legal within fields," let alone the semantic interpretation
questions of "is there a header row", "is this column numeric or textual or
something else," etc.

------
ubermonkey
I'm a member of an older generation (in college 88-92). It's interesting how
few of my cohort (a) have a formal CS degree or (b) would tick even most of
the boxes that were possible in 1992.

Back then, many if not most CS programs were super behind industry, so what
got you hired wasn't your coursework in FORTRAN. It was what you did outside
of class, in independent projects or (a surprising amount of the time) for
money on the side. Many programmers in their late 40s-early 50s don't have ANY
degree, because they learned on their own and then got a job early, without
completing (or even matriculating to) college.

This left large holes in what they knew, if measured by this list, but
generally speaking they were still pretty fantastic developers.

How this applies to someone in school NOW is absolutely unclear. I suspect the
answer isn't "not at all," but I also doubt it's been possible to get hired in
a professional developer job right out of high school for at least 20 years.
It's hard for me to imagine how an 18 year old could know enough; the field is
so much bigger now.

------
GoToRO
I agree with it but I also disagree. They are all valuable skills but guess
what? If I know how to be persuasive, I know how to present, I even see jobs
asking for "self starters", "knows how to manage multiple projects" and maybe
I learn how to do sales then... I just start my own thing. I don't need your
job!

Of course all those skills are valuable for anyone, just like learning to play
piano is. Doesn't mean you shouldn't hire people because they don't have those
skills.

------
known
40 Key Computer Science Concepts Explained In Layman’s Terms
[http://carlcheo.com/compsci](http://carlcheo.com/compsci)

------
somezero
The sources, at least for engineering section, are not useful at all.

Assuming this stuff is needed in the first place:

Spivak's calculus, while a fantastic read, was "difficult" for motivated
honors students at institutions like Harvard. Great exposition, and great
exercises, but it's mostly for aspiring math people who want to spend some
time on the exercises. For example, within the first couple of chapters,
readers will have to do epsilon-delta style of inequalities and basically
learn the tricks, before reading about them in the "limit" chapter. For
calculus, any lightweight calculus book would do. For analysis, Abbott's
"Understanding analysis" is quite illuminating and if exercises are your thing
and want to build up to real analysis from the natural numbers in an
accessible way, then Tao's analysis volume 1 would be good.

"All of statistics" is a bad introduction to statistics because it contains
too many things (Kullback-leibler?!) early on?! It's a great book for a
reference or for a refresher, but not something to learn from. Wackerly is
light enough introduction to statistics, and for probability, Bertsekas!

------
kilo_bravo_3
CTRL-F "ethics".

Not found.

:-(

I guess another generation of developers dark-patterning their users into
giving up their personal info, and then exploiting them for stock options, a
WRX (or Tesla if they've been around for a couple of years) and a Bay Area
condo they can barely afford is upon us.

------
jcranmer
This list feels rather more like "this is all the courses I took in college,
and why you should take them too" than what should be the minimum knowledge
level of a computer scientist. For that list, you need much fewer things--I
can think of 5 things, but learning them well may require several courses:

1\. Communication skills. This should need no explanation.

2\. Required math curricula. You need high school algebra and discrete math.
Light introductions to statistics, linear algebra, calculus, and logic are too
damn useful to pass up, but a full semester course in these topics is often
overkill. Abstract algebra, graph theory, and numerical analysis are more
situational in their utility.

3\. How to design software. This is more than just programming 101 and
software architecture, you also should know how--and when--to use IDEs,
version control, refactoring, testing, debugging, code review, how to report
bugs, navigation of large codebases you didn't write, etc.

4\. What makes fast software fast and slow software slow. Computational theory
and data structures and algorithms fall into this bucket. There's a fairly
standard set of data structures to learn, but I would caution that you don't
ever need to know how to actually write a good hashtable or binary search
tree, but you should know how they work and what the performance ramifications
are. Basic computer architecture should also be required, and I think there's
often too little emphasis on the impact of the memory hierarchy in software. I
also think you should understand how a compiler is going to interpret your
code, what it will and won't do to make it faster, and what you can and can't
do to make compilers work better. (Lexing and parsing theory, which tend to be
the bread-and-butter of early compiler courses, need not apply).

5\. A deep understanding of different programming languages. First, you need a
workhorse language that most software is written in, just to get you employed.
In addition, you should cover the four major programming paradigms:
imperative, object-oriented, functional, and logic. It is more important to
deepen your understanding of one of these paradigms than to pick up another
language. Once you understand all of these paradigms, you should be able to
quickly pick up whatever language you need to get your job done.

As you can see, I definitely favor depth over breadth. The utility of breadth
is mostly in knowing that there are topics out there that other people know
much more about than you do, and you should defer to their opinions (and in
choosing something to specialize in if you're unsure). But many intro classes
will probably leave students with an inflated impression with their
competence. This is particularly dangerous in cryptography, which is so easy
to screw up that even experts do so on a regular basis; if you're not an
expert, you shouldn't even try.

------
tiryns
Ruslan! Yesterday I was going through your how to build a simple interpreter
tutorial, as well as looking through the posted link to see where I need to
polish my skills. Crazy coincidence.

------
tiryns
Ruslan! I was reading your how to build a simple intepreter tutorial, and I
looked at this link yesterday. Crazy coincidence

------
austincheney
I am a self-taught developer. After spending years in the corporate world
working along side CS graduates here are the skills I see as missing from CS
education:

* Writing skills. It is absolutely important that developers be able to communicate needs and requirements with precision and specificity. I always recommend that developers spend more time with their QA staff as the experts next door. Good QA people are excellent, I am mean absolutely astounding, communicators with a very deep understanding of the product.

* Structure versus composition. So many developers really want the world to be simple AND easy. There appears to be some false expectation that programming is like putting lego pieces together, and when this isn't the reality they are utterly lost. Instead developers need to have beat into their heads that code is more like a thought structure. Part of this comes from developing reading/writing skills and part of it comes from an appreciation that logic and abstractions aren't static qualities.

* Reading code. I often see junior developers struggling with how to write code. This is the vast majority of programming related topics I see online. There is a lot of insecurity around this and many developers first try to solve for the insecurity opposed to actually writing original code. This means that instead of taking a risk on writing original code developers will cost themselves in comfort blankets of tools, frameworks, dependencies, and layers of configurations. These insecurities are better solved from building comfort directly through an appreciation of reading code (RTFC).

* Technology diversity. Most developers I have worked with either get into stuff like robotics, or IoT, or simply remain hopelessly isolated to writing code in their primary domain. Most developers who isolate themselves to the code have no idea what is really happening in technology whether its security, networking, hardware, storage, or whatever. The really sad part is that many developers falsely believe themselves to have some expertise or advanced understanding of these non-coding concepts when its very clear, to people in that line of work, the developers have almost no practical experience there (spinning their wheels). As an example I have seen numerous comments here on HN where developers will downvote, into oblivion, networking or security focused comments that defy common understanding of application coding despite never having touched a switch, router, or any sort of security vulnerability assessment/resolution.

* Product management. More often than not developers are writing code in support of some software product. I often see many developers in pursuit of qualities completely opposed to the desires of the end users or the business that pays the bills. Sometimes these erroneous intentions are due to pursuit of _easy_ , sometimes its due to an imaginary understanding of what people want, and sometimes its due to a false or incomplete understanding of the technology. No matter the reason developer focused intentions are generally bad.

* Data structures. Not having a computer science background myself I have always imagined that data structures are a core component of a good CS education. I am frequently reminded of how wrong this thinking actually is.

\---

I also see developers often spending amazing amounts of energy focused on
qualities that aren't helpful to their careers or the products they support.
The following is a wishlist of what many developers wished they learned from
their education that simply isn't helpful.

* Frameworks. A framework is an application serving the purpose of architecture in a box. Sometimes a framework is abused because its either completely unnecessary or because a developer is using it to solve all of the world's problems. A framework isn't going to do your job for you or get you promoted. It is just a tool. Sometimes original code really is better.

* Testing. Test automation is important. A good set of tests reduce risks of regression and demonstrates appropriate handling of various features used in unexpected ways. Many developers often test for all the wrong things. Tests are tech debt. Tests are not an excuse to avoid reading code. When in doubt about what to test sit down and have a very precise conversation with your QA people.

* Design patterns. Memorizing patterns is never helpful and is sometimes harmful. Instead solve the problem any way possible, even if inefficiently. Then refactor that solution over time to achieve better performance and superior simplicity. Through that process of continuous improvement you will unexpectedly learn design patterns.

------
rronalddas
Currently, I think dockerfile are more omnipresent than makefiles

------
bibbitybobbity
Your website isn't secured with a certificate, FYI

------
nezzor
”Every engineer should know” -> ”All of statistics”

------
JustSomeNobody
Whew! Good thing I took the easy route and got a Computer Engineering (BSCpE)
degree.

/s

------
codesushi42
I would add a Statistics or Applied Math co-major, or even a Master's degree.
Being able to analyze data is becoming a must have skill.

