What do you think?
Rate this book
Being Geek: The Software Developer's Career Handbook
As a software engineer, you recognize at some point that there's much more to your career than dealing with code. Is it time to become a manager? Tell your boss he’s a jerk? Join that startup? Author Michael Lopp recalls his own make-or-break moments with Silicon Valley giants such as Apple, Netscape, and Symantec in Being Geek -- an insightful and entertaining book that will help you make better career decisions. With more than 40 standalone stories, Lopp walks through a complete job life cycle, starting with the job interview and ending with the realization that it might be time to find another gig. Many books teach you how to interview for a job or how to manage a project successfully, but only this book helps you handle the baffling circumstances you may encounter throughout your career.
318 pages, Paperback
First published July 1, 2010
145 people are currently reading
1518 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 117 reviews
September 30, 2010
A supposed career handbook, with little relevance to my career. The author has worked at large corporations (including Netscape) and small startups, but his idea of a startup is 80 employees. That's my idea of a large company. He also assumes a kind of corporate culture that I hope is obsolete: The kind where you have a week to prepare for the Big Meeting, the kind where you live and die by PowerPoint. In my career, I never see slides.
Lopp advises the reader on job-searching, but it's a style of search which I consider an illusion: You respond to a job listing with a resume carefully tweaked for the position, pass a phone screen, and interview on site for half a day. When I left college I, too, thought this was how people applied for jobs, but in my experience it's a sign of desperation if you resort to such measures. If you want to apply to a dozen companies and get nowhere, submit your resume. If you want to work, email your friends.
Lopp's advice might apply to those fresh out of college, with no contacts, looking for long-term employment in giant corporations. I've never been such a person, and I never meet them either. If you're freelancing, or working for a startup, then reading this book is useful not for its specific advice, but simply as an opportunity to spend a few hours considering your own situation. It's nothing like his, but in considering the distinction you may clarify your status and your goals.
Lopp advises the reader on job-searching, but it's a style of search which I consider an illusion: You respond to a job listing with a resume carefully tweaked for the position, pass a phone screen, and interview on site for half a day. When I left college I, too, thought this was how people applied for jobs, but in my experience it's a sign of desperation if you resort to such measures. If you want to apply to a dozen companies and get nowhere, submit your resume. If you want to work, email your friends.
Lopp's advice might apply to those fresh out of college, with no contacts, looking for long-term employment in giant corporations. I've never been such a person, and I never meet them either. If you're freelancing, or working for a startup, then reading this book is useful not for its specific advice, but simply as an opportunity to spend a few hours considering your own situation. It's nothing like his, but in considering the distinction you may clarify your status and your goals.
February 25, 2014
Seriously underwhelming at best; offensive at worst.
This is a collection of blog entries, loosely edited into a book. Emphasis on the "loosely." Lopp says that the goals of the book (it has goals?) are to improve the reader's improvisational skills (presumably as regards career curveballs) and to define one's career strategy. Those would have been great, and I picked up this book sort of hoping for exactly that. He delivers on neither, though -- those are pretty lofty goals for something written in dribs and drabs as unrelated blog entries. I would go so far as to say they're post-facto goals, ones that look nice on a dust jacket.
The part that really grates, though, is how much this book is clearly not targeted at me. My gender doesn't align with that of the protagonist in 90% of the supposedly representative scenarios. Lopp has some lame disclaimer in the preface about how we should read "he" to mean "he or she," but dude, if you're being paid to turn a bunch of blog entries into a book, please do me the courtesy of making at least some of your examples gender-free, or alternating. At the very least, don't make it extra clear that I'm not even potentially the protagonist, because of references to shaving and badges hanging from belts.
The chapter nominally for the geek's significant other takes the cake, however. "Your nerd" this; "his" that; all of which very accurately describe a very narrow type of anti-social, socially incompetent dude geek -- many of whom I've encountered and count among my friends, but WHO COLLECTIVELY ARE NOT THE FULL SET OF GEEKS. Argh. To say nothing of Lopp's random urging to get the geek's S.O. to urge him to treat exercise like a game, mentioning that the author himself once passed out in McDonald's after a workout for lack of calories. So many problems with this chapter.
A few pearls, but this is basically just a set of descriptions of scenarios the author has been in, and no help generically. Let's just say that my career strategy was not defined by reading this book.
This is a collection of blog entries, loosely edited into a book. Emphasis on the "loosely." Lopp says that the goals of the book (it has goals?) are to improve the reader's improvisational skills (presumably as regards career curveballs) and to define one's career strategy. Those would have been great, and I picked up this book sort of hoping for exactly that. He delivers on neither, though -- those are pretty lofty goals for something written in dribs and drabs as unrelated blog entries. I would go so far as to say they're post-facto goals, ones that look nice on a dust jacket.
The part that really grates, though, is how much this book is clearly not targeted at me. My gender doesn't align with that of the protagonist in 90% of the supposedly representative scenarios. Lopp has some lame disclaimer in the preface about how we should read "he" to mean "he or she," but dude, if you're being paid to turn a bunch of blog entries into a book, please do me the courtesy of making at least some of your examples gender-free, or alternating. At the very least, don't make it extra clear that I'm not even potentially the protagonist, because of references to shaving and badges hanging from belts.
The chapter nominally for the geek's significant other takes the cake, however. "Your nerd" this; "his" that; all of which very accurately describe a very narrow type of anti-social, socially incompetent dude geek -- many of whom I've encountered and count among my friends, but WHO COLLECTIVELY ARE NOT THE FULL SET OF GEEKS. Argh. To say nothing of Lopp's random urging to get the geek's S.O. to urge him to treat exercise like a game, mentioning that the author himself once passed out in McDonald's after a workout for lack of calories. So many problems with this chapter.
A few pearls, but this is basically just a set of descriptions of scenarios the author has been in, and no help generically. Let's just say that my career strategy was not defined by reading this book.
August 3, 2014
Meh. I'm probably not the audience for this book, since (a) I'm not in Silicon Valley, (b) I'm a remote (to use the author's term, and (c) I'm in the final 7-15 years of my career arc. However, I've been a reasonably successful software developer for 31 years, and there was absolutely nothing in this book that surprised me, or made me think "wow, if only I had known that 20-30 years ago, my career would have been totally different."
Plus...I know this is a book that grew out of blog posts, but it reads like a book that grew out of blog posts. And the stuff on the games of Werewolves and BAB made my eyes glaze over in about 15 seconds.
(Added the following day...)
So, I can see you asking, what would YOU tell software developers just starting out?
(1) Probably: don't. Pick something else. You will run into managers (probably 50% or more at established companies), who have little respect for your work, don't view it as a creative act, and think all software developers are fungible. Meaning that if they have a C# or Java or Python developer in Denver for $x/year, and then they see they can get a C# or Java or Python developer in Bangalore for $x/4 per year, guess what they're going to do? In fairness, some things can be outsourced, and some can't, but to an unimaginative manager, that's the easiest way to drop the bottom line, even if it dooms your business. So, for a career, pick something that requires physical presence, or obvious creativity.
(2) HR is not your friend. They're not there for you. No way, no how. They're there for the company, to ensure that the company does not fall afoul of the law with regard to interviewing, hiring, or firing. They will tell you nothing that not in the corporation's interest for you to know. They may not be your enemy, but they are never, ever, your friend.
(3) If your manager believes that technical reasons are trumped by "well, because I'm the manager, we're going to do it my way," start looking. No, seriously. Huge red flag that should never be ignored.
(4) One of the engineer's jobs is speaking truth to power...but there are ways of doing it that will alienate everyone, and ways of doing it that will allow others to realize, with dawning horror, that, for example, they've committed to solving an NP-complete problem. Try to learn the latter method.
(5) You are responsible for your career. Get more education. Always, always learn (fundamentals, more than tools: tools change too rapidly). Read books, not just blogs.
I've had a long career in this field, and I've never been laid off (which in itself is a minor miracle, meaning I'm some combination of lucky and good). But I'll be just as happy to finish off my professional career and spend time writing prose or code for myself.
Plus...I know this is a book that grew out of blog posts, but it reads like a book that grew out of blog posts. And the stuff on the games of Werewolves and BAB made my eyes glaze over in about 15 seconds.
(Added the following day...)
So, I can see you asking, what would YOU tell software developers just starting out?
(1) Probably: don't. Pick something else. You will run into managers (probably 50% or more at established companies), who have little respect for your work, don't view it as a creative act, and think all software developers are fungible. Meaning that if they have a C# or Java or Python developer in Denver for $x/year, and then they see they can get a C# or Java or Python developer in Bangalore for $x/4 per year, guess what they're going to do? In fairness, some things can be outsourced, and some can't, but to an unimaginative manager, that's the easiest way to drop the bottom line, even if it dooms your business. So, for a career, pick something that requires physical presence, or obvious creativity.
(2) HR is not your friend. They're not there for you. No way, no how. They're there for the company, to ensure that the company does not fall afoul of the law with regard to interviewing, hiring, or firing. They will tell you nothing that not in the corporation's interest for you to know. They may not be your enemy, but they are never, ever, your friend.
(3) If your manager believes that technical reasons are trumped by "well, because I'm the manager, we're going to do it my way," start looking. No, seriously. Huge red flag that should never be ignored.
(4) One of the engineer's jobs is speaking truth to power...but there are ways of doing it that will alienate everyone, and ways of doing it that will allow others to realize, with dawning horror, that, for example, they've committed to solving an NP-complete problem. Try to learn the latter method.
(5) You are responsible for your career. Get more education. Always, always learn (fundamentals, more than tools: tools change too rapidly). Read books, not just blogs.
I've had a long career in this field, and I've never been laid off (which in itself is a minor miracle, meaning I'm some combination of lucky and good). But I'll be just as happy to finish off my professional career and spend time writing prose or code for myself.
September 2, 2013
Poorly edited, rehashed blog posts written in a trying-too-hard-to-be-colloquial-and-"with-it" style, containing only modest and superficial insights, a strong tendency to simplify and categorize people and situations in a gross, reductionist, nearly dehumanizing manner, and backed by a philosophy reliant upon cynical gamesmanship and distrust. In short: all the worst aspects of capitalism in a quick read! I'm more interested in transcending the workaday, growth-worshipping business life than becoming an expert player within it.
Tom Coates recently struck upon a big part of my queasiness with Rands's priors and approach:
"@rands I picture you working in a sort of Game of Thrones-like castle full of manipulators and spies who want to chop your bits off."
https://twitter.com/tomcoates/status/...
(His often self-important, self-parodic aphorisms shared on Twitter deserve a separate discussion.)
Tom Coates recently struck upon a big part of my queasiness with Rands's priors and approach:
"@rands I picture you working in a sort of Game of Thrones-like castle full of manipulators and spies who want to chop your bits off."
https://twitter.com/tomcoates/status/...
(His often self-important, self-parodic aphorisms shared on Twitter deserve a separate discussion.)
December 31, 2012
a very very interesting book for Geeks and alike personalities, it can be boring sometimes, but this is only when it is discussing situations one didn't face yet, but over all it is a very important read for all of us geeks!
i really did enjoy reading it & i totally recommend it to everyone, and for parts where it feels boring, just skim it and keep the book near so that you can return to it when needed ... you will need it, as it discusses all phases of a geek's life/career.
i really did enjoy reading it & i totally recommend it to everyone, and for parts where it feels boring, just skim it and keep the book near so that you can return to it when needed ... you will need it, as it discusses all phases of a geek's life/career.
March 5, 2015
This book feels like a lot of other books by bloggers-cum-authors; just a string of blog posts, and really better in small doses.
I also can't say I've worked in any environments where his advice would apply. And, encouraging pigeonholing people as certain "types" is not a way to get along in the work place. That's just going to give you tunnel vision and shut you down.
The real reason I quit reading this book halfway through had its seeds in the introduction: "For much of this book, my prototypical geek is a he as a convenience. There are plenty of she geeks out there for which the observations of this book equally apply."
Gee, thanks.
Additionally, I noticed partway through that while all the geeks were "he"s, all the managers were not. While it's interesting that the author would make that effort for managers but not his target audience, he also tended to make his examples of female managers embody the qualities people assign to women but not men (e.g. "she's too emotional"), furthering those gender stereotypes.
Eff that.
I also can't say I've worked in any environments where his advice would apply. And, encouraging pigeonholing people as certain "types" is not a way to get along in the work place. That's just going to give you tunnel vision and shut you down.
The real reason I quit reading this book halfway through had its seeds in the introduction: "For much of this book, my prototypical geek is a he as a convenience. There are plenty of she geeks out there for which the observations of this book equally apply."
Gee, thanks.
Additionally, I noticed partway through that while all the geeks were "he"s, all the managers were not. While it's interesting that the author would make that effort for managers but not his target audience, he also tended to make his examples of female managers embody the qualities people assign to women but not men (e.g. "she's too emotional"), furthering those gender stereotypes.
Eff that.
September 6, 2010
This book contains many astute observations about the life of a software developer combined with practical advice about how to approach your career. The book touches on aspects like interviewing for a job, office politics, transitioning to new responsibilities like becoming a manager, how to manage your time, dealing with crises, and thinking about when it's time to find a new job. I found the book did a great job of helping me think about the three questions it lays out at the beginning: What am I doing?, What do I do?, and What matters to me?.
July 24, 2024
Another engineer philosophy book. Read back then in 2015-2016.
I'm not sure I understood even half of it in the same way I understand now. 😆
Re-reading it, I now understand that I learned the hard way to do the right things.
Reading this book is not a trivial task. You may read a section and not grasp anything. Does this mean the book is useless and that passage is not useful? Highly unlikely. It means it's not something that you can utilize at this time or simply don't get it.
Therefore, if you're a software engineer, focus on the book's Career Planning and Development section. Its foundation is the practice of continuous learning.
You either chaotically learn in all directions, as I did in 2015-2016, hope you don't go insane, or you actually have a plan. I recommend the latter unless you want more neighbors in your head. Sorry, poor humor. Asking yourself the questions of "What am I doing", "What do I do" and "What matters to me? What do I care about" is already doing yourself a solid. It's all about direction, less about rules. Have a direction and follow it. Be patient too.
Then comes the "Deconstructing management" part and it's two sides of a coin. One is how to understand and work with your manager better. It's not about psychoanalyzing your manager, it's more about gaining perspective and depth on different kinds of ways you can operate as a report of a line manager. Then there's the part of you being the manager and also hiring manager.
The fact that I use the word manager, is just to use the same lingo as the book, in practice you need to be a servant leader rather than an overseer.
Finally, what's my favorite passage of the book as a hiring manager and person who has built several long-lasting and beneficial professional connections and friendships with great people in the industry?
“Your professional relationship with those you hire and work with is never over. If you're hiring well, you're hiring people not just for this job, but for your career. These are the people who, for better or worse, will explain to others what it is like to work with you. They'll explain your quirks, your weaknesses, and your strengths. When they eventually leave the group, they're taking your reputation with them. You may never talk to them again, but they'll continue to talk about you, and my question is: what stories are they going to tell?”
Did I follow this whole word of advice perfectly? Was I a completionist? Definitely not. I have soured a few relationships, given honesty and help when no one else did, and received nothing for it, yet I trust people may eventually see beyond that.
I'm not sure I understood even half of it in the same way I understand now. 😆
Re-reading it, I now understand that I learned the hard way to do the right things.
Reading this book is not a trivial task. You may read a section and not grasp anything. Does this mean the book is useless and that passage is not useful? Highly unlikely. It means it's not something that you can utilize at this time or simply don't get it.
Therefore, if you're a software engineer, focus on the book's Career Planning and Development section. Its foundation is the practice of continuous learning.
You either chaotically learn in all directions, as I did in 2015-2016, hope you don't go insane, or you actually have a plan. I recommend the latter unless you want more neighbors in your head. Sorry, poor humor. Asking yourself the questions of "What am I doing", "What do I do" and "What matters to me? What do I care about" is already doing yourself a solid. It's all about direction, less about rules. Have a direction and follow it. Be patient too.
Then comes the "Deconstructing management" part and it's two sides of a coin. One is how to understand and work with your manager better. It's not about psychoanalyzing your manager, it's more about gaining perspective and depth on different kinds of ways you can operate as a report of a line manager. Then there's the part of you being the manager and also hiring manager.
The fact that I use the word manager, is just to use the same lingo as the book, in practice you need to be a servant leader rather than an overseer.
Finally, what's my favorite passage of the book as a hiring manager and person who has built several long-lasting and beneficial professional connections and friendships with great people in the industry?
“Your professional relationship with those you hire and work with is never over. If you're hiring well, you're hiring people not just for this job, but for your career. These are the people who, for better or worse, will explain to others what it is like to work with you. They'll explain your quirks, your weaknesses, and your strengths. When they eventually leave the group, they're taking your reputation with them. You may never talk to them again, but they'll continue to talk about you, and my question is: what stories are they going to tell?”
Did I follow this whole word of advice perfectly? Was I a completionist? Definitely not. I have soured a few relationships, given honesty and help when no one else did, and received nothing for it, yet I trust people may eventually see beyond that.
August 31, 2024
I had high hopes that this book would give me an insight into working with engineers. Frankly, there were more tips about how his interview process went and how to tame a geek, not to mention the section regarding Werewolf (as a champion I took a little offense, this game is pure strategy. Don't use it to learn how to be lied to, but how to persuade).
April 4, 2024
Personally, loved it. Lots of great advice and methodology still applicable in 2024 for engineers. Some repeat of his greatest blog posts (as expected since some readers may be unfamiliar). Great handbook at any career stage; Lots of humor as well (appreciated).
March 8, 2015
I have been reading Michael's blog, Rands in Repose for years. Andy and I discussed the latest ones over lunch.
Most if not all chapters come from blog posts usually come with additional polishing. For example, one of my favorites, The Nerd Handbook, is converted from a blog post to Chapter 23 with an introduction on how it should be handed to someone who needs to understand people like me plus an introduction for the recipient.
The best of: Chapter 8: The Culture Chart - "Culture is the undercurrent of ideas that ties a group of people together. In order for it to exist, it must move from one individual to the next. This is done via the retelling of stories.... The is not a corporate values statement on the planet that so brutally and beautifully defines the culture of a company."
Chapter 13: The Impossible -
Chapter 14: Knee Jerks
Chapter 22: The Pond
Most if not all chapters come from blog posts usually come with additional polishing. For example, one of my favorites, The Nerd Handbook, is converted from a blog post to Chapter 23 with an introduction on how it should be handed to someone who needs to understand people like me plus an introduction for the recipient.
The best of: Chapter 8: The Culture Chart - "Culture is the undercurrent of ideas that ties a group of people together. In order for it to exist, it must move from one individual to the next. This is done via the retelling of stories.... The is not a corporate values statement on the planet that so brutally and beautifully defines the culture of a company."
Chapter 13: The Impossible -
Chapter 14: Knee Jerks
Chapter 22: The Pond
April 10, 2017
I cringe to give such a low review because I didn't even finish it. And, there's a chance that it got better as it went on. But, early on, I just couldn't handle the tone and style; I couldn't stay with it.
Maybe I'm too old school, but I don't want authors of my non-fiction books to try to be hip, stylish, cool, overly-informal, etc. I just want valid and useful information structured in a way that is concise and coherent and not overly-boring. This book seems more about the author than the subject. It would have helped to have a sub-title of "a memoir".
Maybe I'm too old school, but I don't want authors of my non-fiction books to try to be hip, stylish, cool, overly-informal, etc. I just want valid and useful information structured in a way that is concise and coherent and not overly-boring. This book seems more about the author than the subject. It would have helped to have a sub-title of "a memoir".
January 24, 2013
I didn't learn much new stuff, but it's a good read if you are wondering what managers in software companies do all day or if you haven't thought your “career” would be in five years.
As most of Lopp's books this one is also a bit scattered, but there are enough fun bits and the books is quick enough to read so hat you give it a try.
As most of Lopp's books this one is also a bit scattered, but there are enough fun bits and the books is quick enough to read so hat you give it a try.
August 11, 2010
Excellent handbook for engineers. Not all of the material will be relevant at any one time but if you keep the book around to refer back to it'll pay dividends.
January 3, 2011
Or Nerds: Why They Are All Special Snowflakes.
August 10, 2014
Don't bother with this one. Offensive language throughout with nothing novel to offer.
July 31, 2015
"Being Geek" is an extremely honest book about author's thoughts on technology career. It starts with who we are, to what we do, to how we do it, and end with "what's next" (trust your gut and charge forward).
Several takeaways I have from the book:
1. Prepare for the unexpected: things can do wrong will do wrong. What distinguishes a competent engineer is his ability to face the unexpected.
2. Be efficient. If we are more efficient, then we have more time to enjoy what we love to do. Therefore, tooling matters, listening to people matters.
3. Do something we love. Let what we do be part of who we are. If my mind is not passively chewing on something I'm doing, it's a sign that I'm not interested in what I do.
4. I'm responsible for my career. My manager is responsible for my job, but I'm the only person who is responsible for my career.
======
Great quotes
It is a defining characteristic of the nerd or geek to seek definition.
At our core, I believe geeks are system thinkers. A simpler way to think about this is that in the mind of a geek, the world is like a computer — discernible, knowable, and finite. After years of successfully using the computer as a means of interacting with the world, we’ve come to follow a certain credo:
We seek definition to understand the system so that we can discern the rules so that we know what to do next so that we win.
Definition, system, and rules. It all goes back to our ever-favorite tool, the computer. Our success with the computer has tweaked out perspective of the planet. We believe that given enough time and effort, you can totally understand the system.
People screw things up. They are the sources of bugs. They ask odd questions, and their logic is flawed. In the pleasant mental flowchart we have in our geek heads, it’s a single person who causes us to frustratingly ask, “Who are these people and why the hell don’t they follow the rules? Can’t they see the system? DON’T THEY WANT TO WIN?” Yes, they do.
The advice and this book begin with a contradiction: prepare for the unpredictable. The unpredictable shows up on your doorstep in two forms: simple unpredictability, which you can assess and act on immediately, and world-changing unpredictability that rocks your world and requires serious work on your part.
It’s professionally fashionable to bitch about your company and your inept manager, but when you start bitching about your career, I call bullshit. The idea that anyone besides you is responsible for your career is flawed. Your boss is only your boss while he’s your boss. Your career is yours forever.
With time and experience, you’ll learn there is a finite set of personalities walking the halls. Yes, they have their individual nuances, but these personalities and their motivations can be understood.
Your boss and his motivation will vary from company to company, but it’s a knowable set of motivations varying somewhere from “hiding until I retire” to “driving everyone absolutely crazy as I attempt to conquer the world.” You can make most meetings useful. You can dig yourself out from underneath the endless list of things to do. It’s OK to quit a job with people you like because there are a lot of people to like out there.
It’s easy to forget with micromanagers and visionaries cluttering your day with their agenda, but as the owner of the code, it’s your job to care — daily. Whether it’s during the joy of writing the code, the annoying days of bug fixing, or the seemingly endless maintenance tasks, it’s your call where the code is going to go next. Are we spending too much time on maintenance? Is it time to throw it away and start over? Sure, it’s not necessarily your decision to make, but it’s absolutely your responsibility to raise the issue, to have an opinion, and to affect the plan. This code is crap. We need to start over.
Growth represents the strategy by which you are learning, doing more, getting promoted, getting the shit kicked out of you, and garnering more responsibility. There’s a simple rule designed to grab your attention: “If you’re not growing, you’re dying.”
Let’s see if you’re dying. Ask yourself the following: Have you failed recently? Is there someone within throwing distance who challenges you daily? Can you tell me the story of something significant you learned in the last week? Any answer of “No” is a troubling sign. You’re coasting. Sure, it’s comfortable, but while you’re sitting there in your mediocrity, your industry is aggressively attempting to make you irrelevant. It’s not personal; it’s a function of all of those other bright people who aren’t scared of failure, who have surrounded themselves with catalytic personalities, and who thrive on understanding.
Perhaps a healthier way to think of it is that your manager is responsible for your job, but you’re the manager of your career. The primary goal of both jobs is to identify and act on opportunity inside of the company that is going to challenge you, force you to learn, and push you to the edge of discomfort.
A reputation is a community-based opinion that you don’t control. It takes years of work to develop and a single missed key responsibility to destroy.
To me, the fundamental unit of growth is knowledge. Knowledge isn’t facts, and knowledge isn’t data. It’s your consumption of facts, data, situations, and personalities, and the consumption yields a discovery. It’s when you mentally build something new. This knowledge may not be novel, but what makes it unique is that you built it for yourself.
I’m a fervent supporter of maintaining a work-life balance that allows you to explore as much of the planet Earth as possible, but I’m also the guy who thinks if you’re going to do this job, you should be absolutely fucking crazy about it. This doesn’t mean that you’re obsessively working 24 hours a day on the product, but it does mean that the work you are doing is part of you.
If my mind isn’t always passively chewing on the things I need to build, again, it’s a sign that I might not care about what I am doing.
Manage your time — it’s an invaluable commodity — obsess about the tools you use, and take the time to understand the people around you. Figure how to speak their language so you can learn how to convey your bright ideas to anyone.
What I’m telling you is that management is the art of choosing what not to do, which means you need to be ready and willing to look at the task at the end of a day and ask, “OK, I made this urgent this morning. A day has passed and I had time, but never got to it. Does it matter?”
Priority is relative. What felt so important last Wednesday loses importance five days later when the larger context of your week, your month, and your career shows up. You need to develop a practice of strategic information shedding where you are constantly and intelligently jettisoning ideas and work. A well-maintained to-do list gives you a daily sense of professional well-being. It constructs the pleasant illusion that you have a degree of control in a world where you have no idea how tomorrow will taste.
When I’m standing in the middle of a Crisis, I’m doing two things at the same time. First, I’m frantically trying to fix the issue by any means possible. I’m also carefully looking to identify the root cause of the Crisis.
Whether you’re formally trained as a computer science nerd or not, you’ve learned the value of efficiency — to make each action that you take mean something. You know that when you’re efficient, you have more time to do what you love.
Before I explain how to get your head around this meeting, I want to talk about intent behind this meeting. Intent starts with a question: “Why does this meeting exist?” If you’re responsible for the presentation in this particular meeting, it exists because someone hates you. It’s not personal hate. It’s professional hate, and it’s exacerbated by a simple fact of organization: different groups speak different languages. Marketing speaks marketing, Legal speaks legal, and Engineering speaks engineering. There’s a fundamental communication breakdown somewhere in the building, and someone is feeling wronged. They’re feeling bullied and since they don’t speak your dialect, they’re complaining up rather than across.
Everyone Hates Engineering Outside of engineering, no one really likes engineering. Here’s why: No one knows what we actually do to build the software, so they assume it’s easy In everyone else’s head, it’s really simply just to add that checkbox to that page and “just branch the code or something... use an If/ Then statement or something.” Cute. And totally annoying. What’s being asked for there is the world’s worst specification, but the real problem is that the person asking assumes they’re describing all of the work involved. They believe that their understanding is somewhat related to the work involved in developing a product. Worse, this misunderstanding goes both ways....
The curse of the Silicon Valley is: we’re often placing our most valuable talent into a job they are utterly unequipped to handle and probably don’t want.
What you need to pay attention to when Alpha Knowledge leaves is the team’s ability to handle the unexpected. It’s not the day-to-day operations of the team that will be impacted by the absence of Alpha. It’s when shit hits the fan that you’re really going to miss
Leaders optimize reality to their favor, and the more powerful and influential they are, the more they can define a comfortable reality for themselves and their team.
Trusting your gut and charging forward. It can be addictive.
Several takeaways I have from the book:
1. Prepare for the unexpected: things can do wrong will do wrong. What distinguishes a competent engineer is his ability to face the unexpected.
2. Be efficient. If we are more efficient, then we have more time to enjoy what we love to do. Therefore, tooling matters, listening to people matters.
3. Do something we love. Let what we do be part of who we are. If my mind is not passively chewing on something I'm doing, it's a sign that I'm not interested in what I do.
4. I'm responsible for my career. My manager is responsible for my job, but I'm the only person who is responsible for my career.
======
Great quotes
It is a defining characteristic of the nerd or geek to seek definition.
At our core, I believe geeks are system thinkers. A simpler way to think about this is that in the mind of a geek, the world is like a computer — discernible, knowable, and finite. After years of successfully using the computer as a means of interacting with the world, we’ve come to follow a certain credo:
We seek definition to understand the system so that we can discern the rules so that we know what to do next so that we win.
Definition, system, and rules. It all goes back to our ever-favorite tool, the computer. Our success with the computer has tweaked out perspective of the planet. We believe that given enough time and effort, you can totally understand the system.
People screw things up. They are the sources of bugs. They ask odd questions, and their logic is flawed. In the pleasant mental flowchart we have in our geek heads, it’s a single person who causes us to frustratingly ask, “Who are these people and why the hell don’t they follow the rules? Can’t they see the system? DON’T THEY WANT TO WIN?” Yes, they do.
The advice and this book begin with a contradiction: prepare for the unpredictable. The unpredictable shows up on your doorstep in two forms: simple unpredictability, which you can assess and act on immediately, and world-changing unpredictability that rocks your world and requires serious work on your part.
It’s professionally fashionable to bitch about your company and your inept manager, but when you start bitching about your career, I call bullshit. The idea that anyone besides you is responsible for your career is flawed. Your boss is only your boss while he’s your boss. Your career is yours forever.
With time and experience, you’ll learn there is a finite set of personalities walking the halls. Yes, they have their individual nuances, but these personalities and their motivations can be understood.
Your boss and his motivation will vary from company to company, but it’s a knowable set of motivations varying somewhere from “hiding until I retire” to “driving everyone absolutely crazy as I attempt to conquer the world.” You can make most meetings useful. You can dig yourself out from underneath the endless list of things to do. It’s OK to quit a job with people you like because there are a lot of people to like out there.
It’s easy to forget with micromanagers and visionaries cluttering your day with their agenda, but as the owner of the code, it’s your job to care — daily. Whether it’s during the joy of writing the code, the annoying days of bug fixing, or the seemingly endless maintenance tasks, it’s your call where the code is going to go next. Are we spending too much time on maintenance? Is it time to throw it away and start over? Sure, it’s not necessarily your decision to make, but it’s absolutely your responsibility to raise the issue, to have an opinion, and to affect the plan. This code is crap. We need to start over.
Growth represents the strategy by which you are learning, doing more, getting promoted, getting the shit kicked out of you, and garnering more responsibility. There’s a simple rule designed to grab your attention: “If you’re not growing, you’re dying.”
Let’s see if you’re dying. Ask yourself the following: Have you failed recently? Is there someone within throwing distance who challenges you daily? Can you tell me the story of something significant you learned in the last week? Any answer of “No” is a troubling sign. You’re coasting. Sure, it’s comfortable, but while you’re sitting there in your mediocrity, your industry is aggressively attempting to make you irrelevant. It’s not personal; it’s a function of all of those other bright people who aren’t scared of failure, who have surrounded themselves with catalytic personalities, and who thrive on understanding.
Perhaps a healthier way to think of it is that your manager is responsible for your job, but you’re the manager of your career. The primary goal of both jobs is to identify and act on opportunity inside of the company that is going to challenge you, force you to learn, and push you to the edge of discomfort.
A reputation is a community-based opinion that you don’t control. It takes years of work to develop and a single missed key responsibility to destroy.
To me, the fundamental unit of growth is knowledge. Knowledge isn’t facts, and knowledge isn’t data. It’s your consumption of facts, data, situations, and personalities, and the consumption yields a discovery. It’s when you mentally build something new. This knowledge may not be novel, but what makes it unique is that you built it for yourself.
I’m a fervent supporter of maintaining a work-life balance that allows you to explore as much of the planet Earth as possible, but I’m also the guy who thinks if you’re going to do this job, you should be absolutely fucking crazy about it. This doesn’t mean that you’re obsessively working 24 hours a day on the product, but it does mean that the work you are doing is part of you.
If my mind isn’t always passively chewing on the things I need to build, again, it’s a sign that I might not care about what I am doing.
Manage your time — it’s an invaluable commodity — obsess about the tools you use, and take the time to understand the people around you. Figure how to speak their language so you can learn how to convey your bright ideas to anyone.
What I’m telling you is that management is the art of choosing what not to do, which means you need to be ready and willing to look at the task at the end of a day and ask, “OK, I made this urgent this morning. A day has passed and I had time, but never got to it. Does it matter?”
Priority is relative. What felt so important last Wednesday loses importance five days later when the larger context of your week, your month, and your career shows up. You need to develop a practice of strategic information shedding where you are constantly and intelligently jettisoning ideas and work. A well-maintained to-do list gives you a daily sense of professional well-being. It constructs the pleasant illusion that you have a degree of control in a world where you have no idea how tomorrow will taste.
When I’m standing in the middle of a Crisis, I’m doing two things at the same time. First, I’m frantically trying to fix the issue by any means possible. I’m also carefully looking to identify the root cause of the Crisis.
Whether you’re formally trained as a computer science nerd or not, you’ve learned the value of efficiency — to make each action that you take mean something. You know that when you’re efficient, you have more time to do what you love.
Before I explain how to get your head around this meeting, I want to talk about intent behind this meeting. Intent starts with a question: “Why does this meeting exist?” If you’re responsible for the presentation in this particular meeting, it exists because someone hates you. It’s not personal hate. It’s professional hate, and it’s exacerbated by a simple fact of organization: different groups speak different languages. Marketing speaks marketing, Legal speaks legal, and Engineering speaks engineering. There’s a fundamental communication breakdown somewhere in the building, and someone is feeling wronged. They’re feeling bullied and since they don’t speak your dialect, they’re complaining up rather than across.
Everyone Hates Engineering Outside of engineering, no one really likes engineering. Here’s why: No one knows what we actually do to build the software, so they assume it’s easy In everyone else’s head, it’s really simply just to add that checkbox to that page and “just branch the code or something... use an If/ Then statement or something.” Cute. And totally annoying. What’s being asked for there is the world’s worst specification, but the real problem is that the person asking assumes they’re describing all of the work involved. They believe that their understanding is somewhat related to the work involved in developing a product. Worse, this misunderstanding goes both ways....
The curse of the Silicon Valley is: we’re often placing our most valuable talent into a job they are utterly unequipped to handle and probably don’t want.
What you need to pay attention to when Alpha Knowledge leaves is the team’s ability to handle the unexpected. It’s not the day-to-day operations of the team that will be impacted by the absence of Alpha. It’s when shit hits the fan that you’re really going to miss
Leaders optimize reality to their favor, and the more powerful and influential they are, the more they can define a comfortable reality for themselves and their team.
Trusting your gut and charging forward. It can be addictive.
December 25, 2018
Read this book in a bit of a rush as I was trying to meet a promise I made to myself to read 12 books in 2018, and I was running late. But I think that's fine - of all the books you could read in a rush this is a pretty good choice. It's a series of blog posts that have been edited together with some bridging content here and there.
I say that like it's a bad thing, but it's actually not. The author sets out his tests for if you need to make a career move in the second chapter. Firstly, are you growing? That is, have you failed recently? Is there someone sitting near you who challenges you daily? And, can you tell me the story of something significant you learned in the last week?
Secondly, are you actively setting the technical direction of your product? Thirdly, are you meeting your commitments? (These latter two I find need a lot less explanation)
Future chapters deal with strategies for finding the right new job, getting promoted, and navigating management. As a structure, that's something I can work with; I got enough (the foregoing summary) out of this first read for the book to have been worth reading, and I know where to go back to in future.
That said, the content is showing its age a little bit. I haven't checked but I suspect that neither agile nor devops were much of a factor when the book was written, and they've both had wide reaching impacts on how software projects work, and how software companies run. Furthermore, much of the advice is specific to American, or rather Silicon Valley, business culture and practice. This limits its general applicability.
'Management' as a way of doing things isn't in danger of disappearing though. You can still level up your savvy (and probably your salary) by reading this book.
I say that like it's a bad thing, but it's actually not. The author sets out his tests for if you need to make a career move in the second chapter. Firstly, are you growing? That is, have you failed recently? Is there someone sitting near you who challenges you daily? And, can you tell me the story of something significant you learned in the last week?
Secondly, are you actively setting the technical direction of your product? Thirdly, are you meeting your commitments? (These latter two I find need a lot less explanation)
Future chapters deal with strategies for finding the right new job, getting promoted, and navigating management. As a structure, that's something I can work with; I got enough (the foregoing summary) out of this first read for the book to have been worth reading, and I know where to go back to in future.
That said, the content is showing its age a little bit. I haven't checked but I suspect that neither agile nor devops were much of a factor when the book was written, and they've both had wide reaching impacts on how software projects work, and how software companies run. Furthermore, much of the advice is specific to American, or rather Silicon Valley, business culture and practice. This limits its general applicability.
'Management' as a way of doing things isn't in danger of disappearing though. You can still level up your savvy (and probably your salary) by reading this book.
November 20, 2022
I was a bit disappointed with this book. I like the Rands blog so I thought I would read this and enjoy it but it was a bit slow to finish for me and I read a good bit. I know a lot of nerds that have other passions other than technology and felt like it put nerds in the light of only really enjoying tech related topics unless it was made a game (like exercise). Most nerds I have encountered chase the high in tech and through other means as well. It also seemed to lean heavily towards male nerds even with the initial introduction saying it was about both genders. Overall some decent ideas on a few things but I disagree with a good bit of the overall idea that this is a true nerd handbook. Just my two cents but some might disagree and enjoy it more.
This entire review has been hidden because of spoilers.
January 8, 2017
Is it a collection of blog articles: yes. Are the chapter titles too cute to find what topic it's on: of course. But is a apt description and frank discussion about what I do and what managers do: absolutely.
Having worked in the industry for a decade, moving from service desk to DBA to manager, from small SMB to global enterprise: this is a good read.
A speed read with some colorful language at times, but still worth reading. And then Googling for the original blogs and forwarding them to peers or reading amusing snippets to my spouse.
Having worked in the industry for a decade, moving from service desk to DBA to manager, from small SMB to global enterprise: this is a good read.
A speed read with some colorful language at times, but still worth reading. And then Googling for the original blogs and forwarding them to peers or reading amusing snippets to my spouse.
May 9, 2022
The author wrote sentences with missing words or incorrect or confusing wording. He dismissed videoconferencing, not knowing superior videoconferencing software has been created such as Zoom. I was disappointed that there wasn't more advice on software itself, most of the advice was about navigating interviews and corporate life. That said, the advice is useful especially the ones dealing with a company's collapse and transitioning to a manager. His point about the geek's instinct for systems thinking and metagaming is quite accurate. His call to always be learning and growing is paramount.
November 15, 2023
I found out about this book from a random image on pinterest, I was curious enough to search about it that it ended being on my to-read list. When I picked this book, I felt like the author was really speaking to me in my language and finished it a couple of quick reading sessions. The author talks about several aspects of a developer's career that I personally have been through and the concise and enjoyable tone in which everything is documented is excellent, I highly recommend this book to all geeks/devs.
April 21, 2024
The book is a patchwork. I guess, similarly to the author's other books. Lots of incoherent stories and anecdotes. Many of those stories are hardly relatable for me as a professional engineer, sometimes I struggled to understand what kind of situation I was reading about. Some of them are entertaining, some give me a feeling this might be useful, but there are no accessible summaries or conclusions that I could take with me. There's no greater story arc. So now I finished the book and nothing has stuck with me at all.
February 26, 2019
A free-flowing, animated, and spirited book that many will either love or hate. I think there is some great content here (I recognize it as a classic) but I find the tone and crassness off putting and grating at times. It also could have used a good deal of editing. Like many books assembled largely from blog posts, it suffers from a very choppy feel. That said, with some fortitude,there are some good insights to be gained from plowing through this hay ride.
February 15, 2019
I wanted to read something about software books and grab this one. The book has many interesting and practical views about software developer's "daily life". It is very interesting and funny specially if you can relate to the events that he writes.
Great read. Best for fresh grads and new to software devs.
Great read. Best for fresh grads and new to software devs.
December 27, 2019
Great book which can be recommended for the experienced people. I mean that it would mostly help to the software engineers with 2-3 years of experience. The book can guide on the ways of the developing in terms of career.
July 10, 2017
Lots of interesting thoughts, but not very well composed and written.
November 17, 2018
Very casual write-up of how to drive a software engineer career into management. I didn't appreciate or like all the chapters, save for the last few management ones
January 27, 2019
It's more like a handbook for Software Developers who has walked into the land of the "Management". I found it an easy read, motivating in some parts and irrelevant in most others.
Read
September 21, 2019I really enjoyed seeing him speak in person last year, but this was a bit of a disappointment.
Displaying 1 - 30 of 117 reviews