Omitting “the mythical man-month” under maybe the assumption that everyone has read it is a mistake. And anyone who hasn’t read it probably should - I get stuff like my company’s c-suite and directors asking for things that make it clear they haven’t read it, I really have to fight the urge to gift them a copy of the book.
I don't think you meant this to be as absolute as it sounds, but as someone currently reading it, I find the asides, especially ones that focus on the nuances of a word's definition, such as "atomic", "consistent", etc. to be tedious while simultaneously lacking in clarity. I hope if Kleppmann ever does a 2nd edition that strips out some of this stuff and adds more examples, because most of his sales are probably from people like me who are job searching but lack distributed system design chops.
I did. And it is. There is no such book out there that covers breadth and sufficient depth at the expense of minor pedantry (that you're alluding to) without losing much meaning. For most engineers, being familiar with pros and cons of technology is far more important than nuances of terminology. They can and should investigate each topic more deeply when time comes.
I repeat with emphasis: It is exceptional in every way possible. Improvements that you suggest should be addressed if it doesn't take away from the breadth + detail and only make it more clear.
I felt like parent first time I was reading and abandoned after a couple chapters. Went back recently and read it through. Wow. Agree with you. One of the best books I’ve read, could be improved but it’s definitely in a tier beyond the majority of books in our field.
I've read The Pragmatic Programmer and large chunks of the Unwritten Laws of Engineering.
They're excellent books, but they're targeted for early career developers and people struggling to figure out the office work life. It's fair to say that you're probably not the target audience, but they're really great books for their niche.
I'm also extremely interested in the idea of reading a book about remote work after reading the blog.
Maybe it's not Remote, but I should definitely read a book about working remotely, considering I do it for so much of my time.
And something that wasn't a book but made a huge impact was Eric Ries's blog, Startup Lessons Learned, circa 2009. He correctly spotted that things like Extreme Programming are generic software development processes, but that in specific domains you could take advantage of their flexibilty to enable new business practices, as in Blank's "Customer Development" process.
Ah, but bad management likes to -claim- to have read it. Sometimes just having the reference can be leverage, i.e., "Well, as per the Mythical Man Month, not all tasks can be parallelized. We can't take three women and complete a pregnancy in 3 months, 3x as fast, after all. This is one of those cases - we won't speed things up by adding people, but we might make things worse"
Sometimes I can't believe that as an industry we've failed to internalize things we've known about for almost half a century.
It'd be one thing if there were managers out there actively disputing the ideas in the book, but I don't really ever see that. Like you say, more often I find managers that claim to have read it and agree. But still, shit like "let's flag if this project is late so we can try to add more people to it" gets said all the fucking time.
I think with a lot of managers, trusting downwards just isn't a thing they're able to do, and so the only move they think they have is to view engineers as miners chipping away at "man-months" of software work. Sometimes I almost think it doesn't matter to them if it actually works or not, it's just the only move they see so it's the only thing they'll do.
Well, speaking as a manager, I can tell you a LOT of that is coming from above middle management too, and the optics of adding people and failing is better than not adding people and failing.
Heck, I stepped away from my last job in part because the environment was that (really, 'leadership' was just generally so bad, and this was but one of its manifestations of suck). I kept having status meetings as we neared a due date (that had been set by product, not engineering, and which our velocity said we would not make) asking us if we'd make the date. To which I replied "Data says no; gut says maybe. If I say we're not going to make the date, what are we going to do differently?", and to which they had no answer -except- "pull people from other projects and put them on this one". Nevermind that the whole difficulty was learning the integrative aspects, i.e., communication, NOT implementation (and that was why gut said maybe; we had learned a lot already, which is what took a lot of time; we were still facing both known and unknown unknowns).
Meanwhile, the teams that were getting kudos were the ones where managers were just like "yep, we're floundering; give us more people". If they succeed, they were brilliant and knew to ask for help. If they failed, well, it was doomed, but at least they knew to ask for help. Nevermind if more people were actually helpful, and derailing other projects just to get them was worthwhile. Clearly, I was a bad cultural fit; I cared more about getting things done efficiently.
The Mythical Man Month reference there was helpful for not derailing things by having more people thrown in the mix; it wasn't helpful for avoiding blame.
> a LOT of that is coming from above middle management
For sure. One of the curses of the modern business environment is the belief in management as a universal skill. That if one has an MBA one can manage anything. That all one needs to do is find the appropriate graph and make it go up and to the right. In practice it ends up being an erasure of domain-specific knowledge in favor of the naive beliefs of the powerful.
The Empire State Building was built on time and under budget, but they did not have a complete plan when they started. This sounds impossible to the modern ear, but that's because executives see plans as a substitute for competence.
The pregnancy analogy has been incredibly helpful to explain the nature of a critical path throughout my career. People instantly get it. I’m often credited with thinking up this analogy because outside of programmers nobody reads MMM.
When I met Fred Brooks, I had no idea who he was. He was just another grandparent of a student in a club I was volunteering with. Spent some time with him on a road trip even. Such a humble and kind man.
It wasn’t until our 3rd or 4th interaction that I put two and two together. The result was a very nicely signed and personalized copy of the MMM.
It has a tendency to rankle managers trying to boost their headcount.
It's difficult to get a man to understand something when their raise depends upon them not understanding it.
I can still remember when the CTO I argued with came into the room one day and said that he'd been given the green light to hire as many additional people as he liked. He was grinning from ear to ear. I suspect he knew it wouldn't actually fix any of our issues but he didn't really care.
I've found if a book or idea doesn't come to them through their own network, then it's easily just dismissed. Especially if the book is nearing a half century old. About the saying that adding people to a late project makes it later, the simple retort was: "But we have agile scrum." End of discussion.
The top 2 recommendations - based on return to learning on time invested - are:
1. Computer Systems: A Programmer's Perspective
2. Designing Data-Intensive Applications
I think it's more important to find a good text book about the language you want to learn programming in, rather than a book about OOP. OOP is implemented differently by each language, and some popular languages these days completely avoid OOP.
I agree but I wouldn’t restrict the recommendation to just if you use python or ruby but if you want to use or understand any language in an OO fashion.
There's an old adage: those who can do, those who can't teach.
There's no magic information you're going to come across to further your career in any sort of literature on software development, or indeed any sort of career in general. Any practical books are verbose versions of framework documentation, coaching books are common sense, others formalising experiential learnings - which are only realised from having that experience itself.
This makes sense; otherwise you could get any Joe Blogs to read a couple of books and become an expert immediately.
Yeah this is probably correct.
Still, on some rare occasions it's so hard to get into a topic that if there's a good book I would give it a try. For example: I'm interested in Ruby internals. The codebase is very very complicated and I have no background in interpreters; in that case Ruby Under a Microscope is a life safer. I would say the same if I was looking to get into Linux kernel development.
But in general - if you are just trying to become a better software developer (e.g write clean, well tested code) you are absolutely right no book will get you there, hard work will.
I'm not sure how any of these books have anything to do with actual career advancement. Career trajectory improvements are generally catalyzed by high-risk business decisions (e.g. doing a startup, joining as an early employee, job hopping, etc.), or political posturing (e.g. getting promoted, gaming the stack ranking, aggressive negotiations, etc.). Being a good engineer doesn't really have anything to do with either. You have plenty of baseline engineers both starting companies and getting promoted over the studious "10x engineers."
Take the 37signals Remote book, for example: as a run-of-the-mill engineer, you quite literally have no say in what the work/office culture of your employer is. Unless you're (at a bare minimum) a VP, no one cares what your opinion is, as you have zero political capital. I don't want to be too negative, so here are some books I would suggest:
The 48 Laws of Power
Outliers: The Story of Success
The Black Swan: The Impact of the Highly Improbable
How to Win Friends & Influence People
> Being a good engineer doesn't really have anything to do with either.
Being a good engineer is necessary, but not necessarily sufficient, for being promoted.
There are some toxic workplaces where politics is the only way to get ahead, but they tend to fizzle out quickly as the upper ranks become filled with people who aren't good at anything but politicking and the good engineers and managers leave for greener pastures. It's certainly not characteristic of a typical, successful company.
In fact, neglecting engineering skills and trying to exclusively play political games is one of the quickest ways I've seen people tank their engineering careers. The problem is that it might work at first, for a short while, but eventually the people around the person realize they're all talk and no show.
Reputations are hard to build but easy to destroy.
Being an engineer is just that - an engineer. It's different from being a leader. Being a "10x" engineer just makes you a better engineer, it doesn't mean you're any more capable of making a decision that would generate a company $100 million in yearly revenue. Just different skill set. Steve Jobs wasn't a great engineer, but he was a great product visionary and marketer.
> Being an engineer is just that - an engineer. It's different from being a leader.
I disagree. In fact, the third or fourth stage of your promotion will often be a leadership position (junior, senior, principal/tech lead). If you're okay with being a "senior engineer" until you're 45, you're going to be in for a rough time when you get inevitably laid off.
I know way to many Anchor-out, homeless, or stay at home dads (Kids moved out decades a ago, or sleeping in the basement. Wife begrudging hating your unemployed, but is still civil when you are around.) who were in Computer Managment.
Save the money while you're young. Computer skills seem to mean nothing after 50. An those ass kissing people skills (Managment) are finished the moment you are laid off.
You will not be the 65 year old working Doctor, or Lawyer.
The barrier to entry is just too low, and since you guys are above unions; I hope you have a sympathetic family.
It will make you liberal though.
If you have the right attitude you will get through it though. A divorce might be necessary, but you probally knew that one was comming for years.
I stand by my take. A good engineer is not guaranteed to be a good lead. And a bad engineer isn't guaranteed to be a bad lead. They are different roles.
Most competent companies let good engineers who won't be good leads stay in IC roles with bigger responsibilities.
My personal experience shows to the contrary, the super talented engineers do well, and get promoted much more easily.
And I’ve seen many cases of “run-of-the-mill engineers” change cultural aspects of the office and the company.
This is all based on mostly one employer, but a very big one. I suspect smaller companies make fast promotions for talented engineers and cultural changes even easier.
(I do agree that sometimes people that look in no way special at first glance turn out to be fantastic founders)
Exactly, why are you chasing promotions? Isn't it ok to be happy with where you are and have satisfaction? My title is Sr Software Engineer. My boss keeps bringing up in our 1 on 1s about what we should do to carve out a path for a promotion to "Principal Engineer" but I don't care. The small amount of pay bump is just not worth the added responsibility (not to mention the hoops they make you jump for the promotion).
Very reassuring to hear that I am not the only one in a position like that; thank you for sharing! (I am planning on stepping pretty firmly off the path to Principal Staff to substantially alleviate work-related stress and anxiety)
This is a great mindset to have. I would especially recommend that you avoid management for as long as possible. The joy of building software is hard to replace once you hang it up and start attending meetings for a living.
Exactly. For many people senior software engineer is a stepping stone to something more, for me, there is nothing greater. If I wanted to be more ambitious I’d start a business.
The article is titled: Five Books that Changed My Career as a Software Engineer
The operative words being "My Career". The article is a subjective listing of books that the author found to be useful in their career and at the stage of their career they read them. Not an edict of what every SWE needs to read to progress in their career.
I have read 1 of the 4 books on your list (and read another partially) and haven't found them to be remotely helpful in my career progression. They may have huge impact on someone else at another stage of their career, that is the point of lists like these.
I find Outliers' chapter on Chinese people and rice field preposterous. It was like reading astrology: The entire Chinese people have grit, and their grit came from growing rice because it was such a laborious job. Really? Really? Really? Did the author even know that for thousands of years, it was the Northern China that dominated the history, and Northern Chinese largely grew wheat? And the book said Chinese were good at math because Chinese digits are short to pronounce. I'm sure Apollonius of Perga, Newton, Euler, Gauss, Hibert, Poincare, and countless others are rolling in their graves. Besides that fact that arithmetic is tiny part of maths, China produced good students in the past decades because Chinese invested in modern education, believed that a nation needed to have many great scientists and engineers, and relentlessly pushed students to learn more maths and science. The Qing Dynasty was a laugh stock in front of the rest of the modern world. The entire nation of China felt the pain and humiliation for not catching up with modern civilization.
They will fuck anyone over for telling them they must lower their standards for the crap like being inclusive or no kids left behind, as if everyone can learn advanced maths. They's how they got better at maths. That's how they produce good students: they believe everyone's potential, and push students as hard as necessary. They still have catch-up to do, but they are getting closer everyday.
The best description of have scene of the pop psychology and pop business books is “knowledge porn”. Guns germs and steel is like that. Makes the reader feel the secret history of the world or some topic is being revealed even though it’s at least partially, or wholly, fantasy :)
In my head, I consider these sorts of books more generalized models to run information through. For example, when I think about some historical occurrence I run it through evo bio, Marxism, geo determinism, critical race theory, symbolic culture, etc. Yeah, some of the origins of these models are dumbed-down, but my reasoning is that the more of these models I have, the closer I can get to that secret history :P
> as a run-of-the-mill engineer, you quite literally have no say in what the work/office culture of your employer is.
Who hurt you?
My experience has been quite the opposite. Creating a great work culture is well within the ability of even new engineers. I would probably suggest the opposite of you, in fact, and suggest that, between engineers and the VP/C-Suite level, mid or senior level engineers probably have the most sway over company culture. As an engineer, you have time, inclination, and ability. VPs don't have the time, CEOs don't have the inclination, and, frankly, no one but the boots on the ground have the ability.
You do in fact seem to negative, and have a take on life that is a bit more cynical than reality. Completely dismissing any value in actually being a good engineer for career advancement for instance is a bit over the top. Suggesting companies always don’t care about employee opinions as well. Real life is pretty bad sometimes but not universally dystopian.
> Suggesting companies always don’t care about employee opinions as well.
Ah yes, the same companies that laid off mass numbers of engineers in 2000 and did it all over again in 2008. The same companies that vehemently fight any kind of unionization efforts and the same companies that insist to haze potential hires with live-coding & whiteboarding tests even though folks have 10+ years of experience. The same companies that were wage-fixing employees' salaries and had to pay out almost half a billion dollars in restitution[1]. Those companies? If you think you have any kind of influence on corporate culture as random engineer #3419, I've got a bridge to sell you.
I disagree. Reading the books mentioned by the OP are more geared towards being a better software engineer. Your list seems to be better aligned to improving the success of a software manager. As for Remote, I found the book useful for making the case for remote work, and how to succeed with remote workers in a corporate culture that was highly resistant to the ideas.
Have you ever managed people? This bit does not match my experience at a number of companies: "you quite literally have no say [...] no one cares what your opinion is, as you have zero political capital".
I'd argue that you have near 100% control over the work/office culture of your employer. You have 100% control over who you work for, so you can control the office culture you work in. It's a 1 to 1 relationship.
If during an interview they say.. "3 days in the office" you counter with "how about zero?" They say "The best we can do is 2", you again counter with "Zero works for me." Don't take the job.
I’ve read The Pragmatic Programmer. It’s not a bad book - I was nodding along the whole way. And that’s sort of the problem with the books of this genre. The thing is, I recognize that these are good techniques because I already spent lots of time applying them. I just don’t know if the idea of compressing years of hands on experience into a textbook works well in practice. This goes for most self-help books as well.
It's a good book at a certain stage in your career. Before that it's too easy to misconstrue it as absolutist (it isn't) or misunderstand the guidance (like DRY, which got a major rewrite in the 2nd edition to help with that). Too late in your career and it is all "obvious" (if you're a competent programmer).
On the other hand, as a mentor I found it useful to re-read it (or, read it through properly, I'd read large portions when I was younger but never all the way through). There's a problem of becoming too expert where you can't communicate with novices in the field anymore, at least not like they actually need you to communicate with them. There was benefit, for me, in re-reading it and nodding along and being reminded of the things I'd learned along the way, getting a name for them, and a discussion I could use as a basis for my mentoring.
Self-help books don't work if you're just starting out. This is because the books sound trite and obvious and you haven't experienced enough failure yet.
But they get very helpful once you've been in a few battles and failed miserably. You'll be able to determine where you went wrong, whereas before it escaped you. You'll then find out how to not make those mistakes again, and do it right next time.
When I read it I too found myself recognizing almost everything it says and it all felt almost obvious... I already had most of those insights myself, am I learning anything?
The real value is that it is much much harder to pass that sort of insight along to engineers you work with or (especially more junior) manage. Books like that didn't make me a better writer of code, but I think they made me a much better communicator, engineer and manager.
Second this. I credit this book for making me the programmer I am today. Scheme is such a wonderful language having come from C/C++ before it. Of all the subjects that affected me by learning Scheme, using Scheme to implement OO as message passing opened my eyes compared to C++.
The thing that changed my career as a software engineer, in terms of seniority & remuneration by time and effort, was by changing my efforts from learning arbitrary tech to learning the domain I worked in. Asking useful domain-related questions gets you noticed in stand ups and helps you write the right code. I work in fintech so the best bang for my buck I’ve had was reading an entry level cert in investment finance.
I think the generic bit of this advice is to excel as an engineer is to focus on the business, not the tech.
Writing individual programs is often quite simple, but developing software products is often not. It's a combination of taste, hard-won experience, a feel for the organizational dynamics at play, and of course, raw programming ability. Note that the things on the list, other than programming, are often pretty complicated!
You kind of have to be a rebel to get that knowledge. Most teams don’t want developers talking to customers or spending time understanding the domain beyond their next ticket, and even in that case they’ll get a product managers distilled version. If the industry has courses/exams and a path of its own that’s helpful so you can get the knowledge that way.
I don't think that is the case, or atleast that has not been my experience. Most teams would be happy if you do these, but not affecting the next deliverable. So if you are willing or can spend extra hours that becomes manageable, but one can't always be in a position to spend more hours working (priorities, family etc.). What would be best is team encourages your involvement and factors that in deciding the target date of your deliverables. This would win for both since knowing domain makes one to understand the problem better and program beetter.
"[...] ultimately pretty simple" you mean if you ignore everything making it hard?
I must admit that this kind of attitude triggers me. I have worked in the energy sector, in engineering (but not IT) heavy companies, and many have this attitude. "its easy to learn programming", "we just need to teach the engineers python" etc etc, and I have seen MOUNTAINS OF SHIT so tall you would faint. It's easy to get tricked, because being both the user and developer at the same time can be such a boost. But the moment there are more users things get hard. The moment the code base gets so large that you can't keep it all in your head, it gets hard.
Software development is easy until its not, and it surprisingly quickly gets to the "it's not" stage. And then you get excel sheets in python.
Some "subject matter experts" make good programmers, but in my experience its not because their background, but because they are smart and have talent for it.
Big +1. Most corporate software is pretty straightforward (the company likes it this way so that it's easier to onboard new engineers). So, you stand out by delivering something other engineers can't, deep insights into how software can solve specific domain problems.
This is good advice for something like finance. But many software companies are out to "disrupt" very broad areas, and unless you intend to stick in one such area, I doubt there is a whole lot of benefit to doing that.
For example, if you are developing software at Uber, there is no "domain" to speak of. Ditto for a search engine at Google. The company pioneered information retrieval in the internet age, so what's the relevant "domain" there?
Of course, if you are writing MCAS software for Boeing, having a good understanding of Control Systems, or Aeronautics (which you can gain by attending nontraditional programs in colleges or universities) will be very helpful. Same thing for something like trading firms (where it's practically formalized and there are programs that turn out quants), accounting firms (e.g., Intuit) etc.
From your examples, it seems that you make a distinction between B2B (with possibly internal clients) and B2C.
The general advice that would still apply to both would be: understand who your client is and what they need in the context in which they evolve, be they consumers in a country you're not familiar with or mechanical engineers you barely know the job of.
- "Hey, I saw a statistic that females are anxious about taking taxis at night in France. Why don't we add a feature to let people share their locations with others?"
- "In London taxi drivers have to pass The Knowledge, a test on roads! Have we considered adding a similar pre-requisite test for drivers in that city?"
- "I noticed a lot of drivers on Reddit have been complaining that the tips aren't viewable on the app, but we have the data. Why don't we add that to the drivers UI?"
Etc... The sources of this information would be user channels like Reddit, taxi-related news sources in countries you operate in, and keeping up to date on legislation. Sure you might not have the ability to make any of these changes yet but if you stay ahead on these factors it's definitely the way to move into a position where you can have that level of impact.
This has been my experience as well. Beyond a level an engineer creates value by being at the intersection of product/UX, business, and tech; by being able to seamlessly transition between them.
As a consequence if one changes jobs say every 2-3 years (different domains) then they become generalist engineers.
In my experience one has to spend 10-12 months at a company to pick up a domain by being deliberate at it. It may look like a big investment but the payoff will be significant once they have sufficient context in their head.
And it's one of the rare good advice. Communication failure (or even slow) is so expensive, being the guy who can translate ideas clean and fast will make a lot of things better.
Take a bow. I was given this wisdom right on my first job and its the best advice I have ever received. Software is pretty useless without the business context so merely talking about software is not helpful.
Totally agree! I have a background in government data science. As I rose up the ranks at the government contractor where I work, more and more of my job focused on corporate stuff that was outside of my wheelhouse. I used to be intimidated by phrases like "That's SG&A, don't take it off the topline." I told me professor friend and she gifted me a copy of Berk & DeMarzo. It's been more useful than any single programming book I've read. Turns out corporate finance isn't that hard, it just has its own language that takes effort to learn.
I’m so happy these comments and conversations may take place now given we as software engineers have reached a saturation point where we are made up of those who are not just satisfied with a Java book or a Ruby book; rather we are made up of a body of members who use the tens of languages that are flourishing today in our programming stack.
Is it just me or do other people struggle to read these kinds of very technical books?
It's not that I don't comprehend, it's that my brain finds it boring and hard to focus. I think I have trained my brain so much on rapid skimming of websites for useful info, while throwing away most of the content, that I tend to do the same with books, which really doesn't work well.
Has anyone found alternative ways to consume this information for brains that work like mine?
Deep, focused reading is a muscle that you need to work on. There isn’t a real answer other than practice, and focus on delayed gratification.
We skim websites/articles because there is so much information out there, and not all of it is useful. I skim articles and then go back to fully read them once I make sure they’re actually worth the time. Same with some books, but books generally are worth it since they went through the publishing process, etc.
I set a single New Years Resolution goal to build this muscle: 12 books in this year. I’ve read 22 now.
What compels me to keep reading is the Reading Insights Streak feature in Kindle. It’s like a little reminder I can always check on to see if I’ve read today or not.
While listening to Derek Sivers and Shane Parish talk about reading, I found Derek's comment to be, what I think, is a way to 'go deeper': assuming you've made highlights in a book, when you finish it, spend time thinking about each highlight. Take unnecessary words out of the highlighted text. Get to the core of the words that really triggered you to think different. I've yet to do this.
This is right, however we also need to acknowledge the prevalence of books which put forth some good ideas, but which perhaps can be summarized in a page or so. Instead they choose to labor on and on around the same point(s) without adding much.
A book that definitely wasn't in the category I described above (for me) was John Ousterhout's Philosophy of Software Design - https://www.amazon.com/Philosophy-Software-Design-John-Ouste... . I haven't run into software design/tech books like that very often.
From the reviews it sounds mainly from the OO/Java and heavy design up front paradigm and not very Agile / test driven. Is that fair? I'd really like a philosophically minded book that integrates these relatively newer approaches.
I consider myself very agile/test-driven-leaning and I got a lot out of the book. It provided nice restatements of many things I've vaguely thought over the years and some nice new ideas.
The book came out of Ousterhout's course on software design where he reviews student code as they work on a significant problem - building a text editor. There is very little (if any) material out there of this nature that goes much beyond personal opinion (usually under the guise of experience) and sloganeering. This one though, is a hearty dive into the delectable details of design.
Second that book! I have read dozens of technical books, but none come close in practical wisdom. If you have been in the industry and worked on large projects you will find it very relevant. I hope it is also as relevant and easy to understand for people who do not have many years of experience already.
Many books belabor the point and take a chapter to explain what a paragraph could.
It might sometimes be useful - for example, to explain a scenario to a newbie who can't relate from their own experience - but for someone who's been in the industry for a while, most of that information is just not useful.
Called US writing style over here, just being overly verbose. Course literature, e.g. Calculus, suffers from this. It is a style in which you wax on and drive home the point by repetition.
This style is popular nowdays and finding books that succintcly describes a subject is hard. This is mostly because you need to have common ground, and writing for the smallest common denominator is better.
I actually think Calculus textbooks are justified in being long. he material is just so hard to grasp for newbies that giving you more and more examples sort of provides you with more time to digest the ideas in the background. Many students need that at that stage in their studies.
Writing succinctly is a difficult skill that requires practice. The US government has put a lot of work into making things easier to understand in recent years. I have a Masters in Public Administration. My professors hammered home the idea that lawmakers and the public aren't going to read your 50 page policy analysis, so matter how brilliant it is. My final paper in Project Management class was worth 25% of my final grade and had a one-page limit. It's one of the most difficult projects I've ever had. If you're interested in learning more about this style of writing, check out plainlanguage.gov.
Relatedly, but I've always wished there were a series of books like, "I'm Already a Programmer but I'd Like to Learn ____"
Trying to pick up a book about a new programming language that is trying to explain the concept of an 'array' or whatever is annoying--I wish there was something to just lay out (still in a thoughtful and guided way) the concepts I needed to understand for that language based on already knowing several others.
Agreed! I've only found a few great examples of books like this, such as Advanced R. There's a lot of "You can skip this chapter if you already know how to answer the following questions..."
I agree that many of these books are hard and super boring to read. That's why I always recommend books that are written in easy and accessible style, such as The Little Schemer, The New Turning Omnibus, and Programming Pearls (not Perl but Pearls by Jon Bentley). Or, books that are written in problem-hint-solution style, such as The Little Book of Semaphores and To Mock a Mockingbird. These are so fun and easy to read.
I tend to gravitate to pen and paper when I’m not zoning into a book and either draw charts on a notebook or write small notes into post-its I stick to the book.
Yeah, I'm the same way. I've gotten better at it though by "practicing." For me, it's the same process as strength training. You need progressive overload. Start with easy to read attention capturing books, and slowly progress to harder and harder books.
Honestly my problem with books like the ones in this list is that they aren't very technical. It's similar to business books and self help books for me, I feel like there isn't any concrete information, just anecdotal stories that I only find semi-interesting. I find myself zoning out while reading them. And I'm not saying the advice isn't good! I just struggle to stay engaged with it.
It's not just you. I have a terrible time trying to get through technical / programming books, they put me to sleep. Not everyone learns the same way and that's okay. I have no problem getting through huge fiction books, so it's not a "book problem".
The a builds on b builds on c style of learning is only one way of learning things, and in many cases, the foundations (a, b) serve you no real value.
Just jump to the sections that interest you (c) and go back to previous sections if you feel like you’ve lost track of what they’re talking about.
For example, the first 20 pages of ‘Remote’ cover why remote working is good. It is intended for people who are considering if remote working is suitable. If that’s not relevant to you, do not waste your time reading it.
Of course, you still have to actually sit and read the chapters that interest you… but, if you struggle with that for the chapters you’re actually interested in perhaps a more project based (do a thing, use references from book) approach, or notes based (treat book as study text, rewrite it as your own notes) might work for you.
…but, don’t feel bad. These are super boring ass books with a few interesting parts to them.
Often, it’s some variant of starting with studying the table of contents then doing a fast first pass of the text. That’s usually a pretty good way of figuring out where to start.
None of these books are very technical in nature. Some of them are, in fact, as far as you can get from technical, e.g., Explain the Cloud like I'm Ten.
If you can't read books, then you are missing out on a lot. It's important to be able to read books (and work through large portions of them). Start reading books by reading fiction, then transition into nonfiction books (that are closer to fiction at first, e.g., history), finally transitioning into long-form technical books. If your budget permits, buy a long-form book on a technical topic and commit to reading it instead of just jumping on a website. For example, if you want to learn Kubernetes, just buy the Kubernetes book written by Beda et. al. I doubt any website will be better than that, and you will spend perhaps a week or two on a shallow read of the book, but you'll have found that you have a much better appreciation of the subject matter than you would have had you just glanced at a few website articles.
My trick is to keep a stack of these books around, and when I have some downtime I flip one open to a random page and read. I also keep a few in my car and on my desk at work.
I honestly think it’s alright. After spending 40-50 waking hours with tech in a week the last thing I want is extend the tech, or professional aspect, of my life more.
I love reading literature though. Hours, engrossed.
This might just be me. Tech is just a means to pay the bills for me - there’s no passion, hatred, love involved here.
Have you tried audiobooks? It helps me a lot to do something boring, like cleaning the kitchen or emptying/filling the dishwasher, while I consume content. Somehow when my body is doing something in automated mode I can focus well on my thoughts or audio/video content. Audiobooks and podcasts are perfect for this, videos are a bit more difficult as you’re likely to miss something, and text content is not adapted at all.
Some people seems to find audiobooks and podcasts fantastic, but I think it's somewhat correlated with your multitasking capability. If I go on a walk listening to a podcast or have it on in the background while working on something else I absorb only like 5% of it because I can't focus on it. As such it's useless for me unless I literally lay back in bed and listen to it. At that point I might as well just read something.
I cannot just sit and listen without doing anything, I need to be doing something with my body to be able to stay focus on an audio feed. I mean, I can do it but I won't be able to keep my attention on the audio content. When I bike, walk, or do laundry, no problem at all!
Anything from microbe.tv: https://www.microbe.tv/science-shows/.
They have podcasts covering evolution, microbiology, neuroscience, parasitism, virology, urban agriculture, and more. Lot of stuff to dig into, you can try and see which one you like.
Not technical, but I like to listen to Startup Therapy, I like how they openly talk about failures and mistakes: https://adspthepodcast.com/
I totally agree, to the point where I’m skeptical about people saying they’ve read something cover to cover.
Someone once recommended me to start at the back of each chapter and do the the problems and only read the chapter or even parts of the chapter for problems I couldn’t solve.
It comes with its own set of drawbacks but it does help with getting through text books where the author was paid by per letter.
It's not that hard. I try to spend 10 minutes a day reading some sort of technical book. Just set a timer and do it. I don't always get around to it. Here's a list of the various tech books I've read cover to cover over the last couple of decades: https://www.goodreads.com/review/list/5348644-neville-ridley...
Reading attention is a skill that can be trained ... and forgotten.
When I was a kid, I read books by the meter, regular at the local library. At age 35, after life happened and after I was immersed in quick internet articles, I realised I haven't finished a book in ages. Which made me slowly read more, having that extra page after "mental exhaustion", slowly working my way up to a while chapter ... trying to get back into the habit.
Now at age 41, I read long stuff again - best decision I've made. But I am under no illusion that I won't fall back into bit-sized consumption if I would stop keeping it up.
It doesnt detract from your general point but I dont think any of these recommended books would qualify as very technical.
Pragmatic Programmer for example could be thought of as a very curated list of blog articles. Great book, but also not intimidating or deeply technical in that sense.
Not a dev, sysadmin, but I agree, I find technical books exceptionally boring.
My example is from the Windows Internals books, it’s a great book, but I don’t think the authors could write it in a “gripping” way, that’s just technical books.
What I do however be it books or video is chunks, takes MUCH longer to do but I find for me it sticks, so if in my learning season (I do bursts of learning, burn out leave it for a couple of months, rinse repeat),
- Read a section or chapter
- Make quick, rapid notes in my notes app (or notebook, I use bear but whatever suits yourself)
- Once I’ve done, go to sleep (I normally study at night, my brains more in a learning mode then for me)
- Maybe at dinner time (at work) I go through my notes, if it’s something I feel may benefit my colleagues I make a brief PowerPoint, I try to translate it into a less technical write up, not everyone is super technical, it’s just a job to them!.
I have a terrible memory for learning, I remember things long term great, short term not so much, so I reference my notes a lot, it’s essentially my mind map/bank.
Video learning is very subjective, I’m currently learning Cisco Umbrella and it’s very boring to me, the creators voice is very mono tone and boring to the point I’ve nearly fallen asleep, but other creators (mostly in the Microsoft MVP zone) are very lively, a good mix of demos and theory that keep me engaged and actively want to learn, Pluralsight is the same, keeps me awake and motivated, I found CBT a little on the boring side in comparison.
Found out that I have ADHD. Never managed to read any books about programming, after a few pages my brain starts making up excuses to do other things and I start rereading the same paragraph over and over again.
No issues doing the actual programming, could sit for hours on end without any issues.
One nifty thing about my ADHD is that something that was super interesting can become dull as hell. For no apparent reason.
Issues with focus, staying on task and motivation are generic issues that everyone has. Just like everyone gets sad or down sometimes. When it becomes a constant problem that affects your life, that's when it becomes a depression and needs treatment. ADHD is similar, except that it doesn't really come and go but is more of an undulating constant.
Screen readers work great, for me it's my phone. On my desktop I'd be getting distracted and bored in about two paragraphs. Even if I try to come back to the article, there's invariable 3 other things that I'm switching between.
On my phone I've read 250k word books cover to cover, same books I could never read on a PC. Attention is weird like that.
Another trick is getting your dopamine* externally. There's an association between ADHD and substance abuse, and I can see why. Pharmacology is a cheat code: a few hours of infinite motivation, will power, and attention.
Unfortunately, when people start needing a substance just to feel normal, that is the definition of an addiction.
(* More complicated than just Dopamine or Serotonin, both seem to play a role. Medecine has not solved this one yet.)
That's a tough question to answer, and I think people should make that decision for themselves, with all the information they have about their particular situation.
Negative side effects of note with usual ADHD medication (amphetamine salts) include increased cardiovascular load, development of a tolerance (you need higher doses to achieve the same effect). Sometimes amphetamines induce small changes in personality, rarely full blown psychosis (this has happened at therapeutic doses!).
In general you should apply the same sort of risk-benefit analysis we use for every other drug. If you don't experience any side effects so strong you want to stop, and you believe you're aware of the risks, great.
If you're taking them without a script, I'd advise you to find a steady-state dose that works for you and stick to it. Don't let yourself increase the frequency or the dose without a conscious decision. That's how many people have spiraled.
Finally, I think it's important to have a lot of respect for psychoactive chemicals. Nature doesn't care very much for human overconfidence. If you start being careless, chemistry will do what chemistry does.
> Unfortunately, when people start needing a substance just to feel normal, that is the definition of an addiction.
Disagree. What is 'normal'?
A better definition for addiction is the brain no longer produces the neurotransmitter without the presence of the drug (or is doing so at a highly diminished rate). There's no evidence that such occurs with the amounts prescribed for adhd.
For that matter, people needing an external source of a substance to feel normal is unavoidably part of being an organism. We need water, or we wont feel normal. We need vitamins -- and plenty of people have vitamin deficiencies, are they addicted to said vitamins?
Those concentration drugs that you hear about, do they work? I've heard that a lot of students use them, but I'm a little bit wary of using something like that.
I use one of them, and it has been a great help for me for studying and for work. I don't take them during "off-time", i.e., weekends and holidays, and I don't feel like I need them for my hobbies, where part of what makes it fun for me is that I can take my time, shift my focus constantly, and define "progress" by my own internal metrics.
They do. If you don't have a diagnose, be careful with it. You want to be able to execute challenging mental tasks without it. You will still be able to do that after trying such medication, but you will always know, there would be a easier way to do it and that can become a mental block.
With the same attitude like any other drug, I guess. It's very likely less harmful than other drugs. If you're mindful about it and you really want to try it, then ...
consult a doctor. they're probably controlled substances in your area, and people trying to get them illegally makes it all the more difficult for people that actually need them to live a healthy life.
There's no evidence that they actually help people that don't have adhd. it'll just make them _feel_ like they're doing better, in spite of any objective measure.
They can work, they work wonders for me. There's also no "magic pill" and they have their downsides. For me, the pros vastly outweigh the cons, and I've tried several times to make a happy life without support of medication and it's just not as good. (Even with trying a more alternative lifestyle, not being in an environment where I need to sit and focus all the time, etc.)
But also, every body and mind are different. Consult a specialist. There's many different types of ADHD medication out there now.
I've had similar experiences in my dealings with ADHD. I've found resources like khan academy and 3b1b to be miraculous in helping me stay engaged. or atleast letting me rewind and watch multiple times.
w.r.t. books on programming - I've found that ones that offer a hands on project really aid in staying engaged with it. That's usually enough to give you a solid primer on a topic, where other literature starts to become a bit more accessible/less of a drag/less overwhelmed with unknown terminology
> I think I have trained my brain so much on rapid skimming of websites for useful info
No, your brain just tricked you. It trained you into thinking that you're doing rapid research of useful info, while it just looks for path of least resistence.
Same. What I did was to limit (minimum and maximum) myself to 1 chapter/section per day of a singular book that I decided to focus on. That way it becomes a habit.
Minimum means that I need to finish it that day no matter what.
I put a maximum because I found through trial and error that if I push myself too hard, even if a topic is interesting, I burn out quickly and procrastinate, sometimes for months, before continuing reading said book. And that is worst case scenario for me.
I admit that I got through a lot of technical books by learning things in a classroom. I don't subscribe to the "children have different ways of learning," but I don't think I would have survived my college majors (math and physics) had I tried to learn them on my own from books, even good books.
On the other hand, I taught myself electronics and programming from a combination of books and just trying things. Maybe trying things is a different kind of classroom in a sense. Certainly a different teacher: Mother Nature, who takes no crap from cocky teenagers.
I don't know why but I've always loved reading technical content cover to cover. It started with cereal boxes when I was a kid and I would read ALL of the text. In my teens it was MaximumPC and 4Wheeler magazine that I would read cover to cover. Now I buy random tech books for things I want to know about like Hadoop, KVM virtualization, Code Complete, etc.
I personally think that it goes deeper than just the ability to read and absorb. You to ask, and understand the motivations _for_ reading something, otherwise it's going to feel like a chore. I just finished "How to Take Smart Notes" and it seriously changed how I view readings like this. Where it's not for a short term gain, but rather an incremental increase in my knowledge base.
The content may not be super relevant immediately, but the book and (really simple) methodology of taking notes on these readings and graphing relationships between concepts means you're slowly building a network of knowledge that grows and becomes more powerful over time.
Something to try is to accept the lack of focus, and when it happens, just switch to skimming. One of two things will happen: you'll realize the information isn't that important or interesting, or something will catch and you'll become re-engaged. In the first case, you can always revisit the material in the future, if you come across a situation where it seems like it might be useful.
None of these books are very technical tbh. They usually describe principles in simple language (big plus IMO) so they could be consumed in a way you would read a novel.
As for having trouble reading difficuly texts try this - read two pages. Try to recall what you read. Then try to connect it with what you already know. You only need to do it for the fundamentals not every sentence and it will help build up flow.
I have a terrible problem with people recommending books that „changed their whatever”. And sometimes I think that it comes from an arrogant place where people being „influenced” by books is a bad place. But I do understand that sometimes books can change the way one thinks about things, and it makes sense to make a list of those.
For me, there are books that had a negative impact on my work. The GoF book is one such book, and its impact on my development is so distructive I can't even begin to explain. It's not only because it tries to codify coding as a sum of recipes, but people reading it end up with the scary idea that there is only one way of doing things, and that one way has a clear name, and a single possibility for implementation. The GoF buffs are those that keep stressing the most autoerotic interview question: „describe me one design pattern, other than Singleton”.
Now worse than people who read the GoF book are people who dove deeper into the issue and learned about more design patterns from other books. One such people screwed my career development for 7 years because at one internal interview he asked me out of nothing about the „half sync half async pattern”, that solves a problem that he wasn't able to describe to me. And since I failed, I was forever on their s*t list.
I think there are good books that can influence your life in a positive manner, but those are incremental changes, things that add a few things here and there. I would expect to see on lists that „changed careers” books on programming languages, like Kernighan & Ritchie on C, or Stroustrup's or Alexandrescu's books on C++. Or books on fundamentals, like Hennessy and Patterson, like Tannenbaum's Network or Operating systems, Knuth, or Cormen&al on Algorithms. But since I rarely do...
> One such people screwed my career development for 7 years because at one internal interview he asked me out of nothing about the „half sync half async pattern”, that solves a problem that he wasn't able to describe to me. And since I failed, I was forever on their s*t list.
This is a sign, that in order to solve the problem, you must move on to a job that isn't the problem.
I learned many things from that experience, but later, when I actually got smarter about career and interviews; being introverted didn't help much either. But I'm glad I didn't make this mistake on my end, when I was at the other end of the table; I was able to hire and help grow people who would have been put down because they didn't read a recipes book.
Abelson, Sussman's Structure Interpretation of Computer Programs also good recommend - helps show that whilst it's not magic, fact everything still works is magical
That is the beauty of this book, there is no need for any extra resources. Install SICP package in Dr. Racket [1] and start reading the book. Try your best to solve the exercises, and don't give up easily on the exercises. Thinking over the exercises and solving them is the best way to assimilate learning from SICP. I read only the first 3 chapters, and relied on notes from Eli Bendersky [2] to check when stuck with exercises.
The videos from a class the authors gave in 1986 are available online (https://m.youtube.com/watch?v=2Op3QLzMgSY). I highly recommend those, if reading the text is not your style.
I think you are being unfair towards GoF. GoF came out when Object Orientation was the rage and it provided a useful compendium of solution archetypes that can be used in response to (solved, recurring) problems. That is not to cast aspersions on your personal experience. It sounds like you had an encounter with an Architecture Astronaut and ended up in a bad place, but the fact that you are writing about it is a good thing, isn't it?
I also agree that "changed my x" is a bit of a stretch; perhaps it's hyperbole and should be taken as such. There are very few "things" that change one's life. Perhaps being in a war, or a natural disaster or some such, having an encounter with death but averting it or some such event could singlehandedly change one's life, but I doubt that reading a book or a set of books is one of them.
It's not a judgment of GoF per se, although I have some critique on the book as well, but of the impact it had. Unfortunately, a lot of people (mis)took it to heart, and GoF became just another book to learn by rote when interviewing.
Somehow related, Google right now demands interviewees to prepare using the Cracking the Coding Interview book. Pretty much it's like someone sells you a door and hands you a set of lockpicking tools instead of you using the key to enter.
I actually really appreciate the GoF book. I don’t use their patterns every day, but it’s definitely driven home the message of carefully thinking about which parts of the system should depend on which other parts, and examples of how you can achieve that.
I also find it useful as a reference because many of the more common patterns do show up in people’s code and in libraries and understanding what a singleton/adapter/factory/builder is, does help me in my day to day.
I think the problem are the people who can’t abstract the message of the book and instead use it as their reference for absolutely everything, over-engineering the hell out of things. When I’m asked the sort of questions you describe, I also just ask if they could instead explain the problem, because being able to solve problems is all design patterns are about. If they can’t, I would respectfully ask how their knowledge of the design pattern will then help them in their job.
I cannot second this enough.
Uncle Bob et all have done imeasurable bad to a lot past and future devs generations.
Advocating for a perverted cloudy way of overengineered sw that builds cvs and horrible enterprise sw.
There are much better ppl to read out there. Anyone actually writing long lived sw. Linus, sam neal, anyone actually DOING it rather than living off self indulgent books.
I agree and hope that no one will come here commenting in favour of the uncle&co, what relevant software have they actually written? And how much time has been lost refactoring code from people that mindlessly followed their extremely simplified recommendations and toy examples? Let's forget them please.
> what relevant software have they actually written
I think Fitnesse [1] is quite relevant. That said, not a lot of FOSS work from someone like him, to put the things he preaches in large and complex projects that we can look at the source and learn from.
> One such people screwed my career development for 7 years
The problem was with this person, not so much with the GoF book. In present days this person might have become an FP fundamentalist and come up with some exotic category theory quiz question that he was very fond of himself.
The GoF book is now of course outdated but the idea of categorizing best practices from the industry was a good one. Unfortunately many good ideas will be abused by people who lack the common sense to know how and where to apply them.
A similar thing has happened to the agile software development movement, to microservices architecture (every service is a microservice?!), unit testing (people trying to reach 100% coverage).
“Gang of Four”. It’s how the book * Design Patterns: Elements of Reusable Object-Oriented Software* is often referenced. The “four” being the four authors.
I've met such newly appointed architects myself - judging by the commit history, they were OK writing unmantainable spaghetti for 10 years, then they read a few books on patterns, got promoted to architects and started applying those patterns everywhere (ending up with unmaintainable overengineered abstractions). When arguing during architecture reviews, you'd often hear "but in book X it's written that..." like they don't have their own opinion. Fortunately, they all outgrew this phase and eventually became proper architects.
Haha I remember my first designs as a Jr Engineer after I had crammed the book into my brain before starting. I’m pretty sure the other devs just threw those classes into the trash when I wasn’t looking. For about a year I thought everything had to be a design pattern and making a vanilla class was a faux pas.
14 years later I don’t think I use any of the patterns anymore. Maybe facade if I’m refactoring a complete mess of a project
My thought about this is that patterns are something I recognize in the completed code, not something I bake into my code. A useful tool for refactoring at best. But re-factoring, not factoring. :)
> It's not only because it tries to codify coding as a sum of recipes
It doesn't do anything of the sort. It may try to codify some specific solutions to SOME specific types of problems, in a very narrow OOP'y context, but if "codifying coding as a sum or recipes" is what you took from it there's little wonder it has colored your view, so.
Some of the juicier bits from these books have been fairly well absorbed by engineering culture, ie "rubber duck debugging" and "DRY". Some of these books I haven't heard of though.
As somebody who didn't study CS in college, the books that most changed my career were:
* Algorithms, by Robert Sedgwick (probably not the best algorithms book, but lots of hands-on stuff)
* Learning From Data, by Yaser S. Abu-Mostafa et. al. This one has video lectures to go along with it.
* C Programming: A Modern Approach. (Definitely not the best, but also lots of hands on stuff)
Another thing I've found extremely educational is to read major incident postmortems (SEV0s and security SEV1s at FB, "huge" OMGs at Google). If you ever find yourself anywhere with planet-scale infrastructure, make sure to read these write-ups. They are treasure.
I have no doubt those books inspire people to become substantially better developers. I have observed in the large corporate world career progression is not linked to either quality of developer or quality of product.
It is important to keep those in mind and then determine what is more important: career progression or work satisfaction.
CODE teaches you about how computation can be structured out of circuits and switches and ultimately transistors. I now understand the fundamental nature of electronic computation.
UNIX taught me about the how an OS deals with hardware resources and the software that run on them. I now understand the environment in which my processes live as well as the structure of a process.
DDIA taught me about the structure of data, how databases operate on data through transactions, the difficulties of synchronization across databases, and the way data streaming works.
Designing Data-Intensive Applications was really good too, the best new technical book I've read in the last five years or so, though I have had trouble applying its techniques thus far.
I liked the `little` series. It's a bit slow if you already know enough circular lispiness but they really manage to make a full theory emerge from tiny innocent questions. Brilliant.
I could add Queinnec's Lisp in small pieces (for the gradual derivation of fancier and fancier interpreters, the continuation one in CLOS was cool, and the bytecode part also very very cool)
Bratko's Prolog book was nice.
I'm tempted to mention the dragon book but I only read 40%.
SICP has already been mentioned a couple of times and I agree with that 100%. What I find helps me more than anything to be a better programmer is to find those gems that take you out of your day-to-day routine and help you see programming in a different way. So a couple of other books I’d throw in with SICP are “The art of Prolog” and “The Little Schemer.” I still today admire Prolog’s declarative style so much today. Even though I haven’t had the opportunity to use it professionally, I still come back to it now and then to refresh on it.
294 comments
[ 1.6 ms ] story [ 129 ms ] threadPersonally, I got a lot of value from Designing Data-Intensive Applications by Martin Kleppmann.
* Rapid Development (Profession)
* Epistulae Morales ad Lucilium (You're not alone, we all share this.)
* The War of Art (At 9am, you are alone.)
* Competitive Advantage (Porter, a personal choice, it's not about the bytes.)
* For those who don't already know, it's a very quick read. And the type of book you'll gladly reread every one to three years.
Exceptional in every way.
I repeat with emphasis: It is exceptional in every way possible. Improvements that you suggest should be addressed if it doesn't take away from the breadth + detail and only make it more clear.
* The Passionate Programmer: Creating a Remarkable Career in Software Development
* The Pragmatic Programmer - your journey to mastery(20th Anniversary Edition)
* Unwritten Laws of Engineering - Second Edition
* Remote: Office Not Required
* Explain the Cloud Like I’m 10
They're excellent books, but they're targeted for early career developers and people struggling to figure out the office work life. It's fair to say that you're probably not the target audience, but they're really great books for their niche.
I'm also extremely interested in the idea of reading a book about remote work after reading the blog.
Maybe it's not Remote, but I should definitely read a book about working remotely, considering I do it for so much of my time.
* The Mythical Man-Month, Brooks
* Rapid Development, McConnell
* Extreme Programming Explained, Beck, et al
* Test-Driven Development by Example, Beck
* Domain-Driven Design, Evans
And something that wasn't a book but made a huge impact was Eric Ries's blog, Startup Lessons Learned, circa 2009. He correctly spotted that things like Extreme Programming are generic software development processes, but that in specific domains you could take advantage of their flexibilty to enable new business practices, as in Blank's "Customer Development" process.
It'd be one thing if there were managers out there actively disputing the ideas in the book, but I don't really ever see that. Like you say, more often I find managers that claim to have read it and agree. But still, shit like "let's flag if this project is late so we can try to add more people to it" gets said all the fucking time.
I think with a lot of managers, trusting downwards just isn't a thing they're able to do, and so the only move they think they have is to view engineers as miners chipping away at "man-months" of software work. Sometimes I almost think it doesn't matter to them if it actually works or not, it's just the only move they see so it's the only thing they'll do.
Heck, I stepped away from my last job in part because the environment was that (really, 'leadership' was just generally so bad, and this was but one of its manifestations of suck). I kept having status meetings as we neared a due date (that had been set by product, not engineering, and which our velocity said we would not make) asking us if we'd make the date. To which I replied "Data says no; gut says maybe. If I say we're not going to make the date, what are we going to do differently?", and to which they had no answer -except- "pull people from other projects and put them on this one". Nevermind that the whole difficulty was learning the integrative aspects, i.e., communication, NOT implementation (and that was why gut said maybe; we had learned a lot already, which is what took a lot of time; we were still facing both known and unknown unknowns).
Meanwhile, the teams that were getting kudos were the ones where managers were just like "yep, we're floundering; give us more people". If they succeed, they were brilliant and knew to ask for help. If they failed, well, it was doomed, but at least they knew to ask for help. Nevermind if more people were actually helpful, and derailing other projects just to get them was worthwhile. Clearly, I was a bad cultural fit; I cared more about getting things done efficiently.
The Mythical Man Month reference there was helpful for not derailing things by having more people thrown in the mix; it wasn't helpful for avoiding blame.
For sure. One of the curses of the modern business environment is the belief in management as a universal skill. That if one has an MBA one can manage anything. That all one needs to do is find the appropriate graph and make it go up and to the right. In practice it ends up being an erasure of domain-specific knowledge in favor of the naive beliefs of the powerful.
A great example comes via Poppendieck's "The Tyrrany of the Plan": https://www.infoq.com/presentations/tyranny-of-plan/
Transcript here: https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of...
The Empire State Building was built on time and under budget, but they did not have a complete plan when they started. This sounds impossible to the modern ear, but that's because executives see plans as a substitute for competence.
It wasn’t until our 3rd or 4th interaction that I put two and two together. The result was a very nicely signed and personalized copy of the MMM.
It's difficult to get a man to understand something when their raise depends upon them not understanding it.
I can still remember when the CTO I argued with came into the room one day and said that he'd been given the green light to hire as many additional people as he liked. He was grinning from ear to ear. I suspect he knew it wouldn't actually fix any of our issues but he didn't really care.
https://teachyourselfcs.com/
The top 2 recommendations - based on return to learning on time invested - are: 1. Computer Systems: A Programmer's Perspective 2. Designing Data-Intensive Applications
There's no magic information you're going to come across to further your career in any sort of literature on software development, or indeed any sort of career in general. Any practical books are verbose versions of framework documentation, coaching books are common sense, others formalising experiential learnings - which are only realised from having that experience itself.
This makes sense; otherwise you could get any Joe Blogs to read a couple of books and become an expert immediately.
I worked through The Little Lisper when I was at university and I got a lot out of it, for example.
Can you recommend any other content like that?
Still, a couple of random things I can think of:
The Spatialite Cookbook is no longer maintained, but I think still useful. That's structured as a sequence of fun exercises: http://www.gaia-gis.it/gaia-sins/spatialite-cookbook/index.h...
I also enjoyed Peter Norvig's Design of Computer Programs online course: https://www.udacity.com/course/design-of-computer-programs--...
But in general - if you are just trying to become a better software developer (e.g write clean, well tested code) you are absolutely right no book will get you there, hard work will.
Take the 37signals Remote book, for example: as a run-of-the-mill engineer, you quite literally have no say in what the work/office culture of your employer is. Unless you're (at a bare minimum) a VP, no one cares what your opinion is, as you have zero political capital. I don't want to be too negative, so here are some books I would suggest:
Being a good engineer is necessary, but not necessarily sufficient, for being promoted.
There are some toxic workplaces where politics is the only way to get ahead, but they tend to fizzle out quickly as the upper ranks become filled with people who aren't good at anything but politicking and the good engineers and managers leave for greener pastures. It's certainly not characteristic of a typical, successful company.
In fact, neglecting engineering skills and trying to exclusively play political games is one of the quickest ways I've seen people tank their engineering careers. The problem is that it might work at first, for a short while, but eventually the people around the person realize they're all talk and no show.
Reputations are hard to build but easy to destroy.
That’s when they pull up stakes and move to the next company.
I disagree. In fact, the third or fourth stage of your promotion will often be a leadership position (junior, senior, principal/tech lead). If you're okay with being a "senior engineer" until you're 45, you're going to be in for a rough time when you get inevitably laid off.
I know way to many Anchor-out, homeless, or stay at home dads (Kids moved out decades a ago, or sleeping in the basement. Wife begrudging hating your unemployed, but is still civil when you are around.) who were in Computer Managment.
Save the money while you're young. Computer skills seem to mean nothing after 50. An those ass kissing people skills (Managment) are finished the moment you are laid off.
You will not be the 65 year old working Doctor, or Lawyer.
The barrier to entry is just too low, and since you guys are above unions; I hope you have a sympathetic family.
It will make you liberal though.
If you have the right attitude you will get through it though. A divorce might be necessary, but you probally knew that one was comming for years.
Most competent companies let good engineers who won't be good leads stay in IC roles with bigger responsibilities.
And I’ve seen many cases of “run-of-the-mill engineers” change cultural aspects of the office and the company.
This is all based on mostly one employer, but a very big one. I suspect smaller companies make fast promotions for talented engineers and cultural changes even easier.
(I do agree that sometimes people that look in no way special at first glance turn out to be fantastic founders)
The operative words being "My Career". The article is a subjective listing of books that the author found to be useful in their career and at the stage of their career they read them. Not an edict of what every SWE needs to read to progress in their career.
I have read 1 of the 4 books on your list (and read another partially) and haven't found them to be remotely helpful in my career progression. They may have huge impact on someone else at another stage of their career, that is the point of lists like these.
They will fuck anyone over for telling them they must lower their standards for the crap like being inclusive or no kids left behind, as if everyone can learn advanced maths. They's how they got better at maths. That's how they produce good students: they believe everyone's potential, and push students as hard as necessary. They still have catch-up to do, but they are getting closer everyday.
Who hurt you?
My experience has been quite the opposite. Creating a great work culture is well within the ability of even new engineers. I would probably suggest the opposite of you, in fact, and suggest that, between engineers and the VP/C-Suite level, mid or senior level engineers probably have the most sway over company culture. As an engineer, you have time, inclination, and ability. VPs don't have the time, CEOs don't have the inclination, and, frankly, no one but the boots on the ground have the ability.
Ah yes, the same companies that laid off mass numbers of engineers in 2000 and did it all over again in 2008. The same companies that vehemently fight any kind of unionization efforts and the same companies that insist to haze potential hires with live-coding & whiteboarding tests even though folks have 10+ years of experience. The same companies that were wage-fixing employees' salaries and had to pay out almost half a billion dollars in restitution[1]. Those companies? If you think you have any kind of influence on corporate culture as random engineer #3419, I've got a bridge to sell you.
[1] https://www.npr.org/sections/alltechconsidered/2015/01/16/37...
Don't see any problem here. I've met my share of "10+" years of "experience".
On the other hand, as a mentor I found it useful to re-read it (or, read it through properly, I'd read large portions when I was younger but never all the way through). There's a problem of becoming too expert where you can't communicate with novices in the field anymore, at least not like they actually need you to communicate with them. There was benefit, for me, in re-reading it and nodding along and being reminded of the things I'd learned along the way, getting a name for them, and a discussion I could use as a basis for my mentoring.
Such as?
But they get very helpful once you've been in a few battles and failed miserably. You'll be able to determine where you went wrong, whereas before it escaped you. You'll then find out how to not make those mistakes again, and do it right next time.
The real value is that it is much much harder to pass that sort of insight along to engineers you work with or (especially more junior) manage. Books like that didn't make me a better writer of code, but I think they made me a much better communicator, engineer and manager.
Link to a pdf of the book: https://web.mit.edu/alexmv/6.037/sicp.pdf
https://www.mit.edu/~xela/tao.html
Just the section on correlation vs causation is invaluable.
I think the generic bit of this advice is to excel as an engineer is to focus on the business, not the tech.
I must admit that this kind of attitude triggers me. I have worked in the energy sector, in engineering (but not IT) heavy companies, and many have this attitude. "its easy to learn programming", "we just need to teach the engineers python" etc etc, and I have seen MOUNTAINS OF SHIT so tall you would faint. It's easy to get tricked, because being both the user and developer at the same time can be such a boost. But the moment there are more users things get hard. The moment the code base gets so large that you can't keep it all in your head, it gets hard.
Software development is easy until its not, and it surprisingly quickly gets to the "it's not" stage. And then you get excel sheets in python.
Some "subject matter experts" make good programmers, but in my experience its not because their background, but because they are smart and have talent for it.
I believe it was this one with a slightly different name
For example, if you are developing software at Uber, there is no "domain" to speak of. Ditto for a search engine at Google. The company pioneered information retrieval in the internet age, so what's the relevant "domain" there?
Of course, if you are writing MCAS software for Boeing, having a good understanding of Control Systems, or Aeronautics (which you can gain by attending nontraditional programs in colleges or universities) will be very helpful. Same thing for something like trading firms (where it's practically formalized and there are programs that turn out quants), accounting firms (e.g., Intuit) etc.
The general advice that would still apply to both would be: understand who your client is and what they need in the context in which they evolve, be they consumers in a country you're not familiar with or mechanical engineers you barely know the job of.
- "Hey, I saw a statistic that females are anxious about taking taxis at night in France. Why don't we add a feature to let people share their locations with others?"
- "In London taxi drivers have to pass The Knowledge, a test on roads! Have we considered adding a similar pre-requisite test for drivers in that city?"
- "I noticed a lot of drivers on Reddit have been complaining that the tips aren't viewable on the app, but we have the data. Why don't we add that to the drivers UI?"
Etc... The sources of this information would be user channels like Reddit, taxi-related news sources in countries you operate in, and keeping up to date on legislation. Sure you might not have the ability to make any of these changes yet but if you stay ahead on these factors it's definitely the way to move into a position where you can have that level of impact.
As a consequence if one changes jobs say every 2-3 years (different domains) then they become generalist engineers.
In my experience one has to spend 10-12 months at a company to pick up a domain by being deliberate at it. It may look like a big investment but the payoff will be significant once they have sufficient context in their head.
I love it!
It's not that I don't comprehend, it's that my brain finds it boring and hard to focus. I think I have trained my brain so much on rapid skimming of websites for useful info, while throwing away most of the content, that I tend to do the same with books, which really doesn't work well.
Has anyone found alternative ways to consume this information for brains that work like mine?
We skim websites/articles because there is so much information out there, and not all of it is useful. I skim articles and then go back to fully read them once I make sure they’re actually worth the time. Same with some books, but books generally are worth it since they went through the publishing process, etc.
I set a single New Years Resolution goal to build this muscle: 12 books in this year. I’ve read 22 now.
What compels me to keep reading is the Reading Insights Streak feature in Kindle. It’s like a little reminder I can always check on to see if I’ve read today or not.
Schopenhauer’s essay “On Reading” is instructive here. He recommends reading fewer books but going deeper into them.
A book that definitely wasn't in the category I described above (for me) was John Ousterhout's Philosophy of Software Design - https://www.amazon.com/Philosophy-Software-Design-John-Ouste... . I haven't run into software design/tech books like that very often.
Many books belabor the point and take a chapter to explain what a paragraph could.
It might sometimes be useful - for example, to explain a scenario to a newbie who can't relate from their own experience - but for someone who's been in the industry for a while, most of that information is just not useful.
This style is popular nowdays and finding books that succintcly describes a subject is hard. This is mostly because you need to have common ground, and writing for the smallest common denominator is better.
Trying to pick up a book about a new programming language that is trying to explain the concept of an 'array' or whatever is annoying--I wish there was something to just lay out (still in a thoughtful and guided way) the concepts I needed to understand for that language based on already knowing several others.
The a builds on b builds on c style of learning is only one way of learning things, and in many cases, the foundations (a, b) serve you no real value.
Just jump to the sections that interest you (c) and go back to previous sections if you feel like you’ve lost track of what they’re talking about.
For example, the first 20 pages of ‘Remote’ cover why remote working is good. It is intended for people who are considering if remote working is suitable. If that’s not relevant to you, do not waste your time reading it.
Of course, you still have to actually sit and read the chapters that interest you… but, if you struggle with that for the chapters you’re actually interested in perhaps a more project based (do a thing, use references from book) approach, or notes based (treat book as study text, rewrite it as your own notes) might work for you.
…but, don’t feel bad. These are super boring ass books with a few interesting parts to them.
Often, it’s some variant of starting with studying the table of contents then doing a fast first pass of the text. That’s usually a pretty good way of figuring out where to start.
Does that mean reading it end to end?
If you can't read books, then you are missing out on a lot. It's important to be able to read books (and work through large portions of them). Start reading books by reading fiction, then transition into nonfiction books (that are closer to fiction at first, e.g., history), finally transitioning into long-form technical books. If your budget permits, buy a long-form book on a technical topic and commit to reading it instead of just jumping on a website. For example, if you want to learn Kubernetes, just buy the Kubernetes book written by Beda et. al. I doubt any website will be better than that, and you will spend perhaps a week or two on a shallow read of the book, but you'll have found that you have a much better appreciation of the subject matter than you would have had you just glanced at a few website articles.
What helped me to go back on track was reading novels and constantly asking myself: did I understand the last sentences that I've just read?
I love reading literature though. Hours, engrossed.
This might just be me. Tech is just a means to pay the bills for me - there’s no passion, hatred, love involved here.
I cannot just sit and listen without doing anything, I need to be doing something with my body to be able to stay focus on an audio feed. I mean, I can do it but I won't be able to keep my attention on the audio content. When I bike, walk, or do laundry, no problem at all!
The only exception was a Linux kernel podcast but the format was really unsuitable for the topic.
Do you have any good technical podcast to recommend?
"Algorithms + Data structures = programs": https://adspthepodcast.com/
Crypto Critics' Corner may be my favorite podcast: https://cryptocriticscorner.com/
Anything from microbe.tv: https://www.microbe.tv/science-shows/. They have podcasts covering evolution, microbiology, neuroscience, parasitism, virology, urban agriculture, and more. Lot of stuff to dig into, you can try and see which one you like.
Not technical, but I like to listen to Startup Therapy, I like how they openly talk about failures and mistakes: https://adspthepodcast.com/
Someone once recommended me to start at the back of each chapter and do the the problems and only read the chapter or even parts of the chapter for problems I couldn’t solve.
It comes with its own set of drawbacks but it does help with getting through text books where the author was paid by per letter.
For the really good books you’ll actually reach the end.
When I was a kid, I read books by the meter, regular at the local library. At age 35, after life happened and after I was immersed in quick internet articles, I realised I haven't finished a book in ages. Which made me slowly read more, having that extra page after "mental exhaustion", slowly working my way up to a while chapter ... trying to get back into the habit.
Now at age 41, I read long stuff again - best decision I've made. But I am under no illusion that I won't fall back into bit-sized consumption if I would stop keeping it up.
Pragmatic Programmer for example could be thought of as a very curated list of blog articles. Great book, but also not intimidating or deeply technical in that sense.
My example is from the Windows Internals books, it’s a great book, but I don’t think the authors could write it in a “gripping” way, that’s just technical books.
What I do however be it books or video is chunks, takes MUCH longer to do but I find for me it sticks, so if in my learning season (I do bursts of learning, burn out leave it for a couple of months, rinse repeat),
- Read a section or chapter - Make quick, rapid notes in my notes app (or notebook, I use bear but whatever suits yourself) - Once I’ve done, go to sleep (I normally study at night, my brains more in a learning mode then for me) - Maybe at dinner time (at work) I go through my notes, if it’s something I feel may benefit my colleagues I make a brief PowerPoint, I try to translate it into a less technical write up, not everyone is super technical, it’s just a job to them!.
I have a terrible memory for learning, I remember things long term great, short term not so much, so I reference my notes a lot, it’s essentially my mind map/bank.
Video learning is very subjective, I’m currently learning Cisco Umbrella and it’s very boring to me, the creators voice is very mono tone and boring to the point I’ve nearly fallen asleep, but other creators (mostly in the Microsoft MVP zone) are very lively, a good mix of demos and theory that keep me engaged and actively want to learn, Pluralsight is the same, keeps me awake and motivated, I found CBT a little on the boring side in comparison.
No issues doing the actual programming, could sit for hours on end without any issues.
One nifty thing about my ADHD is that something that was super interesting can become dull as hell. For no apparent reason.
Issues with focus, staying on task and motivation are generic issues that everyone has. Just like everyone gets sad or down sometimes. When it becomes a constant problem that affects your life, that's when it becomes a depression and needs treatment. ADHD is similar, except that it doesn't really come and go but is more of an undulating constant.
On my phone I've read 250k word books cover to cover, same books I could never read on a PC. Attention is weird like that.
Another trick is getting your dopamine* externally. There's an association between ADHD and substance abuse, and I can see why. Pharmacology is a cheat code: a few hours of infinite motivation, will power, and attention.
Unfortunately, when people start needing a substance just to feel normal, that is the definition of an addiction.
(* More complicated than just Dopamine or Serotonin, both seem to play a role. Medecine has not solved this one yet.)
If they would otherwise not feel normal and there are no negative side effects, is that a problem?
Negative side effects of note with usual ADHD medication (amphetamine salts) include increased cardiovascular load, development of a tolerance (you need higher doses to achieve the same effect). Sometimes amphetamines induce small changes in personality, rarely full blown psychosis (this has happened at therapeutic doses!).
In general you should apply the same sort of risk-benefit analysis we use for every other drug. If you don't experience any side effects so strong you want to stop, and you believe you're aware of the risks, great.
If you're taking them without a script, I'd advise you to find a steady-state dose that works for you and stick to it. Don't let yourself increase the frequency or the dose without a conscious decision. That's how many people have spiraled.
Finally, I think it's important to have a lot of respect for psychoactive chemicals. Nature doesn't care very much for human overconfidence. If you start being careless, chemistry will do what chemistry does.
I'm a prescription-attention-drugs person and specified drugs do not exist.
Disagree. What is 'normal'?
A better definition for addiction is the brain no longer produces the neurotransmitter without the presence of the drug (or is doing so at a highly diminished rate). There's no evidence that such occurs with the amounts prescribed for adhd.
For that matter, people needing an external source of a substance to feel normal is unavoidably part of being an organism. We need water, or we wont feel normal. We need vitamins -- and plenty of people have vitamin deficiencies, are they addicted to said vitamins?
I use one of them, and it has been a great help for me for studying and for work. I don't take them during "off-time", i.e., weekends and holidays, and I don't feel like I need them for my hobbies, where part of what makes it fun for me is that I can take my time, shift my focus constantly, and define "progress" by my own internal metrics.
I don't know how to evaluate the risk, basically. Medical stuff tends to have a lot of noise.
But also, every body and mind are different. Consult a specialist. There's many different types of ADHD medication out there now.
w.r.t. books on programming - I've found that ones that offer a hands on project really aid in staying engaged with it. That's usually enough to give you a solid primer on a topic, where other literature starts to become a bit more accessible/less of a drag/less overwhelmed with unknown terminology
No, your brain just tricked you. It trained you into thinking that you're doing rapid research of useful info, while it just looks for path of least resistence.
Minimum means that I need to finish it that day no matter what.
I put a maximum because I found through trial and error that if I push myself too hard, even if a topic is interesting, I burn out quickly and procrastinate, sometimes for months, before continuing reading said book. And that is worst case scenario for me.
Maybe your brain does not need to work like that.
On the other hand, I taught myself electronics and programming from a combination of books and just trying things. Maybe trying things is a different kind of classroom in a sense. Certainly a different teacher: Mother Nature, who takes no crap from cocky teenagers.
The content may not be super relevant immediately, but the book and (really simple) methodology of taking notes on these readings and graphing relationships between concepts means you're slowly building a network of knowledge that grows and becomes more powerful over time.
I used to but now it feels like a fun game to me.
As for having trouble reading difficuly texts try this - read two pages. Try to recall what you read. Then try to connect it with what you already know. You only need to do it for the fundamentals not every sentence and it will help build up flow.
[0] https://archive.org/details/the-unwritten-laws-of-engineerin...
For me, there are books that had a negative impact on my work. The GoF book is one such book, and its impact on my development is so distructive I can't even begin to explain. It's not only because it tries to codify coding as a sum of recipes, but people reading it end up with the scary idea that there is only one way of doing things, and that one way has a clear name, and a single possibility for implementation. The GoF buffs are those that keep stressing the most autoerotic interview question: „describe me one design pattern, other than Singleton”.
Now worse than people who read the GoF book are people who dove deeper into the issue and learned about more design patterns from other books. One such people screwed my career development for 7 years because at one internal interview he asked me out of nothing about the „half sync half async pattern”, that solves a problem that he wasn't able to describe to me. And since I failed, I was forever on their s*t list.
I think there are good books that can influence your life in a positive manner, but those are incremental changes, things that add a few things here and there. I would expect to see on lists that „changed careers” books on programming languages, like Kernighan & Ritchie on C, or Stroustrup's or Alexandrescu's books on C++. Or books on fundamentals, like Hennessy and Patterson, like Tannenbaum's Network or Operating systems, Knuth, or Cormen&al on Algorithms. But since I rarely do...
This is a sign, that in order to solve the problem, you must move on to a job that isn't the problem.
Abelson, Sussman's Structure Interpretation of Computer Programs also good recommend - helps show that whilst it's not magic, fact everything still works is magical
1. https://stackoverflow.com/questions/19546115/which-lang-pack... 2. https://eli.thegreenplace.net/2007/06/19/introducing-the-sic...
I also agree that "changed my x" is a bit of a stretch; perhaps it's hyperbole and should be taken as such. There are very few "things" that change one's life. Perhaps being in a war, or a natural disaster or some such, having an encounter with death but averting it or some such event could singlehandedly change one's life, but I doubt that reading a book or a set of books is one of them.
Somehow related, Google right now demands interviewees to prepare using the Cracking the Coding Interview book. Pretty much it's like someone sells you a door and hands you a set of lockpicking tools instead of you using the key to enter.
I think the problem are the people who can’t abstract the message of the book and instead use it as their reference for absolutely everything, over-engineering the hell out of things. When I’m asked the sort of questions you describe, I also just ask if they could instead explain the problem, because being able to solve problems is all design patterns are about. If they can’t, I would respectfully ask how their knowledge of the design pattern will then help them in their job.
Advocating for a perverted cloudy way of overengineered sw that builds cvs and horrible enterprise sw.
There are much better ppl to read out there. Anyone actually writing long lived sw. Linus, sam neal, anyone actually DOING it rather than living off self indulgent books.
I think Fitnesse [1] is quite relevant. That said, not a lot of FOSS work from someone like him, to put the things he preaches in large and complex projects that we can look at the source and learn from.
[1]: https://github.com/unclebob/fitnesse
The problem was with this person, not so much with the GoF book. In present days this person might have become an FP fundamentalist and come up with some exotic category theory quiz question that he was very fond of himself. The GoF book is now of course outdated but the idea of categorizing best practices from the industry was a good one. Unfortunately many good ideas will be abused by people who lack the common sense to know how and where to apply them. A similar thing has happened to the agile software development movement, to microservices architecture (every service is a microservice?!), unit testing (people trying to reach 100% coverage).
It doesn't do anything of the sort. It may try to codify some specific solutions to SOME specific types of problems, in a very narrow OOP'y context, but if "codifying coding as a sum or recipes" is what you took from it there's little wonder it has colored your view, so.
As somebody who didn't study CS in college, the books that most changed my career were:
Another thing I've found extremely educational is to read major incident postmortems (SEV0s and security SEV1s at FB, "huge" OMGs at Google). If you ever find yourself anywhere with planet-scale infrastructure, make sure to read these write-ups. They are treasure.It is important to keep those in mind and then determine what is more important: career progression or work satisfaction.
Code: The Hidden Language of Computer Hardware and Software
The Design of the UNIX Operating System
Designing Data-Intensive Applications
They taught me that there is no magic. Everything is logical and comprehensible.
UNIX taught me about the how an OS deals with hardware resources and the software that run on them. I now understand the environment in which my processes live as well as the structure of a process.
DDIA taught me about the structure of data, how databases operate on data through transactions, the difficulties of synchronization across databases, and the way data streaming works.
Designing Data-Intensive Applications was really good too, the best new technical book I've read in the last five years or so, though I have had trouble applying its techniques thus far.
- The Elements of Computing Systems: Building a Modern Compiler from First Principles
- Operating Systems: Three Easy Pieces
- Systems Performance: Enterprise and the Cloud
- Exercises in Programming Style
- The Little Typer
- Conceptual Mathematics: A First Introduction to Categories
I could add Queinnec's Lisp in small pieces (for the gradual derivation of fancier and fancier interpreters, the continuation one in CLOS was cool, and the bytecode part also very very cool)
Bratko's Prolog book was nice.
I'm tempted to mention the dragon book but I only read 40%.