The Pragmatic Programmer: 20th Anniversary Edition (2023)

(www.ahalbert.com)

Show context

sfpotter ◴[17 Nov 25 00:33 UTC] No.45949845[source]▶

Alternatively, consider being an idealistic programmer!

  - Fall in love with a single topic, regardless of how trendy.
  - Learn as much as you can about it.
  - Keep learning about it.
  - Learn about it some more.
  - Spend years of your life doing nothing but breathing and thinking about this one topic.
  - Let fads and fashion pass you by.
  - Don't settle for good enough. Try to build the best version possible.
  - Choose where you work based on your ability to reach staggering new heights with this one topic, and disregard whether it seems like an amazing CV line item.
  - Fail to even notice fads and fashions passing you by.
  - Become a master.

replies(8): >>45949909 #>>45950132 #>>45951043 #>>45951139 #>>45951800 #>>45951958 #>>45953536 #>>45954942 #

1. android521 ◴[17 Nov 25 08:59 UTC] No.45951958[source]▶

>>45949845 #

I have read many books. If you can only read one book about how to program in your life , I would say that it is this book: A philosophy of software design: John Ousterhout. It is 10 times better than the next best book.

replies(5): >>45952407 #>>45952786 #>>45953086 #>>45953542 #>>45971095 #

2. garethrowlands ◴[17 Nov 25 10:36 UTC] No.45952407[source]▶

>>45951958 (TP) #

It's very good. And quite short!

3. ck45 ◴[17 Nov 25 11:45 UTC] No.45952786[source]▶

>>45951958 (TP) #

For me “the problem with software, why smart engineers write bad code” is the prequel. Not as technical, but explains a big problem

4. keyle ◴[17 Nov 25 12:44 UTC] No.45953086[source]▶

>>45951958 (TP) #

Thanks, purchased.

5. tmoertel ◴[17 Nov 25 13:52 UTC] No.45953542[source]▶

>>45951958 (TP) #

This model of complexity from the book is very useful:

    complexity(system) =
      sum(complexity(part) * time_spent_in(part)
          for part in system)

6. sfpotter ◴[18 Nov 25 19:47 UTC] No.45971095[source]▶

>>45951958 (TP) #

I'm not sure if you're just spamming this response all over this thread or if you're replying to what I wrote, but I do actually think there's a connection. I've also read and love this book, and it does push back on the "pragmatic" mentality espoused by The Pragmatic Programmer and other similar books.

I feel like this comes from Ousterhout's focus on actually building working systems. The Pragmatic books are much more focused on how one might get through the day as a programmer working at an org, but PoSD is focused on the ins and outs of building software well. I find that Pragmatic Programmer etc. have little to say about this, and when they do it's usually either trivial or fluff.

I'm not sure if Ousterhout is an "idealistic programmer" (I'm not even sure if this is the right term...), but I definitely feel like he's a fellow traveler...

↑