Absolutely. This kind of list isn't the price to entry.
Toward the middle of your career you should have a reasonable understanding of roughly what's in all of those and why someone cared to write them down, and be able to know when to consult them. And you will know at least a few of them very well.
I'm a little surprised by the answers in "Cryptographic Right Answers". Both libsodium and Chacha20-Poly1305 are not FIPS-compliant. "AES-GCM" is but it has important gotchas in regards to the IV and per key data volume. "AES-GCM-SIV" is more resilient but "AES-GCM-SIV" isn't FIPS compliant either but there is a proposal underway to certify it. So the cryptographic right answer is "it depends". FIPS compliance may not matter to some people but it does a lot to others depending on the context.
I think the safe answer is AES-GCM using envelope encryption?
If you use libsodium, its very hard to screw up your encryption. If you use AES-GCM, it sounds at least like you can screw it up. Surely you'd want to use the first one?
Totally agree with you on this but I think in some settings FIPS-compliance is a requirement -- especially anything to do with the Federal government. The obvious fix is for FIPS to catch up but until then the three choices the document listed aren't great. The first two don't meet the requirements and the last choice, as you've pointed out, can be a bit of a foot gun. I wonder if AES-CBC-HMAC (i.e. Fernet) should be listed as a choice for FIPS? Like keep the original 3 and then have a sub-heading: FIPS-compliant: AES-CBC-HMAC or AES-CTR-HMAC like it did originally.
That list is geared towards developers who don't have a strong background in cryptography and helping them choose a secure algorithm that is easy to implement. Because if you get it wrong, more vulnerabilities will be introduced.
Working around janky compliance standards is a whole separate topic.
Also remember: Even though many of these articles/books/papers/etc. are good, even great, some of them are starting to get a bit old. When reading them, check what modern commentators are saying about them.
E.g.:
What every programmer should know about memory (18 years old) [1]
How much of ‘What Every Programmer Should Know About Memory’ is still valid? (13 years old) [2]
While i cannot comment on the specifics u listed i dont think the fundamentals have changed much concerning memory. Always good to have something more digestible though.
Not every developer needs to know about all of these things. I'd take this more as a "list of interesting details related to common things you might depend on", it's akin to suggesting that doctors of specific specialties (dermatologist) should know about random things that are part of other specialties (proctologist).
Of all the things I’ve seen with emoji at the beginning or end of sentences, none of them are training readers for children and most of them are material by and for adults.
I second this. I feel very strongly that we have to do our best to make technical things more accessible to more people, but this trend of adding emojis to these readmes is just infantilizing. A lot of the content is interesting enough on its own, no need to candy-coat it.
My contrasting advice is that you should use the problems you're facing as opportunities to learn and practice the wider competencies that will allow you to gradually take on bigger and more interesting problems.
You will eventually encounter each and every item on that list, and some. Software engineering is a learning grind till the end. The projects will dictate the skills needed for it to be successful. The difficulty is that you won't be given time to learn any knowledge gaps.
If you are starting your career and panic reading such list, that would take years to learn, if even. Don't worry.
Most of these items are more like nice to know than should know.
Yeah it would be great if every software developer knew everything. But I doubt even the repository owner know all that is listed.
My best advice to newcomers is get your hands dirty and stay away from endless hours of courses, YouTube videos and "awesome lists".
Absolutely. This kind of list isn't the price to entry.
Toward the middle of your career you should have a reasonable understanding of roughly what's in all of those and why someone cared to write them down, and be able to know when to consult them. And you will know at least a few of them very well.
The repository owner does not know everything, and has already forgotten many things he used to know from the list
But it’s a distilled and curated list of the resources I’ve found important to have at hand and revisit periodically
That's nice and all except the title is misleading and discouraging to new devs. I would even put a disclaimer on top of fixing the title.
But I guess it wouldn't be clickbaity then.
There is a disclaimer, but not very clear I guess
I'm a little surprised by the answers in "Cryptographic Right Answers". Both libsodium and Chacha20-Poly1305 are not FIPS-compliant. "AES-GCM" is but it has important gotchas in regards to the IV and per key data volume. "AES-GCM-SIV" is more resilient but "AES-GCM-SIV" isn't FIPS compliant either but there is a proposal underway to certify it. So the cryptographic right answer is "it depends". FIPS compliance may not matter to some people but it does a lot to others depending on the context.
I think the safe answer is AES-GCM using envelope encryption?
If you use libsodium, its very hard to screw up your encryption. If you use AES-GCM, it sounds at least like you can screw it up. Surely you'd want to use the first one?
Totally agree with you on this but I think in some settings FIPS-compliance is a requirement -- especially anything to do with the Federal government. The obvious fix is for FIPS to catch up but until then the three choices the document listed aren't great. The first two don't meet the requirements and the last choice, as you've pointed out, can be a bit of a foot gun. I wonder if AES-CBC-HMAC (i.e. Fernet) should be listed as a choice for FIPS? Like keep the original 3 and then have a sub-heading: FIPS-compliant: AES-CBC-HMAC or AES-CTR-HMAC like it did originally.
That list is geared towards developers who don't have a strong background in cryptography and helping them choose a secure algorithm that is easy to implement. Because if you get it wrong, more vulnerabilities will be introduced.
Working around janky compliance standards is a whole separate topic.
:) Soon to be renamed to "a historical collection of things every software developer had to know about."
Will start with "software used to be..."
Very nice list... I do wonder how much money the author/contributors make by having Tuple's ad at the top of this popular readme file.
It’s a time-bounded experiment with sponsorship (3 months) and it earned me roughly a 1 month rent (before tax)
thank you for the transparency in your comment.
I spent some time looking into prices, and there are repos that have a tiered system with sponsorship
The top tier is 1000$/m sponsorship , for which you get a larger size of the company logo showed on top of the repo
Also remember: Even though many of these articles/books/papers/etc. are good, even great, some of them are starting to get a bit old. When reading them, check what modern commentators are saying about them.
E.g.: What every programmer should know about memory (18 years old) [1]
How much of ‘What Every Programmer Should Know About Memory’ is still valid? (13 years old) [2]
[1]: https://lwn.net/Articles/250967/
[2]: https://stackoverflow.com/questions/8126311/how-much-of-what...
While i cannot comment on the specifics u listed i dont think the fundamentals have changed much concerning memory. Always good to have something more digestible though.
A better title would have been "junior dev compiles collection of his favorite links".
And adds an ad.
[1] https://github.com/mtdvio/every-programmer-should-know/commi...
You are mostly right
The random use of emojis tells me this was written by an LLM. If it's not worth your time to write a list it's probably not worth my time to read
It was written in 2017. If it was written by an LLM in 2017, I would be already quite rich
Author here.
Accepting both constructive criticism and personal insults
Not every developer needs to know about all of these things. I'd take this more as a "list of interesting details related to common things you might depend on", it's akin to suggesting that doctors of specific specialties (dermatologist) should know about random things that are part of other specialties (proctologist).
Clever ad.
Can we pleeeeeeease stop putting emoji in the middle or end of sentences like this was a 6-year-old's training reader?
Any time I see a sentence end in that strong-arm emoji my douchebag-o-meter goes way way up.
Of all the things I’ve seen with emoji at the beginning or end of sentences, none of them are training readers for children and most of them are material by and for adults.
A lot of early-reading children's books embed pictures in the sentences. It helps kids learn the meaning of words or something.
Probably not. I think it's the beginning of a major language evolution.
Hieroglyphics comes full circle.
Thistle bee ace.
I dont mind them when they are not cringy. Arm flex is cringy.
I will replace it with almost anything you want. Pick your option
¯\_(ツ)_/¯
I think the cat is out of the bag on this one. I await the return of ascii art though.
I second this. I feel very strongly that we have to do our best to make technical things more accessible to more people, but this trend of adding emojis to these readmes is just infantilizing. A lot of the content is interesting enough on its own, no need to candy-coat it.
You should know only what you need to know to solve a problem.
My contrasting advice is that you should use the problems you're facing as opportunities to learn and practice the wider competencies that will allow you to gradually take on bigger and more interesting problems.
Tangentially, am I the only one left on the planet who abhors watching videos in order to consume information?
It has been a nightmare watching the world’s information migrate over to YouTube when it used to be quickly digestible text formats.
You are not the only one. I have a lot of people around me whom I coach who prefers info to be in a text form
Would you prefer to have transcripts for those videos in the repo?
You will eventually encounter each and every item on that list, and some. Software engineering is a learning grind till the end. The projects will dictate the skills needed for it to be successful. The difficulty is that you won't be given time to learn any knowledge gaps.
I laughed at timezones
> How to Win Friends and Influence People
really? in 2025?
Yes. Have you read it?
Indeed and I regret wasting time on it. I thought people would be a little more clued in about dale carnegie's work by now.
You would be surprised how many people out there in Tech find value in that book then
[flagged]
Please make your substantive points without name-calling. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.