Code review and mentoring

• You have inherited a Django or Wagtail codebase and need to know what you actually own before committing a budget to it.
• Your team is strong but new to Django, and the early architectural decisions are the ones that will be expensive to revisit.
• A developer is working alone and nobody reviews their work — which is a retention problem as much as a quality one.
• You are about to rewrite something and want a second opinion on whether that is the cheapest way to get what you want. It often is not.
• You have a technical decision to defend to a board, a funder or a procurement process, and need the reasoning written down by someone with no stake in which way it goes.

Three shapes, and most engagements are a mix:

• A codebase review. I read the project and write up what I find: the architecture, the risks, the things that will hurt at ten times the traffic or ten times the content, and what I would do first. Written down and prioritised, so it survives the meeting.
• Ongoing pull request review. I review your team's work on a regular cadence. The value compounds — the second month of reviews is cheaper than the first because the patterns get learned.
• Pairing on the hard parts. Working through a specific problem together, which is how the reasoning transfers rather than just the answer.

Reviews say why, not just what. "Move this to a manager method" is a correction; the same note with the reason attached is the thing that stops the pattern recurring.

A codebase review report is normally ten to twenty pages and covers the same ground every time: how the project is structured and whether that structure is holding; the state of the tests and what they actually prove; dependency and Django version risk; the database schema and the queries that will not survive growth; security and the handling of personal data; how it is deployed and what happens when that fails. Findings are ordered by what they cost you, not by how interesting they are — with the handful worth doing this month separated from the list worth knowing about.

Reading other people's Django is a substantial part of what I do. HFBK Hamburg came over from a media agency, Museum Wilhelm Busch from a small agency in Hanover, and Safety.io came with an existing codebase and no test suite. In each case the first job was working out what was there, what was load-bearing and what could safely be left alone.

Before freelancing I was CTO of a media agency for nearly three years, responsible for the development team, quality assurance and client training — and a senior backend developer before that, pair programming and reviewing the work of junior developers. This is not a sideline I invented for a services page.

• A written, prioritised account of the state of your codebase — not a list of lint warnings.
• Developers who can make the next decision without asking, which is the entire point.
• A clear answer on rewrite versus refactor, with the reasoning you need to defend it internally.

Get in touch and say what your team is working on and where it keeps getting stuck. If you want a codebase review specifically, say roughly how large the project is and how long it has been running.