Constructive criticism (and breaking builds)

Yesterday at work, I wrote out some copy for an app. Well, actually I think (and my technical description is unlikely to be 100% accurate here) I created some ids and strings for an app, ready for other people in my team to use when they get to building that bit of the app. It involved pulling, pushing, Bitbucket, branching, swearing, merging and getting my work reviewed.

None of this would have been possible to get done by the end of the day without help from the team I work in. I was getting a bit tied up in mental knots with all the steps, and I wanted it done and merged (merged and done?) before leaving for the long Easter weekend.

An interesting thing for me (being fascinated by human minds) was the minor but noticeable frustration I felt when the code review found a few things I needed to fix (empty lines, dodgy hyphens and full stops instead of ellipses).

My midbrain: “How can you attack me like this! My work is flawless. Of course there is nothing wrong, I did it.”

My forebrain, a few seconds later: “Oh yeah, that could be better. That’s useful to know. Of course, that should be corrected in case it causes weird line breaks. Good thing this was reviewed. I’m lucky to work in such a helpful team. Of course there will be mistakes – this is not a usual part of my day-to-day work.”

The frustration was fleeting and I’m aware of the contributing factors. I had set myself a deadline and therefore created an extra source of stress, I had mentally started dissociating myself from the work (last string written = done in my head), and there was mention of post-work beer (distraction!). All of these things compounded the (momentary) indignation I felt at having my work questioned.

Me talking about my fear of flying – photo by Andy Barber

Coincidentally, two days previously I’d been talking at a Meetup about the brain’s threat response, and how it can impair the cognitive processes we need working well in collaborative knowledge work. It was interesting to experience it in a code review situation, and to come out of it understanding a little more about how (good) code review culture can help people develop, both technically and socially.

“”Breaking things with problematic punctuation…”

I made the changes – but still managed to break the build with a (previously unnoticed) superfluous quote mark.

Luckily I’d had a few goes at fixing stuff by then so I pretty much managed the push/pull/create a PR/merge thing by myself 🙂

Why I love my role

While I was studying such subjects as Zen Buddhism, environmental sociology and road network capacities at university, it never crossed my mind I would one day end up working in the software industry.

But I am glad I found my way to it, because when I put aside the day-to-day frustrations of protecting teams (sometimes from themselves, mostly from forces outside), and pushing for agile ways of working (against the ever present and insidious threat of  command and control mindsets), when I stop to actually think about it, I realise how much I love the scrum master role I have held for the past 5 years.

These are (some of) the reasons why…

Possibly the biggest reason – it has satisfied my never diminishing desire to keep learning. Technical stuff, people stuff, product stuff, organisation stuff – I can’t get enough. Things I have learnt about include, but are not limited to:

• Databases (relational and non)
• A bit of the C# programming language
• Some html/CSS
• Neuroscience behind how humans think and act at work
• Systems thinking
• Theory of constraints
• Behavioural economics
• How to count to 10 in Hindi
• How to say ‘thanks’ in Urdu, Lithuanian, Polish, Belarusian, Hungarian, Greek…
• Which of my teammates are creative writers, dancers, volunteers, photographers, bakers, gamers, brewers, hikers…
• The evolution of programming languages
• The tribalism/cliquiness of groups of people using programming languages
• Mediation skills
• How much developers rely on each other and the wider hive mind
• More about myself – what motivates me, what stresses me out, how better to look after myself so I can help other people.

Another strong reason…the teams I have worked in have been, without question, welcoming, inclusive and the most patient teachers – from talking me through automated test frameworks, bluetooth protocol diagrams, containers, microservices, version control systems and pull request etiquette…

They have also been good sports in my experimental games/exercises and have never, ever made me feel like what I bring is superfluous or secondary.

The role is personally rewarding and goes some way towards satisfying my do-gooder nature. 7 years ago, after completing my transport planning MSc, I tried getting public sector work in road safety, but our government was cutting funding for such frivolities, hence the ‘temporary’ work that eventually led me to the software world. While I’m aware I’m not making massive contributions to swathes of society, I think I have helped make a few people’s day-to-day working lives slightly easier, more relaxed and maybe more enjoyable. (My core professional tenets are basically to facilitate delivery while ensuring no-one on the team hates coming to work, so the psychological wellbeing of my team is a constant consideration.)

Another reason I love my role is that it has helped me embrace not being in control. I am a natural control freak (I rode on the back of a motorbike once before I knew I wanted to be the one at the front), but as a ‘non-technical’ scrum master, there is no way I can start to let power go to my head and tell the team how to write unit tests, or which architectural solution they should use. Neither can I say the most valuable work to be doing next – there’s our product owner for that.

And I really like this – it’s enabled me to see what can be achieved when you combine people with a diverse set of skills, experiences and viewpoints. It has also allowed me to focus on the things I find interesting… team psychology, individual wellbeing and development, and, yes, wandering around with a hot beverage as I observe all the awesome stuff being done with only the lightest of nudges from me here and there.

On the subject of ‘real work’

Excuses

I’ve been rubbish at updating this blog. I’ve not posted for over a year (though there’s a few drafts knocking around). My excuse is that the last post coincided with the arrival of a foster dog who ended up staying for 6 months, and walking/feeding/training/gazing adoringly took up a lot of time.

Anyway, I’m back, with lots of ideas for posts (whether they materialise or not is another matter).

‘Real work’

What prompted this little flurry of activity is two things I heard at work last week.

1. A newish line manager mentioning in a daily standup meeting how he got some 1:1s ‘out of the way’, with at least one of his reports present;
2. My team was asked to create some strings ‘as soon as possible’ (natch) for translation reasons, but this hadn’t been planned into the current sprint. I offered to do it (I have done it before and can just about manage the version control process with some help) so it gets done without impacting the sprint work. After this was discussed a senior colleague said I’d be doing some ‘real work for once’…

The two people involved were making throwaway comments and I think if they’d stopped to think they wouldn’t have used those words. I mentioned it to the speaker in case 1 a few days later – he said he didn’t mean it like it sounded and he probably could have phrased it better.

In the second case I called it out straight away and I got what I felt was an apologetic response. I wasn’t particularly offended or upset (after doing this for a few years, I have confidence in what my skills bring to development teams) but there was a momentary flash of annoyance when my purpose and value was apparently called into question.

The two cases are different but related – and have led to a few days of rumination on what people consider ‘real work’.

This idea of productive output (in this case, code) being, in words from my industry, ‘must have’ and communicating, improving, planning, pairing, mentoring, coaching, testing, discussing, leading and so on being ‘nice to have’ is insidious. People claim to value such things but their behaviour often says otherwise, especially during ‘crisis’ situations, (arguably the time you need this stuff the most).

If more than one person is ever going to build, test and maintain the software, planning and communication is essential. If the software should reach a quality threshold, and knowledge is to be shared, pairing and discussing is essential. If companies want to retain staff, and keep them engaged and motivated, mentoring, coaching and leadership is essential.

What people (everyone but especially those in management/leadership roles) need to understand is that in building modern software systems, those ‘nice to haves’ are essential in anything other than the shortest-term case.

And importantly they need to convey this so others understand they are valued.

What does a scrum master do anyway?

I think the reason these two events are connected is because much of what I see as part of my role fits into some people’s views of what’s ‘nice to have’. I talk to people, observe, coach, suggest, facilitate, develop the planning and communication skills of the whole team, push for continuous improvement…and yes, drink a lot of hot beverages while I do it.

I should point out that I’m guilty of such thoughts occasionally – the first time I created some copy for the dev team, somewhere deep in my brain there was a tiny buzz about how I had 17 strings to show for my time. Hurray! Look at this validation of my worth! (I even felt like a real developer when some erroneous quote marks broke the build 😉 (despite 3 approvals on my pull request…))

Despite the confidence I mention above, I do have the odd moments of doubt, dwelling on my lack of tangible output and wondering if I should create an intranet page that no one will ever look at.

Mostly however, I am able to resist the lure of busy work and keep my focus on collective output and team wellbeing.

For any new (or experienced) scrum masters that have similar moments of doubt, the best analogy I have heard is that of engine oil.

Wikipedia’s definition includes the following: ‘The main function of motor oil is to reduce friction and wear on moving parts and to clean the engine from sludge’. Oil’s not a moving part, and it doesn’t convert fuel to code kinetic energy but the engine isn’t going to function well for long without it.

I’ve definitely helped reduce friction and wear, and prompted the team to discover and remove the sludge – ie things that slow us down or confuse things.

(There’s something here about developing teams enough so they become…er self-lubricating but it’s probably best not to go down that analogy rabbit hole.)

And anyway, if people look hard enough, it turns out there are many tangible outputs from my role – meetings with a clear purpose, a team that is able to consistently deliver work, moderately content team members that don’t flounder in apathy or stress… The difference is that these relate to the collective (the team) and they come into being over a longer period of time than an hour or a day.

And, the work that goes into achieving this is subtle but real.

Agile in the City Bristol 2016 – 10 great things

Last week, slightly delirious from sleep deprivation brought about by the arrival of an energetic foster puppy, I attended the inaugural Agile in the City conference in my hometown of Bristol. For two days, the M-Shed was full of talks, workshops, coffee and games, and since then my brain has been slowly processing what I heard and saw.

In lieu of a more verbose write up, which I don’t think I could do until I’ve caught up on my pup-interrupted sleep, here is a quick list of ten awesome things from the event.

• Location – The M-Shed is a great museum and venue, and walking towards it from College Green meant some spectacular views of the harbour in the early(ish) morning light.

• Portia’s playtime – Portia Tung, one of the keynotes, has the simply fantastic sounding role of ‘play coach, storyteller and wishmaker‘. Her Friday morning presentation had us singing, chatting, doodling and learning, and even after such a short session it was obvious there are many benefits that can come from playing more.

• Meeting Helen Lisowski and Sal Freudenberg – I have been working ‘with agile’ for a few years and in that time I have become aware of the work of Helen Lisowski and Sal Freudenberg. It was lovely to meet them in person and attend their very interesting sessions on non-verbal communication and neurodiversity in the tech industry.

• Nirvana AND South Park underpant gnomes in one talk – David Evans did a great talk about improving the quality of user stories. It also happened to feature Smells Like Teen Spirit and a clip of the brilliant business strategy of the South Park underpant gnomes…

• Sharpies – I love Sharpies at the best of times. To be able to use an array of rainbow colours gave me some serious stationery shivers.

• Male/female balance – As a motorcyclist, martial artist (‘artist’ is a bit grandiose but there we are) and tech industry worker, I am used to being one of the few females in a gathering. My perception of AITC Bristol however, was there seemed to be a good balance, both with attendees and speakers.

• Practical ideas to try out – My colleagues and I are bursting with ideas and all have a list of things we want to try. The speakers were more than happy to chat between sessions and answer our questions, and it was great to talk to other attendees and share our experiences and thoughts.

• Weathering the storm – Something Lyndsay Prewer said in his session really struck a chord with me – he said what we tend to call roadmaps are better thought of as weather maps. I’m definitely seeing parallels between Michael Fish‘s most famous weather report and the expectations of some stakeholders I’ve worked with.

• No awkward networking – I am not good with small talk and schmoozing, but I love chatting to people and finding out more about them and their experiences. The interactions I had between sessions certainly felt more like the latter. 🙂

• Polaroids, playlists, realtime retro – there were some great interactive elements scattered around the venue with feedback being acted on swiftly and hilarious Polaroid selfies helping us find out more about our fellow attendees.

Making the glass sing

As I type this, the dev team I work in is operating in the smoothest and most efficient way I have seen since starting here 8 months ago.

We were aiming to get a deployment out after the weekend to coincide with a big customer being set up on the product we work on. It now seems, for a variety of reasons, the deployment will be a couple of days later than we hoped. (I’m not saying planned, and I‘m certainly not calling it a ‘deadline’, because as a team we had no real say or influence in setting it.)

We’ve had test deployments failing, and our work wasn’t refined to the detail I’d prefer when we started the sprint. For something we worked on that should be routine, there was only one developer who had proper knowledge of it, and he’s been on holiday. The work we are doing has involved working with partially implemented but disabled functionality so the slate wasn’t blank. We’ve also had a bug fix we’re trying to get live, the testing of which is dependent on data updates by the third party we integrate with every time it’s released to test, staging and live.

It’s not pretty – there are single points of failure and bottlenecks all over the place. Our product owner is having some potentially difficult conversations with people whose expectations didn’t exactly match the reality of the situation. We’ve had three ‘standups’ today to see where we are with everything.

But, despite all this, I am a very happy scrum master. This week, despite all the challenges, I have seen how a group of people can come together and really act as a team, having fun along the way.

The best way I can think to describe it is like when you are trying to make a wine glass ‘sing’ and you try and try and nothing happens, and then you make this sound!

Thinking about the tangible things I can list that have helped this, I have come up with:

• An engaged and pragmatic product owner who is working as part of the team
• A common focus with everyone on the team aware of the goals
• Well (though not perfectly) refined user stories (having an engaged product owner has really helped with any mid-sprint questions that arose)
• A sense of urgency (but not panic) which has made the team feel that they can decline meetings and focus on the work at hand
• No expectation of also ‘just’ working through support cases at the same time (we’re on call for anything urgent but that’s it)
• More than one developer working on a user story. This has helped plan the work, resolve issues, spot potential problems before they occur (or get deployed)
• Having a plan, but also updating it regularly in light of the actual situation.

As I mentioned above, there are many, many things we need to improve – which is a job for everyone at the organisation, not just the development team.

But this sprint, the glass sang clearly. Not every minute of every day, but often enough and loud enough for us to notice.

Back to The Matrix

Things have been pretty quiet in the binary learnings lately. My intro course finished a few months ago, plus it’s been quite a hectic time at work. Consequently, I was happy not to turn my laptop on when I was at home, preferring instead the sofa, a cuppa and a book (made of actual paper). 

However, a few weeks back I was at my dev colleague’s desk and as I glanced at the incomprehensible gobbledygook on his screen, I actually found myself missing Visual Studio. 

I have a new laptop and as I type this, it is busy installing Visual Studio. Hello World round 2 will shortly commence…

But what…is it?

Tonight at college we learned about objects and created some classes. Also there was some nested for loop action. 

Much to post about in my world of learning the magic of binary – I’m just being rubbish at finding the time. 

Anyway, tonight, at the end of the class, our teacher gave us all a present and said we’d talk more about it next week. 

Is it a horcrux? 

Bristol Open Data Challenge

On Saturday, I took part in my first hack day, organised by Connecting Bristol and Urban Things, after hearing about it at the May Geek Girls Bristol Meetup and inviting myself along with 2 developers at work who were already signed up.

The objective for the day was to ‘work with The Bristol API to innovate a creative solution that aims to reduce pollution by tackling a key transportation issue’, and below is an account of my day…

10:30 – I’ve had coffee, created a GitHub account, and heard a lot of things I don’t understand. Currently, the list to look up is – SDK, objective-C, enums (my college teacher mentioned these the other day), Swift, Swagger. I’m sure this list will grow as the day progresses…

10:39 – Ahh, Software Development Kits.

10:54 – We are arguing about ideas and the transport related problems Bristol faces… I’m attempting to dig deep into my memory to recall issues covered in my transport planning MSc.

11:25 – Lists of the issues we’ve considered so far…

• Congestion
• Air quality (map route for runners/cyclists)
• Bus journey time reliability
• Bus lane blockages
• Weather affecting transport choices
• Overcrowded buses
• Road safety for vulnerable road users
• Security for cycle parking
• Lack of parking facilities.

12:41 – Idea 1, route mapper for ‘least polluted’ cycle/walk/run route. Scrapped because not enough real time NO2 data in the central areas.

12:55 – Idea 2, an app to find the safest bicycle parking in Bristol centre. Scrapped after looking at a disheartening heat map of bike thefts between 2010-2014, and uncertainty over data of all cycle parking facilities available.

Cycle theft heat map

13:00 – LUNCH! An excellent spread of cheese and pickle wraps, hummous and raw veg, and a brownie that’s making Tom make weird Meg Ryan noises.

14:02 – We seem to have agreed on an idea.

14:16 – The working title is Stride and Ride (credit Sam Meek-Welsh Davies who did some remote marketing support!), and it’s an app to tell you the furthest distance you can travel on a First Bus 3-stop hop ticket, which costs £1, on your route from A-B. The idea is to encourage people who don’t currently consider walking to increase their active travel by using the bus for only part of a journey, initially for the furthest stretch. We have already identified many ways to expand this (use £1 bus for the steepest part, or the least interesting) but we are trying hard to stick to the minimum viable product.

They’d had A LOT of coffee and sugar by this point

14:42 – Tom and Russ are writing some code, probably. I’ve been drinking tea and working on the organisation side of things but might get pair programming in a bit. Currently they seem to be alternating between cheering and swearing…

15:39 – I’ve been busting out my ‘drawing the internet’ skills and sketching wireframes for the iOS app. However I have been informed that my plans for a user to enter their postcode may be too ambitious and for MVP, we’ll be using longitude/latitude.

16:21 – Judging starts in 38 minutes. Currently we have little to show.

16:40 – 19 minutes to go. There is no front end to speak of but the data is coming through and the console app window is showing something. I think my wireframe sketches were a little premature…

17:15 – Panic mode. Neither Tom nor Russ’s laptop has a VGA or DVI port so presenting our…ahem…app on the projector is going to be a problem.

17:17 – My old creaky 7 year old laptop has been recruited due to its 15-pin D-subminiature VGA connector.

17:25 – Getting the code up has frozen Visual Studio. My laptop is getting warmer by the second.

17:28 – It’s up! And just in time…

17:32 – Demo done. It wasn’t pretty but we got through it.

17:42 – There is now beer.

18:00 – We only bloody won!

I’m not sure I agreed to the team name…

An excellent day was had by all, and I’m excited about being the product owner for the app (Tom and Russ haven’t exactly agreed to this but I know how to give confusing and contradictory requirements (‘Make it POP!’) so I’ve got this…).

Thanks to the organisers and the Watershed for hosting – I’m looking forward to the next one!

Thank you Stack Overflow

Tonight, I have successfully harnessed the power of the developer hive mind.

To play around with lists and randomness, I created a list of chocolate bars (as strings), and I wanted to select one at (pseudo) random. I tried the code we covered in college to deal with random numbers, but it whinged at me about int/string data type clashes (and, as usual, info in the Visual Studio help boxes was as clear as mud).

I did an Internet search, which isn’t unusual and my search terms were “how to use c# random instance to choose random string from list”. Normally I scan a few of the search result pages and nothing makes much sense to me, so I slink away, dejected.

Thanks Joey!

This time however, I found the above response to a question on Stack Overflow and it didn’t look too intimidating. I managed to adapt it and stick it in my code, and lo, it seems to have worked!

Random Twix selection

I’m sure the code above is not the most elegant, I don’t really understand what I did, and I broke things trying to fix the line breaks, but for now I am basking in the achievement of my randomly selected Twix.

Successfully implementing something I found on Stack Overflow – now I feel like I’m a programmer 😉

My first Hackathon

Today I signed up for the Bristol Open Data Challenge, a 1 day hackathon working ‘with The Bristol API to innovate a creative solution that aims to reduce pollution by tackling a key transportation issue’.

Given I only just about managed to declare and initialise an array at college on Tuesday, and have been puzzling over how I do the foreach loop exercise that requires it ever since, I may be attempting to run before I can walk.

But I’ll be in a team with a couple of lovely developers from work, and I’m sure I’ll take something away from the day even if I don’t understand the majority of it 🙂