At university, I loved the code. Now it has become a routine. How to return the former fuse?



    Reflection is a curious thing. Even more interesting if it is based on many years of experience. Under the cut story about the fate of the programmer through the mouth of the Director of Development Parallels RAS Igor Marnat from the first person. Enjoy!
    “If you do not move forward, then you are not standing still. The world is moving forward, but you are not. Thereby, you move back! ”. © (Someone very smart)


    Epigraph

    For me, programming has not yet become a routine, although I have been developing for more than twenty years. I think this is due to the fact that I took certain actions before my fuse finally dried up.

    If programming has become a routine for you, then perhaps my experience will be useful to you. Want something to change? It is necessary to at least change something (deep thought, isn't it?). We need to move somewhere. And so, at different times, I tried moving inwards, sideways and outwards. 

    Movement inward


    The peculiarity of our work is that each developer must be an expert in two areas - programming, as such, and in the subject area for which he creates software. The better and deeper the developer understands these two areas, the more interesting tasks he can solve. The more interesting and large-scale tasks, the more noticeable is the result. 

    Programmers, for the most part, derive their motivation from the upper levels of Maslow's pyramid — knowledge, self-realization, the need for respect. For this it is necessary that, firstly, the result of their work should be noticeable. Secondly, this result should see the light, it should be used by people. The visibility of the result is obviously closely related to the size of this result, with its value, weight.

    During the development of software for telecom, I invested a lot of time and effort in learning a new domain for myself: the device of general-purpose processors and DSP, memory, storage systems, network protocols, types of signaling, signal processing algorithms, in general, a lot of different interesting things from telephony, circuitry, networks.

    It took several years (during which I worked noticeably more than eight hours a day). Five years later I worked at the architect level, participating in creating the structure of the software of new telephone exchanges, the architecture of their components. I wrote less code, developing specifications for the team, reviewing complex code, working on some critical components, protocols and drivers. A good understanding of the structure of each component, its principles of operation, and communication with the others allows it to develop a product architecture, communication protocols, and external interfaces.

    Obviously, any software product is the result of the work of the whole team, but with my level of participation in the project I felt involved in the creation not of separate components, but of the whole product. Drive at the same time get incredible, responsibility is also more.

    In general, the deeper a programmer is immersed in the subject area with which he works, the better he has context, the wider his outlook, the more interesting he can do his work. 
    This applies not only to the internal structure of the product components. The better you know your users, the way they use the product, why, and not otherwise, what problems they have, how the competitors' products are arranged, the more interesting it will be for you to work.

    It’s easy to learn all this - you need to communicate more with support, testing, implementation teams, with end users of the product. If we manage to establish a working interaction, solve some tasks for them, participate in joint work, it is generally super. 

    By the way, there is one more remark about the organization of the workflow itself, which is followed, in particular, by the DevOps philosophy and the approach to development and operations known as SRE, which originally came from Google. It is necessary to strive to eliminate the division between the development, implementation and support teams, the movement towards teamwork.

    Just in case, I note that RFC, animal books on the cover, manufacturers documentation, correspondence in most open source communities use English as the standard means of communication. Information in translations is less, it is often distorted and almost always delayed. Many manufacturers do not bother translations documentation. Therefore, at a minimum, the ability to read books in English is a fairly basic, so to speak, sanitary and hygienic requirement for a developer who wants to develop. 

    Sideways movement


    In many ways, the interest of the programmer to his work is determined by the interest in the subject area in which he works. For example, you may be bored with working with financial applications, but it will be interesting to work on the infrastructure for the operation of such applications.

    In parallel with the development of embedded telephony software, I worked on a distributed system for collecting information and billing users - and this is a completely different world, other languages, other platforms. Next - automation of deployment, configuration and testing, this is the third world, everything is different again. 

    Perhaps to revive your interest, you should talk to a colleague or boss, see what the teams are doing nearby. Even a small step away from the usual activities can change a lot in your work, give you a different view of things. As they say, the point of location determines the angle of view.

    Movement in breadth


    As I immersed myself in telephony, it turned out that I did not have time to devote enough time and attention to other projects I was working on. The solution was obvious - I began to work even more. But it does not scale very much. With long work at night and on weekends, after a while, you no longer want to work, and there is no time to live. The chief and I made the decision to hire another programmer for our team. I rather self-confidently conducted a couple of interviews with a swoop (first in my life on the other side of the table), and I realized that taking an intelligent person to my team is not as easy as it seems. 

    How to understand a stranger in a short time? How to evaluate his professionalism and personal qualities? Are they generally important, these personal qualities? Or is only professionalism important? What do you need to pay attention to when hiring? And how exactly to convert it? Now it all seems pretty obvious, but when I hired the first engineer for me, it was a real dark forest for me. 

    As usual, I started with Google. I found several articles by Joel Spolsky, swallowed them, read the books to which he referred, then links from these books, went to study more systematically, and so, gradually, began to dive into a new subject area - project management, team, management of the development process itself.

    The software development process, like any other production process, has its own researchers, a history of development, best practices, and approaches to the organization. Many of its aspects related directly to the development, best engineering practices, are quite young.

    For example, agile appeared relatively recently, less than twenty years ago, CI - about thirty, the classic book of Frederick Brooks is about fifty years old. Other aspects related to team management, psychology, motivation, management of processes in the organization as a whole, organization of communications are universal, came from other subject areas many years ago, and are perfectly applicable in the field of development.

    I read quite a lot of literature on team management. It seems to me that this topic has been studied most thoroughly and deeply in America and Japan. In addition to classic books about development, engineering, management, I would recommend books by Soviet and Russian aircraft designers and missile designers. In addition, NASA, NAVY, Toyota - these organizations and companies invest enormously in the optimization of their processes, hold internal conferences for their managers, materials on them are available online, there are many interesting art books from them and about them. In addition, in addition to excellent information about the management processes built in these companies, it is just very interesting to read about cars, airplanes, rockets, ships and their development.

    In general, the scope for increasing its competence in the field of management is huge, the tasks are also very different. You can start with the organization of your own work, with the implementation of the best engineering practices such as unit tests, code review, continuous integration and continuous delivery, you can stop very far. And it's better not to stop :)

    Conclusion 


    Practice shows that if you begin to actively move in at least one of the above-mentioned directions, another movement will inevitably take place some time later - up the hierarchy. If there is such a desire, then this is also a very interesting option. The main thing is not to forget about the necessary balance between the organizational and technical work that you would like to keep.

    Software development - a marathon that lasts a lifetime. There are always deadlines, deadlines, all the time you need to push a little more. To save energy and motivation, to protect yourself from burnout, you must switch, raise your head over the routine, look around and look at yourself and your work from the side. Theaters, music, concerts, good books and films are mandatory for occasional use. Or cottage. Or hiking. In general, something other than work. Otherwise, in two or three years, work in any case will cease to be a joy. 

    As for work, no one will take care of your motivation and career better than yourself. Honestly, it's not that no one will take care better - just no one will take care. Books on the specialty, related areas, conferences, communication with colleagues, mitaps are a movement that, as you know, is life.

    If you feel that it is time to change something - you can start with small steps. You do not need permission from above, budget or work in a large organization. All the steps I wrote about, I went above in a small company, in teams of two to ten people. 

    A few good books, a lot of desire and a little movement can change everything for the better. Good luck!

    ZY Share your experience and life hacking in the comments. Unfortunately, Igor is not yet on Habré, I shake karma so that you can invite him. In the meantime, I will forward your questions to him, if any. Thank you for your interest.

    Also popular now: