Jump In

Surprising Role Differences Between Frontend Engineer and Developer Advocate

Change is a scary thing. Even with an abundance of preparation, you may be worried if you’ve made the right choice. It’s only with time, and the events in your rear-view mirror that you have the space to reflect on whether it was the right decision. From graduating from school college or university; to moving town or home; to welcoming a new addition to the family; to transitioning jobs and companies; the anticipation and nerves in the pit of your stomach can leave you worried if the leap you’re about to make is worth it.

 

Three months ago, ahead of my first day as a Developer Advocate, I had the same pre-first day butterflies in my stomach that I do with every change. My husband will attest that I am that person who tends to like having a plan or having considered every angle before diving in. I had weighed up my reasons for leaving carefully. I had done my homework on the expectations of this role, and the typical responsibilities of advocacy roles thanks to some great conversations and resources from wonderful advocates like Trisha Gee, Helen Scott and many others. I had researched the company I was due to join and was happy I was joining a strong, friendly and supportive team who would support me along the way. I felt very much prepared and happy with my decision.

We all have that imposter whispering in our ears questioning our decisions. I just imagine mine looks more like the Shame Wizard from Big Mouth!

But then the sly imposter’s voice starts whispering in my ear. Have you missed something? Have you made a mistake? Should you really leave a comfortable spot in the investment bank you’ve been in for 10.6 years for advocacy?

 

Although my experiences of my first conference slot as an advocate gave me an indication, passing my probation and becoming an Elastic Certified Engineer have shown me I enjoy advocacy and am performing well. It also exposed me to many additional differences that I was not expecting despite my meticulous research. Here I share five surprises I’ve encountered in my first 3 months as an advocate, for anyone curious about jumping into advocacy, or even those interested in movement from regulated industries such as banking to tech.

 

Eeep, Where are the Bumpers!

 

This insight is very much specific to my experiences of moving out of a heavily regulated industry. Prior to this role, I spent just over 10 1/2 years working in investment banking. I had worked for the same company since graduating from university. Despite having progressed through the ranks, and undertaken a mixture of tech contribution and leadership roles, I still felt like I was in my first ever grown-up job in some regards.

 

Finance generally is a regulated industry. It might not be apparent when you start, or for this in other industries, but regulation has an impact on the processes and techniques you adopt when building software. Banking, in particular large incumbent investment banks, can adopt processes that, while often necessary, can make getting things done challenging. It’s natural for developers wanting to ship software to find jumping through these hoops frustrating. Often it’s not apparent what the justification for the procedure actually is. Or these processes can feel like archaic and overly-bureaucratic procedures that are maintained in lieu of adopting modern, automated techniques that could produce similar or enhanced controls and faster delivery rates and less aggravation. Sadly towards the end of my tenure, I felt this frustration as some procedures no longer made sense to me, and indeed some colleagues, and seemed to be more driven by other individuals’ aversion to change than as legitimate protection. Yet for the ones that did make sense, they gave you confidence that there were guard rails in place to stop you from doing something you really shouldn’t.

 

Kid Rolling Ball Using Bowling Ramp

 

Moving from a large to small company is a bit like the first time you go bowling as a kid and don’t have the bumpers or ramp

 

Jumping into a tech company that is currently scaling is a large step away. I imagine moving to a small start-up would have been an even larger change. Often many of the processes you took for granted are there are not, or are regularly evolving. This change can feel odd. Much like the first time you go ten-pin bowling with the bumpers (aka those metal barriers that stop you from rolling the ball in the gutters) down as a child. The first few times you’ve visited the alley as a child you might have had the bumpers up, or perhaps the metal contraption, or ramp, to help younger children roll the ball, to help you get a strike. Suddenly not having those aids available can be initially scary and intimidating. You may be fearful to make mistakes or throw a few gutter balls. Thankfully my experience has shown with a supportive team who has welcomed me and answered my myriad questions, after a few throws you’ll adjust and start hitting pins down again.

 

Beware Freedom Paralysis

 

An extension of this lack of bumpers is an abundance of freedom, which you can fear you’ll fail to capitalise on effectively. Most software engineering teams operate today with a rough plan of where they are going. They will have either regular releases or working cadences where they deliver features. Note I purposefully avoided the use of Sprints there people, as Kanban and other frameworks and techniques work for software too! Ideally, teams will adopt a continuous delivery model with knowing what product direction is and developers will feel confident picking up the next feature for development. Your deadlines feel a lot more concrete.

 

Starting out as an advocate requires more exploration, and has a less concrete path. Some of your activities may tie into conference engagements and booth duty for scheduled conference sponsorships with set dates. But much of your learning and initial content generation doesn’t have a set deadline. Furthermore, this deadline isn’t really set by a single individual such as a Product Owner, Product Manager or other tech management. I have a lot more admiration for advocates as I’ve realised you have to be strongly self-driven to generate authentic content that fits the products you advocate for, and then share it in various forms. This can also be even more challenging as many of the advocates I know and work with work remotely or while travelling.

 

Women Confused Shrugging Shoulders

 

I’ve had the issue of having so many ideas that I’m not sure where to start

 

It’s up to you to find your own way and formulate a plan of what areas you want to focus on. Over time I’ve found that so many ideas for content and projects have appeared in my head that I have to note them down somewhere and form a rough plan of what I’m going to focus on for the next few months. Those who know me as the reformed Scrum Master and Agile geek will be happy to know I have a simple private Kanban board to throw these ideas on and evolve them over time.

 

It’s important to also find your niche. You might think your job is simply to showcase the products built by the company you work for. To present engaging content that is interesting to the community, you need to present an authentic voice. Furthermore, it can’t be a simple product pitch that you throw down developers’ throats. I was surprised that I could maintain my passion for frontend development, and use that to frame the topics I share with the world with a sprinkling of the products for which I advocate.

 

Actions Speak Louder Than Titles

 

There are many different titles that people will give themselves within advocate circles. You might have come across individuals calling themselves Developer Advocates, as I do. Others refer to themselves as Developer Evangelists or even Developer Relations. Figuring out the difference between these titles can be confusing, as they largely mean the same thing. However, this community realises that the title is less important than producing content and engaging with a strong community of enthusiastic developers.

 

A wise and experienced advocate once told me I was already an advocate in practice since I was speaking at conferences and sharing blogs with the world. Yet when I decided to add Developer Advocate at Heart to my LinkedIn profile to attract more advocate roles, it felt forced and fraudulent. Part in a way because a lot of the content I had written had more of an agility or engineering manager vibe. However, the main reason for this was the simple fact that the procedures of my prior organisation when reviewing my content left it feeling like unappreciated efforts that aren’t part of my responsibilities as a front-end engineer. Although some were very supportive and gave me strong mentorship, sadly after a while their support was overshadowed by negative views and experiences.

 

Group of Kids Huddled Together Looking Out Over the Sea

 

Irrespective of whether you’re a developer speaking or an advocate, you are still part of a community and able to share ideas

 

Now that I’ve moved onto this role I see what this advocate meant. Much of the skills I have built in speaking, blogging and coding are those that I use now as a Developer Advocate. Even in the first 3 months! Those same skills will be the ones I will continue to build now that I have the title.

 

Spare Time Is Now My Job

 

As an extension to the prior point on actions, I have a stronger appreciation for how amazing it was for me to undertake advocacy in my spare time when it wasn’t technically my job. Prior to becoming an advocate, I spent an inordinate amount of personal time working on my blog or building a talk. In my last role in the bank, I was strongly encouraged to use company time for building out talks. However, working in an organisation where software and technology are a cost rather than a direct sellable asset can mean justifying working on a conference talk over coding up feature X or attending feature Y is difficult as it can be challenging to justify to users who needed that feature last week.

 

By the end of my software engineering tenure, I found that I enjoyed the time I spent tinkering with code examples or writing talks and blogs far more than building the software and following the required procedures to get my changes live. I once had a boss who emphatically proclaimed when I started working for them that they worked to live rather than living to work. When I heard this as a young software developer living with roommates in London without any dependents or cares I found this strange. We were working 40 plus hours per week, with emphasis on the plus for me. For this reason, the idea of spending the majority of my week not enjoying what I do seemed alien.

 

Happy Family Cuddling in the Sun

 

One great advantage of becoming an advocate is that speaking, blogging and coding is my job, leaving my spare time for me to spend with my family

 

Now as a mum and driven technologist I do get the idea that other priorities drove this individual. Our priorities and passions morph and evolve as we progress in our careers. If your side hustle is more interesting than your day job, and it’s viable to make a career out of it, it might be time for a change. I’m still in awe that I get to do the conference attendance and talks that I considered a fun side gig as my job. Pinch me!

 

Still a Developer at Heart

 

One factor that can make those reluctant to change from software development to advocacy is the amount of code. The coder stereotype is that we sit coding frantically all day and hate writing documentation with a passion. With a move to advocacy, there can be a natural concern that you will rarely get to code or tinker with new technologies, languages and frameworks. Instead, you’ll spend all your time building presentation decks and writing thought-leader-style blog posts.

 

Women Looking at Code

 

I’ve been glad to have had the opportunity to write more code compared to some other roles I’ve held in my time

 

I’ve been happy at the amount of code that I’ve been able to write. Part of advocacy is I need to understand how to use the products the company makes available to developers, and by extension, help share this knowledge. I’ve found in comparison to some leadership roles I’ve undertaken such as Tech Lead and Scrum Master that I have written more code in this role.

 

There is a reason that I include developer in my title. Development is still a strong part of my identity. I am still a developer at heart, who advocates for some pretty cool software. Long may that continue!

 

Thanks for reading! Do reach out if you’re interested in finding out more about my experiences, or have any questions.

Should I Stay or Should I Go? (Na na na na na na na na)

Reflections on Engineer Role Moves Within and Across Organisations

So someone has resigned. Read all about it! Suddenly the rumour mill is working overtime as the news of an individual’s impending departure starts to spread through the grapevine like pests hungrily searching for nourishment from this morsel of gossip. Many of us will have conflicting views on this depending on whether we are the recipient of news or the resignee.

 

Lucky Cats Waving

 

Saying goodbye to a company can be hard, but also opens exciting opportunities and fortunes

 

I wouldn’t call myself an expert on developers resigning, but I do have a few thoughts on the resignation versus mobility debate. In my 10.6-year tenure, I’ve resigned twice, retracted a resignation once, moved teams twice, been promoted once, and moved roles several more times within teams. I’ve also seen the other side of the coin, being the manager or lead trying to grapple with the resignation fallout. Throughout my career, I’ve always had a gut feeling that it’s time to move on to something else to scratch the unfulfilled itch in my current role. Sadly I’ve not always acted on it as quickly as I should. But even that inactivity has helped me learn and grow.

 

This rich career tapestry has molded my opinions on whether a hop to another company is always the right call for your career. As I started my latest exciting chapter recently, I share my thoughts on resignations. In this piece, I’ll cover the reasons people, and more specifically engineers, quit; when a move might be a better option for you; and tips for managers on how to handle resignations with grace based on my own experiences on both sides of the table.

 

News of the World

 

Through my own recent experience, I’m come to think of each resignation as a tabloid newspaper. I can sense some eye-rolls will appear as I write this, but hear me out!

 

Bundled Newspapers

 

Resignations are structured similarly to a tabloid newspaper article

 

There are three primary elements of any tabloid newspaper article, at least in the UK where I reside.

 

  1. There is a single bold headline that is the deal-breaker for staying within the role. Now it may not be a catchy pun like those used by many tabloid front pages here in the UK. But it’s normally the 10 words or less tipping point that has led this person to decide it’s time to move.
  2. Those catchy simple headlines are normally prefixed with a more detailed subheading to give a little more information. Here I like to think in resignation terms there may be some smaller niggling things that are not the top reason but have contributed to your rockstar employee wanting to do something different.
  3. Finally, there is the story itself. The opinion piece that any resignee has on how this bigger picture and smaller elements have manifested into a situation.

 

The headline and subtle subplot are all relevant to a resignation. As a manager on the receiving side of resignation, if you’re looking for things to fix in your organisation to eliminate further, you should scruitinise not only the sensational headline but the subtle detail in the subplot. It’s also important to look at common themes across multiple resignations across teams and institutions. Through the great resignation of 2021 and early 2022 personal factors can mean there may not be common themes, but certainly, from speaking to friends and colleagues it’s more common that bugbears that have subtly gnawed at us over time have eventually built up, and the personal circumstances become the final push to send you on your way.

 

She Moves In Her Own Way

 

Managers and leaders always want to have a simple, one size fits all reason for why people leave. Having been on both sides of the table a few times in my career, I know that is not the case. Thinking back to our tabloid analogy, it would be a pretty boring read if every article had the same headline!

 

The most common reason people cite as the silver bullet of resignations is that "good people leave bad managers". At one time I strongly believed this to be the case. I’m sad to admit that at one point it was the source of my sudden pandemic burnout-induced rage quit that forced me to search for a new role. But each story normally has a more nuanced subplot. I’m more inclined to believe that good people leave bad cultures, opportunities, or processes, that can spread within teams, departments, or entire organisations through one or many individuals.

 

Lego Joker and Two-Face

 

We’ve all had good and bad managers, although I hope none of you have worked for these super villains

 

I’ve always agreed with Rands’s principle that at some point a person’s shields go down, and they become open to new opportunities. His piece gives a wonderful set of questions that flow through people’s minds when the potential of a change emerges. I won’t cover this point as he does an amazing job doing so. But for engineers, architectures, and managers with an engineering heart, there are a few recent themes I’ve observed that contribute to a person putting their shields down:

 

  1. Do I get to work with the technologies and frameworks that I’m interested in? Particularly in heavily regulated sectors where adoption of bleeding-edge tech is considered with an immensely strong aversion for risk concerns, developers may become tired of working on old tech and concerned that they may become stuck and unable to progress in the industry.
  2. Am I getting enough time to focus on the contributions that I’m passionate about? This can be outside open source contributions or community contributions as well as within the business that you work for.
  3. Do I feel productive? Are there organisational procedures that I need to follow that I feel impede my ability to get stuff done? Am I struggling with excessively bureaucratic processes? These may also be driven by company culture or political reasons too.
  4. Do I see a clear career path that fits with where I want to go? For engineers that want to stay technical and are not interested in management or people development, companies must provide tracks for technical progression as well as progression into engineering management and other tracks such as design, testing, and agility.
  5. Do I as a developer feel respected by the establishment. In non-tech companies such as banks, health, and ecommerce where the main commodity or service is not software, you still want to feel like part of the team and not an afterthought.
  6. Do the firm values and mission still resonate with me? Have I outgrown these values? Or am I feeling that I am connected to these values, but others are not practicing them in a way that I’m comfortable with?
  7. Are the testing and technical debt practices treated with the same respect as the development of new user-focused features? Are you able to follow industry best practices in these areas? Speaking to some developers over the years, deprioritisation of these themes produces products that become more difficult to add to and maintain over time, leaving them feeling a lack of pride in the products they build.
  8. Do they have the flexibility they want to need when it comes to hybrid or remote working? Sure, some people prefer the office, but the adoption of the office-focused ethos that many companies are adopting at the moment doesn’t work for everyone. Some people want to spend portions of their time working while traveling or visiting family. Some like me find the benefits of home or hybrid working make family life more balanced. If you want to maintain a diverse and talented workforce mandating office attendance in a post-COVID era may put you at a disadvantage for recruiting them compared to more flexible firms.
  9. Yes, salary and perks are also a factor too. Let’s be honest here! Of course, this list is not exhaustive. I’m sure you’re thinking of many other factors based on your career path to date. But any one of these can open up the technical mind to considering a change.

 

Time to Move On(?)

 

When considering a move it’s often the case that we immediately jump to moving to another institution. However, evaluating the potential for an intra-company option might be a good option depending on the reasons you have for leaving. I remember seeing Carla Harris speak a few years ago walking through some of her pearls of wisdom. The one pearl that I still remember vividly was when she discussed the seat versus the house. The seat in this case refers to the role and high-level duties that you perform each day. The house is the institution in which you are working. She implores us to consider in times of career struggle if it is the seat or the house that is the cause of our discontent.

 

Armchair in Sun House

 

When considering a move it might be the role, or seat, in the house that’s not quite right

 

This advice has steered me well for a few years. I stayed in the same firm for 10.6 years and moved seats several times. It was only when I eventually realised that I wanted to take a different direction that wasn’t compatible with the house, that I ended up resigning. To continue the analogy, I could have stayed and worked to remodel the house, aka change the problems. But another lesson I’ve learned from The Liberators Network is that sometimes it’s worth thinking about if you think the fight to change in some situations is worth your time. Beliefs or opinions that are strongly embedded in organisations can be very difficult to change, even if people agree that they should not be there. In the end, if you will exert significant effort and time to rectify the problem that you don’t think is worthy of your time or impacts your personal timelines, it might be best to find another house that can be a home to these ideals and values.

 

A (Person) Worth Fighting For?

 

I’ve seen many engineering managers disagree on whether it’s worth trying to negotiate to keep someone. This applies to moves out of the organisation, as well as internal mobility moves to other teams. I think there are good and bad ways to approach it. Sadly I’ve handled it badly and well for different individuals over the years (apologies to those in the former camp). But in my experiences on both sides of the table, and experiences with amazing and not-so-amazing managers handling my cases, I’m starting to build a blueprint of how the best resignations are handled. Here’s how I think it should go.

 

You should always start by saying congratulations. Acknowledge their good news. This is the true distinction between good and bad managers. A bad manager takes it personally. Most managers immediately go into problem-solving mode, ask a myriad of questions and propose tons of solutions to try to fix the problem. A good manager acknowledges this is good news for the resignee and expresses happiness for them.

 

Congrats Sign

 

Don’t forget to say congratulations!

 

Next, ask them questions about the new role, and really listen to the answers. Find out what is exciting about this new adventure. How does this engagement fit in with their wider career goals? This moment is about the person resigning. It’s easy to jump ahead and think about the hurt you may feel that someone is leaving your team, or how this person leaving impacts how others see you as a manager. You need to be humble and leave your ego at the door. It’s not about you!

 

Discuss why these elements are not present in their current role. Especially if you have been working with this person to identify ways to expose them to these opportunities already. It may be a question of timing or personal circumstances that mean the timing to jump is now.

 

As uncomfortable as it may be, you should discuss compensation and perks offered in their new role. Amid the great resignation, offers are high. Particularly for long-tenured individuals who have not hopped around a lot, there may be a significant jump. Does this help them with personal aspirations? Can you counter? If you are thinking about discussing a counteroffer with management you should also consider carefully if you should as well.

 

Boxing Gloves on Floor

 

Know when you need to lay your gloves down, as not everyone wants to be fought for

 

Ask them if they want to be kept or fought for. This is important as we normally miss this and immediately escalate to keep people, particularly rockstars that you may want to retain. If someone truly has their heart set on leaving, you should respect this decision and support them in their transition. Throwing directors and senior folks at them to convince them to stay can sour the company’s relationship with that individual and make them feel uncomfortable. Not everyone wants to be fought for.

 

It’s Your Move

 

The Great Resignation has meant it has been an employee rather than employer market. In these times companies need the realise that retention of good people should be of equal, if not greater importance than attraction. Larry Fink’s CEO letter hammered home for me that managers, not just CEOs, should be mindful of the various issues facing their people and be thoughtful in how they engage with individuals.

 

In addition to upending our relationship with where we physically work, the pandemic also shone a light on issues like racial equity, childcare, and mental health – and revealed the gap between generational expectations at work. These themes are now center stage for CEOs, who must be thoughtful about how they use their voice and connect on social issues important to their employees. Those who show humility and stay grounded in their purpose are more likely to build the kind of bond that endures the span of someone’s career.

Larry Fink’s 2022 Letter to CEOs

 

Considering this sentiment, even after the resignation, it’s worth keeping in touch after they leave, and leaving the door open for strong people that you enjoyed working with. Leaving for a new company is always a step into the unknown. Although it might be rare, people may want to come back. I don’t have any experience of this, so I suggest reading Helen Scott’s amazing piece on her experience going back to JetBrains which covers this situation well. I agree with her that probation periods are an opportunity not only for employers to evaluate if you are a good fit for the organisation, but also if this institution is a good fit for you and your aspirations.

 

Neon Sign

 

Just as the sign says, I don’t know where I’m going from here, but I promise it won’t be boring

 

Moving companies can be scary. I was at the same establishment for 10.6 years, and it was my first grown-up job after university as well. So of course I’ve been feeling a mixture of excitement and terror. I’m loving the change and challenge a couple of months in. I’ve also been fortunate to connect with old colleagues and community friends at Devoxx UK 2022 as well, which was amazing too. If you’re currently thinking about staying or going it can be an agonising decision. You may be worried about the timing, what will happen if it doesn’t work out, scary thoughts about being found out as the imposter, or even if the perks will leave you and your family at a disadvantage. The best advice I’ve received is not to overthink it. I’m now embracing that sentiment and enjoying the ride!

 

Thanks for reading! Do get in touch if you would like to chat about my moving experiences, or discuss your own. For those who now have The Clash stuck in their head, apologies and enjoy!

Speak Your Mind

The Differences Between Conference Attendance Experience as an Advocate versus Speaker and Attendee

It’s tech conference season! I’m starting to find that there are two busy periods in the year for tech conferences: April-May and October-November. It’s kept me busy as a new developer advocate starting in April 2022.

It’s more of a learn-by-doing approach, just like learning to swim by being dropped into the middle of Loch Ness. However, I wouldn’t have it any other way as I’ve always been more of a learn-by-doing person. My first ever manager referred to this style as “filling your boots”, which means diving in and taking as much as you want. You just need to balance this with not taking too much. Otherwise, you’ll end up in a similar situation to my husband in his youth where his boots filled with mud at a festival and he struggled to escape the field of sludge (sorry honey)!

I have been fortunate enough to speak at several conferences, including Devoxx UK in 2021 and 2022. My first experience was as an engineer with a passion for speaking and the second was as a developer advocate. I’ve enjoyed both of these experiences. I’ve also experienced vendor booth duty at DevOpsDays Birmingham, which was an enjoyable education. Up until now the closest experience I had was attending university recruitment events on behalf of my prior company.

Speaker on stage as seen by the audience

In addition to adjusting from online to in-person tech conferences, I’ve also been adjusting from attendee to speaker and advocate

I can’t help but see some key differences in my conference experience between my different roles. In this piece, I share my comparative experience as an attendee, speaker, and advocate, as well as tips on how to maximise your experience irrespective of your title.

(Not) Guilty

One key difference when attending is an advocate is that you see attending the conference and speaking to people as part of your job. As a general attendee, even though you are representing the company, it can feel like it’s perceived as a bit of a jaunt because it’s not a common activity for you to engage in. Even if you’re a regular meetup attendee, you are going to sessions in your own time at lunchtime and evenings rather than during traditional work hours. So going to a conference during the day when you have a mountain of work to do can leave you feeling a little guilty.

This could partly be dependent on the various factors that have led to your attendance, such as:

  • Whether you paid for your ticket out of your pocket or if it was expensed via your company.
  • If the ticket forms part of a dedicated personal training budget or a centralised departmental pot. I’ve seen where this is held centrally that you are less likely to partake in training outside of internal company offerings.
  • The number and levels of approvals required for conference attendance and speaking. While many start-ups and scale-ups have lighter procedures such as manager approval, larger institutions may have more defined or multi-level approval processes.
  • Any expectations regarding knowledge sharing of what you find out. Some organisations or departments encourage you to share what you find out via internal blogs or knowledge-sharing sessions. One former colleague I bumped into at Devoxx UK was in this situation where they were taking notes so they could share their learnings when they returned to the office to justify the ticket cost.

I’ve always felt the need to maximise the attendance experience as a junior engineer when I’ve committed to sharing my experience internally when I come back to work. It’s understandable to think of this as actual work since it’s a quantifiable contribution. Often as engineers, we dismiss non-contributory efforts such as catch-ups, 1:1s, or admin because it’s not writing code. then when we transition to management, leadership, or even DevRel roles we realise that these contributions are not only valid but what we spend most of our time on. It’s important to drop the guilt, as learning new technologies and hearing about other experiences makes you better at what you do, irrespective of whether that’s engineering, management, or even advocacy. So enjoy!

Bounce Back

As you progress on your speaker journey, you’ll find you become more resilient to handling issues that appear in your talk. Possible issues are false starts, mispronunciations, and technical glitches. I remember vividly how my first-ever issue knocked me off my flow entirely. It was an online evening meetup where I drank all of my tea before my slot, and then ended up trying to curb a coughing fit live on camera with no water or beverage in sight.

Scrabble tiles spelling resilience

As you gain speaking experience, bad things don’t stop happening. You just learn the resilience to take these issues on the chin and keep going

At that moment I wanted to earth to swallow me up. However since that eventful meetup, and through the advice of other speakers, I’ve learned that the secret to conference speaking is not that your session is full of mistakes. It’s that you keep going irrespective of the mistakes that you make. This realisation has helped me adopt a change in mindset. Despite being a pessimistic character, I no longer finish a talk feeling it was a disaster if one little thing went wrong.

I remember seeing the wonderful Gary Fleming at Lean Agile Exchange 2020. I’ve never seen someone so calm under pressure. He started his talk late because of unexpected Zoom issues at the conference. His clicker wasn’t working so he casually through it over his shoulder. Yet he gave one of my favourite talks at that conference. I remember thinking I would never be able to have that confidence to cope with the unexpected. Yet I feel I’m starting to get there.

Pixelated screen

I got through the glitches, whoop!

This year at Devoxx I had a couple of glitches. My HDMI adaptors didn’t play ball, so I borrowed one from the tech gurus. My shiny new clicker with spotlight capability, which I tested at home for 2 weeks prior, kept freezing. So I abandoned it and went between the large screen and my laptop instead. I had a couple of stutters here and there. Not everything was as I practised. Yet I managed to get a couple of audience laughs, and many compliments afterwards too, including from the amazing James Gough who has been a fantastic mentor to me throughout my career. I’m not completely calm under pressure yet, but I’m getting better at hiding it over time.

Connect

Your first time attending a conference on your own can be a pretty scary one, regardless of your role or whether you are speaking or not. You probably won’t know many people at the event. It can be a bit intimidating to try and strike up conversations with people. Especially if you are an introverted character, or are from a diverse demographic. When you feel like you stick out like a sore thumb, you may be reluctant to speak to large groups of people that you don’t know.

As I attend more conferences I’m feeling more confident about connecting with people. Between DevOpsDays Birmingham and Devoxx UK this month I’ve met with many wonderful people, and had so many interesting and insightful conversations. Not all of them are about tech either. I’ve had wonderful conversations with other speakers where we have all shared our tips. Including the aforementioned notion that no speaker is perfect, and it’s that they keep going.

Two men hugging in a crowd

Conferences are great places to connect. It can be hard at first, but you will be welcomed with open arms

It’s not necessarily that I’ve become this super confident person that can walk up to any stranger and chat away. That is still a work in progress. What has changed is that I’m starting to see familiar faces appear at conferences and meetups. These individuals are also kindly introducing me to others so I can expand my network further. Conference communities are always a friendly bunch when you get to know them.

If I’m attempting to speak to people I don’t know without an introduction, I’m learning to ask more about what others do to strike up a conversation as well. Chatting with a friend this week I agree that people love to talk about themselves, so asking questions is a good way in.

Born to Be Wild

What you do in your day job may affect what talks you select to see at the conference. Thinking back to that justification of the ticket price mentioned previously, we may naturally want to pick topics relating to the tech we use every day to ensure we have the practical knowledge to take back to our organisations. Yet we can still learn a lot from attending sessions outside of our comfort zone. Particularly when it comes to identifying emerging tech trends, different opinions, or alternative patterns.

I saw so many wonderful talks at Devoxx UK this year by some fantastic speakers, and not all are strictly related to my elected speciality of frontend development. Some of my favourites were:

  • The opening keynotes I caught gave some wonderful thoughts. Holly Cummins covered the emergence and future of the Java ecosystem with great humour. Asim Hussein clearly explained carbon neutrality and offset definitions in a way that means I finally feel like I understand these definitions.
  • Grace Jansen covered stateful and stateless microservices in a great session that helped me reflect on my prior microservice experiences as an engineer and realise that it’s not as clear cut as having all your services be stateless.
  • I got to see my new colleague David Pilato in action with his FS Crawler and Elastic talk. Given I’m new to the Elastic stack it was great to see a starting example of how to show off the product to developers using a meaningful use case.
  • Taking a glimpse into the secret life of Maven Central with Joel Orlina was great. Although I’ve only used Maven repositories with Gradle in the Java ecosystem I loved the level of transparency he shared in this talk on their scaling challenges, and how they worked with publishers to address these issues.
  • As a JavaScript and Typescript engineer, I was excited to see Alvaro Berruga talk about what’s coming next in JS. I learned more about the proposal process, which was really interesting. Now I know where to find the language proposals too!
  • Going out of the traditional Web stack with Quarkus Renegade with Sébastien Blanc and Stephane Epardaud was an interesting education. I’ll be looking to learn more about Quarkus in the future, hopefully at a London Java Community meetup!
  • I have some experience of Kafka from an enterprise system architecture angle, so it was great to see Danica Fine show a home project using Kafka and senors to give her alerts when her houseplants needed watering. I appreciate the practicality of this approach given my poor track record of keeping plants alive!
  • Martijn Verburg’s session on running Java containers on cloud infrastructure was very insightful, and I appreciated the practical tips on Garbage Collector selection. My prior experience is that GC selection is never considered, and teams always go with the default assigned by the JVM.
  • Seeing nature and software battling it out against each other in the security domain was an enjoyable experience. Well done to Grace Jansen for covering both sides of the battle solo!
  • Learning more from Guy Royse about Redis and RediSearch on an interactive adventure to find Bigfoot was a great experience. This was a wonderful example of using humour and a practical use case to showcase search capabilities. I’m hoping to give Elasticsearch justice in my new role with some of the tips I picked up in this session.
  • Seeing some of the ML approach adopted by Jonas Mayer, Martin Förtsch, and Thomas Endres to respond to and address sh*tposting online was very amusing and insightful. It refreshed me on some ML challenges such as stopwords and training considerations that I hadn’t been exposed to since my university AI course.
  • Seeing Andrew Harmel Law talk about practical tips for capturing the four key metrics from Accelerate was definitely of interest to me as an agilist and frontend engineer encouraging the adoption of data visualisations rather than the usual data grids, as per my own talk slot!
  • Hearing Kevlin Henney’s closing keynote on our attitudes to change in the software we build made me smile. It was great to see that I’m not the only person who has read Your Code is a Crime Scene by Adam Tornhill too!

Of course, I should also call out the social elements like Java Jep’dy, the speaker dinner, and Devrocks drinks on Wednesday and Thursday evenings too. These were great opportunities to have fun and connect with people.

Fairground prizes booth with fireworks

It’s not so often you see a Java game show with big prizes!

I also have a few others I’m awaiting viewing when the playlist goes live:

  • Sadly I missed the start of Julien Dubois’s session on accessibility. As a frontend engineer, I’m wanting to educate myself more on how I can make the things I build accessible to all, so I will definitely be watching this back.
  • Everyone raved about Julien’s session on REST, to the extent that the room filled out. So I’m checking that out when I can!
  • The same goes for the React Micro frontend talk by Rotem Zifroni. I didn’t make it after my talk slot before the doors closed so I’ll be watching that closely to see how closely it mirrors my early experiences of Angular Micro frontends and the potential approaches that can be taken.
  • I really enjoyed the mental health-focused keynote at Devoxx 2021, so will definitely be checking out Frédéric Harper’s session emploring us to not .gitignore mental health.
  • I’m interested to hear Jonathan Rigby’s experiences of metrics mania in his talk when I can. It’s my experience that teams gravitate towards extremes of over-metrification, or not having any metrics at all. So I’m interested to find out if a happy medium is possible.
  • TDD and other drugs was full, and I heard wonderful things. So I will be watching Vanessa Formicola’s session when it comes online.
    I want to hear Anders Norås’s talk on the Marvels of Teenage Engineering. Speaking to him at the conference it sounded like he had many inspiring stories about prominent technologists learning as teenagers, which I find inspiring.

Stop & Listen

Overall I’ve found the experience of attending conferences as an advocate to be an exhilarating and enjoyable one. I’ve met many people from various companies, made connections that will hopefully lead to future meetup opportunities, and also connected with prior colleagues as well.

Scrabble tiles with listen more

As technologists, we should seek out more learning opportunities at meetups and conferences to grow

Irrespective of whether you are a speaker or not, conferences are a great opportunity to grow as technologists, expand your knowledge of frameworks, languages, and tools and connect with others that can educate you and challenge your thinking. These are benefits you can take back to your day jobs, not just by sharing on a blog or a knowledge share session, but also in the development of the software you build. Don’t feel guilty about taking the time to grow!

Thanks for reading! Do get in touch with your own tech conference attendance experience, especially if they differ from mine.

Get Off the Phone

A Year of Having No Work Access on My Personal Phone

For many, the end of 2021 and start of 2022 has been a time of reflection and comparing for many of us. It doesn’t help that this year social media sends us flashback reminders of prior years. Through the pandemic some of these has prompted feelings of hope for us, such as photos of holidays and family events. Nevertheless, reminders of 2020 events have shown times of great strife and regret that we would probably care to forget.

 

I also have similar experiences when flipping through prior blogs. They can help generate new thoughts and insights for me, which I always appreciate with a wry smile. A recent unpublished blog has got me thinking about back to January 2021, when I made the decision to remove all work applications from my phone. It was an easy decision to make at a time where I was burned out and our family were struggling with isolation after spending our first Christmas and Hogmanay, or New Years for those non-Scots reading, locked down in London away from friends in family in Scotland. I remember coming back from a two-week vacation with an uncomfortable static buzzing continually prickling through my brain, and black raccoon-like bags weighing down my eyes.

 

Dialer Phone

Phone are not just for chatting anymore!

 

It is now one year later. As I come back from a truly relaxing break with my family, embracing the joy and giggles of a happy toddler eagerly playing with his grandparents and cousins, I am glad I didn’t finish and hit send on that piece. Time and distance have helped me consider the decision in a more pragmatic way, and truly see the benefits this has given me for my work and home life separation. I did make other changes. Moving role, adding night off Thursdays to write or lounge in the bath, and ensuring I prioritise work items that I enjoy over the slog of the next item on the to do list were great aids to my mental health and wellbeing. But the most impactful one was definitely wiping all work apps, including email, from my phone.

 

In the midst of my return to work, I also had a conversation with a mentee who was considering installing works apps, including email on their phone. Over the years I’ve had many of these conversations with recent graduates, and each time they make me think about how keen we are to plug into the matrix of work before considering the consequences. Here I share the drivers that caused me to refute Bring Your Own Device, or BYOD, as a productivity driver, and share tips and tricks to help you decide whether unplugging from the work Matrix will work for you.

 

Why Do Fools Fall in Love?

 

The tale of how I came to be plugged in is probably an experience shared by many engineers in their initial rise through the ranks. I received my first dedicated work handset a few months after starting after a late night in the office monitoring report submissions. At this time, it made sense as it allowed me to monitor from home without needing to login from the office, or even connect remotely from home.

 

When the company adopted BYOD a few years later, it seemed like a natural thing to immediately adopt since I was used to having some connection to work. Despite discussion with a good friend about their decision to not adopt BYOD on returning their device, I decided to keep my access. At this point I had formed the bad habit of checking emails on my commute and at home in the evening, much like many others as discussed in this piece from 2015. I told myself it helped me see what I would face the next day and form a plan of what I needed to tackle when I made it to the office.

 

Mum Juggling Phone and Baby

In hindsight keeping an eye on work emails through maternity leave was probably not very healthy!

 

I even continued this pattern while on parental leave. I told myself at the time that it was a useful means of keeping connected to the project to which I would be returning. I listed it as a valid learning mechanism for keeping up to date. It also formed my opinions about email as a bad medium for software alerts, which I reflected on at the time, as I found test environment alerts flooded my inbox making it difficult to find useful content. In hindsight, I now consider it more to be a symptom of FOMO and fear of being forgotten by my team. Especially since I was moved project on return to work, the time does feel wasted.

 

When the pandemic hit, I added our chat app to my phone to ensure I was contactable at times where I was looking after my son. I’m sure any parents reading will remember the challenge of that time. I found this constant connection contributed to a rather nasty burnout in December 2020. I have vivid memories of one lunch time where my phone was buzzing off the table with messages from my team to try and action an urgent approval while I tried to feed a weaning baby. I also found that many of us as we adapted our work hours around personal circumstances defaulted to using chat apps for everything, leading to notifications late at night for non-urgent queries.

 

Stressed Man on Mobile Phone

Maintaining a work connection on my phone meant I was always on when working from home

 

It was clear to me I was no longer reaping that perceived benefit of preparing for the next day. Instead, it made it difficult to sleep as I thought of the next problem I would deal with in the morning. I had been giving advice to colleagues, graduates, mentees and team members at that time to think about if they should have this connection to work. Yet I never took my own advice through that time. It was this realisation that led me to pull the plug and uninstall all work apps from my phone.

 

Who’s Zoomin’ Who?

 

My story may resonate with you at this point. It may not quite have you convinced. If you fall into the latter camp, you may now be rhyming off the reasons you need to maintain your work connection after you log off. I’ve been there! I found that noting down when and what I did on my phone in a couple of days and compared them to my motivations for having the access, was helpful. I ended up with something a little like this:

It’s worth noting down your expectations versus your mobile work activity to assess if they align

I regularly told myself that I needed to be connected to help plan my working day on my commute, but also to ensure I could support my clients and cover support emergencies as they arose. I now see from the above listing that it had evolved to searching for issues that it became a problem. Or as an attempt to multi-task when I really should have been focusing on picking up the food Mini R was enjoying throwing around the floor. Part of the problem in that latter scenario is since you don’t really have context of the message, you don’t know if it’s ignorable or not. Meanwhile, now that I am only contactable via a phone call, I’ll only be contacted for true DEFCON 1 instances, leaving me time to focus on lunchtime.

 

The other opinion you may have, which many new developers and myself at one time have, is that you don’t have anything else to monopolize your time. Therefore, occasionally checking work while chilling with Netflix isn’t the biggest of deals, and not a major inconvenience on my time. While I do agree that I no longer fit in this position, and now that I have a family my time is more important, I do have some regret of the things I could have used that time for instead of working.

 

Bubble bath with wine glasses

Among other things, I wish I had taken more bubble baths instead of being on my phone

 

Perhaps I could have written more. Or took part in more spare time coding. Or taken many more relaxing baths, which I now wish I had the time to do. Or had more uninterrupted conversations with my partner instead of us both sitting glued to our phone while watching TV. Or even gotten through an extra book or two if I did want to ignore Mr R watching the football. Be more respectful of our time outside of work. Even if it works out at around 47 minutes a day.

 

Constructing the Connection

 

I know I won’t have convinced all of you. I may be lucky if those determined to maintain access to work on their personal devices have even read to this point. New features are available on our phones to help us manage application time more effectively, which either didn’t exist or I didn’t know about when I was a member of the BYOD club.

 

Broken Phone with ERROR 404

These days you will not find any reference to work on my phone, and I’ve never been happier

 

My viewpoint will definitely not resonate with everyone, so if you are in the pro-BYOD camp, I do have some tips to help you avoid some of the challenges I faced before I pulled the plug on BYOD:

 

  1. Think about your role and the potential reasons people may wish to contact you. This can help you triage messages and decide which are DEFCON-1 panic stations compared to the sleepy normality of DEFCON-5.
  2. Avoid blindly downloading all available applications or setting up all media on your phone. Take a moment to think about which applications you truly need to access based on the reasons you have previously identified.
  3. Block out your evenings on your calendar to protect your evenings from calls. This is particularly important for those working for global organisations outside the US.
  4. Set a limit of the amount of time you spend on these apps outside of work, both at evenings and weekends. Try setting usage limits or focus time settings for those applications to enforce your limits. Some apps allow you to do this within the software itself, but Android and iPhone have various wellbeing options that you can use to limit applications, and set do not disturb settings for overnight.
  5. When using these applications outside of this time, be mindful of your own usage of chat versus email for any messages that you send to avoid distracting others. Try to respect the decision of others.
  6. Preferably try to have access free days at the weekends to get a true break from work.
  7. Consider having your phone number available in the company directory or shared with relevant colleagues for true emergencies. This is one that I have kept as a compromise.

 

Irrespective of your choice, no way is right or wrong. I know that having that separation is definitely the right decision for me. I wish I hadn’t rushed into connecting to the matrix so quickly. Together we need to respect the decisions of those who are unplugged versus plugged into work all the time. What is more important that we take care of the wellbeing of colleagues in both groups and be on the lookout for burnout in ourselves and others.

 

Thanks for reading! Best of luck finding the work connectivity that works for you. Do reach out if you would like to share your experience or want to discuss which option may be right for you.

People Power

Reflections From Lean Agile Exchange 2021

As both an agilist and software engineer, I enjoy attending a mixture of conferences. Yet in discussion with developers I sometimes am asked what kinds of topics are normally covered. Or even hear jokes about which methodology won in the battle of Scrum vs Kanban (sigh). Or even asking about the soft skills covered with derision, thinking that the lack of super technical content makes them less interesting.

 

The reality is that Agile conferences cover a myriad of content encompassing various domains, including but not limited to psychology, sociology, agile theory, leadership, testing, software engineering and others. While some may consider technical knowledge to be specific to programming and computer science concepts, I would suggest knowledge in these other domains shows technical expertise. Here I reflect on some of the amazing sessions I watched and presented this year, and what I learned.

 

Uncertainty Still Prevails in our Work and Personal Lives

 

The events of the global pandemic over the past 18 months were very much a theme in many sessions at the conference, including in the opening keynote by Sam Conniff, titled Uncertainty Experts. The reality is that uncertainly also impacts us within our day to day work and home more generally. Sam tells the story about how in the face of difficult personal circumstances he interviewed individuals who had faced significantly challenging times to discover how they handle uncertainty. This is an interesting concept as humans are not really wired to handle uncertainty very well. It’s not just me!

 

Directional Arrows

 

We face uncertainty in our work and personal lives

 

If you are curious, KPIs are business metrics that reflect the performance of the department or organisation. However, OKRs are goals you set yourself to improve you performance and drive the change you want to see. This piece summarises it well that KPIs measure performance and OKRs help you decide what to change or improve.

 

The people he interviewed have been through far more significant challenges than most of us have in our lifetime, including but not limited to prison time, abduction, undergoing gender transition and gang membership. Through these interviews and collaboration and a group of scientists, he discovered the 3 primary factors that affect our ability to handle uncertainty:

 

  1. Through fear we default to automatic responses that have worked for us in the past. These are known as safety behaviours. This interesting fact sheet gives some very relatable examples of safety behaviours that I’m sure all of us have exhibited.
  2. A fog comes over us which stops us from reacting, known as uncertainty tolerance. As a very risk averse person I definitely see myself as having an intolerance to uncertainty.
  3. Conviction Narrative Theory enforces a level of stasis in us which leaves us struggling to adapt to the current situation.

 

Sam has since collaborated with scientists to produce an interactive documentary to help participants build resiliency when facing uncertain events. I’m definitely interested to see the impact as building resiliency following a bad case of burnout in 2020 has been a focus for me in 2021.

 

Our Bad Questions Impact the Response We Receive

Collaboration and communication are required elements for working in software development teams today. From some coaching training I’ve attended in the past I know that we need to embrace open questions to give people the space to speak their mind. However, through Priya Sinha and Ragan McGill’s session I discovered there are other types of questions that could be impacting the responses we get.

 

In Seven Sins of Questioning, they cover 7 other question types that we should avoid in our communications:

 

  1. Question Stacking where we ask all the questions at once in a large brain dump. I see many people, including myself, resorting to this tactic.
  2. Leading questions that you ask assuming the other person is wrong. These can come across as arrogant or annoying.
  3. Why questions that put people into a defensive mode. I see these are commonly asked when things go wrong, and thinking to Mehmet Baha’s session on Psychological Safety, could impact the ability of a team to perform intelligent and improvable mistakes that we can grow from together.
  4. Dirty questions that carry a subtle bias, but don’t carry the message that the other person is wrong. A good example is where your question implies an action.
  5. Binary questions where responders can only answer yes or no. There are many shared of grey in this world, meaning that most of the time the answer isn’t simply yes or no.
  6. Self-affirming questions. These are often binary, but carry a special motivation to coerce agreement.
  7. Aggressive questions that provoke people to make assessment about the future before they are ready. The speakers recommend using the Present, Past, Future framework as an alternative to this approach.

 

We are all guilty of asking these types of questions. What’s important is to be mindful of these questioning antipatterns, and avoid them where we can to ensure respectful communications with colleagues.

 

We Should Embrace Being Blocked

 

Handling blocked work items is not specific to software development practices, but it does cause us all pain. Perhaps it’s down to the impact of interruptions on flow state, which is a rather unique construct of programming. I found an old article that suggests it takes an average of 40 minutes to resolve a blocker. This does overlap slightly with a recent talk given at Devoxx UK on the developer experience, which I’ll share my thoughts on soon.

 

The importance of being blocked by Nick Brown rightly points out that we become blocked for a variety of reasons. While I assume the aforementioned 40 minutes concerns factors within our control, such as breaks to search an error message, or perhaps struggling with our tooling, organisational dependencies are also a factor. Particularly for those working at larger enterprises where we can perceive particular procedures and bureaucracy to be unnecessarily hindering our productivity. I’ve been there!

 

Women With Hand Up

 

Embrace being blocked!

 

I agree with Nick that most teams do not have a consensus on what blocked means or how to handle blocked work. This observation mirrors my own experience of using obstacle boards a few years ago, which I presented at LAX 2020. We found that by using an obstacle board for data integrity impediments that team members therefore only considered those types of impediment to be suitable for capturing, and failed to adapt it to include other elements that blocked their work.

 

We’re naturally conditioned that if we get blocked on something, we keep busy and move on to something else, which can be a bad idea. I was reminded of this only this morning, where I logged in to see 1 column on our Kanban board was breaching the item limit. Even a glaring red state can be ignored in our pursuit to be productive. It’s important to enforce limits, and focus on clearing these states together.

 

Technical Debt Is Difficult to Define

 

Einar Host’s session Technical debt isn’t technical was a session at the top of my watch list when I pulled together my initial list of talks I wanted to attend ahead of the conference. I find we struggle to agree a common definition as to what technical debt is. Discussions and debates with colleagues over the years show it is a wide ranging term, where we consider troublesome parts of the code, potential refactoring(s), infrastructure upgrades, architectural transformations and even regular library upgrades to be potential technical debt. Even at conferences I have similar discussions with individuals working at other technology firms, so no organisation is immune to this debate.

 

Meme

 

Rather than an amusing picture and text combination like this, the original definition of meme, or memetic refers to a term that has become ingrained in the collective consciousness

 

Einar interestingly refers to the term technical debt as a meme of sorts. Rather than an amusing picture and text combination like this, he is referring to a term that we have unconsciously picked up without realising it. In 1999, the Los Angeles Times likened these ideas as a kind of virus that is propagated through the population irrespective of it’s truthfulness or adherence to logical principles. I do agree that technical debt has become such a term, leaving us unable to determine it’s true meaning or origin. I’ve also found many terms in my time from both the technology and finance domains that people know and rhyme off without knowing the true definition. A key one from my first week as a graduate engineer was Defined Liquidity Group, which people used without thinking. Anyone who is curious about what a DLG is can check out this overview from the FCA.

 

Einar summarises that the definition of technical debt is that horrible spaghetti code containing many logical branches. His story from his own employer, a Norwegian TV company, definitely proved feed for thought for me. The different types of TV shows and their varying consumption methods, such as the news compared with a series compared with a docu-series, reminded me of similar issues I’ve seen in my time. Not only will you struggle with these as the system grows, but it will be a nightmare for those looking after your system in 10+ years time. I’ve been on the receiving end of both of these scenarios and neither are pleasant!

 

The Different Between KPIs and OKRs is Often Confused

 

I’ve struggled with the difference between KPIs and OKRs myself. Cansel Sorgens had a great talk on this, using her own experience of building her own OKR coaching and training function to explain the difference. The session was very interactive, with some polls to show the differing understanding in the room.

 

Dashboard Charts

 

Think carefully about the KPIs and OKRs that you track

 

If you are curious, KPIs are business metrics that reflect the performance of the department or organisation. However, OKRs are goals you set yourself to improve you performance and drive the change you want to see. This piece summarises it well that KPIs measure performance and OKRs help you decide what to change or improve.

 

The Spotify Model Exists But Is Often Implemented With Antipatterns

 

I was really interested to see the keynote So you copied the Spotify model – here’s what you got wrong as a variant of the Spotify model was the transformation technique used by my current employer. Joakim Sunden was an Agile Coach at Spotify for many years, so I felt these insights would come from someone who had been there, done that, got the t-shirt. That was indeed the case.

 

In my own experience I already knew that we had adapted the model. I was also not surprised to hear his sentiment that many organisations exhibit many antipatterns in their adoption of the model. I’ve definitely seen many of them applied in practice, most notably using chapters to represent reporting lines. In my personal experience, organisations use this to mirror their existing structure over more radical change. It also leads them to struggle to reflect the technical disciplines that it should represent, leading to confusing jargon that tries to cover both bases.

 

Comic Agile Spotify Model

 

A common antipattern of Spotify model role-out that I’ve seen is keeping the existing department structure but changing the names

 

While I’ve not used SAFe, this was also discussed as having some questionable adoption. Speaking to colleagues and family I’ve seen SAFe applied without much thought, leading to teething problems. I find putting scaling frameworks directly on top of an organisation without attempting to foster the collaborative and psychologically safe culture leads to much distress and frustration for people. His advice to identify pockets in your organisation that are adhering to the target ideals, and considering SAFe as a toolbox of techniques that don’t all have to be applied resonated strongly with me.

 

Loneliness and Bonding Affects Our Performance at Work

 

Emily Webber’s keynote The Magic of human Connections focused on just what the title states, which reflecting on how the pandemic has negatively impacted our ability to establish those connections. I was rather surprised to find out that loneliness impacts our performance at work. Thinking of my own experiences over the last year I do see that aspect in my performance, where as 2020 rolled on and I felt more isolated, I struggled more at work. She also highlights the are 4 key elements of modern teams that can increase loneliness:

 

  1. Moving people in and out of teams
  2. Encouraging segregation of duties which can leave people feeling interchangeable
  3. Moving people to temporary secondments, or splitting their time between teams
  4. Establishing short-lived teams to work on temporary projects

 

I hate to say that I’ve seen all of these antipatterns applied. Not only applied to myself in contributor roles from managers, but I’ve also performed the same sins as a prior manager as well. I definitely intend to avoid such patterns in the future as best I can.

 

Hand on the window

 

Nobody wants to be lonely

 

Bonding within teams was also highlighted as a contributor to performance. People who feel connected to their colleagues feel less lonely and therefore perform. It has definitely been my experience that bonding is important for establishing and resetting teams, as I outlined in my own talk Confessions of a Sprint 0. People need to feel they belong to a community of sorts. I loved Emily’s story about setting up random coffee matches within her Agile In the Ether community as it shows a great way to expose people to serendipitous connections.

 

Final Reflections

 

Yet again I felt that I left LAX with more insights than I entered. There were so many other lessons that I learned at the conference, to the extent this blog could probably be double the length. So instead I encourage you to search for the videos when they are available on Vimeo in a month or so. Until then, consider a question we were all left with at the discussion session Shifting ways of working- what have the last 18 months taught us?. I am still asking myself How do we look out for those struggling who are not raising concerns in our organisations? I leave that for you, dear reader, as some food for thought.

 

Thanks for reading! Looking forward to (hopefully) attending LAX again next year.

Coming to the Stage

Comparing In-Person and Online Meetup Lightning Talks

I hear the buzz of murmurs for an excited crowd. The sound of glasses and beer bottles clinking as strangers meet and introduce themselves hums behind excited conversations. Heat from the lights and projector hits my face. The smell of wood from the bar floor fills my nose. A strong feeling of fear resting in the pit of my stomach rises towards my throat.

 

Terrified Woman

Speaking in public is a terrifying prospect for many of us

 

This might sound like the confessionals of a stand-up comic or breathy saloon bar singer. However, dear reader, this is the memory burned into my brain as I took to the stage for my first ever in-person meetup talk. My symptoms sound rather like those of a fear of public speaker, just as Deborah Frances-White outlines in her amazing TEDx Talk on stage fright. Deborah shares a great theory that fear of public speaking stems from our survival instincts, and the need to avoid being lunch. You might think this is not the biggest deal. It was a ten-minute lightning talk. Hardly an escape from a pack of lions!

 

Yet for me it represents a major milestone in my continuing speaker journey. I started dabbling in technical speaking just over a year ago, through the global pandemic. With many meetups and conferences taking place online through that time, all my experience is based in the online world. Often, I would stand in my spare room, talking at an empty screen. That is vastly different to the in person experience I have just described.

 

In the hopes of dispelling some fear and myths of those others who, like me until recently, have only presented online, I regale the experience of my first in-person meetup. I will discuss the key differences between these two formats. Finally, I will give some useful tips to help you prepare to step out into the physical spotlight and give your first in-person talk.

 

Back Stage Pacin’

 

Despite having given a longer version of the same talk at a couple of online meetups, I still felt exceptionally nervous ahead of this first engagement. Part of the reason was down to going to a new meetup, with a lack of familiar faces in the audience. Poor Mr R was subjected to two practice runs in twenty-four hours as I tried to prepare and adjust to the altered talk flow.

 

Those same nerves did not disappear on the train. As you can tell from the below tweet. Instead, I tried to think of the advice I have heard from many fellow speakers that nerves never go away, and that it is simply a case of embracing them.

As you can see from my pre-event tweet, I was feeling pretty nervous!

I got chatting to a couple of people when I arrived, which was a welcome distraction. When the time came for the session to start, I grabbed a seat at the front to make it easier to step up to the stage at my slot without worrying about tripping over others, or indeed my own, feet.

 

Speaking to a new group of people when you are establishing yourself contributes to your nerves. While waiting your turn in a group of speakers can build up your fear, when new to a setting it can also help you get a feel for the audience, as well as being useful for picking up presenting tips. Thankfully, I was one of Five speakers that evening, and the last to go. This gave me the opportunity to see how chilled out and welcoming this group were.

 

Stage Fright

 

Taking to stage felt like a surprisingly natural thing. Most likely my brain telling me this is the same as all the online talks you have given to your laptop before. I could not employ the trick of speaking to the friendly face because, not to say that this audience were not friendly, but they were strangers to me. So, my focus point tended to float around the audience to prevent me uncomfortably staring at one person for the entire talk.

 

Woman on Stage with Microphone

It is far easier to gauge the interest of the audience as you speak when you’re in front of a live audience, compared to black boxes on Zoom

 

One of the key advantages to speaking in person if you gauge the interest of the audience as you speak. With online talks, there is a great disparity in the level of feedback you get as you are speaking. Depending on the audience and tooling of choice you can be speaking to boxes of nodding heads, black rectangles, or even a black void in the case of Webinars.

 

In person you can determine the reaction to segments of your talk. I discerned the nods and smiles as showing acknowledgement of a potentially insightful point. Laughs meant that joke I made landed well. Even the one about hurrying up so we could all get to the bar seemed to get a small chuckle! Thankfully I did not see anyone screw up their face in offence or derision, so no controversial points seemed to have been made by myself thankfully!

 

Person Asking Question with Raised Hand

In my experience, answering questions are a common attribute to both types of meetups

 

One common attribute shared by in person and online talks is post-event questions and feedback. Online meetups normally include a few minutes for questions after a talk that can be asked directly or via the integrated chat feature. In person, while there was no Q&A segment, people were happy to approach me afterwards with any questions they had. I even got some great suggestions on how to improve my slides by a fellow speaker, for which I am incredibly grateful.

 

Online, I have found that feedback is normally submitted afterwards in forms or in the integrated chat. I have always enjoyed answering questions and using those perspectives to inform future talks. It was reassuring to find that common trait between these two formats.

 

She’s Still the Star

 

Overall, I found that many aspects such as questions, nerves and support are very similar between online and in-person meetups. Given that many in-person meetups have spawned from a need to move in-person sessions online to meet the needs of their communities, this makes a lot of sense. Online communities are very accessible to people who need to be home in the evening for caring or other commitments, and there is still a need for both formats as the state of hybrid working evolves.

 

Bar conversation over drinks

In person meetups allow for organic conversations over a drink, which are missing from online forums

 

Nevertheless, one element of in-person meetups that I do not feel has been replicated successfully are the conversations you have after the talks are over. Talk questions organically morphed into full conversations into technology, best practices, and career experience. I have seen attempts to replicate this practice with post-event breakout rooms.

 

The unfortunate reality is that most people will head off from an online meetup as soon as the meeting closes. It is almost as if working remotely has morphed these jovial encounters into another meeting slot. I hope in time we will come to figure out how to integrate the social element into online meetups to preserve their accessibility.

 

All the World is a Stage

 

Overall, my first in-person meetup experience was a positive one. Much like the online communities I have spoken at, the audience wants you to succeed. I am not the gazelle that this pack of hungry lions wants to eat. They are actually more interested in pacing around the bar after I speak in search of a libation.

 

Audience With Love Heart Hands

Meetup audiences, unlike a pack of hungry lions, want to see you succeed on stage

 

I am glad to have participated in this exercise. It serves as good practice for my next in person speaking engagement for when conferences resume. I am hoping to speak in person at Devoxx UK in November, assuming in person goes ahead. I am so excited to have that opportunity. This first in-person experience has been a good starting point focusing on a smaller audience, that I hope to build upon in future.

 

Thanks for reading! Do share your own experiences of lightning talks, in any format. I would love to hear how you get on!

Let The Record Show

Confessions of Creating My First Pre-Recorded Conference Talk

Recording yourself is hard! Recording yourself is downright uncomfortable! Nevertheless, with us all working from home for the past year it has become a more common format for conference talks. Live talks are still happening, and for tips and tricks for that format I recommend you read Helen’s amazing blog post on the topic.

 

Up until now all the talks I’ve given have been over Zoom. Despite those all being recorded, I’ve only once had the nerve to watch myself back. I’ll be honest, it was not comfortable.

 

Microphone

Recording your first pre-recorded talk feels just as intimidating as standing in front of the mic for the first time

 

I recently had to record and edit my first talk. I made a lot of mistakes while doing it. And many of them seem completely daft now! Through sharing my Confessions of a Sprint 0, I’ve also uncovered a new set of admissions relating to the challenges of recording my first talk, and more mistakes that I have made along the way. Here I regale the lessons I’ve learned, as well as some right daft tales of getting your first recording wrong, to ensure that your first recording experience goes more smoothly.

 

What Makes These Talk Types Different?

 

In my continuing speaking journey, I have been fortunate enough to have given talks at various forums including speaker groups, meetups and one online conference. I have observed that there are several key differences between live and pre-recorded talks that make them more difficult to prepare for:

 

  1. It may sound obvious, but they are due earlier than the conference. This means you need to be slightly more organised about preparing for the upcoming deadline.
  2. There are stricter boundaries between the speaker and the audience. This can make projecting your natural energy and authenticity difficult.
  3. It will take a lot longer than you expect to prepare. In addition to the recording, you’ll also need to spend time editing the recording as well.
  4. Speaking of editing, it may be the case that as a new speaker that you don’t have any editing experience. You’ll also be unlikely to have any editing software installed on your machine. I fit into both of these camps!
  5. Using some formats and mediums are no longer available. Techniques such as polling are not possible unless you ask the organisers to incorporate a live element at the start.

 

Tips and Tricks

 

Despite these challenges, I do have some tips that will help you pull off looking like a pro-speaker, even when recording at home.

 

How to Show Genuine Energy

 

As you can imagine, talking to yourself is pretty uncomfortable. It’s easy for that energy to translate badly in a recording. Even someone as bubbly as myself came across as flat when I did my first recording on my own. I was so unhappy with that version that I re-recorded the entire thing again before editing.

 

When giving a talk, you want to come across as genuine, and project your natural energy. I found practicing a few times before you even start recording helped me settle the nerves and find my flow. I did have simple notes up on the screen for each segment to keep track of where I was. However, I recommend you avoid running through a fully written script unless you are confident it won’t sound flat.

 

Man behind the camera

It’s difficult to show energy to an empty room, but there’s nothing stopping you having some moral support hiding behind the camera

 

No one really said you had to speak to just the camera. It is possible to try and elicit help from a friend. This individual could either join muted to a video call that you are recording. Or, in my case as my helpful husband did, stand attentively behind my laptop, so I could look like I was looking at the camera, but was speaking to him instead (thanks honey!).

 

How to Record Yourself

 

There are two key themes you need to be mindful of when recording yourself. The first, and hopefully more straightforward item, concerns the software itself. You can easily use the default camera app on your PC to record. However, if you need to apply a background for the conference, or in my case blur the background since my curly hair interferes with the background, you’ll need to use alternative software.

 

With us adapting to working from home through the global pandemic, we have had to acclimatise to video meeting tools such as Zoom or Microsoft Teams. Zoom specifically has a recording function, which can also be used with the free version. Simply join a new meeting, setup your background or blur, and hit the big recording button.

 

Recording Sign

Consider your recording plan before you start recording, but it in parts or as a single run

 

Before you hit the recording button, take heed of whether you want to record in a single run or in sections. I initially took the advice to record my talk in batches, and split it into sections of a few minutes that would fit with my transitions and section slides. For me personally it didn’t work for several reasons.

 

  1. Trying to record segments between meetings meant I didn’t have continuity of lighting through the recording. So be mindful that the segments need to be recorded at a similar time of day.
  2. I would psych myself out when I made a mistake, meaning I would try again and get into a loop of making mistakes. Before you ask, I’ve now deleted the bloopers reel so unable to share these. Sorry, not sorry!
  3. I would cut at the slightest mistake, rather than accepting the imperfections that show my humanity and leave them in. This meant rather than having a perfect video I would have loads of continuity issues that I had to address through transitions. It would have been better to keep the stutter over going from wide smile to concentrating brow in a single frame!
  4. I struggled to keep to time, since I was recording in segments. This resulted in a far longer talk than I wanted. Editing the recording to time without introducing continuity errors was impossible.

 

In the end, I took the advice of my conference mentor and recorded the talk again in one take. Thankfully, since it was 15 minutes long I could do this. For talks longer than this I would try to break it into 10 minute chunks, that I would time, and included transitions to address the continuity issues. Also make sure to add a buffer of at least 1 minute to ensure you don’t run over. I would also add in transition time on top as I just squeezed in at 30 seconds under time when this was taken into consideration.

 

Editing Tips and Tricks

 

Unlike some friends and colleagues that have experience of video editing from their side hustles, this was my first time doing any form of video editing. Whenever I’ve had to record sessions in work, I tend to air on the side of hitting upload. Mainly because sessions included Q&A segments where I wanted to share the questions and answers. But there was also a part of me that dreaded watching myself back and saw a direct upload with "Och it’ll be fine!" to be a way of avoiding an uncomfortable experience.

 

Watching yourself is hard! You’ll spot imperfections like your hair being out of place. The non-mirrored view may be rather confusing. And you will not be able to stop yourself wondering "Wow, do I really sound like that?!". Although many have told me it gets easier over time, I’m still not quite there yet. And when you’re having to watch segments over again to try and perfect alignment with slides or to add in transitions, it becomes and even more uncomfortable experience.

 

Person editing a video

Watching yourself while recording can be quite an uncomfortable experience

 

What will help with the discomfort is trying to avoid editing excessively to make yourself sound perfect. Editing out ummms, brief stutters and embarrassing moments when the dog walked in or the doorbell rang can have a negative impact on your continuity when cut.

 

We’re often given feedback in presentation workshops that ummm is a bad word, that should be avoided to achieve presentation perfection. The reality is the occasional one is not a big deal. We’re all human after all! Embrace the occasional imperfection in your recordings and focus instead on ensuring continuity of flow, particularly when it comes to hand gestures and positioning.

 

How to Produce a Quality Video

 

Editing my first recording was very much a learning experience for me. I was fortunate to attend a workshop that gave some tips on recording and editing. Examples were editing using Camtasia, and it initially looked very simple. But upon seeing the high cost, and not having any other need for editing software, I began scouring the internet looking for a free alternative.

 

Free trials for many popular tools, and some other free to use tools were out as they added a watermark on the video. You definitely don’t want a tool watermark in your for a conference recording! I settled on OpenShot, an open source editing tool that doesn’t add a watermark.

 

I had to redo my edit a couple of times as I dived straight into editing my video after watching a couple of tutorials on YouTube. Looking back on the experience now, I wish someone had shared the below tips with me.

 

Managing Layers

 

Firstly, try and keep each content type on its own track. I found it helpful with ensuring transitions between my section slides and video segments were clean. It also helped prevent situations where the accompanying slide hid my video, especially in the segments where I am visible at the bottom corner of a slide.

 

I had a slides layer, a video layer and a section transition layer to keep myself right

 

Splitting Video

 

There will most likely be small cuts that you need to make. One possible reason to remove segments is to eliminate trailing segments at the start and end when you’re pulling your concentration face to find the start or stop button. Another reason could be removing segments to meet time constraints or that must be removed even to keep with our not so perfect ideal. Or even just splitting video segments apart to make transition management easier.

 

Most tools, including Open Shot, have a paddle that allows you to forward through segments. From this point, you can select the video segment you would like to cut, right-click and select the slice option. You will be able to keep both sides, or just the left or right as you can see from the screenshot.

 

You can slice video segments and keep either one or both segments

 

Separating voice and video may be something you want to do if you have busy segments such as animations or content showcasing an interactive workflow. I initially experimented with this technique, which is very simply in most video editing tools. If they are anything like Open Shot it’s a case of right-clicking the video segment you want to split, selecting one of the separate audio options (most likely single channel) and deleting the video segment to keep only the audio.

 

You can choose to separate video and audio to keep audio only

 

In my case I kept myself on the screen throughout, alternating between the bottom corner and full screen. Ideally you want to present yourself on the screen throughout. It is you and not the slides that are the main event!

 

Slides and Transitions

 

Producing a simple recording of yourself on video with no other content will be far more straightforward. However, to give your talk a more polished look, to show materials or references for the audience to capture, or even to walk viewers through more technical concepts, you will need to add additional content.

 

In my case, I added slides to my presentation to fulfill three objectives:

 

  1. Separate sections of the talk
  2. Showcase key resources
  3. Reinforce the tips and tricks I gave at key points in the talk

 

Camtasia would make slides easy to include as it has a Powerpoint plugin. However, Open Shot does not have such a feature. Instead I had to export my slides as images and import the images to Open Show as project files so I could include them on the desired track.

 

To ensure a more polished finish, you’ll also need to add effects to ensure a clean transition between the video and slide content, or to accommodate any continuity errors.

 

Open Shot allows you to add transitions onto a media element. This is done by selecting the transition effect of choice and dragging it onto the media element which you want to apply it to. I generally found using fade with a duration of 1.75 seconds worked for me.

 

Drag a transition from the panel onto the media to apply it

 

I would also suggest adding the same transition reversed on the other side for symmetry, which can be done by right-clicking the transition and selecting the Reverse Transition option.

 

You can also reverse transitions at the other end of a particular media type for symmetry

 

Video Exporting and Profiles

 

You might think that once you’ve gotten past the challenges of editing and watching yourself repeatedly that the hard part is over. However, there is one gotcha left that rather badly caught me out. It concerns editing and exporting profiles.

 

Conferences will specify a format to provide your talk, most likely MP4. But there are various different profiles that correspond to that format relating to size, pixel density and frames per second of the video.

 

Initially I found that my recording audio had a 1 second delay compared to the video. It turned out I needed to specify the same export profile as the profile in which I edited the video.

 

Look for something like Choose Profile from the File menu, which is exactly how it is made available in Open Shot. The same profile should be selected in the export dialog, accessible using the Export option under the File menu.

 

Check what profile you are using while editing…
…matches the export video profile

 

Closing Comments

 

Looking back now, recording my first talk was not as stressful as I thought it was going to be. Setting yourself slightly earlier deadlines and checkpoints, just like any work deliverable will give you additional time to try and redo any segments that you later decide are not quite right. If you are representing an organisation that would wish to view the recording before it is sent, also factor that time into your deadlines to ensure you’re not late submitting your talk to the conference.

 

I hope that by sharing my experiences of my first pre-recorded talk that you will feel better prepared for your own. In addition to the guidance I’ve outlined here, I strongly encourage you attend any support session the conference runs to help you with recordings. Also ensure that you read any recording instructions the conference gives you prior to hitting the record button.

 

Thanks for reading! Do share how you get on with your own pre-recorded talks. I would love to hear how you get on!

The Great Impostor

Tackling Tech Impostor Syndrome

When we were young, we relished the opportunity to pretend to be someone else. Perhaps you were a fan of playing astronaut. Or pretending you were a wizard at Halloween when you were wee. Or later when you pretended to be older and more grown up to sneak into an older rated film. Don’t worry, I won’t judge!

 

As professionals we lose that joy. In our current roles, being someone we think we are not feels far more stressful. As does striving towards the dream roles that may appear out of reach. Rather than enjoying the escape, we feel like an impostor who will eventually be found to be engaging in a campaign of deception.

 

Venetian Mask

Many technologists feel they are hiding in wait of the mask being listed and them being discovered to be inadequate

 

Irrespective of whether you have experienced it first hand, or are comfortable stating openly that you have, I’m finding that the majority of people working in tech and finance today have heard of impostor syndrome. A study taken in 2020 by professional community Blind, found that 62% of surveyed tech and finance professionals fear that people will find out they are less intelligent or capable at their job. That’s potentially a lot of people feeling inadequate in their role. If you are unsure if this applies to you, you could try this quiz.

 

Through my own career journey, including breaks from active software development for maternity leave and roles in Scrum Mastery and tech management, I’ve found there are points where the presence of that lurking impostor feels more prominent. Speaking to others has only reinforced that opinion. Here I discuss the times where impostor syndrome can be particularly hard to manage, using my own and others experiences, and some learning tips to help silence the faker.

 

Don’t Let the Sun Catch You Crying

 

Part of the problem with the tech sector specifically is the high rate of change can make getting started and catching up feel like an impossible task. This amazing piece by Helen Scott presenting the evolution of Java over 20 years shows how intimidating it can be to get back into well established technologies. We must also be mindful that in the Web UI domain where I work, there has been an explosion of frameworks over the last 10 years, which can make your head spin! It is no wonder that any break from being technically hands on can make the idea of getting back out there an exceptionally daunting prospect.

 

Mountain

Regardless of whether it’s been 2 or 20 years away from a technical role, getting your hands dirty feels like an impossible summit to climb

 

You may assume from the above that I’m only talking about a traditional career break. However, that is only a drop in the ocean. Through my own experiences, as well as chatting to others, I’ve identified numerous other individual circumstances that could be a potential target for that sneaky impostor demon.

 

  1. Transitions between technical, product and people-focused management positions.
  2. Agility focused roles, including but not limited to Product Ownership, Scrum Mastery and coaching.
  3. New graduates taking their first steps into the world of technology who may need to use new technologies and techniques not covered in their degree course.
  4. Interns, placement students or apprentices gaining their first experiences of work while studying at university.
  5. Long term sickness returners.
  6. Maternity and parental leave. Not all new parents in the world have the luxury of much time off with their new arrival, so I would also include those trying to balance sleepless nights with a transition back to work in this category.
  7. Gaps for travel or any other personal voyage of discovery.
  8. Career transitions to new domains, or even for those starting up their own business.

 

Managers and leaders, do take note of the above demographics as people to watch out for who may need some support getting back up to speed. As a supporter of these individuals, you can help them find time and space to gain their tech confidence back through learning.

 

The Sun Will Shine Again

 

There are many resources out there from experts that look at how to address impostor syndrome. Doing some quick research for this piece, I found there was a common theme to their advice.

 

  1. Remind yourself of past successes and achievements.
  2. Celebrate present wins, irrespective of how small you think they are.
  3. Adopt a growth mindset, to help you accept setbacks and continue to press for successes.
  4. Take solace in knowing that you’re not alone. Think of the your role models who openly speak about their own experiences with impostor syndrome.

 

Man celebrating success

Celebrate every win, even if it’s as small as finally getting that Gradle build working!

 

With tech imposter syndrome specifically, it’s also about building the confidence to try again. Just like any learning journey, the road to making piece with this demon is filled with successes and failures. Ultimately you need to remember that your skills that helped you leaning technology X or even how to code the first time around are still relevant. You can try some of these tips to help manage the journey:

 

  1. Set some small learning goals and build up. Even something as small as raising your first small pull request, or completing a small problem in challenges such as HackerRank or Advent of Code can give a much needed boost to your confidence. It certainly did for me last December!
  2. Dedicate a regular time slot to brush up on old concepts or to learn something new that excites you. I received this great tip from a colleague who used a regular evening slot to juggle interview preparation and family life.
  3. Elicit support from your manager to have dedicated learning time during work hours if you can. Historically as a Scrum Master or Team Lead I found myself repeatedly wondering why people never blocked out time for learning in their calendar. Or why there were no scheduled team knowledge shares. On reflection I could have done more as a manager to adjust capacity to accommodate their training time, therefore giving them the space in their calendar.
  4. Experiment with different formats to try consuming information in a different way. For me, and some others I have spoken to, listening to a podcast while cradling a sleeping baby or folding clothes is accessible. You can find out more about my own experiences comparing my work and maternity leave learning preferences here.
  5. Seek feedback from managers and mentors on your progress. This week, as I was banging my head against the wall when something wouldn’t work, I thought I was a complete failure. Chatting to someone you consider knowledgeable on how they think you are doing may highlight a discrepancy between your own performance perceptions and the reality that others see.
  6. Embrace your non-technical skills as strengths. Many consider coding or designing immensely complex software architectures to be the pinnacle in technical expertise. But the soft skills and other pools of knowledge you still possess are just as important to maintain.
  7. Be kind to yourself and embrace breaks. Setting aside regular time for practical coding with some circumstances such as illness or a newborn may not be accessible to you right now. That’s ok!

 

Best of luck with tackling the tech impostor!

 

Thanks for reading! Do reach out and share your own experiences of and tips for tackling tech-focused impostor syndrome. I would love to hear them!

All Together Now

Reflections on Our First Mob Code Review

Two heads are better than one. Indeed that is commonly the term used to justify various paring and collaboration efforts. Including the deceptively contentious topic of pair and mob programming. Diverse thoughts and opinions can come from individuals from diverse backgrounds, with diverse thoughts and experiences, and at different stages in their career and stage of development.

What about three heads? That is indeed the question I was pondering ahead of a recent mob review. I’m certainly known for my slightly odd ideas. This latest hair-brained scheme was a recent attempt of mine to correct some worrying patterns of behaviour being exhibited as part of regular UI code reviews.

 

Three headed statue

None of us have three heads, so we rely on collaboration with others to obtain the best solution we can

 

I have since moved onto a new team. Yet the story of our first mob review is one story that I am eager not to have remain untold. Here I regale the tale of using a mob review to educate myself and other developers in review standards and best practices, and how they can be used as a health check for team review behaviours and psychological safety.

 

Part of the Queue

 

Like many great tales, this story begins a little further back than the actual event. It starts with a queue. A queue of rather large UI code reviews that appeared suddenly a few days before the end of the sprint. Of course one could immediately comment on sudden work bursts, suggesting how work tasks should gradually tick down with developers raising small regular requests to ensure regular integration. I certainly raised that very point rather quickly. However it was the next step which defines the turning point in our story.

 

In the interest of evaluating a raised concern that UI peer reviews were not approved as quickly as backend service reviews, I waited. I waited eagerly to see what feedback would be bestowed upon these solutions. I waited avidly for the green tick celebrating an approval and merging. Yet what actually happened was…

 

Queue of shoppers with trolley

Queues may be a part of pandemic life, but regular queues of large pull requests is a warning sign that small regular reviews are not being raised

 

Nothing. The backend service requests were reviewed in a perfect swarming formation. Interestingly the UI reviews were left outstanding until I weighed in with either commentary or an approval. If I wasn’t concerned before about the expertise hole I would leave behind upon moving to a new team, I certainly was now. I’m not proud to say, but I was also feeling the effects of review fatigue after spending the majority of three days reviewing gargantuan pull requests. It’s not just Zoom fatigue we need to worry about working remotely!

 

When two more requests appeared the next working day, I felt it was time to understand this review reluctance plaguing the UI codebase. My working theory was the lack of experienced UI expertise that has been a challenge experienced by not only this team, but the wider group for several years.

 

A Little Less Talk and a Lot More Action

 

Team dynamics was also an issue. A culture supporting pair programming still doesn’t really exist. This has been partially manufactured through a combination of distributed teams and a lack of dedicated tooling for collaborative programming. The deliver at all costs ethos pushed by the wider group also doesn’t help. However, it’s also due to the preferences of some engineers to work alone and just get stuff done. Not everyone is geared to the pairing style.

 

Code with cuddly toy elephant

Like pairing with humans, rubber duck (or cuddly elephant) programming is not for everyone

 

I knew that leaving this issue to persist would have a detrimental impact on team productivity and code quality. Mainly because I was moving to a new team and could no longer provide dedicated review time as often. However, it is also that I realised that I had become the gatekeeper for changes, which is not healthy! Rather than continue having pair reviews with individuals, it was time to shake things up with a mob review.

 

Come Together

 

One morning on our standup the number of open PRs was raised as a blocker. This was my cue to strike. When discussing blockers after updates were finished, I asked how comfortable others were reviewing UI requests. The mixture of silence and mumbled statements of discomfort validated my assumption.

 

I invited everyone to stay on the Zoom meeting post-standup where we would conduct a mob review. For those unfamiliar with the term, this involves walking through an outstanding request and discussing the feedback in a group. This is far more collaborative than our normal async structure of raising a review request and pinging the team chat to notify others of the request.

 

After a few staggered drop offs we were left with myself and two others. Perfect, a trio review it is! We simply opened the PR within the portal and started talking. Bitbucket is our tool of choice, but many others are available.

 

Quiet child with hands over mouth

I found the best thing was to try to limit my contributions to questions to ensure others could speak their mind, which is easier said than done

 

As the more experienced engineer, it can be easy to overpower the situation and simply give feedback and note it down in the tool. What worked well in this situation for me was to ask some questions about segments to hear what others think. This method worked well as it gave everyone irrespective of experience a chance to share their views comfortably.

 

Another useful element was to be mindful of giving balanced feedback. As I have covered previously on my piece on UI code review best practices, developers learn from both positive and negative feedback. Actively calling out nice elements of the design and implementation in this review was a great entry into discussing alternative approaches and their trade-offs in a friendly forum.

 

On the Sunny Side of the Street

 

There were two key benefits that came out of this session. Firstly, discussion on usage of null and undefined enabled us to agree a convention for our team that could be documented in a set of UI review guidelines to help communicate our standard to new joiners, and encourage consistency across our many modules. Rather than it being mandated by myself, using the collective opinions of all to formulate these conventions establishes a shared ownership model that they can continue after my departure.

 

The second benefit luckily proved to be the intended myth-busting effect. By engaging in discussion rather than pushing my agenda, I managed to clear up an assumption by a colleague who was new to the team that reviews had to go through me. I was happy to hear that this discussion gave them the confidence to hit the approve button and provide comments in future PRs. All experience levels can contribute meaningful feedback to a review, be it async, pair or mob style.

 

Teacher at the blackboard

Learning experiences come from peers at all levels, not just the teacher at the front of the class

 

I’ve had the opportunity in my almost 10 years of experience to learn from not only those further on in their careers, but also those just starting out. While pair programming would be the preferred mechanism for sharing opinions and writing code in a more collaborative style, embarking on shared reviews and discussions is a great alternative where pairing is not possible.

 

Get Yourself Together

 

If I have inspired you to give a mob review a try, consider the following best practices which worked for me on this occasion:

  1. Make the review session optional so people can drop to get on with other things if needed.
  2. Consider your tooling carefully. I imagine using collaborative coding tools such as Jetbrains Code With Me or Visual Studio Code Live Share would be great. However, if those are not available a screen share and your existing review tool or IDE will also work well.
  3. Use questions to elicit ideas on what to change rather than imposing your own senior viewpoint. This will better support contribution from colleagues at all levels and facilitate discussion.
  4. Explain the reason for a comment. Explaining why you consider a particular approach to be good or bad helps educate the wider group on your thinking.
  5. Encourage questions. This is a collaborative effort, not a dictation!
  6. Document any agreed guideline conventions that come out of any mob reviews in a shared space. A good example is the Typescript project guidelines which live within the repository.

 

Thanks for reading! Do reach out and share your own experiences of async and mob reviews, or even pair programming. I would love to hear them!

Mix It Up

Experiences Combining BDD Behavioural Specifications with UI e2e Testing

Sometimes in life, two unexpected elements can combine together to form something better. Quite often we talk about two minds being better than one. But this applies to other things too.

 

One key example from music is the concept of a mashup. For those unfamiliar, a mashup is where at least two songs are merged together to produce another track. In 2020 one mashup that caused a storm in the UK was the merging of Dua Lipa’s track Hallucinate with the BBC News theme. Ben Howell’s remix actually won the Remix of the Year in the BBC Radio 1 Lockdown Awards.

I’m not a massive Dua Lipa fan, but I do find this track rather catchy. Do listen if you can!

Inspired by Ben’s achievement, myself and colleagues have been playing around with combining Behavioural Specifications with e2e testing to improve our testing footprint. In this piece I discuss the justification for combining these practices, the lessons we have learned along the way, and provide a simple example showcasing these benefits.

 

My Name Is

 

Before delving into why these techniques combine to be a match made in heaven, let me explain what each of these concepts are for anyone new to these concepts.

 

Blank Name Tags

Let’s get to know these terms a little better

 

Behaviour Driven Development

 

BDD, or Behaviour Driven Development is a practice where new features are discovered by collaborating with business partners and specified as a set of examples that can drive implementation and testing of said feature. It evolved from the Test Driven Development movement.

 

I refer purposefully to specifications being used as part of this mashup very purposefully. What we intend to use in conjunction with an e2e testing framework is the examples, most likely specified in a format such as the Gherkin specification used along with the Cucumber framework. If you are following BDD as a practice, these specifications shall be outlined as part of the formulation stage. There are numerous resources available online that explain BDD as a concept, along with the benefits. Do check out two of my favourite sources from Seb Rose:

 

  1. Seb Rose @ Lean Agile Exchange 2020: Our BDDs are Broken
  2. Smartbear: Understanding the Benefits of Test Automation and BDD

 

End to End Testing

 

e2e, or End to End testing, refers to the ability to test the end user workflow by recreating the product experience from the user perspective. You’re basically testing the entire product from beginning to end.

 

Looking Over Shoulder at Person Using Site

e2e Testing is focused on testing the product from the user perspective

 

Of course with e2e testing there is an argument to be made as to when it is appropriate to connect to the live running services compared to mocked services. I could spend an entire blog talking about my thoughts on when to connect to live running services compared to mocked. Since we are focusing on the basic setup today, the example covered later in this piece uses a hardcoded dataset.

 

Put Yourself In My Shoes

The user perspective aspect of e2e testing is exactly why it can merge with BDD practices so well. Behavioural specifications, such as those we shall write in Cucumber using the Gherkin format, are the examples that expose their view of the product.

 

We live in the age where technology and software are heavily ingrained into our everyday lives. Users of our software are not faceless individuals anymore. If we are not the direct end consumer, we often work within the same organisation with them, as I do, or we are competing with many products to gain attention and revenue.

 

> You never really understand a person until you consider things from his point > of view… until you climb into his skin and walk around in it. > > Harper Lee, To Kill a Mocking Bird

 

To build good products, we need to embrace the comments of Atticus Finch and walk in our user’s skin. By collaborating to form examples using BDD, the documented examples can then be used in your tests. This makes the intended workflow understandable for developers and stakeholders alike.

 

How?

 

There are several different technologies that can be employed to achieve this mashup. Primarily, you need three frameworks:

 

  1. BDD Specification Framework
  2. Assertion Library
  3. e2e Testing Framework

 

This example, available on my personal GitHub, covers usage of Cucumber, Chai and Protractor. The main justification for using Protractor is that it is available with any Angular project created using the Angular CLI. I am very intrigued by Cypress as a potential replacement for Protractor as the expressive language it uses instead of the Page Object pattern looks to be more inline with user workflow than Protractor’s element based syntax. I will happily report my experiences in a future post.

 

Good Example

 

There are many resources that explain in detail how to setup Cucumber, Chai and Protractor. This guide by Amadou Sall is particularly helpful. However, at time of writing with the release of Cucumber 7 and the bundling of the cucumber types, you need to explicitly state install of Cucumber 6. Note that this will be required until Protractor provides support, which was not the case at time of writing. The command is as follows:

 

npm install --save-dev @types/{chai,cucumber} chai cucumber protractor-cucumber-framework

 

Focusing on the tests themselves, there are three file types for a given test that we require:

  1. The feature file containing our examples, or the behavioural specification. This is identifiable from the .feature extension.

  2. The test steps, postfixed by .steps, which lists the implementation of a given scenario step.

  3. Since we are using Protractor, we are adopting the Page Object pattern. This means we have an additional file, containing .po within the filename. It is here that we place our logic for accessing elements on the page.

 

Based on my experience of writing these tests in enterprise software, I’ve found it useful to use the folder structure depicted below. I advise adopting the below folder structure separating feature, test steps and page object files to stop your e2e folder from ballooning out of control. Adopting a component-based folder strategy similar to the Angular implementation is a valid option. Nevertheless, since we are testing the user perspective of the application, we will most likely have any given scenario touching multiple components, meaning this structure is less clear by comparison.

I’ve found structuring the folders in a file type rather than component structure scales better for larger applications

American English

 

Using Cucumber exposes the Gherkin syntax. The power of this syntax is that it allows you to express the user workflow in english-like language that users will understand. Often you should be able to collaborate with stakeholders using the BDD process to formulate their perspective as a series of examples.

The feature file allows you to use the examples elicited
via user collaboration as the scenarios to test against

As you can see from this example each scenario will specify a particular scenario outlining how the user expects the system to behave. Within each scenario:

 

  1. We can set the initial state using the Given line.
  2. The When segment outlines the precise action that you are expecting the user to perform.
  3. Our Then statements show the expected behaviour. Here you can see I have two checking on not just the title, but the list of artists I expect to see as a data table. These data tables are particularly useful for data-driven products such as financial systems.

 

Step by Step

 

The implementation of these steps is carried out in the steps file, depicted below. You will see for each Gherkin keyword, we specify the expression matching the precise step in the aforementioned feature file. We also specify a callback function dictating the steps to execute for that precise step.

The steps file are the main glue outlining the system
actions corresponding to each scenario step

Focusing on the Then statement, you will see we are using parameters to promote reuse of these steps for potentially multiple scenarios. In addition to simple textual parameters, data tables such as the artists table shown in our example can support specification of complex data types and collections. Data tables are particularly useful for data heavy applications such as those I see working in financial services.

 

Being a web application, we often encounter asynchronous situations in obtaining the page results. It’s important to ensure you use async and await correctly to handle the time taken to capture the elements or perform service calls. Often when starting you may be tempted to start including timeout waits, but these should be used sparingly. In this trivial example it is not required, but I have often seen them be gradually increased over time when pinging backend services directly.

 

You Find Me

 

Looking at the steps you may see we are performing particular operations to get elements on the page. With Protractor we use the Page Object pattern to seek out elements to inspect within the tests. It has the advantage of decoupling your test steps from the page layout. Be mindful that other frameworks such as Cypress do not advocate that pattern.

 

All of the examples here search by CSS paths, including the $$ and $ Protractor shorthands. Other selectors, including by id, name, ng-model and binding are provided.

The po file is a Protractor specific construct as it uses the
Page Object pattern to separate DOM-based logic from the testing framework

All of the examples here search by CSS paths, including the $$ and $ Protractor shorthands. Other selectors, including by id, name, ng-model and binding are provided.

 

Coda

 

As we have reached the end of this track, I hope you have seen how combining BDD specifications and e2e testing helps provide expressive and understandable testing. By using examples produced in conjunction with key stakeholders, we can develop features in collaboration with users to showcase the expected product workflow.

 

Sheet Music

Let music inspire your technical choices

 

Feel free to check out the code on my personal GitHub at the listed link if you’re interested in digging more into the code. I hope this also encourages you to think about how other technologies and techniques you either use or research can be combined to make a more effective combination. Be inspired by music and mashup your technologies today!

 

Thanks for reading!