Developers, software engineers, coders. Many names that in all honesty refer to the same persona. What do these people do all day? Why are they in such high demand? Why do they get such high salaries? Why don’t they conform to the norms that people laid out for many years as far as clothing, procedures, communication skills go? I will attempt to answer these and other questions in this post.

Why is there software development?

Fundamental question, in my opinion. As species ever since we figured how to make tools, grow crops, build shelters and refrigerate food - basically taking care of the bottom of Maslow’s pyramid - we wanted to do things faster, better and in larger quantities. Fast-forward to 20th century, and you will see that many of our problems moved from manual to mechanical and then to digital. Having said that at its core software development tackles the problem of automation of tasks and needs that are or aren’t in demand.

What do developers do?

Q: What do developers do?

A: They develop.

Q: What do they develop?

A: Software.

Q: Ok, but what is the process of developing software?

A: Good question!

Now we are getting somewhere. Well, like any other job, software development follows steps (or in fancier lingo methodologies that companies have given names e.g. Agile, Waterfall). Throw away all that cruft, and you are left with something like:

1. Identify a task/problem/need
2. Describe it in sufficient detail so there is no ambiguity around what is supposed to happen for the developer that is implementing it
3. Allocate resources/minions/developers
4. Let them do their thing (more on that later)
5. Review what has been done/delivered
6. Repeat

The recipe listed above describes the process from a manager/stakeholder/domain expert’s perspective. Now if we are talking about the same process from the perspective of the developer himself then we get a different picture:

1. Task assignment - pick up a task from a list/get a task assigned to you
2. Design phase - identify the challenges presented by a task, generate various types of documentation and diagrams that describe a proposed solution and choose the technology that can power that solution
3. Implementation phase - this is where work gets really done. This step can be merged into the previous one. This, however, is discouraged since it leads to prolonged development cycles and inability to focus solely on technology problems.
4. Test your work - see if it actually behaves as specified
5. Iterate until the solution is technically sound and fulfills the specification it was designed against

What I have described above is actually not exhaustive. In a team setting you have people with different set of competences and skill set. Whenever someone wants to change something in the system - that is the whole thing that constitutes multiple people’s effort over many years - you need to have the approval of certain colleagues. Usually those are team/tech leads or senior developers that know the intricacies of the system and can reason about proposed changes in a more holistic way. Thus, they can spot mistakes easily and can suggest changes an inexperienced developer didn’t think of. An added benefit to the described process - called a review process - is that explaining your thoughts in a written or verbal form will force you to synthesize your knowledge and challenge your familiarity with the subject. In an ideal world the outcome will be something easy to understand.

I will have to disappoint you, dear reader, since we are still not done. As a developer in a company - depending, of course, if you are a consultant/contractor/part-timer, or a full-time employee - you need to not only augment/expand/add to an existing system, but you need to maintain it as well. Software doesn’t sleep. Thus, in order to be able to keep a company’s customers happy you need to keep the system up and running 24/7. This, of course, doesn’t map 1 to 1 with neither how the working day nor how our circadian rhythm operates. Therefore, things like on-call rotations are created where developers have a cell phone by their side at all times during the calendar day so that at any point in time they can respond to alerts and problems in the system. On a more relaxed note, whenever customers complain that the mechanics of the platform are not functioning properly, and the customer support cannot handle their request, guess how is responsible for addressing the issue? Yup, the developer who made it and that is logical and fair at the same time.

So we arrive at an important point about the workday of a developer and all the possible roles - sometimes referred to as hats - the developer assumes. At any given point in time a developer could be:

• designing a solution
• implementing a solution
• troubleshooting an issue/bug
• reviewing colleagues’ work
• presenting technical and non-technical topic to technical or non-technical colleagues
• other things that depend on the seniority, role, company size

Getting good results at either of these tasks requires focus and concentration. Sometimes it is the case that priorities among tasks change. That impacts many things, but the most crucial one from the perspective of the developer is the loss of focus. Thus changes - or context switches as they are more commonly known - are predominantly disliked by developers as they force you to get out of the zone and break your line of thought.

Why so many of them everywhere?

So far we have looked at the process of crafting software - what steps constitute it, who the people involved in it are and how they interact, and what their responsibilities are. At the beginning of this post I set out to answer a series of questions, two of which were related to the ample amount of job opportunities, and the high remuneration that developers receive as opposed to many countries’ average. I think there is no doubt that this position is heavy on cognitive load and mental capacity. The previous section should have affirmed that to a great extent. However, there are many other professions that require among other things either deep knowledge across a vast amount of topics, ability to make quick optimal decisions under pressure, ownership of problems or ability to thoroughly examine other people’s work and judge without emotions. Doctors, lawyers, fireman - they all exhibit one or more of the qualities listed above.

So what gives? As I said previously - the more we evolve as species, the more our will to know more and do more in a given amount of time is. We have found that if communicated to properly - currently by transporting high speed signals emulating 0’s and 1’s - we can allow machines to make stupendous amounts of computations in extremely short amount of time. That means that they can answer questions that we didn’t imagine were possible to answer. The people that can speak the language of the machines - damn right, the developers.

Ok, but not everybody can afford to learn a programming language or has the knowledge to set up hardware that is supposed to power these software solutions. Furthermore, everything costs money and only big companies have the budget to buy those expensive machines and hire to these expensive machine communicators, no? Wrong! Computers have been getting faster. They have also been getting cheaper due to growing supply triggered by the growing demand. Combine one with the other, and now you see why they are manufactured in extreme quantities. That’s what we call economies of scale. Next we have The Internet. Interconnectedness at a keystroke. With the rapid expansion and betterment of hardware we turn to growth of software. Algorithms for persisting information concisely on that same hardware or algorithms that sift through the many blocks on your HDD or SSD looking for a specific value - these are just minor examples of things that drive interest in digitization for companies. And then The Cloud happens. Companies like Amazon, Google and Microsoft created online subscription services which allow you through the simple setup of a credit card to be on your way to access compute and storage power that only the most experienced hardware and software engineer can harness. Finding solutions to complicated real-world problems has never been so automated and easy to start with. That it’s a good explanation as to why this job proliferates every day.

As for the salaries - I think that after I discussed what goes on into the typical day for a developer, it is easy to see why employers are ready to pay top dollar for their recruits. Not everyone can keep large amounts of context, that they keep up-to-date and be able to constantly decide right from wrong for a given product.

Challenges for developers

The first thing that comes to my mind is health. Many hours of sitting with a poor posture on a crappy chair at a fixed distance from a glaring screen. That’s the reality for many people practising this exciting profession. The negative outcomes of that are many, and I already spoke about how some of them can be addressed here. Other things related to the nature of making big decisions and having to deal with many demanding stakeholders pulling each in their own direction are stress, burnout and the likes. Those are dangerous situations to be in, and they have yet to find their true attention at the work-life balance stage.

As far as work goes there is one thing that every successful developer needs to do - be curious. That manifests in doing courses, research in tooling and languages, eagerness to learn new things. In other words - to stay relevant and competitive to people that are just coming out of school/colleague/university, one needs to constantly keep taps on the latest trends and be aware of what tools there are to choose from.

Work and life can be quite juxtaposing sometimes, so it is important to be able to find time for hobbies and be able to make a clear separation between time that you are paid for and personal time. It is often the case that work seeps through everything you do leaving you with very little time for your own hobbies.

Conclusion

Crafting software takes hard work, dedication and experience. Software keeps on getting more and more abstract with focus on the actual goal that is being pursued while hiding the gory details behind nice facades. In order to become successful and keep on evolving as a developer, one needs to embrace failure and seek challenges. That being said I know many people that work as developers but don’t put that much emphasis on their job. They view it just as a job and that works for them. So frankly it’s up to the individual to decide for themselves - do they want to make the wheel turn or turn with everyone else.