The Bad Example

Imagine a character called Jack who hires an electrician to have a ceiling lamp mounted.

• "Hello Mr Electrician, could you mount the lamp for me please?." - Jack asks.

With a bright smile Electrician starts his job. At the end of his work, Jack pushes the switch and… the lamp doesn't give any light.

Full of surprise on his face Jack kindly asks:

• “Why isn’t it working?”

And the response was:

• "You didn’t ask me to make the lamp work, you asked me to get it mounted."

There is lots of absurdity in the story but one can find in it an analogy to a modern software engineer’s work reality. We, developers, want some clear acceptance criteria, mock ups and well refined tasks. On Friday afternoon we are proud that all the requirements are clearly met by our implementation, but from users’ perspective the functionality sometimes resembles the well mounted lamp that gives no light.

In that story Jack is the project manager and Mr Electrician is the orthodox, acceptance-criteria-oriented-developer.

Such a situation is a project manager’s nightmare. The role of a project manager is to receive, digest and broadcast signals between people of different worlds. From developers, through upper management up to customers. They physically cannot point out every single thing to be done and hold the dev by hand to make sure everything in his implementation makes sense. They want to trust the developers, have faith in their common sense and rely on their technical, but also user-oriented expertise.

The Good Example

Since we have covered the nightmare scenario, let’s now imagine a more pragmatic and professional approach to mounting the lamp.

Driven by frustration and disappointment Jack found another electrician to make his lamp work. His name is Mr Pragmatic Electrician. Right after receiving the job Mr Pragmatic Electrician mysteriously started looking around the room. He came back to Jack and said:

• "I’ve reviewed the lamp, it has no lightbulb in it. Moreover the wiring is not covered safely. I also verified the allowed amperage in your room and it’s not sufficient for the lamp. I’d propose to completely replace the main wiring, but that will require hammering the walls. Alternatively you could remove some electrical devices from the room. And if we are going to rewire the room, I’d also propose to move the lamp a bit more to the center, as it would provide a much better light distribution across the room."

Jack was absolutely stunned by the professionalism and complexity of the advice he received. He felt really comfortable and felt he could trust Mr Pragmatic and told him:

• "I can see you know what you’re talking about, I need to go out, but please do all you find suitable to make it work. I’ll be back in the evening."

The result of Mr Pragmatic’s work was a beautifully lit and safely wired room.

The Analysis

Why was Mr Pragmatic's approach so much more valuable to Jack?

• He reviewed the current state of the lamp
• Investigated the surroundings
• Verified the related pathways
• Took a broader look all around the lamp, presented a non-technical, user-oriented guidance to properly mount the lamp in the most efficient way
• Clearly described his findings, dangers and risks
• Decomposed the problem on many layers: safety, effort, effectiveness of the potential solution.
• Defined the obstacles, blockers and presented an alternative approach
• Proposed clear and professional solutions to the problems

And most of all… He took responsibility for the idea of LIGHTING THE ROOM instead of MOUNTING THE LAMP.

Following Mr’s Pragmatic attitude you will gain lots of trust from your Project Manager and you will make his life much easier.

The skill I value the most in developers is the ability to take a look at the product as a whole, beyond the Jira tasks - Kasia, Project Manager at Bright Inventions.

The Summary

The professional developer takes responsibility for fulfilling a high level, abstract need, he supports the manager to achieve his needs. A pragmatic approach is to take a holistic view on the idea, the concept, the issue that you are working on. Change perspective, think like a specialist, but then like a plain, ignorant user. Do not blindly follow the acceptance criteria of your task. Fulfil them, but make sure they sit well within the system. Verify all the flows around your new feature - do they still make sense? Should they be aligned? Think about the future of this feature - is it likely to be extended? Does the codebase allow that? Should you propose a refactoring for that module? Be courageous, accept the fact that the business thinking is intrinsically entangled into developers' work routine. Do not only do the coding, but take responsibility for the functionalities.

At the end, please ask yourself these questions:

As a software engineer have you happened to stick so hard to acceptance criteria that you missed some meaningful details in your implementation?

As a project manager, have you come across non-supportive, acceptance-criteria-oriented devs? How did you approach the lack of reason in their attitude?

By Radosław Landowski, Backend Developer @ Bright Inventions.

Photo by Pierre Châtel-Innocenti on Unsplash.