My observations may be useful to those who are still studying or have recently started working on projects, and perhaps even to those who have been doing development for so long that they’ve stopped thinking about it altogether.
1. Perfect code is not the most important thing
It may seem surprising, but writing code for a business project is a secondary task. The main thing is to solve the problem of the business or its users. This fact is not easy to accept, especially for people who are truly passionate about programming. This is where, for example, the problems of some successful competitive programmers are hidden. Having entered the market as developers, they sometimes continue to look for a unique ultra-efficient algorithm when there is already a proven solution.
I worked in my first startup at the age of 15 to 16. There simply were no other developers in the startup. It was difficult to resist the desire to find the perfect algorithm, especially when I knew that I was still going to meet the deadline. But now I’ve changed my position: if you decide to write something of your own creation, then do it only if it’s unique, and cannot be replaced with a ready-made solution.
2. You and the product influence each other
The Google Software Engineering book explains the difference between development and engineering. In fact, this is simple and does not involve a demonstrative rejection of ready-made and proven solutions. If you are writing a product that will still work ten years from now, you are a software engineer, but if your product needs to be rewritten in a year, then you are a software developer.
You need to choose which one you’ll be. And think about the people who will use the application and work with the code after you. Save your creative energy for unresolved problems.
3. You need to get used to teamwork
I worked alone for many years. I started with visual programming at the age of 12. Then I moved on to C# and Java, then HTML, CSS, and JavaScript, and after that Android. I worked as a freelancer doing websites. Then I worked single-handedly on Android development in a startup.
When I switched to the software outsourcing industry, I tried working in pairs, and immediately appreciated how joint development, even with two people, is different. You can no longer change your code whenever you want because you can't be sure that interference won't ruin things your colleague depends on.
4. Treat other people's code with care
Many programmers do not like to look at someone else's code. It looks worse, simply because it is different. I usually have the same first reaction: “We need to redo it!” But I try to fight this desire. Bringing your own experience into the code is a completely different matter. It's cool when a review offers a solution that you could never have thought of. The main thing is to learn how to formulate your comments.
Instead of statements, I would recommend using questions like: “Why did you choose this particular solution?” Because in writing, where you can’t smooth out the effect of your intonation, any affirmative sentence can be perceived as being imperative. and even aggressive.
5. The main soft skill is responsibility
I plunged into the professional environment quite abruptly and at a very young age. Therefore, it was a revelation to me that, having promised to do the work on time, you can’t just say “I forgot” or “I didn’t succeed.” I had to get used to the fact that there are consequences for a broken promise. Not in the sense that you are fired, punished, or scolded. But in the sense that the client's application crashes or your team can’t do the demo in time.
6. Soft skills are not equal to life experience
Like any other skills, they are formed from theory, analysis, and application in practice. It's just that the ratio of these components here will usually be different than in the case of technical skills. But this is also largely determined by the reluctance of people to study theory, of which there is quite a lot written about soft skills.
For example, there’s a book by Robert Martin called "The Ideal Programmer", which, like other books by this author, is worth reading for all IT specialists. This one is more devoted to interactions with people than with technology, and on one occasion it helped me a lot. I also recommend that you read books about corporate culture, e.g. “No Rules” about the rise of Netflix. It does a great job of explaining what commitment is and why it’s better to be honest.
Тhe problem with soft skills for an engineer is that communication is not idempotent, which we normally prefer. Idempotence means that a function can be applied multiple times without changing the result, and that doesn’t work with people. They react to the very same action differently.
7. Failure doesn't mean you're a fraud
Probably the most important thing I've learned in clients’ projects is not to take defeat personally. This is necessary for programmers with a heightened sense of guilt, which I suffer from. At my first job, in a startup, it helped that I, as the only developer, was responsible not only for all the failures but also for all the accolades. I had to remind myself that only those who do nothing don’t make mistakes, and without me, there would be neither failures nor the project itself.
