Pair with people you like and code reviews with people you don't like

Pair with people you like and code reviews with people you don't like (misquoted from someone way smarter than me).

That sums it up very well for how I feel about both practices.

With large teams, especially if distributed or partially outsourced, code reviews can ensure code quality and are quite essential. It will allow you to share some knowledge and instill best practices. It will be a reminder for people that their code will be viewed by others so don’t take shortcuts.

However code review can also be a total bottleneck if over-bureaucratic. It will add an overhead for all work. If there are some high and mighty gate keepers that will stop you from pushing your code frequently then you have a complete velocity block. If your code is shit then fair enough, but if it is merely nit picking or just disagreements between styles then it is very costly. If however if any compulsory reviewer is not in your office, country, time zone or just very busy then that adds a large delay in the feedback loop.

Another issue with code reviews is that quite a few reviews are of low quality due to lack of context. They do not necessarily know all the discussions, history of why a piece of code works this way, project code style, etc. Especially if they are of the tainted ivory tower architect affliction.


In smaller, agile and especially collocated teams code reviews will flag issue unnecessarily late in the process. Just pair from the start instead to ensure no short cuts or dodgy code slips through, and automatically spread the knowledge. If you do not trust two of your developers combined then you do have a serious problem.

You can though in addition have small and short swarming/tripling/quadrupling sessions in front of 1 computer to look at especially important issues when they are worked on, not afterwards.

If you do neither code reviews nor pairing then you are in trouble.

Expanded from my own Hacker News comment https://news.ycombinator.com/item?id=6693064

Don't hire me

There are many reasons not to hire me

I will say no, a lot. I am pragmatic and may find a better solution by asking what it is you actually want to achieve. Or just No

I will say its crap if it is, immediately

I will have an opinion, always. Even when based on very little facts. Sorry

I will change my opinion 180 degrees quickly if a good team convinces me I am totally wrong. This happens a lot, thankfully

If obedience is important to you don't hire me

I am in no way politically correct (not an excuse to be an asshole either) and I make terrible jokes and often “too soon”

I do not have a filter for whom to sugar coat a situation to. I will say the same whether you are a team member, manager, CEO, client or shop keeper. And always blunt and honest

I will be honest with estimates. As in they are total guesswork and only worth it to gage magnitude

If you prefer polite sales type people that tell white lies or total tales then I am not your man

I don’t clock in, I’m definitely not a morning person. If you value timeliness above value then I am not your man

I don’t clock out on the dot either but I rarely work overtime and never weekends. Too risky, if the TPS reports can't wait, don't hire me

I like collaborating, pairing, even tripling for important decisions that needs swarming

I like the team taking ownership together, I detest micro managed task delegation

If you need bums on seat and each task accountable to a person then don’t hire me

I will not jump up like a lap dog when people panic, I barely got a pulse at the best of times. If you prefer knee jerk reactions don't hire me

If you want me to be an ivory tower architect, don't. I like to work with the team to find out their best suggestion is and then work with them to implement it

Or if you have another architect of an ivory tower inclination telling me how to implement something - not going to happen

If you want to keep status quo don’t hire me, I will insist on continual evolutionary improvements. Otherwise the systems will rot, become a big ball of risk and your best developers will leave

However if you want a ninja/rockstar, I am not

If you want me to work with a ninja/rockstar I rather not. Some are okay, but most are a PITA and imperceptibly costly for the company

Insist on Windows? Don’t be ridiculous. No serious developer would accept that handicap unless desperate

Shirt & tie? No, not happening. You can’t take techies dressed as used car salesmen seriously

If you prefer drones in suites, that is not me

Many of these are valid reasons not to hire me

Some I hope are reasons to hire me

Your call

@flurdy | linkedin.com/in/flurdy | www.eray.co.uk