Soft Skills That I Learned in my First Job
“I cannot figure out why this isn’t working!” I sat at my desk going through a frustrating piece of CSS code. As a fresh graduate from college, I wanted to impress my team with my abilities. When my manager asked me to fix a CSS bug, I hadn’t worked on CSS before, but I thought I could handle it without his help. Unfortunately, the code was at least several pages long and completely foreign to me. After spending two days trying to fix it, I asked a frontend engineer on my team, and he crushed my ego by fixing it in five minutes! The first lesson in a long list of lessons I learned from my first job was to: always ask for help when I am unfamiliar with an area. No matter how much I grow, there will always be areas with which I am not comfortable.
Understanding company culture and jargon
Adams, Scott. “Jargon Poisoning.” Cartoon. 26 June 2019. dilbert.com. Web. 09 Sept. 2020.
When I started my first job, everyone would throw around jargon that barely sounded like English! It is very common to walk around an office and hear conversations like “push that PR,” “file a Jira ticket,” or “turn on the A/B test.” I learned that I should ask coworkers about important words and concepts as soon as I hear them. I went six months without understanding the term “MAU,” which stands for monthly active users, because I was too embarrassed to ask about it the first time I heard it, and then it became too late to ask anymore! Every company has its own jargon; sometimes, they are context-specific and other times, they mean exactly what they sound like. For example, a “bug court” and “war room” are both meetings to handle outstanding bugs, but war rooms are for higher impact bugs.
Working on assignments in college is stressful. Most of us have been in the position where we pulled an all-nighter only to submit the assignment ten minutes before it is due even if it’s incomplete! Working at a company is slightly different. The deadlines are still important, but sometimes I just can’t complete the work on time due to unexpected delays not under my control. In that case, I have learned that the best course of action is to share my status with my manager, project manager, and any other stakeholders. This is even more important at a smaller company, where I have been asked for a status update frequently, sometimes multiple times a day from different people! If I am stuck on an issue such as testing, immediate help is available. If I updated the right people, work becomes less stressful even if it’s not completed on time.
Second, I have learned that it’s very important to communicate progress to other teams who are dependent on my work! I work largely in teams of two or three engineers who work on different areas of the project, so a single person may delay the rollout of the feature. One time, I had a marketing campaign depend on my project and as soon as I realized there would be a delay in the project, I communicated to them so that they could push back the campaign.
After my CSS debacle, I learned that it is very important to ask for help when I am stuck. There is a huge difference between asking other people to do my work for me and asking for assistance from experts! I generally try to solve problems by myself before approaching someone else for help; this ensures that I understand the context before asking for help. However, spending extra hours trying to learn everything on my own does not earn me extra points! The most successful engineers are the ones who know when to ask for help and how to craft specific questions.
Collaboration does not just mean asking for help. Sometimes my work is dependent on features and APIs from other teams. I cannot wait for them to complete their portions of the code in order to test my own code. Instead, we need to set up constant communication so that our code is compatible, and we just need to iron out a couple of details at the end. In one of my first projects, I had to consume a few APIs and create a user page for our product. The initial specification said that one of the APIs would produce a JSON file that I would use for data. However, when we integrated our work, I found out that the JSON file was empty!
Lack of communication with other teams can lead to inconsistent results
After talking to the other team, I realized that they had changed the interface but due to some miscommunication, I had not received that information. It took me an extra week to finish the code. Although the situation was out of my control, we were ultimately all responsible for the delayed shipment of the feature!
The tech industry is very collaborative. The most valued professionals are those who can work with other people. As I became more proficient at working with coworkers, I was placed on larger projects with more visibility! Learning to collaborate early will set the groundwork for a successful future career!
Frameworks are the big buzzwords of frontend/UI engineering. Sometimes learning a framework feels like buying a new car, which loses 30% of its value when it leaves the car dealer’s lot. In the same way, frameworks become obsolete while I am still learning to master them. When I started my first job, I spent a couple of months becoming comfortable with backbone.js, until everything switched to React! Although I was expecting the change, I was slightly frustrated that I would have to learn another framework in order to be proficient at my job. The tech industry changes very quickly and learning to adapt accordingly is key to being successful at the job and searching for new jobs. I have tried to work with several different languages and frameworks to ensure that I do not pigeon-hole myself. I have learned to get familiar with the new tech as it comes out — it has only helped me in the long run!
Similarly, different companies have different coding styles. A large tech company would have a huge emphasis on performance, stability and scalability, while a smaller tech company would be more focused on quick iterations of code. The best way to learn is through communicating with coworkers. I went out of my way to talk through my code design with more experienced engineers and learn from my mistakes in code reviews!
Companies have several checks and balances to make sure that the released products do not have major issues; however sometimes mistakes do happen! While trying to change a small image on my company mobile homepage, I accidentally added a very clickable extra button right in the middle of the page. I caught the issue quickly and I was terrified. This was a visible error, and I was not sure whether I should tell my manager or whether I should just fix it before anyone noticed. I ended up telling my manager to be safe, and he informed me that it was not a huge concern, but I should fix it before customers started asking questions. He also prepped my team just in case any complaints came through. I am glad that I ended up telling my manager; if I hadn’t, the team might have been blindsided by complaints! Regardless of why the situation happened, I have learned to be accountable for my mistakes. The sooner I tell my teammates, the better they can prepare for repercussions.