I have been working lately with junior front end developers, as well as mentoring aspiring developers and one of the questions that they ask me is how to become a better/senior developer. That's a question that is hard for me to answer quantitatively but the one quality that I know about senior developers is their ability to solve problems, in a timely fashion. In this post I wanted to illustrate that aspect, but also to give an anecdotal insight into what a day might look like in the life of a front end developer, and the twists and turns that it can take to solve a seemingly simple problem.
The Bug
I had implemented a new report page for one of our applications, where the user can create a spreadsheet like report by setting a few parameters. I say spreadsheet like because although it visually looks like a spreadsheet to the user, I implemented it as a flexbox based grid of individual grids, due to other requirements that made it difficult to achieve with a regular table. So far so good, except that to maintain the table appearance, I really need pixel perfect coherence between the individual grids which after a little tweaking with padding and margins I achieved on Chrome on my Macbook. The code is deployed, everything looks good except for my colleagues running on Windows, they observed a slight shift one some of the columns, breaking the table illusion. To give you an idea, this is what they were observing:
Easy enough I told myself 8:30ish AM that morning, it's just another rendering issue, I just need to reproduce it and fix it.
Lesson 1: "It works on my machine" should never be a valid developer's answer to a bug. Unless you believe that other people at delusional, you should use it as a basis to start your investigation knowing that at least it works somewhere. It should never be from your perspective the end of it.
Reproducing the issue on Chrome/Mac
Like i said, my colleagues on Windows 10 were definitely seeing that bug so I first tried changing the resolution on my Chrome browser to see if it might be related to a responsiveness issue, no dice that way. Next I changed my focus to the operating system and thought that maybe the issue was related to a difference in the Chrome rendering depending on the OS.
Reproducing the issue on Chrome/Windows 10 with BrowserStack
Next then was trying it in Chrome on a Windows 10 instance of BrowserStack. After many tries, again no dice. Let's try something else. I remembered I had a IE11/Windows 10 VM lying around for my (non Chrome) Edge. By this time, with standup included, it's 12:00ish PM.
Reproducing the issue on Chrome/Windows 10 with VirtualBox
I fired up the VM and tried to reproduce the issue, still no luck. I further probe with my colleagues and it became clear that the issue was resolution related. Their laptop was running on a 1920x1280 resolution and they were easily able to reproduce. i spent the next hour or so trying to get VirtualBox to render my Windows 10 VM guest using that same resolution to no avail. Somewhere in my Googling somebody mentioned using Parallels, which I had already installed.
Reproducing the issue on Chrome/Windows 10 with Parallels
With Parallels fired up, I was quickly able to fire up a Windows 10 VM with the correct resolution, install Chrome, which led me to one of my favorite snark for my Windows colleagues
Abou Kone@abookone
Internet Explorer: Browsing tool mainly used to download Chrome on new Windows installations.18:56 PM - 21 Feb 2020
0
1
and lo and behold on accessing our dev server, the bug was there as soon as the page loaded. After a quick debugging session, I found the culprit behind the rendering issue.
Lesson 2: Be good at accepting when it's time to fold. If you're going down one road and it's not working, learn to quickly re-assess and try something different that will get you closer to your goal.
The Problem
While defining one of the borders for a particular grid, I had used the following code:
border-top: dashed
On Chrome Mac, this translated actually to:
border-top: dashed 3px;
Basically creating a 3px dashed border by default. I naively assumed that this was the default border with in Chrome. I found that in Windows, leaving Chrome to make the decision actually rendered as:
border-top: dashed 1px;
So there was always a 2px difference between the grids. Easy enough, now that I knew the problem, I wanted to switch back to my local env to fix and test the issue. It's around 3:00PM.
Lesson 3: With CSS, be as specific as possible when creating your rules and don't assume.
The Fix
Here again, while trying to work on the fix, I ran into another snag. Our Angular app runs on port 4200, and our API on 8080, which means that even after setting Parallels to be able to access my Mac localhost from my Windows VM, I was still unable to launch the app because of CORS issues. There are many different ways of solving this issue, i quickly tried:
- Editing my
/etc/hosts - ngrok
but I decided to make use of the built-in Angular proxy configuration which we had previously used but discarded after enabling CORS on the API. What I thought would be a 1 minute affair turned into an hour when i realize the proxy configuration was not working!
The Angular Proxy
I was defining the different api proxy paths in proxy.conf.json as:
"/api": {
"target": "http://localhost:8080/api",
"secure": false,
"logLevel": "debug",
"changeOrigin": true
},
When the application was running, trying to hit for example /api/reports would proxy to http://localhost:8080/api instead of http://localhost:8080/api/reports. WTF? After re-reading the documentation many times, it finally jumped at me what I was doing wrong and the Angular/Webpack-dev-server people will correctly point out that ,y target was wrong, I should not add the context path in the target url but just the host. After changing the configuration to:
"/api": {
"target": "http://localhost:8080",
"secure": false,
"logLevel": "debug",
"changeOrigin": true
},
everything was peachy again and I was able to work and fix the issue properly. Psych! In the meantime, one of the Junior developers submitted a PR for which I had to do a code review, which lead to a video call to go over the code implication in depth since unbeknownst to the dev, his code as implemented would introduce a couple of regression bugs in the code. With that out of the way I was finally able to get back to the issue to fix and deploy, it's around 5:00PM now.
Lesson 4: Pay attention to details, especially syntax and spelling. That's why practices like pair programming and code reviews are important. Having a second set of eyes going over your code will help catch these little errors that we make that take too long for us to catch because we are used to our own code.
Summary
What looked like a simple visual CSS bug created a journey that involved of course Google, VirtualBox and Parallels Desktop VMs, Browserstack, Angular and some high level networking (etc/hosts). I've learned a few things during that process and here are some of the advice from that experience in that day that I would share with aspiring front end developers:
- Whoever told you that as a front end developer, you would only be dealing with HTML, CSS and Javascript lied. As you have seen, producing applications require a lot more knowledge that usually, you can't teach directly. It's something that you pick up with experience.
- As a developer, your number one skill to develop is your problem solving. As illustrated here, solving code issues is sometimes not a straightforward affair. You will have to solve problems within problems.
- Take ownership of your work. You are ultimately responsible for the code you produce and it is your duty to ensure that it is of the highest quality.
- Embrace the process. This is what makes our industry so fun but so frustrating at the same time. Things will not always run right, even if (you think) you're doing everything right. Things will break or malfunction, even with your best efforts and part of your job is to figure out how to get them working again.
- For non-coders on the team, it's important to understand that things that look "simple" can turn out not to be so simple, either in implementation or in correcting when it comes to estimations.
- For my non English speaking friends, up your English skills. Like i said, navigating those issues required a lot of Googling and I can't imagine how much slower I would have gone had I not been proficient in English. There is a lot of good information out there and the absolute majority of it is in English, so having a good grasp of the language definitely helps.
With hindsight now, I went back to BrowserStack and it looks like you can launch a VM with a particular resolution, which would have saved me a couple of hours maybe if I had paid attention. At the end of the day, I found the whole experience funny but not atypical, and I learned some things from it. This is why wanted to share it with others, especially, more junior developers dealing with impostor syndrome to show you that being senior does not mean being all knowing and perfect, it just means that you're gonna "mess up in style" and usually be able to recover from those mess-ups quicker. What about you, do you have any interesting bug or experience that you could share?
Top comments (8)
Hi Code,
I'm a beginner at coding and was on a lesson on CSS 3. The exercise asked for the text to be changed from red to blue. I tried everything under the sun. Keep in mind, I had just woke up and had only 1 cup of coffee. Well I found the problem. It was, I typed blue in the wrong parameter. Moral of the story, don't try to learn coding being half awake!
True! I can't count the number of times I've done something similar. With this work, one minute you feel like a god, the next, like the biggest fool there is around!
When something like this happens and takes up ~an entire day, do you ever feel like it's been a day wasted? For me, when I spend that long working on one bug I really start doubting myself and imposter syndrome just sneaks right in.
At all Sharkie! And that was the whole point of this post, to share with others that sometimes what seems simple is not so simple and it is okay! I have more than 15 years of experience and this has happened frequently enough that in retrospect it makes me laugh. The other way to see it is that these "side quests" is how you learn and consolidate your experience, either by harming something new along or learning what NOT to do. The major point to remember is that it will very rarely happen to you twice because of the same cause, since after all again, we do learn from our mistakes. Simply accept them as unintended required side quests that rewards you with experience,stamina points and other goodies on your way to complete your main mission! 😉
What's up Abou!!
All good Eddie! Good to see ya! got a funny story to share on a bug?
Had an issue where my system did not perform as expected under immense load even though it was sized to handle much more than it took. The customer was not happy to say the least. I flew out to the office and after days of taking things apart and back again, it was a QA team member who discovered that the system was being artificially limited by an apache configuration.
The misconfiguration was limiting the system to 15% capacity. Once we fixed the config, it overperformed. The lesson I learned is that sometimes, it takes a fresh set of eyes to solve the bug. We have our own internal biases that limits where we look to solve the problem.
Hey Abou, can totally relate 😂
especially that things that may look easy and simple for others can take up a lot of time with all these little twerks and different browsers/devices ...