I had planned to write on the topic. In his book, Steve McConnell advocates for PPP = Pseudocode Programming Process
Basically, he says you should outlines the structure of your code first, before writing your actual code.
IMHO this is even more relevant in the age of AI assisted programming. Pseudocode Programming Process is becoming Prompt Programming Process.
The process is the same, it's just the tooling around it that has evolved.
It didn't have to be completely correct, but it did need to be directionally correct (or, at least illustrate a way of solving the problem, even if we ended-up doing it differently)
I poo-pooed those, and would only create my pseudocode after writing my program - I'd already "been programming" for close to a decade, so why go through the 'pointless exercise' (as I thought at the time) of designing a solution only to have to implement the solution?!
Then I left those intro classes and we started getting more-interesting assignments
All of a sudden, having a plan - even a very simple block diagram, or set of bullet points, etc - became vital to solving the problem
I don't know that I'd tell someone to fully pseudocode their solution before implementing something today ... but blocking it out, getting the high- and medium-level logic/parts drawn-out/written-down is most definitely vital to having a chance at a successful implementation
I then keep the pseudo code as comments in code and go from there.
But I don't know others are doing the same. I'm a pretty mediocre programmer so I have to do it a lot.
I have never seen people write pseudo code as part of the programming process.
Diagrams, comments, tests, stubs sure, but never really pseudo code.
I do it to structure my code, but I remove the comments as I implement it because I try to make it obvious in the code what's being done. You know, regular good programming, pick good names, keep the code reasonably short, add comments when needed, etc.
The same way you won't see the detailed outline of a writing once it has been written. Yet, the author likely started with an outline.
I mean if it's just a few lines, a change to existing code, etc, you can jump straight in with actual code.
But if it's a new object/module etc, start by writing some function names, and some rough structure within them, etc. All in IDE/editor. And I wouldn't call it pseudo-code, just a rough outline.
Hate to break it to you ... but those are all forms of pseudocode (or verification of your process (which is nearly the same thing)) :)
That book hasn’t aged as well, but it had some parts that are still quite relevant, today.
I always thought that Rapid Development was better than Code Complete.
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.
A lot of folks around here don’t seem to like him, which I find odd.
I would assume the author just hadn't had much exposure to those ideas so they weren't even considered for inclusion. (Besides, they tend to not be researched so actively because they don't leave as many paper trails.)
Other than that gripe, though, I learned a lot from it!
Construx eventually developed a curriculum around a fairly “corporate-friendly” version of Scrum, that I never found that appealing.
The way I write code, these days, makes Agile look like Orthodox religion.
However, it’s highly dependent upon me, being who I am, and a lifetime of habit and personal process. It would probably not scale well.
McConnell has always been about introducing process, metrics, and rigor to software development. I don’t think he’d be thrilled with the way I do stuff.
WFM. YMMV.
"Agile Development" (under that name, at least) didn't really appear on the scene til nearly the end of the decade
Precursors to it were there (spiral development, pair programming, etc) ... but kinda hard to write about something that didn't exist yet :)
Code Complete is the "Introductory Level" and Rapid Development is the "Practitioner Level".
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.
It's very hard to rank books precisely, because how much people get out of them also depends on past experiences.
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.
But what's important is not that you pick The Right Book now, it's that you pick up another book when you are finished with this one.
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 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.
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.
IIRC, this book started me on the "meta-rules" of code style, the "what makes good rules", specifically
* aim for readability
* the role that "mere familiarity" plays in readability
* Team style over individual style, org over team, industry over org.
* the small amount (but not zero) of actual data i.e. studies here.
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.
There's a book about modernizing PHP applications that when you read it you feel you are reading about symfony's architecture.
- Rapid Application Development (also by McConnell)
- Soul of a New Machine by Kidder
- Mythical Man Month by Fred Brooks
- Programming Pearls by John Bentley
- Applied Cryptography (2e) by Bruce Schneier
- The Cuckoo's Egg by Cliff Stohl
- Structured Computer Organization by Tanenbaum & Todd
- Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, etc
- A New Kind of Science by Wolfram
And many more could be added to this list
Sure, some of them use acronyms or reference technology that you've either never heard of or has been supplanted
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
Don't get hung-up on specific examples - they're just there to illustrate the problem domain
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.
I work as a data engineer and I always wanted to enforce some rules for the team:
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.
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.
3. Comment the sql queries wherever hacky. There is no way I know why the original author put up some conversions in the code.
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.
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.
Architecture can change quite a bit too - all the async webs make things difficult. Most of the bug reports we get on mobile are not test coverable. e.g. some jankiness when going back to a page, or something like liking a post three levels down and finding that your like was not registered when you go back towards the home screen. We had some bugs like an OS modding text animations, making the text invisible in very niche situations. Then you have combos of ltr and rtl languages and layouts. Adding test coverage can be 4x the effort of writing the code once with no tests, not to mention the architecture for test support making things exponentially more complex.
Maybe we have to rethink what complete code really means.
I read the mythical man month recently and the examples often involving OS/360 development are brutally outdated. I couldn't relate and I had to force myself to finish.
Bentley's Programming Pearls, by that standard, is also "brutally outdated" - but the point of the book is not "how do I make this work in early 1980s technology"
The point of PP is "ask the right question"
The point of MMM is "add resources when necessary; be brutally minimalistic about how many resources are added"
The best way is still, reading and writing lots of code. You'll pick the right way quite naturally.
I'm not done, but many ideas I got from the book made me a better programmer.
