From Bootcamp To Devengo

If you look at my CV, the title “junior developer” comes after a degree in geography. I’m also a specialist in network analysis (no, not the one related to computer networks but this network analysis). With the arrival of the pandemic in 2020, I had to rethink my future and, to be honest, it was an advertisement on the radio that helped me take the step into a world that had always caught my attention and that, at the same time, also was slightly intimidating, to say the least.

I started in the development world doing a bootcamp in which I trained as a fullstack developer for three very intense months. After the bootcamp, my first contact with the working world of web development was an internship, developing a training website where students could do their exams online. At the end of the internship, I landed at Devengo as a junior developer, which at that time was dedicated to offering Salary Advance for workers from different companies.

First Months At Devengo

The first few days, while I was preparing all the necessary setup and taking a look at the repositories, I felt terrified and, I can’t deny, at times, overwhelmed. I understood what the code did in each file but didn’t understand how they related. I often didn’t understand what the rest of the team was talking about in the meetings, but I put on a poker face (in retrospect, I don’t know why, honestly).

Devengo has an onboarding system that makes it easier for you to adapt to the work environment. It consists of a small guide with the most essential steps to start working. Additionally, they assign you a buddy to make everything even more manageable.

And you may wonder, what or who is a buddy?

Your buddy is another person on the team (usually a senior) who aims to help you land in the company and guide you. During the first weeks or months, you share some daily hours with your buddy as you become more confident. It’s great to have this time to resolve doubts, learn new things you didn’t even know existed, and even cry if you feel lost (thanks, Ivan, although I didn’t cry!).

I tried not to get too overwhelmed, and to do so, I analysed the flow of each endpoint, following one by one the files that made it up and their respective specs. Going through this process, I discovered many new things about Ruby/Rails development.  

For example, I learned how helpful the Rspec contexts could be in describing all the possible scenarios in a new development. They help to test not only the happy path but also to rule out possible scenarios that should never occur if the implementation is correct. They are a very good way to understand the code better and even save you a lot of “research” through the repository.

I hadn’t even been at Devengo for three months when the pivot that they had been preparing for some time materialised, leaving behind the world of Salary Advance to focus on the world of Instant Payments, so my head (although the base code was the same) had to wake up to separate both concepts and get to know well their similarities and their differences.

I will discuss these differences further down, but the banking world is complex enough to write an almost unlimited amount of posts.

Evolution Over Months

Until I was offered to write this post, I had not looked back to see how I have progressed over the months. 

There have been many areas where I have noticed improvements: the capability to understand the code quickly, a significant increase in my ability to debug complex flows, the reduction in the time it takes me to prepare a good spec that covers all possible scenarios and even I see myself capable of planning the development of a new feature from the beginning.

However, I have noticed the most progress (although I still have a long way to go) when reviewing coworkers’ PRs and the comments they have left on mine.

At first, I did not consider myself capable of “questioning” the comments they left me on my PRs. There were even times when I had multiple different comments on the same piece of code, which generated even more doubts in me: “Why is it better to do it that way?” “Shouldn’t we all have the same vision on how to do this?”

BZZZZZTT! Junior mistake, there are infinite ways to program the same functionality, and over time, you discover your style (within limits, of course).

Currently, I have more ability to argue the reasons for my PRs, make my own decisions when writing code in one way or another and even suggest changes in the PRs to others, when at first, my comments were only made up of questions with more doubts.

Being Junior Developer On A Senior Team

The truth is that before entering, I was not worried about being the only junior developer; however, once inside, I felt very unproductive, feeling more like a nuisance than a help to the rest of my coworkers. Although they never made me feel like this, it was hard when I had to speak in the daily meetings  and every day, for weeks, being unable to say anything like: “Today I finished implementing feature X”.

It was a pretty frustrating process, but now, looking back and taking a step back to contemplate it, I understand that it was a process that I had to go through to understand and apply all the knowledge that I learned during those weeks.

Subsequently, new senior co-workers joined the team. Their onboarding has given me the perspective that general work experience is not the only type that counts, and specific experience within a company or industry itself is very valuable. In some cases, I was able to resolve the doubts of more senior coworkers! (yes, I’m proud to be the one explaining something for once).

Fintech Specific Pros/Cons

Working in a Fintech also conditions you a lot regarding the level of product understanding needed and how you have to adapt to the standards the banking world imposes.

For example, the levels of caution and security required by this type of company are not the same that may be required in other industries. They have to be much more restrictive. 

Not only because we are “moving”/”dealing with” money that is not ours but because these movements have legal limitations and strict controls to avoid fraud and money laundering, known in the industry as AML.

At first, you are not aware, but as time passes, you understand that you need to learn a lot of different things about the banking world:

• How it works, beyond having an account in a bank.
• What parties intervene in the process.
• What problems each party may have.
• How they communicate with each other.
• What types of errors can occur (technical, legal, etc.)
• What temporary limitations may occur.
• What problems are in your hands to solve and which are not.

To ease this process, at Devengo, we develop and release iteratively, coding small pieces of the features, which, little by little, are joined together. Doing it this way minimizes the possibility of breaking something with a big “launch day” deployment.

When developing a new functionality, we usually work under feature flags. These flags allow us to soft-release to production, opening the new functionality only to the actors we want, ranging from an entire company to a single bank account. And that, when you start to deploy as a junior, gives you much peace of mind.

Takeaway

My main advice is to make yourself believe that if you have gotten the job, it’s because you are suitable for it. Believe in yourself! 

If you find it difficult to believe in yourself, I hope you are lucky enough to have colleagues who celebrate your achievements.

Secondly, when they suggest a change in a PR, before blindly accepting it, question it and take it as a learning experience, not because it is not valid, but because that will make you aware of the different ways you can implement it the next time you face a similar development.

I also think that it is essential -although it may feel tedious sometimes- that you don’t downplay the importance of planning the implementation, leaving it reflected in writing, even in the PRs description. This will help avoid any doubts, headaches and wasting time searching, plus, it can significantly help those who review it without being 100% aware of the context.

Remember, software is a people problem!
If what you have read has not been enough for you, or you need a keyboard to break while you scream and cry… look for me on LinkedIn, and I will be your buddy!