- 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.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...
complexity(system) =
sum(complexity(part) * time_spent_in(part)
for part in system)It's ok to be passionate about a topic, but also understand if that topic is still relevant in 3-5 years.
And, for what it's worth, following my own advice (I wouldn't give it otherwise), I haven't had major problems finding work. I live a comfortable life: own a house, have a wife and a kid, with another on the way...
Actually, knowing what it's like out there for a generalist programmer, I feel maybe more recession-proof with my highly specialized skill set (knock on wood). There are fewer jobs out there for me, but when I apply to the ones that are available, people tend to be interested in talking to me.
Of course, one thing that helps that I didn't mention in my original list: aggressively network with the other people who do the same thing that you do...
My personal favorite was always the one about "English is just a programming language", but when I read the 20th anniversary edition that one seemed like it had been toned down? I did not go back to find the original one to compare, but the way I remember it it was pretty hardcore about keeping text as text and using tools like for programming (use macros in text to avoid repeating yourself etc).
Overall the 20th anniversary did feel a bit less idealistic? I guess for a "pragmatic" book that makes sense, but I remember the original like it was making stronger arguments for or against things. I really liked the (anti-)IDE chapter, or the parts on the importance of learning how to use a good text editor well, for instance, but now they basically cut that out. Did give me the impression that they were trying to be down with the kids at times.
I started using Emacs 15+ years ago because you can easily make it into an IDE, but it works for any text. Essentially it's like learning to use a kitchen knife vs buying a mincer, a grater, a food processor, a mandolin, and whatever other single-purpose tools they're peddling at the kitchen shop today.
Since then, the Emacs way has caught on. I see stuff like Atom and VSCode as just vastly inferior forms of Emacs. They can all be text editors or IDEs if you want them to be.
AFAIK, all the hate from IDEs at the time came from the way Eclipse and the Microsoft ones work, and all the love came from the Borland ones. As Borland failed, the "correct" opinion became obvious, but it was actually only correct by accident and didn't reflect any inherent properties of the software.
I am curious if they did change that much, or it is just peoples memory and nostalgia playing into the impression.
I do still encourage people to learn C only because you could understand how the language works or a long weekend and it will help you appreciate just how things actually work under the hood (and a bit above the assembly instructions level). And TPP is great for helping you understand what to do when actually working on a deliverable project and not just the exciting parts. It’s the difference between building a toy that runs on your machine and a project others can run and use.
You might think that coming from K&R, I wouldn't have liked my second and third books, which were two of the first Head First series. They took essentially the opposite approach from K&R, but I enjoyed them too and learned quite a bit. Something about the content lended itself to a more visual approach to the material (maybe the nature of OOP).
But K&R was the first book that I read that made me feel like I fully understood what was happening. Of course I was missing a lot of nuance a a bunch of abstraction layers that I learned about later but that book felt very self-contained. I read the first time it when I think I was 25 or 26 and at 39 I might want to do a refresher.
I really wish they'd do a revised 2nd edition using Golang as the base for the book instead of C; but otherwise it still really holds up well
And good news: it's been open sourced: https://freecomputerbooks.com/Expert-C-Programming-Deep-C-Se... and its well regarded on Hacker News https://hackernewsbooks.com/book/expert-c-programming-deep-c... .
There are several links to PDF versions of the book. None of them include either a copyright page or a statement that it's been released as open source.
The author's own website <https://afu.com/> includes errata for the book, but doesn't provide or mention a free copy.
A free sample of the Kindle version of the book does include a copyright notice. A book published in 1994 is not public domain unless it's been explicitly released.
Something that appears to be a legitimate PDF sample (not the while book) is here:
https://ptgmedia.pearsoncmg.com/images/9780131774292/samplep...
Also, Dave Thomas, one of the authors, is looking for a job.
> So, I'm looking for a job!
> Internal or external consultant, devrel, training, team fixing, design, architecture. WFH or travel the world.
> So, if you know any company that has a Dave-shaped hole, please email me. Some more about me on my site. Links below.
> Many thanks.
> email: dave@pragdave.me
The other one is "Code Complete".
https://newsletter.pragmaticengineer.com/p/code-complete-wit...
Out of the classic broad books that get recommended all the time, this is one of the best IMO. I really don't like Clean Code (Martin's follow up, Clean Architecture is fantastic, though). Refactoring by Fowler is also a great generalist language and system book (but a specific topic).
One of the smartest takeaways from all of this, which keeps getting proven over and over.