This book is considered a classic but the latest edition was published almost 20 years ago. Is it still relevant? Does it still succeed in its stated goal of bridging the gap between research and commercial software development?
I read it last year and I think it's still relevant.<p>I had planned to write on the topic. In his book, Steve McConnell advocates for PPP = Pseudocode Programming Process<p>Basically, he says you should outlines the structure of your code first, before writing your actual code.<p>IMHO this is even more relevant in the age of AI assisted programming. Pseudocode Programming Process is becoming Prompt Programming Process.<p>The process is the same, it's just the tooling around it that has evolved.
Heck, I still use stuff I picked up from <i>Writing Solid Code.</i><p>That book hasn’t aged as well, but it had some parts that are still quite relevant, today.<p>I always thought that <i>Rapid Development</i> was better than <i>Code Complete</i>.<p>I’ve probably read all of McConnell’s stuff (and I’ve taken a lot of Construx courses). At one time, I was quite the fanboi.<p>A lot of folks around here don’t seem to like him, which I find odd.
I think anything that makes you take a new perspective on (software) product development and reflect on your experiences and pay attention to patterns of outcomes is going to make you a better developer.<p>Even if the book would be hopelessly outdated, that's usually informative too. It tells you which specific parts of the industry change slowly and which evolve rapidly. That will help you figure out where we are headed and what you can count on will be roughly the same for the next 25 years of your career.<p>It's very hard to rank books precisely, because how much people get out of them also depends on past experiences.<p>If you already have the book or can get free access to it -- why not try? Even just the preview on Amazon is usually good to give a sense of what it is like. Read a few chapters and see if it's something you think you want to continue with.<p>But what's important is not that you pick The Right Book <i>now</i>, it's that you pick up another book when you are finished with this one.
It's absolutely still relevant, but it might not be as dominant as it was when first released. By that I mean that the landscape of software development has changed significantly with much more community-driven ecosystems (no longer ~just CPAN) and much more programming is figuring out how to think about choosing the right off-the-shelf architectural components.<p>So, it's relevant and still excellent in guiding you how to write and manage code, but make sure you don't let it lead you to a conclusion that you should write your own code for all aspects of your system.
I'd say it's still a good resource to have; it's not just about programming but about project management, planning, etc.<p>I'd take their recommendations about code style and documentation and whatnot with a grain of salt though, languages, tools and styles have changed since then. Don't skip them, but don't adhere to them religiously; add them to your arsenal of knowledge.<p>It's also a bit of a slog to read front to back, so consider picking one chapter at a time or only looking up a subject you're curious about; I'd consider it more of a reference.
It's in the same group as Pragmatic Programmer, Refactoring, Patterns of Application Architecture and the Gang-of-Four book for me. Still recommended for junior programmers as they're all teaching the core of good design.<p>However seeing as the better frameworks/languages/IDEs have internalised a lot of the learnings and that the specific conventions may be outdated - so just follow the recommendations for your platform/framework.
In my opinion, it's as much a "recommended read" as a lot of <i>other</i> so-called "classics":<p>- Rapid Application Development (also by McConnell)<p>- Soul of a New Machine by Kidder<p>- Mythical Man Month by Fred Brooks<p>- Programming Pearls by John Bentley<p>- Applied Cryptography (2e) by Bruce Schneier<p>- The Cuckoo's Egg by Cliff Stohl<p>- Structured Computer Organization by Tanenbaum & Todd<p>- Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, etc<p>- A New Kind of Science by Wolfram<p>And many more could be added to this list<p>Sure, some of them use acronyms or reference technology that you've either never heard of or has been supplanted<p>But you could [nearly] do a find-and-replace on those "outdated" terms with a "current" term, and the books would [effectively] be up-to-date<p>Don't get hung-up on specific examples - they're just there to illustrate the problem domain
I would still recommend it. Well actually I would recommend Code Complete II as it is the be updated version. I met Steve McConnell in person and have read most of his books. I've found them to be gems.<p>There is a lot of value in reading different things even if you aren't sure about the value to see what you pick up. Sometimes you will learn something or see a situation you never would have expected.
Regarding coding practices:<p>I work as a data engineer and I always wanted to enforce some rules for the team:<p>1. DAGs must have a section that describes what it does and have link to jira ticket and documentation if applicable. Stakeholders should be named too.<p>2. DAGs must have a created by and modified by section with a summary of what they did. Yes we can track changes in GitHub but if we do a lift and shift upgrade of Composer instances all trackable changes are gone.<p>3. Comment the sql queries wherever hacky. There is no way I know why the original author put up some conversions in the code.<p>4. Every etl should check source data before and check loaded data after. Put up some test cases there. For critical processes, failure should always trigger emails and slack message sent to at least two places: DE team and related stakeholder team. God there are SO MANY cases we can get rid the trouble to pick and clean the data because we did not reject obviously wrong source data.<p>5. Think about potential errors. If you have to SUM a column of large integers, watch for overflows. If your column is nullable, watch for unexpected nulls. Such and such.
Most likely no! Do you really need to read a 900 page book to understand how to write good code? There might be nuggets of wisdom here and there, but you'll most likely pick them on your own as you code and grow. Problem with these books is that you tend to over-apply whatever you read. You read the fact that configurations are good, so you create a nest of abstractions to make code configurable, even when it doesn't make sense. This is the stuff that I have seen happen over and over again. Over-engineered crap resulting from programmers trying to make future-proof code.<p>The best way is still, reading and writing lots of code. You'll pick the right way quite naturally.