Growth can be viewed from many perspectives. Each plane looks a little different. I have mentioned many times in my materials how important the aspect of growth is in the IT industry. Sometimes we understand growth as further education, gaining knowledge about new technologies, and sometimes simply as broadly expanding our horizons.

Over the last 11 years, I have taken part in creating around 30 projects while working within different companies, and around 50 as a freelancer. Sometimes my involvement was very demanding, and sometimes it was a short affair lasting only a few days. I can openly say that nothing develops us as much as project work. In a project we encounter many cases that we would have no chance to meet during training, workshops, or self-study. I always repeat that we can increase our level only by writing code. Like in a good RPG game - to "level up" your character, you need to complete a series of quests and defeat hundreds of monsters wandering around the area.

Time in a Project

I changed projects quite often. This came from several things. Sometimes I reached a technological wall where I felt I would not achieve anything more, sometimes the project ended, and sometimes the offer was too good to reject. It might seem that I am rather a supporter of frequently changing projects. And indeed, I do see great value in broadly understood change, but it is impossible not to appreciate projects that have many years of development behind them.

The Problems of the Young

In young projects, we will never get to know the problems that are fought at later stages of their life. Very often it turns out that what happens later validates the decisions that were made at the beginning. We have to say it openly - a programmer's whim should not decide which technology is chosen in a project. A team without experience will choose technologies according to what is fashionable, cool, and familiar.

During one of the training sessions I ran last year, I talked with a team that has maintained a project for 20 years. Longer than my entire professional experience. 20 years ago, when they were starting to build their project, I was 14 and had no idea what I would want to do in my adult life. Interestingly, many of the people I trained have worked in this project since the very beginning of its existence. A strong crew, but also one that has been strongly bruised.

A quarter of a century ago, technologies were completely different. Nobody had heard of NodeJS, React, NPM, or TypeScript. Modern frontend basically did not exist yet. The application's requirements were significant - it was a banking application responsible for managing customer accounts. It seemed that it would be a simple internal project without unnecessary fireworks. And that is how it was released in its first version.

Over the years, the banking services market changed. Communication technologies developed. Smartphones appeared. People started using online banking. All of this required changes. From a business perspective, it was decided that the existing application would be the best place to handle most new features. More and more layers were added, producing code whose maintenance would become impossible in a few years.

The example above shows very clearly that not everything can be predicted. Products have several life phases: from market introduction, through growth, then market maturity, all the way to decline. In my opinion, IT projects should be treated like products. The last phase, meaning the phase when our product simply has to be kept alive, is very instructive. In the decline phase, we most often deal with legacy code, meaning code that is so outdated, burdened with enormous and unpayable technical debt, that it cannot be easily replaced with something newer because the costs would be too high.

I wish everyone could land in such a project at least once in their life, even for a moment. It gives a very broad perspective and shows why understanding the past is so important.

Long time in a project, however, is not always a reason to be proud. A lot depends on the challenges the project gives us - if there is a will to develop it, or at least optimize it, then great. Projects that only continue to exist, without a phase of active programming or refactoring, are probably the worst place to develop yourself.

David and Goliath

I have worked in companies where there were 5 of us in total, and in corporations with thousands of employees. Of course, the project carried out within a given organization is still a major aspect. It is worth emphasizing, however, that large projects in large corporations have their own "time". I do not mean deadlines, exceeding them, or delivering. I mean the time that is necessary for anything to be done. It is definitely longer in a corporation than in a small organization.

I will give an example from my professional life. At one point I worked for one of the largest companies in the world - because of its size, every activity had a procedure prepared for it. Most often it was related to security or control. I consider these very important aspects, especially in companies that deal with finances or personal data. Unfortunately, procedures that should improve work often become limitations - especially in creative processes. I waited more than 2 weeks to receive access to the project, and this was not the company's record. Setting up the project required installing packages that were on the list of forbidden software. I received my first task after about a month - and it was probably not anything requiring specialist knowledge.

What does this show? Growth in huge companies is very often limited by procedures. When going to work in corporations, we very often have to expect a kind of powerlessness that will sometimes affect us. Decision-making is blurred, and because of that, everything takes a long time. A very long time.

To sweeten it a little, I will add that the larger the company, the larger the budgets. The larger the budgets, the greater the emphasis on aspects such as testability, performance, and quality. In my opinion, these 3 layers give the broadest opportunities for understanding and growth.

In that case, it seems that small companies should be better. Personally, I do not like small companies - because of the lack of time for everything, usually a portfolio of small clients, and therefore small budgets. Teams are often small or one-person. When it comes to growth in such companies, the last point I mentioned, meaning team size, is the biggest disadvantage of such organizations.

It is impossible to develop yourself without confronting your knowledge, observations, and work with others. One-Man-Army is a phrase that leads to burnout and in no way means effective growth. Making decisions on your own can be nice - I have that in the project of my own website - but my website is my testing ground. A client's application, for which we receive money, cannot be turned into such a laboratory. I am skipping the fact that building an application that someone else will take over in a few months, again alone, creates more frustration in a programmer than it actually develops them. Such applications are bags of bugs that were cleverly hidden by previous one-person teams.

In small companies, there is not always someone to learn from. Unfortunately.

Dinosaurs

Have you heard about the famous job offers for COBOL programmers? A few years ago, around 30 thousand zlotys per month was already being offered on average to people who knew this language. COBOL is a grandfather among programming languages, and yet it is still quite popular. We can find it, among other places, in ATMs and insurance or banking systems. It is also quite simple - its syntax was meant to resemble English. Even so, it is a dinosaur that has not changed for years. Working in such a language gives us a chance for good money, but it puts us into a box for years and blocks development.

I am not thinking only about COBOL, but about all technologies that companies built only for their own needs. Creating such a technology can be developing, but working with it is less so. Examples: the Gosu language from Guidewire or SAP's ABAP language. You can accidentally lock yourself for years in a rather tight cage. It is hard to get out of such a box later. Fortunately, most often you leave with a full wallet.

Leadership

The hardest thing in projects is ensuring the right team composition. I mentioned how important it is not to work alone. Equally important, however, is who manages the organization in which we carry out a given project, and how they do it. A boss who is difficult or, on the contrary, too soft, can torpedo any project, even the best one. Unfortunately, we are not able to catch this easily. Here it is worth trusting intuition and running away from toxic people. Work is work. Not home, not family, but also not a labor camp or prison.

By boss I do not mean only the owner or CEO - I treat this concept rather broadly: manager, leader, CEO - it depends on who manages the project. I will emphasize that, in my opinion, management is the hardest aspect. A manager can introduce a very nervous atmosphere or defuse it, can support the team or additionally burden it, can be for the team or against it. In my opinion, they have a huge influence on how the team and its individual members develop.

Summary

Contrary to appearances, interesting and developing projects can be found everywhere - both in small and large enterprises, while working for many years in one project, and while working for only a few months.

Personally, I never choose projects where the technology is little known, the manager is a despot, and the technical team is supposed to be dynamic and one-person. Finding such a gem is difficult, but I have managed to do it a few times. I would not like to say anything bad about Software Houses or Interactive Agencies, because valuable projects happen there too, but personally I prefer product companies, where there is more control over what is being produced and quality depends only on internal arrangements between the business side and the technical side. Unfortunately, this is not entirely a natural process when you are an intermediary between the application and the client.

Returning to the RPG analogy. A moment will come when the game will not allow us to gain another level, or when gaining the next ones will not be very profitable. Then it is worth redefining the set of skills we have acquired and thinking about the possibilities they give us, because perhaps we will discover new paths that previously seemed unreachable.