Ecology of programming

    We are not talking about the benefits for the Brazilian forests of switching to electronic document management or turning off the Num lock to save energy. I want to talk about "ecology" as a broader (or, conversely, more specialized) concept, as the interaction of the developer with the development environment in the broadest sense of the word.


    It just so happened that, to my shame, I am very lazy. My second negative quality is impatience. I am too lazy to go to the computer in the room and share the folder - I better go to it via RDP and it terribly annoys me to wait until the computer turns on - I better leave it turned on for the night. However, as it turned out, both of these qualities are very, very useful for the developer.

    The first project I worked on depended entirely on web services across the world. Every day I had to start by connecting to a slow (because the faster one was already busy when I came to work) VPN, which used to fall off at the most inopportune moment. Web services were far away, so each launch of a project for debugging could take up to five minutes. The project was rather big - the complete assembly took about three minutes, plus the launch of two minutes (the services are far away) - it turned out, I waited five minutes to check if I changed one character in the line correctly ...
    It’s clear that I was too lazy to connect to the VPN and me annoyed the speed of the project launch.
    The most unpleasant of all this is that others were very tolerant of this, saying "what can you do." It literally amazed me - how is it possible to not even try to improve my not even daily - every minute work. I could not endure for so long - the idea came to my mind to write a “caching proxy” that would untie me from both VPN and external services, allowing me to start debugging as quickly as possible. Bottom line - my “proxy” was sold to the customer and now it’s almost used in production, and now I don’t need to connect to the VPN - customers were generous with site-to-site VPN (I want to believe that my weekly nagging about VPN also had something to do with it ) It should be noted that, alas, a lot of time passed from the idea to implementation, and the “proxy” was never brought to mind ...

    My next big task was to collect builds and put them on remote machines at about the same end of the world as services. Again, the activity was tedious and long - everything had to be done with hands. For a full day I managed to collect and put four builds - two hours on the build. And again, the management did not see (or did not show) that it was bad - apparently, it was cheaper than setting up a normal build process. I managed to persuade my superiors to give me time to create a build script. As a result - a script, in case everything is fine with the sources, assembled the build in 20 minutes, I just had to start the installation on a remote machine. Now this script is the basis of the build process for at least two projects ...

    I can also recall putting the repository in order - before that, I had to make commits into the project in five branches and, God forbid, someone would commit at the same time as you. And a small fix in the developer tool, which allowed us not to enter the username each time. And the ability to watch XML in a formatted form instead of raw text, and a macro for the studio, making it easier to find specific project resources, and much more.

    And to be honest, two things have always surprised me. The first is the humility of my colleagues, who for the most part did not try to change anything in the annoying, uncomfortable, and slow routines of their daily actions. That's right - the developer should be lazy. I am too lazy to do day after day that which can be easily mechanized and simplified.

    The second incomprehensible thing is how difficult it is to “sell” changes in the project ecology to customers and managers. On the other hand, of course, they are very easy to understand: a contribution to the environment is a very long-term investment, associated with the risks of "nothing-happened". However, from my own experience I can say that these changes are usually very cheap compared to the daily time and effort of each developer in the team.

    Now I switched to a new project, where again I see a bunch of "environmental" problems - and a script-hell for maintaining databases in working condition, and the lack of a dedicated server for performance tests, and a bunch of configs and magic passes for starting a server, and a mess in the repository , and the lack of kick-offs for new people on the team. And again - to all my exclamations, “How is it so?” I hear only “It’s always been like that” and I see that even if my immediate boss really wants to change something, I’ll have to bang my head against the wall again and again, trying to prove to customers that all this is necessary and can be changed.

    Also popular now: