Steve McConnell(deprogrammaticaipsum.com)
deprogrammaticaipsum.com
Steve McConnell
https://deprogrammaticaipsum.com/steve-mcconnell/
41 comments
> It's not that these books are bad, or out of date. It's more that they exposed some new ideas at the time that, to the books credit, have been picked up and made mainstream or basic/required knowledge for the working programmer
What books do you recommend though to get novice (or not so novice) programmers up to speed? IMO there is a lack of modern literature and general introductory material to the kind of wisdom you otherwise only get after decade(s) of software development (if at all, for quite a number of people).
A recent one I liked is “A Philosophy of Software Design”, but it only covers so much ground, and some of its advice requires further qualification.
What books do you recommend though to get novice (or not so novice) programmers up to speed? IMO there is a lack of modern literature and general introductory material to the kind of wisdom you otherwise only get after decade(s) of software development (if at all, for quite a number of people).
A recent one I liked is “A Philosophy of Software Design”, but it only covers so much ground, and some of its advice requires further qualification.
Pragmatic Programmer, Art of Unix Programming, and Code Complete (in that order because of page count) are the books that I recommend these days to junior devs
> Reading these books after 20 years of programming I found that I really struggled to find anything useful to take away from them.
I believe this is the highest compliment a book can receive. When reading it the first time makes a big difference and the second time doesn't, it means it was so well written that you internalized it completely.
I believe this is the highest compliment a book can receive. When reading it the first time makes a big difference and the second time doesn't, it means it was so well written that you internalized it completely.
I totally agree. Code Complete was my road map to a new field, full of recommendations for other books to read. I gave away my first two copies of the first edition, and eventually bought the second edition. It didn't have the same magic. I've looked for it in other books, like The Pragmatic Programmer, The Practice of Programming, and others, but it's like The Sixth Sense (or The Crying Game or The Usual Suspects): you can only see it for the first time once.
I loved code complete and it made me a better programmer and for a while everything was great. Then along came complicated frameworks, multiple languages, the chaotic HTML/JS/CSS world, k8s, yaml, dependency injection, functional and OO mixed together and it feels like Code Complete is too naive in this crazy new world. Most of the normal world seems terrible to me.
I wonder what Steve would think of it. I didnt even know about "More Effective Agile", maybe it'll tell me.
I wonder what Steve would think of it. I didnt even know about "More Effective Agile", maybe it'll tell me.
Similar thoughts. I have worked with some folks who basically just do 'java' all day. It's a web app, but there's a team who gets to pretty much do just 'java' - little to no web stuff, little SQL (that's another team), and... There have been times over the years when I've been envious of that type of situation, but then I think I'd hate it. But I sort of hate the current state working across all things web.
You forgot 'SQL' (or broad 'data management and access'), as well as security and performance stuff in your list above.
I don't want to be a 'stick in the mud' but.. I also resist some of the newer/shinier things, precisely because they don't always stick around (and I've been burned). But also, I don't really have time/bandwidth to be an expert. Doing server mgt, security, etc half-assed, by just following a couple of readmes... that can lead to lots of trouble.
You forgot 'SQL' (or broad 'data management and access'), as well as security and performance stuff in your list above.
I don't want to be a 'stick in the mud' but.. I also resist some of the newer/shinier things, precisely because they don't always stick around (and I've been burned). But also, I don't really have time/bandwidth to be an expert. Doing server mgt, security, etc half-assed, by just following a couple of readmes... that can lead to lots of trouble.
For me code complete helped me write decent code around these things.
No framework will write your business logic.
As an asidev there's a really stand out section called Table Driven Methods, he shows how to go from nested if hell to so simple it's mind boggling. Also on the way he detours into the OO approach which doesn't help simplify things at all. I've never seen anything like this advice anywhere else. Also for beginners just explaining how to name functions and variables is great. In fact I worked with a so called senior dev who was naming things terribly.
Code Complete is a great book
It is not overly opinionated, it is direct, it tries to support the statements it makes.
It does not tell you a great story or tries to play you. It is what it is. And still it's a great reference.
It's the anti-Uncle Bob, which tries to manipulate you and convince you of his way being the best way.
It is not overly opinionated, it is direct, it tries to support the statements it makes.
It does not tell you a great story or tries to play you. It is what it is. And still it's a great reference.
It's the anti-Uncle Bob, which tries to manipulate you and convince you of his way being the best way.
FWIW, one useful tidbit from Uncle Bob that I keep thinking about is how the number of working programmers has doubled every five years.
http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html
That insight helped me calm down quite a bit. Because noobs are being produced faster than best practices can percolate. Per Mark Twain's quip about lies racing half-way around the world before truth can get its pants on, every generation thinking they invented sex, and how people are generally emotionally attached to their first notions (no matter how wrong).
(So if your introduction to computing is thru Python, PHP, JavaScript or whatever, it's super hard to see their flaws, or to appreciate what their precedents were trying to achieve.)
http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html
That insight helped me calm down quite a bit. Because noobs are being produced faster than best practices can percolate. Per Mark Twain's quip about lies racing half-way around the world before truth can get its pants on, every generation thinking they invented sex, and how people are generally emotionally attached to their first notions (no matter how wrong).
(So if your introduction to computing is thru Python, PHP, JavaScript or whatever, it's super hard to see their flaws, or to appreciate what their precedents were trying to achieve.)
I appreciate Uncle Bob's opinionated approach. The easy path would be to remain agnostic on which way is best. But that often, at least for me, results in design paralysis as I try to figure out that magic best way to organize a project or accomplish some task.
Instead, if I start with an opinion, I'm able to make immediate progress even if I end up refactoring down the road for some reason or another.
Of course there's no single write way to organize projects and write software. But one mediocre way that makes sense to me right now is often preferable to 10 better ways that I don't yet understand.
Instead, if I start with an opinion, I'm able to make immediate progress even if I end up refactoring down the road for some reason or another.
Of course there's no single write way to organize projects and write software. But one mediocre way that makes sense to me right now is often preferable to 10 better ways that I don't yet understand.
I like Clean Code and Code Complete.
Clean Code has a narrative and is opinionated. It explains the experiences that formed those opinions. It is a better read.
Code Complete is dry, academic, and comprehensive for its scope. It references many studies and is well documented. It has opinions too of a sort. It is a better reference.
Thinking of function length - Clean Code says short functions are good. Code Complete references studies that say it is not long functions that are bad, it is functions using too many objects/variables that are bad. This of course has an indirect effect on function length. So I keep this in mind, and both books are helpful.
I read a bunch of Uncle Bob's books and usually don't mind him being opinionated, although I did think the opinions in Clean Coder got to be too much. Although not all of it. Recently I have been mulling the idea from that book that there should be zero regressions. I think there is something to that, if you start to accept there can be 2-3 regressions per sprint, then why not 5-7? Why not 10? I agree with him that acceptance of regressions is a problem.
Clean Code has a narrative and is opinionated. It explains the experiences that formed those opinions. It is a better read.
Code Complete is dry, academic, and comprehensive for its scope. It references many studies and is well documented. It has opinions too of a sort. It is a better reference.
Thinking of function length - Clean Code says short functions are good. Code Complete references studies that say it is not long functions that are bad, it is functions using too many objects/variables that are bad. This of course has an indirect effect on function length. So I keep this in mind, and both books are helpful.
I read a bunch of Uncle Bob's books and usually don't mind him being opinionated, although I did think the opinions in Clean Coder got to be too much. Although not all of it. Recently I have been mulling the idea from that book that there should be zero regressions. I think there is something to that, if you start to accept there can be 2-3 regressions per sprint, then why not 5-7? Why not 10? I agree with him that acceptance of regressions is a problem.
> It is not overly opinionated, it is direct, it tries to support the statements it makes.
Totally. I appreciated that he actually cited actual studies of commercial software projects, such comparisons of defects found in code reviews vs tests or defects vs function length.
Totally. I appreciated that he actually cited actual studies of commercial software projects, such comparisons of defects found in code reviews vs tests or defects vs function length.
What books of Bob's do you think manipulate you? Specifically the books, rather than blog posts or tweets.
> Reading these books after 20 years of programming I found that I really struggled to find anything useful to take away from them.
This seems a fairly common refrain in the comments. Am I the only one who forgets things? I have to reread things to keep the ideas crisp in my head.
Oh well!
This seems a fairly common refrain in the comments. Am I the only one who forgets things? I have to reread things to keep the ideas crisp in my head.
Oh well!
Totally agree, and had the thought this somehow is what happened to Sun Microsystems : what was special about their unixes was so successful, and reincarnated largely with updates in Linux, that it's the current norm. Similarly for NeXT.
Same. Once I started as a back-end dev, a mentor gave me his copy. I still have it, but have passed on v2 copies a couple of times.
I still have my copy of Code Complete 2, and considered it a huge boost as well.
I've got to remember to revisit it soon.
I've got to remember to revisit it soon.
I can't understate how important Steve McConnell's writings have been to my software career. Many years ago I was just a young developer completely immersed in tech and algorithms, but I was frustrated that the teams I was involved with weren't better at making software. Code Complete, Software Project Survival Guide, and his other writings really helped me appreciate how important craftsmanship, design, process, and forethought are to a project's success.
I've never been under the impression that he figured it all out on their own, or that they captured the end-all, be-all of how to make software. Some of the things he wrote about have evolved tremendously over the years. But I still get incredible value of revisiting those books and reinforcing better engineering practices and habits he evangelizes.
I've never been under the impression that he figured it all out on their own, or that they captured the end-all, be-all of how to make software. Some of the things he wrote about have evolved tremendously over the years. But I still get incredible value of revisiting those books and reinforcing better engineering practices and habits he evangelizes.
You mean overstate.
For some reason, I've been noticing this mistake more and more lately.
For some reason, I've been noticing this mistake more and more lately.
Yep. That's what I was thinking, but not what I wrote. Sincerely thanks for pointing that out.
Most of us couldn't care less. Or could we? I forget which.
OK, I'll bite. :-D
If you say you "couldn't care less" then you don't care at all, and that's what you are trying to point out (This is the correct version of the phrase, for how it is used in every case I can think of).
Saying you "could care less", means you do care, at least a little (as Weird Al points out in the "Word Crimes" song). Again, in the places where I hear people use one of these phrases, they always mean they don't care at all, and are trying to emphasize that.
Only "I couldn't care less" makes sense for that meaning.
If you say you "couldn't care less" then you don't care at all, and that's what you are trying to point out (This is the correct version of the phrase, for how it is used in every case I can think of).
Saying you "could care less", means you do care, at least a little (as Weird Al points out in the "Word Crimes" song). Again, in the places where I hear people use one of these phrases, they always mean they don't care at all, and are trying to emphasize that.
Only "I couldn't care less" makes sense for that meaning.
That's all true, but I would argue that in practice, the colloquial meaning of "I could care less" and "I couldn't care less" have become the same through usage. Much in the same sense as how "literally" came to mean "figuratively" through misuse, to the point that at least some dictionaries now contain an entry for "literally" that refers to the sense here it mean "figuratively". #headexplode
Yeah, I figured that would be mentioned. I just personally don't agree that it's OK to say "well, everyone means 'empty' when they say 'full'".
When the phrase you are using quite literally (hehe) means the opposite of what you mean, that's just abuse of the language. Unless, of course, you are trying to be sarcastic (which is never the case with saying "I could care less").
I feel the same way about literally/figuratively, and at least figuratively (hehe-2) roll my eyes on that one regularly.
When the phrase you are using quite literally (hehe) means the opposite of what you mean, that's just abuse of the language. Unless, of course, you are trying to be sarcastic (which is never the case with saying "I could care less").
I feel the same way about literally/figuratively, and at least figuratively (hehe-2) roll my eyes on that one regularly.
Yeah, I hear ya. I'm definitely not happy with the current state of affairs myself. I'd like to think there can be some level of precision in our use of language. But sadly, the rest of the world don't seem to care what you and I think. :-(
Ya. I loved Code Complete v1. Loved it. Such a great snapshot of a period in time.
Mostly, Code Complete is a model for how to think about thinking, a self examination, how to do introspection.
A current superior example of this strategy is Dan Luu. IMHO.
Mostly, Code Complete is a model for how to think about thinking, a self examination, how to do introspection.
A current superior example of this strategy is Dan Luu. IMHO.
Dan’s writing is really informative. I also really admire the way that he uses Twitter. I’ll often see a recent tweet from him that is part of a long running topic thread that he appends to when he has something new to say.
I was surprised to see no mention of "Software Estimation" which I found to be a useful, if dry, book when I was struggling with how to estimate software in a better fashion.
I've been debating on getting my team of engineers a book as a gift, with Code Complete or Pragmatic Programmer as high on the list. Trouble is, as others noted, they're best when you're starting out and less helpful later in your career.
Does anyone have any books they recommend for senior engineers (approx 10 years experience)?
Perhaps it's harder to recommend one book because by that time generalized knowledge should already have been absorbed.
Does anyone have any books they recommend for senior engineers (approx 10 years experience)?
Perhaps it's harder to recommend one book because by that time generalized knowledge should already have been absorbed.
I would highly recommend Refactoring by Martin Fowler. Out of all the books I've read and been exposed to, that one stuck with me the most over the years.
"A Philosophy of Software Design" by John Ousterhout - a recent find and probably the best book on programme design I've ever read. Author is an experienced programmer and Computer Science professor at Stanford.
Are there any other author's similar to Steve McConnel?
Someone who writes a book with pragmatic advice, based on real life research, focused on delivering projects quickly, on time, and with few defects?
Instead it feels like almost all the writing in software is evangelizing.
Someone who writes a book with pragmatic advice, based on real life research, focused on delivering projects quickly, on time, and with few defects?
Instead it feels like almost all the writing in software is evangelizing.
I would say Scott Ambler. His book "building object applications that work" was amazing and it helped me understand how to design systems
I guess "The leprechauns of software engineering" by Bossavit would fit. I've only read the free chapter myself though :-)
Good question.
Yes. Old but gold. Brian Kernighan. Jon Bentley. Google them and their books.
Yes. Old but gold. Brian Kernighan. Jon Bentley. Google them and their books.
You'll find many in his bibliography. Start with those, see who cites them, and McConnell.
Wholeheartedly agree with recommendations for Kernighan and Bentley. I think there's one Kernighan book I don't own, and they are all gold (if old.)
I'd suggest anything and everything written by Gerald Weinberg, starting with what looks most appealing to you now.
'Making Software', edited by Wilson and Oram is chock-full of the latest research of its day (10 years ago.) It's dry, but it presents work of some top SE researchers. Following that group on twitter/Google scholar would bring you to the edge of what is studied in SE research.
I'd suggest anything and everything written by Gerald Weinberg, starting with what looks most appealing to you now.
'Making Software', edited by Wilson and Oram is chock-full of the latest research of its day (10 years ago.) It's dry, but it presents work of some top SE researchers. Following that group on twitter/Google scholar would bring you to the edge of what is studied in SE research.
I really like John Lakos who has written a few books on large scale C++ projects. Very practical material. I don't know how well it translates to other languages but they have been very helpful for my C++ projects. His books are based on his extensive real-world experience in this domain, both for EDA software and Bloomberg.
*I have no association with him whatsoever.
*I have no association with him whatsoever.
One of the best (if not the best) books for developers.
Has anyone here read the books in his recommended reading list in Code Complete v2? I'm curious which ones are still relevant.
Having read it a few times since I think it falls into the same group of books as Mythical Man Month, Peopleware, and the Pragmatic Programmer where the earlier in your career you read it, the more you'll get from it.
Reading these books after 20 years of programming I found that I really struggled to find anything useful to take away from them.
It's not that these books are bad, or out of date. It's more that they exposed some new ideas at the time that, to the books credit, have been picked up and made mainstream or basic/required knowledge for the working programmer