14 min read

On Quitting the Frontend

Yesterday, I received an offer doing devops for a blockchain startup in Boston. It’s the first time in my professional life that I’ve joined a company in a role other than as a JavaScript developer, and I’m very excited to make the career change.

Sure, I’ve done years of independent consulting where I’ve not worked with JavaScript at all (most recently writing Elm and Golang). No matter the role, I’ve always sought to automate and write tools, and, in so doing, discovered that I have a real passion for tooling, so it makes sense to go the devops route.

This is a monumental shift for me, at least professionally, and one that I’ve been looking forward to for a long time. I’m extremely excited about moving to the back end, but I’m also tremendously overjoyed to be quitting the frontend.

I like the JavaScript language itself, which I find to be very fun to use and can be quite expressive. Yes, it has some annoying quirks, but that’s to be expected from a language that was famously written in just ten days.

But I have found frontend development to be very boring and tiresome for awhile now, and unfortunately, I find many of its practitioners don’t care much beyond just getting something to work. Ship it!

So, I want to tie a bow on this period in my life, and I thought that a brief autobiographical stroll down memory lane would be just the thing to wrap up.

Life as a Programmer

I was a late bloomer, only learning my first programming language in 2003. This was after I had taken a break from university life after earning a BA in history from the University of New Mexico. I had fully expected then to go on to earn a PhD in history and become a teacher like my parents and others in my family.

The language that I learned then was of course PHP, and I was coding websites which persisted to a MySQL database (of course). The barrier to entry was low, and it was a good space in which to get started.

There was no frontend, as it’s now known, but a UI, and it was composed of HTML and CSS, with little-to-no JavaScript. Back then, you coded the full web application. There was no such thing as a “full-stack developer”, a truly silly term; you were just a programmer and expected to know how to deliver a full web application.

Per the frontend, some people used tools such as DreamWeaver, but I preferred to write the UI by hand, which was in line with my desire to truly learn something, no crutches. Also, at the time, there was a real emphasis to learn these technologies (HTML, CSS and JavaScript) from the ground up.

( Sadly, frontend devs heavily rely on too many abstractions now, rarely knowing or caring about the DOM, BOM and JavaScript itself. Don’t believe me? Ask a frontend developer to code something in a plaintext editor like Vim and don’t let them use any libraries or frameworks. Bummer, dude. )

I enjoyed it enough, I guess, at least in the sense that I’ve always enjoyed learning, but I wasn’t hooked yet on programming. I wasn’t overly excited about PHP, and most of the sites I worked on were not very challenging.

This would change after I joined a local company in early 2007 in Pennsylvania to work on the UI for a student loan agency in Pennsylvania (I had a mortgage to pay, after all). The role was as a UI Interface Developer, as it was called back then, and through it I was exposed to new JavaScript frameworks such as ExtJS. I was also given a lot of space to build an internal library of APIs and tools, as the team was (re-)writing and copying/pasting the same code whenever a new feature was developed from a wireframe. It was a wonderful opportunity to explore and learn, and I took full advantage of it. It was so much fun.

ExtJS, as it turned out, was to play a major role in my programming life, as we’ll see. I was blown away by it, and in reading its source code, it set me on the JavaScript path for the better part of the next 11 years.

My History with JavaScript

Yes, I wrote my own JavaScript library, unapologetically influenced by Ext. Included were some widgets, such as a data grid and drag and drop functionality, and a DOM query selector parser. I was fairly proud of it, and I used it on all of my own projects (Memory Game, Music Theory, Code Buddy, et al. Code Buddy has been lost in the mists of time, sadly. ).

Back then, there was a real lack of JavaScript tooling. I didn’t think too much about it, other than just accepting that that was the state of things, but in hindsight I’ve come to believe that was a very good thing. It meant that I’d have to come up with my own solutions rather than lean on an abstraction.

Of course, everything is an abstraction, and using one, such as a tool, isn’t a bad thing, but there’s really no excuse to use an excess of third-party modules when it comes to developing in the browser. And, in 2007, one didn’t have that dubious luxury.

In the days before jQuery, when I was having to ship code that worked cross-browser, I learned how to write JavaScript and CSS that performed and looked the same on IE 6 & 7, Firefox and Safari. And it wasn’t just me, it was everyone writing code for the browser. You had to know this stuff, and no company would hire someone that only knew how to write JavaScript and CSS that worked in only one browser.

I remember when Ajax became a thing. You looked at the spec and wrote your own little Ajax library with conditional branching for Internet Explorer and then everything else. Remember all the DOM Level APIs? I do, and I could name the improvements that each one brought.

Those are some of my old man credentials, but seriously, it was important to know this stuff.

It’s not like that anymore.

Seeing Purple

In those years, Yahoo! had been setting the pace, and I was regularly on YUI theater to learn from their latest video postings (Crockford’s first round of tutorials on JavaScript was a huge source of inspiration to me) and buying all the books put out by its JavaScript programmers.

Fast-forward two years. I went from that company in PA to Yahoo! in Sunnyvale, CA, via a brief stop at GoDaddy in Phoenix. It was a dream job for me, and I settled into my role as a JavaScript developer (Technical Yahoo!) working on the Connected TV team.

In November, 2009, Yahoo! was still the leader in JavaScript programming (although, there were cracks in the foundation), and there were many prominent voices in the JavaScript community that were still employed by the company. For example, I unwittingly insulted Douglas Crockford in a conversation in URLs. As usual, I thought I was being hilarious, and it was only later that I realized what had happened. I was mortified. Of course, I apologized, and he was very gracious about it.

I learned a ton of stuff on that team. Working with JavaScript on an embedded system and interpreted in a runtime other than that provided by the browser, I was exposed to many things that I never would have encountered by just working with the browser.

And I had a lot of fun. I had the opportunity to travel to Las Vegas with my team to help man the Connected TV booth at CES 2011. One day, after a nice tinkle while taking a break from the booth, I spotted Ozzy Osbourne combing his hair behind me in the mirror as I was washing my hands. I didn’t say hello because I thought he must have been an impersonator. What an idiot (me).

At Yahoo!, I attended as many presentations as I could, which were very frequent on the campus. For instance, you can see me in a photo from when Ryan Dahl gave a talk on a new JavaScript runtime he was developing called NodeJS. I’m in the upper right corner in the red Phillies hat. Deal with it.

Here’s another one, from Yahoo!’s 15th Birthday Party. I’m giving horns with the band Collective Soul after their performance. Handsome!

Weeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

“It’s nice to want things.”

I was fairly happy at Yahoo!, but then I was contacted by a recruiter to interview with Sencha, the company that owns the aformentioned Ext framework that influenced me so much. I jumped at the chance, and after an excruciating two months of waiting (they were in the process of wrapping up and releasing Ext 4, a fairly seismic change from Ext 3), I got an offer to join.

I was ecstatic. Again, this was the framework that inspired my passion for JavaScript four years prior, so it was an easy decision to leave my position at Yahoo!. Even though it was less money, I recognized a great opportunity when I saw one. After all, money isn’t everything (as my Dad says).

Sencha was a great place to be in 2011. It was a still a startup, an atmosphere which was new to me, and I was employee number 40-something. We were all in the same room, no cubicles, no walls. Having joined the company as a support guy (although it was a heavy development role), I started making code commits within two months of my employment and got to know all the programmers on the Ext frameworks team, where I eventually landed.

I learned a ton, especially from Don Griffin. Not only was he a fantastic manager, but he’s one of the smartest people and best developers I’ve ever had the pleasure to work with.

Among the skills I honed was how to write modularized code. I became really good at debugging and refactoring. Any later bug fixes that touched the areas that I had refactored were usually only surgical in nature, often just needing to change a single line. I saw this as a good sign that the refactoring or bug fix was the right choice.

I started to trust my judgement much more than I ever did, and my confidence grew as my pull requests started to become merged faster and with fewer comments asking for changes and updates.

Don was great at gently pointing out or otherwise making me aware that something I was doing needed improvement. For example, I became embarrassed at the realization that frequently I didn’t fully understand a problem that I was trying to fix, and that lack of understanding became painfully obvious when he would ask me to explain the problem and its origins.

And that had larger implications. For if I didn’t fully understand the problem and what needed to be fixed, I couldn’t possibly fix the problem in the best possible way, which often took the form of a minor refactoring to make the code more maintainable and less tightly-coupled.

Mind you, it wasn’t laziness or a lack of interest or that I didn’t care. It was a time issue. Well, a lack of it. With many other bugs and tasks on my plate it was difficult to give every one the full attention it deserved.

This would invariably stress me out. I wanted to spend the time necessary to fully understand the issue and to fix something the right way, but, for a whole variety of reasons, that can frequently take a significant amount of time, time which I didn’t think I had.

The best managers and coworkers implicitly understand that programming is hard and can often be time-consuming, but it wasn’t until Sencha that I experienced a true programming environment, one where developers were truly valued, their judgement trusted and time and space given. I was in the trust tree.

Further, Don insisted that “it takes as long as it takes” to fix something, and this gave me the space I needed to do my work. I was so grateful. For the first time, I really understood the benefits of having a good manager.

And it wasn’t just me. He gave the entire frameworks team (all six or seven of us) the time to dig in and fully understand the implications and scope of a fix. This of course meant that the codebase would continue to be hardened and improved.


After nearly five years at Sencha, I made the decision to leave the company. It wasn’t an easy decision, and my main motivation was to join a company that was using the latest and greatest libraries and tools in the JavaScript community. Ext is great, but it’s a walled garden, and I felt that I was falling behind in what I should know about the latest iteration JavaScript development.

Although it was the right choice to leave, I would become tremendously disappointed and frustrated with what I discovered outside of that walled garden. My expectations did not match reality, and I would learn over the next several years that JavaScript web development had become appallingly bad, at least as practiced by the companies I worked for outside of Silicon Valley.

Enterprise Sucks Balls

I’ve made a huge mistake. I’ve followed through and joined a large company in Waltham, MA. I quickly regret the decision, and it isn’t long before I leave the company.

It’s not worth going into much detail; it’s very boring, and no one cares. I was a terrible fit for them, and they were a terrible fit for me.

I was shocked at how little people knew despite the impressive titles: Senior Frontend Engineer II; Principal; Architect. They were intensely Agile.

But, I felt real knowledge was lacking. Only one other colleague understood prototypal inheritance. There were many, many abstractions, mostly used poorly. The codebase, not old, was already filled with several unnecessary layers of indirection and misdirection, and I was never given time to fix any of it because the team culture didn’t believe that doing so added any “value to the customer”. The most common response to almost any question was “because, we’ve always done it that way”, and any change was resisted.

It was tiresome, and we were all glad when I left.

Weeeeeeeeeeeeeeeeeeeeeee


At this point in the story, my wife and I had already left the Bay Area and moved back to the east coast to be closer to family. We initially move to a small town on Cape Ann on the Atlantic, later moving to a small farm in central Massachusetts to have a bit of land and more animals.

I was so turned off by corporate culture and frontend development that I spent the next two years feeding my head and doing freelance work that turned out to be mostly Elm and Golang. My wife was totally supportive. It was fun.

Quite suddenly, it ended when my biggest client surprised me one day by saying that the work had suddenly dried up. I was completely caught off guard, and made a fear-based decision that was a huge mistake. The same one as before, actually. Derp.

How could I have made the same mistake? Because it was safe. I wanted to transition to the backend, and I believed that my best shot at doing so would be to join a large corporation doing frontend work and then make the transition internally to a backend team. It made a great deal of sense at the time. Additionally, I felt that I wouldn’t be hired onto a backend team out-of-the-gate because I didn’t have the necessary experience, and I should hedge my bets by playing my strongest hand, which was frontend programming.

The corporation I ended up joining did tick many of the boxes, so it wasn’t completely crazy that I’d do it all over again. For example, the salary was great, I could work three days a week from home (very important with all of our animals), and my would-be manager personally assured me that she would help me to move to a backend team in two years.

So, I sold myself out.

And lasted six months.

As it turns out, I’m a terrible corporate employee.

Conclusion

So, after a month or two of prodding, I finally agreed to apply at Algorand, where Chester works, culminating in the offer I mentioned in the beginning.

I’ve said for years now that I was lucky to have worked in Silicon Valley at two of the finest JavaScript companies in the world, and that it was a once-in-a-lifetime opportunity.

However, I think now I may have another shot, and I’m taking it. I’ll be working with an amazing group of people, one of whom is a Turing award recipient.

Fatti forza!