Aging in IT

It is great to be a developer: constant emails with job propositions, able to get a new job whenever you want. The world hasn’t enough developers, which puts us in a great situation.

Not all is great. Technology moves fast and we are constantly being bombard with new programming languages, new methodologies, new tools. There is a constant need to updating our knowledge. What allows us to have a good salary today, might not be enough to get a job tomorrow. The younger minds fresh out of the University urge us to be constantly learning.

Management path

Not long ago, a management position was seen as the natural progression from a development position and the ones who didn’t make it, were not good enough. I recall a manager saying he wouldn’t hire a 40 years old developer, because there was something wrong with him/her.

People feel the management path is a getaway card from the mosh pit of technologies. I believe some developers with big potential on the technical side prematurely moved away from development to become average managers.

Fortunately things are changing and the technical path became distinct from the management one and as prestigious. This deepens the question: As developers, how can we age in IT?

Gaining time or wasting time

If you have been long in enough in Software Development, you know most of software complexity is accidental: unnecessary complexity added by developers, unrelated with the problem it is solving. Many argue differently, I most note here.

The reality can be seen on your every day. Pay attention to how much time you spend understanding implementation details, compared to understanding the problem it is solving. The difference is easy to spot: Business related people don’t know and don’t care about implementation details.

Some added complexity is always required, as Software Architecture: not business related, but fundamental. Usual it is not the case, we overdo it: that special file having to be “touch”ed, apparently unrelated HTTP requests having to be done by order, a configuration change to a service breaking another service.

Unless you want to become an Oracle developer, this specific type of knowledge is of no use outside the company. As a less experience developer, it benefits you and augments your knowledge, but after a while you are just wasting time.

Keeping up

We have a huge volume of information available to us and can be overwhelming. Without a strategy, researching and learning can be time consuming and frustrating. It is hard to pick the best sources of information.

We have blog posts, feeds, tutorials and every little piece of information we find over the internet contain the most updated information we can get. Very useful to keep us updated on latest technologies and trends. The information volume is massive and volatile. The time window to consume it is small. Provides a fast and cheap way to learn the basis.

Word of mouth is another useful source of information. It can be from work colleagues, meetups, conferences, … This kind of information is more deep, as people give their insights, based on experience. It can save weeks of erratic research and experiment. The communication channel is very rich, as questions can be asked or even have a conversation. Nonetheless, it is second hand knowledge, as people present their own interpretation. It is limited in time and amount of information. Contents presented on conferences have relevance and speakers expertise on the subject.

(Good) books provide stable, relevant, accurate, complete information and deep theoretical knowledge from great minds and distilled years of experience, that you can’t find anywhere else. The good books are easy to spot: everyone says they have read it. Those ones provide directions to other great books and authors. With time, you notice certain books are always referenced. Those are a must read. If I randomly pick one of my books, chances are “The Mythical Man-Month” [1] or “Design Patterns” [3] are referenced. Don’t just say you read them, actually read them.

Different types of skills

Looking into a job spec, what stands out are years of experience on specific technologies: it’s the easiest way of accessing a developer’s value and get faster return of investment on the salary to be payed. Salaries are based on future income expectations. Hiring developers new to technologies will require more time to achieve the same productivity of experienced ones and they might leave before reaching the break-even point.

The constant need to stay up-to-date with the latest technologies and thickening the CV are important to stay relevant. Are those the only important skills on a developer? I see a few influential skills to the developer’s value:

  • Low level technical skills – expertise on concrete technologies
  • Higher level technical skills – theoretical and abstract knowledge
  • Individual personal skills – ability to solve problems and situations
  • Interpersonal skills – communication and interaction with other people
Screen Shot 2018-06-16 at 9.29.45 PM
Different types of skills

Low level and high level skills are technology related. Individual and interpersonal skills are more people directed, usually called soft skills. All skills evolve over time and have different characteristic:

  • Durability – for how long it stays relevant
  • Learning time – time taken to reach a certain level of expertise
  • Applicability – how useful it is across different companies
  • Pay-off time – how long it takes to get results
Screen Shot 2018-06-16 at 10.35.40 PM.png
Difference between skills

Low level skills are the easiest to achieve. Take a look at container technology: after one day we are able to create a container and apply it to the problem at hand. Understanding how everything works is a different matter: requires knowledge on operating systems, networks and hardware. For every day common problems this deep knowledge isn’t important, but sometimes it makes the whole difference. On the long run, it will avoid huge mistakes and headaches.

Anything people related is timeless and extremely applicable: people don’t change that much and no matter which company or industry you are, people are a constant. Soft skills are very durable and broadly applicable.

We walked on the moon and made transistors as small as atoms, but still not fully understand the human brain. With no surprise soft skills have a steep and long learning curve. Building relations and adjusting to new environments requires time, taking longer to produce results than simply writing code.


Shuhari is a three words agglutination, where each word represents the different levels of learning to reach mastery. The concept highlights mastery is not achieved over night, it requires time and practice, plenty.

Often we are betrayed by our own nature, described by the Dunning-Kruger effect: “people of low ability have illusory superiority and mistakenly assess their cognitive ability as greater than it is”.

Young developers feel proud and knowledgable from writing applications that work. Making applications that work is not hard. Hard is to constantly incorporate new changes on a ever growing complex system, built simultaneously by several people, keeping existing functionality undisturbed [2]. This is Software Development and requires experience.

To better illustrate the concept, nothing better than use books on a specific subject: programming.

  • Shu – “Data Structures and Problem Solving Using Java” – Introductory knowledge about algorithms, specific to Java
  • ha –  “Design Patterns” [3] – Pre-made solutions to recurrent problems for Object-Oriented programming
  • ri – “Domain-driven Design” [4] – Modeling complex problems, segregating business from technological problems. It is applicable to all Software Development


Can someone over 40, with a family, not become obsolete? If instead of chasing every new technology, we focus on master a few ones, makes it easier. Investing on more durable, longer term and broader applicable skills help us stay relevant and ahead of younger fresh minds.

Robert Martin has been around longer than me and he says things haven’t changed much since Alan Turing [2]. I wouldn’t go that back, but main programming paradigms already existed by 1970. New languages are based on already existing ones, with a new twist. For example, if we understand the principles and ideas behind Functional Paradigm, we will prepared for any new functional flavors in the future.

Improving is not increasing the number of lines in the CV. I’ve seen many developers calling themselves polyglots, without fully mastering any of the programming languages. My litmus test to determine if I’m still improving: if I look back on the past and don’t think I was dumb back then or didn’t knew nothing what I was doing, it means I didn’t improved.


[1] “The Mythical Man-Month”, Frederick Brooks, Addison-Wesley, 1975

[2] “Clean Architecture” – “Introduction”, Robert Martin, Prentice Hall, 2018

[3] “Design Pattern”, Gamma et al, Addison-Wesley, 1995

[4] “Data Structures and Problem Solving Using Java” Mark A. Weiss, Pearson, Oct 2009

[5] “Domain-Driven Design: Tackling Complexity in the Heart of Software”, Eric Evan, Addison Wesley, 2003


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s