Learning Through the Web: Lessons Learned

Disclaimer:
The subject discussed below is based on my personal experience with software tools in a humorous aspect. It is not meant to be approached as “the correct approach”, it’s something that I find useful.

Working as a software engineer I have encountered a plethora of problems that require different tools per case. Obviously there is no chance of knowing every tool you are going to use, especially early on, on your career. And since computer specialists double in numbers every 5 years, based on Clean Coders, My lawn article [1], every day makes this case more relevant. With such a rate of growth, learning new tools and methodologies becomes an industry problem
When I begin to use a new, to you, tool, the cycle goes like the following:
  1. A new need appears
  2. You think of and (maybe) look for the best tools available
  3. You select one or a combination of them based on your needs and taste
  4. Then you start googling the required setup
  5. Once you have the required setup in place, you start to play/test the tool and squeeze bits of code here and there, most of it examples you find googling in the previous stage
  6. Then you try to fulfill the original need using your new shiny tool
  7. Once you are done, you are proud of your creation, you try to make it look a little better, you rename a variable, you use a better name for the file (testTestlastFinal.sh is not going to make any sense after a couple of weeks), but deep down you know you are missing something
Note: see also the diagram below

A month later, a similar problem appears, or it seems similar to you because there is a while since you used that new tool. You know, for example, the differences between an ansible variable and a bash variable, now you find a useful page of documentation that discusses the topic, and then you check for a similar example and you copy it to your code.




You start the cycle again but now you already have a working example, so you copy that example to a new directory and start modifying it, then you imagine what the solution could be and you google it, the first time you got unlucky then you look for a comparison with something you know, and that clears things a bit for you but still, you have not found the answer to the original problem.

After reading a number of google pages, documentation, and StackOverflow pages you begin to create a notion of how this problem might be solved. It seems that you are rather away from the point you started but you are closer to reality. This approach can continue and the solution is usually reading and duct taping. After a few cycles, your duct-taped solution grows big and maybe, even unmanageable.

Then you say, enough is enough, let’s start looking for the best practices about this tool, let’s see what other people can do with it. Hence you start reading articles with titles like 10 things you can do with <tool-name>, or seven secrets you didn't know about <tool-name>.

You follow those articles and then the situation begins to be tolerable, a few cycles after you start considering that there must be something you are missing and you end up reading a book to gather more information about the subject.

I've now been using Ansible for the last 15 months and in the link below you can find the things that I was missing before reading a book on the subject, in my case Ansible up and running [1]

Learning through the web: Ansible


The points made in the link above made my code more idiomatic(writing a programming language as it is supposed to be written [2]) which led to increased readability and made the process of breaking the code into components easier. The deployment of the code was also positively impacted by the ssh tips given above.

It is very helpful to use a tool to automate a job, but if you want to continually improve your work when it is automated you have to use the tool as it was intended to be used. It will be beneficial to resist the law of the instrument, an instrument in our trait is not only the operating system, or the language. Design patterns and language idioms are also instruments that we constantly misuse without noticing that much.

References

[1] Ansible: Up and Running: Automating Configuration Management and Deployment the Easy Way, Lorin Hochstein
[2] Robert C. Martin, Clean Coder, My Lawn, [Accessed July 7, 2020] https://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html
[3] Idiomatic code, Stack overflow, [Accessed July 7, 2020] https://stackoverflow.com/questions/84102/what-is-idiomatic-code#:~:text=Idiomatic%20code%20is%20code%20that,rather%20than%20looping%20through%20it.
[4] Law of the instrument, Wikipedia, [Accessed July 7, 2020] https://en.wikipedia.org/wiki/Law_of_the_instrument

Popular posts from this blog

Constraint Theory on Cities: Skylines

Image
 In 1984 Dr. Eliyahu M. Goldratt introduced, with his novel “ The Goal: A Process of Ongoing Improvement ”, the theory of constraints. Theory of constraints emphasises on calibrating a pipeline of work using as a metric only its total output and not the productivity of each component. The user of the theory has to identify its output, its input and the major bottleneck in its pipeline. This fundamental theory was also depicted in the novel “ The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win ”, which was meant to be the devops flavor of the novel “The Goal”. In this novel, a new assigned IT Manager has to deliver a new project which is supposed to give to its company a competitive advantage on the market. While doing this he has to sustain the life cycle of all the IT projects this organization runs. I read the two books with little time difference between them, quite recently. I started being a fan of this theory and I was wondering if such a theory could
Read more

Learning Through the Web: Ansible

This list is a companion to my article Learning Through the Web: Lessons Learned As mentioned in the article, during the learning period I get through, I try to read a relevant book and spot the things I missed on the web. This list is exactly this for ansible. The book read is Ansible Up and Running [1] Firstly something that comes handy, you can make your Ansible playbooks executable using shebang by adding #! /usr/bin/env ansible-playbook at the beginning of the file It is a good practice to keep files and jinja templates on separate directories (/files, /templates) because during the execution of each respective task, (file or template) ansible will check those directories first, either it is in a role or simply a playbook Handlers in ansible run only on changed task status, not always default/main.yml variables are meant to be overridden whereas vars/main.yml are not You can define dependencies between roles You can pass roles variables using the following syntax roles: - { role:
Read more