Scan barcode
eb00kie's review
funny
informative
lighthearted
relaxing
medium-paced
4.0
Management in a nutshell for all geeks everywhere. Really.
Do you feel like management/leadership are buzzwords associated with someone stealing time for The Art of [insert what makes you happy, here] with endless meetings?
Do you get a cramp in the glutes when someone speaks about “team culture”?
Here’s a compact version of management know-how for science types everywhere. It’s just a different type of programming language. Really. Ignore the C++ chapter and geeks can finally understand what this is all about.
All geeks - everywhere:
Geeks in accounting
Geeks in investing
Geeks in business
Geeks in consulting
Geeks in banking
And, of course
Geeks in software
Do you feel like management/leadership are buzzwords associated with someone stealing time for The Art of [insert what makes you happy, here] with endless meetings?
Do you get a cramp in the glutes when someone speaks about “team culture”?
Here’s a compact version of management know-how for science types everywhere. It’s just a different type of programming language. Really. Ignore the C++ chapter and geeks can finally understand what this is all about.
All geeks - everywhere:
Geeks in accounting
Geeks in investing
Geeks in business
Geeks in consulting
Geeks in banking
And, of course
Geeks in software
kwugirl's review
4.0
Excellent read on basically all the soft skills related to working with and as a software engineer. It's pretty clearly written and actually not that long, it only took me this long because I got into one of my "eh non-fiction" phases. Also they did a good job keeping their use of gendered pronouns balanced.
corrompido's review
3.0
A quick read about the non-technical skills that a programmer should cultivate for success in software departments. It was well written, and even though nothing is completely revelatory in here it does a good job of laying out the basics. I especially enjoyed the beginning parts of the book that dealt with what kind of culture you should aim to have in development groups, what can threaten culture, and how to push better culture.
stephms's review
4.0
Humility, respect and trust (HRT). The authors ask us to think about a recent problem (of the human variety) and pose the question of whether the people involved are all acting with HRT. Chances are, they say, one of those is lacking.
No great revelations here, but the book does a nice job of framing the age-old problem of team dynamics specifically for technical/software dev settings. I like the emphasis on how to define (and defend) a productive team culture. Easier said than done, but always worth striving for.
No great revelations here, but the book does a nice job of framing the age-old problem of team dynamics specifically for technical/software dev settings. I like the emphasis on how to define (and defend) a productive team culture. Easier said than done, but always worth striving for.
rayan_ral's review
3.0
The book is ok, though pretty basic, advices can be summed up as "don't be an asshole".
Book concentrates on "strategy", that is quite obvious, without saying almost anything about tactics, which is actually hard part - and very nuanced, so you can't really give an advice for every possible situation.
On the positive side - it's easy to read, and can be read in a day or two, so you won't get bored.
Book concentrates on "strategy", that is quite obvious, without saying almost anything about tactics, which is actually hard part - and very nuanced, so you can't really give an advice for every possible situation.
On the positive side - it's easy to read, and can be read in a day or two, so you won't get bored.
tlockney's review
4.0
Debating whether to give copies to every one I work with. Lots of nuggets here.
evanbernstein's review
3.0
This would be a good first book on management for developers. After managing for the last 4 years or so, I didn't find the book particularly interesting or new; I often found it a little too proud of itself. I read this part of a manager book club at work; I enjoyed the conversation that came out of having read the book more than the book itself.
The ideas that did resonate with me from the book that were either things I had distinctly thought of, or that were a good reminder:
- ask my reports "what can I do for you me?"
- ask my reports "what do you need from me?"
- my main job is to clear obstacles from my reports so they can get work done faster. This means not knowing answers is ok, but knowing who does know the answer is vital.
The ideas that did resonate with me from the book that were either things I had distinctly thought of, or that were a good reminder:
- ask my reports "what can I do for you me?"
- ask my reports "what do you need from me?"
- my main job is to clear obstacles from my reports so they can get work done faster. This means not knowing answers is ok, but knowing who does know the answer is vital.
scottshepard's review
3.0
“Software is easy. People are hard."
We like to think of our jobs as very logical and straightforward. Define the problem, find the right tool, fix the problem. But in reality almost all software is built by teams. Besides git and latex, all popular tools and every corporation is created by many hands touching different pieces of the machinery. Even if every person on the team has the best intentions, everything can fail if the proper steps to building and maintaining the team structure are not taken.
What I like about this book is it is written for the average team member. It’s not about how to start or manage a software team. It’s not about how to hire for one, it is about how to exist in one. The real message is how to work with any team as any of the excellent advice given here (excluding the rare software specific advice and anecdotes) can apply to any team. There are some great lessons in this book, some cliche but many not. It was refreshing to not only get the standard advice such as, “Respect each other”, but sound practical day-to-day experience as to what that means. I learned that to these authors (who worked at Google and helped develop subversion) it means that you assume the best in people, and address problem behaviors instead of problem people. I found much of the advice sounds and not condensing. I have already taken some of it to heart.
We like to think of our jobs as very logical and straightforward. Define the problem, find the right tool, fix the problem. But in reality almost all software is built by teams. Besides git and latex, all popular tools and every corporation is created by many hands touching different pieces of the machinery. Even if every person on the team has the best intentions, everything can fail if the proper steps to building and maintaining the team structure are not taken.
What I like about this book is it is written for the average team member. It’s not about how to start or manage a software team. It’s not about how to hire for one, it is about how to exist in one. The real message is how to work with any team as any of the excellent advice given here (excluding the rare software specific advice and anecdotes) can apply to any team. There are some great lessons in this book, some cliche but many not. It was refreshing to not only get the standard advice such as, “Respect each other”, but sound practical day-to-day experience as to what that means. I learned that to these authors (who worked at Google and helped develop subversion) it means that you assume the best in people, and address problem behaviors instead of problem people. I found much of the advice sounds and not condensing. I have already taken some of it to heart.
xaviershay's review
3.0
Very light introduction. Picks up a star for being easy to read, you won't find anything new in here though.
More...