Help, often accepted, sometimes rejected, always okay

Help (verb) make it easier or possible for (someone) to do something by offering them one’s services or resources

Today we will talk about help, more precisely helping people who refuse help. However, before I delve any further, you should have a quick read at the Agile Manifesto.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

As I go through the (true) stories I am about to tell, it will be up to you to figure which principles tie in the way I tackle today’s topic. That way we both put the work in one of my posts. I’ll do the same for yours if requested. The stories will be told in chronological order so you may even notice changes in reactions from on end. Talking about ends…

Frontend helps backend: Crisis on infinite ends

A long time ago in a start-up far far away, a product was screaming for more features. On one hand, we had a frontend , faster after months of ownership. On the other hand, the consulting firm that built the backend finally handed over the code for a few weeks. The fresh backend pair working on it was doing its best to catch up but it was a mostly unknown code base with poor test automation. I should probably say non-existing as testing that a couple random getters get stuff is not testing.

We used Jira for project management and had a few backend issues being raised and the pressure was high due to an upcoming marketing event. Back then I owned the iOS code and wrote in Objective-C, yep a while ago, and offered to help out the backend guys pick up bugs. 

The first occurrence felt like a « I java dev look down on you iOS dev » which in hindsight I find funny because that’s how I considered people building their career in mobile dev. It was not seen as serious development then. What makes it funnier is that back then I spent most of my commercial years writing iOS code than anything else.

I always see myself as a guy who would be much more proficient writing Java or C# as I spent most of my studying years practising and improving with them. Always hanging around the top of the class for these. Eventually after checking what I wrote guy 1 realised his mistake and we got along pretty well over time and I got to help him more as we were more backend intensive in terms of features being built or improved.

That one time I offered help and got disgusted by the outcome

A quick intro because this is longer than others

I am not a guy who gets angry easily, to get me to that point you really need to try hard. Or in that case, try hard not to do anything. Introduce guy number 2, a lead Android developer. This time I am the backend guy daring to meddle with frontend code. Heavens forbid!

There the pace is different from the first story as in Backend and iOS teams moved pretty fast on user stories. Android, not that much. We were going at a rate such that there was a couple of sprints between a service being implemented backend-wise and the matching UI on our Android app. Pretty soon I ran out of backlog stuff to pick up.

One day, during a planning session, I suggested that I should pick up one of the Android user stories. One that matched a backend service I created a few weeks earlier. The plus here is that I knew about the API, can write Java and did a bit of Android in the past. The product owner pretty happy about it gave me the green light. I did not see other options as it solved the lack of backend work for me and to delay in Android progress.

Now the juicy bit

The task was straightforward. Call the service I built and display the data in a collection view. In order to be thorough, I mimicked what seemed to be our Android standards from existing code. I applied myself to code clean to the best of my knowledge at the time. Within a week I was done implementing and cleaning up. I remember being quite proud of myself. I pushed my feature branch then nothing.

Not exactly nothing, after nagging guy number 2 for a few days he told me that I should have never picked up the task. Better even, reviewing what I did would waste his time as I am a “fake” Android developer. You know, classic teamwork stuff. Then I thought it was a phase, that maybe he felt threatened that a guy who has zero Android experience on his resume could do work he does. To this day I do not know nor care about the reason any of it happened. I saw it as an insult to my ability to write software.

I took it to anyone who would listen and had to power to do anything. Not much happened, from my understanding the guy told them he was too busy to review my code and they believed that. Then he said my code was bad, note that he still did not review it when he said so. I even confronted him a few times and went over his head all the way through C-levels because I was that pissed off. At that point, the code is rotting, unreviewed for almost two months.

How it ended

I was asked to leave it. Told that I would help the support team until our backend backlog got refilled. I did not protest because at that point I just wanted the situation to end.  Eventually, guy 2 picked up the story that had been in “review” for a few months. He “reviewed” the code, by that I mean, created a new branch copied my changes and opened a new pull request. Curious to know what big difference there would be between the code he wrote for that feature and mine. None. There was none. Absolutely, fucking, none. He actually stuck with copying my code after all the shit I got. I’m overplaying it as there were a couple “changes” but nowhere near what he told to our stakeholders.

A renamed variable here and there at most. Nothing major. Nothing justifying the disrespect I was showed for the almost three months I waited for a code review that never came because I am not a “fake” Android developer. I remember telling one of my bosses before even finding out about the end result that if I joined as an Android dev then and the same thing happened I would have immediately left the company. I did quit the job a few months after that for other reasons. It is funny that those reason tie-in with this and other stuff that led to being tired and bored.

Closing this until the next, hopefully far in the future, occurrence

Doesn’t it make sense that someone finishing first helps a team by picking up tasks when he can? Do we want a world where write our bit of code and ignore teammates who may need help? Personally, I don’t. I am lucky to be gifted enough so that I can pick some languages and be productive with them within an existing code base. I am certain not to be the only developer capable of this. What I am sure of is that versions of these stories happened to others who may have stopped providing help. This is a big loss for our industry. A big loss for our teams and a big loss for productivity.

It’s not because you accept one’s help that you are less valuable, quite the contrary! Sometimes that help gives you the time you need to deliver that one critical feature on time without having to worry about the ticket you got freed from. Other times, that help is the opportunity to learn a new approach to a problem you would tackle differently.

We even have modern IDEs that are a great help to write better code. And even better, our peers can review the code we write and catch some issues early. On top of that, continuous integration allows catching errors early especially when you practice TDD. These tools allow me to move faster by myself.

These tools exist so that teams move faster and with more confidence. You should be able to trust that your tests cover your code logic. You can even take a page from my future-proof posts. They should guaranty your software behaviour as long as they remain intact. If you are in a position where your tests do not play this role, then you should question them. Not the ones trying to help you move faster. Before I leave you, did you catch which principles of the Agile Manifesto were violated?

Facebook Comments

Leave a Reply