I take that statement to be aspirational. I can look at that list and stress about everything I don't know very well or I can look at it and think that there are so many opportunities for me to improve my knowledge.
Was hoping this would be a collection of resources like
- Falsehoods Programmers Believe About Names[0]
- Falsehoods programmers believe about addresses[1]
- Falsehoods programmers believe about time [2]
etc.
Was a bit disappointed to realize it is more standard foundational papers on various CS topics.
The problem with general statements with "every programmer should" is that programming has become such a diverse field that there are definitely things that not _every_ programmer will need. For example, as an embedded software developer, I would say that every programmer should know I2C/SPI, EEPROM/Flash, semaphores/mutexes, RTOS task scheduling strategies, assembly language, what a HAL is, etc (I don't see any of those on the list from my brief perusal). In my field, if you don't know any of those, you're going to have a tough time getting a job. But the reality is that most programmers don't need to know the majority of what I use day-to-day and I don't need to know some things they need like basic web UX practices or how to serve a terabyte of data that I'm sure is the absolute fundamental minimum required for certain other development positions.
I'm pretty sure given the enormity of the entire field of programming, the only things Every programmer should know are:
1. if and loops
2. Readability is very good. Comments help.
3. pointers/references vs values
I think these are the only things that are truly universally necessary to understand, whether you're writing assembly, for the web, for a game, or anything else that executes code.
Definitely agree. Coding is so different depending on the language and the field. I'd also add:
4. Version Control
I've onboarded some new grads, and was surprised to find they don't teach version control in college. Students generally picked it up on their own, but I'd kind of expect at least 5 min of the first lecture of CSCI 101 to be something like "here's git and here's why you need to use it".
With my Dev Concepts collection (12 books I'm writing), I'm taking a different approach. Instead of saying "developers absolutely have to know/do this" (which is often biased/opinionated/situational), I'm just explaining all the ideas/concepts/principles I can think of. That way, curious developers can explore and learn about things they didn't know existed (and might benefit from knowing or applying to their own context), or need to learn about to solve an issue they're facing.
It will take me quite a while to get where I want to be with this project, but I'm confident that a good chunk will be timeless; even if there are many moving parts in IT, there's a huge amount of pretty stable ideas/concepts.
Sorry (not sorry :p) for the shameless plug, but here's the link: https://dev-concepts.dev. I'd be thrilled to exchange ideas about this!
15 comments
[ 3.0 ms ] story [ 43.4 ms ] threadI take that statement to be aspirational. I can look at that list and stress about everything I don't know very well or I can look at it and think that there are so many opportunities for me to improve my knowledge.
You do not need to know this to be successful.
:wq
:q!
q [a-z] Some sequence of actions that you might want to automate q Now use the macro with @ and the letter you chose earlier
I used vim for longer than I care to admit without realizing macros are useful.
Was a bit disappointed to realize it is more standard foundational papers on various CS topics.
0. https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
1. https://www.mjt.me.uk/posts/falsehoods-programmers-believe-a...
2. https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...
1. if and loops
2. Readability is very good. Comments help.
3. pointers/references vs values
I think these are the only things that are truly universally necessary to understand, whether you're writing assembly, for the web, for a game, or anything else that executes code.
4. Version Control
I've onboarded some new grads, and was surprised to find they don't teach version control in college. Students generally picked it up on their own, but I'd kind of expect at least 5 min of the first lecture of CSCI 101 to be something like "here's git and here's why you need to use it".
If anyone wants such a reference, there's the "Missing Semester" which is all about practicum. Lecture 6 is on Git:
Lecture 6: Version Control (git) (2020) https://www.youtube.com/watch?v=2sjqTHE0zok
or how to post questions and copy answers posted on stackoverflow.com and make them fit in your own code.
I see a lot of comments on SO asking to tailor down the answer further for their exact problem.
It will take me quite a while to get where I want to be with this project, but I'm confident that a good chunk will be timeless; even if there are many moving parts in IT, there's a huge amount of pretty stable ideas/concepts.
Sorry (not sorry :p) for the shameless plug, but here's the link: https://dev-concepts.dev. I'd be thrilled to exchange ideas about this!