Category: Developer wisdom

Developer Professionalism : Take a stand

Dattatraya Kale

Few weeks ago, I was travelling to my hometown by a bus. I reached the pick-up point at scheduled time, but when I arrived, I found that the bus was late.

Finally after a wait of 2 hours, the bus arrived and the driver found himself in the middle of many angry passengers who were also waiting for the bus. After a while, I patiently asked the driver, “What was the problem?”. To which he replied, “The bus is having problems since last 4-5 days. I told the management that we need at-least 2-3 days to fix the bus, but they are not ready to listen. They are insisting to run the bus by doing a quick-fix for the time being.” I again asked him, ” Are you sure it won’t fail again?”. He replied, “We’re not sure, let’s pray that the bus does not fail.”

It was an overnight journey, I started thinking, why is the crew taking such a risk of using a bus they are not confident of. There were kids, old people on that bus. What-if it fails in middle of nowhere?

How many of us have encountered such a situation before in our own professional lives?

Have you ever been asked to ship a low quality quick fix, so that the software can be shipped into production quickly?

Have you ever been pressurized to develop a piece of code in short time, thereby giving you less time and opportunity to produce a good work?

I have been in such situations too and to be honest, I’ve even done that. I’ve succumbed to pressures. But is that the right thing to do?

People from these professions, such as doctors, construction engineers have an obligation towards the society and that obligation is to protect human lives first.

Software these days, is no different. Software is everywhere. It’s being used to suggest what medication a patient should get, it’s driving cars for you, it’s even bringing you from top floor to the ground floor of the building you live in. It’s omnipresent.

And the onus to ensure that it works as expected, is on us. People have lost lives, due to bugs in software, it’s as real as it gets. Developers these days, are now being held accountable for the work they produce.

So if you are not sure, if you’re code will as expected, if you are not sure, you’ve covered all edge cases, if you are not sure that the quality is up-to the mark, learn to say NO, take a stand. (But remember, when you do so, do it with a proper justification too.)

Don’t be too clever

Dattatraya Kale

A few days ago, I along with my friend went to the restaurant. When I went to use a washroom, I found these symbols on the doors.

I realized the humor of the designer and then I went to the Male washroom. However, I observed that other people who don’t understand the humor, having difficulty to understand the correct washroom. They had to ask staff for help. Hmm! That’s not that user-friendly.

Similarly, people try to be too clever while writing the code.

Please see the above code snippet. Do you understand the intent of BombDetector.Detect? Original author must have tried to use his humor while writing the code.

However, the maintenance developer may not understand the humor behind it and he would feel helpless to understand the intent.

The original author was checking the value of the input argument and throwing the exception if a value of an argument is null.

Above snippet could have been kept simple.


Try to keep your code as simple as possible so that everyone could easily understand it and easily work with it.

Dattatray Kale

Start practicing Shoshin

Dattatraya Kale

When you were a child and wanted to learn something for the first time. You chose to learn it from others with an open mind. Take an example of painting the picture. You could experience this when your kids try to mimic you while learning something the first time.

(My daughter Shruti tried to paint the butterfly. She was eager and tried to accept every information with an open mind)

When you acquire knowledge about something your mind becomes more closed. Over the period of time, you become reluctant to accept more information.

I hope you had experienced this at least once. When you try to give suggestion to improve processes like stand-ups, grooming, retrospective or some other agile process, the senior person would refuse to change since he/she thinks that he/she knows everything.

He/she choose to kill your suggestion with her/his closed mind! EGO?

I was introduced to this term by my agile coach when I was working with Tieto education Pune.  Initially, I was not very convinced or sure about it, preconceptions!

(Image: http://kungfupanda.wikia.com/wiki/File:Mantis-Po-acupuncture.png)

However, over the period of time, I saw good behavioral changes in me and my scrum team.

Shoshin clearly encourages good behaviors in you and your team. See below description from Wikipedia.

“If your mind is empty, it is always ready for anything, it is open to everything. In the beginner’s mind there are many possibilities, but in the expert’s mind, there are few. ” ― Shunryu Suzuki

I started attending various agile and software craftsman ceremonies with an open mind like study circles, knowledge sharing sessions, refinements, the storytelling of epic work items and so on. It really helped me and my team to grow as a scrum team.

Believe me, if you choose to practice below-mentioned attitude (SHOSHIN), it will really help you in the long run.

  • Openness

  • Eagerness
  • Lack of preconceptions.

I would highly recommend practicing Shoshin mindset in your team. Even you could include it in your way of working.

(Image: https://www.deviantart.com/keysamoguri/art/Inner-peace-301041283)

See what James Clear says about SHOSHIN: https://jamesclear.com/shoshin.

https://blog.beingcraftsman.com/datta/

Just don’t be mute pair programmer

Dattatraya Kale

The motivation behind this post was, I saw few developers who do full time or part time pairing with their peers and driving the process, choose to be mute for the whole time. Of course, this is an anti-pattern.

If you choose to be mute rockstar coder then it wouldn’t help anyone neither you nor your team.

If you see food shows on TV, you’ll observe that there will be two people working together (I used the word working TOGETHER).

You know there will be one chef who knows how to prepare the dish and other chef doesn’t know about it.

They talk with each other about the recipe, ingredients, do’s and don’t, what, how and why and so on so that the other chef gets the knowledge. Next time, the other chef could easily prepare the dish. During this process, the first chef would know few tips from another one.

You see the secret of their success is they talk with each other about the problem at hand.

The same thing is applicable to developers who work in a pair for full time or part-time.

As a developer, our peer may be facing some problem and when he/she comes to you, you should do the same thing as these chefs choose to do, just don’t be mute, talk, work together!

You should talk about the problem at hand, why, what, how and so on. There is a possibility that as a driver of the process, you would learn something new from another developer.

Even one of four values of agile and software craftsmanship emphasize on individuals and interactions. Please see below.

From agile manifesto

 

From manifesto for software craftsmanship,

https://blog.beingcraftsman.com/datta/