Good bye Bureaucracy

“I think you are hanging out with the wrong kind of people” - Raul Ramirez

It was 2014 and I was interviewing for my first ever job as a Software Engineer. Just fresh out of college and when I was asked the question which technologies I knew, it seems my answer did not impressed my interviewer (who would later become my boss). From that moment on, I realized I had to keep myself up to date with the technologies I was using and learning; and most importantly, I had to make sure I was around people who would alwasys push me to be a 10x engineer. Fortunately, I got the job (appararently based on my potential).

Going forward 6 years and here I am leaving the second company I’ve ever worked for as a Software Engineer. It’s been an incredible journey. I started working there as a contractor, moved on to working directly for them, from a Software Engineer to Senior Software Engineer to finally becoming a Technical Lead (wow, 4 roles!). Scotiabank has taught me many things, I’ve seen good and bad. It feels right that I share all of those things to the people who seek the same as I do: be surrounded by the right people, at the right time.

I’ve gathered this list of 6 things that helped me through my life as a scotiabanker. I hope you find this as useful as it once made my journey there more enjoyable.

En la variedad está el gusto (variety is the spice of life)

Many times, we as Software Engineers just spend time around other engineers, which is part of the job itself but I think it takes all the fun of interacting with other roles or people. This used to being me at my first job. I would always go to lunch, play videogames, go for a drink with other devs, the problem there is that we as developers sometimes have a type (if you know what I mean).

The advantage of working at Scotiabank was that each team consisted of different roles: you have UX designers, business developers, engineers (frontend, backend, QA), and even marketing folks. My advice here is that you should find the time to spend with each single one of them, get to know their likes and dislikes and find some common ground. Find the people you will play soccer with, other people to go for a drink, go to as many birthday lunches as possible, go to the office parties! Because that is where you get to talk to these people, stop talking about work, talk about something else, we are not just code-producing machines.

La consistencia parece cuento chino (consistency seems wishful thinking)

When I started in that office, we were a group of just 7 frontend engineers. There were only 2 repos for the new project and the old one. That was it. So, when you were asked to code a button, you would probably try to find something like that in the code and copy/paste it. Other times if you didn’t find such component, you’d probably build it yourself. As time went by and the team got bigger (now there were more than 10 frontend engineers), we realized the need for a design system. We started working on a components library, so that it would become more obvious what you had to code from scratch from that you had just to consume.

Engineers are commonly tied to code, so it becomes very noticeable whenever we want to change something that many others use. There is even a feedback process in place for changing code (hello Pull Requests!). This is not the case for other teams. Creativity is at its peak with UX designers sometimes, which I realized made it difficult to have the same experience for let’s say following a product adquisition flow. Different templates for basically the same use cases. Always work with your team and make sure that there are guidelines for your design system. Designing an experience should involve engineers and designers in all the phases of the process. Don’t wait til it’s too late for making suggestions for changes. Designers are your friends too.

La curiosidad no mató al gato (curiosity didn’t kill the cat)

The first problem with working at a big multinational is that there are processes for almost everything. The second problem is that sometimes these processes are not documented well enough or the documentation is hidden in a dusty book or in an old email buried somewhere.

Always be curious of how things work. The answers are there, you just have to look for them. Which in my case would translate to searching for things in the company’s confluence. Sometimes I would find the answer to my doubt and other times there would be nothing there, so I had to ask someone, send emails and even start lots of email threads until you get your answer. My responsability there? Of course, I needed to document my findings, this would save a lot of time for the next peer looking for the answers to a similar issue.

La flojera es a veces una virtud (the best developer is a lazy developer)

Coding involves doing repetitive things. You have two options to perform them: do them manuall each time or spend some hours first to automate them and forget about repeating them.

In our journey to coding consistency, we implemented a way to static review our code against a set of rules each time we would save our progress. That way we would avoid having to give the same feedback in each pull request about formatting the code. It took some time to get to the sweet spot where you are happy with the automation of the process, a lot of false positives would appear in the beginning when triggering warnings for an unwanted feedback. But this is part of the work when you automate things, don’t get discouraged when things don’t work as expected at first.

Automating didn’t end there. In the end, we automated coding deployment, unit testing threshold requirements, and even analytics change checks. The moral of the story here is that laziness should not be seen as a bad thing when you automate things, that saved time will allow you to do other things (relaxing included).

No eres tú contra el mundo (it’s not you against the world)

As I took a more senior position at Scotiabank, I would realize I had less time to code the improvements I was proposing. Learning to let go and trust your team is as important as coding itself. By accepting that others could do the job and do it very well took away my stress.

Sometimes we will not have control over the whole process and that is good. Your team is as capable as you and they could share the workload, give feedback to each other in the process, and come up with a beautiful product in the end. After having done this, your team grows a lot, they learn to take ownership of the products they are building. This, my friend, is awesome.

Todo extremo es malo (everything has its limits)

With the pandemic that hit us in 2020, the number of developers feeling burnout increased. I would find myself working more than the usual in order to meet the deadlines. While doing this at the beginning seemed manageable, it turned out to be tiring.

Don’t get me wrong, I enjoy coding A LOT. I compare coding as the same feeling people get while playing videogames. But as you’ve probable heard this before. Every limit is bad. Coding and working to the limit can hurt how you feel about them. Draw a line between your responsibilities and what is humanly possible to accomplish in such period of time. Allot more time to do other things besides the work-related stuff. Your inner self will thank you later.

I’ve titled this post good bye bureaucracy because in the end that is how I feel about leaving Scotiabank. The feeling of freedom and moving away from so many processes and repetition is something I looked forward to for a long time. I hope that this new adventure in my next job doesn’t need a swissknife for survival but allows me to enjoy what I love the most: technology.