In hindsight, I was able to change my career to frontend developer without much effort at least initially.
I was at this one company working as a data analyst, and sort of just switched my position to frontend developer, thanks to flexible internal transfer policy at that time.
As a data analyst, I had been using tools like RStudio Server and Jupyter Notebook, and I was always intrigued by the fact that they ran in the browser.
- "How is it possible that I type an R command or Python command in the browser and it evaluates and returns the value in respective languages?"
- "Is there a Python or R interpreter hidden inside the browser?"
- "I thought browsers only understand JavaScript.."
Questions remained unresolved. And more and more I wanted to understand how the web worked.
The timing of the transfer couldn't have been more appropriate, because my company was actively developing a data analytics solution for our corporate clients, and our dev team desperately needed a perspective from data analysts, the expected users of our solution. And well, I sort of fit into that picture nicely.
I was both excited and worried to start working as a web developer. Interestingly, nobody in the dev team seemed to care if I were familiar with web technology or if I knew what was expected for the new role.
It didn't take long for me to realize how unprepared I was to do the job.
From day one, I was looking at a React.js code base even before I had any understanding of how html, css and javascript worked—I still find it funny when I think about how confused I was, looking at JSX syntax all day.
A few weeks in, I was surprised how little the required knowledge was to complete a small task like changing styles of a small UI component. So I was able to get by, only focusing on the narrow context that was relevant to my assignments, treating everything else as a black box.
But my curious mind felt uneasy not knowing how the black box worked. So every spare moment I got, I would start searching how things really worked.
Well, it turned out that understanding how things really worked was incomparably harder than completing my assignments. All I managed to understand was that what's actually powering our frontend project was these scary-sounding javascript libraries; Webpack, Babel, Redux, Reselect, Sass, etc. And actually, reading their documentations left me even more confused.
I occasionally asked our team lead about how things really worked under the hood, only to receive an answer that was either very hard to understand because he used a lot of other jargons that I was not familiar with, or he didn't know also.
One day while my curious mind was searching for answers online, I accidently found a Github project that looked suspiciously similar to our frontend project—later I learned our project used this github repo as a boilerplate and grew from there. That was when I started to suspect, "maybe understanding how things really work is hard for everybody." And I was expecting, "maybe as I gain more experience in web development my understanding of lower level stuff would increase naturally as well."
Well it did, to only a limited extent, but still the actual mechanics of Webpack, Babel, and React were still largly a mystery. The gap between what I wrote in the IDE and the actual html, css, and javascript that were running in the browser didn't seem to be getting any closer.
And these uncomfortable thoughts started to emerge in my mind,
"Maybe I'll never be able to understand these lower-level javascript libraries if I continue working as a web application developer, no matter how many years pass."
"And if things change in the future, and other libraries gain popularity, and the industry expects web developers to know how to use them, I might have to learn them all over again."
"What I now know about how to use React might not be too helpful for me to learn another popular framework in the future."
"When we use frameworks, are we really learning core fundamentals of the web? or are we just getting used to a particular way of doing things and a set of particular syntaxes?"
These questions eventually led me to start thinking,
"What differentiates the authors of frameworks and the rest of us, the users of the frameworks?"
"Are they all born geniuses who started programming in their early ages?"
"Maybe they all have very solid foundations in computer science, to create something like a javascript framework."
That's actually what I have believed for a long time; one needs to have a solid understanding of computer science fundamentals to create something like React. So I was going to take a year off of work and study CS fundamentals, following this wonderful website: teachyourselfcs.
While it's certainly the case for a lot of framework authors to have a strong CS background, and I still think it's invaluable to learn CS fundamentals as someone pursuing career in software engineering, I have also found many counterexamples to my assumptions. People like Evan You and Rich Harris, they don't seem to have a very strong computer science background, and yet they've created some incredible javascript tools and frameworks that people love.
As I found more and more counterexamples, I was more and more convinced that focusing soly on web development would be the way to go—time as a resource was also a huge factor to consider. I can only afford about a year or two without an income, and by the time I get back to job market, I want to be a better web developer.
So here I am again—this time with an abundance of free time—trying to understand how things really work under the hood.
It's going to be an exciting year, because I'm doubling down on web dev.