Signs of Life

Searching for Signs of Developer Discontent

Recognition of a job well done in software engineering, or arguably any profession, is intriguing. Rock stars are rewarded for their achievements in building software with leading others in their quest to build software. One aspect that we never really prepare new managers for is the complexities of the human systems they support.

Do managers seek out the signs to address developer issues, or do take the wrong fork?

Building scalable enterprise applications is certainly not easy. Comprehending the hidden mysteries of the programmer psyche is far more challenging. Even more so when attempting to gauge their job satisfaction. Often we charge into battle at the point of no return. The signs are there long before, but we quite often don’t follow the route to the final destination. Here I ponder how to monitor themes of displeasure as an alternative to the knee-jerk reaction tactic, and consider if we are initiating the rescue mission too late.

No More Heroes

To determine if we are engaging in timely heroics, we need to first scrutinise the behaviour of dispirited developers. Having regular catch ups with your engineers is imperative in the quest to track their levels of fulfilment. This may sound obvious, but I’ve certainly seen on both sides of the line that this notion is not always apparent. In fact one junior developer recently exhibited extreme surprise that I was putting in a regular catch up at all.

Amazement aside, getting the most out of a 1–1 on either side requires skill and practice. There is a temptation to use such sessions as a general status update. Managers should be mindful that this could be a diversion strategy. People normally love talking about themselves. If they are focusing on tasks, they may be showing reluctance with discussing issues.

Single open questions are the key to breaking that cycle. We tend to ask multiple at once to extract all we need. Perhaps it’s out of impatience to identify a solution. Adoption of a more laid back style is imperative to extract issues early. Ask one question and wait. Embrace the silence. There may be a temptation when vexations are voiced to immediately react with reassurance. But getting to the route of the problem relies on listening and understanding their perspective.

A Sign of the Times

As managers, we know we need to listen. One of the key responsibilities we should focus more on is identifying and rectifying issues. So why are we still missing the signs?

Humans struggle to deal with awkward conversations. We actively avoid discussing uncomfortable matters and will sweep them under the rug. If they are out of sight, they are also out of mind. Once we find out about issues, great or small, we need to do something to address them. Actions speak louder than words.

As the signs become brighter, we shouldn’t continue to ignore the issues, even if they are difficult for us to fix

As managers we need to ask ourselves why we are in denial. There are several reasons that could be at play. Perhaps it is easier to ignore the predicaments we see, especially if you are powerless to fix them. Potentially we become disconnected with such problems, especially if we have never needed to carry out the originating task or function.

Some reasons may be less innocent. We all have aspirations and agendas. Managers, like engineers, can become engrossed in deliverables and miss the big picture. It can be challenging to dedicate time to addressing a pitfall for someone else that may contradict your own viewpoint. Participating in meaningful conversations to grasp their differing perspective is vital in our role in empowering programmers. If you project an agenda, or worse contradictory opinions over time, people will be less likely to raise concerns.

Measure for Measure

Once managers engage and begin listening, it’s important to monitor issues and their occurrences. Managers are certainly not infallible, and grievances can arise again. If you are not able to rectify a particular issue, measuring how often it arises is critical to ensure your developers don’t become frustrated.

Use your regular catch ups with disgruntled directs to identify the key themes of conflict. If they are becoming more regular points of discussion, it’s a strong hint that the issue is not being addressed. Not everyone is going to yell their issues from the rooftops. If you’re waiting for that point to sort out their problems, you are running the risk of them leaving.

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.

Atticus Finch, To Kill a Mockingbird

Continuous improvement should apply to people as well as processes. Any issues you discover are productivity blockers for the developer in question that we should be attempting to alleviate. Try alternative approaches to rectify the concerns raised. Encourage your people to raise all burdens, regardless of your own affiliations. Only then can you empathise and take a walk in their shoes.

Thanks for reading!

Broken Mirror

Tackling Retrospective Regression

Taking time to reflect is important. In this chaotic world we need to deliberate more in order to grow. Humans are generally pessimistic creatures. We tend to focus less on our achievements than our failures when recalling past events. Through 20:20 hindsight we can identify our mistakes and the exact set of steps we would enact to undo our wrongs. The Undoing Project by Michael Lewis covers this condition far better than I ever could.

Mistakes in a mirror may appear closer than achievements

Retrospectives shine a mirror on how we build software. Their aim is to provide an opportunity to dwell upon the collective successes and failures of the team, and use that hindsight to improve. The initial euphoria is great, but over time the shine begins to dull. Here I ponder some emerging bad habits that can develop over time, and how you can polish that retro mirror to return it to its shining former glory.

Blind Hope

One of the cardinal sins of agility is not having retrospectives at all. This is a symptom of novice and experienced Agile teams alike. All the reasons I’ve encountered to date are not by any means intentional or malicious. It may be tempting to start with just a stand up and build up to retrospectives. However, you’ll miss the opportunity to routinely assess progress.

Once you are having frequent retrospectives, it is paramount to learn the warning signs to preserve the most important of ceremonies. Where the regular meeting invite lies on the team calendar is vital to preserving the voice of the team. Scheduling at the exact same time as a stand up may seem like a smart solution to address context switching. Regardless, you run the risk of focusing on your stand up, and forgetting the retrospective.

Consider the humble ATM, or Cash Machine if you’re so inclined. I recall an anecdote from my university HCI class on why your card is released before the cash. The lecturer in question gave an amusing tale pertaining to treasure seekers taking their money and leaving their card in the machine. To reduce fraud, the order was altered since the key aim of the transaction is to obtain those crisp notes.

Humans are goal oriented, so make sure the end goal is not blocked by any others

Regardless of whether this fable is an urban legend or not, the moral is clear. With a double booking, you run the risk of confusing the true goal. Once the stand up is complete, you are relying on the team to remember a more infrequent ceremony. Dedicate a reoccurring entry to your retrospective, regardless of your Agile paradigm of choice. Maintaining this slot is critical to ensuring that the meeting always occurs. Not honouring that habitual entry removes your teams voice and breeds discontent. So hold it at a different time, preferably at a time where they can get comfortable with a cup of tea and contemplate recent events before the retrospective starts.

Everything Changes

Sometimes people need a change of scene. Routine can be great, but it becomes repetitive after a while. While there are many particular formats a retrospective can take to elicit feedback, over time a routine can render them less effective.

Every team has their preferences. A retrospective format can develop into a familiar security blanket. If your team is using the same questions every few weeks, it will enforce a particular frame of mind when attempting to identify improvements and celebrate successes. Consider evolving your plan to get your team thinking differently. True, some may be more effective than others. Nevertheless, failing fast works for retrospectives too!

Thinking Out Loud

Fostering diversity within teams is imperative for many reasons. Differing experiences, backgrounds, opinions and personalities help us build strong teams that will bring innovations to the software we write. Much research has been performed on software team cohesion and the personalities that are drawn to software engineering.

Be mindful of how contrasting personalities engage in retrospectives to empower team members to speak. Balancing introverts and extroverts is particularly challenging. Care must be taken to avoid louder voices being prioritised. In troublesome times this may breed discontent among quieter individuals.

Like tortoises, we should encourage quieter team members to come out of their shell during retrospectives to obtain a collective view

Colleagues with perception and feeling characteristics, as classified under the Myers-Briggs Type Indicator, make for great cohesive agents. They can prevent extroverts from dominating the session. Asking probing questions to introverts directly can help bring them out of their shell. Picking on the quiet ones may seem unfair initially , but it will make for a more balanced viewpoint. However, this does not mean that open questions should not be asked of all team members, regardless of personality, to extract more detail.

Reaction to Action

Regular reflection on our progress is vital to refine our development practices. Good retrospective facilitators will help extract possible process improvements. They are essential to thwart attempts to turn your retrospective into a rabble. Actions speak louder than words after all.

Once these activities have been identified, they can’t just be forgotten. We need to follow through with such suggestions and measure their effectiveness. Logging these ideas and assigning owners is imperative to ensuring their execution. One possible enhancement for us is assigning these items as part of our normal work. Only then will we be able to see the ripple effect of any pebbles we skim across the water.

Thanks for reading!

What the F**ture?!

Tackling Feature Toggle Aversion

We are fortunate enough to work in a cosy world of a component-based architecture. Several of my colleagues have a love of microservices, and none of those are afraid to shout it proudly from the rooftops. Our approach introduces a lot of benefits ranging from the obvious such as decoupling of key logic, to flexibility of hosting.

Developers need to be as comfortable switching features off as they are with a light switch

Multiple teams owning these components introduces some challenges. When things don’t go to plan, a single team can block itself and others if that new shiny logic is not ready. I’ve witnessed more than one instance recently where toggling the feature off would have prevented the ensuing frustration of features being blocked. Unexpected behaviour with features in production would also have benefited from a feature flipper. Here I reflect on recent issues on encouraging feature flag use, in the hope we can learn to love the off switch.

Capture the Flag

People are scared of being found out, especially when they don’t know something. It takes a lot of nerve to admit lack of familiarity in a world where knowledge is power. Even the most humble of egos doesn’t want to get caught in the trap. I have many developers not using toggles that when approached in a more comfortable environment will admit they don’t know what they actually are.

I’m not just talking about naming here. As outlined by Pete Hodgson and Martin Fowler, there are several different names in use. However, a rose by any other name still smells as sweet. The problem is that programmers believe that the implementation is fundamentally different depending on their usage of framework X or technology Y.

Be comfortable that surrendering to feature flags does not make your code any less elegant

Developers think we need to have an all singing, all dancing framework that can turn functionality on and off. I’ve seen examples of how to build such toggles on both the client and server code. I advise that under the KISS principle, the simplest approach is always best. To that end, a simple constant controlling an if statement is suitable for the majority of use cases. If this can be parameterized to be passed into the process to permit switching the logic off in production with a config change rather than deploying a new code version, all the better!

It’s Complicated

It’s not simply the case that once developers know what a feature toggle is and how they can be constructed that they will immediately be sold on using them . I’ve heard quite a few attempt to justify not writing feature toggles. Developers and leads alike regularly attest that they don’t need toggles, for differing reasons.

The first, is their effect on code complexity. Those of us from a Computer Science background will remember back to that first lecture on complexity. Perhaps several algorithms were scrawled in messy lecturer script on the blackboard, with the class tasked with determining their complexity. Those of a different discipline will have picked it up from general reading or training.

Regardless of where that spark of knowledge came from, we have answered enough exam questions and provided enough interview answers over time to be able to explicitly calculate complexity with ease. It implicitly forms our decisions on algorithm design and coding on a daily basis. For some, it is used as a justification for not adding a feature toggle. That is certainly not the case if we remember back to our complexity rules.

Algorithm elegance doesn’t justify a lack of toggles. Part of this stubbornness could boil down to a misunderstanding of the permanence of a toggle. No one is suggesting that toggling code should be permanent. Good developers will remove existing toggles once the logic is verified in production. Great engineers will add and remove them consistently to their features. Leads need to support these engineers in their introduction for new features and logic changes alike.

So Much for My Happy Ending

The perpetual optimism of developers is another challenge in the adoption of feature toggles. No one wants to think that building out the latest story will go anything but smoothly. Engineers will blindly follow the yellow brick road all the way to Oz. They will typically have at least one or more of the below mindsets:

My feature will definitely go live! I will not encounter any blockers along the way.
I’ve comfortable with the code base so it will definitely take me X days to implement this story.
This new feature will definitely work first time. My code is perfect, bug free and I’ve covered every edge case with my tests.

Each of these arguments can be used by developers as an attempt to discount building a feature toggle. Programmers are human, and optimists at that. We all want to feel the warm glow of our work being used by clients. Nevertheless, with this optimism comes the notion that we will deliver perfect features, on time, every time. Turning that feature off suggests that all the blood, sweat and tears they poured into development will be in vain.

It’s not because they’re incompetent, or that they are calendar-challenged, it’s just that estimating the time to do something we’ve never done before is something we suck at. And, by nature, we’re often optimistic animals.

Jeff Patton and Peter Economy, User Story Mapping: Discover the Whole Story, Build the Right Product

We need to nurture faith that there are benefits to hitting the off button. The benefit is that we have flexibility to cover when things go wrong. It’s alright for development work to run over, to be incomplete, and that turning it off and on is a good thing. Foster some humility in your developers to get them comfortable switching their features on and off. An initial leap is satisfying for individuals, but it’s not always the right call for the collective.

Thanks for reading!

Leave a Light On

When Bored Developers Become Frustrated

Leave a Light On

When Bored Developers Become Frustrated

Coders want to spend the majority of their time coding. It may sound like a rather obvious statement. Yet it remains the case that we struggle to balance the coding to release management ratio. Developers are comfortable performing other tasks besides, but the value needs to be clear.

Identifying the signs of unhappy developers and acting on them promptly is the key to keeping the best people around

I’ve spent significant time over the past week talking to unhappy developers. Disengaged developers. Each in different stages of unhappiness. All tackling their frustrations in different ways. It is true that bored people quit, but disheartened people quit too. Here I reflect on how such discontent manifests and the signs to look out for to keep your best developers around.

Are We Human, or Are We Developer?

When reading Managing Humans by Michael Lopp a few years ago, one chapter in particular struck a chord with me. Bored People Quit. In hindsight it was mainly because I myself was bored at work. I desperately needed a change.

Recent events have got me thinking about that time again. Reflecting on prior experiences has certainly helped me establish different techniques for supporting those who reach out for help. I re-read the chapter this week to help reflect on my handling of each situation.

Hunting the Apathy Grail

Identifying the signs early is important to prevent boredom transforming into anger. As managers we should always be on the lookout for changes in behaviour. We should always ask questions to assess their engagement with their daily work. Classic traits highlighted in this chapter include changes in schedule such as last minute vacation and changes to working hours.

> The goal here is to discover boredom before they know it, and the act of a > simple question might be just the mental impetus they need to see the early > signs in themselves. > > Michael Lopp, Managing Humans

In the slightly more modern age of flexible working, consider the frequency of work from home days. It is not an exact science. Nevertheless it can also suggest your rock star is participating in initial stage interviews and coding exercises. Quite often it can be a sign of other life events. Even those we should be on the lookout for as managers to ensure we provide the necessary support to retain our top talent.

Thinking back now, I regrettably see the tipping point more clearly in at least one case. Handling these effectively will build loyalty. Get it wrong and you could cultivate resentment instead.

Foster the Frustration

What are the key activities that cause boredom and frustration to fester? Lack of toys to tinker with is definitely the most common one I have experienced in my not so recent past. Software development is not just limited to spending endless days locked in a cupboard writing code. Talented developers are always happy to own development and release management tasks if the balance is right. Admin needs to be seen as a valuable and concise set of steps, rather than a wall between them and reaching coding nirvana.

Governments and large organisations alike love to apply processes to feel in control. Paperwork is a necessary evil. In regulated environments such as mine, management often struggle to consider the volume and effect. This can lead us to enforce waterfall artefacts on top to give management security, regardless of Agile adoption. Regulated environments such as ours can still cultivate agility. Working software over comprehensive documentation is baked into the principle because it is the main item of progress for developers and clients alike. If it takes several hours just to go through the motions and get the paperwork together, we may need to rethink the balance.

Never too Late?

Boredom is frustrating, but being hounded when you don’t want to be saved is tedious. Scurrying around trying to convince someone to stay is not always the answer. You need to read the situation and determine what is your best course of action.

Managers should test the waters before pulling out all the steps. Some want to skip off into the sunset to find their happy ever job ending.

Some individuals do want to be saved. Some want to be woo’ed with you charging into battle to fight to keep them. But some quite simply just want to be left alone. For the latter, initiating a fight may be doing them a disservice. It may be more appropriate to let them go. Choosing to leave a role is a scary, exhilarating time. There are a lot of emotions at play. As a manager, the danger is that you’ll confuse them into staying and harbor resentment. Lopp is indeed right that once someone quits, they can do so again if they stay. The precedent has indeed been set by that point.

Keeping good people is hard. It is important to identify the signs early and support them with opportunities to grow. Constantly reinforce regardless of whether they are happy and frustrated that your door is always open. If they do end up growing, provide them with the support they need. When facing the unknown, people like to know that the door didn’t slam shut behind them if that rosy new role doesn’t quite pan out. Let them know that you will leave the light on.

Thanks for reading!

Like Real People Do

The Important of Failing Fast When Managing Humans

The title of Manager is one that up until recently has instilled a level of fear in me. The fact that it is regularly used interchangeably with Leader in the corporate world probably doesn’t help.

Leadership for me describes a confident, charismatic individual charging forth with their army into battle with gusto and enthusiasm. Hardly the term I would use to describe the mousy impostor sitting in my chair that bounces between phone calls and meetings like an overenthusiastic jack-in-the-box!

We need to stop fearing failure and take more risks with encouraging developers

Regardless it’s a title that has followed me around since my recent promotion and role change in January. Not so much that I have great power, but responsibility is certainly on the up. Here I reflect on the past six months, and ask why we fear failing fast when managing software developers.

Why Fail Fast?

The concept of failing fast is rooted deep within innovation theory. As much as our massively inflated egos would like to think otherwise, we are not infallible. We often don’t know if the latest wacky idea to solve our problem will actually work. By encouraging early failure, we empower teams to openly propose new ideas. Diversification of thought and workforce has already been established as vital for organisations to compete in the market. Yet if we can adopt such a nurturing environment for product development, why can the same not be said for people development?

To understand if we can fail fast, we need to consider what the ramifications of people management failures actually are. That depends on the circumstances. It ranges wildly between that individual having to work a few extra hours to being passed over for promotion or role change (or worse). However, what about the effect on the manager themselves? We are human after all!

Managers Aren’t Psychopaths… Usually

A key motivation of human behaviour is maintaining the balance between pleasure and pain. Unless you are a masochistic individual, it is more likely that your actions are an attempt to maximise the former. Good managers establish a strong rapport with their directs, without getting too sucked in. It may be easier to switch your emotions off the moment you enter that intimidating corporate tower of doom. However, by flicking that switch you lose a connection with colleagues that you can leverage to support them in completing their best work.

Managers still need to connect with their directs to get the best work from them

It is challenging not to get invested as you build such relationships. These bonds introduce unnecessary pressure on always getting it right first time. As we start to care, we realise that it’s detrimental to get it wrong. The software I write isn’t safety critical. As a wise man once said to me, no one will die if that new feature is not released next week.

Empathetic managers see breaking a person’s expectations to be more detrimental. Failing a person has a larger side-effect than a failing test. It is absolutely true that software development is easier in comparison to people development. The trick is to remain as objective as you can, rather than the opposing extreme of ceasing to feel.

Chain… Keeps Us Together

One of the hardest challenges I’ve had to conquer over the last six months is being able to let things go. Both in terms of delegating work, and admitting defeat in ongoing battles. A key benefit of delegating is to develop another person. As failing fast on a task is an amazing thing, we need to become comfortable with letting them make those mistakes. Even if sometimes they need to make the exact same one we have ourselves done before.

> It is better to lead from behind and to put others in front, especially when > you celebrate victory when nice things occur. You take the front line when > there is danger. Then people will appreciate your leadership. > > Nelson Mandela

As the chain gets longer, we have less control over the outcome. Being a control freak becomes impossible. The important next step for us as managers is to provide constructive feedback on how they can improve, rather than resulting to criticism and playground gossip.

Developers may enjoy playing with code, but we should nurture and encourage mistakes

Examples are vital to this effort, but our own experiences can be used as a parable. Be open with your own journey, and use the woeful tales of our achievements and regrets to reinforce these messages. Aside from being a useful learning point, it exposes a ray of humanity that managers need to feel comfortable showcasing. I may now be a manager by day, perhaps a leader in time. Regardless, I certainly don’t dream of electric sheep by night!

Thanks for reading!

Use Somebody

Can User Personas Support Adoption of Agile Principles?

A few months ago, I opened Pandora’s Box and unleashed user personas on the team. Despite the challenges around their adoption, it has had the intended effect of encouraging developers to start talking to our users, and identify the problems that our software needs to solve.

Sitting on the dock of the bay, I reflect on whether user personas are supporting our continued Agile journey

Nevertheless it has not always been sunshine and lollipops. Enforcing standards can lead to backlash when the value is not immediately clear. Since personas are documentation, it can be seen as introducing unnecessary bureaucracy. Here I attempt to assess persona agility against the Manifesto for Agile Software Development, and highlight the value they bring to our processes.

Documentation Over Working Software

One concern initially raised is that the burden of additional documentation doesn’t fit the criteria of prioritising working software. Working in a regulated environment results in a lot more documentation than other organisations. We feel the need to justify every decision. The burden of writing said documentation is often imposed from top down, resulting in frustration for programmers.

Developers tend to exhibit an extreme hated for documentation. From university and beyond into the world of work, the sole purpose of engineers is to write code. This pesky documentation simply blocks them from carrying out their raison d’être.

When determining the key value of encouraging greater user engagement, the question I had to ask myself is how to reduce the overhead. By providing a concise template in a bullet point format, we allow for rapid generation and change of these personas, without overburdening developers. That way they can focus on building working software, but still with users in mind.

Dreaming of Electric Sheep?

Collaboration with users is important, so much in fact that customer collaboration is a principle in the manifesto. It is a key pillar, especially in my role where I’m actively developing products for colleagues in the same organisation. To build the right thing, and maximise value, we need to understand our users and what they do. Furthermore, we need to empathise with users struggles and identify the goals rather than just the process.

People may be sheep, but we need to ensure we target individuals as well as the entire herd

Processes are inherently complex, especially in the corporate world. Humans make it so. The processes are often outlined in expansive process documents that read more like War and Peace than The Hungry Caterpillar. This is another reason documenting the user interactions we have in the search for value all the more important, albeit in a far more concise format.

Who Are You?

As outlined previously, the goal of the template was to help developers integrate personas easily into their everyday cycle. The template listed only key headings to identify their key daily tasks, the challenges they face, and the systems they typically use. My aim was to summarise the key attributes of a user’s day to day function, without having the profile sound like a dating profile. Personal attributes are therefore limited to role title, location and photo.

Templates in the corporate world should avoid non-essential attributes such as personal information, keywords and quotes to reduce documentation overhead

We do want to encourage empathy, but us knowing that Jane Doe is 27, loves dogs and spends their weekends binge-watching Netflix doesn’t achieve empathy for how they use our systems. It may help you build a relationship by discussing the latest episode of insert latest flavour of the month here. However, knowing that they spend 1 hour everyday pulling data from our systems into a spreadsheet to transform the data into a another format should allow us to focus on not just the user, but their interactions with our systems. Only then can we evolve our software and optimise these interactions.

People Change

People change as they adapt to their environment, even in work. I’m definitely not the same mousy optimistic developer that joined the intimidating corporate technology world just under 7 years ago. I’ve worked on many systems, with differing technology stacks. I’ve evolved as a person outside of work as well. Those insights bleed into the software I build and the work that I do.

This effect is not just limited to technology, but every aspect of an organisation. As people change, they make their mark for a while and then leave. Processes change depending on the ideas thrown into the proverbial pot. Understanding of processes definitely does fluctuate, and it is OK to admit you don’t always know what an individual does 100% of the time.

Everything Changes

Recently I’ve had a reminder of that experience. One process I’m currently analysing has changed again a year later, and as of this week may do so again. The goal is still the same, but the execution has changed in every region.

This process has evolved for several reasons. The initial change was where the information was being stored. It was not necessarily the realisation that the data is there in the system, but that the execution time was becoming exponentially longer as each day was documented. Personas allow us to adapt to changing user challenges. Responding to change is a key principle of the Agile manifesto. When thinking of change, we should consider change in people, processes and software. Personas definitely help support Agile development, in a world of constant change.

Thanks for reading!

Programming With Passion

Is Technology Infatuation Imperative for Building Better Systems?

People are puzzling. Over the course of my first six months managing humans, I’ve found that everyone has different interests and drivers. Not everyone will adhere to the programmer stereotype of the introvert sitting in a cupboard typing furiously.

How do we ignite developer passion for both client value and technology, without snuffing out the other?

Following a series of fortunate events this week I’ve been reflecting on the importance of passion in software development. Does excitement for solely coding make a strong developer? If not, is it possible to fan the enthusiasm flame within our programmers to improve the products we build?

Money, it’s a gas

The first event of this week that got me considering passion was the above quote appearing on my Twitter feed this week. It certainly divided opinion. Many did think they wouldn’t be programming as a career if they didn’t enjoy writing code. However, many objected to pleasure being their primary motivation. The reply that stuck with me most was that money was a bigger factor than enjoyment. Turns out when you program for a living you expect to be paid cold, hard cash for your efforts!

Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.

Linus Torvalds

Money is one thing, but given the range of careers out there that pay, there must be another light that draws the moth to that coding flame. Otherwise why not pick any random 9–5 job in your desired wage bracket and go nuts? People tend to be drawn to fields to which they naturally excel. Therefore it’s safe to say that when picking how to spend over forty hours of your week, you’re going to pick software development if you are motivated to build software.

Technology is Not Enough

The next event of the week got me thinking about the differences between good and great developers. It’s not very often that a pint in the sun results in such a profound moment of thought.

Strong technical skills are certainly important. Given the fast pace of technology enhancements, even in my short six years of working, great developers evolve. They get excited about building software the right way. They scour resources for new technology to integrate into their systems. They sell the value to colleagues, and spread the word organically. Nevertheless, programmers need more. They need to be passionate about the subject domain as well as the technology.

Our best developers exhibit inquisitiveness on client processes. To provide value, you need to be comfortable asking questions. However, what you do with the answers can distinguish between good and great engineers. Directly automating the existing process shows understanding of what is done today. Only by understanding why the process is completed today, and the goal of the process itself can great developers distinguish themselves. That way you can propose the most valuable solution, and provide process optimisations where required.

Nurturing Passion

The final event of this week centres around mechanisms to encourage passion. Like any skill, it is important to consider the nature versus nurture argument. Can passion be taught, or is it an attribute we need to evaluate when hiring a programmer?

With good developers, it is possible to nurture if they can see the value. Passion can often be attributed to extrovert behaviour, but a productive team does not just contain extroverts. Teams diverse in thought, experience and personality are found to be more productive. Even when I was at university, significant research into personality composition of teams using metrics such as Myres Briggs had already been undertaken, which proved useful for my research studies.

Diverse teams have a mix of personalities, which can make measuring passion challenging

Measuring passion is difficult as not everyone exhibits enthusiasm in the same way. Good managers will figure out the subtle cues you disclose to determine if your current workload is engaging. Faking enthusiasm is difficult if you don’t believe in the message you need to convey.

The answer lies in finding those inspirational characters that you can use to engage with developers and nurture their enthusiasm. One effort we have been focused on this week is how to identify role models at different levels within the Technology division, and share their inspirational stories. Those at the top are certainly inspirational, but if you’re just starting they can be challenging to empathise with.

Role models should be advertised at all levels to instil that passion. But be warned. Unless you find both the technical challenge and business domain interesting, your passion will eventually fizzle out no matter who is around to inspire you.

Thanks for reading!

A Review a Day Keeps the Conflicts Away

A Reflection on the Merits of Small, Frequent Reviews

I used to tweet a lot of articles. I mean A LOT! To the extent I am mocked as the team Tweetaholic. There are definitely a few gems in there. Nevertheless, one subsequently deleted find on code review size definitely stirred some active debate in the office.

Hence my first official collaboration with the amazing Joe C. Think of this as our rebuttal to why code reviews are less broken than they appear, especially if trunk-based development is adopted.

Moving the End Zone

We have all been there, especially us authors. You are asked to review a massive pull request touching a ton of files. The majority of these appear at the start or end of our day as opposed to just before lunch.

Large requests such as these stem from developers getting into the zone. Coding happily for hours on a massive task that gets progressively bigger. There is nothing more exhilarating than the magical feeling of your hands dancing over the keys. However, to reduce merge conflicts we need to exercise some collective control. We mandate developers not only pull recent changes into their local fork, but push at least once every 24 hours.

This constant collaboration ensures developers are not slowed down by each other. Furthermore, it encourages communication and discussion which expands their skills. Small and steady on this occasion definitely wins the race!

Owning the Collective

Another rather surprising observation that took us aback was the notion of a single reviewer for a single code base. Having an individual responsible for any task is doomed to fail. By assigning an exponentially high bus factor to any one person, you are running the risk of halting the code production line if they get sick, encounter hardship or burnout, or are hit by that mythical Knight Bus.

Part of being an empathetic colleague is understanding when we all need to chip in. Understanding managers must be quick to identify members of their team that are struggling. This single point of failure invites disaster into the software house.

Under Pressure

The main pre-lunch pressure scenario is troubling for the authors. The reviewer in this case felt pressure to merge code despite being uncomfortable doing so. Did it really need to be done as urgently as the requestor suggested?

The whole premise behind a code review is to make sure developers and reviewers alike understand the consequences of a merge. Furthermore, we want to make sure that the quality of the code being committed is as high as possible, and adheres to the team’s collective standards and definition of done. For this to happen, it’s important to know who the right people are to review such merge requests, and to certify that those individuals are the ones to provide the final sign-off. Both authors have very different skill sets, coming from the opposing server and UI sides of the force. Nevertheless, we both regularly ask developers who have sent us reviews outside our respective areas of expertise to send reviews to the other. This ensures that the purpose of the review is met. OK, developers have sometimes ended up waiting a few extra hours before the code is merged, but it has also meant more meaningful feedback is provided to the reviewee. It is both the authors’ opinion that the targeted feedback provided is worth the additional wait time.

Think of a code review as a stationary bike. Setting the resistance as low as possible may give you a feeling of immediate satisfaction. Regardless, you will eventually find yourself wondering after a year why your code muscles are no stronger than before. By avoiding the path of least resistance, and putting up with feeling like your muscles are on fire, coding will become easier as your muscles begin to strengthen. Any good coach will tell you the best place to go to build such strength.

Absolute Power Corrupts Absolutely

In this scenario, a single reviewer has power over the entire team, and can dictate which shall pass. Any team allowing such a model are setting up that individual to be the most hated person in the team. Developers will see a dictator who stopped my code from being adopted. They stopped the dancing of my fingers across the keys. And they will bite back, hopefully not literally! Reviewers do tend to be more experienced, so managers need to consider if they can afford for this person to become miserable, unhappy, and ultimately leave as a result of the regular infighting that they will have to endure from others.

Having a single gatekeeper enforcing which code shall pass can lead to animosity among the team

Using this single gate keeper to dictate what code shall not pass could improve quality, if the reviewer is good. Nevertheless, the code will most likely confirm to their ideal architecture, their best practice and their code style. Unfortunately that means their bad habits will also creep in (and we both definitely have bad habits, as much as we don’t like to admit it)! Diversity of thought based on experience in life and code is vital to driving high standards and writing better code. Only by encouraging cross review can you strive to enforce collective ownership. We don’t agree that collective ownership is a fallacy. In this model you encourage single ownership. By distributing power and responsibility, you can encourage happy, productive developers, whose fingers will dance the night away over the keyboard.

Learning is More Than Doing

One aspect of code reviews that does often get lost is the learning aspect. People learn by more than just doing. One author recently highlighted that coding continually will not make you a better developer. Practice is certainly important, but how effective are we at reflecting on that code later? Could we, even as senior developers, benefit from the feedback of others on our own code? When can we reflect, and learn from a larger community pool without resorting to reading and ingesting the wisdom of others?

Being a code reviewer is an important role in the development of any junior engineer. You have an opportunity to instil best practice, and impart some of the advice you wish you had received a few years earlier in the exact same situation. Arguably it is even more crucial that reviewers take their role seriously and incorporate learning from the vast array of books, articles and other resources that our industry is fortunate to churn out regularly. Whether you like it or not, you are distinguishing yourself as a role model by reviewing their code. With great power, comes great responsibility.

Thanks for reading! Special thanks to Joe C for his contribution!

Weaving The Software Tapestry

Caught In A Trap

The Code Smells Hiding in Web Development

I spend a lot of time conducting code reviews these days. Far more than writing code in fact. As bold as it may be to say, I am the most experienced Web developer in my team. It pretty much came about because I’ve proven myself to be capable. With great power comes great responsibility after all!

Of late, I have been reflecting on how our Web strategy has evolved, and the resulting spider’s web that we are now trying to disentangle ourselves from. Deliberating over the last few years has got me thinking that many principles are language agnostic, not least code smells.

The Scent That Transports You Back

It is said that a single scent can transport you back to a happier time. Catching that first scent of tomato soup and toast will always take me back to my grandmother’s kitchen. My first memory of code smells comes from a lecture on Software Engineering at Glasgow University. While most students dozed lazily in their seats at the soft skills covered, I was engrossed in this idea of refactoring.

Code smells, like tomato soup, take me back to a simpler time

For those unaware, Code Smells are a term coined by Kent Beck, and utilised within Refactoring by Martin Fowler. These smells describe a symptom that potentially indicates a further underlying problem within the code base. Following that initial lecture, it wasn’t until several years later when I was in my first grown up job as a Software Developer that I actually read the book. It certainly didn’t disappoint. I’ll admit, all the examples were in Java, which I hadn’t touched for a couple of years. This introduced a learning overhead as I was forced to brush up on my Java skills. But the principles still made sense. And, for geeky me anyway, they sparked that same excited realisation that I could make our code more readable and understandable.

Moving Out West

Just under three years ago, I moved onto a new frontier, to the exciting world of Web development. The Web Wild West had historically been ruled by JavaScript. The language itself has some advantages, the key being that it enables pretty much anyone with the will to get dynamic Web pages up and running quickly. However, the lack of static type support does certainly lead to a multitude of errors if you are not careful.

This was pretty much the reason that we adopted Typescript from the outset. Coming from a Desktop UI development background, it made sense to utilise a language similar to C# to get us comfortable quickly. Deadlines don’t cease when you’re learning, and there were definitely no exceptions here!

We proved quickly that we could build out new, arguably scalable features in a short timeframe. This would have been the perfect time to re-evaluate our stance and ensure we were refactoring regularly as we go. Unfortunately, we were very much victims of our own success. Looking back at the code base now, not instilling further good practices including regular refactoring introduced a ton of bad smells.

I’ll not go into details of the God classes, large classes and methods, or even the huge number of copy-pasted code that I have seen. That’s not really the point of this thread. I will certainly admit that I regret allowing it to get to that stage.

Escaping the Web

We are now attempting some rather exciting things to try and escape the expansive spider’s web that we have created. By creating a modular-based UI architecture, we can split the features into logical groupings. That in itself has challenges that we are addressing. However, no matter how many modules we split these features into, we still need to address the stale code smells that remain.

> I don’t understand it. But for that matter > I don’t understand how a spider learned to spin > a web in the first place. When the words > appeared everyone said they were a miracle. > But nobody pointed out that the web itself is a miracle. > > E.B. White, Charlotte’s Web

Through peer reviews the collective have been imparting the advice they can. Our code quality is certainly improving. We are so far preventing the reintroduction of many of the smells we had before. Or, at least I thought that was the case.

Following a change in IDE this week to Visual Studio Code and installation of a Typescript supported complexity plugin, I’ve seen that a couple of smells are reoccurring. When considering why, part of this certainly stems from a lack of complexity metrics on our PR portal itself. However, thinking back to reading Martin Fowler’s Refactoring, I wonder how many of the next generation have actually read it?

Similar to Millennials being raised with the complacency that Technology is intrinsic in their lives, a lot of these developers have evolved with the mentality that refactoring tools have always been available in their favourite IDE menu. Does this lead to a lack of appreciation of where these ideas originate from?

This disregard seems to manifest itself in long methods in classes, among other foul code scents. It has resulted in an urgent set of tasks being defined in this sprint to address these particular problems. However, going forward we need to instil an appreciation of where the term refactoring truly comes from, and train our developer’s sense of smell to detect these bouquets.

Thanks for reading!

Searching for Signs of Developer Discontent

No More Heroes

A Sign of the Times

Measure for Measure

Tackling Retrospective Regression

Blind Hope

Everything Changes

Thinking Out Loud

Reaction to Action

Tackling Feature Toggle Aversion

Capture the Flag

It’s Complicated

So Much for My Happy Ending

When Bored Developers Become Frustrated

Leave a Light On

When Bored Developers Become Frustrated

Are We Human, or Are We Developer?

Hunting the Apathy Grail

Foster the Frustration

Never too Late?

The Important of Failing Fast When Managing Humans

Why Fail Fast?

Managers Aren’t Psychopaths… Usually

Chain… Keeps Us Together

Can User Personas Support Adoption of Agile Principles?

Documentation Over Working Software

Dreaming of Electric Sheep?

Who Are You?

People Change

Everything Changes

Is Technology Infatuation Imperative for Building Better Systems?

Money, it’s a gas

Technology is Not Enough

Nurturing Passion

A Reflection on the Merits of Small, Frequent Reviews

Moving the End Zone

Owning the Collective

Under Pressure

Absolute Power Corrupts Absolutely

Learning is More Than Doing

Read More Code to Write Less

Writing versus Refactoring

Read Code First

The Code Smells Hiding in Web Development

The Scent That Transports You Back

Moving Out West

Escaping the Web