I’ve been recently talking to former colleagues about work. We discuss code and perceived quality in code. We tend to discuss the merits of good code and what it really looks like. Each time I come back to the same place in my mind. Good code is mainly about collective code ownership & having a shared understanding of what you are doing. So how does one go about helping manifest this?
I think software development is a 80/20 game… Depending on which you play it governs the impact on this collective code ownership and what some may deem as code quality.
If you work in the following manner 80% code and 20% communication – your code bases will all have a mish mash of styles, poor tests, good tests and really anything in between. Certain code will be well understood by certain people, and other bits will be understood a lot less by other people. Some people will open code bases and swoon at it’s clarity for them but others will open it up and want to instantly refactor it!
I’m more than convinced that working the other way 20% code and 80% communication gets a better shared code understanding. Now I don’t mean that you all sit around in meetings and discuss what good code looks likes. I suggest that you pair about 80% of your time, this is the communication piece that is lacking the other way around. This conversation drives a shared understanding through your code bases. It also helps ideas flow from mind to mind, while producing code to a certain degree.
Communication doesn’t just start or end with pairing, it starts by having the team be a team. This is something to focus on above and beyond everything else initially. Once you have this everything else will flow… More on this in another post.
You hire someone, you’ve been through the interview process which can take up to 2 hours, you’ve invested time and money in getting that person to come and join your company. Then they join and you’ve not got the induction nailed. I’ve had this happen a few times to myself. Get to the company – no computer or a borrowed computer – sat alone on a bank of desks with none of my to be team members. Walking out for lunch by yourself to find the shops that supply food, which you can’t find because the office is in a location you’ve not been to before. As an individual you’ve perceived this place to work as crap or not. I have positive work experiences after this has happened but it’s taken time for this initial perception to be reversed.
Yet the solution to this is pretty simple – in my eyes anyhow. It just needs a bit of planning ahead, not much but just an idea of how you are going to get people bedded in to your team. Here is a rough guide for an induction that works:
- Get all the equipment they are going to be using ordered (fortunately when I was hiring, this was handled by my HR colleague) – it’s got to arrive before and be ready for them to use on the day they get there. Keep pestering until you are happy it’s going to on there desk when it arrives.
- Get a desk within the team area – ideally in the middle of where the team sits – if there is no room, make room – move yourselve if necessary.
- On the day of arrival get there before they do – i.e. if they are going to get there for 8:30 – you’ve got to be in for 8:15.
- Once you’ve been notified they are here – go get them straight away – they are your priority for the day.
- Buy them a coffee – have an informal chat about the weekend and travel in. I usually talk about working hours at this point – as people want to know this.
- We had a company induction the morning they would arrive – if possible get this out of the way as soon as possible.
- Get them to be dropped off in your team area after the induction.
- Go out for lunch as a team (you should be doing this every day so adding another person should be easy!).
- Once back from lunch – let them setup there kit which will be nicely boxed on there desk. Let them install whatever they need to get there job done (hopefully the PC is already imaged with key software). If there are problems then take them the people who can sort them out (i.e. infrastructure/desktop support people) free introduction done ;).
- Give them access to what they need to do there job (i.e. Git, TeamCity, Octopus).
So that’s day 1. The next couple of days are pretty free form but generally I followed something as follows:
- Get them working on production code within the first 2 days of joining – I promote pairing so this was easy for them to drop in with a pair.
- Get them to release to production within the first week of being at the company – if you can’t release this often then start working towards it.
- Walk them through the architecture of the solution they are working on.
- Walk them through the full architecture of the eco-system they are working with.
- Get them to setup a build pipeline within the first month of being at the company.
- Setup your 121’s with them.
- Show them around the department – hopefully this should only take a couple of informal introductions – nothing to over the top required.
That’s about it from memory – I know it looks like a lot. But once you’ve done it once it’s a breeze. I’ve found that your other team members will end up helping with this as well! It really does matter making that first impression – people want to feel wanted and valued!
“in the first few milliseconds of our perceiving something we not only unconsciously comprehend what it is, but decide whether we like it or not.”