Programming ecology

It is not a question of the benefits for the forests of Brazil to switch to electronic document circulation or to turn off the Num lock to save electricity. I want to talk about "ecology" as a broader (or vice versa, more specialized) concept, as the interaction of the developer with the development environment in the broadest sense of the word.


It so happens that, to my shame, I am very lazy. My second negative quality is impatience. I'm too lazy to go to the computer in the room and share the folder - I'd rather go to it via RDP and I'm terribly annoying to wait until the computer turns on - I'd rather leave it 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 was entirely dependent on web services on the other side of the world. I had to start every day from connecting to a slow (because the faster one was already busy when I came to work) a VPN, which had the habit of falling off at the most inopportune moment. Web services were far away, so each project launch 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 (services are far away) - it turned out, I waited five minutes to check if I changed one character in the line correctly ...
It is clear that I was too lazy to connect to the VPN and I was annoyed with the launch speed of the project.
The most unpleasant of all this is that the surrounding people treated it very tolerantly, saying “what can we do about it”. It literally amazed me - how can you not even try to improve your not even daily - every minute work. I could not tolerate for so long - I had the idea to write a “caching proxy” that would untie me from both the VPN and external services, allowing me to start debugging as quickly as possible. The result is that my “proxy” was sold to the customer and is now used almost in production, and now you don’t need to connect to the VPN - the customers are generous with the site-to-site VPN (I want to believe that my weekly whining about VPN also had to do with it ). It should be noted that, alas, a lot of time passed from idea to implementation, and the “proxy” was never brought to mind ...
')
My next big task was to build builds and install them on remote machines at about the same end of the world as the services. Again, the exercise was tedious and long - everything had to be done by hand. For the full working day I managed to assemble and install four builds - two hours per build. And again, the management did not see (or did not file a mind) that this is bad - apparently, it was cheaper than establishing a normal build process. I still managed to persuade my superiors to give me time to create a build script. As a result, the script, in case everything is fine with the source, I built the build in 20 minutes, I just had to start the installation on the remote machine. Now this script is the basis of the build process for at least two projects ...

I can also remember putting the repository in order - before this, commits to the project had to be done 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 not to enter the user name every time. And the ability to view XML in formatted form instead of raw text, and a macro for the studio, facilitating the search for specific project resources, and much more.

And to be honest, I was always surprised by two things. The first is the humility of my colleagues, who, for the most part, did not try to change anything in the annoying, inconvenient and slow routine of their daily activities. That's really true - the developer should be lazy. I am too lazy to do every day things that are easy to mechanize and simplify.

The second incomprehensible thing is how difficult it is to “sell” changes in the project’s ecology to customers and managers. On the other hand, of course, it is very easy to understand them: a contribution to the environment is a very long-term investment, with “nothing-nothing-out” risks. However, from my 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 have switched to a new project, where again I see a bunch of “environmental” problems - and script-hell to support databases in working condition, and the lack of a dedicated server for performance tests, and a bunch of configs and magic passes to start the server, and confusion in the repository and lack of kick-off for new people in the team. And again - to all my cries of “But how is that?” I only hear “So it was always there” and I see that even if my immediate superior really wants to change something, you will have to beat your head against the wall again and again, trying to prove to customers that all this is necessary and can be changed.