
A collection of things software developers should know - mr_mig
https://github.com/mr-mig/every-programmer-should-know
======
oldandtired
This is what every programmer should know:

1\. Life is too short, so get a life.

2\. Know that you don't know everything, so get don't arrogant.

3\. Don't get caught up in the various programming "religious" wars, there's
more to life than a specific point of view.

4\. Laugh and enjoy the the wonderful beauty in the world around us.

5\. You're as much the idiot as the person you consider an idiot.

6\. Sometimes the "important things" one is working on are just not that
important, so get a life.

~~~
ATsch
I find that saying the phrase "get a life" to people that enjoy what they are
doing is extremely condescending. If I enjoy programming all day, or having
huge flame wars, or maintaining a huge collection of antique watering cans
sorted by volume, then who are you to judge me for that?

~~~
kraftman
I'm not OP but I took it as 'get a life [outside of work]', i.e. don't get
bogged down in the crazy 100-hour work weeks and stressing about climbing
corporate ladders if it's not what you enjoy.

What you do with your free time is up to you, it's just a reminder that it's
your free time not your companies.

~~~
wruza
Your quoting style is simply depressing.

~~~
kraftman
I'm so sorry.

------
rsp1984
The title of this should be:

 _Links for SW developers to look things up if needed_

The claim that SW developers should _know_ all of these things is plain
ridiculous. I'd consider myself a fairly successful hacker (sold my small
startup to BigTecCo and worked there for a while, licensed them some other
code, now working on my own startup again). And I'd say I know perhaps 10% of
what's on this list and I have a basic (not very detailed) understanding of
maybe 40% more. The other 50% I have no idea about.

However I do know a fair amount of stuff (in detail!) related to my field
that's NOT on this list and that's what sets me apart.

So bottom line: Use these lists to look things up. Specialize in what you like
until you're really good at it. Be open to learn new things. But don't let
anyone tell you that you do need to _know_ all this stuff before you're a
"real software engineer".

------
lawn
Statements like "every programmer" are bad as they usually mean "every low
level programmer" or "every web programmer" or similar.

For example why is it important that _every_ programmer knows about SEO?

~~~
domlebo70
It's not meant to be taken literally.

~~~
afarrell
There's no indication of that, so how do you know?

~~~
oddlyaromatic
>These are resources I can recommend to every programmer regardless of their
skill level or tech stack

> Highly opinionated . Not backed by science.

This kind of indicated that to me, at least. Also the format of the title is
just inherently daft and a rhetorical device that summarizes the kind of list
it is. Like "things to do before you die", or "ten things you won't believe
Michael Jordan sat on".

We all have our own version of this list in our heads. This person just
published theirs.

Also it says:

>P.S. You don't need to know all of that by heart to be a programmer. But
knowing the stuff will help you become better!

------
lambdas
Stay humble. You don't know as much as you think you do. That's the takeaway
from these IMO.

Don't think anyone can commit all of these guides to memory but a very nice
reference.

~~~
pamqzl
> Stay humble. You don't know as much as you think you do.

The other related takeaway I got from this is that programming looks _very_
different from other corners of it.

Some things that one programmer thinks are required knowledge will be seen as
completely obscure minutiae by someone else, and vice versa. For instance,
this list seems to think I need to know about SEO, and "falsehoods about
names", but I've never in my career had to deal with search engines or even
names at all. The terrain looks very very different from where I'm standing...
which just reminds me that I don't have a bird's eye view.

------
bitshift955
Very glad to see "Falsehoods Programmers Believe About Names" included in this
list [1]. I still struggle to always get this right.

One thing I'd suggest including is something about not rolling your own crypto
in the security section. Does anyone know a canonical article for this? I've
got [2] bookmarked but not sure if a guide with the pitfalls of designing your
own crypto scheme is right for this list.

[1] [http://www.kalzumeus.com/2010/06/17/falsehoods-
programmers-b...](http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-
believe-about-names/)

[2] [http://loup-vaillant.fr/articles/rolling-your-own-crypto](http://loup-
vaillant.fr/articles/rolling-your-own-crypto)

~~~
dqv
>I still struggle to always get this right.

I really like the FHIR Human Name data type[0]. It requires none of the
fields... so it can represent someone without a name. It also has all the
necessary fields for representing someone's name and their name in various
forms and pretty much as many edge cases as possible.

The only problem is turning it into a UI that makes sense.

[0]:
[https://www.hl7.org/fhir/datatypes.html#HumanName](https://www.hl7.org/fhir/datatypes.html#HumanName)

~~~
mberger
May I ask where you work that you work with FHIR?

~~~
dqv
I was helping someone with an appointment reminders implementation. I was
googling how to communicate with practice management systems, came upon HL7,
and then FHIR.

I don't do anything "real" with FHIR at my company, I just borrow concepts
because FHIR does a pretty good job at encapsulating the healthcare domain.

------
Aardwolf
Missing topic: version control

Obviously also missing is programming languages and e.g. good recommended
books/links for each, but I understand that it's meant to be language-agnostic
so listing any particular one would not work.

~~~
FanaHOVA
You don't need version control if you know Homoglyphs obviously.

------
fridek
I hope this list stays brief. Every list so far I observed was eventually
bloated to hundreds of items (useful or not) by helpful pull requests.

~~~
bryanrasmussen
it's already too bloated, some are things every systems programmer should
know, the SEO is things every web programmer should know. The embedded
programmers don't need to know it, really. Hardly any programmer needs to know
the RegexHQ one, they can look that stuff up if needed.

~~~
andai
I guess they should have done an AND instead of an OR?

Right now it's "Every Programmer _Combined_ Should Know"

~~~
bryanrasmussen
Right, there are things that every programmer ANDED should know, but those are
few.

~~~
bryanrasmussen
And at that level of generality it could probably be pruned slightly more for
a list of things that everybody who manages programmers or is a programmer
should know.

------
weego
Every programmer should know cpu cache read time? How many times is this going
to come up. Barely anyone in the world needs to know that.

~~~
icebraining
I don't think it's that useful to know specific numbers, but knowing the
orders of magnitude is important when you're writing anything even somewhat
CPU intensive. It helps you understand why certain patterns of code are
slower.

------
leoharsha2
These are the other things that a developer should know -

1- Focus on the problem and not the tools ceremony around it. 2-Don't follow
the herd and the hype. When given a problem, keep drilling the problem until
it is absolutely clear to you and then only work on solution.

Meta-habit: learn to adopt different habits for different situations. With
that in mind, some techniques I've found useful for various situations:

When developing for yourself or a small team, let problems accumulate and fix
them all at once (or throw out the code base and start anew). When developing
for a large team, never let problems accumulate; the code base should always
be in a state where a new developer could look at it and say "I know what this
does and how to change it." This is a consequence of the reader:writer ratio -
startup code is written a lot more than it is read and so readability matters
little, but mature code is read much more than it is written. (Switching to
the latter culture when you need to develop like the former to get users &
funding & stay alive is left as an exercise for the reader.)

~~~
HeroOfAges
_2-Don 't follow the herd and the hype. When given a problem, keep drilling
the problem until it is absolutely clear to you and then only work on
solution_

This is one of the most frustrating things I've had to deal with when
developing with a team. No one wants to take the time to think about a problem
before working on a solution. Almost always, the people I work with would
rather spend weeks coding than spend a few hours thinking about the problem,
just so they can present a solution "first". It drives me crazy!

------
sAbakumoff
I have the ultimate version that works really well:

0\. don't touch with a barge pole articles about "things that software
developers should know"

------
l0b0
It is trivial to find both categories of programmers who do not require all of
these (such as embedded systems developers) and things which are not mentioned
at the top level but should be (such as version control systems). How about
"Links for Programmers like Me"? One more word, but much more accurate.

------
blub
What list is based on "science" or at least empirical evidence? Once one has a
certain amount of experience, these opinion-based guidelines seem pointless,
insufficient and tiresome.

I know about SWEBOK, freely downloadable from IEEE. Anything else? Books about
SWE have pretty bad ratings, what's the bible of SWE?

------
iainmerrick
So the "things" here are links to various articles and essays. Some of them I
recognize and there are definitely some good ones in there (like Fred Brooks'
"No Silver Bullet").

This kind of list would be much more useful with more careful curation. Rather
than just giving me 100 links in broad categories, write a sentence or two
about why each article is worth reading. Maybe pick 10 or 20 articles to
showcase, rather than 50 or 100.

------
fiokoden
I almost entirely differ in thinking these are important to know.

------
jonsen
Every programmer should know what they don't know.

~~~
the-dude
Deep

------
intellectronica
Every Programmer Should Know LISP

~~~
wruza
Why the hell is that "get a life" at the top instead of this?

~~~
sideshowb
Because this one got downvoted by the Haskell fanatics

------
lobster_johnson
Some of the points about phone numbers also apply to email addresses.

For example, as has been shown repeatedly, most email validation patterns are
simply wrong, and are best trimmed down to something like /^[^\s]+@[^\s]+$/.

Arguably more useful than a text-based email validation is validating whether
the domain part has a valid MX. This will guard against many typos.

Another less-obvious fact that people eventually come to realize is that
emails don't last for ever. I run a site where people constantly contact
support about being unable to log in, because their email address is no longer
active, and they forgot their password. (Some of them even forgot what their
user name was.) It turns out many people use their work or school email, and
that this email ceases to work after they leave. It's a good idea to regularly
ask people whether their email is still valid.

All of the above could easily be bundled as a SaaS service. We use Mailgun for
email address validation and for reading bounces (so we can alert users that
their email is no longer working, in case they're stilled logged in), but a
high-level, all-in-one service could be useful.

------
chasd00
#1 is stay humble. If you're humble you will never stop striving and learning
to get better. By the way, that's probably the most important thing for
everyone, not just software developers.

Whenever I think i'm hot shit I go watch some SpaceX videos on YouTube. That
gets my feet back on the ground and my nose to the grindstone pretty quickly
heh.

------
auggierose
It's always nice to have these lists. Not because you should take them
terribly serious, but because you might discover unknown (as opposed to known)
gaps in your knowledge.

Under the "Books" section I would add Sci-Hub and Library Genesis.

------
sdiepend
There are too many goddamn lists. You want to be a programmer? Good! Google
for courses and just pick what you want or need to get the job done.

~~~
amelius
> There are too many goddamn lists.

Agree.

We'd be better served by a decision tree.

------
jimktrains2
Complete aside: I've been working on a "book" (quotes because I'm sure I'll
never finish it :-\\) That is designed to help provide vocabulary and ideas
for breaking down problems. The book will contain no programming, and part 1
won't get into anything like "how to sort" or "different ways of constructing
a tree". The idea, especially in part 1 is breaking down problems and
solutions, not how to implement those solutions. Part 2 provides more
information on implementation and analyzing algorithms, but still not the
actual implementation.

[http://jimkeener.com/pdfs/aptb-book-
toc-44e1b61.pdf](http://jimkeener.com/pdfs/aptb-book-toc-44e1b61.pdf) is the
current table of contents. It feels a little disheveled in places. I'm still
working out some of the structure, but I'd say 95% of the final sections are
there, and maybe 85% are in the correct relative positions (at least in part
1). I'm also going to be trying the following parts mirror part 1 in structure
as much as possible.

Right now it's a GFDL license, but it's not yet public. I'm still debating if
there is a better libre license, but one that would allow it to be physically
published as well.

------
nnd
> [https://www.codementor.io/blog/best-cities-software-
> engineer...](https://www.codementor.io/blog/best-cities-software-engineer-
> earnings-271vpf599k)

Some interesting salary stats here, was surprised to see Seattle stand out
with an average salary adjusted to the cost of living.

------
agentultra
There's also the SWEBOK [0] guide which is a useful document that attempts to
catalog what other engineering disciplines refer to as, _the state of the
art_.

[0] [https://www.computer.org/web/swebok](https://www.computer.org/web/swebok)

------
staticelf
Seems like a really bad headline for otherwise a good list of links to
subjects that may be interesting to read about as a programmer.

I can't say I know even 50% of the things on that list and I have managed to
get a good life from my programming skills so far so I think I am good.

------
ktta
Also, 'What every computer science major should know' by Matt Might:

[http://matt.might.net/articles/what-cs-majors-should-
know/](http://matt.might.net/articles/what-cs-majors-should-know/)

------
blumomo
I don't see how this list differentiates a good programmer who "knows" those
"things" from other good programmers who don't.

To me the title is a click-bait and the document doesn't encourage me to
actually "know this things".

------
mythrwy
What if you don't deal with names or email addresses as a programmer? Do you
still need to know those "falsehoods"?

This is more like a list of things from someone's bookmarks.

------
dsjoerg
A collection of what specialists think generalists should know

------
_pmf_
> and may in fact be a symptom of deeper string-validation issues

It may also be a sign that there's a very early filtering stage that drops
request at a very remote edge, which is a very good thing to do. See [0];
basically, you configure your server to completely drop requests that contain
any character that has any possibility of being suspicious.

[0]
[http://twiki.org/p/pub/Support/ConfigureFailsOnNext/mod_secu...](http://twiki.org/p/pub/Support/ConfigureFailsOnNext/mod_security.conf)

~~~
andai
I think you meant to post in a different thread?

~~~
icebraining
It's a response to the "Big List of Naughty Strings" article, liked from the
Every Programmer Should Know List.

------
viach
Good thing the collection is short enough, otherwise I wouldn't be able to get
to the bottom with the list of advertised services.

------
lolive
Anyone with a good resource on "function composition" should add it to the
list.

------
corpMaverick
You don't really need to know all of these. But the list is great.

------
Witosso
Do you know any similar repo for a QA \ Software tester?

------
wolco
There is only one thing a programmer should know. How to program with some
language. Everything else is variable.

------
saikatsg
Nice post!

------
biggiejr
nice one

