Developer Evolution

This is a story about us . For those of us who have 10 or more years of experience in software, described in the article may seem familiar. And those who are still in the early stages of their careers will be able to find out what awaits them in the near and not very future, and get a couple of tips.

Transferred to Alconost
')

The first steps

The mechanism itself is not yet completely clear, but sometimes a spark ignites us - and we just fall in love with programming: this can happen after some university project, and after writing an application for our own use. After all, so much to learn, so much to try! In software development, there is a very short cycle of remuneration, which constantly raises the level of dopamine and makes us hook on programming. We’ve been bitten by a programming spider, but don’t worry: it’s not a disease - it’s just brain chemistry .

For the first time we are looking for an employer, and when we are hired, we think we are very lucky. At first, we are full of enthusiasm: we are ready to learn everything about everything and strive for it, undertake any task and do not object. By deleting items from the task list, we get the reward that our brain is looking for. And while we are learning and creating something new, we don’t really care about which projects and technologies we are working with.

However, at this stage of our career, we can ask too few questions. Usually, probably, people reluctantly ask questions because asking and acknowledging that you don’t know something is somehow embarrassing. For some, this may actually work like this, but sometimes we, the developers, simply prefer to spend many hours on a task, but solve it on our own rather than ask for help. Perhaps this is also a matter of the reward system: our brain likes to cope with the tasks independently, and there is no pleasure from the solution obtained on a platter of a particularly difficult problem. If this is about you, then still do not hesitate to ask questions: there will be many tasks ahead, and you probably want to gather as much knowledge as possible for the time spent on this planet, and asking questions is a great way to learn.

Absorb the knowledge of those who studied for many years on their own mistakes - priceless.

In addition, we tend to trust our supervisors too much and not hesitate to follow their advice. Do not misunderstand me: this is usually not bad, but it is imperative to check the information received, especially if it seems that something is wrong. Sometimes curators become a bit too self-confident and, perhaps, need a shake. Take time and write an example of what you think is an improvement, so that the curator can easily evaluate it: if you are right, your comment will be accepted, because the curator must be an experienced and intelligent developer. If this does not work or it turns out that you are wrong, they will help you to understand where you made a mistake, and this is a valuable lesson.

Another common mistake in the early stages is that the days fly quickly, very very quickly: we want to show how productively we can work, we write tons of code, and as a result, we are not even sure if we are moving in the right way. It may turn out that you are wasting your time, so stop, clarify requirements again, take a deep breath and work on the task more purposefully.

Ship to ship

For the first few years or even months, we reach a point when it begins to seem that there is no place to grow further on this place: the colleagues are no longer so competent, and the curators are not so special as it was thought before. We absorbed all the knowledge that we could, and we begin to look for a place where we can continue to learn fascinatingly.

We become a little more demanding when looking for work: we want to work where it will be possible not only to learn new and unfamiliar, but also to use our favorite technologies to create cool pieces.

At this stage, you can change a lot of ships, because on paper the companies look great, but from the inside they are pretty boring.

In the end, with perseverance, we again find a great place to work - or at least to meet current needs - and begin to work.

Unreasonably difficult? Yes, this can not be!

Gradually, we are developing, and if we are not very lucky, we have an obsessive desire to write perfect code. Refactoring after refactoring, and again refactoring: the code becomes more and more beautiful in your opinion - and less and less understandable for other team members.

Here is my advice : try to estimate how long it takes to write your own excellent object-oriented language or a general superabstract solution with a reserve for the future ( which is currently used only in a few places in the code base ). Also, double check what git diff says to you. Are you sure the code got better after refactoring? Usually, if you managed to throw out a large piece of code - this is a good sign. And you can always change your mind and postpone it for some time in a separate branch.

At this stage of our career, we are obsessed with showing the companies and the rest of the world how smart we are. We need this to get a portion of dopamine, thanks to which we sit in the workplace. Ordinary tasks are beginning to be repeated, and we are saved by spending time on improving what is already working - and at the same time there is not enough time for code that actually solves business problems.

Even if we have a proven method in combat that works well, we are still looking for “new” ways and invent magical improvements. We are starting to spend a lot of time trying to improve what is already working well enough and what the development team thoroughly understand.

In this case, you need to remember this: the code that works stably in “combat” conditions leaves more time to calmly evaluate new methodologies, advanced frameworks and experimental libraries. New mysterious problems in production is not very fun. Therefore, experiment on less important parts of the system or create several carefully tested side projects. This greatly simplifies the introduction of innovations: you can share achievements with colleagues, find out what they think about it, and ultimately achieve a smoother transition to improved solutions.

Often we fall into another trap: we strive to make everything work 100% of the time. We take into account all possible borderline cases and write tons of complex code for them ( which in fact can even make things worse ) - as a result, the code base becomes harder and harder to maintain. It may seem that this approach is the only correct one. However, sometimes from a business point of view, imperfect systems work - this is normal, so consult with someone for whom you are writing code: he may prefer to use resources and time to develop new functions, and if there is a problem, just send an email so that someone can figure it out with the problem manually.

Why are we led to the hype

In the career of a developer, the following happens: we decide that the world can wait, and we undertake to study something new - it can be a new language, a new framework, a new methodology, and even a completely new area of ​​development - well, or something still. And how do we make a choice, what to study?

It happens that some topic simply attracts attention - for example, because it seems that this is a solution to one of the current tasks. Sometimes we study something, because we think that the whole industry is moving in this direction. And sometimes the main goal is to get a better job.
The most difficult thing here is to learn how to distinguish a temporary hype from really standing technologies. The only advice I can give is to try the new one myself and check it for real.

It is not enough just to read the articles in blogs - take the time and dig deeper, make your own list of disadvantages and advantages of the technology. Find out if it really solves the stated problem?

After spending a lot of time studying frameworks and libraries, I realized that the most important thing is to keep them slightly on the periphery of the software systems being developed: if they have too many errors or something better appears, then they can be easily replaced.

The ability to find among the hype something really useful is an important quality of a good developer. New technologies are born every day, and no one forces them to use.

In order to grow up as a software developer, it is also important to give preference to operating in real-world code, rather than newfangled buzzwords in the resume. Sometimes it is not easy, and at the interview does not sound very cool - but for the company should be much more important to have working and supported software.

However, this does not mean that you have to stifle curiosity in yourself and stop devoting time to learning breakthrough technologies. We must try to find a middle ground: to be inspired by how newcomers enjoy new products, but at the same time understand that work must be done - and sooner rather than later.

Forward to the heights

Climbing up the career ladder, we become increasingly self-confident, so we often begin to seem annoying and less competent to younger team members and even supervised developers. We write the code less and less; Someone starts to think that the tasks assigned are too simple, and this only aggravates the problem. Try to do the opposite: give the rest an example and close simple tasks on your own - even if they are boring.

If the team has enthusiastic developers, it helps not to forget that you need to keep curiosity and continue to learn. We must constantly try new things: the professional experience gained even in a couple of years will help make more informed decisions about which technologies to use.

It is difficult to somehow summarize what constitutes an accomplished developer with a decade of experience. We tend to develop in different directions, but the same problems await us.

We are more likely to fall into the trap of careless development: at this stage, experience tells us that we should not rush into abstractions, since they will not be needed most of the time. Therefore, just remember that if a team does not like working with some part of the code base, this is a sign that the corresponding code was written carelessly and was abandoned. It may need to be rewritten, so pay attention to it when there is time to deal with technical debt.

Another danger lurks us - to become a victim of our own cargo-cults, which have managed to develop over the years. Be sure to question your beliefs from time to time.

A few words about modesty

Many years of experience do not provide absolute protection against bad code - constantly ask the opinion of others and ask to check your code. Sometimes I ask my wife (she is not a programmer ) to subtract my code - in order to understand if she can figure out what he is doing or not.

Surely you have heard it before, but I repeat: experience must first of all teach that it is impossible to know everything. Anyone can teach you something you have no idea about.

Do not give up

Every developer in his career has ups and downs. Someone begins to pay more attention to money, not to job satisfaction, and as a result, either works on a contract or receives a lot of money for uninteresting work . Someone in search of life without constant catching errors in the code goes to a managerial position.

Continuing to disassemble the endless stream of problems (and this is the essence of software development) is a hard mental work. Everybody had (or there will be) days when too much is coming in - and you think: “ Why am I doing this? Everything is very bad . ”

If it seems to you that it is time to change your profession, take a break. It’s usually enough just to go offline for a few days (or weeks). You will not believe how much it shakes: you will return and eagerly pounce on the code - you might even want to get into the jungle and disassemble the mess, which all did not reach the hands.


About the translator

The article is translated in Alconost.

Alconost is engaged in the localization of games , applications and sites in 68 languages. Language translators, linguistic testing, cloud platform with API, continuous localization, 24/7 project managers, any formats of string resources.

We also make advertising and training videos - for websites selling, image, advertising, training, teasers, expliners, trailers for Google Play and the App Store.

Read more: https://alconost.com