Software Requirements - Karl Wiegers
Programming TypeScript - Boris Cherny
Associate Cloud Engineer Study - Dan Sullivan
Design Patterns - Gang of Four
Refactoring - Kent Beck, Martin Fowler
Programming Pearls - Jon Bentley
Patterns of Enterprise Application Architecture - Martin Fowler
The Pragmatic Programmer - David Thomas, Andrew Hunt
CSS: The Definitive Guide - Eric A. Meyer, Estelle Weyl
Working Effectively with Legacy Code - Michael Feathers
Head First Design Patterns - Eric Freeman, Bert Bates
Code Complete - Steve McConnell
Peopleware - Tim Lister, Tom DeMarco
Clean Code - Robert C. Martin
The Clean Coder - Robert C. Martin
Clean Architecture - Robert C. Martin
Don't Make Me Think - Steve Krug
Functional Design Patterns for Express.js - Jonathan Lee Martin
The Surrender Experiment - Michael A. Singer
The best books I've ever read:
Principles - Ray Dalio
The Power of Now - Eckhart Tolle
The Effective Executive - Peter F. Drucker
Think and Grow Rich - Napoleon Hill
Extreme Ownership - Jocko Willink, Leif Babin
Influence - Robert B. Cialdini
The Startup Way - Eric Ries
The Lean Startup - Eric Ries
12 Rules for Life - Jordan B. Peterson
Measure What Matters - John Doerr, Larry Page
The Fish That Ate the Whale - Rich Cohen
The E-Myth Revisited - Michael E. Gerber
The Score Takes Care of Itself - Bill Walsh, Steve Jamison, Craig Walsh
Management - Peter F. Drucker
Thinking in Systems - Donella H. Meadows
Blue Ocean Strategy - W. Chan Kim, Renee Mauborgne
Sounds like you’re diving head first into web development? Or taking it to the next level?
Careful not to burn yourself out, that is a long list of technical books, that have nothing to do with the books you’ve read and enjoyed in the past that are from other genres.
Long story short, I am an entrepreneur who sold a company and am transitioning into maximizing my engineering knowledge before diving back into entrepreneurship.
I've spent a considerable amount of time studying top performers and learned how to manage stress levels effectively. I do exercise, meditation, yoga, stretching, forest bathing, mindfulness, journaling, and other activities that battle against burnout.
I am much more worried about failing to meet my goals than I am burnout. Appreciate your concern though!
I'd say if the goal is to maximize engineering knowledge, less might be more. Especially if you don't plan to apply it on a day to day basis as an engineer.
For example, I'm currently reading Clean Architecture by Martin that is on your list. While the words on the pages are not hard to understand and it doesn't rely on any advanced computer science/engineering concepts, actually comprehending the posed principles, their implications, how to reason about them and how to pull them off well in a real world scenario is absolutely non-trivial.
I have met many people in tech that devoured douzends of books and conference talks, hundreds of podcast, blog posts, articles and that were an endless source of catchy quotes found in them. But they weren't able to actually apply all this "knowledge" to anything beyond the most basic. And in cases where these people where in leadership/management positions this often had negative impact on the project/product.
To finish with a catchy quote from Clean Architecture:
Kudos to you and best of luck :)
I’m an engineer by trade, but I’ve quit my job recently to start my own thing, and moving into web dev (my experience is in native dev), so I both share your concerns and your reading list!
You have quite overlap between some stuff. I would recommend "Clean Code", but then skip the rest from the same author, at least for a while. While "Code Complete" is good, it's loooong and also a lot of the same stuff.
For patterns, "Head First" is a bit childish maybe, but the content is fine for someone learning to recognize patterns. "Patterns of Enterprise..." is also good, but more dry. I'd stick with one of those two. And then skip the one by GoF, unless you want to read the "original" for some reason.
"The Pragmatic Programmer" is probably the book that has shaped my work the most.
Another "Patterns" book that seems to be interesting is "Pattern-Oriented Software Architecture For Dummies" by Robert Hanmer. I've actually ordered it and look forward to read it in the coming year.
There's also "Patterns for Fault Tolerant Software" by the same author that looks pretty interesting too.
Code Complete seemed to be a book with a lot of dense, redundant content. Reading what was written had me feeling like I was reading information that could have been written by myself. Clean Code on the other hand (along with Refactoring by Martin Fowler) changed the way I write code for the better.
Not a long time ago I've found this comment about how to read Code Complete: https://www.amazon.com/gp/customer-reviews/R65Q50S27SSWE - After reading the comment, maybe I'll consider to give the book another try with a different approach :)
I'm confused by the praise for this book. I couldn't finish it. No real insight or anything technical, just fluff (Dreams + Reality + Determination = Success!).
I'm with Josh Wolfe [1]; I think Bridgewater is going to be exposed as one of the random, large hedge funds that got lucky for a spell, but is not any better than an index fund, ex-fees.
Looking at your top priority books I recalled a slide from one of Brian Will's videos on object oriented programming: "Object Oriented Programming is Bad" https://www.youtube.com/watch?v=QM1iUe6IofM&t=326s. At around the 43:51 he pulls up a slide picturing several of these (and similar) books. Here is a rough quote: "I can tell you from personal experience of having read these books that you don't need to read them. They don't have answers, they aren't going to square the circle, and you are going to waste productive years of your life trying to live up to their ideals." Now that is just one rather controversial opinion, but we are talking about potentially wasting productive years of your life so I wanted to let you know that opinion is out there. That being said, it would probably be hugely beneficial to read a few of those books and then watch a few of Brian's videos (he has three or four on the topic) and sort out your own opinion. Also, Brian's other (not controversial) videos (dozens) are excellent for learning about programming. Also, Steve Krug's Don't Make Me Think is a keeper. I thought of it last night when I was checking out at a store. I stuck my debit card into the thing, entered my PIN number, then clicked the big blue button that said "Skip PIN". The woman behind the counter said "don't worry about it; everybody does that!"
Skip design patterns, I think it locks developers into a sort of religious loyalty towards OOP abstractions. When you understand the pattern it describes you get a sort of catharsis for discovering a new interesting thing. In reality, any of these patterns are just bad despite the cleverness.
Modern programming is heading in a different direction already so it'd be better to move forward without it.
I disagree because people often don't have the luxury of working on greenfield projects.
When you are working with an old codebase, you are going to run across design patterns. You will see terms like factory, builder, observer, decorator, pool, flyweight, etc... and it's going to be helpful to know what those are. A lot of the value of design patterns was in the terminology.
Times have changed where few non-greenfield projects use these patterns as well. Languages like Go and javascript will rarely have these patterns. I would avoid depending on the programming language.
If you are working with Java or C++ these are the two languages where these patterns will appear, even in greenfield projects due to developer loyalty. If you are working with languages other than this, then you are more likely not to encounter these patterns that often.
Thus avoid the book unless you want to become an expert in Java. Also these patterns can be learned without the GoF book just off of quick scans of articles on the internet.
Presumably some of the problems they intend to solve still exist.
Is there some resource you can point to that says in the past when faced with situation X developers tended to use pattern Y, these days that has been superseded with way of doing things Z?
I've seen some of those patterns leveraged to great effect in modern software. But genuinely curious about alternative ways to solve the same problems.
I've definitely noticed the trend towards more and more functional programming these days. I doubt it's simply a case of "just use FP and there are no more problems".
Rust, Go and javascript are three languages that are moving away from the OOP paradigm. None of those three languages are classified as functional.
>Is there some resource you can point to that says in the past when faced with situation X developers tended to use pattern Y, these days that has been superseded with way of doing things Z?
While I don't agree with a lot of it, I think it sums up my opinion really clearly. It's not about DP's but because DP's focus around OOP and the video is a criticism of OOP therefore the arguments apply to DPs.
Thanks. I've observed this as a general trend too. I'm starting to become more and more interested in the functional way of thinking.
The image you linked it interesting. I want to dive more in on the how/specifics. I don't necessarily buy the argument it's trying to make that "just make a function and you no longer have a need for factory pattern". You're trying to accomplish something fairly specific with that. Functions compose, I could see how there are properties they have that can be leveraged to achieve the same goal, but I'm guessing the functions you write or the way you write functions to achieve each of those specific aims likely differ in subtle yet important ways. I'm very interested in those details.
>I don't necessarily buy the argument it's trying to make that "just make a function and you no longer have a need for factory pattern".
The same pattern is achievable with functions but the implementation is so trivial in FP that it doesn't even need a name:
Just have a function return another function. That's a function factory.
Same thing with dependency injection:
Just have a function take another function as a parameter.
Outside of this I wouldn't even recommend either pattern at all. It's bad practice in all paradigms. Only have data flow through your execution path, don't have new "execution paths" flowing through your execution paths, such architectures tend to be over-engineered.
Do you have a good example of a reference architecture or implementation of a non-trivial system you can point me to?
I've recently gotten a copy of the book Domain Modelling Made Functional. I'm yet to read it, but I'm pretty intrigued by some of what I've seen and I have heard it comes highly recommend.
I'd be very keen to hear of other high quality examples of things people consider good reference material.
Functional programming is rare. It's sort of like the PS3 when it came out. Better specs across the board but harder to use and understand so it's hard for me to point to production level examples. Facebook does have one big project done in haskell you can look into that. Also whatsapp is done entirely in erlang.
Also note that the trend I see in the industry is not exactly movement towards functional programs but more movement towards borrowing features popular in functional programming as well as getting rid of classes.
I agree with crimsonalucard but for different reasons. This book is catalog. It's like reading a dictionary from start to finish. This becomes dull fast and you don't learn efficiently. Sure you can just use it to look a pattern up once in a while but then again you might as well read the Wikipedia article.
Based on your Best Books list, check out David Goggins book 'Cant Hurt Me'. I found him through a podcast he did with Joe Rogan and it resonated with me on a deep personal level. It ultimately inspired me to change my life: I lost 50 lbs since, got a raise and promotion at work and travelled more in 2019 than the last 5 years.
Can't hurt me was so masochistic that after 50% of the book I started thinking why is he doing "that much". It's a good book no doubt. It makes you feel that limits are just in mind. But I've to give it a break after hearing (audible) 66% and will return to it later :)
