Code Reviews

In my thoughts about codecraft post, I mentioned that we’d discussed Code Reviews during the lean coffee session:

The question was “How much should we nitpick in Code Reviews”, and I can easily see Code Reviews being a great guided conversation on its own, especially with the side discussions on what code reviews are for, who should do them, and when they should be done, which reflect conversations I’ve been having at work.

It’s a topic that’s stuck with me, so I wanted to add a few more questions, to see what you think, and some thoughts about code reviews from my experience.

What are they for?

The common refrain around code reviews is that they ensure consistency and quality of the code, and should be seniors or peers checking the code against a checklist (possibly implied), following a process to ensure that the mistakes that came before aren’t made again. I can hear the agile proponents in the audience screaming at that.

Alternatively, the code review is a structured communication about the problem, and the solution, and the architecture, where the developer feeds back their understanding of the requirement and their implementation of it to another member of the team to validate their understanding, and through that conversation, with another pair of eyes, the developer and their pair can uncover any potential issues that need to be addressed. At the XP end of this scale, this code review is a continuous progress and a natural side effect of paired programming, and in such a view, any review that requires less time than the original development is a poor substitute for a full conversation.

Code reviews can also be used to gate check-ins – to ensure that all code has been viewed by at least 2 (or sometimes 3) pairs of eyes before it is allowed into a branch on the release path.

How much detail should they go into?

If a code review is a conversation, the answer is easy : as much detail as the developer went into, if not more. In the checklist view, the level of detail depends completely on the checklist. Hopefully, the checklist itself is enlightened enough to transfer some of the checking to automated tools, to enforce coding standards, test coverage, and other things, and the code review is the recognition that those automated tools are never enough, and an attempt to plug those gaps.

How long should they take?

As long as they need. It should never be a burden or a blocker to the rest of the team. If code reviews are a bottleneck, there’s something wrong, but equally, a code review that only takes a couple of minutes is a paper exercise, on anything but the simplest change.

Should the developer be present?

The situation is obviously complicated by geographically distributed teams, but let’s assume for this argument, there’s a decent video conference set up for the conversation. The developer has the opportunity to introduce the requirement and the implementation, and the reviewer can ask questions to clarify decisions. Ideally, these would be open questions, that elicit deeper responses from the developer, and may often be generic questions, such as “How does this work?” or “Why did you do choose to to it that way?” that could, if required, be put on flash cards to help new reviewers.

Tools like Github (and gitlab) are set up to allow asynchronous communication over a code review, which lessens the need to a developer to be present, but may depersonalize the experience to some extent, which may provide a more complete check, because the review is of the code rather than the developer, at the expense of potentially alienating developers who don’t agree with the changes. If the developers can’t work together, they can’t review.

If reviews frequently lead to rework, direct conversations are definitely more important to resolve ambiguities and ensure the developer being reviewed understands the reasons and consequences.

Should they be done at the end or the start of the feature?

This was a way of working that I discovered from Gitlab, where many pull requests are created at the same time as the feature branch, allowing conversations between developers as the code is developed, rather than using code reviews to gate check-ins prior to merging. This allows architectural and other design decisions, and the requirements, to be discussed in situ, with the code as it is being developed, which should inoculate the branch from the worst effects of drift that may occur once the Continuous Integration ideal of everyone integrating onto the same branch multiple times a day is compromised to allow feature branching.

Rail Ticket UX

You may have noticed that Rail Tickets in the UK look a lot different, and it annoyed be, because I don’t trust that the change will make things easier for me, and I’ve yet to find the study to prove otherwise.

When I challenged it on Twitter, there was a split between the lovers and the haters of the new design, and also a brilliant example of how not to sell the design by the Scotrailgb parody account, in a tweet that has since been deleted, using language I have heard others use to justify their way.

This is industry wide and was tested on two month old babies who had no problem, sure you’re not just simple?

Use language wisely. You don’t sell change by insulting your users, customers, developers, colleagues or managers.

https://twitter.com/craignicol/status/631847304358690816?s=09

https://twitter.com/jay_tyler/status/631767276887404544?s=09

https://twitter.com/craignicol/status/631756264759013376

What do you think about the new design, and the alternatives?

Work-life balance : No interruptions, only peace

My favourite discussion from the Technical Lead discussion was defining a successful technical lead, to which one of the first answers was that no-one will need you. If you are good at what you do, you can optimise yourself out of a job, or at least free yourself up to go on holiday once in a while, without anyone needing to interrupt you. Get better at getting away. This is something close to my heart, having had 3 breaks in a row interrupted due to having to make decisions for a team late on various Saturdays.

If you want the same, first you need to get in the proper holiday mindset – where you do not get any work email on your phone. If work really want you to read email on your phone, they’ll pay for it.

Once you have the mindset though, there’s a number of things you need to do to make it happen, so you can avoid webmail and phonecalls and properly relax. Thinking about your break is also a good way to build a resilient team, and a resilient project. Here’s a few things that have worked for me.

Don’t build software, build teams.

Start with the team. You won’t always have a choice of the team, but if you want to defer your job to the team, at least temporarily, you will need people in the team that you can trust, and that the rest of the team will respect, so that they can keep a steady hand. And make sure you debrief them before you go.

Don’t speak, write.

Talking is great for working through problems and sharing knowledge. But people will forget. So write it down, and then talk it through. That way there’s something to refer to in 6 months time, when they, and you, have forgotten what you did and you need to work it out again from first principles.

Automation trumps documentation.

But if you can write it in code, do. People get bored reading documentation, skipping the sections they think they know. Computers don’t know how. And run the automation regularly, so you know it’s up to date. Deploy often from scripts, not documents. Every document runs the risk of papercuts.

Delegate everything, to everyone.

In other words, don’t be the only person on the team who knows how to do something, and don’t let anyone else on the team be that person either.

Own the code, but don’t be the code.

If you practice ego-less programming anyway, this should be easy, but ego-less programming takes a lot of deliberate practice. Be proud of the code you write, but not so proud that you can’t leave it alone for a week or two. If you have build the right team, you know the code will be in as good a condition without you as it would if you were there, bar a nudge or two you can easily resolve when you get back.

Relax.

Walk off. Don’t look back. If you keep checking in, you’ll send the message that you don’t trust your team, and you run the risk of micromanaging, which means your team will lose some autonomy and be less effective, which then creates a vicious cycle that you will need to get more involved. If you run the project as if you’re not needed, except in an emergency, it will run more smoothly, and you will be able to relax.

Plan.

From day 1, plan for knowledge transfer, plan for delegation, and plan for everyone’s holidays, and family emergencies, and paternity leave, and for the loss of team members to other projects and companies, plan for a team that will change over time, in the short term and the long term. It’s not a matter of treating people as replaceable parts (see the last point, and trusting your team), but it is a matter of responding to change, and building flexibility in from day 1. I don’t always get it right, but the more successful I am, the better the team works, and the more I can relax.

Trust your team.

Trust them, and let them trust you. And please, please, please, don’t phone them whilst they’re away. Lead by example.

Thoughts about @codecraftuk conference

I really enjoyed the CodeCraftConf last Friday. Well done to the organisers for a great set of discussions. A very different style of conference, and a refreshing change from the lecture-based conferences. A lot of good discussions, and I just wanted to throw some thoughts down whilst it’s still fresh in my head.

technical lead discussion

Technical lead discussion summary available here.

agile

The questions in this session were based around the Agile Manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

There was a lot of folk agreeing with the things on the left, but it was hard to find people who saw much value in the things on the right until directly challenged on it, which I found an interesting dynamic. There was also a lot of talk about feedback and communication and how that works. Plenty of interesting thoughts.

lean coffee

Prior to lunch, I joined the lean coffee session, where a number of topics were proposed.

There were a few topics covering mobile development, javascript frameworks and some other good topics, but the one that sticks out most for me was about Code Reviews.

The question was “How much should we nitpick in Code Reviews”, and I can easily see Code Reviews being a great guided conversation on its own, especially with the side discussions on what code reviews are for, who should do them, and when they should be done, which reflect conversations I’ve been having at work.

I think it’s a great format, and I look forward to trying it at our next lunchtime session in the office.

security

This session particularly interested me as I used this topic as a dry run in the office before I guided my session on the day, and regular readers will notice that security is an interest of mine. The key questions here were around application security, but a lot of the discussion covered testing and social engineering, and why we still trust some companies that have been hacked, but not others.

BDD

I had trouble deciding which session to attend at the end of the day, but as I was late in, the decision was made for me, as there were no seats left at the other talk. So there was a slight musical chairs element to proceedings.

The session itself was particularly interesting to me as I’ve been exposed to some of the ideas and technologies related to Behaviour Driven Development, but I haven’t had a chance to discuss using it for actual projects, and following the discussion, I understand that it requires a particular relationship between the developers and product owners to work. Definitely something to explore further.

There was another interesting discussion in this session, that had been bubbling through most of the sessions in the day – the idea of “Cargo Cult process”, where the memes and practices of techniques such as TDD, Agile and BDD have been parachuted in to a project, or organisation, without understanding the purpose of the techniques or the problems they are trying to solve. As discussed in the Agile session, the successful processes are those that start with a problem, a pain point, and find ways to address that, and put a feedback loop in to ensure the problem is addressed, and then move on to the next pain point.

If customer engagement isn’t your problem, the BDD Three Amigos session might not give you much value. If your product owner trusts your developers, or can read CI results, you may not need Cucumber to write your tests.

Venue

I was a little but unsure about a conference in a pub, but there was a great space, and some of the best conference food I’ve had. The room itself could get a little noisy when the conversations got heated, as there were 2 converations going on at once, but the organisers were working to address that on the day and at future

I’m looking forward to the next one.

Technical Leadership at @codecraftuk follow up

I had a great time at the CodeCraftConf, and I’ll be writing up my thoughts on the other sessions shortly, but for the benefit of those who attended the technical leadership session and those who were interested in the questions, I made a few notes on each question to reflect suggestions, and discussion points that we covered, as well as a couple of additional questions that came up during the conversation. Feel free to use them as inspiration for running your own session around these questions.

Before that however, I just wanted to give a few thoughts on guiding a session, for anyone interested in running one themselves.

Preparation

The best questions are open, and not technology specific. I also found that phrasing similar questions in different ways can help to draw out additional detail. I had the questions reviewed by a couple of trusted friends in advance, to make sure they covered enough ground and were good starting points for discussion.

Guiding

I chose the first question as an ice breaker, as it was something I felt anyone interested in the topic could give a short answer too. Don’t be precious about the order of questions. Know what’s coming up so you can pull questions forward when the conversation naturally flows into it.

Try and pick up the subtle cues for people who want to speak, and use your authority as guide to try and spot them. This may often mean liking away from who’s currently speaking.

---

What is a technical lead?

Role model
Learning
Build your relationships
Technical Architecture
Decision maker
How to build software better
Facilitate not dictate
Coach / mentor
Coding standards
Person I go to when I have a problem
Encourage communication and collaboration
Challenge and grow the team
Arbitration and negotiation
Scrapper – fighting external stakeholders in behalf of the team.

What are the most important behaviours for technical leads to exhibit?

Calm under pressure
Promoting knowledge
Approachable
Don’t have to know everything. Knowledge is an inverse hierarchy, it collects at the bottom.
Balance
Drawing out quieter team members
Delegation
Open minded

What most inspired you about your previous technical leads?

Clarity on code knowledge
Removal of fear
Encourage learning from mistakes – mistakes happen, so learn from them when they do.
Protect from blame – collective ownership, no scapegoats
Guiding rather than fixing – not grabbing control of the keyboard
Tailoring messages to the audience
Simplifying solutions.

Why do you want to be a technical lead?

“I didn’t want to be a technical lead ”
Help people
Recognition
Drift into it
Job description makes it uncomfortable / or gives you ammunition when scrapping
Earned authority

What scares you most about being a technical lead?

Responsibility – easy to make big mistakes
Not keeping up with technology
Friction with the outside and non-technical stakeholders
Being reactive vs proactive
Meetings
Deskilling

How do you measure success as a technical lead?

If nobody needs you
Happy management – no meetings
Happy team

What one thing would make your life as a technical lead easier?

Open minded developers
Customers who know what they want and what the requirements are
Unified working practices and strong management
Ban the word “just”
100% utilisation is bad
More time to just think
The right work environment
Flexibility and respect
The right tools

How much coding should a technical lead do?

A lot!!
Structured time boxes
Lead on one project, developer on the next
1/3rd – 2/3rds coding was the accepted range in the session, but some unhappy leads were doing less
“feature lead”

What responsibilities are you happy to delegate, and what do you want to control?

Delegate everything. But know it will be OK.
Control to make sure the delegated work is complete and the team feel supported.
Map delegations to the team
Delegate by negation – military strategy :
– “I will do this”, give leader option to refuse, then carry on
– This style can take a while to get used to
Constant communication
Don’t micromanage

How do you plan for your own absence, so you can rest on holiday?

Good team mix – senior vs junior
Choosing your staff
Building the right relationships internally and externally
Documentation
Automation

What qualities do you want your team to have, and how to you help them get that?

Ran out of time to cover this question, skipped to a combination of the following two.

How do you deal with conflicts in the team?
How do you deal with external pressures on the team?

Life experience
Soft skills
Project Manager should be the political front to the outside world
Have to work in partnership with the PM
Compassionate, put yourself in their shoes
Smaller teams are easier

Additional questions :

What happens to the project when the technical lead changes?

Do you need a tech lead? Are techniques like voting to resolve conflicts enough?

Technical Leadership conversation at @codecraftuk

I have scheduled this post for just after my session at CodeCraftConf completes, as a place to continue the discussion. Thank you for all of you who attended.

Following my last post about the Technical Lead session at CodeCraftConf, I’ve reworked the questions, and repeated them below.

1. What is a technical lead?
2. What are the most important behaviours for technical leads to exhibit?
3. What most inspired you about your previous technical leads?
4. Why do you want to be a technical lead?
5. What scares you most about being a technical lead?
6. How do you measure success as a technical lead?
7. What one thing would make your life as a technical lead easier?
8. How much coding should a technical lead do?
9. What responsibilities are you happy to delegate, and what do you want to control?
10. How do you plan for your own absence, so you can rest on holiday?
11. What qualities do you want your team to have, and how to you help them get that?
12. How do you deal with conflicts in the team?
13. How do you deal with external pressures on the team?

You can also find the questions at the CodeCraftConf Technical Lead session on Github if you would like to run the session yourself.

My thoughts, which may change during the session are:

A technical lead provides the direction, vision, enthusiasm, and occasionally the kick up the bum for the team, and helps to clear obstacles. They should lead by example and should care deeply about the wellbeing of the team, and the success of the project, which cannot succeed without a successful team. They should keep their technical knowledge, and domain knowledge up to date, as they are asked to make a lot of decisions, and whilst they should defer and demonstrate confidence in their team, they cannot get respect without the being able to make the decisions and ask tough questions to make sure the decisions made by the team are correct. I’ll cover the rest in a future post.

Source: CodeCraftConf by @codecraftuk

Personal Identity in a digital world

In the light of more data breaches, especially highly personal data of the form held by a certain affair website, I wanted to revisit the 4th Rule of network security. If you don’t trust encryption, you store as little as possible which implies YAGNI for data storage. There’s a few other benefits you get as well, in simplifying your storage. In this post I want to focus on the simplest and most obvious personal identifier, your name. And I’ll assume you’ve all read Falsehoods Developers Believe About Names, so if you haven’t yet, read it now.

What’s in a name, or a person?

At its basic level, a name is a poor identifier. Going by Google and some misplaced emails, I know of at least 3 other people in Scotland, 1 in Australia and 2 in USA who share my name. So my name is not sufficient to uniquely identify me, which is why I have a number of tracking references for the NHS, National Insurance (for Americans, think Social Security Number), my employer and others, and why it’s hard to get my name on social networks or email providers unless I get in early.

Do you need to know anyone at all? Is a tracking id enough?

Given that your name is not sufficient to uniquely identify you (and therefore is also harder to verify), is it even necessary? For many sites, and apps, not even a login is necessary or desirable to users, so advertisers, content providers and others often just use a tracking cookie or similar to identify you again the next time they see you.

If they need a login is a username and password enough?

OK, but your software needs to verify users and store data about them. You’ve got a good authorisation and authentication story to allow users access to their own stuff and no one else’s, without permission.

Do you still need their name? If you are a music site tracking my favourite videos, why do you care who I am? And if you’re built on a shoestring budget, why would you want the hassle of securing password when you can grab an OAuth library and not have to worry about it at all. Some of them will give you a name, some won’t. What purpose does storing a name, real or otherwise, serve?

Do you actually need to split names into first and last?

OK, so you actually need someone’s name, how are you going to store it? A name, a first and last name, middle names? If you are splitting a name and then littering your code (or at least your CPU time, if you’re resharing code) with contractions to display those names, then you may be doing it wrong. And who’s to say that all your users have a first and a last name? (see common misconceptions about names)

What about titles?

So you need a name, and you are sure you can split it. What else do you need? Do you need a title? Does it matter if your drop-down asks for Mr or Mrs or Miss? And by the way, what about Ms and Dr, and Prof, and can you handle Mx now, or do you discriminate? And by the way, how easy is it for the user to change those fields, as required by law?

What other details are you doing that you don’t need? Addresses? Country? Phone number? Email address? Credit Card number? Mother’s maiden name? Name of first pet?

Why does free train WiFi need my gender and age?

Or any website? And Why are those fields mandatory?

As a user, what is my motivation for giving you those details? The more information I give you, the more I have to trust you. And if I don’t trust you, you don’t get my data. If I know why you need it, there’s more chance of you getting my data. If I don’t know why you need it, I will assume you’re selling it, and I may think that even if I know why you need it.

Don’t ask me to trust you, and you won’t be disappointed.

What are you storing because you can, rather than because you need to?

Is your data a security risk, a performance risk, a trust risk? Or can you justify everything, and point to the requirement that details that justification?

If you lost your data to hackers, what would your users be most concerned about being disclosed? Can you stop storing that data?

Using a Pebble Smartwatch

6 months ago, I got a Pebble Watch. Not the Pebble Watch Time, or Pebble Steel.

My first, and overriding, impression was a reminder of my childhood, when I got a Game Boy, and my friend got a Lynx. He laughed because his was colour, and looked cooler. I laughed when he ran out of battery and couldn’t find any games for it. And for many years, Nintendo had the best selling console. That’s how I feel with the Pebble vs the other smart watches. Pebble has the battery life, and a simplicity of purpose, whilst the competition have touch screens, a lot more sensors and capability, but a battery life that means you always know where your charger is.

What is the Pebble like to use

Bluetooth pairing is annoying. It took at least 10 attempts to get the watch to pair with my phone. The watch could see the phone and the phone could see the watch, but it was very fiddly to verify the pin in the short window it was visible. I had this experience with 2 separate phones so I’m blaming the watch.

I needed to get a new strap because my wrist reacted badly to the one it shipped with.

Replies to sms and hangouts are very slick. Access to Android notification quick actions and dismiss is very useful.

Responding to phone calls is a little less slick. On both phones there’s a very noticeable delay between the call starting to ring and the watch displaying the caller id and reject option. All other notifications show up at the same time, or occasionally before, they sure up on the phone.

I had to restrict the apps that notified to my watch because the vibrations were going crazy. That’s helped me out using my phone anyway, it was a good excuse for a spring clean.

I like the night time mode – no notifications whilst you sleep, so I can use the watch to track my sleep and as an alarm. I use Misfit for sleep tracking and it works well. It also tracks my steps, but so does Google Fit on my phone.

My wife isn’t convinced by the claim that it’s not meant to wake her up when the alarm vibrates on my wrist.

It’s very good at what it does, showing my notifications, and letting me reply where the Android notification allows. It’s also easy to develop for.

In the spirit of Troy Hunt

Troy Hunt : The Apple Watch is simultaneously awesome and pointless.

Compared to the Apple Watch, some apps require an Android or iOS partner if they need functionality the Pebble app doesn’t provide, but in general, only settings and notifications direct you to your phone. If you can’t do it on the pebble, there’s no point in having the app. A few apps do require network access via the phone, but it should be obvious when and where they need it.

It’s been rock-solid. I’ve had one watch app crash occasionally, but the watch itself has not crashed.

There’s no microphone on the original models, and the short messages and glanceability are the key use case. Unlike the Apple Watch, thankfully there’s no TTP or pointless photos.

Step out of the shadow cast down by your ego

Don’t define yourself by your job. You are a fascinating unique intersection of many identities, including your job and your vocation, but even when these align, you are much more.

You have friends and family. You have friends outside work but in your vocation who are a great sounding board. Use them to explore the market. Not necessarily to find a new job but to be sure your current one is giving you what you need.

Don’t define yourself by your code. Be passionate about it, be proud of it, but don’t give yourself to it. It will consume you in every imperfection found in review, in every late night and weekend you spend fixing one last bug, in every sleepless night worrying about the things the users don’t care about.

If you don’t have balance, it can destroy you.

Be comfortable in yourself and your code and work will follow. If you don’t know who you are, find out, accept your flaws and limitations and choose which you will improve and which you will defer to others.