- The Healthy Programmer
- Clean Code
- Test-Driven Development by Example
What should I add to my library?
* "Compilers: Principles, Techniques, & Tools" by Aho et al. (i.e., "the dragon book")
* "Data Flow Analysis: Theory and Practice" by Khedker et al.
* "Understanding MySQL Internals" by Sasha Pachev.
* "Transaction Processing: Concepts and Techniques" by Gray and Reuter.
* "Fundamentals of Wireless Communication" by Tse and Viswanath.
* "Genetic Programming: An Intrduction" by Banzhaf et al.
* "Applied Crytography" by Schneier.
EDIT: A few additional comments:
(1) Although these books are problem-domain specific, some of them had benefits outside of their problem domains:
* The Dataflow book has some great coverage of fixpoint algorithms. It's really helpful to recognize when some problems are best solved by fixpoint analysis.
* The "dragon book" takes a lot of the mystery out of compilers. That's somewhat helpful when writing code that needs to be fast. It's super helpful if you want to work with compiler-related technologies such as LLVM.
* Understanding the fundamental challenges of transaction processing helps you avoid massive misadventures when dealing with databases or concurrent / multithreaded systems.
(2) YMMV, but I've found it hard to soldier through these books unless I had a need to for my job or for school.
For a good intro of modern back end development, check out Engineering a Compiler. It's also got the lexical and parsing end of things, but a bit better done, but still quite theoretical.
One of the best books I read on programming is "Concepts, Techniques, and Models of Computer Programming"; it's not strictly speaking language agnostic, based as it is on Oz, but Oz isn't a language you'd ever use in production and is a reasonable base to introduce you to ways of programming that will probably be completely unfamiliar, like constraint programming, dataflow, concurrent logic, etc.
As someone who has quite a few books on compilers, program analysis, type theory, etc... I find the Dragon book an irreplaceable reference to this day. It has a breadth of content shared by very few other books. For instance, Muchnick's classic "Advanced Compiler Design and Implementation" is really good for analysis and optimization but neglects all front end topics. The only area where I believe the Dragon book is inadequate in is type theory (I recommend Types and Programming languages [TAPL] by Pierce and Semantics with Application by Nielson for a gentler intro).
As to parsing, its chapter on parsing (4) is not as "hip" has some people want. However, it is solid and will teach you how to do parsing. There are newer and fancier techniques not covered in Chapter 4 but in general most people would benefit just having a solid understanding of recursive descent parsing!
Most programmers don't understand parsing worth a crap, imho. Some compiler theory would do most of us some good. I read it because I was doing data stream parsing back in the olden days before XML (which was before JSON), when we had to write our own stream formats. It really changed my whole way of thinking about a fundamental class of programming problems.
'Essentials of Programming Languages' and 'Types and Programming Languages' are good choices. (But slightly off-topic for this particular subthread, since they don't deal with parsing.)
Try "Parsing Techniques: A Practical Guide" and then a more concise book like Muchnick.
Being familiar with the Chomsky Hierarchy (), and the kinds of language recognizers required for each level in that hierarchy, can save parser authors a lot of wasted time.
E.g., "regex's can't count!"
If you want more resources on Compilers other than books, such as tutorials, guides, talks and papers, then go ahead and check the Awesome Compilers vertical I compiled a while ago: https://github.com/aalhour/awesome-compilers
Wrote many for XML/json based configs.
One of the more famous compiler writers from that era once told me that the Dragon book's original codegen section wasn't even historically how anyone wrote a compiler and it certainly didn't reflect modern practice even back in the 90s.
However, the update significantly improves it with the addition of Monica Lam's contribution. I don't know if it's state of the art for codegen (probably not), but I'm not sure what book is (Muchnick is great too, but this is also quite old now).
Applied Cryptography was an important political statement that we can and should have access to cryptographic technology, but I don't think it can be recommended as an appropriate introduction to the field in 2017.
Also, Donald Knuth's "The Art of Programming" (at least the fundamental and sorting/searching algorithms books), plus a book about graph theory and algorithms.
It's definitely a good idea to have prior general knowledge of database internals before reading an "internals" book.
I'm not sure if it's out of date, but my favorite book on the topic was "Database System Implementation" by Garcia-Molina et al. I found it to be super-readable.
What I like about the "internals" book is you get to see a real, specific database up close, warts and all. It gives you a different perspective from an overview book like the one mentioned above.
Additionally, I don't see how the need to know about the internals of MySQL means one should use a better database. PostgreSQL is normally proposed as the better alternative to MySQL if one sticks to Open Source, and all the good experts at it I have met were familiar with its internals too.
I think your last sentence is what caused me to misinterpret you. I agree with your comment up to "... being a good database.", but I think the point at which you need to know the internals of MySQL are irrelevant to whether you should use a database that is better for the problem you're trying to solve or not.
An equivalent substitution for another database would be fine; anyone have any suggestions? Then again, such a substitution is really solving a non-problem.
IMHO, MySQL is especially ugly due to an attempt to insert an abstract interface around its storage engines. IIRC that interface is leaky, and its documentation is pretty spotty. Also, the InnoDB storage engine has a lot of complexity that seemingly duplicates what's provided on the storage-engine-agnostic side of that interface.
One of the big lessons I took away from studying MySQL's internals, and partially confirmed by the "internals" book, was this: Be careful when designing a plugible storage-engines framework for a DBMS; MySQL has some examples of what can go wrong.
That's something you're unlikely to find mentioned in a generic DBMS-implementation book, but is very good to know about regardless.
2004 is old now? Really?
Honestly, good books don't age as long as their core domain stays valid. Structurally C++ is pretty much the same as when the book came out.
It was written for a different type of developer and a different type of development environment and a specific language, C++.
You haven't looked at C++ lately if you think it's the same as it was in 2004. The ISO has released new versions of the language in 2011, 2014 and ratified a new standard here in 2017. If you're writing C++ code that is consistent with 2004 C++ then you're writing a really bad version of "C with classes", not C++.
Modern C++ contains native support for the filesystem, threads, lambda expressions, variants, upcoming networking library, coroutines (at least in Visual Studio), no more new/delete memory management, parallel algorithms and a ton more. This is a completely different language now and the code you write looks nothing like 2004 C++ code.
Just about all of these things were around in 2004.
"If you're writing C++ code that is consistent with 2004 C++ then you're writing a really bad version of "C with classes", not C++."
I applaud your attempt at an authoritative voice. But you focus on mostly technical trivia that are thin scaffolding on top of the language. I agree modern C++ is nice but it's the same language still.
"This is a completely different language now and the code you write looks nothing like 2004 C++ code."
Are you trolling? This reads like a transcript from a TV commercial.
> I agree modern C++ is nice but it's the same language still.
Well...in the same sense that any language is the same language after you add a bunch of things to it that weren't there before and shift to using those new features as idiomatic parts of the language. I would expect C++ written in 2004 to use different patterns than C++ written in 2017. Not "completely different"...but different.
I would say generally C++ style has evolved through last decades with people understanding class based architecture as an antipattern and data pipelines based on preferably immutable data as the more robust and understandable approach. This has nothing to do with language standards or 'idiomatic' constructs - both can be expressed as perfectly elegant C++, using the '98 or '11 or '17 variant.
But anyway, within this context -
refactoring old code - I would not expect a legacy codebase to resemble 2017 C++ as much as 1997 C++. This is the main reason I find the claim of methods to understand circa 2004 C++ to be outdated to be silly.
That's never been the way that I've read it, and it's not how I meant it. New language constructs allow for more-natural ways for the code to express the intent of the programmer, replacing the use of older constructs in the places that they were clumsy.
The entire point is to make the language more practical. Patterns of use in a language aren't idiomatic because of dogma (or at least, they shouldn't be). They're idiomatic because they're a clear and elegant way (or at least the most elegant way available) to implement something.
> I would not expect a legacy codebase to resemble 2017 C++ as much as 1997 C++.
Agreed, but then we come back to the fact that we might refactor a 1997 codebase differently in 2004 than in 2017.
Well, if the original code is of the worst kind of a mess, Feather's circa 2004 collection of methods to make it more understandable but functionally the same work just fine for the first part of the refactoring. In my experience this is the most difficult part as well. To what dialect of the language the code is ported after it is understandable, is a relatively trivial syntax transform after this.
I speak from experience from having recently had to implement features to a production codebase with millions of lines of code, some of which date back to Fortran, and that took the final step of evolving into C++ sometimes in the late 90's.
I prefer the definition of legacy code that it's any code that does not have unit tests. In this case every transformation to a production codebase needs to retain the original behavior - without exact understanding what that behavior is.
I think this comment should have been my original response to this thread instead of the relatively cheeky responses I wrote earlier.
And Fred Brookes' book is over 30 and sadly just as relevant.
That statement alone, one of the sections of the book, recommending you to allow the compiler to find your errors for you, is an example of the "age" of the book.
At the time I read it, when it first came out, I loved it. I still love Michael's work and advice to this day, but this book was written for another time.
And also it seems to be something lots of programmers don't realize for some reason - many times I had to instruct people to crank up their compiler warning settings and actually read them. Especially in C-land, I can't count the number of times I solved someone's problem by appending -Wall to the gcc invocation and telling them to come back after they fixed all the warnings...
The IDE space has improved a lot since 2004, eg. Jetbrains' tools around refactoring and code cleanup suggestions, make things super simple.
Don't get me wrong, I've read this book, multiple times, it's on my bookshelf and think it's a great book, but it was written when the state of development was a much different landscape, IMO.
Definitely the best book I've read on programming.
I had very rose-tinted nostalgic memories. They did not hold up.
"How to Design Programmes" is a much better book. (But made for rank beginners.) And for the more advanced, "Types and Programming Languages".
See "Why Calculating is better than Scheming" (https://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87....) for a critique.
Don't get me wrong, SICP is still a good book to have read. Just no longer my favourite.
I do not mean this as empty snark; it is something you can see across the board in programming language evolution. It is virtually impossible to propose a new general-purpose programming language today that does not have closure support, which is the biggest thing you're finding missing from C and Java to use the techniques in SICP. (It is not the only thing, but it is the biggest thing.) You'll note Java is going to bolt them on soon, or recently bolted them on, but it'll be another decade before Java is using them fluently either way.
I've often recommend SICP to self-taught programmers; it is not a complete substitute for a computer science education, but it is a concentrated dose of the stuff you're probably missing out on. Expect it to be the work of some months to work through it. However, in the end, a self-taught programmer who has also worked through SICP systematically and carefully is probably a better programmer than 80% of the modern computer science graduates nowadays. (If you want to avoid that fate, oh ye who are still in school, take the freaking compilers course at the very least. Do your peers complain that it is hard? Then maybe it is a good one.)
Had it been optional, I would have been sorely tempted to skip it. But, taking it was probably good for me in the long run :)
Any other general-purpose language you'd be inclined to pick up right now would be fine.
IIRC, you end up implementing a scheme, which you can do nearly in the language of your choice, then the book covers that language you are implementing.
IMO, you're supposed to write your own Scheme to reap full benefits from SICP.
The book contains a recipe for an interpreter that can be transferred to any other language. Chapter 5.4 : The explicit-control evaluator.
Strangely this fact is not advertised that much, I find it to be one of the coollest features of the book.
The implementation is not a direct syntax translation - one needs to figure out how to implement the base susbstrate and how to handle e.g. tokenization, but well rounded software engineer should have some model in ones head how to manage these (so if there are missing pieces this is a good opportunity to brush on those).
It took me a while to understand that, if you’ve been raised on Java or C, these things are not obvious at all.
While it certainly espouses a functional style, I found the greatest lesssons to be higher level, focusing on abstraction.
Though I have limited knowledge of C and Java so would be keen to hear your elaborated thoughts on this.
Also, as a beginner, you don't want both the difficulties of contepts _and_ the difficulties of language to combine to stop you from learning as effectively.
>Also, as a beginner, you don't want both the difficulties of contepts _and_ the difficulties of language to combine to stop you from learning as effectively.
Are you referring to the need to learn Scheme to work through SICP? While the asker specifically requested language-agnostic books, Scheme was chosen as a language for SICP for being a "syntax-free" language...
That's not particularly demanding requirement. The class began with a single lecture about how Scheme worked and after that Hal and Gerry assumed you knew all the language you needed to and dove in.
When the course was introduced (early 80s), most incoming MIT freshman had not programmed a computer (!), including those who planned to do course 6 (EE or CS -- 6.001 was a requirement for either degree).
First-class functions, lambdas, closures, lexical scoping, etc. Abelson wrote, for instance:
"6.001 differs from typical introductory computer science subjects in using Scheme (a block-structured dialect of Lisp) rather than Pascal as its programming vehicle. The subject's developers feel strongly that Pascal is hopelessly constraining, and that important ideas (such as functional programming and object-oriented programming) can be addressed within Pascal only awkwardly, if at all."
no, i'm referring to the fact that this book isn't language agnostic (i.e., you wouldn't want to use anything other than scheme/lisp).
I'd also recommend The Linux Programming Interface by Michael Kerrisk as it teaches so much about what makes modern Unix what it is but.. it's arguably quite oriented around C by necessity. It's not a "C book" by any means though.
- Code Complete by Steve McConnell
- The Effective Engineer by Edmond Lau
- The Pragmatic Programmer by Andrew Hunt and David Thomas
It has good parts. But it has some very bad parts too, when it reinforces myths that, IMO, are very wrong (e.g.: cone of uncertainty, X times better programmer, etc).
I'd recommend to read it with care.
> - The Pragmatic Programmer by Andrew Hunt and David Thomas
After many years I still read parts of it, again and again. And I still like it.
It covers some really foundational concepts like idempotency which programmers don't often think about when architecting systems.
It's about software engineering but also about hardware and some different kinds of design outside of IT.
From an interview about the book :
> Eoin: Your new book does talk about software design in places, but it’s really about design generally, and the case studies span buildings, organizations, hardware and software. Who is the book aimed at? Are you still writing primarily for people who design software or are you writing for a broader audience?
> Fred: Definitely for a broader audience. I have been surprised that The Mythical Man-Month, aimed at software engineers, seems to have resonated with a broader audience. Even doctors and lawyers find it speaks to some of their team problems. So I aimed this one more broadly.
Brooks is also the author of The Mythical Man-Month which is often mentioned on HN.
If you don’t know much about hardware (and maybe even if you do) it’ll change the way you think about computing devices.
- Excellent book that gets into the internals of what developers need to know about SQL and covers each part as it relates to the 4 major SQL databases (Oracle, SQL Server, Postgres, MySQL)
- Also has an online version: http://use-the-index-luke.com/sql/table-of-contents
The Code Book - Simon Singh
- It's just a good read that covers cryptography and message hiding throughout history. Probably a solid book for somebody around high school age.
- Advanced Programming in the Unix Environment by Stevens
- Operating Systems: Design and Implementation by Tanenbaum
- The Art of Unix Programming by ESR
- Parsing Techniques by Grune and Jacobs
- Applied Cryptography by Schneier
Yes. TAOUP has a lot of good content about Unix programming styles and traditions, much of it useful generally. ESR's writing style is a bit heavy / verbose / uses verbal flourishes, but if you can let that not put you off, the book is worth reading. I've read most of it. One of the good sections is about Rules (of programming in Unix, which are not really rules, of course, but informal guidelines developed over many years of experience by many people - ESR has sort of codified them, a thing he tends to do a lot :)
The Rule about separating the interface from the implementation is a good one. I've seen developers at even enterprise companies sometimes not follow it in practice.
> - Parsing Techniques by Grune and Jacobs
Just saw that there is a new edition of this book:
*but be aware that he's a polarizing figure and opinions of his merits differ
(and if you happen to have a differing opinion, please use the reply button instead of the downvote button)
TAoUP is a good book on the Unix Philosophy, but it's worth noting that the ultimate expression of these ideas (Plan 9) was a failure, and the 'everything is a file' metaphor is arguably incorrect. I hope I didn't give the impression that it was not worth reading, especially in the sense that there are few other good sources for that information (even using Unix is not likely to teach you much about its whys and wherefores). I just think that it should be read in the proper context, and that recommendations should try to include that context.
And I'd bet that a lot of programmers wouldn't be working on and with Linux right now if they hadn't have read that book long ago.
Both of them changed my career path from Dos/Windows to Linux
'Facts and Fallacies of Software Engineering', Robert Glass. Glass presents a list of things everybody knows, or ought to know, and gives both academic and opinionated support and/or critique for why they are and aren't so.
'Making Software', Oram and Wilson. An edited collection of papers on evidence-based software engineering.
'The Deadline', Tom DeMarco. A thinly disguised commercial for his advice on how to organize software development teams and organizations, packaged as light, light novel.
Unless you have some understanding of your system's architecture, how it's run in production, and why a production environment is Really Different and a Big Freaking Deal, and how operations is supposed to look like, you'll never be an effective programmer, no matter whether you run your own operations in a small start-up or work for a large enterprise with dedicated operations teams.
Complexity is the single major difficulty in the successful development
of large-scale software systems. Following Brooks we distinguish
accidental from essential difficulty, but disagree with his premise that
most complexity remaining in contemporary systems is essential. We
identify common causes of complexity and discuss general approaches
which can be taken to eliminate them where they are accidental in
nature. To make things more concrete we then give an outline for
a potential complexity-minimizing approach based on functional programming
and Codd’s relational model of data.
I have attempted some of the problems in Lua, Python, Erlang and Ada. It is very doable. So not just for Scheme.
But when I finally opened it up, wow. You can appreciate just how dense the information is. It really reads as if no sentence was written without some purpose of conveying information. Definitely go slow reading this series so you can properly ingest what's written.
I'd say the 'Head First' books are modern equivalents with a similar spirit.
I'd venture that besides recursion, the other key concepts in programming have been pointers and first-class functions. Getting a grasp on these 3 ideas has been essential to learning.
Great short book to get you thinking creatively and how to dissect algorithmic problems, language agnostic with pseudocode examples.
Non-programming but still highly relevant for a professional programmer: Mythical Man Month, and Peopleware.
It's a collection of programming exercises I used when I taught introduction to programming. They start out incredibly trivial, ("prompt for a name, print "hello [name]" back to the screen. But the trivial part is, in my opinion, the fun part when you work with a new language.
That program is a two line program in Ruby. But it might be much more complicated if you implemented that as your first GUI app in Swift for iOS.
I wrote the book to teach beginners, but I and others use those exercises to learn new languages. The book has no answers, just the problem statements.
Teaches you to think simple and elegant.
Even if you don't adopt formal methods in your day-to-day work (often we're not building sky-scrapers) it's a useful book to give you insight into the kinds of questions one should be asking and thinking about when designing software systems.
* The Architecture of Open Source Applications (volumes I and II)
* The Performance of Open Source Applications
* 500 lines or less
One of the most influential programming books I've ever read. The code is in Java, but it's east to follow even for a non-Java developer, and the truths are universal. Learn the most fundamental design and encapsulation patterns. Uncle Bob Martin is a legend. This book has probably made me tens of thousands of dollars.
Any language worth learning has this property of influencing the way you think forever. TDD, Code Complete &co are all very integrated into mainstream industry and are no longer novel. If you find yourself needing to recommend your colleagues to read Code Complete you might consider working on the skills to get a better job.
The Unix Programming Environment was published in 1984. I read it over 20 years later and was astonished at how well it had aged. For a technical book from the 80's, it is amazingly lucid and well-written. It pre-dates modern unix, so things have changed but much that goes unstated in newer books (for brevity) is explicit in UPE. (Plus, the history itself is illuminating.) It gave me a much deeper understanding of how programs actually run over computer hardware. Examples in C are old-school and take a bit of close reading but oh so rewarding. https://www.amazon.com/Unix-Programming-Environment-Prentice...
Mastering Algorithms in C. Another fantastically well-written book that shows (with practical examples) how to implement common algorithms. This is just such a great book!
Code (Petzold). This one is truly language-agnostic. Others have mentioned it already. Can't recommend enough if you're iffy on the internals of computers and programming.
Write Great Code (Volumes I and II). Randall Hyde's books are fantastic explications of the underlying computer operations. Examples are in assembly or pseudo-code but easy to understand.
-How to make friends and influence people. Anyone who works collaboratively with people needs to be able to communicate effectively.
-The Elements of style. Writing understandable code is similar to any other type of writing.
I swear I've had this book recommended to me at least a thousand times, I'm almost suspicious though I don't know that suspicious is the right word
It was written in the 1930s, and has been continuously in print since then. How many books have achieved that honor? That's because it's one of the best books you will ever read. Absorbing its lessons will make you a better person.
Edit: Written in a question-answer style, it’s geared toward luring you into recursion and functional programming.
The algorithms are explained, and demonstrated (in java). But with the knowledge of how the algorithm works you should be able to use them in another language.
(And even though henrik_w already mentioned it, Code Complete2 is a really good book to read!)
Lot's good suggestions in this thread, here's one I didn't see:
"Software Runaways - lessons learned from massive software project failures," by Robert L. Glass.
After I complete this book, I think I'll read his other book: Crafting Interpreters. This one teaches about implementing a programming language from scratch, once in Java and a second time in C.
"Introduction to algorithms : a creative approach" by Udi Manber. ". Great book to learn algorithm design.
It's an old book but the most eye-opening one to me.
Still a worthy topic, still worth your time. As was mentioned about 'The Pragmatic Programmer', I think reading this works best once you have a few years of experience.
But programmers haven't changed much since then. You'll recognize all the weirdness in software work.
This is one of the few truly language agnostic books on programming. SICP is close, but it is limited in relevance at times due to the limitations of a particular language (Scheme).
"Algorithms and Data Structures" from Niklaus Wirth.
"Introduction to Algorithms, 3rd Edition" from Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, Clifford Stein.
"The Garbage Collection Handbook: The Art of Automatic Memory Management" from Richard Jones and Antony Hosking
"Code Complete" from Steve McConnell
"From Mathematics to Generic Programming" from Alexander Stepanov and Daniel Rose
* "Refactoring: Improving the Design of Existing Code" Martin Fowler (978-0201485677)
* "Computer Systems: A Programmers Perspective" Randal E. Bryant (978-0134092669)
Motulsky's Intuitive Biostatistics - this one goes over all the usual methods used in science from distributions to t-test to ANOVA to regressions etc., the basics, but doesn't introduce the maths (you use R for that) but the assumptions and pitfalls of all of those methods.
Statistics Done Wrong: The Woefully Complete Guide - this is all the stuff that's going wrong in applied statistics, a bit short but enlightening
Discovering Statistics Using R - a whopper of a book (~1000 pages?), it goes through everything while also being funny (the constant humor may not be for everyone). Graphs, correlations, regressions, all the MLMs and GLMs, linear models etc. pp., their assumptions, how to run them in R, how to interpret R's sometimes annoying output, etc. pp. Like Motulsky's, but wayyyyy more in-depth on the language's specifics.
Naked Statistics - an intro to stats for laypeople with a focus on politics/economics, good for interpreting and assessing daily news
Any examples of books focused on that? I can't think of any.
Robert C. Martin introduces the disciplines, techniques, tools, and practices of true software craftsmanship. This book is packed with practical advice–about everything from estimating and coding to refactoring and testing. It covers much more than technique: It is about attitude.
If at first sight my may think that they are outdated and superficial, but you can't be more wrong.
I here assume your source code will be read by others; or by yourself after more than three months has passed.
If you want this sort of thing, read a well-respected publication's style guide (e.g., from the AP, NYT or Economist).
The concepts and terminology are absolutely invaluable to understand, but you can pick those up other ways.
"The underachievers manifesto" - a short book that does wonders for your mental health in a world that values productivity and superficial, short-sighted goals over everything else.
Even if you never intend to program in D, I encourage you to read this book to get a different view on metaprogramming, memory safety, and concurrency.
Implementing Domain Driven Design by Vaughn Vernon
Clean Code by Robert Martin
I think you will find some code in all of the books but the ideas are applicable almost everywhere.
If you can, forget about the title and just read it; most of the good stuff in this book is less about objects and much more a fantastic seminar on programming in general.
I've seen the "dragon book" mentioned several times, and I think it (and similar books) are good if you really do plan to (re-)invent a real world, large scale, programming language. If you really just want to get a feel for what's going on under the hood, the language presented in Nand2Tetris is specifically designed to have the necessary complexity to cover most of the details, but not so many special cases that you end up "chasing dragons". And the course is modular enough that you can jump right in and just implement the compiler if you want.
Learning more and more about imperative programming, OOP, design patterns, etc is good, but branching out into declarative programming and the functional and logic paradigms will stretch your mind for the better.
The great thing, I think, about The Reasoned Schemer is that it tackles a complex topic with almost no prose. The whole book is basically one code example after another, in a Q/A style. "What does this do?" <allow you to think about it> "Here is what it does, and here's why." Rinse and repeat. I think more technical books should try this.
I like reading the classics of the field. Not only because they are classics, but also because they tend be well-written and hence more readable as well (than your average text). But maybe that is a tautology :) - they are classics because they are well-written ...
Update: Answering my own question - I saw here:
that it is part of a series, which includes the books I mentioned above.
- The Practice of Programming
- The Mythical Man Month
- The Cathedral and the Bazaar
- The Art of Motorcycle Maintenance
- Introduction to Algorithms
- Hackers and Painters
Some of these do contain mixed language code examples, but they are expressed in a way to be agnostic. A problem is a problem; in any language.
It's a nice fiction book that goes into how different people view the world. At least that's what I've gotten out of it so far, I'm only about a quarter of the way through it so I might be missing some of the things it covers.
I started reading the book about a year into my first development job and it really brought to light the frustrations my users were having as I was seeing as it was just another interesting problem to me. As I said in my past post I haven't been diligent in reading it so I'm only a quarter of the way through but here's hoping I'll get more insights out of it when I pick it back up.
I do think that what this book talks about can be discovered in other ways, but for people who are just starting in the technology field it's a good primer to be aware of how others experience what you implement.
IMO, It's more "philosophy" than "programming", but it makes you think about the role of technology in our lives and our role as creators of that technology.