Learning on the Job

It has been almost a month since I last wrote here. Things are moving pretty fast and I still did not figure out a healthy rythm of working, living, relaxing and writing. I’ll get there, though.

One of the things that almost always occupy my mind is the question: what should I write about next? There are a lot of things that I want to write about, but not so many that I feel have reached a level of maturity in my own mind in order for something minimally good to come out of it.

This, however, is a slippery slope and I think that it can easily lead to analysis paralysis. And I have always had the feeling that the value of writing is not really on the final product (at least not from the writer’s perspective), but on the process. I want to revisit this blog posts in the future and be able to read them and think ‘Jesus, I wrote so badly back then’.

So, all of this initial blabering is to say that this post is about some things that I have had contact in the job and that I feel that it is worth of note. It is not meant to be a deep dive on any topic at all. I want to revisit some of the topics more in depth in the future. So, let’s do it.

Code is a liability

I have read this phrase many times during my studies, but I finally feel that I got to cross with a situation of its manifestation.

My first task, to be done jointly with another junior colleague, was to add some support endpoints so that, whenever needed, engineers could use it to interact with a database through the endpoints without having to directly interact with the database. This was required by some governance body of the company.

For some reason, I had access to the database in the development environment and my colleague did not. So I could easily query the database to see if the handler of the endpoint was able to insert a new line on a table, for example.

Since my colleague could not query the database directly, he, pretty cleverly, migh I say, design other endpoints (let us call them secondary endpoints) to query the database in order to test the task endpoints. I see no problem with this approach - in fact I think he showed initiative and creativity - instead of waiting for someone to authorize him to access the development database.

However, when sending the pull request, he left the “secondary” endpoints code there. At that I think that was a mistake - and told him. That code was only necessary for the development task - it was not meant to be used in any other scenario. He chose to keep the code anyway - in his words: what harm can be done?

When our senior engineer reviewed the code with us, he stated the same I had pointed out. And then he added: all code is a liability - it is another place where things can break. It can be exploited by an attacker to gather information about our database. It can be abused by a legitimate user that discover it.

So there’s that. I was happy my intuiton was right on this one.

Clean Architecture

My next task was to verify if a database column was compliant with a legal requirement that is going to come into force in the near future. A value in this column was to be store as text but it is relatively common to store it as integer.

I checked and the database was fine, the type was VARCHAR like it was supposed to be. Now I had to check the application to see if somewhere in it these values were somehow transformed and dealt with like they were integers. And then, my friend, I was the first contact with an application built with C#/.NET using Clean Architecture.

I have some experience with C++ and had used interfaces as dependencies before, but nothing like that. Every dependency was an interface. I have to traverse at least two abstractions in order to get to the code that I wanted to investigate.

At first this was a little overwhelming and cumbersome for me, but quickly it became second nature and now I can even see the value of it - I got to inspect some other codebases that use the same approach and it was very easy to find what I was looking for.

But yeah, it quickly became clear to me that Clean Arch can be overkill for simple projects.

Coming up

I think that is enough for this post. But I have a lot more I want to talk about:

• Deployment in Kubernetes clusters
• Dependency Injection in .NET
• CI/CD and QA requirements
• Observability
• Batch methods vs naive loops
• and many more things…

Will I ever get to the end of this list? I hope not. I hope I just get to a point to attack these things in a constant enough pace.

Here’s to hoping