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.
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.
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...
What I'm describing is actually the exact opposite of being a hipster. From the dictionary, a "hipster" is "a person who is unusually aware of and interested in new and unconventional patterns (as in jazz or fashion)".
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...
Yup. There is certainly an element of strategy that enters into it. Doubling down on a single programming language or piece of tech is probably not a good idea. Maybe doubling down on a niche field or subject is...
It is? I often find that I work really well with people who are highly adaptable generalists. They help me get random things done that I'm slow at, I help them get highly specialized things done that they're slow at.
Not only are they not mutually exclusive, but if we're being honest, only idealistic programmers care enough to read Pragmatic Programmer, and they read it in the process of becoming a master.
When the first version came out, around the time I got my first job, it felt like everyone around me had read this book, and for a long time we were throwing around quotes from this book. Sadly after a few years it felt like the only thing that really stuck in the larger community was "Don't Repeat Yourself", which wasn't really something that at the time stood out as much more important than many of the other "rules".
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.
Twenty years ago, I was strongly anti IDE and pro text editor. In the last ~10 years or so text editors have gained features previously only found in IDEs and IDEs have improved their performance and brought in features from text editors. I would argue the distinction between text editors and IDEs at this point is academic.
The main difference is "IDEs" typically contain custom, ad hoc text editors in them. They don't allow you to build transferable skills that can be used to edit any text. People who use them will typically use some other editor to make documents, another one for their notes, and one per programming language.
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.
>People who use them will typically use some other editor to make documents, another one for their notes, and one per programming language.
I'll never be convinced that that is a bad thing. And honestly, by the time you make emacs have the features that dedicated editors have, it's not emacs anymore anyway.
Well, cutting the IDE out may happen because IDEs improved.
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 have read a number of programming books but the only two that really stood out to me and that I still remember are The Pragmatic Programmer and K&R The C Programming Language. They are obviously very different but foundational in ways that enabled me to get a lot of things done.
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.
My first programming book was K&R as well. It was an excellent introduction to programming.
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).
It was technically not my first. Really my first was around age 6 or 7 and it was a companion to my grandfather’s Pravetz 8D which had a listing of BASIC commands and I think like 20 or so listings of programs. His students had also programmed a few games that he had copies of which were cool. I ended up trying to modify them and writing some of my own but that’s how I got into this whole thing.
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.
The book that's really stood out to me is the Kernighan/Pike "The Practice of Programming" as something that steered me in a really good direction when I was first learning to write code.
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
I know that there are many reasons for people to work after 65. I also know that sometimes life takes surprising turns. But it makes me nervous to see people so capable as Dave that are well known in our industry looking for a job. What is the hope of the rest of us ? I love software engineering but I still hope to be able to retire to work on my own projects.
When I started a programming job, I read this book, Clean Code, and Code Complete. Code Complete is kinda old but still great, Clean Code is not bad but it's Java centric and has a lot of questionable tips. But The Pragmatic Programmer never gets old.
I got on very well with Van der Linden's Deep C Secrets. It's from 1994, so misses out on the newer versions, but aside from that it's aged well, IMHO.
Are you sure it's been open sourced? I'm reasonably sure you've linked to a site offering pirated copies.
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:
I bought the first edition when it came out. I was just 3 years into my SW development career and it provided a lot of good advise. I bought the second edition and enjoyed it, but the first edition had a special place in my heart.
A great book, but I read it too late, after I had already learned pretty much everything it says the hard way. So it was one of those books I enjoyed because it reinforced what I already thought, but didn't really get much from. Wish it had been written a decade earlier.
I'd say learning things on your own, even if they take time, is still better as you don't have to actively force yourself to develop that mindset. We often rush towards our goal without realizing how important the journey (small steps) is. Isn't reaching the goal more worthwhile if you have enjoyed the journey along the way? Isn't that what it means to be human?
If you are into podcasts Steve McConnell (the author) was a guest a couple of months ago on the pragmatic engineer podcast. My one take away from that podcast was just how young and new in his career he was when he wrote that book.
Yes. And if you read his other books, you'll see that he was trying to create positive change in programming over and over again, but steadily climbed what part of the organizational ladder he was trying to address.
That book, being the first, is pretty squarely aimed at shortening the journey from junior programmer to senior.
I don’t know why seasoned veterans praise these books and then implement some of the worst interview practices to test people on writing convoluted bs code for hours. Just doesn’t make sense. Do you want to hire pragmatic programmers or monkeys?
It's a very solid broad programming book! I thought it was going to be too generic or over hyped, but it was solid. That said, I do find the most interesting software books to be about specifics, but that's nothing against this book.
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).
An incredible book. One very near and dear to my heart. It always sits on the bookshelf behind me with pride of place in every video call or conference.
Have the first edition and I had the PDF version before the print was released I'm pretty sure... it was a thing with those Ruby/Pragmatic books when they were 'in development'. Still have my K&R The C Programming Language from 97 with my notes in it.
Was it this book that introduced YAGNI? (You Ain't Gonna Need It). I feel like it was back around peak Rails hype in 2009 that that was bandied about a lot.
I’m really glad I got it after stumbling across the original at my university library. It’s really nice reading it from time to time and getting inspired to become a better developer
Alternatively, consider being an idealistic programmer!
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.
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...
This model of complexity from the book is very useful:
For me “the problem with software, why smart engineers write bad code” is the prequel. Not as technical, but explains a big problem
It's very good. And quite short!
Thanks, purchased.
Redundancy groups are full of idealists.
It's ok to be passionate about a topic, but also understand if that topic is still relevant in 3-5 years.
Being an idealist doesn't excuse you from being a realist.
Did that, doesn't pay. Being a technology hipster is like being a master of jazz, it doesn't pay, so you sell out and play pop music.
What I'm describing is actually the exact opposite of being a hipster. From the dictionary, a "hipster" is "a person who is unusually aware of and interested in new and unconventional patterns (as in jazz or fashion)".
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...
I tend to agree with everything you said.
Was just thinking of this
" - Fall in love with a single topic, regardless of how trendy. "
Sounded hipster.
Fair! Personally, I'm not sure how you can get good at something if you aren't at least a little in love with it.
Here's another take: https://www.youtube.com/watch?v=75Ju0eM5T2c
All comes down to whether or not you picked a topic that will be financially viable several years later.
Yup. There is certainly an element of strategy that enters into it. Doubling down on a single programming language or piece of tech is probably not a good idea. Maybe doubling down on a niche field or subject is...
All those who fell in love with Silverlight, Flash or UWP likely agree with you
Yeah, but what were they doing with these tools?
Over specializatoin is the enemy of adaptation.
It is? I often find that I work really well with people who are highly adaptable generalists. They help me get random things done that I'm slow at, I help them get highly specialized things done that they're slow at.
Yeah, we need both types.
I get you're comparing philosophies but none of those suggestions are mutually exclusive to the lessons taught in this book.
Not only are they not mutually exclusive, but if we're being honest, only idealistic programmers care enough to read Pragmatic Programmer, and they read it in the process of becoming a master.
Amen
When the first version came out, around the time I got my first job, it felt like everyone around me had read this book, and for a long time we were throwing around quotes from this book. Sadly after a few years it felt like the only thing that really stuck in the larger community was "Don't Repeat Yourself", which wasn't really something that at the time stood out as much more important than many of the other "rules".
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.
Twenty years ago, I was strongly anti IDE and pro text editor. In the last ~10 years or so text editors have gained features previously only found in IDEs and IDEs have improved their performance and brought in features from text editors. I would argue the distinction between text editors and IDEs at this point is academic.
The main difference is "IDEs" typically contain custom, ad hoc text editors in them. They don't allow you to build transferable skills that can be used to edit any text. People who use them will typically use some other editor to make documents, another one for their notes, and one per programming language.
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.
>People who use them will typically use some other editor to make documents, another one for their notes, and one per programming language.
I'll never be convinced that that is a bad thing. And honestly, by the time you make emacs have the features that dedicated editors have, it's not emacs anymore anyway.
Well, cutting the IDE out may happen because IDEs improved.
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.
That's because being strongly opinionated about anything nowadays is viewed down.
But was it actually changed? Or was it a memory of a strong opinion that upon re-read years later, wasn't that strong of an opinion?
I am curious if they did change that much, or it is just peoples memory and nostalgia playing into the impression.
I have read a number of programming books but the only two that really stood out to me and that I still remember are The Pragmatic Programmer and K&R The C Programming Language. They are obviously very different but foundational in ways that enabled me to get a lot of things done.
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.
My first programming book was K&R as well. It was an excellent introduction to programming.
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).
It was technically not my first. Really my first was around age 6 or 7 and it was a companion to my grandfather’s Pravetz 8D which had a listing of BASIC commands and I think like 20 or so listings of programs. His students had also programmed a few games that he had copies of which were cool. I ended up trying to modify them and writing some of my own but that’s how I got into this whole thing.
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.
The book that's really stood out to me is the Kernighan/Pike "The Practice of Programming" as something that steered me in a really good direction when I was first learning to write code.
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
[flagged]
I second that, absolute favorite
A classic book. I learn something new each time I read it.
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
https://x.com/pragdave/status/1978142569272877078
I know that there are many reasons for people to work after 65. I also know that sometimes life takes surprising turns. But it makes me nervous to see people so capable as Dave that are well known in our industry looking for a job. What is the hope of the rest of us ? I love software engineering but I still hope to be able to retire to work on my own projects.
When I started a programming job, I read this book, Clean Code, and Code Complete. Code Complete is kinda old but still great, Clean Code is not bad but it's Java centric and has a lot of questionable tips. But The Pragmatic Programmer never gets old.
I got on very well with Van der Linden's Deep C Secrets. It's from 1994, so misses out on the newer versions, but aside from that it's aged well, IMHO.
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... .
Are you sure it's been open sourced? I'm reasonably sure you've linked to a site offering pirated copies.
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...
I was given code complete by my first programming manager in around 99 -- maybe he thought I needed to read it heh
[flagged]
We only need to see one comment from you about this, don't we? Please give it a rest.
I bought the first edition when it came out. I was just 3 years into my SW development career and it provided a lot of good advise. I bought the second edition and enjoyed it, but the first edition had a special place in my heart.
A great book, but I read it too late, after I had already learned pretty much everything it says the hard way. So it was one of those books I enjoyed because it reinforced what I already thought, but didn't really get much from. Wish it had been written a decade earlier.
I'd say learning things on your own, even if they take time, is still better as you don't have to actively force yourself to develop that mindset. We often rush towards our goal without realizing how important the journey (small steps) is. Isn't reaching the goal more worthwhile if you have enjoyed the journey along the way? Isn't that what it means to be human?
One of my favorite books on the actual practice of programming.
The other one is "Code Complete".
Code Complete is my favorite, hands down. The Psychology of Computer Programming was also very much worth the read.
If you are into podcasts Steve McConnell (the author) was a guest a couple of months ago on the pragmatic engineer podcast. My one take away from that podcast was just how young and new in his career he was when he wrote that book.
https://newsletter.pragmaticengineer.com/p/code-complete-wit...
Yes. And if you read his other books, you'll see that he was trying to create positive change in programming over and over again, but steadily climbed what part of the organizational ladder he was trying to address.
That book, being the first, is pretty squarely aimed at shortening the journey from junior programmer to senior.
I don’t know why seasoned veterans praise these books and then implement some of the worst interview practices to test people on writing convoluted bs code for hours. Just doesn’t make sense. Do you want to hire pragmatic programmers or monkeys?
It's a very solid broad programming book! I thought it was going to be too generic or over hyped, but it was solid. That said, I do find the most interesting software books to be about specifics, but that's nothing against this book.
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).
An incredible book. One very near and dear to my heart. It always sits on the bookshelf behind me with pride of place in every video call or conference.
> Keep Knowledge in Plain Text
One of the smartest takeaways from all of this, which keeps getting proven over and over.
Have the first edition and I had the PDF version before the print was released I'm pretty sure... it was a thing with those Ruby/Pragmatic books when they were 'in development'. Still have my K&R The C Programming Language from 97 with my notes in it.
Was it this book that introduced YAGNI? (You Ain't Gonna Need It). I feel like it was back around peak Rails hype in 2009 that that was bandied about a lot.
I’m really glad I got it after stumbling across the original at my university library. It’s really nice reading it from time to time and getting inspired to become a better developer
One of the best book on software as a craft - read it couple decades ago and still recommend it to anyone who wants to be good in this craft!
The best programmer book i've ever read
My first programming book was The ZX81 Basic. The best I ever read.
[flagged]
Why did you repeat this comment all over this post?
Their "AI agent" did it.
Maybe the author