The developers song

The developers song by Nikola Stjelja on GoAnimate

Video Maker - Powered by GoAnimate.

As I wait for my one hundred twenty projects long solution to load I pray the Lord for my soul to keep.

As I dream of complex code, loops, functions and classes, patterns and database I reach for Hermes the god Alchemist and inventors in my hour of need.

I no longer can reach the dream of perfect machinery

I no longer can feel the systems beat

It is one long chain of stack overflow, exceptions and performance pits

No tests to speak of, not builds to rely on

Just one long, long evening of darkness and despair of enterprise code ready to be released

It is time for me to step down, to reach my bottommost level and open my snail farm on a far away island

Is it is not that the future that awaits us all?

Hermes doesn't respond

My soul is mine to keep

The solution is loaded , all one hundred and twenty projects long

The code is green and blue and yellow and red

I start pounding my keyboard

I start building my code

It takes a moment for the grid to pop up

For the exception to raise I fix the problem

Release my code I go home happy, ready for tomorrow to do it all again.

Different styles, different problems

 

In software development as a culture there are multiple personal and organizational styles of development, process and project management.

What happens when a person , an engineer, switches from an organization which favors one style to an organization which favors another?

Usually there are two very negative responses which just popup continuously:

• Shock and negation,
• Aggressive takedown of the alien style

In my experience you can expect them from senior engineers who recently switched from one culture to the next. I’ve always waited with apprehension a new hire to see if she is going to throw a ruckus and put everything up and down or is she going to integrate into the process and contribute normally to its advancement.

I’ve seen people shockingly negating the new mindset and creating grief to everybody around them until they either accept the new state or leave. Of course I’ve seen people who continued to push their style onto others until it infiltrated certain parts of the project (have you ever heard bout this : “Hey why is this code in a different style then the rest of the application, don’t you guys have an architecture?” and the response “Yeah, that was Ivan he is a bit strong headed about some things, can’t do nothing about that.) and created a mess which just increased the maintenance cost of the project. That is not really good.

I’m a long time listener of the Manager and Career Tools podcast. One of the podcast I’ve listened to in the last few months is about your first six months in new job. The core idea was “do not make waves in the first six months”.

We are all engineers here, we want to improve things make them better. Something's in the new project, new organization are wrong or not optimal and can be corrected. But some aren’t. How can somebody figure out the difference?

So many times I’ve participated or seen arguments of a technical solution which just boiled down to individual preferences. Both solutions fitted the problem well. And then escalated into flame wars.

What I’ve learned is to pause and think: “is this a real problem, or just not my preference”.

Usually people are more receptive to solutions how to solve a problem then they are to changes to their preferred style. People do not want needless change, we all want our peace and quiet. We don’t want to pick a new style, we want them to use our style for better and worse.

A funny cartoon I've created about the problem:

Space coders - the enum battle by Nikola Stjelja on GoAnimate

Video Maker - Powered by GoAnimate.