Hacker News new | past | comments | ask | show | jobs | submit login
A collection of things software developers should know (github.com/mr-mig)
589 points by mr_mig on Sept 5, 2017 | hide | past | favorite | 165 comments



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.


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?


My guess is in this case the original commenter means "get a life" if you feel pressured to only think about programming or work.

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.


If this is how it was meant, perhaps a different phrase would have conveyed OPs opinion better. For me, "get a life" is strongly associated with "douchey jock" behaviour, bullying, nerd-shaming (is that word a thing? it is now) and phrases like "you like math? what a nerd, get a girlfriend bro", things I'm sure many people on HN have had to deal with.


When I'm reading HN I assume the commenters are at least somewhat similar to myself until I have evidence to think otherwise. The culture here is neither anti-intellectual nor anti-math. Given that we're on HN I'd say it's safe to assume no one is telling you to quit coding or stop caring about math. On this forum issues around workaholism and burn out come up all the time, "getting a life" is a step toward not burning out.


In the US, the specific phrase 'get a life' carries the connotation of contempt for the persons to which it is offered as advice (typically unsolicited). In normal use, it is an insult that dismisses everything about a person. It isn't just used against nerds, it is also aimed at people who are doing some menial job or at a person who is complaining about some bad behavior imposed upon them by someone who tends to get away with such things.

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.


Yes, the particular phase "get a life!" was used against nerds, Trekkies, by William Shatner in a Saturday Night Live sketch [0]. It wasn't a new gag, but it raised the fandom's profile into the mainstream and it's often been repeated (e.g. on The Simpsons in Comic Book Guy and his cohort).

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.

[0] http://snltranscripts.jt.org/86/86hgetalife.phtml


It was in common usage where and when I grew up several years before Shatner on SNL. Whether my youth was at the forefront or not I don't know...but now that I have a teenager I know that many phrases he uses and thinks are new go back (at least) several decades to when I was the same age.


[flagged]


That was an explanation, not a reaction.


Right. People from all over the world read and write comments on Hacker News. It's a big and diverse audience where not everyone is a native English speaker let alone an American in Silicon Valley. That's part of what makes commenting fun, interesting, and challenging...at least for me.

Based on the rest of the comment, I don't think a charitable reading is unwarranted. But that does not mean someone's negative reaction is unwarranted either. "Get a life" can be and is used as 'fighting words.'


While I agree with you in principle. I think the original poster's intent was keeping a work life balance. Work will consume you. Corporations will consume your life. You may be perfectly happy living in your work, but if you have loved ones they will suffer.

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.


As a person who lived through this as a kid, I want to express my strong support for your comment, and provide +1 data point.

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.


Honestly most things people are uniquely passionate about that take work outside of your workplace will get you equal or nearly equal weird looks. A lot of people want to go to work to make money and come home to watch TV. I worked for Obama for America in 2008 and spent months walking door to door in Indiana, most people went to to work, took care of their kids and watched TV. And didn't want to spend time doing much else.

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.


Yeah, when I say that I do code as a hobby so I spent some free time on it, a reaction I get quite often from coworkers is: "I already code at work". Or "I would rather spent my time having fun".

Oh well, it is not for everyone. :-)


> 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.

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.


I mostly disagree—it's quite common to have intellectual interest in technology. It simply requires a lot of sacrifice in terms of social life to fit in with your career.

Also, assuming positive intent will get you far in life, especially on forums like this.


The phrase "get a life" could make me feel that way, as well. As I age, though, I see the shortness of life more clearly. There is the distinct possibility that someone who enjoys programming 80 hours/week will in the future realize he/she devoted all of his/her time to work and never took a spin through the other aspects of life.

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.


Suck it nerd! Get a life! (kidding, seriously) As others have said, this HN, everyone here needs to "get a life"


I agree; I found this comment, while probable well-meaning, very condescending. It seems to approach programming as something one does only for work, or as something that's an impediment for a more meaningful life.

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. :)


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.


It probably would have been better worded as "Work to live, but don't live to work. Don't make your job your whole life."

"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.


Your quoting style is simply depressing.


I'm so sorry.


It's the preferred method in Python.


The problem is until you try something new you can't be sure you really enjoy what you're doing that much. After 15 years of sitting in a chair and doing what I loved I found out I love other things just as much and I'm sad I didn't know earlier.


I'm seconding this reading and I'd like to remind everyone that for many here, programming is still an intellectually stimulating experience first and a job second, if at all. Not all code - especially not the interesting one - is made at work.

I suppose GP meant "work-life balance", but for some of us, code is more part of "life" than of "work".


For one thing, I do know my life revolves around programming.

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?


I thought I was happy just programming all day and night for probably half of my life. I didn't realize that people need normal light-hearted social interaction and occasional rest and relaxation for our health, both physical and mental. It cost me a great deal to learn this lesson and I hope to spare anyone else from learning it the hard way.


I think there's a case to be made that it is possible to judge whether people's behaviours are helping them to enjoy their lives to the best extent.

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.


I agree there's a case to be made. There's a strong case to be made. In fact, those of us who heard "get a life" shot at them probably made that case many time. The case is this: someone's hobby of tourism / enjoying cars / writing stories / riding horses / all kinds of sports / engaging in gossips and interpersonal dramas / whatever else mainstream does is at least as valid of a lifestyle as my hobby of geeking out about spaceships and writing code for fun.

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.


Pleasure and pain equally enable a self-satisfaction one might term 'happiness', like the pleasure of consistently demeaning oneself when one finds oneself frustrated by life because demeaning _others_ is pleasurable.

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).


But don't you really have a secret unfulfilled desire to sit in a dimly lit, extremely noisy, crowded bar, sipping overpriced alcohol while yelling platitudes at people you kind of know?


Every time I hear 'get a life' it's from people that fill their time partying.


You're getting bent out of shape from a harmless common refrain to the general HN readership - not you - in a well-meaning context? Yeah, get a life.


I tend to avoid this particular flame war by encouraging people to define their own personal goals in life and make sure their work is driving towards those goals. The bad place to be is to be giving away all your time and energy to work for someone else's goals, in hopes of a big payout so that some future day you can works towards your own goals.

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.


Exactly. I interpret "get a life" to mean, don't defer living and happiness, indefinitely, however you define them.


"Being right" gives you a high - that is why flame wars can be so addictive. Like cocaine it may give you instant gratification and pleasure but in the end it is not worth.

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".


Yeah, Im trying to be more conscious of this, I love that cheap high. It's a formula for being an asshole, unfortunately.


Not trying to offend, but . . .

> 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.


> 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.


I wasn't commenting on the particular issue. I was merely saying that "who are you to judge me?" is a peer in society. Our lives are interconnected to varying degrees and your life will definately affect others.

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.


> Whether or not you enjoy something is not always good metric for said thing's long term effects on your life.

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).


I think you're agreeing with the post to which you're replying.


For someone that loves algorithmic challenges, I am sure knowing about phone numbers is going to make them ecstatic.


If you "have a life" you would not be offended by such a comment as you would have a work/life balance and thusly "gotten the life", this is projection in the extreme


Only if you're looking for it.


> then who are you to judge me

Any psychologist with a rudamentary understanding of what is required for a healthy mind.

(not a psychologist myself)


Psychologists don't judge. They only try to help you if something is a problem for you personally.


Well.... I hate to tell you, psychologists judge, they just refrain from exposing their jusgement to their clientele. Psychologists, like doctors and police, are still human. Warts and all. But I get the sentiment and, like those same said psychologists, should probably have kept my opinion for me and my drinking friends =)


While I agree with the rest, this one is flat out wrong:

> 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.


My personal version is this:

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.


I'd add:

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.


4. All actions are strategies to meet basic human needs. Look for the needs behind the actions. This will bring effortless understanding and compassion.

Focus on the needs and look for multiple strategies to meet them, thus staying open and flexible in the implementation.


Agreed, there are some people who deserve the term idiot. At the same time you're probably an idiot if you call people idiots, even if they are. You're going to make your own life harder.


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

Are you implying there is more to life than programming?


It can't possibly be true that there is, so he probably doesn't


He may be implying manual testing.

If not, then I'm out of ideas.


I've heard stories about the outernet but it's a weird imperfect place


There's more to Life beyond Programming - [Marriage, Love, Kids] (not a sorted list)


My list in order Kids Health Happiness Money Marriage


Really? It would seem that:

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.


Be careful with that. There's a growing body of evidence that waiting too long to have children causes some disorders. EG Autism is far more common in children born to older parents. Money is an especially difficult one, as it's very easy to move your own goal continually upward. Happiness is also difficult, since it's almost always going to be a transient state and not a long-term thing.

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 wasn't really meaning the As-Seen-On-TV "rich and happy".

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.


Well said. Though I not longer have the illusion of control. You must manage your mind, body, environment, etc.


There is no good list for everyone... Personally, "stability" is antithetical to my contentment


Stability is relative. Contentment and kids are an oxymoron.

Don't wait is true. Than again, don't get married to someone you can't stand just to have kids.


The mvp of reproductive success lol.


I learned the hard way that my own health comes first even to my kids. I had a kidney stone episode that really put me out of my mind. The pain was so bad I could not think on anything but to survive. I couldn't even remember I had a family in the first place. So my health comes first, if it deteriorates, all the external world goes away.


friends and/or a membership in a community can be nice too, and is one of those "often correlates highly with happiness" kinda things, so i'm just adding specificity from my life to an item in your list.


One can write a nice version in a couple hours.


5a. There are some genuinely shitty people out there that don't necessarily deserve a pass just because no one is perfect and everyone makes mistakes. Dealing with such situations can be exceptionally difficult. Avoid talking shit if possible but try not to be apathetic either (for your own sake as well as others').


7. 'Dilbert' is a documentary.


And, arguably most importantly - 7. If you see a skunk, just slowly cross the road to the other side.


Here it would be, if you see a tiger snake, run like hell.


I'm unable to think of any definition for the word "idiot" that would make number 5 generally true. "Human" doesn't work. "Imperfect" is closer, but still doesn't quite work since almost everybody readily admits that already. It's certainly not true that everybody is equally incompetent. Nor is everyone equally rude, or equally impulsive, or equally stubborn.


See my explanation above. I have learned the hard way to recognise that though there are obtuse and pigheaded people who will not listen to anything you say and are extremely difficult to deal with, don't for a minute ever treat them as an idiot.

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.


Oh, I agree wholeheartedly with never treating anybody "like an idiot."


You don't need to know everything to be arrogant; you just need to know one complete way to build a system from the ground up and have an implementation to show it. At that point, everything which you don't know is unnecessary and the conditions are set for a vigorous arrogance to flourish.


Very much like How Naval talks - https://news.ycombinator.com/item?id=13905251 (previously on HN)


I have had some fun reading the responses. So I'll add some commentary to my list.

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]


Thank you for sharing that. If you write an article, I will add a link to the list


This post has extra meaning when one looks at your nickname! I am with you, we are dealing with too much unnecessary stuff.


5: no. Sometimes an idiot is an idiot and if you have a real one in the team, sanity requires either of you change job


How's the activity on your public github profile? Contributions to open source projects? How often do you voluntarily mentor others? What other programming do you do in your spare time? You better eat and breathe code, trends, frameworks, because there will be no other food and air... and the salary will be USD 40k max anually, because the country you live in is cheap (we've just checked on Numbeo).


are you a programmer or a manager?


Submit a PR adding this to a "meta" section?


Getting to the source of #3, another piece of advice is to never define yourself, or your ego, by the things you use.

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.


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".


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?


The same about all the stuff regarding equity and stock options. Currently looks like a list about what every web developer that works for funded startups should know.


I find that learning how to work with list is like having a crescent wrench in your tool box. Not every tool box have one but I sure think they should.

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.


Yep, I guess you really didnt read that article :D The List in the title is not the datatype ...


I did the other guy didn't :)


It's not meant to be taken literally.


It shouldn't be advertised like that.


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


>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!


SEO 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.


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.


> 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.


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...

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


>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


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


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.


I consider the names article more a thought experiment. Consider the last point:

> 40. People have names.

Good luck getting names right.


> Falsehoods Programmers Believe About Names

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}".


> even a tiny weekend project will take near infinite time to handle all of these cases.

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.


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

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.


The same was true about Unicode text not too long ago. If we don't start trying to do things correctly, we will never get to a better place.


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.


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


Yeah but Version Control is absolutely a must.


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.


That'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.


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.


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

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


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


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.


There 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.


Heinlein'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.


> 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".


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.


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.


Biggest 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_fo...


Programmers don't actually have to know how computers work either, but sometimes it comes in handy.


I 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.


This made me laugh. Thanks. :)


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.)


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!


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"


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.


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?


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.


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


Every programmer should know what they don't know.


Deep


Every Programmer Should Know LISP


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


Because this one got downvoted by the Haskell fanatics


> 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."


I disagree; every programmer should definitely know a Lisp; and a bit about LISP just for a historic perspective.


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.


#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.


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.


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.


> There are too many goddamn lists.

Agree.

We'd be better served by a decision tree.


Could you please put this in a list form so that I can start following it? /s


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 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.


> 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.


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


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.


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

http://matt.might.net/articles/what-cs-majors-should-know/


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".


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.


A collection of what specialists think generalists should know


> 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...


I think you meant to post in a different thread?


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


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


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


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


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


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


Nice post!


nice one




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: