Teamwork (November 13, 2016)
The concept of teamwork I briefly mention in the previous post warrants a post in itself. I’m absolutely not an authority on building and running teams, but just like anyone else in the programming profession I’ve got some of intuition about it.
First of all, it seems like good teams are rare: most companies are dysfunctional in some way or the other that sometimes make Dilbert cartoons look like the bastion of good reason. Dan Luu wrote a long entry on that recently:
Over years, advances in software engineering — which is most commonly defined as a set of practices allowing software development on an industrial scale — made it possible to at least partially work around human imperfections by established a software development process. Practices like writing unit tests, doing code reviews, adhering to coding standards and choosing low risk technologies made it possible to develop software of enormous size. Like any process, when being enforced unreasonably those practices have a chance of scaring away your best employees and potential candidates.
That’s simply because those things are not pleasant. Nobody likes writing unit tests, or renaming variables just because your reviewer has an idea of a better name. A job that advertises itself as being in a team that practices TDD to the book is most likely the one that you’d want to run away from.
However, encountering a good team that works together organically is possible. My intuition for recognizing a team like this is that it shouldn’t require you to be dumber than you are. You want to write smart code? Sure, go ahead, you shouldn’t have any reasons to think that your colleagues won’t be able to understand it.
|Entries (RSS) | © 2007–2017 Sergey Mikhanov|