DEV Community: Thiago Ramos

Become a developer by changing your habits

Thiago Ramos — Sat, 06 Mar 2021 19:20:47 +0000

This was first published in my Hey World blog. Access here to subscribe: My Hey Blog

Nowadays I am reading a lot about how to build new habits and how to improve as a person in some aspects in my life and as I was re-reading James Clear’s book about atomic habits everything started to get together like pieces in a big puzzle. I had heard the audiobook years ago but I just took it for granted.

But now, I immediately remind myself of a conversation I had with a friend of mine that was trying to become a developer but didn’t know where to begin. He had tried before some years ago and it didn’t work for him so he quit. As I was listening to his story I wasn’t sure what to tell him, I was literally out of ideas on how he could practice so he wouldn’t quit again so I told him what everybody had ever told me:

“If you really want it and feel you don't like it, you just need to practice and you will, eventually, overcome the point where you stop hate the thing and start enjoying it”

Back then I didn’t know how terrible this advice sound and now, re-reading James Clear’s book I think I know where I failed.

See, you can’t become someone if you believe you can’t be that person. You simply can’t become a runner if you don’t believe you are a runner. But the thing is, no one will wake up one day a tell yourself out of nowhere: “I am a runner” and actually believe in it.

But, the good part is that it doesn’t need to be that way. You don’t need to believe 100%. You need to tell yourself that you are a runner and go run.
The next day you wake up and think, I am a runner, I did run yesterday and it was awesome. Of course, my legs are hurting, but that’s ok, I am a runner and this is part of my evolution as a runner, let’s run today.

In the beginning, this will be harder than it sounds, but as you go run the idea of being a runner will start to become your identity. And, by looking at your calendar you will see proves that you are a runner because you ran all those days. And you will start to feel better with yourself because you will become healthier and that will only enforce your identity that you are a runner.

Once your identity is formed it will be harder and harder to let go of running and all of this started because you said to yourself: I am a runner.

See, it’s not about results, it is about identity. You don’t need to say: I will run to lose weight. You need to say: I will run because I am a runner and that’s who I am.

I was stunned when I read this simple idea. And I remember all my conversations with this friend and how I became a software engineer.

I remember I had this clear idea that I was a programmer way before I knew how to write software well. Of course, it took me years and years to learn and become a good software developer whatever that is. But the part that I had forgotten was that I did saw myself as a developer even before I made my first program. And when I started to learn how to program, I remember I was doing it every day for hours.

In my mind, I was a programmer, not a person who wants to learn how to program. That was who I was. Back in the day I had a full time job as a salesperson in a music store. But I already saw myself as a programmer not a salesperson, and by study every day for hours, I was becoming a programmer and that was only reinforcing my identity, the identity that I already had made the decision that I would be. I was a programmer.

It is so clear to me today that I thought it would be good to write about it. We are surrounded by coaches of everything nowadays. Coach for health, coach for focus, coach to tell you who you are, coach of this and that, and this is a dangerous subject to write about but I have no intention whatsoever that this text sounds like this. One thing this text has in common with coach speeches though, in some ways it is telling you something you already know but keep reading.

One thing I came to believe was that my friend was quitting because he was just trying to learn to program to find a job. He didn’t believe he was a programmer, that he was a software engineer and I do believe that if you don’t change your mindset, and are forced to change your identity it will be hard for you to accomplish the tasks of study hard every day to learn any subject.

I do have a lot more to say about this and maybe I will write down more thoughts about it but I don’t want this letter to take long.

So, tell me. Do you want to learn to program? Did you see yourself as a programmer? If not, start to. You are a programmer, you are everything you want to be. Sounds foolish but it’s true. Start to believe in this and then, get an hour in your day where you could be watching TV and start to learn a programming language. And the next day, look at yourself in the mirror and repeat to yourself: I am a programmer. And when you have another free time, don’t watch TV, continue the studies. Soon enough you will generate so many proofs that you are a programmer that you won’t need to tell yourself you are a programmer anymore because you will be.

Peace folks. Hope you all stay safe.

If you enjoy this, please subscribe and follow me:

Review of the Book: Design Elixir Systems with OTP

Thiago Ramos — Sun, 07 Feb 2021 16:31:23 +0000

This book by Bruce Tate is, for sure, one of the best findings that I did this year.
For those of you who don't know me, my name is Thiago Ramos, I am a senior software engineer for a California based startup and I work mainly with ruby and rails.
Some years ago I discovered Elixir seeing one of Jose Valim's presentations and he got my attention. As a Brazilian, I had heard of Elixir before in 2013, but it was only in 2016 that I looked into it.

Well, life gets in the way and I never really studied Elixir. But at the end of 2019, I decided that I would learn Elixir and all the PETAL stack because I loved the language and the fact that it is functional and runs inside the Beam Virtual Machine which is a 40+ virtual machine that already solved the concurrent problems that we are mostly facing now, all of this got me thinking, hmm, I think this is a great language and ecosystem for the future. I must learn it now.

From there to now I read a lot of Elixir books including Programming Elixir, Phoenix Programming, Programming Ecto, and Functional Web Development With Elixir, OTP and Phoenix. All excellent books, especially the last one that I will do a review later.
This year I found Design Elixir Systems with OTP and I am glad I did.

This book is somewhat comparable to the Functional Web Development with Elixir in the sense that both authors code layer by layer which means that the book is structured in a way that each chapter or part of the book is responsible for one layer.
In the case of this book, the author is splitting the code into 5 layers plus two chapters related to testing.
The following is an attempt to explain a little bit of the book for those of you who don't know it or already know but are not sure to buy it.

Layers Explained

First of all, I got say that this book is not for a programmer that is learning elixir. For that I think you should go first to the Programming Elixir book, to understand the data structures, the functional language idiom using elixir and to understand how Elixir uses recursion, how do you create functions, how to use them, and other aspects of the language.

That being said I think if you understand a little bit about all those topics above you will find that this book will help you greatly. First, because it's almost a hands on book, where you can see the author implementing the code and discussing why he chooses to use Map instead of a Struct or vice-versa, you can see when he uses Tuples and when he prefers to use Keyword Lists.

What I am trying to say here is that seeing the choices being made regarding the problem at hand is great to understand better why and how to use particular data structures over others. And that's, for a person that is learning the language, it is awesome to see.

I am kind of biased because I always learned better by doing and I was never a big fan of Bible type of books anyway.
Through all the book the author is creating a Quiz system where a particular user can build quizzes through templates and can apply those quizzes to other users. There are two main core parts in the system:
The Quiz Manager is where a quiz is created, all the templates and fields populated. You can have multiple templates for a single quiz, like addition, multiple additions, and so on.

The other is the Quiz Session where a user can take a quiz. In this process, the user needs to correctly answer several questions so he can pass the quiz. All of that is configurable through the Quiz Manager. The Quiz Session will also timeout and that we will see when I talk about the Scheduler structure.

So, the author starts by creating the core of the application which consists solely of modules that contain some structs and functions. He does not talk about Ecto or changesets or schemas or anything like that, he is not worried about any persistence layer. Just the intricate relations between modules and their functions. He goes on and creates all the core structure with logic for the Quiz problem. In this part, you will have a fully functional core that you can test and even work within the console.

This approach has a name in the architecture world which is Hexagonal architecture.

In the hexagonal architecture your core business logic is in the center and all the infrastructure code is in the boundaries, which in this case means:

Processes
Supervisors
Database (Ecto)
Web Layer (Phoenix)

So, in the core the author does not create any GenServer or worries about processes or anything like that, it is just plain old Elixir modules with functions. I have some thoughts about this approach that are conflicted.

I did a lot of projects where we did the separation of concerns using the hexagonal architecture. I will do another post about my experiences on this but one thing I can say now is that you should analyze if your application is too data-centric, which means that your web layers almost always send data back and forth from databases to the web or other delivery channel. Or if your application has a high "density" of business logic.

In my experience, I think you don't need to adopt one structure and use it everywhere for all the cases in your system. I think you can understand the parts of your system that would be good to be extracted from concerns about persistence layer and delivery mechanisms and extract them so you can work on them without worry too much about database schema structures or JSON/XML structures or whatever it is your delivery mechanism.

What I see a lot is that people tend to be rigid about their early choices and create code in the system using the choices they made early on even when it is clear that it doesn't need to be that way. And we tend to see a lot of layers with no logic and layers of conversion data being used where it is most unnecessary, just because the choices were made and who the hell is brave enough to go against the system in place, right?

I am rambling here. Going back to the book.

The next step is to create the boundaries where all the GenServer processes exist.

So, with all the core done it is easy enough to create the modules that will start the processes that will use the core modules to create quizzes and make it possible for users to take the quizzes.

What I found good in this part of the book is that you can see how an experienced elixir developer thinks about it and how he approaches the creation of the servers and the API for that servers.

In this part, he goes on and creates the GenServers and the API for the GenServers which consists of functions on the module that hide the calls and the logic that is executed in the GenServer callbacks like "handle_call" and "handle_cast"
The author does a great explanation of why it is better to use GenServer.call instead of GenServer.cast and uses the Logger code in elixir to explain how they use those methods and callbacks to apply back pressure and limit the flow of data so the system continues healthy.

All GenServer.call are synchronous and the GenServer.cast are asynchronous which means that if you use only the "cast" function you can end up receiving more messages than you can process and once your mailbox is full you will start to reject messages and one away to deal with this is to use the "call" function instead. Depending on your business requirements you can create logic to use "cast" and change it to "call" if needed.
I will not spoil more than I did so far so you read the book too.

The next step he goes to create the supervisors. In this book, he creates both the configuration for static and dynamic supervisors. He does a great job explaining why we need dynamic supervisors for the Quiz Session part and why we don't need for the Quiz Manager part.
Quiz Sessions are created by the user. So each user taking a quiz is a different process in the tree.
Quiz Managers don't need to have more than one process because they are not dynamic. Once we have a manager with all the templates we can start taking quizzes using the templates already created.

Of course that he goes on to explain that this is the case for the business logic he thought about. We, of course, could have multiple Quiz Manager processes if we want to.

The last part of the book is related to the Workers. What are they exactly?

At first, I thought about them as background jobs because I am a full-time ruby/rails developer, and every time someone talks about workers in my mind they are talking about some work that is done in the background. But in Elixir every process you create has its own world there and does not share anything with any other process.

In this case, the author says that we should, in general, avoid naked processes and use Tasks instead or always work with supervisors and he goes on to write examples using the erlang library poolboy. I may be wrong here since I don't remember the words he wrote.

But in this part of the book, the author creates a module called Proctor which the basic function of the module is to schedule quizzes, start them, and terminate them when they timeout.

This layer uses all the other layers built in the book and
the code specifically creates processes and terminates them when they should be terminated.
So, the worker word is used in a meaningful way here, they are processes that do the work of schedule quizzes and create and kill quizzes processes when it should.
In a sense, this layer is adding one more process in the tree that is responsible to create processes and kill them.

What did I think of the book?

My general feeling about the book is that it is a great book to learn a lot about OTP. I learned when to create processes, the type of code that should go within, I learned how to use Supervisors to leverage a system that is reliable and scalable. I lost the fear of creating trees of processes and I got to see how an experienced developer usually thinks when coding in elixir.
Overall I am much better at elixir than I was before reading the book.

I have to be careful though because following someone's path (code) does not mean that you really get the knowledge and by now I have baggage enough to know that I need to write and write a lot of code and solve a lot of problems so I can be good at something.
Keep in mind that I am not learning how to code and I do study elixir for some years now. So I do think that if you are starting now I am not sure if Elixir is the best language for you and neither this book.

I do think that if you know the basics this book will greatly improve your Elixir idiom and you got to see pretty good tricks.

I wish you all be safe and well and let's learn Elixir.

It is all about the concepts!

Thiago Ramos — Mon, 27 May 2019 12:57:58 +0000

You want to be a great developer, a software engineer that can write code in multiple languages, a person that knows how to use Rails, Django, all or most of spring projects and Hibernate, you know ruby, python, Scala, java, javascript and all the universe of javascript libraries and frameworks and you call yourself a software engineer, but you can’t understand the story that your customer is telling you, so you can translate that to software and modelling the problem to inform and communicate to other engineers what to do and how to solve the customer problem. Well, if you recognised yourself in this description you may feel, sometimes, an empty space inside of you like a dark space of fear and regret of having not learned the concepts behind the practice. Or you just know you need more theoretic study.

Let me be clear, I am not judging anyone and I don’t have an opinion about what is the best path to success in programming, I just found out that programming concepts are getting more and more forgotten and this is not just my or your fault.

If you are like me, you felt, at some point of your life, the desire to know how things work in a computer and how those programs you used to use were made. I started wonder that in 1995 and at that point I discovered some basic languages that made me possible to create real simple stuff, but I was delighted. Years later I was already creating websites and doing programming courses, but no one open my eyes for the inimaginable power of the concepts behind the languages.

Even when I was graduating, the university didn’t care so much about going deep into concepts like object oriented, design patterns, or how to extract information from conversations and understand the requirements and build models about it and understand domains and contexts. And it took me years into programming to realize that I was relegating this important part in detriment of just learn the programming language.
But learning a language like Java, without going deep into object oriented design made me write procedural code in an object oriented language. I was luck then, because I had mentors, people who saw my hunger for knowledge and put me into the right direction.

I was all about understanding concepts before languages or both together. Things like design patterns and why they are important (tip: Do not just record patterns in your head, try to understand the problems they are trying to solve), object oriented design, refactoring techniques and how to apply it, the basics of a good programmer like naming things, short and conscise(when possible :) ) functions, single responsibility, all the SOLID principles and a bunch of other topics put me aside from other developers and soon made me evolve faster, simply because it became easier to understand other languages, because I knew the concept already. See, I didn’t mention functional programming because it was not hype back then.

Today you don’t have excuses to learn more in depth about programming concepts. Don’t be the guy who thinks MVC is the best pattern for solve any problem and Domain Driven Design is just applied in huge enterprise applications. The knowledge at your dispose today is infinitely bigger than it was when I began to program. (I am not as old as you may think).
There are a great collections of books that help with that, some of those are:

GOOS — Growing Object Oriented Software with Tests, Clean Code,
Working Effectively With Legacy Code,
Design Patterns — Elements of Reusable Software,
DDD — Domain Driven Design,
Implementing Domain Driven Design,
Test Driven Development

But there are so much more!

As soon as you grasp the concepts of a language you will see that test driven development is the most important tool to force you to follow code design decisions. I think that, maybe, is the most important one because test driven code has two bigger benefits for me:

Is reliable and it will bring more and more confidence as the time goes by.
It forces some design decisions and make possible for you to see other hidden concepts in your logic or flow of thought.

But you cannot enjoy all the good things a TDD approach can give you if you don’t know what it is a good objected oriented or functional design. If you can’t understand what your customer (could be your boss) is saying and you can’t extract information from conversations and translate that to models, if you don’t know what makes a good class or function and you don’t understand polymorphism for instance. If you don’t know that and much more, regarding concepts, TDD will not help you. There is no silver bullet or blue pill, only the damm red pill that you will take, whether you like it or not.

So, if you are starting right now or you want to start and you want to use my advice I would say to you:

Start by understand the basics of the language you want to learn.
Try to create real simple but useful applications
As soon as you realize that you understand the basics of the language, try to jump into the concepts. Keep in mind that concepts are harder to learn than languages and maybe, you will need to read and read again. You will feel like you will never be able to apply that or learn, but you will. Eventually you will see that you are thinking diferently than you were before and the more you read the more you will introspect that knowledge.
Do some project. Try to apply the language, concepts and frameworks in a project. There is no better way to do it.
Learn the basics of a programming language is easy. The most difficult part is to create reusable and understandable code. But this is the path that we are all walking together and will continue for a long time. See you soon devs. Hope you have an awesome life as a developers.