My Junior career’s retrospective
This is a translation from my Spanish post “Una retrospectiva de mi carrera Junior”. I’ve received a lot of lovely messages about it so I decided to make an English version.
After spending a couple of years in web development working for small companies in Venezuela and Chile, I decided to leave my job as a Junior developer. I was offered the role of Semi Senior at Globant, a software company with more than 6,000 employees, and accepted the position.
This is a new phase of my career where I expect to encounter different team dynamics as well as having to deal with bigger projects and expectations about my performance. Being completely honest, it’s all a bit overwhelming.
I’ve performed a mental review of my years working in web development and want to share the lessons I’ve learned during that time. I believe they made me a better professional, as well as a better person. This will also act as a reminder to myself when imposter syndrome rears its ugly head and fills me with doubt. Because sometimes revisiting old lessons can get you through those periods.
Before I begin, I have to do a SUPER DISCLAIMER: Everything I write here is from my experience, and no more or less valid than the experiences of other people. I can say that this is an expression of my reality and if by telling my story I can help someone to feel more comfortable and valuable in our chosen careers, then my purpose for writing this is fulfilled.
Code is not the most important thing
This is the only section where I’m going to mention code directly, and it’s to say that every day I convince myself that a lot of importance is given to what we write in our IDEs.
I’m currently involved in my local JavaScript community, and it’s very easy to get carried away discussing the best framework or library to use, or if it’s worth using any of them. Worse than that is listening to discussions about how web developers are of a “lesser category” compared to someone who uses C++, Python, Ruby, or Go.
The truth is, discussions such as whether to use a for or forEach to loop through an array or why you should or shouldn’t be using a framework do not matter. The codebase of any program will reflect the processes, the vision of a company, or even biases of the programmer who wrote it. It doesn’t matter if my code isn’t optimized 100% (is that even possible anyway?), or that I could be using a better performing framework as it may not be the best choice for the product I’m developing.
Most of the times my job was difficult it wasn’t because I didn’t know how to achieve something with a specific framework, or because of a function that used three for loops instead or one. Those are things than can be solved easily, or you can find an alternate solution. The difficulty instead stemmed from the fact I didn’t understand the requirements of the task and therefore what I needed to do. On other occasions I was blocked and afraid to ask a co-worker, or the team couldn’t come to an agreement because no one wanted to allow any different points of view but their own.
It’s common to see good programmers fully-focused on their computer, but uncomfortable around other people or worse, feel they are too important to talk to them. Most of the problems in software development can be traced back to ineffective communication, a disorganized team, and a lack of vision about what we are doing. Dealing with those issues requires skills that you won’t find on a computer. Knowing how to communicate within our team and between teams, refining our emotional intelligence, and being considerate towards others are all important skills/qualities.
To counteract this, I’ve stopped obsessing about what’s in the JavaScript ecosystem and instead will dedicate more time to improving my programming practices. That should make the job of reading and changing my code easier for teammates. I will also work on my prejudices and social limitations so as to improve my communication skills, share my experiences, open myself to other points of views, and welcome all feedback.
This is not an easy thing to do, and not everyone will always agree with me, but I think I’m on the right path and I feel this is what has and will continue to make me a better developer. Because at the end of the day we make software for people and with people.
The “broken” brain
Once, when I was talking about mental health, a coworker asked me “Have you ever thought about killing yourself”?
That’s a rough question, isn’t it?
I found it funny, not because I think the issue of suicide is funny, but because I’ve been through it many times in my life. It’s very hard to handle.
As the great Sara Vieira said in her talk, “Your brain doesn’t have a fix flag”, being able to function normally takes some people much more effort than others. It may take many years to be aware of that about yourself, and many more to take the necessary steps to deal with it.
Since I was a little girl I’ve had to live with what I call a “broken” brain. I felt very sensitive and fragile and that I never really deserve the good things people and life in general sometimes off me. I would cry over things that many would look at and say “it’s not that bad.” I lacked the strength to get out of bed at times, and much less be productive. I avoided places and situations that could trigger panic attacks… so I know what it’s like to have a brain that plays against you every day.
I used to function in an environment that treated mental health as tabu. My depressive episodes were something I had to deal with on my own for many years before I could receive proper treatment. The María of that time is very different to the María of today. Now I live in another country, I’m independent, and I still go to therapy without need of regular medication.
Nevertheless, I still have bad moments. I’ve taken tranquilizers before job interviews, suffered a panic attack during a presentation. and visited the bathrooms at each of my jobs to cry because I simply couldn’t handle the day. Despite that, I’m more than capable of making decisions, getting my work done, and presenting it in front of other people.
Working in the tech industry can be cruel sometimes, though. It’s still encouraged for individuals to be egocentric, prioritizing logical thought about the work rather their relationships in the workplace, and not getting carried away by emotions. This is all done while working long hours under pressure and surrounded by people who prefer the company of a computer screen.
I made a big effort to get into that work mindset, becoming more aggressive, leaving emotions at home, and growing a thick skin. And you know what? That shouldn’t be normal. I don’t need to become or pretend being another person that’s not who I really am. No one has to navigate between the lack of empathy and sacrifice their happiness just to hit a deadline.
Regardless of whether you suffer from mental issues or not, it’s ok to impose limits. That doesn’t mean you’re not a professional, quite the opposite in fact. It means you’re aware of what you feel and what you can comfortably do. The ones who don’t understand or judge you for your actions are the ones with the problem, not you. Remember, you’re a human being not a machine. Even a machine breaks down when it’s forced to function beyond its limits.
It’s ok not to know
When I was at school I didn’t have many friends. What I remember most are the years of rejection I suffered from my classmates due to my way of dressing, talking, or the things I enjoyed.
One positive from school was when the teachers congratulated me for my good grades. Since I was a kid, I was seen as being very “smart”. My grades at school were the only means by which I was recognized in a positive way. It made my mother proud, teachers congratulated me, and even some classmates asked for my help to study. In other areas I was a cry baby, shy, ugly, or with strange tastes.
Even though my social life became easier at university, I was already convinced that the only good thing in me was my intelligence. That was very gratifying, but also a big obstacle to function normally.
The problem of defining yourself in such a limited way is that it’s very easy to crumble when you feel you’re not living up to that description. Working in web development has offered me many chances to feel that way!
When I was having difficulties understanding something at work, I felt like the biggest failure in the world. I no longer felt smart, therefore nothing good was left in me. This wasn’t just triggered by experiencing a difficult programming challenge. I realized that I’d forgotten many basic things through the years, so when I see another person who knows what I don’t, then Bam! María feels like an idiot again. Such situations mean my productivity takes a big hit and they even triggered a couple of panic attacks.
Those feelings took a long time and a lot of work to make them disappear, but therapy and sharing my concerns with my colleagues and teammates allowed me to become more comfortable with the fact of not knowing things. It’s natural to forget basic things when you’re working with layers and layers of abstraction. It’s actually a plus to work that way in terms of productivity because it saves you the effort of taking care of the smaller, more basic details therefore allowing you to solve bigger issues!
It’s also worth remembering there are many types of intelligence. No responsible company ever wants to depend of an egocentric programmer, incapable of working inside a team, even if they are extremely efficient at delivering functionalities.
The value of encouragement
Is always good to emphasize the value of our own efforts. It’s a lovely feeling when you leave excuses behind and own your successes. I’ve been told many times that my achievements came by my own hand, and that may be true. No one forced me to read JavaScript books or to give a talk in a a meetup, but without my senior colleagues and friends who offered me words of motivation when I was doubting myself, I don’t think I could have done any of it.
When you’re in a position of power or major influence, you require awareness of the messages you’re sending and the effect they can have on those who are lower down the ladder. There are people who prefer to do harm and believe that belonging in the IT industry is a privilege for a few.
And yes, it does greatly affect women and minorities. I’ve listened many times to nonsense about how women can’t program. Bullshit! I have a friend who told me about how much she liked to program until her university professor told her she would never be good at it. She was just a freshman, and so naturally got very overwhelmed and it took her a couple of years to consider revisiting programming. Are these kinds of things necessary?
Honestly, programming is not an activity reserved for very smart people. Like any other profession, it takes practice and study. Excluding people who are interested simply because of prejudices is something that I can’t comprehend. As I go forward in my career, one of my great satisfactions is seeing people excited to learn and improving just because I share my experiences and the things I do.
There is a lot of value and learning when you help someone else to be a better developer. So I encourage you to exchange ideas with people who are learning, share stories and lessons, acknowledge their efforts and help them without judgement to find their weak points so they can work on them.
Our industry is enriched by embracing diversity and that needs to be encouraged. There are people who made me feel that I could contribute in a meaningful way to technology and it’s really precious to feel their support and see them be proud of me. That is something I want to give to all the people who look to me for help and guidance in the future.
How to deal with mistakes
Through the many jobs I’ve had, I’ve seen instances of developers trash-talking people who have left the company. There is also the situation where someone finds a bug and the first instinct is to make a git blame so others can make fun of the person who introduced the bug.
I confess I didn’t think these actions were a big deal, and I even joined in. Now I’ve realized it is unnecessarily cruel. Such behavior resulted in me being very hard on myself when I was the person introducing bugs… I felt ashamed, that I was a bother to my team, and I didn’t deserve the position I had.
With time I realized that focusing on who was to blame for bugs resulted in wasted time, delays in finding a solution, and ultimately damaged the team spirit. Does it really matter who made a mistake if everyone is aware of what happened and we can take steps to ensure it doesn’t happen again?
I’ve had many opportunities to reflect on my way of working and the same with my teammates. It’s a fact that we all make our best effort and produce the best code we can taking into consideration any restrictions placed on us by a project. A truly united team takes a positive attitude towards mistakes, works together to solve them, and encourages each other. Blame and guilt don’t even factor when this happens, just people helping each other get out of the mud.
The truth is that mistakes are the moments where you learn the most. I’ve made the decision to take advantage of those by facing them head-on, sharing my experiences, and leaving behind the mentality of “you break it, you fix it” and instead helping my peers.
Now what?
Well… I’ll tell you I’m a bit nervous! To go from small to bigger teams will bring new challenges where I will have to make some adjustments. But all the people I’ve met so far in my career have allowed me to gain experience and change my approach. All the interactions I have are meaningful, even if some of them have been difficult. I believe that as long I keep in mind the foundations I learned as a junior I’ll be capable of having the right mood to face any bump in the road ahead.
To the people who decided to give me a place on their team in Globant… Thank you so much!
…And please, let me share cats gifs for all eternity.
A million of thanks to the following people who helped me with feedback for the Spanish version: Daniel Rodríguez, Leonardo Graterol, Tatiana Molina, Kat Guzmán and Federico Cayrol (I didn’t redacted this as a retrospective dynamic, sorry!).
And a big final thank you to Matthew Humphries and Flor Vilchez, who helped me with the English translation.
