9 ms·
A collection of things software developers should know
- fridek 9y agoI 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 9y agoit'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 9y agoI guess they should have done an AND instead of an OR? Right now it's "Every Programmer Combined Should Know"
- bryanrasmussen 9y agoRight, there are things that every programmer ANDED should know, but those are few.
- bryanrasmussen 9y agoAnd 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.
- loudo 9y agoThat's because the people who make them don't know what pedagogy is. This is lazy pedagogy. It's like leaving a kid at a library instead of at a school. Why do we have schools and teachers, when libraries with big lists of things to read have existed for hundreds of year? If you want the answer to that spend a year or two looking at what good pedagogy is preferably with someone who is highly skilled at it.
- afarrell 9y agoThere are loads of people who don't actually know how to efficiently cut the loin from a pig, tack against the wind, or ensure proper close air support while bringing even a few thousand soldiers into territory held by an enemy force... But who still post that Heinline monologue about how specialization is for insects.
- carlmr 9y agoHeinlein's quote I think is not to be taken too literally. It's the notion that human beings can do so many things and there's a lot of synergy in knowing that many things. You'll start seeing connections between one and the other and solve problems in activity A while doing activity B. It's fun too! I might not know how to butcher a pig, but I know multiple programming languages, multiple human languages, I ski, I climb, I skate, I ride bikes. I can cook foods from cuisines from all over the world. I read books on things I haven't formally studied. Life is just more interesting if you're not a one trick insect.
- afarrell 9y ago> not to be taken too literally Sure, but it doesn't help you actually decide where the line is between "things which I should focus on learning" and "things which are massive skills that it would take many years to learn and I shouldn't bother." My biggest problem here is with "learn how to plan an invasion".
- rootw0rm 9y agoYou could probably butcher a pig. It's not rocket surgery.
- fiokoden 9y agoI almost entirely differ in thinking these are important to know.
- jonsen 9y agoEvery programmer should know what they don't know.
- the-dude 9y agoDeep
- bitshift955 9y agoVery 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-believe-about-names/ http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b... [2] http://loup-vaillant.fr/articles/rolling-your-own-crypto http://loup-vaillant.fr/articles/rolling-your-own-crypto
- bs71721 9y ago"Not rolling your own crypto" originally meant "do not design your own new algorithms without peer review". It is a pointless HN meme to apply this to implementing crypto (ok, the C haters here won't have a clue, but that is a given).
- dqv 9y ago>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 9y agoMay I ask where you work that you work with FHIR?
- dqv 9y agoI 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.
- lambdas 9y agoStay 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 9y ago> 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.
- lawn 9y agoStatements 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?
- halloij 9y agoIt's a clickbait title. Should be changed... Sure, it's an interesting list, but no. Not every programmer needs or would want to know.
- domlebo70 9y agoIt's not meant to be taken literally.
- ship_it 9y agoIt shouldn't be advertised like that.
- afarrell 9y agoThere's no indication of that, so how do you know?
- oddlyaromatic 9y ago>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!
- andai 9y agoSEO is largely about understanding how people think and phrase their questions. If you're ever going to write something and want other people to read it, they typically have to find it first. Even if the person has already found your project or your docs, following SEO principles will make them easier to navigate. Here I'm referring to the "stuff people type into search boxes" aspect of SEO, not the "dirty tricks" aspect.
- weego 9y agoEvery 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 9y agoI 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.
- wasted_intel 9y agoThis made me laugh. Thanks. :)
- skummetmaelk 9y agoProgrammers don't actually have to know how computers work either, but sometimes it comes in handy.
- zengid 9y agoI sense a bit of humor in your comment, but none the less its worth learning. In the end, the CPU is the actual machine that runs the code. It's good to have an idea about how it works because it clears away a lot of the smoke and mirrors that abstract VMs use in defining their behavior.
- hackermailman 9y agoBiggest game changer in terms of my skills as a developer was learning to write cache friendly code ie: principal of locality/locality of reference. Even within the confines of the JVM https://www.reddit.com/r/scala/comments/6hlpbn/techniques_for_locality_of_reference_in_scalajvm/ https://www.reddit.com/r/scala/comments/6hlpbn/techniques_fo...
- lolive 9y agoAnyone with a good resource on "function composition" should add it to the list.
- _pmf_ 9y ago> 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_security.conf http://twiki.org/p/pub/Support/ConfigureFailsOnNext/mod_secu...
- andai 9y agoI think you meant to post in a different thread?
- icebraining 9y agoIt's a response to the "Big List of Naughty Strings" article, liked from the Every Programmer Should Know List.
- intellectronica 9y agoEvery Programmer Should Know LISP
- wruza 9y agoWhy the hell is that "get a life" at the top instead of this?
- sideshowb 9y agoBecause this one got downvoted by the Haskell fanatics
- kazinator 9y agoI disagree; every programmer should definitely know a Lisp; and a bit about LISP just for a historic perspective.
- deleted 9y ago[deleted]
- flavio81 9y ago> Every Programmer Should Know LISP Seriously, yes. Every programmer that wants to perform as high as possible, should grok Lisp, or a Lisp dialect. It makes sense, since they are "programmable programming languages."
- oldandtired 9y agoThis 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.
- nnd 9y ago> 1. Life is too short, so get a life. Are you implying there is more to life than programming?
- smikhanov 9y agoIt can't possibly be true that there is, so he probably doesn't
- Tade0 9y agoHe may be implying manual testing. If not, then I'm out of ideas.
- LoSboccacc 9y agoI've heard stories about the outernet but it's a weird imperfect place
- amrrs 9y agoThere's more to Life beyond Programming - [Marriage, Love, Kids] (not a sorted list)
- BatFastard 9y agoMy list in order Kids Health Happiness Money Marriage
- l0b0 9y agoIt 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 9y agoWhat 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?
- sdiepend 9y agoThere 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.
- auggierose 9y agoIt'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.
- staticelf 9y agoSeems 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.
- deleted 9y ago[deleted]
- viach 9y agoGood thing the collection is short enough, otherwise I wouldn't be able to get to the bottom with the list of advertised services.
- biggiejr 9y agonice one
- wolco 9y agoThere is only one thing a programmer should know. How to program with some language. Everything else is variable.
- dsjoerg 9y agoA collection of what specialists think generalists should know
- nnd 9y ago> https://www.codementor.io/blog/best-cities-software-engineer-earnings-271vpf599k https://www.codementor.io/blog/best-cities-software-engineer... Some interesting salary stats here, was surprised to see Seattle stand out with an average salary adjusted to the cost of living.
- jimktrains2 9y agoComplete 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.
- sAbakumoff 9y agoI have the ultimate version that works really well: 0. don't touch with a barge pole articles about "things that software developers should know"
- Aardwolf 9y agoMissing 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.
- ktta 9y agoAlso, '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/
- rsp1984 9y agoThe 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".
- leoharsha2 9y agoThese 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 9y ago2-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!
- chasd00 9y ago#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.
- agentultra 9y agoThere'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
- Witosso 9y agoDo you know any similar repo for a QA \ Software tester?
- iainmerrick 9y agoSo 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.
- corpMaverick 9y agoYou don't really need to know all of these. But the list is great.
- saikatsg 9y agoNice post!
- lobster_johnson 9y agoSome 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.
- deleted 9y ago[deleted]
- blumomo 9y agoI 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 9y agoWhat 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.