Two sides of a coin

The better you do the automation, the less the developer needs to think and learn to make it run. So, is the automation of tasks actually bringing us forward or the need to think less makes us simply less knowledgeable? Is the fact that we don’t spend time on daily tasks give us wider possibilities, or is it putting us away from the need to think?

Build tools, automation tools, configuration management, virtualisation, abstracting out hardware and network - the purpose is to make the life of the developer easier and let him/her concentrate on the coding. Instead, one might end up spending most of the time on integration/maintenance of the tools and organizations end up opening departments just for that and hiring concrete tool experts.

My strong believe is that our mind power and the technologies, that are the product of it, are given to us, just like the earth is given to us and it is up to us to decide what we do with them. One can get stuck wasting his/her time in Facebook and getting less and less intelligent every day. Another person can use it as a source of inspiration/technology/news/collaboration. One can keep polluting the surroundings, never caring about the nature, or can embrace it in a non-harmful way. One can keep posting photos of their food on social media, or they can use it to spread awareness on important topics.

Same here - you can do docker run and have no idea what it is doing underneath, and keep wasting time on trying things without understanding them or you can choose to understand the internals once, so that you can use it better and get more results out of your tools.

It is also about how the tool is presented. Some of the tools (like I believe docker is one of them) are putting their effort into spreading the word around - enabling people to really dig deep and understand the internals of the implementations, being accepting when someone is just starting in the field of contribution and helping them get their pull requests merged. And that is how the tools should evolve. We need that kind of tools, that would enhance learning, that would make the developer think about the delivery and infrastructure more, that would remove the edges between “ops” and “dev” and bring us towards truly cross-functional full-stack engineers.

Most of the commercial tools choose to go the way of hiding the implementation and selling the support. Sometimes I feel the documentations they have are deliberately complicated and cumbersome. And that is stopping the progress. The people, and their poor decisions. And not the tools themselves, not the ones who sit their for hours putting their education and mind to build the technologies that move us forward and automate the daily tasks for us.

One of my colleagues, after hours of struggling with getting “the thing” deployed in a docker container (and to be fair the thing was complicated, old and had a lot of building bricks) stated: “nowadays developers spend more time on the tools rather than on the code”. Is that indeed so? Are we wasting our time on the tools, instead of getting the real benefit from them by avoiding the repetitive work?

My thoughts on that are, that the definition of the developer has now lost it’s original meaning and become a much more wider concept. Even if we forget the devops buzzword, how many developers are there now, that are just coding? And is building programs really enough nowadays? Can you get away, by just concentrating on a piece of code, and not caring about how it is delivered or if it is delivered at all? So yes, the progress of the infrastructure tools does keep the developer (in the old definition of it) from evolving, but it brings the people who are truly interested in digging deep and widening the range of their knowledge to a new, more advanced level, which then comes back (as I believe) with a better, more readable, easier in management and delivery code.

And that is progress.