Today I wanted to highly recommend you the book: Team Geek: A Software Developer’s Guide to Working Well with Others (and its newest version: Debugging Teams: Better Productivity through Collaboration) written by Brian Fitzpatrick and Ben Collins-Sussman.

I hardly ever buy tech-oriented books but I did buy this one. In fact, I’ve bought it twice since I had to leave the first copy in Nantes when moving to Barcelona. First, because it’s a book that it never gets old (technology quickly evolves but humans stopped evolving a long time ago, easy to notice when some decide to open their mouth!) and secondly because IMHO it applies not only to software teams but to all kinds of groups of people that need to collaborate. Therefore, in my case it’s twice as useful: to help me manage my research team (even if the book includes some valid criticisms to how researchers work) and to help me manage the software development projects we work on.

So what is this book about? The best summary is to repeat its mission statement:

The goal of this book is to help programmers become more effective and efficient at creating software by improving their ability to understand, communicate with, and collaborate with other people

We all know (or should know) that engineering is easy but people are hard and as they say, dealing with people is not something you learn at the school. In fact, quite the opposite, since what we all remember about group assignments is that you should trust no one!. But like it or not, professional coders always work in teams and one’s team directly affects that individual’s property and happiness more than more people would like to admit.

The book sets up to fix this. Based on the three pillars of collaboration: humility, trust and respect, the book covers:

  • How to build a team culture (if you don’t do it, somebody else will take over and do it for you, imposing his culture!). This includes a clear mission statement, good communication patterns and guidelines for efficient meetings
  • How to be a good captain for your team (because every team needs one!) avoiding typical mistakes like micronamanagement, hiring pushovers, ignoring low performers and good leadership patterns (e.g. not go leaping into solution mode since many times an engineer asking for advice typically doesn’t want you to solve the problem but rather to hlep him solve it, knowing the right people is more valuable than knowing the right answer, avoiding the use of the compliment sandwich or how to increase motivation).
  • How to deal with poisonous people (you know who I’m talking about!). On this I liked a lot this qutoe by Greg Hudson: he often walks the fine line between genius and lunatic. The problem is that genius is such a commodity these days that it’s not acceptable to be an eccentric any more
  • How to interact with your organization including finding the right friends (hint: be nice with secretaries!), navigate bad managers, stopping bad habits (hint: you can’t stop them, you have to replace them with good ones),…
  • Users are people too. You don’t write for yourself. Sucess will depend on getting many other people to use your software as well. And to do so, you have to care about their emotional perception of your softwarwe so pay attention to first impressions, be nice with them when they have questions, put some time in marketing it and make sure your product is as usable as possible (yes I know, this is basically your dream to-do list, right? 🙂 )

I’ll stop here but you can go ahead and learn this and many other things by buying one of the books below. I dare to say this is going to be the best investment ever you can do for your career!.


Want to build better software faster?

Want to build better software faster?

Get the latest news in software modeling, model-based and low-code development

Thanks for your interest. Check your inbox and confirm your subscription!

Pin It on Pinterest

Share This