Things I learned as a UX Engineer for the past year
Coding is a big part of being a UX Engineer, or software engineer, but its not the only thing! None of these memes are mine, except the second one…enjoy!
In 2020, I made the life-changing decision to decide to change careers and go to a coding bootcamp to change into tech. I had a lot of expectations going into the industry, which has been proven wrong time and time again. Here are a couple of things that I’ve learned in the past year working as a UX Engineer.
CSS is HARD and being good at it is severely underrated
Not my meme but its accurate
9 out of 10 times, when someone decides that they want to go into the tech industry they learn the big 3. HTML, CSS, Javascript. Most of the time, people end up breezing through HTML and CSS, only to struggle with Javascript.
Yes as a front end dev, UX Engineer, or whatever title you hold in your current position you are expected to be pretty good at Javascript especially since the Javascript side is what makes the sites work. But being good at CSS is a severely underrated skill, because a person who is pretty decent at Javascript, could be horrendous at CSS, and when you’re someone who is trying to become a dev out of bootcamp, the first thing people see on your portfolio site is the way things are styled, laid out, and most importantly nowadays if your site is responsive.
With CSS, there are frameworks such as Tailwind, Bootstrap which can help you make responsive and pretty sites pretty quickly, but jumping into these right away without knowing the basics pretty well can cause you to have lack of basics of CSS. Whereas, if you do everything with strictly vanilla CSS, you’ll have a better understanding of the box-model, the padding/spacings and you have more of a creative flexibility since its your design and styles, as opposed to using frameworks where everything is out of the box right away.
Another thing, CSS requires a crap ton of patience. More often that not, you would think CSS would be an incredibly simple fix, but then…there are some issues you can definitely run into which can test your patience.
The basics of CSS is pretty straightforward to pick up, but when you start diving into the rabbit hole of specificity with CSS, patience is definitely a virtue. A huge example of this is, say you are working in a huge code base with global styles. If you want a quick fix, you could easily go into the global file and change something, but then….that would present another problem, which means things change that you didn’t mean to change. So to remedy this situation, the best way to fix this would to be more specific with your class names in the css files.
Come in with an open mind and be willing to learn
If you’re a coding bootcamp graduate, 9 out of 10 you probably learned the big 3, HTML,CSS,JS. A javascript framework, most likely React, Node.js and an object oriented programming language either Python or Ruby. My background was working with React…for this project I got placed on…the frontend framework would be….Angular.
The reality is, sometimes you’ll end up in a position where you won’t be able to work with a framework or something you’re familiar with, so keeping an open mind on what you’re going to be working with definitely helps. Prior to joining the project, I started taking some courses on Udemy on Angular, but nothing compares to just diving deep into the project to get experience right away.
Now as far as the project I’m on, do I regret being placed on it?
Absolutely not!
One of the traits of being a good engineer is the ability to pick up something pretty quickly. Admittedly, I’m still struggling with Angular, and there were days recently when I found myself crying over an issue because stackoverflow or google wasn’t able to help me. After doing a couple of pair programming sessions with some of my senior devs I began to understand more on RxJS, Typescript and their types/interfaces.
But anyway, ever since I got thrown into this project my CSS has improved significantly, which if you’ve known me during my early coding days, was my worst out of the 3, my coding skills have gotten a lot better, I have a way better understanding of object oriented programming since Angular is more OOP as opposed to React being more functional programming based.
Speaking of keeping an open mind….
Try not to take Code Review too personally….
From my experience code review is one of the best and the worst things that I have come across during my career as an engineer. When you don’t have it a bunch of crap code can get pushed to production, which can cause problems for your code.
At my first position, there wasn’t really code review. We had a process of when we raise our MR, we put in screenshots describing the changes that were done, then we would place the link to the MR on the Jira ticket we worked on. Once we see our MR is merged in, we mark our MR for retest for the QA devs to retest and see if our fixes are in.
In my current position the process is pretty much the same, except the extra step of posting it on our teams channel and other members of the team actually reviewing the code. It’s also interesting to me because as a junior dev, I would normally expect a senior or higher to review code, but I remember one day my senior dev was saying during stand-up that EVERYONE should be reviewing code. Which of course led to me asking “Does this include me?”. To which he answered: “Yes, you’re part of the team, you should be reviewing other people’s code”.
Code review as a junior dev is a good thing because you have a chance to see other pieces of the code base that you might not even get to touch because that’s not your “part” of the code so to speak. You also get to see the styles on how the more senior engineers code, and you get to ask them why they coded it the way they did, which is a great way to learn, if I say so myself.
Now, when you’re on the other side of code review, it can get kind of discouraging especially when you see a bunch of comments pointing out the same thing over, and over, and over again. Recently, I was assigned a task where I would actually be able to develop something from scratch and I guess call it mine. So I developed it, asked some help from one of the senior devs because I still wasn’t too familiar with RxJS and raised the MR.
For code review, the next morning, I woke up to 39 comments on my MR. Most of it was reminding me to remove console.logs, forgetting to use CSS variables, and some feedback on some of the functionality I implemented. After I raised that, I received more feedback, and it just snowballed into over 70 comments.
After that week, a part of me was so broken from code review.
The following week, I got reminded by my coworkers that code review isn’t supposed to be taken personally, its a way to help you grow as an engineer to help you write more intentional code, less buggy code, it ensures you’re following the code-style guidelines, and its also a way to learn something new too as well. After that week of dealing with that MR, I started becoming more aware when I push up/raise my code for review.
Communication is Key
One of the most underrated skills you need when working as a developer is communication skills. Gone are the days when software engineering is considered an activity where you are sitting alone and not interacting with anyone inside the programmer cave.
One day at work I was talking with one of the senior devs who was working with the same client but on a different part of the code, I reached out to him for help but I was having some trouble explaining what I needed help with.
He told me to take a deep breath and to slowly explain what I needed help with. Afterwards, he was able to point me in the right direction on how to implement the feature with some amazing pseudocode. After he explained it to me and wrote it down, I was easily able to come up with solution on how to get it working properly.
When I first started working on this project I’m currently on, I often reached out to the senior dev of my project but I wasn’t very good at asking my questions. I remember one day that before we met on a very quick call, he told me to recap what I originally did, and to be more specific on what I was asking as well as what errors were popping up and stuff like that. Nowadays, I try to be very specific with errors that I get when I’m working/debugging as well as providing screenshots with errors and what I’ve tried previously.
Also, if you’re given a very large and vague development task don’t be afraid to reach out and ask! If you are a junior dev like me, everyone wants you to succeed, learn, and are extremely willing to help. It’s very intimidating to reach out and ask, but trust me when I say, I guarantee people want you to succeed in your role.
In addition to working with the front end devs, I also work with a couple of backend devs who I would reach out to if I had any API related questions, a designer on my team who I would ask and receive feedback from with my initial implementation of the design, a PM who I would ask questions about the tasks given to me if I need something specific, and of course my senior dev on the project if I would need some help with stuff.
Get to know the business side of the project you’re on
As I’ve mentioned in the earlier section of this post, engineering is not just sitting and coding on a project all day, the reality is its really a small piece of the puzzle. I have some meetings here and there, not as frequent if I was a senior or a manager but I have a good amount that I do attend during the week. With the exception of sprint demo, I was kind of a face in the crowd of devs. I remember I think 4 or so months after I started my current position, the PM of my project told me he wanted me to get a little bit more screen time in front of the client, so I got invited to another meeting during my day.
After I started attending these meetings, I started to see a little bit more behind the WHY of what we were building. I got to interact more with the client and see the business logic and things that I wouldn’t really be thinking about.
In addition to that too, when given a large development task such as implementing a new feature, there are times when you do actually have to reach out to the people on the business side of things to get clarification on the requirements you need to develop, so definitely try to figure out whos who!
The hardest thing isn’t coding, its knowing what to google
I remember when I was working on a bug, I reached out to my senior dev to help me out because I ran out of ideas at this point. In the span of 3 minutes, he found a solution for me which worked with what I was trying to fix on stackoverflow. I asked him how he managed to find it out right away he responded:
“The hardest thing about development is knowing what to google”
Its true, and this popped up again recently, I was trying to add in a feature, but was can maximum stack call error on the console. I reached out to the senior dev who helped me come up with this solution, because he foresaw that error happening, and he googled it and came up with a fix for me to implement.
Googling as a dev is definitely an art. More often than not, just copying and pasting the error that you receive on the console can lead to a quick solution on stackoverflow, but if that doesn’t lead to the solution you need you definitely need to think outside of the box on how you’re googling what you’re trying to solve, such as using specific keywords, so if you’re googling something with Angular such as what I often do while working be sure you include Angular and not AngularJS (if you know, you know), or even including the keyword site: especially if you wanna go through stackoverflow.
So yeah, these are a couple of lessons I’ve learned the past year working as a front end developer! I’ve definitely learned a lot of lessons and my perspective working in the tech industry has changed a lot since I’ve entered the industry. This is just a few things I’ve learned so far, and I hope whoever reads this is slightly entertained and gets something out of this.
