bookmark_borderThe personality of software developer

In Poland, some devs say: I haven’t become a software engineer to talk with people. We, programmers, sometimes like to be perceived as incomprehensible, Heraclitean savants, who stand above the masses of ordinary users. Some of us, look down on junior developers. The internet is full of such memes, showing how dumb junior developers are, compared to legendary seniors.

When we show an old technology to a junior developer


Among us, developers, there’s a constant battle. The ongoing domination struggle. How many times have I seen refactoring a source code to the shorter version, using unpopular language features just to show off how great our knowledge is… As well as reduced estimations, to prove we’re more efficient. And people starting recruitment processes just for the sake of training. Last but not least – assigning not easy but mundane tasks to junior developers.

In one company I worked for I had a colleague, let’s call him Peter. Peter was a junior developer like me. One day, however, probably due to longer experience, he has been promoted to a regular developer. Two weeks later, when I was working with the source code, I asked my colleagues at the open-space about decimal type in C# which I didn’t know at that time. Peter immediately stopped working and laughed out loudly.

– You do NOT know the decimal!? You’re such a junior dev! – he said

Then some senior developer heard it and laughed out even louder.

– Peter, how dare you to laugh? You asked me the same question one month ago!

Meanwhile, it is cooperation and synergy, not ego and knowledge about esoteric technology features, which creates productive teams that create beautiful, well designed, effective solutions to business problems and make clients happy. After years spent on software development, I’ve understood one thing…

The most important quality of a software engineer is empathy.

Empathy is the ability to understand and share the feelings of another. If a developer can see the world through the eyes of other people, he’ll be able to create software easy and comfortable for ordinary people. If he can think outside of his perspective he’ll be able to write the source code understandable for others. Therefore modifying it will be easier and cheaper. Having empathy, the developer will be able to communicate with the business.

As developers, we should always try to improve our empathy. We should ask ourselves as often as possible – will that be understandable for others, who don’t know what I know? Won’t it be overly complex, will it be easy to use? Do I use the language simple enough?

When we recruit developers we should carefully look at their personality. Self-contained, tyrannical people, even if technically brilliant, can create more problems than they solve. I’d recommend to not focus solely on IQ and technical skills. Most of the projects don’t have as monumental technical challenges as we imagine.

Technologies inevitably fade away and disappear. What will be left is the source code. It’s going to be source code written by the people who were able to understand that someone will come after them and that person will need to understand their work, that this person will probably not have deep knowledge about framework and the programming language, and maybe won’t have as deep domain knowledge as they have. Or it’s going to be written by people who don’t care about their successors but themselves rather. Nobody would like to maintain the source code created by the latter. It will be a hell to recruit people and their work will be slow and ineffective. We don’t want it. Therefore – focus on empathy.

bookmark_borderModified agile

I can’t remember how many times have I heard a word Agile during recent years. We’re agile. We’re doing agile. We’re introducing agile.

It sounds like people dialogues in the kitchen. Yes, I’m going to the gym. Sure, I do cardio. Yeah, I do Crossfit. Of course, I consume supplements. Aero? Every week.

But somehow I can’t see the muscle grow.

The results of this supposed agility I can’t see as well. There used to be chaos and it still is. Estimations have been poor and they still are. The technical debt balance looks like the credit card of a young adult after the summer weekend. Deadlines are scary like cancer and deployments as painful as colonoscopy. And last but not least – the scope is still not flexible at all. But we’re agile!

Are we?

The worst failure of Agile is I believe its promise it can be modified and adjusted. Therefore let’s come back to the analogy of a gym. We are growing muscles. But we don’t take care of the diet because we like to eat. We don’t train our legs because on Fridays we go to the party. We don’t go to the gym when we have a headache.

Then we visit a gym for two years and we still are somehow ashamed owners of a beer belly instead of rock-solid ABS.

Can we be agile if we have a fixed scope? Can we deploy at the end of each sprint if we don’t have the whole organization prepared for it? Can we build better software without showing the client a new version at each iteration? Can we be agile if there’s no client yet, only the budget?

Maybe yes, maybe no.

But for sure if we will modify or remove half of the rules from Agile recommendations we will achieve mess, not benefits. So let’s be serious, responsible developers and not be tempted to eat a cookie when we’re on diet. We can’t eat a cookie and still have it.

bookmark_borderThe fundamental problem of software development

If we would ask the question – what a software developer’s job is about? – probably most of the people would answer – it’s about writing source code. Some of them, more familiar with the software industry would reply – requirement analysis, application design, programming, to some extent also testing and deployment. That’s what can be seen. The operational perspective.

What cannot be seen however, at least at first sight, is much more important and entails a plethora of issues.

The world is complex. Almost infinitely complex. Objects consist of elements, elements of materials, materials are made of chemical substances, those are made of molecules, molecules made of atoms, atoms made of elementary particles, so on, so forth. On the other hand objects aggregate to places, places into cities, then we can think of regions, states, continents, planets, planetary systems, galaxies, groups of galaxies, etc.

Human beings simplify things. When we describe a group of people, we say: a few, several, dozen, crowd. We don’t count and say – 27 people. When we see the colors we say light green, warm, cold, gloomy, happy. We don’t describe the colors as a mathematical concept of red, green and blue values.

Computers do operate on numbers, values. We can’t put into machine the human idea of a car or gasoline. We must create a model of these things, simplification of the real world behind the words we use every day, we must choose the values which will describe them (volume, octane number), we must identify relationships between them (a type of fuel for a car).

People and computers are fundamentally different. Software is a bridge between the two worlds. Building software is creating the proxy, the communication layer between two extremely incompatible realities.

The consequences are enormous. This incompatibility makes software creation difficult, long and complex process. Because of it the software engineers quite often can’t communicate with the clients. Because of this barrier, we don’t have smooth conversations with Siri and we don’t see the robots from sci-fi movies on the streets. Because of this the cars on the streets still are driven by humans.

What draws my attention after years of work in the software industry is the human tendency to minimize effort (see: Law of triviality). A tiny fraction of the general population is eager to put the effort to deeply analyze the problem on which they work. Most of the people will stop at the first reasonable solution they can think of. It’s very clearly visible when software developers try to test their programs. They almost never are willing or able to use their software in a different way than the default scenario. It’s the simplest scenario, the one which is known for them very well. Creation requires effort. This constant mental optimization, this effort reduction is visible also in the designs of the business people in the organizations. Almost always it comes out that some scenarios have been missed during the planning stage. At the moment we even assume, industry-wide, that it’s impossible to analyze everything upfront (fundamentally different philosophy has been applied in the space shuttle program software engineering team, which is very well described here).

Software development, unfortunately, requires precision. At every stage of the project, starting from the analysis, through implementation and finally ending with tests and deployment we need to maintain intellectual rigor. It’s dictated by the nature of software itself. We cannot let ourselves to be lazy. We must always, at every moment of work be as precise as possible. Otherwise we will face consequences – bugs, mistakes, security breaches. Compilers are cruel – bugs are always fault of developers, not computers, and the same can be said about software development in general. Whatever we will ignore – it’s going to hit us back, painfully, sometimes deadly.