Remote 15+ Years Full Stack/Front End Web and Generalist Developer (JavaScript/Polyglot) - Chicago, Illinois

Note: it is my full intention that nobody read all of this rambling foolishness about my career. It's best skimmed and maybe ultimately skipped to the all caps "GETTING TO THE POINT" towards the end. The SEARS stuff might be a fun read for anybody who's ever suffered a hot mess though.

EARLY

This career is the product of an aborted journalism degree. I had previously worked at Game Informer Magazine for a few years and decided I wanted to return to becoming a "real" journalist after some low-level IT work that turned me on to the idea of maybe exploring code again (I hadn't really since high school).

Then I discovered HTML/CSS/JS through some side classes I thought might give me some options as a journalist but within about a year of that they couldn't teach me about web technology fast enough (the book DOM Scripting was hugely helpful) and I eventually self-taught to the point where I realized I was employable. So I started begging employers to give me a crack at contract gigs on Craigslist and eventually broke into the career that way, eventually getting my first full-time job about a year and a half later. Side-note: Craigslist is also where I met my wife, arguing on Rants & Raves, back when it was more fun than toxic and racist.

SEARS

While I've always enjoyed the layout work that characterized an early front end dev's career back then, from early on I've been particularly drawn to more complex UI problems. At my first full-time job at Sears, where I joined a front end team of 20+, among many other things, I wrote a carousel that was elastic, capable of adding/removing items without losing its place as enough space became available with the resizing of the window. It had options for full page scrolls, or 1-x items at a time, it supported IE back to 6, but most importantly (and this took a few iterations to be fair), it was ultimately nigh indestructible.

"Indestructible to what?" you didn't ask? Well, for our back end team, we had, I think, 1-200 in-house global-firm-that-rhymes-with-Bimfosis devs whose code literacy mostly ranged from 100% actually code illiterate to just shy of not very competent (with some very rare and no doubt frustrated exceptions) basically jumping up and down on a customized (and thus impossible to update) websphere e-commerce back end with no version control. No lie. No version control. The front end code, of course, did. Probably for being able to easily prove what the latest version of our code was supposed to look like alone, along with the usual benefits.

Code deployment was literally those devs I just described with no exaggeration, pasting sometimes entire directories over each other directly in the server, inevitably causing all of the HTML to mutate, JS/CSS to get duplicated, sometimes with newer and older versions of the code. This, as you might guess, wasn't great.

But when everything would go to pieces, my tough little jquery carousel in its final hardened form was almost always still there with UI intact. And everything still worked even if half the controls were off the page with the busted container nobody had ever put it inside, on our end.

Another thing about me that's been true since very early on in my dev career, is that I've never been afraid to step out of my comfort zone and learn some new stuff to tackle a pain point that couldn't be dealt with with web technology alone.

Thus, another handy thing I wrote at Sears was a tool designed to identify all of that duplicated JS and CSS so we could rat the back end guys out whenever they made a huge mess and our UI started falling apart. I learned Python and regex (to this day I love a regex problem) so I could run a scraper to explore key parts of our site, identify JS functions and CSS declarations, and then scan the rest of the JS, CSS, and HTML files to count all the duplicate selectors and function names which got as high as in the dozens on our first checks.

In case you think I'm exaggerating about Sears for effect, I was there when the baby-cooking grill happened. TMZ originally broke the news.

private link

Long story short, passing data through a back end through more conventional means was apparently enough a challenge to the back-end team that they all learned this neat trick of passing content through query params in all of their links. Somebody with some web knowledge noticed this while surfing the site, the gag link they posted went viral, and it got so many hits it got cached by the server and you could actually navigate to the baby cooking grill without a direct link via the UI (our more senior guys did try to warn people about this).

Eventually, more due to related business problems than backend hijinks which were more of an interesting challenge once we took the blame game away from them, I realized I was going through a sort of perpetual grieving process that kept bouncing back to denial just shy of reaching acceptance and it was time to go. One of the strongest teams I've ever been on though. And many of them stuck it out to improve things drastically on the tech side of the organization and it showed.

MORE RECENTLY

I've had a wide variety of experiences since Sears, working in different environments from SaaS shops, to agency work, and varying stage startups which at the pre-maintenance-mode stages are probably my favorite.

But looking back on it, even the painful experiences are ones I've walked away from with valuable skills and lessons learned that have served me for the rest of my career. A lot of my early back end exposure, for instance, came from having to learn Java, JSP, and ultimately SQL (another language I prefer working with directly), to understand a hot mess of JSP that was standing in the way of solving some basic front end problems not long after Sears.

A NASTY SEO PROBLEM

And this is how I was ultimately equipped to find a solution to a big SEO problem much more recently at Insureon, largely developed on my own time since nobody was expecting or believed the front end guy (who's really a full stack guy with a preference for FE focus) could possibly solve, until I showed them the demo.

The problem was that Google (really, google?) decided that it would be really important to SEO that all links on a domain be consistently trailing slash or no trailing-slash or they would punish your rankings for it, pretty severely based on post-fix rankings improvement IIRC. On a CMS website running a variety of variant DNN versions and plug-ins, this was a beyond non-trivial task for our content team as there were many many pages dating all the way back to when DNN was relevant, and probably over 10k links to check and normalize (actual links changed was 7k-ish IIRC). It would have likely been months of painful work to update via CMS.

My thought was that our excellent DBA always had a full plate, that I enjoy SQL, regex, untangling things, and helping people dodge pain, so why shouldn't I take a crack at this?

So I did some exploratory work, identifying relevant fields in a lot of not-very-well-documented DBs and threw a node app together to search for all links in HTML content and fields, and then normalize every last one.

Naturally this whole thing felt a smidge ambitious, so I made sure to keep track of the number of replacements, conducting a character count of all changed content to verify that nothing had gone wrong. I also added a step to print all the changed HTML content out on the screen with a prompt for each modified section to give a quick once-over to make sure nothing looked like it got trashed before committing all of the changes to all of the relevant DBs.

I think it took about a week or two of exploratory for an hour or two every night, looking at the templates and then identifying related DBs, tables, and fields. And then maybe about 20 hours to get the working prototype up and running that was ultimately used to normalize thousands of links in a few minutes without a hitch.

In the end, it was one of my favorite career wins. I helped a lot of content people dodge some serious misery and apparently the SEO folks had never seen anybody resolve an issue of that scale that quickly before.

GETTING TO THE POINT

Anyway, this has no doubt gone a bit long, so I should get to the point, which is that after working with it for a year, I don't like Typescript. Not one bit.

I hope even after a small portion of that hopefully hastily scanned long form, I've inflicted on you, it's clear that it's probably not because I'm afraid to learn new things or because I refuse to work with anything other than what I'm most familiar with or that I don't care about code quality or naively believe there is only one flavor of type system worth working with.

So if that's not an obstacle and you need somebody who can:

* actually solve non-trivial UI problems that require more than plugging the disappearing/reappearing of HTML into framework state

* is delighted to assist, train and be an advocate for junior team members

* knows web technology in and out

* is comfortable with any framework unless its proponents say dumb stuff like "If you're touching the DOM you're doing it wrong"

* isn't afraid to pinch hit as full stack, desktop, mobile with the right tools for the UI, or even random dev ops project guy

* is happiest learning new stuff or facing new challenges from whatever direction they come from...

I hope you'll consider me in spite of my heresy regarding "a better way to write JavaScript."

And please don't think me too cowardly for not admitting to this on Twitter or LinkedIn. Unfortunately it seems like 95% of anything JavaScript-related has been overrun by Crockford minion carpetbaggers who when you actually press them on it, never liked or understood JavaScript for the damned-fine language that it is, that nobody ever needed to apologize for.

Thanks for your time,

Erik Reppen