A Philosophy of Software Design.

Very well-written. At 190 pages, quite likely finish-able in a weekend. But if you get 70% of the way through it, that is still very valuable. It makes sense as an underlying set of principles that explain why you would use design patterns.

I came into this thread hoping to find the suggestion near the top.

Beyond his credibility as the creator of Tcl, in the talk he gave at Google about the book [1] he describes the course he teaches that was the inspiration for the book. The course is to write a word processor with a team and extended it with features over the semester, swapping codebases between teams so occasionally you have to work with other's code. Essentially the largest possible code project you can fit in one semester. Along the way, Ousterhout will give a deep code review of the each project. I think it must be very insightful to see the same project implemented so many ways, and to see what works in terms of simplicity and extensibility.

[1] https://www.youtube.com/watch?v=bmSAYlu0NcY

I see only positive reviews for this book here, but I went to look it up on amazon and the first review doesn't look particularly good and I'm looking for anyones reason to refute this:

"This book does not consider functional programming, or the fact that terrible software in modern times is often the result of layers of incorrect abstraction that are often induced by the overuse of "object oriented" (OO) programming techniques. Instead, it takes OO programming for granted as being a good thing (visible in its preferences for two OO languages, C++ and Java), and then it reasons in that domain, making it totally uninteresting to many potential readers. The book also assumes that formal design doesn't work (he calls it "waterfall"), and takes alternatives for granted. I doubt the author is even aware of his inherent bias, but it is incredibly strong."

Does anyone here agree or disagree with these points?

I would not agree that the bias towards OOP is a problem in the book, since most of the concepts are paradigm-agnostic. Nevertheless, I feel that the author exposes a rather opinionated (sometimes even dogmatic) and narrow view of software design.

Although I think that the book provides a lot of very valuable insights, I missed a more differentiated view of the concepts presented in the book. For example, in chapter 4 ("Modules should be deep") Ousterhout dismisses the use of small classes and methods. He argues that using many small classes and methods makes the system as a whole more complex because many little pieces have to be managed. I completely agree with that statement. But only under the assumption that software systems are static and never-changing. If we consider software systems as ever-changing, I would argue that using smaller pieces often provides the flexibility necessary for maintaining large systems.

I've also noticed that point in one of his talks and disagreed with it immediately. My own experiences have found small components easier to test and reason about in higher level components. I do think that navigating through a codebase with a lot of small files would make the codebase seem a lot more complex (especially without a modern code editor where you can't do things like click on an interface method and see all its implementations), but the biggest drawback of having small components, in my opinion, is that a lot of the developers I've observed are very bad at drawing coherent software boundaries

> a lot of the developers I've observed are very bad at drawing coherent software boundaries

That's a very good point. Designing small components probably requires more effort and can also cause a lot of harm if done incorrectly.

When arguing against small classes and methods by default, he's in good company: http://number-none.com/blow/john_carmack_on_inlined_code.htm...

Prior HN discussion: https://news.ycombinator.com/item?id=12120752

There are also numerous people which promote the excessive use of small classes and methods like for example Kent Beck or Robert Martin. As always, there probably is no "right" answer, it really depends on context.

Yes, except Kent Beck and Robert Martin have zero engineering cred and way too much "Agile" cred, for a lack of a better word.

I think that would be better off in a different book rather than as a part of this book.

It is better to provide a clear and memorable picture that is only slightly wrong than a hedging and muddled picture that is still slightly wrong.

Hrm, I read the book and the code samples were in mainstream languages, naturally, but there wasn’t a specific reference to OO. Algorithms by Sedgewick had more reference to OO but we don’t say that book is overly biased towards OO.

The text isn’t about implementation or paradigm. It’s about things applicable in software design in general. For example, good interfaces are deep, rather than shallow. The examples of narrow interfaces are in Java because they were good examples. If you have to instantiate 5, 6 objects to use an interface, the interface is not deep. But if you had to do the same thing in a CLI interface or a GUI, it’s the same idea. You could apply the same ideas to functional APIs.

This book brilliantly illuminates the deepest issues at the core of software development. It is a well-written, gentle read. I have been programming for close to 50 years now, and this is probably the best and most insightful book I have ever read on software development. Its deceptive simplicity is such that a first-year programmer would benefit from it. Read it once per decade! You will get more out of it each time as you mature as a developer.

I don't find design patterns very compelling unless you're stuck with underpowered statically-typed languages like Java. There, they serve somewhat as a way out of the straight jacket. In more powerful languages there are better, simpler ways to design your systems.

I came here to recommend this one, very digestible and has had a significant impact on the quality of the software I write.

This is a great book. Highly recommended for inclusion in a “thin” bookshelf.

An absolute must have I agree, amazing book.

"The Elements of Style", by Strunk & White. 92 pages.

For example, page 19: "Put statements in positive form."

Code is improved if booleans are put in positive form, such as replace:

    if (!featureIsDisabled()) ...

with:

    if (hasFeature()) ...

You might laugh, but I see the first form all the time. Sometimes I go on a refactoring mission to remove as many negations, nots, and bangs from the code as possible.

?? You mean this book-- "The Elements of Style is an American English writing style guide in numerous editions. The original was composed by William Strunk Jr. in 1918, and published by Harcourt in 1920..." [1]

Cool! 1920s book on English writing style inspiring your coding style.

My first reaction to the 'positive form' was to recall a conversation I had once with a retired programmer about flow control diagrams. They relayed how the normal form for these required, for example, the boolean nodes to exit True in one direction and False in another--but all similar nodes had to exit in the same direction.

I wondered if a paper-based design, once translated into code, might not include conditionals such as the example which seem awkward once the paper design is lost and forgotten.

Now I don't know which detail is more interesting--

How design methodology effects the comprehensibility of written code.

How I was inspired to apply natural language writing principles as programming best practices.

[1]: https://en.wikipedia.org/wiki/The_Elements_of_Style

> 1920s book on English writing style inspiring your coding style.

Absolutely. It is surprising (but not really once you think about it) how applicable it is.

I use negative flags (but not negations) so that I can break out early with early returns ...

  if (isFeatureDisabled()) {
    // do not proceed
    return
  }

But still the style guide holds, since there is no negations ...

I do try to reframe as different words, such as "right" instead of "notLeft", to eliminate negations.

I think that Style: Towards Clarity and Grace is a good follow-up. Have a free PDF: https://sites.duke.edu/niou/files/2014/07/WilliamsJosephM199...

"Writing with Style, Conversations on the Art of Writing", by John Trimble is another great writing book (The second edition is 161 pages if you don't include the appendices).

The ability to communicate in writing is an important skill even for developers.

I was first put onto this book by my PhD supervisor while writing up my dissertation. Revolutionised the way I wrote English for the better.

Ever used a router command line from Cisco, arista etc? Switch on a port with "no shut"

The 22 immutable laws of marketing by Al Ries and Jack Trout. Software is ultimately for humans. Understanding products, marketing and selling help you build better tools for humans and see how products (be it open source, programming languages, retail products, etc) work in the marketplace and not run down paths of "well this is the most popular they must be the best" ...

Solid marketing foundations are probably one of the more important skills that separate the good from the great practitioners.

Everything else on this thread I've read isn't a weekend. It's a careful study.

Very interesting read.

I find law 12. the law of line extension speaks to the current apple product line. There used to be a single phone they made, today there are 4 to choose from.

Any other marketing books worth reading? Especially branding?

What about the 22 immutable laws of branding by the same authors?

I recommend these two free online/e-books by Niklaus Wirth:

Compiler Construction https://inf.ethz.ch/personal/wirth/CompilerConstruction/inde... How to build a compiler from scractch (if you read German, there is an even more concise book by him, "Übersetzerbau)".

Project Oberon https://inf.ethz.ch/personal/wirth/ProjectOberon/index.html How to build a personal workstation including all software from scratch.

For those of you who claim to start and finish a book in a weekend, are you spending literally the entire weekend doing nothing by reading? Do you take breaks? Do you speed read? Do you take notes? What's your strategy?

For me, some books are much easier than others and that plays a big role in how fast I finish reading.

> are you spending literally the entire weekend doing nothing by reading?

For the most part, yes.

> Do you take breaks?

Yes.

> Do you speed read?

No.

> Do you take notes?

Usually I take notes on things that jump out at me while I read. I don't take a lot of notes. Maybe one note every ten pages or so.

> What's your strategy?

Stay off of reddit and hacker news. Instead of spending time on the internet in the mornings or if I feel board, I reach for the book I am trying to finish and I keep my phone somewhere it can't distract me. Very tempting to get distracted and start looking at your phone. Before you know it you're five pages deep on reddit and half an hour is gone.

Another thing I do pretty frequently is flip to the next chapter and tell my self, only x pages to until I get to that chapter. It helps me stay focused and motivated.

In general, the more you read, the better your read.

For me, fiction books are easy when getting into it. It's like watching a movie unfold inside the head. It's simply difficult to put a good fiction book down.

Non-fiction in general is not as fast to process. But, sometimes books have a lot of redundancy, explaining things already explained, repeating the same thing over and over, and repeating the same thing over and over, and explaining things already explained, and so on. I just skip that without remorse.

I speed read when it makes sense (for example, when finding some information fast in a mass of unknown text). I take notes in different ways, sometimes use a mindmap and use different techniques to analyze and remember.

I take some breaks, too, but they are not scheduled nor regular. The ideal break is a short walk outside, but this is often not practical.

Doing 350 pages of non-fiction in a normal weekend is hard, unless I'm alone without family, eat takeaway and have some background knowledge of the subject and can skip some parts since I already know it. For something completely new, maybe 3-4 days is more accurate an estimate.

Doing 350 pages of fiction is very fast, specially if it's in my native language. Other languages are a bit slower to process.

Last but not least, if it turns out that the author is stupid and/or the content is rubbish, then reading the book becomes hard work. Therefore, I think one has to have some form of interest in the book as well to motivate reading the book at all and to be open to consuming the book effectively. For me, this interest is actually one of the key things for consuming a book. For example, once I had to stop reading one of George Friedman's books for the aforementioned reasons; thinking "this is such bullshit" after every few pages is not a good signal.

One way to build up this interest towards a book is to create, beforehand, some questions which the book should somehow answer.

Hope this helps and gives you some ideas.

I can really do fiction books that fast.

If I really push I can do a 350 page book in one day of about eight hours.

I do take breaks if I have a need such as eating, or the rest room.

I do not speed read. My strategy is to sit down, read, and get done at some point.

Non fiction is a bit different, and depends wildly on the topic, how familiar I am with the topic, and how dry the book is.

I also enjoy nonfiction podcasts, and talks which I play at 1.5x speed while doing things like bike riding, or cleaning.

I don't think there's a particular reason to read a book in one weekend. For me the outside world kinda just fades away as I do it like it does when you binge a lot of things. But if you don't have the time or that ability, shorter chunks, even a chapter a night or splitting it over multiple weekends seems like a good idea to me.

I've recently taken to listening to almost everything spoken at 1.5-1.75x speeds. Content creators on YouTube have taken to speaking v e r y slowly, adding a lot of useless fluff / filler, or both. I see it in almost every video that I watch today. It seems like everyone is chasing that magic 10 minute mark with videos containing 2 minutes of actual content.

The side effect being that I am able to track things much better now at that speed and I can bang through podcasts much easier now that I've acclimated to the faster speeds. Really recommend this to anyone who also listens to a lot of podcasts or audio books, it's a good hack to get more content in.

> I also enjoy nonfiction podcasts, and talks which I play at 1.5x speed while doing things like bike riding, or cleaning.

Listening to a podcast or audio book while doing monotonous tasks is both life changing and addictive.

It goes from an annoying 30 minute walk from the subway to somewhere to hey I can catch up on Mission to Zyxx.

I used to be able to do 200 pages in 4-6 hours (albeit not highly complicated books - Narnia books near the 4 hour limit ), but am out of practice reading for such extended periods due to having a family. Still I doubt that it could be over 8 hours for the simpler books.

Huckelberry Finn, which is a pretty complicated book given all the dialect and the ideas it presents, used to take me about 8-9 hours. I recently read it over a period of 2 days in ebook reader during pauses in a pretty heavy schedule of taking care of kids, cleaning house etc.

Depends what you mean by “finish”. Especially for reference books, I may get everything I need out of it without deeply reading from cover to cover. For a reference work I usually skim it first, just to get a very high level overview before I decide how far to really dig in (I find it _much_ easier to do this with paper books than with ebooks).

I am single. I have no kids. I am not allowed to go outside because of the lockdown. I have 32 hours in a weekend. I can spend 8 hours for reading and I think it is enough to finish a 150-pages book. I am reading books with my kindle, underlining important parts, and putting them into Goodreads at the end.

I'll say if you are not taking breaks, and notes then you are only wasting your time. A book should be savored. Re-read many times.

What about just reading the book once, and returning to it some day later if you want to refresh and maybe work it properly?

That's the same idea I want to convey.

It’s like binging a tv show

Some are easy to binge cause they keep your attention

Others are a slough

Most importantly, how much do you retain?

I guarantee they don’t have kids.

Audiobooks at 4x speed while walking or other menial activities.

Grokking Simplicity: Taming complex software with functional thinking

I’m cheating a bit because this is only under 200 pages because it’s a work in progress.

It’s such an easy read, but does a great job at explaining the value of functional programming for building real-world applications without getting bogged down in monads, currying, and complex type systems.

Once it’s complete, I’d make it required reading for any new junior/intermediate devs on my team (or anyone unfamiliar with functional programming).

[0] https://www.manning.com/books/grokking-simplicity

Judging by the table of contents, this book looks really good. Ideally though I would like to read through a good sized sample on my kindle in mobi format before making a purchase.

The Manning website allows you to read a good amount online for free. Their books and book reading experience are impressive.

I enjoyed reading Professor Frisby's Mostly Adequate Guide to Functional Programming, 146 pages.

https://github.com/MostlyAdequate/mostly-adequate-guide

Awesome resource! The companion course on egghead is also great and quirky: https://egghead.io/courses/professor-frisby-introduces-compo...

Sounds interesting but unfortunately for me knowing JavaScript seems to be a requirement

Refactoring UI.

Very pragmatic and approachable for us developers who may not have much idea about design. If you want 'good enough' design for your side project but don't want to use templates, this is the book you'd want to read. The book is a bit expensive though.

I love refactoring UI. Very practical advice.

There's a whole series of ebooks by Syncfusion that are exactly what you're describing. Matter fact I think they call them the "Succintly" ebooks series because they tend to introduce a technology or topic in a short 100-200 pages. Check em out here: https://www.syncfusion.com/ebooks

At 2.5k a year, I'd rather pay for Pluralsight or something similar. That's an amazingly huge price for an individual-focused training.

I'm seeing free E-books. That $2.5k must refer to their services.

I just downloaded a free book. In the intro it says:

> Free forever. Syncfusion will be working to produce books on several topics. The books will always be free. Any updates we publish will also be free.

Data & Reality (Kent, 1978)

https://www.goodreads.com/book/show/19305264-data-and-realit...

164 pages. This book has had a bigger impact on my professional work than any other.

tl; dr: Any description of reality is subjective, which means that no data model can be an objectively correct description of reality. The book presents methods for reasoning about data in spite of this.

The Mythical Man Month, Brooks. Probably more than 200 pages, but you can read the chapters as stand-alone essays. There are other good books about programming as a social activity, but everyone who does development for a living should read this one.

Neil Davidson: Don't just roll the dice – Software pricing guide

https://neildavidson.com/downloads/dont-just-roll-the-dice-2...

Somewhat related but more generally about estimation: Hubbard, How to Measure Anything https://www.amazon.com/How-Measure-Anything-Intangibles-Busi...

Ullman, 'Elements of ML Programming'. It's where I learned functional programming back in the 1990's, and I still think it's one of the clearest expositions around. Yes, it's the same Ullman who wrote the dragon book.

Ullman's book is really accessible and what introduced me to SML as well, but for those looking for something that goes a little deeper, do read "ML for the Working Programmer" by Lawrence Paulson (author of Isabelle). It has one of the best introductions to ML's module system and even covers building a (toy) tactical theorem prover. Oh, and it's now available online for free as well [1].

Another great book on FP is "The Functional Approach to Programming" [2], which is a bit like SICP but using Caml (OCaml without the O) instead of Scheme.

[1] https://www.cl.cam.ac.uk/~lp15/MLbook/pub-details.html

[2] http://pauillac.inria.fr/cousineau-mauny/main.html

I was in office hours with Ullman once, and he was having trouble coming up with a derivation for the runtime complexity of a famous algorithm from a topic unrelated to the class. "This should be easier," he joked, "I came up with this!"

Here is my recommendation: Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

https://www.amazon.com/Apprenticeship-Patterns-Guidance-Aspi...

During the Spanish Civil War, volunteer fighters found that a book had to be at least 350 pages to stop a bullet.

(Not a dig at your question, it just came to mind.)

Little Schemer (216 pages)

Classic MIT text. Pretty dense feeling though, my brain melts after a chapter or two at a time

Dan Luu's programming book list (https://danluu.com/programming-books/) is a great resource. I bought the Dasgupta Algorithms book from that recommendation. (I've just started it so I can't say much about it yet.)

The Dasgupta algorithms book is great. I read through it on my own a few years ago. Much easier to follow than CLRS (and much more manageable in size, though it obviously leaves out a lot of the stuff they cover). It strikes a good balance between rigor and clarity. Also has one of the better explanations of dynamic programming that I've seen if I remember correctly.

I really like Grokking Algorithms. You can probably read it in a weekend if you don't do the code exercises.

That's a terrific book. I'm not a professional programmer and had no training in algorithms when I saw it and picked it up. It was a great introduction for me, and I had a lot of fun discussing the topics with my father, who is a software engineer.

Finally picked up Strunk and White after years of procrastination and so far it has been a tour-de-force consolidating/spelling out the knowledge I picked up along the way (ESL). I found mentally swapping out words about writing for words about programming to be fun.

Brian Kernighan (the K in K&R and AWK) also wrote a similar book with P. J. Plauger called "The Elements of Programming Style" [1]. There's even a talk by him about it online (2009) [2].

Kernighan also co-authored a (imo) really great book with Rob Pike (once an assistant of Penn & Teller [3]) called "The Practice of Programming" [4]. Unfortunately, this one is a bit over the 200 page limit.

[1] https://en.wikipedia.org/wiki/The_Elements_of_Programming_St...

[2] https://www.youtube.com/watch?v=8SUkrR7ZfTA

[3] https://youtu.be/z4iVAcYyWN0?t=180

[4] https://en.wikipedia.org/wiki/The_Practice_of_Programming

Not as thin, but you might find Steven Pinker's The Sense of Style interesting as a follow-up to S&W.

If you liked that, I heartily recommend "Style: Toward Clarity and Grace" by Williams.

Kingsley Amis 'A guide to modern usage', a similar choice for non-Americans.

For a beginning programmer, I'd say buy a copy of "Code Complete", then rip it into 5 parts. Read any one of the 5.

Programming Pearls is short and very good.

Mom Test by Rob Fitzpatrick. Found it to be a very well written book with simple but useful todos.

Shipping Greatness by Chris Vander Mey is a brilliant book that relates his experience at Google and Amazon and the culture of quality necessary to ship reliable products that will be used by millions. Well written and a great read.

Mastering Vim Quickly: From WTF to OMG in no time

https://jovicailic.org/mastering-vim-quickly/

109 pages.

Writing Solid Code by Steve Maguire - 245 pages but really well written and an enjoyable read. Examples in C but principles are applicable with any language.

Kent Beck TDD book is a thin book e really good.

I second this. The third part of the book is a great look at which patterns are helpful with testing.

I went through my recent-books shelves and found a few shorter books that are well worth reading. Short books for developers are rare these days.

Algorithms Unlocked, Thomas Cormen, 212 pages

The Art of Readable Code, Dustin Boswell & Trevor Foucher, 180 pages

How To Take Smart Notes, Sonke Ahrens, 151 pages

How to Write a Thesis, Umberto Eco, 223 pages

How Charts Lie, Alberto Cairo, 193 pages

Practical Object-Oriented Design in Ruby: An Agile Primer, Sandi Metz

264 pages, although including code snippets and a few diagrams.

Definitely not the best but it's short, fun, and for developers. Definitely doable in a weekend.

So You Think You Know C And 10 More Short Essays on Programming Languages: https://wordsandbuttons.online/SYTYKC.pdf

Don't Make Me Think (200 pages)

Grokking Algorithms An Illustrated Guide For Programmers and Other Curious People (235 pages)

Some classic old textbooks are about that size but they are very dense. A Discipline aof Programming comes to mind. It's about deriving imperative code from the weakest precondition you need to give to the next statement and about proving programs correct with a big emphasis on loop termination.

The Mythical Man Month

The unwritten laws of engineering (James G. Skakoon, original by W.J. King). 67 page introduction to "soft skills" for engineers. I wish I read this book earlier to understand that being a great coder is only part of growing into a great engineer.

Test Lean and Ship Healthy - https://github.com/srcclr/test-lean

A short handbook on developing high quality software in the DevOps world.

Hmmm... Glancing at my shelf. That's not easy. Two that are close are:

Programming Pearls 2e (239 pgs)

Practice of Programming (267 pgs)

I see Algorighms + Data Structures = Programs, but I know that's well into 300 pgs w/out looking.

Thank you for this "Ask HN" ever since I became a parent, the only books I'm able to finish are the ones that are 200 pages or less.

Then don't worry about finishing. Reading 200 pages of a good, long book is better than finishing a bad book < 200 pages.

I have 2 little boys, and even though I've been working on Conan the Cimmerian for over a month, its worth it.

The Principles of Object-Oriented JavaScript by Nicholas C. Zakas (120 pages).

"User Interface Design for Programmers" (159 pages)

Is that the 2001 Spolsky one? Still relevant?

Amongst my many weaknesses, UI is the weakest.

A Tour of C++, by Stroustrup.