Weeknotes 07×05: The end of 38

Actual Theme

Bit of a strange, scattered week this week. I don’t think I’m going to be able to stick to my usual structure of expected-thoughts vs actual-thoughts, so I’m going to launch in and just note down what I need to get off my chest. Was lovely to be so linked to by Katie Attwood this week though (the joy of publishing late) – I think a bit of a refreshed look at week notes this series has really paid off.

Clouds

Monday

Memory clouds, like the sea mist that rolled into town as I got off the train. G-cloud. Excel. WordPress. Unremarkably productive.

Tuesday

Planned power outage in the whole office building. Worked from home, which meant finally getting a semi-decent mysql gui client on linux. Bugfixing. Document writing.

Wednesday

Spent the morning fixing a couple of bugs – the power outage had a few knock-on effects which we hadn’t encountered before, so we had to scramble to get things fixed before a webinar later in the day. Then I had to go back to the same bug as the day before, which had reared its ugly head again. Technobabble here, but need to line up some time to fix it properly. One of the more frustrating duties of Head of Tech is that design flaws can come from any one person in the team, but if it goes wrong, it’s up to the lead to sort out time and skills to fix it. Or maybe that’s just me?

Also put in a small stake against casual feminism. I’m not sure it helped, but I’ve been trying to see things from a different viewpoint following on from a couple of discussions recently, and maybe I’m starting to see the issues a bit more clearly? Dunno, still feels like a whole conversation to be had in private. Not sure why. To easy to feel like you’re shouting about it, going “LOOK AT ME, I’M SUCH A FEMINIST MAN.”

film noir

Thursday

Thursday was long and intense, not helped by being groggy when I awoke, having one ear blocked, the office air seeming to hang with its own tension, and witnessing a minor road incident. Our “internal analysis” session looked at 4 more S’s from McKinsey: Structure, Style (of management, etc), Staff and Skills. Given there was a lot of history we hadn’t ever really discussed before, it brought a lot of things to the surface, which is good I think, but draining. At one point I think I was having an argument, but I was zoning out to the point where I couldn’t tell you what it was about. That’s not great.

Personally though, it reinforced my view that getting good feedback at the moment is really hard for me – I don’t feel I have the opportunity, openness or, perhaps, trust, to ask anyone what I could/should change, or what impact I’m having. I’m very much in my own filter bubble, which is something I wasn’t expecting to affect me so much, and it was actually encouraging to hear that others would like to both give and receive honest feedback.

I’m further resolved to just be open about it, and ask specific people for feedback next month. If people aren’t going to offer to do me a 1-1, I’m going to have to do it myself. Ho hum. There’s also a lot of legacy around, which I need to clear up on. June could be emotional.

Friday

Me birthday. Going to have brekkie in a nice cafe, then go for a walk to the coast and back over the hills.

walking

Culchure

Reading

  • Taoism by John Blofeld – how have I not picked this up from my pile of books before?
  • What is Feminism? by Bea Appleby and Louise Spilsbury – A slim book intended for older children and teenagers, but I wanted something fairly simple and impartial as an introduction to some of the ongoing discussions and wider ‘theory’/discourse about the subject, which it was.

Seeing

  • Saw The Shape of Light exhibition at the Tate Modern yesterday – without kids. Recommended for fans of abstract monochrome photography through the ages – I very much enjoyed it, plus great to traipse round the South Bank for a whole day.

Pondwatch

  • Not much this week – no duck fights. I went to help out on Tuesday evening, but everyone finished just as I got there.
  • The bluebells are gone now too. I didn’t manage to see them properly this year.

Nobody Likes Code Reviews

Judgemental Pigeon Disapproves

Typical tech team conversation:

“The work is nearly done, just a few tidies but it basically works.”

“Has it been properly tested?”

“Not yet, but the basics work.”

“And any changes that come out of a code review, I assume.”

“True, but hopefully not many.”

“So still a fair bit to do then.”

“Yeah, a bit more.”

We’ve been running code reviews for a few years in a fairly tiny team with a mix of experience. For context, we don’t generally have strong specialisms, and do a fair bit of picking-it-up-as-we-go. Over the time, I’ve noticed two fundamentals:

  1. Nobody likes code reviews
  2. The right attitude to code reviews goes a long way, both for individuals and for the business

Part One: Nobody likes code reviews

You’ve just spent days using nothing except your brain and fingers to craft a solution (elegant or otherwise) to the latest user need – brilliant! The problem to hand is solved, everyone will love you, blah blah blah. Onwards and upwards.

Except – Code Review.

(If you’re not familiar with the term, then a Code Review is basically a chance to run what you’ve done past someone else. This. Is intended to catch bugs, raise questions about the work, point out improvements (including style, documentation, formatting, etc), and learn from each other. The actual benefit will depend on who’s reviewing who – it can be beneficial for a junior member of staff to review a senior member’s work, and vice versa, but the dynamic will obviously change.)

The word itself is horrible; “review” sounds so judgmental. Like your work is going to be scored out of 10 by some gravy-train critic with an axe to grind. The code works, doesn’t it? Why does it need anything further? This isn’t school any more.

There are two main reasons to be “afraid” of having your code reviewed:

  1. Explaining things to others is hard and boring.

  2. Being “wrong” is difficult.

This gets at a fundamental “double-think” that helps in code reviews – and, indeed, in life. On the one hand, how can we be proud of our work so that we can take interest and responsibility for it, while simultaneously being humble enough to accept critique?

Part Two: The right attitude goes a long way

In order to not hate code reviews – and to become stronger as a result of doing them – we must therefore develop a key set of skills as a programmer being reviewed:

  • Respect for the person reviewing, whether they’re more senior, junior, or an equal peer – without this, we cannot be open to suggestions from them. (And vice versa, it is essential to respect the person whose work is being reviewed. This mutual respect is the key part of the “contract” underlying reviewing each other’s work.)

  • Patience to explain something (often to someone who may otherwise have no idea about context)

  • Clear communicationstorytelling about what you’ve done (and not done), and (more importantly) why you’ve done or not done it

  • An inquisitiveness that opens us up to collaboration, to help explore feedback and suggestions arising from review.

By focusing on these as key skills to develop, a team can learn more quickly from each other. Individuals can improve their own skills faster, as well as learn more about working with other people generally – an essential, yet subtle side-effect of code reviews is learning how other people think. By being open to alternative thought processes, we can expand our own, and bring wider experience to problems in the future.

As Tech Lead (or a senior developer), what can I do to encourage these properties in the team?

The main, most essential thing is to simply lead by example. It’s good to become part of the process by reviewing code (as may be expected, depending on the team size) and adhering to the values above. But also it’s important to write code and be reviewed – this demonstrates what you believe to be good practice. Plus everybody has something to learn off others – often a junior member of staff reviewing your code will ask you basic questions that get you to think about your basic assumptions.

Secondly, and this is something I’d like to bring in more, it’s valuable to be very clear about the aims and values of the code review process up front. Inform new staff about why code review is important, and remind people every now and then.

It’s very powerful to be able to say that a team can learn from itself rather than rely on books and courses, or that a developer’s job entails learning and teaching, above and beyond simply pushing out lines of code and UML diagrams. Learning and teaching is something a good team does all the time, as a matter of course.

I haven’t touched on more detail here, such as what the main attributes look like, or what to look out for to see if a team really are developing as a unit – maybe I’ll follow up with these in a later blog post, if there’s interest.

Weeknotes 07×04: In and out the dusty Jigglypuffs

Welcome, reader. Here are some weeknotes…

Before the week…

What am I looking forward to this week?

Thinking through the next steps of the tech team Roadmap. Keep on running, and all that. And there’s good potential to line up some really satisfying work for the team over the summer.

What am I not looking forward to this week?

Balancing a bunch of work stuff with chicken pox childcare.

What am I not sure about?

Planning for upcoming busy with people being away, or out and about. Takes a lot of effort to keep the dots joined.

Expected theme

Lots and lots of tiny steps.

After the week…

Actual theme

A strange sense of getting things done without being there much.

What surprised me?

Getting excited about doing public speaking – see Friday.

Space for links.

But more prosaically I am missing two things from my diary:
– time to do some proper thinking and get into ‘flow’ so I can do more than just respond to things (and avoid getting into the habit of doing this as the weekend)
– Some unscripted time where I be available to my team for follow up actions and checkins on projects

  • Why Small Teams Win: “When everyone knows and understands exactly how their contribution adds to the final product, everyone on the team ends up creating better work.

Monday

Bonk Halliday.

Tuesday

Half day. Early in for an early finish, only to find some hastily arranged meetings and other people on sick cover. This is fine, but in combination with my own hours being thrown around, meant I spent some time rejigging my thoughts and plans for the next few days.

Re-prioritised the important stuff I could help with. Warned the team about stuff that was likely to get pushed. Succinct summaries in Slack as a reference point for later.

Chatted to our partners on GDPR. Trying to bring everything together in a smooth, organised fashion, but I suspect that’s not going to happen, now that we’ve discussed everyone’s diaries.

CALENDAR BATTLE – MAY 25TH, I CHOOSE YOU

Discussed product pricing with Kim and Stefan. Felt for the first time that I kind of got this stuff – how market development is all about a balance between revenue and sustained business, but also how it can dovetail with opportunity. We’re looking like we need to discount a little to pull in certain clients, but the cleverer approach ties this in with market opportunity 3 or 4 years ahead, the potential for expanding the team in the short term, and opening up new projet ideas.

They might not work out, but it all makes sense in my head. (Obviously this lack of angst and puzzlement makes for rubbish weeknotes. Sorry.)

Finished by fixing a web thing which I’d got stuck on. Again, crap weeknoting. (Lesson being learned: uh, look in the obvious config files? #mindblowing but #smalltruths)

(Better lesson learned: Legacy code is complex and I don’t think our current approach to exploring it is particularly geared up for easy access or collaborative exploration.)

Wednesday

Had to cover #son2 as his reign of pox came to an end. Did some gardening and went to the playground.

BECAUSE I LIKE THIS GIF

Thursday

Long sprint planning meeting in the morning. There’s a lot of stuff coming up, with a self-imposed deadline at the end of the month, so useful to talk it all through. But still feels like it’s hard to get a basic overview of priorities, and that we’re still spending a lot of time deciding whether other work should come in or not.

Maybe that comes down to a mix of three things?

  • 1. Focuses are discussed, but not strongly adhered to – can we be clearer on priorities in the days before the planning meeting?
  • 2. The world is changeable – c’est la vie, but can we be clearer about whether a change necessitates an interruption to expected focuses?
  • 3. Skill sets – what personal attributes do people need in order to make a decision quickly – Familiarity with the work? An interest in progress rather than complete correctness? Sharp rationalising?

Strikes me that playing games with time limits on might be a good exercise for decision-makers in group environments – I’m thinking stuff like speed chess, or any fairly fast, but complex game.

In general, I wonder if there’s a link between playing games and effective decision making?

YOUR TURN, JIGGLYPUFF… TO MAKE AN INFORMED RESOURCE-DRIVEN STRATEGY MOVE

Good retro on scope creep, which turned into looking at different kinds of specification and clarity/uncertainty. I have a personal action to plan out longer term estimates and business value measures better, but realistically not going to happen in the next few weeks.

Also finally, finally had a good session with Excel or improve our reports on Hive Pixie. I can see an end now, now that the Proof of Concept has been proved. Very happy.

And this sprint, in our Pokémon-based naming system, is the classic “Sprint Jigglypuff”. Generally a good feeling today, and seems appropriate for Eurovision week!

Shut it, Jigglypuff

SAVE YOUR ENERGY FOR SATURDAY, JIGGLY

Friday

Worked from home for domestic logistic reasons. Which worked out well and got loads of stuff done. Mostly digging into my email Backlog, and digging out policies for all the third party services we use. Woooohooooo.

Must dedicate more time to maintaining emails – what is the best time of day for this?

Scarily, I’ve signed up to do a quick talk about Democratising Big Data at the end of June – looks like I’m the only non-academic-Doctor talking. Feeling a little sense of imposter syndrome I guess, but not as scared as I would thought I’d be.

I’ve got to send a quick abstract of the talk next week, which is forcing me to think about my point, and my narrative – and I’m actually getting really excited about it! So I just need to fend off the feeling of Imposterness with some confidence that I know the subject (a decade of working in the area helps – A DECADE) and a clear line that I can follow, so I don’t go off into strange waters.

ANY QUESTIONS FROM THE AUDIENCE?

Future plans

Been writing up a blog post on Code Review Culture following on from last week’s notes – I will finish it this week.

Also Ian noted his interest in a broader series of posts, looking at establishing a culture of errors more generally, so I’m hoping to start plotting a few on this.

Kultcher

Reading

Pondwatch

  • Saw two ducks having a right old barney with each other. Didn’t know whether to break it up or what.
  • Fish were jumping on Tuesday morning. Pretty big too, size of a human footy I reckon.
  • The bluebells are still out!

Weeknotes 07×03: GDPR. Development. Personal. Reviews.

Sorry, no time for gifs or pics this week… THE CONTENT IS TOO INTERESTING IN ITSELF.

Before the week…

What am I looking forward to this week?

Breaking the back of my GDPR work. Unless it breaks me first.

No crazy deadlines – I should take the opportunity to smile a bit. I’m far too concerned about whether I doing the “right” thing. Last week taught me I really need to rest more.

The second round of Book Club.

What am I not looking forward to this week?

Hmm, nothing in particular.

What am I not sure about?

Discussing mentoring and my own career. Feels odd just writing it down, tbh.

Expected theme

Good progress on multiple fronts. Expect pretty boring weeknotes then…

After the week…

Actual theme

GDPR. GDPR. GDPR.

What surprised me?

Getting staff development back on the agenda.

How much I’ve taken unnecessary things off my plate the last few months.

Space for links.

  • GDS book Digital Transformation at Scale via Emer Coleman’s blog
  • Cape Town Water usage map – Cape Town had to cut its water usage by more than half, to survive the year, which meant massive, coherent action across a divided city. What role will real time data visualisation play as feedback, as we have more need to change habits in the face of climate change? Can it be integrated sensibly with civic change programmes, or will it be flapping alongside, a tech or artistic curio?

Monday – GDPR and team development

Monday sit-down. Dev stand-up. Got on with some code reviews to keep things moving. The current work looks within striking distance, and John is off from Wednesday, so important to keep things ticking.

Some solid GDPR work – audited our main databases to check for user data, and all as expected. Draft plan in place to tidy up a bit, and caught Stefan (PO) to work out when we can do the work. Google Sheets, Confluence checklists, Jira, and post-its, all working in uniform at last. Very happy.

Monthly management meeting after lunch. Bit of a push through finances – useful stuff, but tricky to draw a line between getting an overview, useful discussion, and too much detail. Would be good to get a better agenda for this meeting, and a chair to keep thighs “fresh”.

I got to discuss options around possible mentoring for me, and we decided the time/cost isn’t quite right (which was a shame, but why I wanted to raise the question with others, and fit with my own hesitations). Best result was that it aired the conversation around personal improvement across the team as a whole, which is important – moreso than my own mentoring.

The balance between company and self – partial vs impartial – in this decision is a strange one. As I suspected, personal development needs to tie in with company plans, and as ever, I don’t have much of an idea on how much weight others want to place on “tech” in the company.

If I don’t go for this particular mentoring, it does leave me with a bit of change of plans though, and I guess I’m back to looking for maybe some free mentoring on tech leadership.

Tuesday – Code Reviews and Pokemon

Code review day to keep the current dev push ticking along. Mostly Javascript, which is a good opportunity to sanity check and pick developers’ brains. Code review is all about my learning, and today I had a useful discussion about semi-colons (really?) and realised I needed to document some code approaches better, so did.

I still feel a little uneasy about code reviews, and a wary about coming across as too antagonistic. Developers are often (rightly) proud of their code. But also (wrongly) want to move on to getting the next thing working. Code reviews stand somewhere in between criticism and learning opportunity, but neither is inherently welcome if the attitude is one of just “get stuff working”.

It feels like code reviews could have their own cultural definition. Time for a spin-out blog post!

Went Pokémon hunting properly for the first time, with 4 kids. Kind of oddly hilarious.

Wednesday – Me and Future

Activate completer-finisher mode – pushed to close off a bunch of sprint work. Jumped into Javascript and things went well.

GDPR catchup on our servers.

Had a bit of a 1-1 with one of our Board members, which was really good. It’s been a while (or never?) since I’ve talked through my thoughts on my own role, and what the company is doing. One hour is pretty short, so it was a bit scattered, but came out of it much more relaxed.

Firstly it helped me to list the stuff I do, and work out which aspects I enjoy, which are necessary duty, and which I’m just “hand-holding” temporarily. I can start to think about “exit options” and handover ideas for the last of these.

Second, it gave me some confidence to push forwards on the things I think are important to me. I really want to get a stronger tech programme in place – it feels like we’ve got a bit “settled” in our habits, and it could be pushed forwards a bit. In reality, this would mean stronger change and adaptation, including :

  • better staff skills and learning
  • clearing up code debt
  • bolder, clearer roadmap for internal change
  • more integration across the company, rather than just my team
  • clearer, nimbler process for all of the above

I feel like the last couple of years have been a lot of on-the-job practice to work out how to do the these things. Now I’m ready to apply it all.

Lastly, by listing my roles, I also realised how much stuff I’d already handed over, these last few months. A couple of the hand-holdy projects I used to list in my roles were no longer there. Not writing them down reminded me that it’s ok to relax a bit again.

Also #son2 has some spots. Has he got chicken pox?

Thursday – Small Steps and Learning

Catch up chat with our partners to raise some GDPR stuff with them.

Released an update to a site, trying out some new deploy scripts which almost worked. Took longer and was slightly more nerve-wracking than expected, but all fine 😉

Had a very positive chat with Stefan (PO) to arrange one small next step we can do to improve our debugging process. In essence, it was a chat to ask “permission” to raise errors more clearly, with a simple decision to use a single label in Jira, and agreement to review these regularly. Another small, but important, step to happiness…

Chatted through options on some analytics work with Joel. Should be a nice bit of work coming in over the next few weeks.

Had some fallout from a “bit of an incident” from the day before, which I wasn’t directly involved in, but tied in with thoughts on staff learning I’ve been having the last few months. Everyone makes mistakes, but not all mistakes are equal. Errors are the best way to learn, but not always good for the whole. How does a manager know when to let mistakes happen, and when to step in and stop them?

(The risk of “micromanagement” comes up, but rarely gets mentioned in the context of “a series of small errors adds up to systemic catastrophe”.)

As above, we have code reviews in place. But an error-encouraging environment needs a lot of infrastructure in place. This week, 1) code reviews missed a piece of functionality being missed out (although this got caught by testing), and 2) I noticed some reviewed code which could have been better, and went back to help (“force”) a bit of a rewrite. What does that say about our failure infrastructure?

Yeah, can definitely see a series of blogposts here…

Friday – Chicken and Pox

Turns out #son2 does indeed have the chicken pox, not just lots of insect bites, so stayed at home to look after him. Got an hour on emails, although was most proud of summarising an overview of the immediate upcoming priorities. Summarising stuff is definitely an art.

Kultcher

Reading

Writing

Pondwatch

  • The little white rowing boat has been seen, out from its slumber shed, being prepared to guard against liquid leaks. The boat is named after a lady who helped get the pond setup as a community adventure. I really want to catalogue all the names the pond has dedications to.
  • Pulled out a road sign that had been dumped in the pond. It was covered in lime green blossom floating near the pond edge.