Definition and thoughts. Developer’s point of view

It looks like I have finally found my MOJO in the world of Software Development, and that is a scalable improvement of developers’ productivity.

What do I mean by that?

Closing tasks in time and in budget

We are normally paid to provide some kind of service. The developer´s service is to close “tickets” by implementing features, providing support, etc. Generally speaking, your company will be quite happy if you close your tickets according to the earlier agreements and without budget overspending.

However, there is a catch. We cannot afford to implement “what we were asked to implement” and close the tickets, so our annual reviews look right. We must be very critical of each and every line in the “ticket”. The business might have changed. The market situation might have changed. The requirements might have initially been wrong or non-optimal.

Remember - the fastest way to process a ticket is to cancel it. The fastest way to fix the bug is not to let it down to the next phase. Stop it at the analysis stage and your team will save tons of time. Your business will save tens of thousands of £, even for the simplest bugs-not-written.

Thinking beyond the tasks

Never, never ever underestimate the importance of thinking “beyond the tasks”. Even if you are a junior developer, try to understand the Architecture of your application. Try to understand your product’s architecture. Try to understand your company’s business. All these things will help you to spend less time in the future, over and over again. You will just “happen” to know if the feature is ready to be moved to the next stage if you are “reinventing the bicycle” if you are unnecessary reimplementing functionality that has been already implemented. For example, once I saw an external consultant “going above and beyond” by calling us and saying that there will be a postal reform in a country in half a year's time and checking if our company is aware. His proactivity allowed my manager to act based on the new information and prepare the resources for the products affected.

Continuously react to the changing environment

No plan survives the first contact. Things will always change. You need to periodically stop and check if your current approach is still optimal. The building might be on fire, so the best decision might be to leave it and wait till further instructions! I am not joking here. I have once spoken to a trader, who was working on a weekend and ignored the fire alarm ringing as it was “obviously a test”. When he left the building later, the next building has burned down and the firefighters were very surprised to see him.

Touch base with the stakeholders periodically. Show them the interim results, in a format suited for them. The “preventive feedback” is an amazing source of inspiration & finding better ways to do things.

If you find that your task is not needed any longer and you have just spent 5 days on analysis - close the ticket, even if 1 day is left. It will be a 1 day of your time, saved for the company. You might pick up a new task or invest your time into learning Architecture and Business. Of course, there will be exceptions and sometimes it might be wise to finish the task, especially if there is a non-ignorable possibility of that task becoming relevant in some foreseeable future.

Stepping out of the equation

We are all unique and special. Sin embargo, not that many products have been created by one persona for that 1 person only. Usually, our craftsmanship is about collaboration with other people. Think about “we”, not “I”. Think how your task relates to the tasks of your team or even your company. Do you really want to spend this day on that specific task, or you would pick up another task as in 2 days your team will be affecting (or even blocking) a number of other tickets of the team?

Sometimes these things are even bigger. Some of us might remember how a very reputable company has trained a photo recognition AI model to be a racist one. As I understood, there was no such intention, but the developers did not think about a wider “we”. So, developers fed the system with their own photos. The team was not diverse enough, so the system recognized photos of “people similar in appearance to these developers” as way better than people who did not have a similar appearance. Feel free to google “racist AI” for more bitter examples.

I think that diverse teams are better equipped for making sure things like racist AI do not happen. From my experience, I can say that diverse teams are really thinking out of the box and these teams do think about “we” instead of I.

We are professionals, our job is not only to close the tickets but also to do it in the right way. Even (or especially) when we need to step out of the box and tell our colleagues that the current approach must be changed.

The best things are scalable
I will almost always choose something which affects a group of developers in a positive way versus something which will only affect me, as a developer in a positive way. Yes, I might benefit from spending a few hours choosing a “Star Wars” mug (sorry, Star Wars fans 😊 ). However, it might be wiser for me to create a page in our internal Wiki on a workaround I have just found for an issue that affects “2+” developers continuously, in a negative way. It does not have to be a costly action. When Covid-19 broke out I shared my headset purchase with the team. I knew the headset works OK and I knew that in these times people do struggle with VOIP communication. I also knew that there are many people like me, who cannot afford to spend £100+ on a headset for communication with colleagues.

Epilogue

It is not possible to put 14+ years of experience in one article. Also, I am human and humans do mistakes. So please do challenge my statements. Do try to adjust things in a way that is better for you and your environment.

I intend to continue writing about developers’ productivity. Stay tuned.

Thank you for reading. I hope my article will help you to write high-quality code faster, with less stress.

I would like to thank @bruno Souza, Венкат Субраманіам 🇺🇦 ✌️ , Trisha Gee, Alexander Nikitin, Yugo Sakamoto and the "celebrity developer" program students ( https://code4.life/tcdb/#more ) for the inspiration.

Special thanks to @LondonJavaCommunity and @Recworks for helping the developer community to grow and to make this world a better place.