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.

 

Smoldering rose

 

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.

 

Collaborating

 

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.

 

Gandalf

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

Read More Code to Write Less

Recently I’ve been reflecting on the amount of time I spend reading code. Far more than I write in fact. In addition to the constant stream of pull requests filling my inbox, I’ve also been reading the code of our reusable UI components, including a recent rewrite. Here I contemplate the ratio of reading to writing, and whether we’re encouraging the correct ratio between developers.

 

Writing versus Refactoring

 

As I discussed recently in Caught in a Trap, we have previously suffered from writing a few bloated controls. Some of them are very feature heavy, so with the ongoing rewrite we are only including the features that we actually need. It sounds obvious, but we only want to include the features that are actually common within the common components.

 

Adding a new feature over the past week without over-complicating the control has been challenging. It has required compromising between refactoring and fully rewriting. Refactoring should be small incremental moves and optimisations, which was what the initial design intended. After a few days, I received a large pull request with a ton of new classes created. This is a prior trap discussed in my previous post, as this is contrary to Trunk-based Development practices. Large reviews are more synonymous with rewriting, which we wanted to avoid.

 

Yarn

Developers need to learn when to refactor and mend existing code rather than always create new classes and methods

 

Coding is both a logical exercise and a creative process. Developers seem to exhibit a preference for spinning their own yarn of code rather than mending the existing jumper. Here we did need a new jumper to allow for building of the requested screens for the next few sprints. Letting go and accepting the delay has been a good management lesson for perfectionist me.

 

The importance of upfront design is also apparent here. Any knitter will tell you they need to know the pattern in advance to make sure the jumper doesn’t end up as just a scarf. Building software is no exception. Therefore, we have introduced a regular design session following retrospective feedback to get developers thinking about code rather than diving straight into writing.

 

Read Code First

 

Our recent rewriting exploits got me thinking about how often we should spend reading versus writing code. A precise ratio is not difficult to find, and I had definitely came across it before in my spare time reading. In Uncle Bob’s book Clean Code, he advises that the ratio of reading to writing code is 10:1. If I reflect on the time my team spend, they are not reading enough code. We may love weaving a coding tale, but reading more code will make us better developers.

 

![The Matrix](https://images.unsplash.com/photo-1526374965328-7f61d4dc18c5?ixlib=rb-1.2.1 "Only by reading more code will developers be able to learn to write and understand code better")

*[Only by reading more code will developers be able to learn to write and understand code better]([ The more that you read, the more things you will know. > The more that you learn, the more places you’ll go. > > Dr. Seuss, I Can Read With My Eyes Shut!

 

There is an expansive world of books, articles, opinions and other resources out there to discover and digest. Agile mandates continuous improvement of process. To exercise agility, developers must continue to learn to continuously improve their code and architecture skills. Only then will we be able to better refactor and stitch in our new features.

 

Thanks for reading! Claps are always appreciated.

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.

 

Tomato Soup

 

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!

Can’t See the Trunk for the Feature Branches

A Retrospective Look at Adopting Trunk-based Development

People are interesting. We have our habits and behaviours ranging from the accepted to the downright quirky. Some of us are exceptionally flexible, while others revel in their habits. Developers are no exception. This is a story reflecting on developers as creatures of habit, striving for their "perfect" merge.

 

Initial State

 

Upon commencing our agile journey just under three years ago, we adopted the practice of creating a branch for each individual sprint. This change was mainly attributed to the teams arriving one Monday morning to find all projects had been moved from Perforce to Git. At the time it was certainly painful, but definitely proved to be a blessing in disguise!

 

With the adoption of Git, we pretty much adopted the bog standard Git workflow, with the slight tweak of creating a new branch for each sprint. Developers would eagerly create and refactor code, raising pull requests into branch X and creating feature branches in their own private fork for their stories and dutifully worked on their items.

 

Git Flow

The Git Workflow is familiar to most…

 

The Git Workflow is familiar to most…On reflection, creating a new branch every sprint did seem like overkill. Lead developers did end up with the challenge of having to delete branches every so often to keep the branch listing manageable. Surely, if we had continued with this model a single development branch would have been reasonable.

 

Feature branches themselves proved to be troublesome. Developers would not merge back to the sprint branch very often. In the majority of cases, they would raise the request only once their feature was complete, regardless of splitting the story down. I’m sure you’ll not be surprised to read that merge conflicts were common, and quite often affected multiple files. Integration between pieces often occurred towards the end of a sprint, resulting in a slap bang attempt to fix any issues. Breaking the psychological need to only commit perfection beholden to the developer seemed impossible.

 

A Bright Idea

 

When the alternative approach of Trunk-based Development was proposed to us in a knowledge share, it was the classic cartoon moment of a light bulb sparking to life within my head. The premise was essentially the reverse of our approach at the time, where developers raise pull requests directly to master.

 

Trunk-based Development Flow

Trunk-based Development seemed like the bright idea to solve all those problems

 

As outlined at the Trunk-based Development home, developers merge directly to  master. Initially, I thought back to all those branches we had to maintain. All those large pull requests. The pain of dealing with merge conflicts every sprint. I got that usual thrill of excitement coursing through my veins common with every hair-brained scheme I propose in work.

 

Trunk-based Development Flow

As outlined at the Trunk-based Development home, developers merge directly to master

 

Adapting to Change

 

Trunk-based Development was initially adopted across a couple of teams. Adoption of a new branching strategy is significantly easier when a few of your colleagues are on the same knowledge share. The journey to date has certainly been interesting. The obvious benefit for leads was we no longer needed to create as many branches. In fact, thanks to the use of labels, we have been creating physical branches only in the event of hot fixes to a release, which are then merged back to master.

 

> The programmer, like the poet, works only slightly removed from pure > thought-stuff. He builds his castles in the air, from air, creating by exertion > of the imagination. > > Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering

 

One initial surprise was changing developer mindset in more ways than one. Adjusting to pulling the latest recently rather than getting caught up in the coding moment is something they were forced to adopt. It was no longer the case that they could work on building that castle without syncing up with the drawbridge being constructed by their colleague.

 

Diverging forks and merge conflicts also occurred more initially if developers didn’t raise pull requests regularly. They were forced to commit smaller pieces, while still adhering to the definition of done. This does result in more requests to review, but smaller reviews are definitely easier to understand.

 

These changes in behaviour, for the most part, seem to be holding. However, one thing that has not necessarily been eliminated is the use of feature branches by all. As their forks are their own, some do create branches sharing the story, or event sub-task name. Arguably that can increase the number of divergent branches a developer encounters in their fork. It also contravenes trunk-based best practice since they’re not pushing small frequent changes. But it seems in some ways that developers still like labeling a castle as a castle, or a tower as a tower. The question is if the same control is to be exerted over their private branches as it is over the trunk.

 

Thanks for reading!

Opening Pandora’s Box

The Challenges of Introducing User Personas

User personas are a challenging addition to the UX design stage that we have been incorporating into our agile development practice over the past few months. While taking the plunge into writing my first piece, I thought it apt to reflect on some of the unintended side effects introduced through encouraging developers to write realistic and reliable personas.

 

Persona Ownership

 

Completing these personas started out as a hair-brained scheme to get our developers talking more to our users. Developers are in a rather fortunate situation that our clients work in the same organisation. We have challenges where not all developers are co-located, but nothing that is a show-stopper for talking to users and eliciting what their jobs actually entail.

 

Providing a template was intended to give a common specification of how to document the discoveries developers made by talking to users. Potentially even to frame conversations going forward. We were quite surprised to find developers emailing the persona directly to the user, asking them to fill out their own role.

 

I get it. It’s certainly the easy way to get an accurate set of responsibilities, challenges and goals. It did certainly lead to questions who gets the credit for persona creation: developer or user? However, doesn’t it detract from the journey of finding out the processes themselves? Arguably it could seem like a one off exercise. Since user responsibilities and processes evolve over time, we need developers to keep them up to date. Only by regularly engaging users in person, or over the phone in the case of remote developers, can we maintain accurate user representations.

 

When Users Find Out

 

Given developers shared the template out to some key stakeholders, it was no surprise that users and managers alike quickly found out about the personas we had written. What surprised me in particular was the range of reactions that were exhibited.

 

Kevin McCallister

Unlike Kevin, users were happy rather than shocked about our persona experiment!

 

The majority of stakeholders applauded our initiative. They could clearly see the value in engaging with them directly, and how it could help us identify new stories to address their challenges and improve their working lives. Others questioned why we had not always done this, and engaged their teams to collaborate with us and help us bring the details up to date.

 

However, the other side of the coin definitely introduced some challenges. Some individuals did seem rather reticent. Divulging challenges in your role did seem to be considered by some as complaining, the last of which you want your boss to see. Arguing for users to be identifiable rather than anonymous partially contributed to this concern since we included their mugshot as part of the template. However, the value of having an identifiable contact that users can empathise with seemed important. Especially given the majority did consider being a person more of a badge of honour!

 

Too Much of a Good Thing

 

Pandora’s box has been open for a few months now, and despite a few locusts making their way out, we’ve certainly seen manly positive aspects. Developers are now able to better identify the precise user for the features they build. Their knowledge of business processes has vastly improved, along with many arranging regular day in the life sessions with key stakeholders to share their new found knowledge. The quality of user stories written have vastly improved, with the benefit of each story listed more often than not.

 

Where's Wally?

Where’s Wally is over 25 years old, but we’re struggling to find him in our persona list!

 

Like everything, you can have too much of a good thing. There is certainly an element of persona explosion happening right now. This makes finding the right persona at times like a game of Where’s Wally!

 

Part of this issue can be attributed to our challenges of collective persona ownership. It’s OK to edit a persona created by someone else! Another is just not checking what personas have been entered already. However, so far the experiment is holding well, and we are certainly reaping the benefits!

 

Thanks for reading!