A collection of things software developers should know
github.com
github.com
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.
If you are happy and fulfilled programming all day, go for it, program all day. Personally I would also encourage you to at least try and pursue some other interests because experiencing new things is fun & exciting, but if you're happy that's what's most important.
But many of us, especially those of us in the United States, live in a culture where we can be expected to think of our work as our life. A culture where we are encouraged to memorize CPU cache fetch times rather than picking up a novel, going to a museum or spending time with family. When we say "get a life" most of us are arguing against that culture, not telling you how to enjoy your time.
I'm not saying that is the intended reading here. Nor, that such a reading is charitable.
One of the things I assume when I writing on HN is that I can go back an edit what I wrote to make it better. "Don't forget to live life," might better express the idea. Finishing with "Get a life" after showing the overall intent might better express the sentiment.
Leading with "Get a life" means the reader reads with only their existing context and can reasonably apply standard connotation. It is normally a bullying phrase, and an author ought to expect it to be taken as such without doing a lot of additional work. It is no surprise that it puts people off.
Suppose the author's response to people being put off by the advice "get a life," is something like "well, that's their problem." That's exactly the connotation of dehumanization "get a life" has in US culture and a charitable reading is unwarranted.
I assume the phrase was used here in the most generous sense but that's often not how it will be received. I think it's more constructive to avoid the phrase and to express the sentiment in other ways.
Experience has taught me don't get caught up and lose that balance. Its a long journey to recovery after you have suffered both emotionally and physically.
IT going mainstream made life a bit easier for us - if you say you're a programmer, people no longer roll their eyes. But that's not because geeky/nerdy lifestyle is more accepted now. It isn't. If I say to my cow-orkers that I code a lot after work, most will be looking at me like a weirdo just as much as my classmates did when I was in secondary school. People who care about technology on an intellectual level - not just on a money-making level, or shiny-trinket level, are still rare and still treated as the weird ones.
As more nerdy and ambitious people, we are the weird ones. Programming in your free time might get slightly weirder looks than participating in local theater or something but I think some of the scorn you perceive is residual from the hostile environment that existed for nerds in grade school and high school. After that people still think you're weird but generally don't care that much, they're busy watching TV & taking care of their kids.
Oh well, it is not for everyone. :-)
For the general population, yes. If you are willing to move, there are companies where you can get coworkers that don't roll their eyes.
Also, assuming positive intent will get you far in life, especially on forums like this.
My bet, though, is that often enough people who are absorbed in their work also enjoy other things. I've seen plenty of posts on HN regarding going for a walk to think and clear his/her mind.
I'm a free software hacker and activist. I'm also a professional programmer. My life outside of work is how I described myself in the first sentence of this paragraph, and I'm unhappy with how _little_ time I have to devote to it. These are things that are fundamental to my identity, so saying "get a life" when talking about what makes me me is telling me that the life I chose isn't one worthy of choosing.
Again, I'm not confident that this was the oldandtired's intent with those comments, but I think there's an important perspective to consider. The username is also suggestive. :)
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.
"Get a life" has always at least had a negative undercurrent, and is often an overt insult implying that one's entire lifestyle is unworthy, and inferior to mainstream lifestyles.
I suppose GP meant "work-life balance", but for some of us, code is more part of "life" than of "work".
I work from home and so get to spend time with my kids and have a pretty chill time, but everything I do, is calculated towards solving that next problem.
E.g.when I'm stuck on a problem, I go play with my kids to rest and passively process it.
To me, this is a pretty chill life. This is what a "life" means to me.
Traditionally, people's careers have always been their lives. Blacksmiths, farmers etc, why can't it be now?
It is a very extreme position to say that there is literally nothing which can be generalised about people's experiences, and so one person's heroin main-lining hobby is as good as another's model railway collection so long as they both profess an equal belief in their respective enjoyment.
There must be something more than this that we can say, since we have the distilled thoughts of millennia of some of the most capable humans thinking about these questions (what makes a good life) and lots of case histories of how people's lives have gone.
This is different from judging someone's moral worth or probity or what have you, and I think it is harmful to gloss over the distinction because it creates a kind of skeptical collapse.
This might be what the prior comment means to indicate by getting a life - that we should each individually research this question and not presume we've got a good answer already. If it is what they meant, I agree that their phrasing was unskillful.
This is what many of us had to (usually unsuccessfully) argue to our colleagues (and family members!) during school years, so if a full-blown dismissal of "get a life" phrase is a knee-jerk reaction, it's unfortunately a well trained one.
We are comfortable perceiving other species' limitations, even directly perceiving how their behavior or evolution will be their downfall, but we're not particularly good at analyzing ourselves in this way, and its owing to, rather than in spite of, moral constraints, themselves varying from demographic to demographic, so that ultimately the question becomes "_Which kind_ of human should propagate?" For Aristole, only slave-owners could practice virtue, materially and cognitively (though today, epigenitics would tell us there isn't as much of a distinction here as one would wish, or the recent literature indicating IQ drops the _longer_ one is poor as well; Aristotle ultimately had an idea of this as well, but treated of it separately in On the Soul).
So if you love your work, great. If you were to get hit by a bus tomorrow with no regrets, great. But if you were to do this work for the next 3 years, THEN get hit by a bus, and wish you had done something else with those 3 years... that signals that you might need some changes.
Despite the unfortunate redaction, I guess the parent is telling that if you find yourself chasing this kind of highs very often, you probably are basing your life on shitty values like "being right all the time".
> If I enjoy xyz, who are you to judge me for that?
I find this (common) sentiment troubling and frankly a bit arrogant.
Whether or not you enjoy something is not always good metric for said thing's long term effects on your life.
Other people have experienced different things than you and may have some really good insights. Assuming you know exactly what's best strikes me as arrogant. Judgement and ostracization, while often misused, are effective tools for a society to encourage beneficial behaviours.
Conforming behaviours. Not beneficial. One could argue that conforming to mainstream is beneficial for the society, though I personally don't buy it - if you look at what the average of human interests is, it's all pretty petty. If we were all stuck at the lowest common denominator, I'm not sure if we would get far as a civilization.
Now, one good argument I've heard for following the "mainstream wisdom" on "getting a life" is regret - i.e. that if you won't live a life in a particular way (lots of social interactions, focusing on a spouse and kids, etc.) you'll regret that on your deathbed. I'm still relatively young (in the lower half of my expected lifespan), so I might be wrong about it, but I don't buy that argument either. I've come to the conclusion that regret will happen anyway - people basically regret what they didn't do. If I focus on cranking out widgets, I'll regret not spending time with the kids. If I focus on my family, I'll regret not doing anything actually useful with my life. Etc.
Bottom-line: I think that currently, the pendulum is still too far on the conforming side.
Everyone should definately recieve input on how they're living their lives. Some input may not be valuable, but unilaterally dismissing it is hubris.
I'm not arguing for some extreme where people are stoned in the streets. Just that you should entertain some feedback from society.
For example: I was eating lunch outside and staring at my phone the whole time. An older lady came up and said that I should put my phone away, slow down, and just enjoy the weather/my lunch. I gave it some thought and decided that she was right. Now I conciously try to use meals as a true break and it's been refreshing. Valuable input.
Another example: I was out on a rainy day. I was wearing a JHU raincoat (had for $3 from a clearance rack) + boat shoes and someone said I should be careful about what I wear lest people think I'm "white priviledged".
Personally, I think that's bullshit, but I was still respectful. I probably won't be taking their advice, but their input might actually be valuable.
But isn't this the very definition of judging"?
When people say "get a life", they are implicitly saying that you current life isn't up to measure (by their own values).
Any psychologist with a rudamentary understanding of what is required for a healthy mind.
(not a psychologist myself)
> 5. You're as much the idiot as the person you consider an idiot.
I don't throw the word "idiot" around lightly but when I do, in a work / programming context, it's apt. I'd imagine I'm not the only one in that camp.
1. Everyone is ignorant of something, so don't be condescending.
2. Everyone does stupid things, including you, but it doesn't make them stupid.
3. Everyone has their own incentives, which may or may not be aligned with yours or the organization you work at. Understanding them helps you understand their point of view, and to decide whether to help them, ignore them or fight them.
Focus on the needs and look for multiple strategies to meet them, thus staying open and flexible in the implementation.
Are you implying there is more to life than programming?
If not, then I'm out of ideas.
Happiness, Health, Money, Marriage, Kids
would be the correct order to process these tasks? Without the previous item(s), the latter item is harder to obtain and maintain at full functionality.
A better list is probably:
Stability, Contentment, Kids.
When your situation is stable and you're content with how things are going, then consider kids. Don't try to wait until you're rich / happy all the time, it won't work.
I meant "happiness" more as the opposite of "pain and despair". If you are not in a place mentally to have a partner and children, don't do it.
Same with "health". If you aren't healthy, either by circumstance or by choice, you probably aren't ready for a partner or kids.
"Money" is relative. I really mean, if you have enough resources to provide for more than yourself. If you can't provide anything for a relationship, or kids, you aren't ready.
You could draw this as concentric rings of self-control, and only once you are in control of the inner ring, can you progress to outer rings.
You must control your mind, body, environment, relationships, and offspring. If you lose control of one of the inner rings, then you cannot control the outer rings.
Don't wait is true. Than again, don't get married to someone you can't stand just to have kids.
I have dealt with various people over the years who are very intelligent and very expert in their fields of endeavour, yet will treat you as a idiot if you don't comport yourself with a total respect for their opinions and viewpoints. If you raise a question that they believe is irrelevant, their responses head rapidly south to treating you as an idiot.
1. I have been programming for nearly 40 years, even though I now care full time for my wife, I still create and modify various programs nearly every day. I am a geek, but talking with people (especially the young, including my children, my grandchildren and my nephews and nieces) opens my eyes to different wonderful perspectives. Learn new things every day, and share with people every day, it's a wonderful way of living. As well as that, there is a cultural difference between the US and other places. Get a life is about rounding out as a person. Programming is but one small aspect of our lives as people. As a geek talking with my geek nephews we often talk about geek things, but our conversation get quite broad. I suppose the one thing I am glad about is that none of my children became programmers.
I have a high functioning autistic grandson. His younger sister and brother have no such problems. Watching them and seeing them grow is an incredible, delightful and wonderful experience. Seeing my grandson in operation has opened my eyes to who I am and the slight autism that I have. I see him look at the world in a light that is so unique. I have seen and shared in other autistic children lives over the years and the universe is a more wonderful place for them being in it. So when you go and get a life, see the unique, wondrous world around us, especially in the people whose lives you interact with.
2. After nearly forty years programming, arrogance (I am very specific about using that word) is an occupational hazard for all programmers. We often forget that we really don't know everything. Good ideas come from all sorts of places. Been there, done that and have watched so many go down the same path.
3. There are many different programming "religious" wars. Many times each side has a valid point that can be used in conjunction with each other. So keep learning new languages and their basic concepts to see what is useful to you as a programmer. Understanding different conceptual bases often will give an insight in how to solve problems at hand.
4 Pretty self explanatory.
5. I thought this one was self explanatory as well, but, here goes. It doesn't matter how much knowledge you have in a specific area, if you start treating people as imbeciles and idiots for their lack of knowledge or the "silly" (are far as you're concerned) questions they ask, you have become very much what you consider them to be. In reality, we know little, and it should be fun to share our knowledge and in turn share in the viewpoints of others. This was a lesson I have had to learn a number of times over many years. There are no "silly" questions.
6. How many of you over your time of programming have had "critical" deadlines to meet which were no more critical than the specific coffee blend you have in morning? There are many who believe their project is of a "critical/important/world shattering" nature and yet if it misses by weeks or even months or never even reached completion, the world still goes on. You do what you can, you don't kill yourself over inconsequential things.
[Have made an edit to slightly more comprehensible]
You might program in C on Linux. You might game on an xbox. You might have tried Rust or Go and think they're pretty groovy. You might have an iphone.
None of these are a part of your ego. They aren't a part of your image. You don't need to feel attacked if someone criticizes, rightly or wrongly, your choices.
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".
For example why is it important that every programmer knows about SEO?
If you don't know list you won't know when that is the right solution. I have seen many people just use a SQLite DB for something as simple as a 20 item list.
> 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!
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.
Don't think anyone can commit all of these guides to memory but a very nice reference.
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.
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...
[2] http://loup-vaillant.fr/articles/rolling-your-own-crypto
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.
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.
> 40. People have names.
Good luck getting names right.
So if you take these to heart, even a tiny weekend project will take near infinite time to handle all of these cases.
It would require infinite space, every possible supported character set, a massive fuzzy-logic search engine, etc.
Humans handle complexity by avoiding it until it becomes a pressing need. The first pass at understanding is always an oversimplified model. Usually we make additional passes, hopefully with progressively more nuanced and educated models.
Knowing that your system will run into problems in the future is sometimes enough. Deferring problems until they are actually significant business impacts is a reasonable strategy.
This applies to "Falsehoods Programmers Believe About {Names, Addresses, Phone Numbers, etc}".
A "tiny weekend project" assumes, by definition, a tiny userbase. The point is to assume nothing about a dataset, because even dozens of seemingly reasonable expectations about names are wrong.
The point of the article is not to tell you to immediately write perfect code, but to make you aware of your code's limitations.
In the real world, you'll constantly have to interact with external or internal systems that are based on the "wrong" concept, so implementing it "right" makes your system really awkward to work with.
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.
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.
Right now it's "Every Programmer Combined Should Know"
But who still post that Heinline monologue about how specialization is for insects.
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.
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".
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.
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.)
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!
0. don't touch with a barge pole articles about "things that software developers should know"
I know about SWEBOK, freely downloadable from IEEE. Anything else? Books about SWE have pretty bad ratings, what's the bible of SWE?
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.
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."
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.
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.
Under the "Books" section I would add Sci-Hub and Library Genesis.
Agree.
We'd be better served by a decision tree.
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.
Some interesting salary stats here, was surprised to see Seattle stand out with an average salary adjusted to the cost of living.
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.
To me the title is a click-bait and the document doesn't encourage me to actually "know this things".
This is more like a list of things from someone's bookmarks.
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...