HN Books @HNBooksMonth

It is not equivalent, but if someone has the time to read the list, I would recommend instead the reading of R. L. Glass "Facts and Fallacies of Software Engineering" [1].

[1] https://www.amazon.com/Facts-Fallacies-Software-Engineering-...

Hi,

If you want to be a generalist, you may want to learn things which are useful independently of the programming language.

Some books that would qualify in my opinion (as examples):

- Code Complete: A Practical Handbook of Software Construction, Second Edition by Steve McConnell

https://www.amazon.com/Code-Complete-Practical-Handbook-Cons...

- Facts and Fallacies of Software Engineering by Robert L. Glass

https://www.amazon.com/Facts-Fallacies-Software-Engineering-...

Learning the different approches taken by multiple programming languages is certainly useful. It may not be that much relevant which language it is unless you want a job specifically in that language.

I can't speak for Google but I guess it is more relevant how familiar you are with software development practices and general knowledge about architecture, design, testing, algorithms to name a few than a specific language.

Since no one has stated it, this looks like a rip-off of https://blog.codinghorror.com/rule-of-three/ (which comes from https://www.amazon.com/exec/obidos/ASIN/0321117425 ).

Of course there are many other places such as the mentioned C2: http://wiki.c2.com/?RuleOfThree , my point is just that the Erik authoritatively says he is postulating it, but it's already all around the internet.

⬐ erikbern

Author here. It's slightly embarrassing that this turns out to be an old idea – it wasn't my intent to rip it off. I'm fairly sure I must have seen it a long time ago and then forgot about its origin. In retrospect I probably should have googled it.

⬐ franciscop

I was just thinking about this last week because of that old CodingHorror post so I was quite surprised to see it here as a new idea. I was actually just expecting a link or two at the bottom of the article.

Also, I have misused rip-off here; I didn't mean to say you defrauded/cheated/stole anything, just that it's an old idea already going around. I apologize for incorrectly using this verb and accusing you of ripping off this idea.

⬐ brlewis

The article now mentions this at the bottom. I think if he were intentionally trying to rip it off he wouldn't have called it "rule of three" because that makes it too obvious. I think he just forgot having seen it.

It's kind of fortunate that it worked out this way; I like seeing people comment on a well-established idea as if it's newly postulated.

⬐ franciscop

Yes, I misused rip-off and now after a quick search I found that it has a much more negative meaning than I intended.

⬐ svat

Perhaps instead of "rip-off of" you meant "riff off of". :-)

  and how do you know the others solutions
  are really secure? Linux is going to get
  the most eyes, critics, scrutiny on this
  because is way more widely used ...

This is commonly known as the "given enough eyeballs" fallacy[1]. While it might help when more people have an opportunity to review security critical subsystems, a given OS' popularity certainly does not guarantee this. Heartbleed[2] is often cited as an exemplar for this very situation.

1 - http://www.amazon.com/Facts-Fallacies-Software-Engineering-R...

2 - https://en.wikipedia.org/wiki/Heartbleed

Facts and Fallacies of Software Engineering (http://www.amazon.com/Facts-Fallacies-Software-Engineering-R...). It may be starting to get a little dated, so it's hard to say that all the referenced research is still applicable in the same way. But it's a good antidote to a common problem everywhere I've worked: the idea that our team is in some way special or unique in a way that implies reasonable standards of software engineering practice don't apply. It's almost always part of a rationalization cycle that justifies the way things have always been done or some kind of Taylorist management practice.

No wonder I had a hard time finding that Glass book in Google, it's Robert Glass, not Phillip. http://www.amazon.co.uk/Facts-Fallacies-Software-Engineering...

⬐ lifeisstillgood

aargh - I keep doing that. Probably a dozen times over the past few years - it's the strangest thing. I now know more about a minimalist composers works than I ever expected to for a tone deaf Mozart fan.

To be fair to Jeff, he was quoting from "Facts and Fallacies of Software Engineering" by Robert Glass [0].

The two rules are very similar, and that's why I think they have the same 'theme'. In one we are talking about when to refactor and in the other when to create a library, but both are essentially the same idea. Don't spend time generalising something that might never be used again. Three existing uses is (apparently) a good heuristic for answering "When is something going to be reused lots?"

[0] http://www.amazon.com/exec/obidos/ASIN/0321117425/

please read this book:

http://www.amazon.com/Facts-Fallacies-Software-Engineering-R...

Greg Wilson did a book, which I did not enjoy, on this topic: http://shop.oreilly.com/product/9780596808303.do and a slideshow, which I recommend: http://www.slideshare.net/gvwilson/bits-of-evidence-2338367 .

My take is that there is much to learn from science about how to evaluate propositions regarding software engineering (most, but not all, of them are unsupported) but few new useful ideas.

Another reference along these lines: http://www.amazon.com/Facts-Fallacies-Software-Engineering-R...

Also, make sure to read tons about how programmers feel about business guys / managers, and figure out how not to be like those people. There's tons of advice out there, and there may even be some good advice in the most offensive rants. Read those rants, feel the pain of those programmers, and see the opportunity to improve yourself so you don't inflict similar pain.

Some possibly helpful resources which you may have already seen:

http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...

http://www.joelonsoftware.com/ (right sidebar has a ton of articles)

http://www.amazon.com/Facts-Fallacies-Software-Engineering-R...

⬐ SoftwareMaven

I think this is SO much more valuable for a biz founder than learning to code. Understanding the development process and developers is critical. On the other hand, knowing how to code is merely useful.

(Note: I differentiate "knowing how to code" from being a coder. One means I made it through Python for Dummies; the other means I have a history of making software and understand the issues around it. That is far more than useful.)

⬐ patrickk

Also, read Peopleware. It's an excellent book for anyone who has to manage technical teams.

http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...

Joel Spolsky mentions that every manager at Microsoft has to read it (I could be wrong on that, but a lot do read it apparently).

I've never been a fan of extended analogies as a way of explaining things. At some point you need to understand the subject for itself, and not in terms of something else.

That said I strongly second his point about the value of keeping designs simple. And I have an interesting piece of evidence in support of it.

I just read http://www.amazon.com/gp/product/0321117425?ie=UTF8&tag=... and one of the "facts" that Robert Glass brings up is that a 25% increase in requirements results in a 100% increase in software complexity.

I put "facts" in quotes because the claim is only supported by one study and I have lots of questions around how one would define key terms like "software complexity". However based on experience I am inclined towards believing that something like this is true. If you further believe (as I do), that the source of the requirements doesn't matter, then adding internal requirements about design is going to result in complications.

As a result I am inclined towards simple, clean designs. I gladly introduce polymorphism, abstraction layers, and so on fairly frequently. But only if I see a concrete benefit from doing so. If I am not convinced that this piece of abstraction produces a net win within the context of this software solution, I don't do it.

(For the record I am not a software master by any means. In Zed Shaw's terms I'd be an expert, although early mentoring with the right person kept me from ever suffering from the love of complexity that he pastes all experts with.)

Never meaningfully demonstrated? Have you tried to verify the claim?

Go read Peopleware. You will find described very carefully set up coding comparisons that routinely found a factor of 10 productivity difference between different experienced programmers on the same task, and also a discussion of what organizational factors lead to those productivity differences.

There is other research on the topic as well. For instance http://www.computer.org/portal/web/buildyourcareer/fa035?utm... cites "individual differences" research that found a 30 fold difference between mediocre programmers and the top programmers. That article is supposed to be a distillation of http://www.amazon.com/Facts-Fallacies-Software-Engineering-R... so I'd look there if you want citations into how that research was done and what exactly they found.

⬐ nostrademons

I thought the Peopleware claim was that some teams are 10x more productive than other teams. I could easily buy this, because it's very easy to generate more internal communication work than it produces, i.e. be negatively productive.

I'm not sure I buy it for individuals, except in the limiting case of someone completely not knowing what they're doing and having no idea where to start.

I guess it's also possible with the economist's definition of productivity ($$$/hour), since so many projects turn out to be commercial flops. But by that definition, startups and research are some of the least productive sectors of the economy, not the most.

⬐ btilly

No, Peopleware's research was on the productivity of individuals at different organizations. To be precise what they did is arranged a series of "coding wars" where multiple organizations would each select 2 individuals and all would code up solutions to the same problem in the language of their choice. People were asked to keep a log of what they did, and describe various things about their environment.

They found an order of 10 productivity difference that showed up under any of a number of possible measures. The also found that the best predictor of a given person's productivity was the productivity of the other person from the same organization. They also identified a number of workplace environment issues that were strongly correlated with productivity.

This overall picture comes with many caveats. Individual productivity differences were still quite significant. They didn't have any way to tell correlation versus causation. (To what extent does a better environment make programmers better, versus correlate with being able to hire and retain them?) The coding assignments were fairly small. So don't read too much into the result.

But given the size of the difference, and that it is one of the few attempts to quantify these issues, it isn't a result to take lightly either.

⬐ kingkongreveng_

Well, I just googled the peopleware citation and it seems the study backing this often repeated claim is from the 1960s and people have plenty of questions about its methodology.

I'll easily buy 2X or 3X productivity difference. I'm not buying these casually tossed off claims about 10X or 30X productivity differences without the supporting research discussed in detail front and center. Unacknowledged differences of that magnitude would imply a massive arbitrage opportunity that has persisted for many years. And that's just not realistic.

⬐ btilly

I don't know what you found through Google, but it was a bad description of the research cited in Peopleware. For a start the research they discuss was done in the 1980s, not the 1960s, and the methodology of their study was quite carefully done.

Read http://javatroopers.com/Peopleware.html#Chapter_8 for a much better overview of what Peopleware actually says. Of more interest than the productivity differences measured is the discussion of what factors were part of those productivity differences. Once you've read that, you may find the result much more believable. (There is a lot of detail in the book that is left out of the summary, but that's in the nature of what summaries are.)

⬐ sshumaker

I've experienced a 10x difference firsthand - and not against bad coders, but against average ones (they were former game developers, so they're quite possibly above average vs. the rest of the software industry). And you can slice the productivity along a bunch of different axes - systems designed and built, loc (not a great metric), complexity, features, etc - and the metrics still hold up.

That said, this order of magnitude is pretty rare (and it was against the slowest of the programmers) - but if you have a few true superstars, you can expect at least a 4x difference against the average in a group.

As far as compensation goes, at my last internet startup there was approximately a 5x difference, once you factor in bonuses. In the games industry, it was more like 2.5x.

For the worst coders, we tended to fire them after a few weeks if they somehow made it past the interview process. So there was a well-correlated difference in compensation there - we either paid them a few weeks of salary or 0$ in the latter case. :)

⬐ camccann

Unacknowledged differences of that magnitude would imply a massive arbitrage opportunity that has persisted for many years.

Only if "programmer productivity" is a primary limiting factor and one can reliably distinguish relative productivity beforehand, both of which strike me as unlikely in most situations.

⬐ damienkatz

If you view computer programmers as mental ditch diggers, then the idea that one could be so much more productive than another seems crazy. But when you see it as a creative endeavor, it's completely rational that some could be orders of magnitude more productive, even infinitely so.

For example, when you have a hard problem (like a networked 3d game with physics) that is beyond the abilities of a developer A (he can't solve the problems at hand, no matter how much time given), but not developer B (a creative thinker who can solve the problems quickly), then I think you can literally say Dev B is infinitely better than dev A for those hard problems. Because it's going to take you infinitely many developers A's randomly poking at their keyboard to solve the problems. But dev B will solve them in a reason amount of time.

Now dev B isn't infinitely smarter, but for certain tasks, he's infinitely more productive. The point is the productivity differences are highly context dependent, and the greater the creative and cognitive load of the tasks, the the greater the measurable productivity differences between the highest and the average developers.

⬐ SapphireSun

Slight nitpick: Infinite developer As will not solve the problem unless you assume that each developer can solve a finite part of the problem. If Developer A simply can't solve the problem none of them will help.

⬐ joe_the_user

But this reasoning applies if:

1) Knowledge is entirely linear. If there some tasks programmer A fails at and some tasks programmer B fails at, then all you have is an apples-to-oranges comparison (which is what a lot of the x10 chest-pounding comes down to).

2) Knowledge isn't shared in the group. My proudest moments have involved actually teaching my co-workers how to write a recursive descent parser, why ACID matters in databases or how to divide a multi-threaded application between worker and consumer threads. It might be true that if I'd just kept my knowledge to my self and laughed as they failed, I might have been a 10x or even a 100x programmer. But it was more pleasant and satisfying to be the guy who actually helped everyone.

⬐ lincolnq

I always upvote people who say "go read Peopleware". See http://news.ycombinator.com/item?id=986024 for more discussion about the book.

A lot of these come from Glass's excellent book "Facts and Fallacies of Software Engineering": http://www.amazon.com/Facts-Fallacies-Software-Engineering-R...

It's quite concise (224 pages), but it's chock full of quite excellent advice. Each one of these points (and many others) is fleshed out in a separate chapter that gives a good deal of background, clarification, and supporting evidence.