Code crit?

As a front-end developer, I’ve often been invited to take part in design critiques, more commonly referred to by designers as simply crit.

These collaborative sessions, when run well, are highly enjoyable. My go-to guide on running successful design critiques is this one by Scott Berkun.

In short, the best design crit sessions:

• involve between 3-7 people
• are run by a well-prepared facilitator (usually the person who did most of the design work)
• focus on specific questions about user goals
• tend to occur early in the design process
• produce concrete actions and outcomes
• involve non-designers where relevant

By comparison, code reviews:

• tend to be done when the work is ‘dev complete’
• may only involve one reviewer - possibly a senior gatekeeper
• are done asynchronously (e.g. using a GitHub pull request)
• are more of an overall review
• only involve other developers

There is most definitely a place for code review at the point at which the work is considered functionally complete. But I’m strongly of the opinion that there should be no big surprises about the design of the code to anyone else at this point, especially for larger or more complex chunks of work.

As well as reviewing all code once complete, why not hold regular ‘code crit’ sessions earlier on in the process? These can work in exactly the way described by Scott Berkun. They are best held at the point where one or more developers have done some initial research and investigation into how some functionality may be best developed, e.g. by investigating a library or exploring the pros and cons of certain architecture patterns or implementation approaches.

You can call them what you like. In one team I’ve worked with they were ‘design reviews’; in another, a weekly ‘Architecture Round Table’. But the goals are the same: to increase team coherence, eliminate silo’d knowledge and reduce the waste caused by heading in the wrong direction.

Introducing sessions like these can be a great way to foster collaboration in a team that’s struggling to work together. I’ve also found them to be a gateway drug to more formal collaborative techniques like mobbing and pairing.

Just remember that they need to be well-facilitated and produce meaningful outcomes and actions.

Does your team hold early code design reviews? What form do they take?

All the best,

– Jim