Team Geek

I recently read this book: Team Geek. It’s like postmodern poetry: it’s both too much and too little.

Expectations

The book starts with a fantastic chapter: the “The Myth of the Genius Programmer”. In this chapter the authors explain that we, as developers, tend to overestimate the impact of an individual programmer. They say that nobody cannot expect it from himself to be such a genius as we imagine Linus Torvalds to be. E.g. he didn’t write the whole Linux all by himself. Instead, he provided a prototype, then organized a community around it. None of them was a simple achievement, however, he didn’t write the Linux all by himself. So, they conclude, one can do much if he works well with others.

The basics

The next chapter, “Building an Awesome Team Culture” explains what a team culture is and why such thing is important. E.g. you need to have good people and some basic rules. The rest will basically follow, however, one must continuously take care of the team culture.

They also state their most important principles: Humility, Responsibility and Trust. They even define an acronym for it: ‘HRT’, that we pronounce like ‘heart’ because that’s where the good things come from.

If only. But, more about it later.

Then, through the book they cover all sort of topics that are important in teams. What if you are the lead developer? What if your boss is a bad manager? What are the most common management patterns and antipatterns? How to deal with poisonous behaviour? Etc.

All of those cases fall back to the ‘HRT’: Humility, Responsibility and Trust. Sometimes they mention that it should be OK to fail. Also, they say, admit your mistakes. Be nice, no matter what. You need to do the right thing. Sometimes doing the right thing gets you fired. Sometimes the right thing is to quit your job.

Idealism

The principles above are all true. I just find them too idealistic.

OK, this sort of books are, by nature, always a bit idealistic. As an example, consider assertive communication. Some people tend to suppress their opinions, while others tend to dominate others. A book, however, cannot tell what’s the case of the current reader. They usually just declare a set of rules, and, we have a lack of reality.

The problem is that it’s too easy to give idealistic advice. Here is one from me: figure out what other people want. Then, if you can do it while preserving your personal integrity, give it to them. This will make other people eager to help you.

Realism

So, back to the book. All it lacks is a little realism. It has a page or two on working for a bad manager. But that’s it.

This book is great on Chekhov’s terms it’s a great book because it rather asks questions than answers them. These are my questions:

– How do I know if I’m humble and respectful? How do I behave that? OK, it’s not a real question, but it’s something that I keep working on a day-by-day basis.

– Should I keep being humble if admitting any mistakes puts my boss into micromanaging mode?

– What should I do if in certain cases it’s not OK to make mistakes? This can happen in startups that have strong competition so they apply ASAP Driven Development. This can happen in huge corporations too that adapted fear-driven-development.

– This book suggests that leaders rather ask questions than give answers. Which is great, but, how can we deal with leaders who suggest things by asking questions like: “Why didn’t you use that other tool instead?” – so, how do can I deal with that?

Some of the book reviews say that his book tells us the Google way of doing it. Based on this book, Google must be an amazing place to work at. Nevertheless, it’s still a company that has its own perils. Also, while I like values this book enumerates, other people might like other things. Some of us are comfortable with command-and-control. These guidelines wouldn’t help them too much, I think. They should instead join the army find a place that fits better their personality.

Wrapping up

This book is a great survivors guide for programmers. The authors cover lots of important topics and aspects of teamwork. All the reader needs to do is to temper it with some realism. We need to check these rules if/how they are applicable on our workplace. Also, we need to check how it fits with our personality.

This sort of self-improvement is slow. It takes a lot of consciousness. Also, it requires tons of feedback. All of this falls back on improving our EQ. So, how do we do that?

All I could say here how I did it. But, that’s just me. If you think you have problems with dealing with people, then a therapist is usually a good place to start. What comes after that, it depends on you.

Advertisements

About tamasrev

A software developer, specialized in Java, addressing himself as generalist. A proud daddy.
This entry was posted in programming and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s