I have been a developer since… well, I do not know! I am for sure been paid to create softwares for ten years but my first line of code was twenty years ago. During the years between these instructions stupidly copied from a programing book to my first paycheck, I learned from books and websites, sharpening my skills on several pet projects, and reinforced this experimental knowledge with computer science courses.

A lot of these projects seemed very good while I was making them, until I learned new stuff or started to look at what professionals do. As time went by I looked at the past projects very critically: I knew nothing, everything was just crap. Then one day I read the readme file of the GPL release of DOOM where John Carmack tells us “Projects tends to rot if you leave it alone for a few years”. Damn! Then he adds “I wrote this code a long, long time ago, and there are plenty of things that seem downright silly in retrospect […]”. What a relief! Even the amazing John Carmack thought he wrote inefficient code in the incredible model that was DOOM. Maybe I was finally on the right path.

This message made something click inside me, I suddenly understood that I should always learn, that I will always improve my skill and look at my previous work thinking it is the job of a less experienced programmer, because it is. As long as I will continue practicing, every line of code will eventually seem clumsy or bad, but it does not prevent to create masterpieces. So all I have to do is to focus on the current project and try to do it as good as I am currently able to.

Since then I practiced as much as I could, trying my skills on several projects, working with very different people. Now I think it is a good time to produce a summary of the good and bad things I have seen and did as a software developer.

There are a lot of things to say so I am going to share them through several articles. Here comes the first part on the importance of efficiently sharing the workload.

Be a leader, not a hero

If you are anything like me, as a developer you certainly have a sensitivity for challenges. You may have experienced this nice feeling we have when a difficult task comes in, when nobody can think of a nice solution while we are feeling in our guts that it should be done a given way. “I’ll handle this” do we say in our most virile voice, “just observe and learn” continued in our most internal voice. This moment when we address large issues by ourself, going through an intensive week-long tunnel of coding, designing and refactoring to finally reappear in slow motion, Armageddon style, extenuated and covered in sweat, sticking out our chest before saying with a deep breath: “Damn yeah, I made it work!”. Thanks to us the project made a big step forward. See how valuable we are!

We are not that valuable. Actually the precise fact that we decide to tackle a problem on our own instead of sharing the load with the team is a failure; this is the behavior of hero programmers.

I have seen developers addressing every software need this way, aggressively parading while implying that nobody else in the team could even understand the basis of the solution. These people would come out of the blue over your shoulder, interrupting your work to tell you that “Customer MoneyProvider had an issue with our software, we need to address it now! Look at it and fix it! You know what, you’re too slow, I’ll handle it.” Then they would storm out with their red face, skipping their meal to fix the issue in a quick and dirty way while the customer had found a workaround and dealt with the issue on his side.

A professional developer would have opened a ticket for the issue, maybe he would also had a quick look at the code to find a hint of the cause. He would have discussed the issue and its solutions with the rest of the team, teaching the juniors by the way on how to handle this case. He would have let the producer prioritize the story, then he would have reported to the customer that his issue was going to be fixed in the version X of the software. We should be this developer.

Taking a feature or an issue personally is a pretentious and unhealthy behavior. When we think that we can handle something better alone than with the team, when we think that we are the pivotal point of the team, we should take a break, go find a teammate and ask him to give us a huge kick in the butt. I have heard several people telling that they were the reason the company was going well, from fellow developers to waiters and cooks in a restaurant I worked for, and every time when they left the company we could observe the same thing: nothing changed. The people in place would just share the load and breathe in relief from being freed from their grumpy colleagues until someone would be hired to fill the empty spot.

I have also seen myself cutting a feature discussion short because I just wanted to implement it so much, while my colleagues did not see any interest in it. I thought that they needed to see it working in order to understand its powerfulness and I was wrong. I should have seen in their doubt that I was going to lose our time by adding an unwanted feature that we did not need and that we would have to maintain. What I actually did was adding more complexity to an already complex project.

As experienced programmers, as team players, it is our job to adjust our rhythm to the one of the team. It is our job to take as many time as needed to teach the less experienced how to handle things efficiently. It is our job to think, every time, that this elegant and smart solution we provide is the crappy solution of the better-than-us developer we have not met yet.

I had a colleague who came in a project I was working on alone until then and who told me that a particular part was very inefficiently implemented. We discussed about it, my opinion being that it was a perfectly understandable piece of code and that it was sufficiently efficient for our needs while his opinion was that it could be as understandable and still far more efficient. Then he spent some of his own time to implement this part as he wanted in a side branch so he could show me the difference. His code was incredibly faster but I thought there was too many tricks, an unclear responsibility and some implicit requirements. We continued talking about it, then I proposed an implementation that was as fast as his and that was readable enough to please me. This colleague perfectly did his job; he saw a subject on which I was weak and he showed me how it could be efficiently done. He forced me to rethink how to solve this kind of problem and instead of doing the changes on his own he guided me toward an implementation that pleased both of us. Valuable lesson learned.

Our temptation to be the guy who made it working is also triggered by some kind of urgency implied, deliberately or not, by the management. Typically, I have seen the case where a customer demo was planed for the next day and the product manager asked us to quickly implement a feature he absolutely wanted to show. The hero will agree to the request and there is no way it can end well. What if we manage to do it in time? It will be so messy that we will not want or be able to maintain it. It may even not be in the stable product the customer will buy. It will be so inefficiently tested that it will certainly fail during the demo. Actually just the fact of breaking the rhythm of the sprint, leaving aside our work in order to patch this feature will result in a global dissatisfaction and half-assed work to finally complete the sprint.

Another kind of management pressure is the negotiation of the estimations. The developers would estimate a story at ten points and the product owner would ask: “can you do it for five? ten is too much, I need it quickly”. Well, the answer is obviously “No we can’t”. If our product owner asks us to do something for less than its cost, we must resist until he breaks the story into something of a lower cost. We should take this kind of request as an insult. Is he implying that we use twice as needed time to implement his stories? Is he suggesting that we are not working at our most efficient velocity? We should not accept that. We should work our best so we can refuse to negotiate an estimation. If it does not fit the schedule, then the prioritization must be reviewed, the stories must be rewritten. Sometime everyone must be remembered that everything has a cost, every feature cannot be refined under a given amount of work. The best producers I have met understood this and would never question an estimation. By doing so, letting us being the ones deciding the estimation, they made us committed to it; guaranteeing that we would do our best to fulfill it.

It is tempting to accept this kind of requests because we are under the impression that it would help the product manager or the sales. It make us feel that we are doing something good for someone; we are nice. Actually our job is to be reliable, far before being nice or friendly. Our job is to provide a product of an expected quality in a controlled cost, even if it means that we sometime have to refuse to help someone we wish we could. Just refuse nicely.

Hey, liked what you have read? Continue with the next part: be reliable.