Found in 25 comments on Hacker News
mindcrime · 2020-07-17 · Original thread
I can give you the names of a handful of books that might be useful. Some are more technical, some less so. Some are more about personalities, some about the business aspects of things, some more about the actual technology. I don't really have time to try and categorize them all, so here's a big dump of the ones I have and/or am familiar with that seem at least somewhat related.

The Mythical Man-Month: Essays on Software Engineering -

Hackers: Heroes of the Computer Revolution -

The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage -

Where Wizards Stay Up Late: The Origins of the Internet -

Open: How Compaq Ended IBM's PC Domination and Helped Invent Modern Computing -

Decline and Fall of the American Programmer -

Rise and Resurrection of the American Programmer -

Accidental Empires: How the Boys of Silicon Valley Make Their Millions, Battle Foreign Competition, and Still Can't Get a Date -

Softwar: An Intimate Portrait of Larry Ellison and Oracle -

Winners, Losers & Microsoft -

Microsoft Secrets -

The Friendly Orange Glow: The Untold Story of the PLATO System and the Dawn of Cyberculture -

Troublemakers: Silicon Valley's Coming of Age -

Hard Drive: Bill Gates and the Making of the Microsoft Empire -

Masters of Doom: How Two Guys Created an Empire and Transformed Pop Culture -

The Supermen: The Story of Seymour Cray and The Technical Wizards Behind the Supercomputer -

Bitwise: A Life in Code -

Gates -

We Are The Nerds -

A People's History of Computing In The United States -

Fire In The Valley: The Birth and Death of the Personal Computer -

How The Internet Happened: From Netscape to the iPhone -

Steve Jobs -

The Idea Factory: Bell Labs and the Great Age of American Innovation -

Coders -

Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software -

The Pentagon's Brain: An Uncensored History of DARPA, America's Top-Secret Military Research Agency -

The Imagineers of War: The Untold Story of DARPA, the Pentagon Agency That Changed the World -

The Technical and Social History of Software Engineering -


"The Mother of All Demos" by Doug Englebart -

"Jobs vs Gates" -

"Welcome to Macintosh" -

"Pirates of Silicon Valley" -

"Jobs" -

And while not a documentary, or meant to be totally historically accurate, the TV show "Halt and Catch Fire" captures a lot of the feel of the early days of the PC era, through to the advent of the Internet era.

And there's a ton of Macintosh history stuff captured at:

charlysl · 2018-11-17 · Original thread
"On the criteria to be used in decomposing systems into modules" (1972) - because the core principles of modularity haven't changed []

"The Mythical Man Month" (1975) - because human nature hasn't changed []

"The History of Fortran I, II, and III" (1979) - because this historical piece by the author of the first high level language brings home the core principles of language design []

"The Unix Programming Environment" (1984) - because the core basics of the command line haven't changed []

"Reflections on Trusting Trust" (1984) - because the basic concepts of software security haven't changed []

"The Rise of Worse is Better" (1991) - because many of the tradeoffs to be made when designing systems haven't changed []

"The Art of Doing Science and Engineering: Learning to learn" (1996) - because the core principles that drive innovation haven't changed [] []

"xv6" (an x86 version of Lion's Commentary, 1996) - because core OS concepts haven't changed [] []

jmcomets · 2017-09-12 · Original thread
I recommend reading The Mythical Man Month[1] to anyone interested in proper SWE project management. There are so many wannabe managers out there that will just through more people at a project which is slowing down.

To quote the book: "Adding manpower to a late software project, makes it later". There's some really good stuff in there, even for those of us that are less interested in management.


W0lf · 2017-06-05 · Original thread
I've gathered all the book titles in this thread and created Amazon affiliate links (if you don't mind. Otherwise you still have all the titles together :-) )

A Pattern Language, Alexander and Ishikawa and Silverstein

Advanced Programming in the Unix Environment , Stevens

Algorithmics: the Spirit of Computing, Harel

Applied Crytography, Wiley

Clean Code, Martin

Clean Coder, Martin

Code Complete, McConnel

Code: The Hidden Language of Computer Hardware and Software, Petzold

Coders at Work, Seibel

Compilers: Principles, Techniques, & Tools, Aho

Computer Systems: A Programmer's Perspective, O'Hallaron and Bryant

Data Flow Analysis: Theory and Practice, Khedker

Dependency Injection in .NET, Seemann

Domain Driven Design, Evans

Fundamentals of Wireless Communication, Tse and Viswanath

Genetic Programming: An Intrduction, Banzhaf

Head First Design Patterns, O'Reilly

Implementing Domain-Driven Design, Vernon

Intrduction to Algorithms, CLRS

Introduction to General Systems Thinking, Weinberg

Joy of Clojure, Fogus and Houser

Let over Lambda, Hoyte

Operating Systems: Design and Implementation, Tanenbaum

Parsing Techniques, Grune and Jacobs

Peopleware: Productive Projects and Teams, DeMarco and Lister

Programming Pearls, Bentley

Software Process Design: Out of the Tar Pit, McGraw-Hill

Software Runaways, Glass

Sorting and Searching, Knuth

Structure and Interpretation of Computer Programs, Abelson and Sussman

The Art of Unit Testing, Manning

The Art of Unix Programming, ESR

The Design of Design: Essays from a Computer Scientist, Brooks

The Effective Engineer, Lau

The Elements of Style, Strunk and White

The Healthy Programmer, Kutner

The Linux Programming Interface, Kerrisk

The Mythical Man-Month, Brooks

The Practice of Programming, Kernighan and Pike

The Pragmatic Programmer, Hunt and Thomas

The Psychology of Computer Programming, Weinberg

Transaction Processing: Concepts and Techniques, Gray and Reuter

Types and Programming Languages, Pierce

Understanding MySQL Internals, Pachev

Working Effectively with Legacy Code, Feathers

Zen of graphics programming, Abrash

Jtsummers · 2016-12-14 · Original thread
Mythical Man-Month, Fred Brooks [0]. Very informative series of essays on his experiences and lessons learned with IBM. If nothing else, helps to properly frame my expectations on projects with respect to resources needed to properly coordinate with others, and the pros and cons of adding people to projects at different stages (and in different roles).

Getting Things Done, David Allen [1]. Useful toolkit for getting things out of my head and onto paper (or org-mode or OmniFocus) so that I can properly focus and prioritize my time on the things I need to get done.

Communicating Sequential Processes, C.A.R. Hoare [2]. Strongly influenced the way I think about programs in general, but specifically in the embedded field where I work. (NB: I've not actually read or worked through the full text, but mainly taken what was needed to properly communicate ideas in my designs or to analyze designs and systems others have produced. This is a task for myself for early next year.)

Moonwalking with Einstein, Joshua Foer [3]. I've always had a good memory, I actually picked this up to give to a girlfriend who had a terrible memory and read it in a couple days before giving it to her (she was out of town when it arrived). Helped to explain methods that I'd somehow developed over the years, and gave me concepts and a better understanding of other methods of memory acquisition (for either short or long term purposes). If you really want to improve your memory, there are probably better resources to learn specific techniques, but this was an informative and entertaining overview. WRT work, we have to keep large systems in our minds all the time, and potentially dozens of different systems written in different languages. Memory is critical for this, even if it's just the memory of where to find the information and not the information itself.

Fluent Forever, Gabriel Wyner [4]. This one is my current read. Goes back to Moonwalking with Einstein. While the book is itself about language acquisition, it's actually given me quite a bit to think about with respect to general learning and memory acquisition (in this case, specifically for long term retention and recall). We have a couple training programs (we need more) for our new hires on development and testing. There are some concepts in here and in related readings that I think would greatly improve how we teach these folks what they need to know and in a way that would improve their retention of that information. We have a lot of people retiring in the next 1-3 years, so this is actually quite critical right now, though management is quite lackadaisical about it.








The Toyota Way, Jeffrey Liker [5]. I grokked Lean from this. Hardware focused, but the concepts can be (and have been) generalized to other process focused fields. This has helped with understanding what business processes really need to be codified, what feedback mechanisms need to be present for improvement, the criticality of bottom-up feedback and improvement (employee investment in the company/product cannot be overvalued if you want quality and good craftsmanship).

The Little Schemer, Friedman & Felleisen [6]. Going back to the comments on Fluent Forever. The structure of this is fantastic for conveying and helping students retain information. The Socratic method is very useful, and structuring courses and introductory material in this format is useful, this happened to be my introduction to it (well, I'd heard it before, but my first time really encountering it in practice). It's a useful tool for solo-study of a topic (pose your own questions and construct answers), and as a method of guiding someone to a conclusion or better understanding. Also useful in debugging software or decoding software you didn't write, after a fashion.



angersock · 2016-10-31 · Original thread
Or The Mythical Man Month ( )

Honestly I'm kinda surprised that didn't come up sooner...but only half-surprised.

GFischer · 2016-03-16 · Original thread
I second that observation. I wish the manager at my day job read ANYTHING, at the very least some informercial-laden industry publication.

In my case, I'd like him to read Fred Brooks' "The Mythical Man-Month", to make him understand how a programming system costs a lot more than a simple module.


In second place, I'd place "Peopleware", so he'd understand the importance of communications, and how the current office arrangement is losing the company a lot of money:


Amazon link to both:

I think reading this book[1] is even more important than learning to use a keyboard (and mouse) with the intention of creating software or any complex system.

Knowing your limits is one thing, but understanding why/how they are being manipulated by outside forces (e.g. overestimating ability) is another. And how to counter those forces is also included in these pages.

Thank's for the sanity and well-managed project advice Fred!


atombender · 2016-01-31 · Original thread
Joe Armstrong's paper on the history of Erlang (of which he was one of the authors) is superb (though it's less about corporate culture than about the language):

There's The Mythical Man-Month:

Showstopper, the book about the development of Windows NT, is great:

A little surprised to see that the Mythical Man Month isn't on that list:
scholia · 2015-12-15 · Original thread
Indeed, the history of the development of very large software systems has been littered with disasters. Don't people read The Mythical Man-Month any more?

I'm a huge believer in going back to primary texts, and understanding where ideas came from. If you've liked a book, read the books it references (repeat). I also feel like book recommendations often oversample recent writings, which are probably great, but it's easy to forget about the generations of books that have come before that may be just as relevant today (The Mythical Man Month is a ready example). I approach the reading I do for fun the same way, Google a list of "classics" and check for things I haven't read.

My go to recommendations: - The Structure of Scientific Revolutions, Thomas Kuhn, (1996) - The Pragmatic Programmer, Andrew Hunt and David Thomas (1999)

Things I've liked in the last 6 months: - How to Measure Anything, Douglas Hubbard (2007) - Mythical Man Month: Essays in Software Engineering, Frederick Brooks Jr. (1975, but get the 1995 version) - Good To Great, Jim Collins (2001)

Next on my reading list (and I'm really excited about it): - The Best Interface is No Interface, Golden Krishna (2015)

If you're interested in this topic, might I recommend:

No Silver Bullet: Essence and Accidents of Software Engineering, Frederick Brooks (1987) -

No Silver Bullet Refired, Frederick Brooks (1995)

Both can be found (along with lots of other good ideas) in The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition -

Fred Brooks, author of No Silver Bullet[0] which GP is referring to, and the fairly famous Mythical Man Month[1].



eob · 2014-01-20 · Original thread
You might be interested in this book. It's required reading in many CS curricula:

hga · 2013-10-23 · Original thread
Note: in the 20th anniversary 2nd edition of The Mythical Man Month (, in one of the new chapters, Brook's backs off of his original "Build one to throw away" advice.
hga · 2013-08-30 · Original thread
It's been a long time since I've read either, but I can state in general that software engineering concepts don't tend to get outdated. The state of the art stuff I learned in the late 1970's is still almost entirely valid, although when it comes to low level stuff you'd want to e.g. adopt the advice about goto statements to other non-local things we are confronted with nowadays.

So reading an old classic like The Mythical Man Month isn't going to be a waste of time at all and is strongly recommended, but later really good stuff like these two books have additional lessons we've learned since then. So read the 20th anniversary version of that book (, in which the author revisits issues and e.g. modifies his advice to "plan to throw one (version) away, because you will". The potential state of the art has gotten better, you can often get away with not doing that.

sjclemmy · 2013-01-04 · Original thread
I did the same; taught myself css, php, javascript and quit my FTJ last Christmas. Best thing I ever did.

I also sent the following as advice to someone wanting to get into web dev:

"I was just thinking of 'easy ins' to the world of web development and a good source of information is there's a lot of information from people who work in the world of tech startups and it's good information.

Also - if you are wanting to do php dev the key things to learn are: Software engineering techniques and practice - object oriented development and abstract patterns are key to how to think about good development. Database design and development (1st normal form, third normal form etc) Learn SQL. (SQL for dummies or similar is good for the basic commands and syntax etc.) - it's the best source of help for software development on the internet. read books, the ones that come up again and again when people talk about learning to program:

also - look at - that's where programmers keep their source code.

Learn about Object Oriented Programming, Design Patterns, MVC (which is a design pattern) is specifcally useful for web development.

Also - demand for javascript programmers will increase over the coming years because of things like jQuery and Ajax.

That's my starter for ten - if you are interested in a career as a web programmer.

If you want to focus more on the html/css design side you could do worse than focusing on one CMS - such as wordpress and learning it inside out - you could then offer that to clients and it's a good way to provide web sites cheaply with very little effort."

robomartin · 2012-11-27 · Original thread
OK, if you don't have any real experience in low-level embedded coding (relevant to device drivers), RTOS or OS design in general, file systems, data structures, algorithms, interfaces, etc. And, if you have "hobby level" experience with Assembler, C and C++. And, if your intent is to write a desktop OS, from the ground up, without making use of existing technologies, drivers, file systems, memory management, POSIX, etc. Here's a list of books that could be considered required reading before you can really start to write specifications and code. Pick twenty of these and that might be a good start.

In no particular order:






















































54- ...well, I'll stop here.

Of course, the equivalent knowledge can be obtained by trial-and-error, which would take longer and might result in costly errors and imperfect design. The greater danger here is that a sole developer, without the feedback and interaction of even a small group of capable and experienced programmers could simply burn a lot of time repeating the mistakes made by those who have already trenched that territory.

If the goal is to write a small RTOS on a small but nicely-featured microcontroller, then the C books and the uC/OS book might be a good shove in the right direction. Things start getting complicated if you need to write such things as a full USB stack, PCIe subsystem, graphics drivers, etc.

kenkyhuang · 2011-01-21 · Original thread
The Mythical Man Month, although old, has some great tips for estimating software engineering work.

tokenadult · 2010-11-27 · Original thread
Does The Mythical Man Month by Brooks

qualify as a programming book for this thread (maybe not)? It has no information on how to write "Hello, World" in any language, and little how-to information about coding, but a lot of information about effective programming, and it is a very interesting, readable book.

AmitinLA · 2010-08-20 · Original thread
I come from a similar situation and faced similar challenges, especially after trying to launch a web startup with no financing and no developers on board. It failed. I'm determined to stay in tech, so here's some of my (occasionally conflicting) thoughts.

1) You call yourself a business guy, but are you a product guy? If you're a product guy -- if you can understand the soul of a product and how it interacts with people -- that can be inherently valuable. In my experience, most people I've met may be "tech" or "business", but they're not product people.

2) Get an internship. Beg. Show up, prove why you're valuable, send unsolicited resumes with advice and biz dev/product suggestions. Be humble, but not too much. Work for free for a couple months, or at minimum wage or whatever is legal. Just get your foot in the door.

3) Read. The Elements of User Experience (, The Mythical Man Month ( -- these are just to get you started. Learning to code a little bit will be good as well. The point is not to become an expert developer, but to learn how developers think. Think of your reading as travel literature and learn about different cultures.

4) Look for non-sexy opportunities. Twitter, FB, 4SQ, Zynga etc., get all the hype, but there's tons of need for software development and product design in what I call the "iceberg industries." The trucking industry brings in $250 billion dollars in revenue every year. That's almost twice the size of the airline industry and yet a typical website of theirs looks like this:

5) Think about CPG (even though it's not tech, it still can be a startup). It's a risky, tough move and faces lots of market forces, but can be incredibly lucrative. You could find a small local product that you believe in, invest some cash to get equity, and try to make them big. As a consultant, your skills may be valuable because the problems in these types of entrepreneurial efforts are operational problems, not innovation problems.

6) Don't worry too much about the idea or where you're working right now: your goal is to build professional and personal credibility. Give away your great ideas. Most people who have them don't tend to have just one.

7) Don't worry about home runs. Most entrepreneurs I know have small lifestyle businesses and love their companies no matter the size. It's kinda like having a kid. S/he's probably not going to grow up to be president, but you're going to love 'em anyway.

Maro · 2010-06-25 · Original thread
By Fred Brooks, author of The Mythical Man-Month. I'm reading the book right now, it's great.

Here's a link to MMM in case someone hasn't read it:

10ren · 2010-06-20 · Original thread
See p. 7 of Brooks' The Mythical Man-Month, for "The Joys of the Craft"

He lists 5: creation; usefulness; intricacy; constant novelty; tractability.

Some of these are in common with graphic design; but the "constant novelty" perhaps addresses your "boredom". Turing said that programming need never become boring, because any repetitive coding (or concept) can be captured in a function or module. Once you're worked out the solution to a problem, you write a reusable module to deal with that problem, and embodies your understanding of it, and you don't have to do it again. So it's always new problems.

Now, in practice, it isn't always that easy. Code that can be reused generally is much harder to write than code for one specific case (the literal meaning of ad hoc: "for this"). The hardest part is specifying what it do, not coding how. This approaches AI: to go from a problem that initially you cannot even understand, to one that you can automate 100%, is transcendent. Almost Frankensteinian... (aka The Modern Prometheus).

For me personally: I get a simple pleasure from making something happen on the screen (like any act of creation); but I actually don't like programming much for its own sake. I enjoy solving problems, and making them real. It's easy to dream something; but to do it is a real accomplishment. And anything on the road of that journey becomes equally important.

I don't know what stage you're at, but it's possible that you're not yet up to wrapping up the common parts of your coding, so you don't have to do them again. If you keep on typing the same predictable, mechanical things, that would be boring. Computers are ideal for this kind of mechanical work.

Fresh book recommendations delivered straight to your inbox every Thursday.