Tag: teams

I do a lot of code reviewing, both in my day job as principal developer and also as an open source maintainer. Sometimes it seems like I read more code than I write! Is that a problem? I'm tempted to say that it isn't. To be a good writer, you must be well-read; I believe that to be a good developer, you need to be code-omnivorous and read as much of other people's code as possible. Code reviews are like little chapters of someone else's code to dip into.

Over time I've developed some particular processes that I find helpful when reviewing code. In particular, I often surprise people at how much review I do before I run the code. Sometimes I grab the branch so that I can use my local diff tools, but I don't actually execute code until I've established some basic facts. This post is a little insight into what's happening in this not-running-the-code-yet zone.

When I spoke at PHPNW10 in October, I talked about teams, skills and the importance of benchmarking things in order to illustrate improvements. If you didn't see the talk, the video and slides are linked off the conference site. In particular I talked about the importance of analysing skills in a team, then improving them, then analysing again to see how things had changed. This post is about that process, some techniques that might apply, and what to do with the results when you get them.

I mentioned the 360 Degree Feedback Technique during my keynote at PHPNW10 and had many comments and questions about it since, so I thought I'd post about it in more detail

Last weekend I gave a talk at PHPNW10 in Manchester, entitled "Teach a Man to Fish". This is a keynote about teams and how to use the resources around you to create a team where individuals and the whole team continues to learn and develop. The slides are not very …