The tortuous path of the developer

Learning programming is a lifelong undertaking. Almost always will come across something new, the existence of which you still did not know.

I communicate with a large number of students studying computer science, and many of them believe that they will learn programming at the university, and then they will simply go and apply this knowledge in their work. Perhaps they comprehend some business knowledge in the process. But professional programmers will immediately realize that they are completely newcomers, these university graduates.

After talking with @PrototypeAlex , where we discussed the many stages that developers go through, I had an inspiration to write about it. For the 30 years that I have been writing code, I went through almost every stage described in the article, and some were especially painful.

Do you recognize yourself at any of these stages? And what did I miss? Many stages slip out of my sight; we never stop learning and making discoveries.

Great Copipaster

Writing code is difficult, but people have solved the problem for you! Your browser goes to Stack Overflow as you type "s" in the address bar, and you insert hours of code fragments to see which one does what you want. Sometimes it sucks up moral strength, but in the end you get at least some working code.

What you will understand: you will understand that the only way to learn how to program well is to work through the tasks yourself. Even if it slows down your work, you only access Stack Overflow a couple of times a day. Your programming skills are improving and now you are working much faster and much less dependent on code written by others.

Successful Methodist

You have learned to write code that does what you need, but nothing works the first time. And the requirements are constantly changing. You stick in some code and dig in it until it works. Works? Release! You are incredibly productive, and you are praised by the product manager.

What you will understand: the code is read not only by computers, but also by people. You start working on projects with other people, and they climb onto the wall every time they read your code. You have not written a single test, and they cannot even refactor the code and improve it without fear of breaking.

You understand that a waste of time trying to make the code cleaner can slow you down, but if you do, your code can be easily maintained in the future. Your teammates will be happier from working with you, and you will ensure the long-term value of your company.

Smart Coder

Now you know the different techniques of your favorite language and can compress some part of the code into a reasonable, small method. You sit relaxed and praise yourself for how compact it is! Look, what a cool code, how it emphasizes your skills.

What you will understand: sometimes it seems sufficient just to be smart, but - it turns out - this does not affect social relationships too well. Other people's brains do not work like yours, and despite the fact that they are good programmers, they cannot immediately understand your smart code. It is much better when your code has clearly defined concepts for all who read it. Your "smart" code now has a place in all sorts of puzzles and puzzles such as code golf.

Commentator

Others need to understand your code, so you need to check that it is very well commented. You explain what happens every few lines. Everything is so adapted for reading!

What you will understand: many comments do not accurately describe what the code does, and this makes it surprisingly hard to read. You decide that you will use comments to explain why the code is written exactly as it is written, and not to describe what this code does.

Now your code is easy to read, uses descriptive variable names and a lot of exactly named methods. Your high-level methods are now read almost like English! And comments are inserted only where it was impossible to make the descriptive code itself.

Code Refactor

This is a crap code. He inherited more than five years, we need to get rid of it and start a new one. Seriously, we can write much better. With the new it would be much cleaner and easier to work.

What you will understand: profit from the "outdated code" - this is what forms your salary. At the moment, you have already worked with several code bases and realized that there are no full-fledged, unspoiled places in the world: you know that there is always technical debt.

Now you minimize refactoring and make it part of daily changes, affecting only what is needed to send these changes. Periodically, you provide support for small refactoring projects to get rid of the worst and most affected parts of the code base. You are trying to ensure that the new code is well designed. You understand that factoring requires a good business case.

Adherent 100%

You have an editor trained to automatically control the quality of the code according to the standard, and each time before a commit you start checking the metrics to make sure that the “code is good”. Everything that you write is necessarily tested, and tests cover 100% of your work. You get a warm, cozy feeling from the knowledge that all your work is quantitatively magnificent.

What you will understand: although most good code has good metrics, you will find that not all code with good metrics is good in itself. You’ll understand that you relied on metrics, standards, and best practices too much, instead of using your skills to test how good your code is.

Now you actively use your brains to write beautiful code, re-read it when you're done, and use code-review to make sure the right way. You have comprehended the principles behind the boundaries of instrumental measurements, instead of simply trying to write code that extracts a certain number from a tool. You are still using the tools for metrics, but at the level of the entire code base to get a general understanding of the state of the code and what you can pay attention to in order to improve it later.

Passion for trends

Using the latest technology makes your code ultramodern! You like to apply everything new to production code. You use the functional Ruby programming style, and you are the first to use NoSQL for the application with the formers. These new technologies are much more productive and elegant. This is such an exciting experience, and you know that you have become very valuable to your employer. You definitely will not stay on the back of the story.

What you understand: a passion for trends is cool, but it pulls problems. You spend a lot of time bypassing the borderline cases and using the new technology, which no one else is really familiar with. There are not too many support or libraries available for the new framework, and there are also people with experience using it that you could hire. One of the end products had a state of failure, in which some data was lost, and this was a professional disgrace for you.

You realize that using traditional technologies for end products brings great value to your company, even though it is a more boring way, because you really liked the new technology. In the evenings, you tinker with toy projects, fueling your obsessive joy and skills until the trend is high enough for your business to rely on it.

Fan of Patterns

Smart people have come up with elegant patterns to describe good code, and you use them in your code. All the time. Many conversations with colleagues are reduced either to the use of a better pattern, or to how it would be possible to write something better, with another pattern. You know that with this approach, the smart people who have developed these patterns will love your code.

What you will understand: watching that your colleagues do a lot of work during the time that you manage to run only on trifles, you realize that maybe you are too carried away. In the end, the pattern is just a rough template that preaches nothing, but simply guides you to do something useful.

Now that you have learned these patterns, you can stop thinking about “implementing the X pattern” and just write code using intuition and experience. Thanks to this you can produce a lot of useful code. (And your colleagues are happy that you stopped talking about patterns).

Premature Optimizer

Monolithic applications are not elegant, and your architecture is so sophisticated. Small micro services, each of which controls one feature of the application, with a smart messaging solution are the obvious way to develop a new application. You start as if you’re going to continue along the same lines, and this ensures that your application will be scalable.

What you will understand: you will find that micro services greatly inhibit development, giving rise to all sorts of difficulties that you would not have encountered in the monolith. You are thinking that you could enter the market much faster, and, of course, make money in order to finance the development more quickly if you started with a simpler design.

Since you worked in large teams, you know that having more than forty people working on the same code base is a complex configuration: everyone needs to know everything about the system in order to work with it effectively, and this does not scale. Now you see the pros and cons, and postpone the decision to refactor services until it makes economic sense.

Oracle

Your code is great. All you talk about it. To you show professional respect. Colleagues are built in line to your table, in the hope of hearing comments about their code. You have a stressful job because of eternal employment, and you are concerned that the company is holding on to you. When you are sick, bad things happen.

What you understand: you understand, being an oracle is a bad idea for the performance of your organization. Instead of quietly sitting and writing great code, you spend time on actively training your company's developers. You write a lot less code, and for this reason your team’s performance drops. But you understand that if you can raise the level of skills of each developer, together they will write code that you didn’t have time to write, and then they will surpass you.

You will find that developers have become more confident in making their own decisions, and, although sometimes not the right ones, they learn from their mistakes and become excellent developers thanks to your mentoring.

Defender

You are one of the senior developers of a large organization or a leading developer in a small one. You help make business decisions and train your developers to be great. But management or clients always find a way to make bad decisions, and you have to protect your team from their incompetence. They want to implement meaningless, stupid functions or components that complicate the code. You spend a lot of time fighting with them, protecting your code and developers, and sometimes ruin your relationship because of your passion for keeping a happy team.

What you will understand: having destroyed a decent amount of relationships, you realize that the existing code and work is a merit of management and customers. You come to the conclusion that sometimes people without a technical background cannot foresee the technical consequences of their requests, and make it their mission to become part of their team, give them valuable information and advice so that they have the opportunity to make the right choice. The only way to form a strong and trusting relationship with them is to behave as described above.

Once you speak out, the best strategy is to get out of their way so that they can make the right decision for their business. You will always be there to support them, if something goes wrong, but in the end it turns out that quite often everything goes well, because you have built excellent relationships, and the worst decisions are cut off at the root.

(Translation by Natalia Bass )