How to achieve a lifelong career as a developer

You want to spend your life as a developer. You probably have a lot of questions about how to achieve this – I have collected some of them and will attempt to answer. First though, let me give you some information about myself, so that you know what qualifies me to respond to these questions. 

It may well be that no-one is sufficiently qualified enough to answer all of these questions properly, but it is certainly worth giving it a try. What I can tell you about myself is that I have been writing code since the age of 14. Now in my fifties, I have over 35 years of coding experience under my belt.

Furthermore, my career has spanned many roles, several of them not directly related to coding; nonetheless, I have always continued to write code, and coding proved to be my secret weapon in ensuring I performed well in the non-coding roles I held. As a consequence, I probably have enough experience to have something useful to say!

Should I pursue a career in software development?

As you probably already know, software development is generally a well-paid job. Furthermore, it is a job that involves a lot of creative elements, making it a desirable occupation for many people. It is no surprise that the number of people getting involved with software development is constantly growing.

However, programming is not for everyone; it requires some specific talents and abilities that not everyone is gifted with. Just wishing to be a class=”textannotation disambiguated wl-thing” itemid=”http://data.wordlift.io/wl01770/entity/software_developer”>software developer is not enough to become a decent one – you need to start out with some talent of your own.

Some people say you need to be good at maths. I do not believe this is true – or at least not entirely. Programming and maths share the requirement of applying strong logic and the need to be formally accurate. However, while maths usually deals with numbers, and strives to produce numeric answers to problems, programming is more concerned with producing textual or graphic answers to non-numeric problems.

Also, mathematics generally focuses on producing simple and synthetic solutions.  In programming, taking the longer route is often appropriate – it’s acceptable to be verbose and descriptive, and to do more coding work in order to express your solution clearly.

Programming is mostly about the ability to find an operational solution to a problem, and then provide a precise description of the steps required to carry it out. Many would-be programmers fail in visualizing the solution, even if they intuitively understand how to solve a problem. Others, while they can express a solution to a problem to some degree, are unable to be precise enough in describing the solution to a computer.

So, what specific talents do you really need? In my opinion there’s an easy way to check whether you possess the right talents to be a successful programmer – just try to write some code to solve a problem! I wrote my first program simply by following a few pages of instructions that described the BASIC programming language.

I would recommend learning a few instructions in any programming language, then using them to see if you can solve simple problems. If your neurons can create a working model of what you need to do and you can translate that into code, then you probably have the gift.

If a simple problem is too complex for you to tackle in code, beware: a professional programmer is expected to sit in front of a computer for countless hours doing precisely that.

Is 40 too old to start a career?

To be honest, the role of developer is frequently one held by younger people. By the age of 40, the expectation is that one should be at least a senior developer, if not a technical leader or a software architect already. However, there are a couple of things worth mentioning on this subject. 

Firstly, I have met at least a few people who moved into a development career late but nonetheless successfully, mostly because they realized it was a better choice than the career they had previously pursued. Secondly, how fast you achieve seniority is mostly related to your talent.

If you have a burning passion you may have what you need to be a senior within a couple of years, while others will take 10 years to acquire the necessary knowledge. Once you’ve achieved that status, you have all the time in the world to move into management roles.

What is the best technology to learn on?

In my opinion there is no single ‘best’ technology to learn on. In IT, the underlying concepts are usually very similar, while the fields of application are vastly (and frequently) variable. You should really cover the basics of one programming language (I would suggest considering either Python or Java) and learn how to write algorithms. Once you’ve done that, the rest is just field practice.

Generally, you need three months of practice in a given technology to become fluent, but anything more than six months rarely makes a concrete difference. In fact, since technologies change very rapidly, I would suggest that you should avoid (and I mean this seriously!) any technology that is too complex to learn in more than 3 months. 

Let me be more specific: it is a good idea to invest years in universal concepts such as algorithms, architectures, or patterns. However, I would not recommend investing more than a few months in frameworks or libraries. These change frequently and you will have to re-learn them, so putting a lot of effort into these areas is just not worth it.

There are a lot of very complex frameworks that can take years to learn – I suggest avoiding these, even if learning them appears to lead to a great pay packet. This may be the case, but how long will such frameworks – and the associated pay – last?

The more complex those technologies are, the slower they will be updated and the faster they will become obsolete. 

How do you survive beyond 10 years in the industry?

You will only survive in the industry for more than 10 years if you keep learning. The problem is choosing what to learn. There is a difficult compromise to make; on the one hand, you should not go after every new thing that appears on the horizon – many of these technologies will not be widely adopted and will eventually disappear.

On the other hand, however, you cannot afford to wait years to learn.

So, the most practical approach is to investigate any and all tools and techniques that start to emerge, particularly those that only a few people (but definitely not just one person) are pursuing. You need to reserve part of your time for continued learning. 

You should also focus on learning things that work in ways that are significantly different from what you are used to. If you use a particular library and the competing library (there is always at least one!) improves in a specific direction, your library will soon catch up. A small improvement may not be worth switching. On the other hand, you will see new fields of application and new tools. These are the new directions worth pursuing. 

You need to view trying something new not as a ‘risk’, but as an investment in maintaining your skills and keeping them to date. If you delay learning new skills too long, you may end up in a situation where your current skill set suddenly becomes obsolete and you will have to rush to make a switch. If you are prepared for this moment, it will be easy.

Otherwise, you may find yourself out of a job and not ready to embrace the ‘new thing’ that has become a ‘must have’.

What can I do with 15 years of experience?

The more code you write, the better you will understand how larger systems work. Over time, you experience different use cases and face new challenges. In the process, you will develop a good understanding of what does and does not work.

I believe that this latter ‘negative’ knowledge is really the core prize of experience. To understand what I mean, imagine that you are a soldier parachuted into enemy territory who must survive to return safely to his base camp.

If you have experience, your chances of survival are much higher. Your experience, both direct and indirect (knowledge of other people’s disasters) will help you to avoid forests in which you can get lost or closed-off areas where you can easily be surrounded, and you will keep a careful watch for minefields because you know to expect them.

Your knowledge of similar cases may allow you to report your position without being discovered and enable you to move to a place from which you can be rescued, without asking your aides to take too many risks. Even if you make mistakes, you may be able to recognise your error early enough to remedy it before it becomes a catastrophe.

An inexperienced soldier is much less likely to go all the way. He immediately makes huge mistakes; he doesn’t get far before he allows himself to be discovered and captured. He does not survive. Experience helps us to avoid big mistakes and allows greater progress in a treacherous field in which it is easy to make fatal mistakes.

How long is too long at one job?

It’s definitely a bad sign when you are not learning anything new, and, perhaps even more importantly, you are not evolving and keeping your skills and knowledge up to date.  

One important thing should be underlined: if the job you are doing is healthy and well managed, the technology stack needs to continue evolving. This happens because, as technology evolves, so must the product you are working on. Consequently, if the process is healthy, you must refine your skills to match the evolving needs of the project – this is a requirement of the job.

Unfortunately, this does not always happen, typically when your product does not generate sufficient revenue.

Sometimes, sadly, revenue generation can be fine, but the stakeholders are too greedy to invest in development, or too short-sighted to anticipate evolution, choosing instead to stick to what brings in money, and delaying any investment or improvement until it becomes a matter of life-or-death.

In such environments you will face long periods of stagnation, where you do the same thing all the time, and spend countless hours fixing bugs or creating a flood of unusual fixes to work around well-known problems (instead of a healthy refactoring).

This continues until the stressful moment arrives when absolutely everything has to be updated all at once.  At that point you must learn new tools and techniques – and apply them – immediately, and without sufficient time available to learn enough to apply them properly.

In such situations, when you reach a point where learning stagnates, it is probably time to consider a switch.

Is software development really a dead-end job after age 35-40?

Yes and no. As I said, pure development of simple applications is usually performed by younger people. Older team-members are generally expected to be mentors – senior developers, technical leads or architects.

However, what software developers do is also hugely variable. Many companies do simple development tasks on a large scale, so the job is repetitive and sufficiently simple that it is more economical to use less-skilled developers for this day-to-day job, and older developers for management tasks.

Yet, there are also software companies producing very complex and advanced software, and coding experience is never enough in this situation. In companies like these, you could spend your entire career writing code, happily being faced with a never-ending stream of new challenges.

In a sense, programming is never a dead-end job. But you may have to develop your skills and change jobs if you want to stay in the role, moving towards companies carrying out more complex programming.

Alternatively, you can accept the evolution of your role and shift to non-coding roles such as architect or technical leader. Even if you don’t code, keep in mind that programming is never absent.

You may not write code directly, but you are required to understand, anticipate and describe the code to be written. Your role is to guide younger developers towards the implementation of a vision of the big picture  – a big picture that, if you are up to the role, you should have clearly in mind.

Is programming a dead-end career?

Definitely not. As already discussed, you can continue as a developer until retirement. Other options include moving into technical management, or creating a startup.

Almost every developer tries at some point in their life to found their own company or join a startup. In a sense, I believe this is the culmination of a career as a developer, assuming other roles do not satisfy you.

Founding a company is part of the normal evolution of a developer. While you must keep in mind that the odds are against you, in my opinion everyone should try to work in a startup at some point in their life.

My advice is never to risk your own money, though. Make a choice between risking your time (working for peanuts for a while) or investing financially in the company, but the stress of being both founder and principal investor is often too much for many people, and everyone should be aware of their own limits. 

Don’t forget that becoming Elon Musk is not something you can plan.

Although many people believe there is a formula, most of the time these start-up ‘superstars’ become what they are because they were extremely lucky and either had or found the right connections.

Instead, consider a startup as an option – perhaps the first option – but be prepared to fail and return to your life as an employee if your startup doesn’t succeed.  Alternatively, you could try again with another startup idea, if you found you enjoyed the ride!