đŸ Archived View for dioskouroi.xyz âș thread âș 29364892 captured on 2021-11-30 at 20:18:30. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
________________________________________________________________________________
The one thing that I find is not helpful, is the âlitmus testâ approach.
i.e. âYou are a bad programmer/engineer/scientist/person, because you did not read this book, or know this technique.â Thing.
I see this frequently. As a [mostly] self-taught software developer, Iâve been on the receiving end of a lot of this behavior.
In my case, I have a real âOh yeah? Iâll show you!â streak. I became expert at stuff, simply because some e-bully told me I was bad at it (because they were the only ones fit to judge others).
Not everyone has that kind of stubbornness. I suspect that a hell of a lot of truly gifted folks never realized their passions, and that our industry has been robbed of significant talent, as a result.
Maybe Iâm looking at the past with rose-colored glasses, or I was fortunate to run into the people I did, but I donât recall encountering a lot of this behavior, when I was getting started. I needed a lot of help and nurturing, when I was younger, until I reached the confidence level required to have an âOh yeah?â response. Iâm grateful that I got it.
_"A new idea is delicate. It can be killed by a sneer or a yawn; it can be stabbed to death by a joke or worried to death by a frown on the right person's brow."
-Charles Browder_
> _"A new idea is delicate. It can be killed by a sneer or a yawn; it can be stabbed to death by a joke or worried to death by a frown on the right person's brow." -Charles Browder_
Not just ideas, people have lost their careers to unkind jibes. Here's English Cricketer Monty Panesar explaining the unexpected course his life took after a retort by Australian cricketer Shane Warne that "Panesar hasn't played 33 matches, but the same match 33 times" in a damning indictment of his uninventiveness and inadaptability:
https://www.theguardian.com/sport/2021/nov/28/monty-panesar-...
A relevant comment from a thread on CalyxOS:
https://news.ycombinator.com/item?id=28101853
"I fear not the man who has practiced 10000 kicks once, but I fear the man who has practiced one kick 10000 times." - Bruce Lee
So now I'm thoroughly confused, which one is better?
I'm pretty sure Bruce Lee would agree that the one kick needs to be employed in many contexts and situations for that to hold.
I don't think the concept was as well known. There was less chance for robotic/fragile implementation of things in the past.
The intentional one.
_> A relevant comment from a thread on CalyxOS:
https://news.ycombinator.com/item?id=28101853
_
Ooh... that's ugly.
Fun story I like to tell people about exactly this.
A little over a decade ago I was working a gig at the software subsidiary of a fairly large non-tech multinational. It was a lot of mostly nice people and a mix of skills and experience as youâd expect.
Anyway - there was a manager (M) on a project I was on who was.. unpleasant. They had quite an ego, and were very much the type to pass blame down the chain.
Regardless, there was a student on one of their projects who was struggling - I had spoken to this person a few times and they seemed eager enough to learn and had a friendly manner. I never worked with them directly so couldnât comment on their capability - but even then, they were at the start of their career and still learning so obviously you would have tempered expectations.
Anyway, one day M comes in and people ask if newbie is out sick or is coming in later that day. M proudly exclaims that they wonât be coming back as they had a heart-to-heart the day before and M let them know that software development was not the career for them, that they didnât have the right skills for it, and that they should pursue a career doing something else instead.
M was saying this with a grin, not out of malice, but as if theyâd just saved this poor soul from wasting their time trying to succeed at a career that this expert of the craft could tell they were unfit for.
I was utterly dumbfounded that someone could be so incredibly conceited as to think they could possibly make a determination like that of someone just starting out that was getting no support from their boss.
I left soon after in no small part because I actually felt nauseous being around the person after that. I donât think they stayed around for long but I heard from long-term folks in the same place that the distaste of this individual was fairly widespread.
tldr; weâre all just bags of meat, eating and pooping on a ball of rock flying through the cosmos. Be kind to people, and pull your head out of your ass.
Thanks for sharing that. It makes me angry; just hearing this, thirdhand, and a decade later.
I was a manager at a company that paid âcompetitiveâ (i.e. âlowâ) salaries.
A significant part of my job was identifying âdiamonds in the rough,â and helping to train and nurture them; then, encourage them to stay.
I feel that I did fairly well, here. When they finally shut down our team, the person with the _least_ seniority had a decade.
These were senior C++ developers. They could have gone anywhere.
As a young kid on one of those "competitive" jobs, I've always wondered about this. Do you genuinely encourage them to stay, or do you secretly wish them to move on to better work as well? Surely getting stuck there for a decade isn't the best thing for their career.
Yes, and no. A few did move on, and had well-paying careers, but it took them a long time to find happiness, and they tell me that they never found a situation that was as comfortable as when they worked in my team. The final team members have moved on to do fairly well, although it took a while. They are brilliant engineers, and will be a credit to any organization that hires them.
The pay wasnât awful, but I was a good manager, and worked hard to accommodate things like family obligations, and, in a couple of cases, serious medical issues. The company had its flaws, but, for the most part, treated its employees well. As time went on, that became less and less. By the time I left, I felt as if the company had become quite rapacious, in its HR policies, and that made me sad.
The pay may not have been that great, but the work was very interesting. We were a marquee brand imaging corporation (which is why they felt they could get away with mediocre pay), and the technology was pretty awesome. We regularly worked with some of the top engineers and scientists in the world. It was an excellent line in your CV.
I have come to learn that money isnât everything. Thereâs a tremendous amount of cynicism in our industry, and that is really pretty discouraging. Money has been quite corrosive to the joy of software development, in my opinion. Real damoclean sword.
I was really hoping for some karma in this story, but it wasnât there :(
I can't speak to this story itself, but I wonder about the general principal underneath these sorts of objections.
That is: we should just be naively encouraging of people to pursue whatever they happen to be trying to pursue. This seems born of a boomer-era "be yourself" world view in which "anything is possible". I think this cheats people a great deal.
When physics is demonstrated in schools and TV as some game, it shouldnt take until Masters to figure out it isnt. Programming likewise.
What I see in this culture of "be yourself" is really an admonishment for not "trying to be successful", in the narrowest sense, ie., blindly pursuing programming even though you're not suited to it.
People shouldn't be hoodwinked into careers they arent going to like on the basis they "should like them" because presumably "anyone can be successful" and "everyone needs encouragement". Underneath this ideology is a very narrow notion of success, and a very concerning lack of empathy.
"Encouragement" isnt a neutral good; it's an instrument to develop people -- often in one's own image. There's a lot of people "encouraged" into career's that depress them.
Maybe some people take to programming like a fish to water, but plenty of others struggled at first. Knowing when to give up is important, but part of that is knowing when _not_ to give up. That is a complicated and individual question; an ignorant gatekeeper who discourages anyone who's not immediately successful isn't helping here.
The gordon-ramsey (army coach, sports coach, theatre director, ballet director...) school of "encouragement" prescribes the opposite.
That is: if you arent passionate enough to overcome discouragement, you arent passionate enough to excel.
Of course, we dont need excellent programmers en-mass. However, it is interesting to observe that this "egotistic troupe leader" is a fairly common form of small-group excellence-seeking human organization -- and appears to work.
It gets more-and-more common when looking at how the best "troupe-sized" groups in the world are organized.
I'd be interested in research on this area.
So Iâve thought about this in the years since.
Hereâs the thing though: the person in question was already struggling, as a new person in an office of people with experience, without assistance from their manager.
For their boss to tell them some variant of âyouâre not cut out for thisâ in that vulnerable of a position when you have no frame of reference (and when itâs from the same manager that was supposed to have been helping you) is _wildly_ different to hearing that from an impartial peer.
In several of those contexts, quitting is going to be even more painful than perseverance (in terms of both social shame and punishment). You donât need to worry about alienating captives.
Well, it also has a lot to do with whether or not you want good _teams_, or good _individuals_. The "Marine Bootcamp" methodology is hundreds, if not thousands, of years old, and is how we make good teams.
Teams are how we _make_ awesome stuff, but individuals are how we _conceptualize_ awesome stuff.
I've found that the best products come from hybrids of the two.
I think this is a really helpful remark.
If you look at where this works, the team simply needs to execute -- largely not think creatively. I can see, then, why this is a comparatively rare form of organisation in programming teams.
I wonder if there's room for it in programming training. Imagine being drilled to produce the same algorithm in a variety of languages over-and-over. Would this be useful? (I use to drill myself in writing dynamic dispatch MVC frameworks as a teenager; I could produce a whole framework and app in a 1hr technical interview -- is this useful? I dont know).
I raise this because I've become increasingly interested in rationalising the Ramsey-esq autocrat, as its always been a part of myself I have been most self-critical of; because I am at once very sensitive to upsetting people but also "brutally attentive" to their (and my own) failure.
I have recently been asking myself: is this brutality actually useful? How much? Does it really require the humiliation a Ramsey or drill-sarg engages in?
Recent western cultural mores are aimed at ameliorating ego-injuries. Is there value in causing ego-injuries? Is there value in humiliation? Clearly there is -- it works in some cases.
Its a weird question to ask though: our culture is so preoccupied with preventing ego-injury... it seems immoral and absurd to suggest causing them.
I donât think there is value in humiliation. I feel like it will attract a certain kind of personality. Maybe you want that in a group of Marines who make life and death decisions. Most programming jobs luckily donât involve those kinds of choices (the exceptions may be medical devices, manned rocket software etc).
Importantly you are discouraging a whole bunch of folks who might have much to contribute but have been chased away by the distasteful practices in the industry.
So true. Direct feedback is way under appreciated.
Litmus tests are how git has managed to get away with having such an abysmal UX.
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.
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.
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.
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.
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.
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.
I actually find the opposite.
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.
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.
It would be nice if the table of contents marked where to start if you're already familiar with programming concepts.
Learnxinyminutes?
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.
I had this exact problem.
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.
It seems like if you need to remind yourself if youâve read today or not you arenât doing âdeep readingâ.
Schopenhauerâs essay âOn Readingâ is instructive here. He recommends reading fewer books but going deeper into them.
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.
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.
You donât need to read these books end to end.
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.
Books have been written on how to read a book.
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.
> doing a fast first pass of the text
Does that mean reading it end to end?
Sometimes yes but not always. It depends on the book.
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.
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
A little trick for technical articles that I've found is to use screen readers.
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.)
> 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?
> Unfortunately, when people start needing a substance just to feel normal, that is the definition of an addiction.
If they would otherwise not feel normal and there are no negative side effects, is that a problem?
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.
>there are no negative side effects
I'm a prescription-attention-drugs person and specified drugs do not exist.
What are the go to options?
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.
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.
Why are you 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.
> Why are you wary of using something like that?
I don't know how to evaluate the risk, basically. Medical stuff tends to have a lot of noise.
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.
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.
That seems very unlikely. At least compared to the chance of the drugs having an unmitigated positive effect.
Ok so how do I give this a try?
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.
I would recommend trying something like l-theanine, or other any of the other supplements which have purported effects on focus.
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.
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.
Those are completely different books than what the blog post focuses on. Yours are solely focused on learning tech/maths.
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.
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.
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.
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.
I used to but now it feels like a fun game to me.
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.
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 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.
Don't blame yourself if a book is verbose and tedious. Most books (and youtube videos) are 10% information and 90% padding.
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.
I have the same kind of problem. It has gotten to the point that I couldn't even read sentences that make more than two statements.
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 William Gibson novels, but I have to read them twice. The first time Iâm too confused. Only on the second pass do they make much sense to 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 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.
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.
I suspect you didn't look at the article - I was caught off guard, they're not technical. It's not a list I would go near.
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.
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.
Interesting, I have the opposite issue :)
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!
I've never found a podcast that is not full of idle chatter. Admittedly I gave up searching after trying some astonishingly dull ones.
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?
CppCast is awesome, even if you're not a C++ developer:
"Algorithms + Data structures = programs":
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:
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.
Are these very technical really?
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...
Is not that hard, you just start at the front and make your way to the back.
For the really good books youâll actually reach the end.
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".
I read novels just to reduce the pace of my brain.
Maybe your brain does not need to work like that.
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.
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.
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 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.
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.
Uber:
- "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.
Would you mind sharing the investment finance cert you read?
https://www.cisi.org/cisiweb2/cisi-website/study-with-us/fou...
I believe it was this one with a slightly different name
Thanks!
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.
Exactly. Programming is ultimately pretty simple. The hard part is the specific domain knowledge of the business.
"[...] 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.
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.
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!
If youre doing simple stuff then its simple i guess
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...
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.
> 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.
> 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).
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.
[1]:
https://github.com/unclebob/fitnesse
Would you mind linking to something written by Sam Neal? Not familiar with the name.
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.
>Or books on fundamentalsâŠ
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
This has sat on my shelf for my ten year career and I've never read it. Are there any up-to-date resources to help approach the text?
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.
1.
https://stackoverflow.com/questions/19546115/which-lang-pack...
2.
https://eli.thegreenplace.net/2007/06/19/introducing-the-sic...
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.
This is a gem!!
Just install Dr. Racket and write #lang sicp at the top. What kind of resources to help you approach the text youâre looking for?
Incidentally, I just installed Racket today so I can work through SICP. I was kind of confused by the choices of what to run.
> 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.
What the hell is GoF
â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.
agree. Iâve inherited codebases from new âarchitectsâ who seemingly have just read GoF.
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. :)
Or SICPâŠ
Maybe they are good books, but I found that most of these summaries are bland and generic, as in these phrases:
"The book is strictly about career development and it has a lot of insights ..."
"The book is filled with classic and fresh anecdotes, thoughtful examples, ..."
"This book is amazing to understand the corporate structure and how you should behave ..."
These generic praises aren't good enough to overcome my threshold of interest, so to speak. A better way, if I'd suggest, is to pick a choice quote from the books. Quotes can be hit and miss, but when they click, it can pique the reader's interest in a much more acute way.
I thought I was the only one who felt this way^. Dunno why this article is upvoted so much. Actually the post heading itself seemed so clickbait-y that I didn't click into this link and the comments until it reached 500 votes.
Show, donât tell.
I really donât get why this has 500+ updoots. What am I missing?
Huh. Mine would be:
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.
I love the Mythical Man-Month, but itâs one of those books that only software engineers seem to read, and they already know whatâs in it.
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.
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.
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.
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.
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.
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.
> It's a good book at a certain stage in your career.
Such as?
Journeyman level, earlier if you have a mentor that can help you properly understand the contents (particularly, not to take parts of it as dogma).
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.
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.
I vaguely remember a chapter on code generation which was the only failed recommendation/prediction. The rest was spot on.
As a self taught dev, the books that helped me most are:
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.
I love love LOVE Petzold's Code.
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.
As another self taught, my favorites would currently be something like (from low- to high-level):
- 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 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%.
Would you please elaborate how specifically each of these helped you?
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.
Clean code... To this day I cringe when I see methods/functions over 20 lines long.. Or when I see commented code blocks in one function..
Other have mentioned The Mythical Man Month, and I'd say it's a great book. Sadly, more often than not, it's something I wish I could staple to managements foreheads. "read this now before our next planning session"
The Rspec book was a great book, that helped me fully embrace TDD, and this has led to more sleep filled nights than I had a right to before its consumption.
1984... This one terrified me so much, that I have to include it. I write code much more securely because of it.
Strange in a Strange Land. If only because I learned what GROK means.
> Clean code... To this day I cringe when I see methods/functions over 20 lines long.. Or when I see commented code blocks in one function..
To this day I cringe when I see dogmatic opinions of a fraud taken like an absolute truth.
Interesting. This is the first time I've seen Robert Martin to be referred to as a fraud. I'd like to read an elaboration of this.
I looked around and found this video [[
https://www.youtube.com/watch?v=mb9VPWbrqmE][Uncle
Bob (Robert Martin) is a Fraud!!!]] but most of the comments are dismissive of the review.
The examples in Clean Code are bad and would never make it through modern code review.
qntm did an extensive overview of this:
Not a great video. He starts by attacking Robert Martin for taking 10 minutes to get to the substance of his talk, but then his own video never progresses from there and never gets to anything substantial.
>Interesting. This is the first time I've seen Robert Martin to be referred to as a fraud.
I'm not sure if fraud is quite the right word but he gets a lot of flak on HN for being something of a religious fanatic. E.g. the top comment in this thread:
https://news.ycombinator.com/item?id=26153823
Clean Code was the first book I read that suggested (with concrete examples and rules!) that I should use code as a communication medium to other programmers first and foremost, the orders you give to the computer comes second.
It is an opinionated book and there are some dumb rules in it but it did way more good than harm to the dev community. Definitely not a fraud...
"I read it there first" != "the idea came from there"
Uncle Bob puts forth a couple of good ideas from time to time, but none of those good ideas are his.
I never argued who thought about this idea first it's just where I met it. There is value in gathering good ideas. Could you please point me to the books about clean code before Uncle Bob? I'm interested.
> I cringe when I see methods/functions over 20 lines long
You may find this post interesting
http://number-none.com/blow/john_carmack_on_inlined_code.htm...
>To this day I cringe when I see methods/functions over 20 lines long..
Wait until you have to follow dozens of 5 lines methods for the sake of unrequited abstraction that could have been compacted in an easier to read 30 line method.
> .. The Mythical Man Month, and I'd say it's a great book. Sadly, more often than not, it's something I wish I could staple to managements foreheads. "read this now before our next planning session"
Did you read the book? It's not about the (ab)use of mandays/months in planning sessions, it's about the huge differences in capacities between individual programmers and the importance of having some "10x programmers" in your team.
Thatâs a very opinionated view from someone whoâs actually read the book.
I thought the whole thing was about having a plan, and many well structured, organised teams; having a 10x programmer makes no difference at all without the rest of the things; no matter how great you are, you canât do everything, and if you try, youâll become a bottleneck.
I sympathise very much with wanting to staple âdo you actually have a plan for how thatâs going to work?â to someone in a planning meeting.
> Very good professional programmers are ten times as productive as poor ones, at same training and two-year experience level. (Sackman, Grant, and Erickson)
> Sackman, Grant, and Erickson's data showed no correlation whatsoever between experience and performance. I doubt the universality of that result.
> A small sharp team is too slow for really big systems.
^ literally a quotes from the book.
There is a cost to indirection, a long function can often be way more understandable than a bunch of short, overly decomposed ones.
Why the dots?
I thought only boomers do this.
>1984... This one terrified me so much, that I have to include it. I write code much more securely because of it.
What book?
https://en.wikipedia.org/wiki/Nineteen_Eighty-Four
Your link seems to be broken?
1984
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.
I've not got through the majority, but I consider the up-to-date list on Teach Yourself Computer Science as the best one that currently exists:
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 this book would be great addition to any software engineer . I think book captured the recent modern practices ( last 10 years?) in one place .
The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact
Effective Engineer - Notes :
https://gist.github.com/rondy/af1dee1d28c02e9a225ae55da2674a...
https://www.amazon.com/Effective-Engineer-Engineering-Dispro...
Mine will be none. Only practice, coding, building, testing, exercising again and again has helped me.
Have you considered trying books filled with structured exercises?
I worked through The Little Lisper when I was at university and I got a lot out of it, for example.
I think this is the kind of content I need. One that presents a problem and allows me to figure out a solution.
Can you recommend any other content like that?
Good question. I guess my answer is not really. I'm not sure why I haven't sought out more of this kind of thing.
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--...
projecteuler.net?
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.
Archive.org has "The Unwritten Laws of Engineering" by W.J. King available (one of the book recommendations) [0].
[0]
https://archive.org/details/the-unwritten-laws-of-engineerin...
For me:
I didn't know about "Unwritten Laws of Engineering" - skimming through some of it, this is an excellent book and I wish I knew about it before.
I was fortunate enough to be around senior engineers who took upon themselves to mentor junior engineers like myself. Now that I'm in their shoes, I find that the engineering landscape has changed quite a lot (especially in software) and often find that junior engineers don't see themselves needing to be mentored and sometimes even offended by recommendations.
I think some of this can be seen in this thread as well - some are commenting about how bad these recommendations are, and some even about the general practice of recommending books (how dare you!).
Given that the OP is just talking about books that he felt changed "his" career, I think it's really not something to be challenged and disagreed in such manners.
Commodore 64 Programmers Reference Guide.
The book for the last PC that I could completely comprehend and bend to my will. And then came the #_$__! Mac OS. Freedom into slavery. Rainbow into chrome.
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:
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.
For both C and Algorithms, what do you think is the best since you feel both the above books aren't the best?
I'd recommend books by Clayton Christensen such as the Innovator's Dilemma and How Will You Measure Your Life.
Just the section on correlation vs causation is invaluable.
SICP made me fall in love with programming
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++.
Link to a pdf of the book:
https://web.mit.edu/alexmv/6.037/sicp.pdf
Totally disagree. SICP is the most boring and hard to read book ever written and I don't recommend it to anyone.
I read The Phoenix Project a while ago, and it was pretty good to understand what DevSecOps is supposed to mean. It also convinced me that simpler processes are better and you add layers to those simple processes only if they are necessary. Sometimes you should accept that a more complex process might help track metrics better or might be logically better, but the simpler process is easier for everyone to grok and in that way easier to communicate about. It's been a few years since I read it but it was also entertaining to read in more of a story form than in the usual technical or managerial language.
I honestly found the writing in the Phoenix Project painful, but I'm surprised you're the only one to mention it since I've heard it come up a fair bit elsewhere. I think it's probably more popular in the more traditional IT world than HN's typical audience.
I'm not very particular about reading so I'll just steam ahead on even the crappiest books.
For nonfiction books I mostly put myself in the mindset of learning or conceptualizing the content in a more abstract way, like building a mind map.
For fiction, I picture the story like a movie, which distracts me from bad writing, so this book hit that sweet spot for me, personally, where I could imagine the world and the events but also conceptualize the abstract content.
I actually wish I could read more technical books that have fiction and technical concepts mixed like that!
Edit: Also, for as much as people complain about DevOps here, I'm amazed so few people have read this book. It's literally the book that invented DevOps as a term, right?
It didn't invent the term. John Allspaw and Paul Hammond maybe did, in this talk:
https://www.youtube.com/watch?v=LdOe18KhtT4
(from the comments, I guess this talk is actually referenced in the book?)
Other places credit Patrick Debois who ran the first devopsday in the same year:
https://newrelic.com/devops/what-is-devops
Thanks, my memory gets a bit fuzzy after a while.
Reading this list was interesting, and I feel compelled to share my own. Reading these books won't guarantee a great career. But on reflection, they did shape my world view.
My recommendations can be found categorized here:
http://deliberate-software.com/page/books/
A few in there are marked as "dangerous" - books that I've seen totally destroy productivity, but I included them since it's impossible to refute what you don't understand.
There seems to be a lot of criticism of the books mentioned in the blog and the comments. I am aware that expecting that some books are going to revolutionize a person's skills as an engineer is naive at best, but some people are even going as far as saying that following some principles/books can even be destructive. Ofc following anything dogmatically is dangerous, but is that the only concern? Just keep in mind that not everything can be applicable to every situation and we're good?
Genuine question, as a software engineer of 3-4 years professional experience, how should I approach furthering my skills? A lot of advice is just "do more, practice more, try things" and while that is going to be a significant part of it, I don't believe we should outright ignore books as a valuable source of info. How should I approach and identify books that contain "outdated" or sometimes "wrong" advice?
Understand that most of the books are born from experience. But they represent what that author(s) learned, which may or may not have been the right lesson in every case and, almost always, is not a true universal lesson.
Some views have to be considered in context. If OO means Smalltalk to one author and C with Classes to another their statements on âOOPâ will actually be about two different things, learn from them both but donât misapply the lessons from one to the other (happens a lot).
With that in your head, read the books and question them. Experiment with their ideas where you can or run thought exercises, âWhat ifâŠ?â
Also, read âThe Psychology kf Computer Programmingâ by Weinberg. He presents many different case studies (though briefly) and commentary. One of the few books where it is clear his prescription is, âStudy people and their behaviorâ not âDo what I say and youâll make perfect code.â
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.
I love it!
https://www.developerdotstar.com/mag/articles/read_princprog...
https://www.mit.edu/~xela/tao.html
I can hardly believe the 37signals "Remote" book would've changed anything for anyone. I've read it almost a decade ago when it came out when I was early in my career and it definitely was practically a waste of time. In retrospect, it still is. I also can't tell from the blog post how it changed OP's career.
Not a single one of these books is worth reading imo.
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.
Anything you recommend instead?
Personally, I got a lot of value from _Designing Data-Intensive Applications_ by Martin Kleppmann.
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.
* Mythical Man Month (Experience)
* 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.)
The War of Art * is a must read for anyone and everyone.
* 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.
Ask the collective:
> Designing Data-Intensive Applications
Exceptional in every way.
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.
They do look lame. Spoiler: the 5 books are
* 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
I can't speak for the other books, but The Pragmatic Programmer is one of my favorites.
I agree, I'm sorry you're getting downvoted.
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.
Maybe this the best place to ask this.
Unfortunately I've ended up supporting application and not actually coding so during interviews I can't get past technical parts. I feel very embarrassed by my lack of technical abilities. Anyone else had this issue? How did you rise above it?
Try to find positions where they care more about your thought process and your past experience than in your ability to memorize facts about computers. I'm pretty good at my job and make pretty good software (I think), but I couldn't tell you how to form a red-black tree or do a bubble sort. I routinely look up simple Python syntax and how to articles on bash, but nonetheless I get good jobs, and I can reason about a problem and I can read and understand technical documentation. I started barely knowing Python and googling literally everything, like for loop syntax. I'm not going to be the next big name, but I have satisfaction in life and do ok.
Grind Leetcode
Amazon currently has a "buy 3 for the price of 2" for some books.
https://www.amazon.com/promotion/psp/AFPAOXML5M9KX
Looks like a lot of physical books are half off as well.
This book changed my software career
"Developer Hegemony"
https://www.amazon.com/dp/B0722H41SG
I got my start with
o Computation: Finite and Infinite Machines --- Minsky
o The Art Of Computer Programming --- Knuth
o Structure and Interpretation of Computer Programs --- Abelson and Sussman
In that order. Everything else is syntactic sugar. <g>
My career shaping "book" was Ralph Brown's Interupt List
Ruby Under a Microscope is the first and only technical book I will finish; if you like Ruby and are curious about how things work under the hood it's a joy to read.
You need to look for something that actually interests you. Reading some bible on design patterns with hundreds of useless Java or C++ examples often IS boring. And let's be honest it probably won't make you a better software developer.
A close second to me was Hacking: The Art of Exploitation by Jon Erikson. It's a great introduction to low level stuff and how basic hacks are formed. Really loved it though I admit I never finished it.
Edit: I meant to say it's the first I have finished (which will happen soon). I'm not saying there aren't other worthy technical books out there I'm sure there's plenty.
I liked The Mythical Man-Month. What do people think of Fred Brooks' more recent book, The Design of Design (2010)?
There can be only one: The Elements of Programming Style
There can be only one: Structure and Interpretation of Computer Programs
Is there a good book on object oriented programming for beginners? By beginners I mean people who code regularly but aren't software engineers.
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.
As irritating as it is, the Head First book on OOP is actually decent for a novice.
If your language is Ruby or Python I would recommend Practical Object Oriented Design by Sandi Metz
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.
Depends on your language. But Effective Java is not a bad one if Java is the language you use.
It would be interesting to know more about the author's career.
Rhetorics come and go.
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
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.
yeah that's a huge problem with all of Gladwell's work. Compelling but unsupported.
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
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.
> 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.
> eventually the people around the person realize they're all talk and no show.
Thatâs when they pull up stakes and move to the next company.
> 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.
[1]
https://www.npr.org/sections/alltechconsidered/2015/01/16/37...
> that insist to haze potential hires with live-coding & whiteboarding tests even though folks have 10+ years of experience.
Don't see any problem here. I've met my share of "10+" years of "experience".
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)
Promoted to what though? A job with more responsibility but not really a good enough increase in pay to go along with it? No thanks.
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.
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".
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 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.
Most guys in tech are laid off around 50-55.
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 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.
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.
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.
Pragmatic programmer is rather problematic for me.
I think it covers some good basics for people early in their career but a lot of its guidance can be harmful when taken extremely literally or like dogma.
Read Uncle Bob's books.
If they didn't allow you to start your own website/service or become independent then they did not change your career.
What a narrow minded way of looking at things. You don't know other people's stories, or what their priorities are, or what situation they're in.
It's perfectly possible for your career to be changed without you bootstrapping your own project.