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.
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.
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.
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.
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.
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.
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.
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!)
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.
"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.
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".
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.
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?
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.
