On the self-development we can look from different perspectives. I mentioned many times in my articles how important is self-development in IT industry. Sometimes we understand self development as further training, gaining knowledge about new technologies and sometimes just as broadening horizons.

Over last 11 years I was a part of about 30 projects, working in structures of different companies and about 50 projects, working as a freelancer. Sometimes my contribution was very demanding, in other cases was short romance for few days. I can honestly say, that nothing develop us so much as work in real project. During the project we meet many unusual cases, that we wouldn’t have a chance to meet during training, workshops or learning ourselves. I always say that we can efficiently increase our skills only by writing code. Like in good RPG game - to level up your character you have to do plenty quests and kill enormous amount of monsters.

Length of service in the project

I changed a lot of projects. And I’ve done it quite frequently. The reasons were quite simple. Sometimes I bumped the wall and I felt that I cannot reach anything new in that technology. Sometimes project ended. Sometimes offer in new project were too good to go. I know that it looks like I am a big fan of frequent change of projects. Indeed I see a great value in widely understood change, but I can’t say that projects with long history of development are bad.

Little problems of little

When project is young we can’t even imagine problems that we would fight on further stages of life of it. Very often it looks like our next steps in project, depends on decisions that we made at the beginning. Let speak it out - selecting technology stack in project shouldn’t be vision of programmer. Team without experience will choose technologies which are modern, cool and which they are know.

During one of workshops, which I provided in last year, I talked with a team, who is responsible for project from 20 years. Longer than my whole professional experience. 20 years ago, when they were starting building this project, I was 14 and I didn’t have idea what I will do in my adulthood. Interesting point is that most of workshop attendants are still working in this project. Strong team, but also very bruised.

A quarter of a century ago technologies were totally different than now. Nobody heard about NodeJS, React, NPM or Typescript. Basically modern frontend didn’t exist. Requirement of that app were quite high - it was a bank app for managing clients accounts. Initially seemed that it be simple, internal project without any water effects. First release was exactly like this.

Over the years market of bank services changed. Communication technologies have developed. Smartphones have appeared on the market. All of those required changes. Business decided, that existing app will be the best place to handle most of new functionalities. New layers appeared, adding code, which sustain will became impossible in few years.

Above example shows perfectly, that we cannot foresee everything. Products have few life stages: from introduction to the market, through growth phase and maturity of product, to decline stage. In my opinion IT projects should be treated as products. Last stage, when we need to keep alive our product, is very enlightening. At decline stage usually we are working with legacy code, which is basically obsolete (with big technical debt). This code is just not replaceable with anything newer, because costs of that would be to high.

I wish everybody to be a part of that kind of project at least once in life. It gives very wide perspective and show why understanding past is so important.

Long experience in project isn’t always a source of pride. Many depends from challenges, that project gives us. It’s super when there is will to develop project or at least to optimize it. Projects, which only exist, without stage of active programming or refactoring are the worst place to self-develop.

David and Goliath

I had an opportunity to work in small companies, where whole organization counted 5 people and in corporations, where squad was count in thousands. Apart from the fact of company size biggest value is the project that we are realizing in organization. It’s worth to point that big projects in big companies have their own „time”. I am not thinking about deadlines, passing or achieving them. I am thinking about time, which is crucial to do something. In corporations this time is much longer than in small businesses.

Here’s an example from my professional life. In the past I was working for one of the biggest companies in the world - because of its size every activity had its own procedure. In most cases procedures were related to security or monitoring. I think that those are really important aspects, especially in companies from finances and personal data protection industries. Unfortunately some procedures, which should improve our work, often are blocker, especially in creative work. For access to code I waited more than two weeks (and it wasn’t the longest wait), project setup required additional packages, which were blacklisted, first task to do I received after almost one month - and it wasn’t anything, which needs senior level developer.

Why I am pointing this? Self-development in huge companies is often restricted by procedures. Working in corporations is connected with inability, which will touch us from time to time. Decision-making is blurred and it’s why everything lasts a long time.

To disenchant my opinion about corporations - I need to add as bigger company as bigger budgets. As bigger budgets as bigger pressure to aspects like: testing, performance and quality. In my opinion those layers give greatest opportunities to self-develop and understand requirements and technology.

So, small companies should be better. Personally I don’t like small companies - because of lack of time for everything, portfolio built on small clients and little budgets. In small companies teams usually are small or even single person. Self-development in those organizations is limited by team size and short deadlines, which are results of small budgets. **We cannot develop ourselves without confronting our knowledge, observations and work with others.**

One-Man-Army approach (one person responsible for everything in a project) leads to professional burnout and it doesn’t have anything in common with effective self-development. Decision-making by our own can be fun - I have it in my project of my website - but my website is a training ground for me. We cannot make lab or shooting range from app of our client (because we are taking money to make it work properly). Building app as single developer makes in us a lot of frustrations, especially when we inherited it from another single developer. This kind of apps are like bottomless bag with bugs, which were cleverly hidden in the code by previous devs.

Usually in small companies we don’t have possibility to learn from others. Unfortunately.

Dinosaurs

Did you hear about famous offers for COBOL programmers? Even few years ago proposed salary was bigger than average in our industry and it was about 30 thousands of PLN per month (30k PLN is mote than 7k USD). COBOL is grandpa among programming languages. Despite this, it is still quite popular. We can find it in ATMs, banking and insurance systems. It is pretty simple - it syntax is to be similar to natural language, like english. It’s a dinosaur and it’s not changing from years. Working in this language can give us very good money, but it brackets us for years and it is blocking our development.

It’s not only COBOL, but bunch of technologies. Also technologies that were created by companies for their internal usage. Inventing technology can be developing, but work with it - not always. Examples: Gosu language from Guidewire or ABAP language from SAP. By mistake we can close ourselves in a tiny golden cage from which is really hard to escape. Fortunately as a "billionaire".

Leadership

The most difficult task during preparing a project is building a proper team. I mentioned how important is to not work alone. But likewise important fact is who and how manage the organization, which is responsible for the project. Boss, who is difficult to deal with or, opposite situation, not so hot, can destroy every, even best, project. Sadly we cannot catch it easily. It’s worth to depend on our intuitive and run away from a toxic people. Work is work. Not home, not family, but also not prison or labor camp.

I wrote boss, but I wasn’t thinking only about owner / CEO of company. I would rather consider this definition wider - also as manager and leader - it depends who is managing the project and the team. I would like to emphasise that in my opinion managing is the hardest aspect. Manager can build nervous atmosphere or lighten it, he or she can be a supportive or encumber team with new duties, he or she can be for the team or against it. In my book manager has huge impact on development of team members and the whole team.

Summary

Against all appearances curious and developing projects we can find in any kind of company - as well as in small as in big. It’s also not the case how long we are working in one project - as I pointed above - sometimes it can be valuable experience.

Personally I am never choosing projects, where technology is little-known, manager is a bully and technical team has to by „dynamic” and single person. Finding this gem isn’t easy, but few times I did it. I won’t say anything bad about Software Houses or Interactive Agencies, because even there are valuable projects, but I prefer companies with their own products, where is bigger control on what and how products are deliver, where quality is an internal agreement between a technical team and a business.

Coming back into RPG games analogy. In game we will achieve moment, when game wouldn’t allow us to level up or cost of leveling is too high. Than is worth to redefine reached skills, rethink possibilities that they give us, because maybe we can find out new paths, which earlier seems unreachable.