I feel like I have read most of these in a piecemeal fashion, but seeing all these articles together like this really drives home the importance of paying attention to the basics. Great collection; thanks for sharing!
All of these are great resources. Just as "Falsehoods programmers believe about names" they are howevere not resources every programmer needs to read (though they may of course benefit from it).
And honestly, a lot of "falsehoods" are really just nitpicking. I mean yes, you may once in your lifetime encounter a user with a real name longer than 2048 characters (or wherever you've set your limit) but really, if those are your biggest problems you're in a really good position :)
It is usually the simpler issues that bite you when internationalizing. The separation of first and last names don't always work outside the anglosphere (and sometimes even within it). Some users have 5/6 part names etc etc.
Why not? While there are lots of terrible SEO consultants and stupid recommendations, knowing how SEO actually works and the way it rewards good, up-to-date content, is incredibly valuable. And knowing how things really work is the best way to defeat the crummy suggestions and gimmicks that a misinformed marketer might suggest.
I'm just assuming here, but I think the parent commenter was referring to the fact that not every programmer needs to know SEO, since there are several disciplines that don't depend on search engine results.
When the article title includes the words "every programmer", that's a really large set of programmers. I don't think a programmer working on embedded systems needs to know about SEO, nor do kernel hackers, nor do scientific programmers...
Oh, the engineer marketing moto: make a good product and customers will come. So appealing and so false!
I'm not doubting your experience, but this is such a common misconception that I must point it out.
If usage of your product is not what puts food on the table, by all means go for the engineering marketing approach. It's genuine.
If you need customers to have a roof on top of your head, though, learn marketing. It's not evil, it is necessary, and strange as it may seem, it is as important to success as product quality.
I think he means if your website contains information google can find it. simple as that. only thing you really need to know is that text on its own is more easily searched than images. but that should be obvious to any one.
A very large number of programmers spend their time working on non-web code for companies. I don't need SEO at all... that's what our marketing department is for.
The title should have been "10 Articles Every Java Web Developer Should Read," and even then a few of them would be out of place.
The implication in my post was that this was for a pet project where you are the marketing team and things like choosing a good project name that's actually searchable matter.
Otherwise you end up with things called "Go" and "Ruby", both of which took years to become googlable.
SEO tactics and practices change so rapidly... almost any article or book written about SEO is outdated by the time it's released (unfortunately). Tactics that were considered "best practices" even 6 months ago may actually harm your site these days. -- There is no magic bullet for SEO.
I realize this is going to come as something of a shock to you, but most of the programmers in the world aren't cool kids working at the Next Big web startup. SEO isn't part of their world, never will be, and SEO consultants never come knocking at their door.
At least, if you're a programmer and need to learn a little about SEO, this is a decent article. Most information on this topic are in slideshow format, with only broad bullet points. This one is pretty text heavy and information dense, which I appreciate.
The list is heavily weighted to implementation details. I'd include a few essays like "The Rise of Worse is Better" (http://dreamsongs.com/RiseOfWorseIsBetter.html) to encourage programmers to take a step back and think about design and architecture more often.
I would argue that every programmer should be at least exposed to some assembly, so you can understand (and appreciate) a little more about how the computer actually does what it does.
if we're adding "philosophy of programming" essays, i'm a huge fan of james hague's "Slumming with BASIC Programmers" [http://prog21.dadgum.com/21.html]. it's a small post, but i personally found and continue to find it very thought-provoking.
Sorry, no. If you are doing your accounting in floating point, you are setting yourself up for really strange non-balancing balance sheets. You can do everything in fixed point.
Remember that fixed point does not mean the point is at the rightmost position. It means it is in a fixed position.
Of course, yes. But the naive people will start using FP math - so they have to be warned as early as possible.
I'm doing all my math in fixed point (eurocent), but that has its drawbacks too if you deal with VAT and have to hit a specific total price given only a VAT rate and a net price... or if you're dealing with gas pumps and that x.xx9 cheating. Or scales, where the law requires more precision...
Sure, but not at the ultra low level that the article linked goes into. The article comes at it from an approach that if you're building (for example) scientific software then you need a deep understanding of how rounding will be performed so that the results are correct.
Don't get me wrong, understanding FP representation and arithmetic is useful for web developers, but the comment was on that actual article that was linked which goes into it in a level of depth that most web developers won't ever really need to dive into.
Can anyone provide some good reads on the replaying leap second concept? Has anyone ever taken advantage of this? How do projects that rely on subsecond accuracy and syncronization resolve the issue?
There should also be an article about how every programmer should write without too many grammatical errors. Some of the emails I used to receive were borderline incomprehensible and I'd have to go battle it out in person.
If you actually read the letter you can see that it also applies to modern programming and not just to "goto". Its truly a timeless article that everyone should read (and its really short!)
"Numbers every programmer should know"- Probably the most interesting part of that article is the slider. As you move it up and down, you can see how all the different things get faster over time.
... Except for the final one, "Packet Roundtrip". Networks have reached a physical limit of the universe, the speed of light.
It's worth noting that the full explanation given here assumes that the many-worlds interpretation is correct, which not all physicists would agree with. But the "no-communication theorem" is true independently of which interpretation of QM you adopt.
This is a non-relativistic description. The correct relativistic description assigns quantum field operators to events in spacetime, and operators at spacelike separated events commute--i.e., they give the same results regardless of which order they occur in. So there is no physical fact of the matter about the order in which the particles "change state".
Perhaps we can back up a bit. The first reading I used to assign to my students back when I was teaching lower-level classes (I'm a C.S. prof.) is "On Following Rules" by Kirit Saelensminde.[1]
It's a quick, easy read. It makes a point that is important and not hard to understand, but that is often missed. And it provides a framework for dealing with the concepts you get from all those other articles you're supposed to read.
Another way to think about it is that if someone doesn't understand a rule, then they are subject to the rule. If they do understand it, then the rule is subject to them.
Kirit is saying that, in the latter case (and only in that case) they get to decide whether to follow it.
One reason your idea works is that, in the first case, they don't get to assume that others are also subject to the rule.
This article "How to write shared libraries"[1] also from Ulrich Drepper should be added to the list. At least for C/C++ Programmers.
1 - http://www.akkadia.org/drepper/dsohowto.pdf
Link broken. Should be http://www.akkadia.org/drepper/dsohowto.pdf
Done! thanks
Good list. I would add "Falsehoods Programmers Believe About Names"[1].
[1] http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...
http://wiesmann.codiferes.net/wordpress/?p=15187&lang=en
Falsehoods programmers believe about geography
http://www.mjt.me.uk/posts/falsehoods-programmers-believe-ab...
Falsehoods programmers believe about addresses
http://www.cscyphers.com/blog/2012/06/28/falsehoods-programm...
Falsehoods programmers believe about gender
http://erratasec.blogspot.com/2012/06/falsehoods-programmers...
Falsehoods programmers believe about networks
http://pozorvlak.livejournal.com/174763.html
Falsehoods programmers believe about build systems
http://infiniteundo.com/post/25326999628/falsehoods-programm...
Falsehoods programmers believe about time
http://butgrace.com/2012/06/19/more-falsehoods-programmers-b...
More falsehoods programmers believe about time
I feel like I have read most of these in a piecemeal fashion, but seeing all these articles together like this really drives home the importance of paying attention to the basics. Great collection; thanks for sharing!
So many lists. And so many good additions by people in the comments.
There should be a github repo and site that lists everything so additions can be managed.
All of these are great resources. Just as "Falsehoods programmers believe about names" they are howevere not resources every programmer needs to read (though they may of course benefit from it).
And honestly, a lot of "falsehoods" are really just nitpicking. I mean yes, you may once in your lifetime encounter a user with a real name longer than 2048 characters (or wherever you've set your limit) but really, if those are your biggest problems you're in a really good position :)
It is usually the simpler issues that bite you when internationalizing. The separation of first and last names don't always work outside the anglosphere (and sometimes even within it). Some users have 5/6 part names etc etc.
Yep, that was the one I thought was conspicuously missing.
"What every programmer should know about SEO"
Yeah, no.
Why not? While there are lots of terrible SEO consultants and stupid recommendations, knowing how SEO actually works and the way it rewards good, up-to-date content, is incredibly valuable. And knowing how things really work is the best way to defeat the crummy suggestions and gimmicks that a misinformed marketer might suggest.
I'm just assuming here, but I think the parent commenter was referring to the fact that not every programmer needs to know SEO, since there are several disciplines that don't depend on search engine results.
When the article title includes the words "every programmer", that's a really large set of programmers. I don't think a programmer working on embedded systems needs to know about SEO, nor do kernel hackers, nor do scientific programmers...
Until they want their sexy opensource library to be used by more than one person.
Make good enough library, keep the source valid and the persons will come.
I have never done any special SEO tricks and yet all my content is fairly high on the results.
SEO in general is quite useless in my opinion. Make the content good enough so that people want to visit the site! Don't trick people to come there.
Oh, the engineer marketing moto: make a good product and customers will come. So appealing and so false!
I'm not doubting your experience, but this is such a common misconception that I must point it out.
If usage of your product is not what puts food on the table, by all means go for the engineering marketing approach. It's genuine.
If you need customers to have a roof on top of your head, though, learn marketing. It's not evil, it is necessary, and strange as it may seem, it is as important to success as product quality.
I think he means if your website contains information google can find it. simple as that. only thing you really need to know is that text on its own is more easily searched than images. but that should be obvious to any one.
In those areas, SEO is going to have little to do with the uptake of their libraries.
A very large number of programmers spend their time working on non-web code for companies. I don't need SEO at all... that's what our marketing department is for.
The title should have been "10 Articles Every Java Web Developer Should Read," and even then a few of them would be out of place.
The implication in my post was that this was for a pet project where you are the marketing team and things like choosing a good project name that's actually searchable matter.
Otherwise you end up with things called "Go" and "Ruby", both of which took years to become googlable.
SEO tactics and practices change so rapidly... almost any article or book written about SEO is outdated by the time it's released (unfortunately). Tactics that were considered "best practices" even 6 months ago may actually harm your site these days. -- There is no magic bullet for SEO.
I realize this is going to come as something of a shock to you, but most of the programmers in the world aren't cool kids working at the Next Big web startup. SEO isn't part of their world, never will be, and SEO consultants never come knocking at their door.
At least, if you're a programmer and need to learn a little about SEO, this is a decent article. Most information on this topic are in slideshow format, with only broad bullet points. This one is pretty text heavy and information dense, which I appreciate.
Maybe front-end developers; but agreed, not every programmer should know SEO.
The list is heavily weighted to implementation details. I'd include a few essays like "The Rise of Worse is Better" (http://dreamsongs.com/RiseOfWorseIsBetter.html) to encourage programmers to take a step back and think about design and architecture more often.
+1 to this.
Maybe also the wonderful "Big Ball of Mud" essay:
http://www.laputan.org/mud/mud.html
I have to mess with the html to read the article because of the background..
On Chrome I use the Stylebot plugin because there are many sites that make it difficult to read their content.
I would argue that every programmer should be at least exposed to some assembly, so you can understand (and appreciate) a little more about how the computer actually does what it does.
A great (free!) ebook pdf is "Programming From The Ground Up" on the GNU site: http://download.savannah.gnu.org/releases/pgubook/
HOWTO: Be more productive http://www.aaronsw.com/weblog/productivity
On Being A Senior Engineer http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engi...
Ooh Aaron... :-(
if we're adding "philosophy of programming" essays, i'm a huge fan of james hague's "Slumming with BASIC Programmers" [http://prog21.dadgum.com/21.html]. it's a small post, but i personally found and continue to find it very thought-provoking.
10 Articles every web programmer should read. Personally, SEO has zero bearing on my work. Java is only relevant to a subset of developers.
I'd argue that the ones on memory, floating point arithmetic and games programming networking have little relevance for most web developers.
Floating point arithmetic is the only arithmetic if you're a web developer.
Any website dealing with any form of sales/money WILL have to deal with FP arithmetic problems sooner or later!
Sorry, no. If you are doing your accounting in floating point, you are setting yourself up for really strange non-balancing balance sheets. You can do everything in fixed point.
Remember that fixed point does not mean the point is at the rightmost position. It means it is in a fixed position.
Or do all of your math in cents. Then you've only got to worry about FP at the displayed end.
Of course, yes. But the naive people will start using FP math - so they have to be warned as early as possible.
I'm doing all my math in fixed point (eurocent), but that has its drawbacks too if you deal with VAT and have to hit a specific total price given only a VAT rate and a net price... or if you're dealing with gas pumps and that x.xx9 cheating. Or scales, where the law requires more precision...
Or do it as everyone else and actually use ints instead of floating points? I thought this was common knowledge by now...
And I just noted the wording made me look like an asshole, sorry.
Sure, but not at the ultra low level that the article linked goes into. The article comes at it from an approach that if you're building (for example) scientific software then you need a deep understanding of how rounding will be performed so that the results are correct.
Don't get me wrong, understanding FP representation and arithmetic is useful for web developers, but the comment was on that actual article that was linked which goes into it in a level of depth that most web developers won't ever really need to dive into.
SEO ???
hahahahaaha
Can anyone provide some good reads on the replaying leap second concept? Has anyone ever taken advantage of this? How do projects that rely on subsecond accuracy and syncronization resolve the issue?
edit: for anyone interested, there has never been a negative leap second (it's always been something like 23:59:59, 23:59:60, 00:00:00). see http://en.wikipedia.org/wiki/Network_Time_Protocol#Security_...
edit2: however, there are negative leap seconds in UNIX time. I wonder if there's a vulernability here? see http://en.wikipedia.org/wiki/Unix_time#Leap_seconds
There should also be an article about how every programmer should write without too many grammatical errors. Some of the emails I used to receive were borderline incomprehensible and I'd have to go battle it out in person.
GOTO Considered Harmful
http://www.u.arizona.edu/~rubinson/copyright_violations/Go_T...
If you actually read the letter you can see that it also applies to modern programming and not just to "goto". Its truly a timeless article that everyone should read (and its really short!)
One might argue that this classic article equally applies to callbacks.
You could read it as a manifesto for solutions to callback hell which do not mess up your program's state, such as reactive programming.
http://www.reactivemanifesto.org/
To really make something of the knowledge of memory & latency, an 11th article to get you thinking about how your program interacts with the cache:
http://research.scee.net/files/presentations/gcapaustralia09...
For every article you tell me I must read, I'll be happy to demand you read 10 articles of my choosing in return.
Ken Thompson's Turing Award Lecture: "Reflections on Trusting Trust"
http://cm.bell-labs.com/who/ken/trust.html
This is part of the reading list of Stanford's CS PhD qualification. http://seclab.stanford.edu/SecurityQual.html
"Numbers every programmer should know"- Probably the most interesting part of that article is the slider. As you move it up and down, you can see how all the different things get faster over time.
... Except for the final one, "Packet Roundtrip". Networks have reached a physical limit of the universe, the speed of light.
http://www.eecs.berkeley.edu/~rcs/research/interactive_laten...
There is no law that says that information can not travel faster than light is there? The law is just a out mass/energy.
On top of that I believe faster than light transfer of information has already been experimentally shown to exist.
Yes, there is. Information has to be carried by some form of mass/energy, so if mass/energy can't travel faster than light, neither can information.
No, it hasn't. If you're thinking of the CERN neutrino experiments a couple of years ago, that turned out to be an equipment error.
Hmmm... shouldn't two linked quantum particles change their state in sync, no matter the distance?
You can't transport information through quantum entanglement.
I don't think so; see: http://lesswrong.com/lw/q2/spooky_action_at_a_distance_the_n...
It's worth noting that the full explanation given here assumes that the many-worlds interpretation is correct, which not all physicists would agree with. But the "no-communication theorem" is true independently of which interpretation of QM you adopt.
This is a non-relativistic description. The correct relativistic description assigns quantum field operators to events in spacetime, and operators at spacelike separated events commute--i.e., they give the same results regardless of which order they occur in. So there is no physical fact of the matter about the order in which the particles "change state".
There was this[0] relevant post on HN a handful of days ago. [0] http://strilanc.com/quantum/2014/05/03/Storing-Bandwidth-wit...
No, there are still some areas where we can make gains, practical speeds are still below c.
Perhaps we can back up a bit. The first reading I used to assign to my students back when I was teaching lower-level classes (I'm a C.S. prof.) is "On Following Rules" by Kirit Saelensminde.[1]
It's a quick, easy read. It makes a point that is important and not hard to understand, but that is often missed. And it provides a framework for dealing with the concepts you get from all those other articles you're supposed to read.
[1] http://www.kirit.com/On%20following%20rules
I'd like to add a rule 3: Don't impose or evangelize rules you don't fully understand.
Good idea.
Another way to think about it is that if someone doesn't understand a rule, then they are subject to the rule. If they do understand it, then the rule is subject to them.
Kirit is saying that, in the latter case (and only in that case) they get to decide whether to follow it.
One reason your idea works is that, in the first case, they don't get to assume that others are also subject to the rule.