Ryan Martinsen

10 years of charity: water

This video is just over 20 minutes long, but well worth your time. Please watch it when you have a chance.

Everyone in the world needs clean drinking water and you can be part of making that happen.

There’s a lot of crap going on in the world. Be a force for good.

On Being Dismissive of JavaScript

I started writing PHP in 2003. I wrote it full time until being moved to a new team at my job in June 2014. My new project had a back-end in Python (Django) and a front-end in JavaScript (Angular).

I was excited about the Python, but I had a lot of reservations about the JavaScript.

I loved jQuery when I discovered it in 2007. I don’t remember an exact moment when I stopped loving it, but when I did I decided all JavaScript was bad. Maybe it was working on (or creating) one too many large piles of spaghetti DOM manipulation. Perhaps it was dealing with old browsers. Whatever the cause, I decided I didn’t like JavaScript anymore. Death to JavaScript! Yay backend programming! Down with CSS, too, because this bandwagon is going places!

I doubled down on my dislike with every hot new JS framework I heard about. Backbone? Boo! Knockout? Hiss! Ember? Haha look how stupid this website looks when JavaScript is turned off!

But now I was going to be on a new team working on a project in Angular 1. I had to learn this stuff. Would I rage quit in a few weeks? Or would it provide me with so much snarky tweet material that it’d all be worth it in the end?

Here’s how I was feeling one month into this new project.

This was my way of saying that using a big JavaScript framework was the same as failing. Because how could you not notice? Portions of sites would load slowly or fail to load altogether. It all felt like a big step backwards.

By October I was beginning to toy with the idea that there might be something to this whole fancy front-end framework thing. It wasn’t my thing, but it’s maybe okay if it is for some people. Surely I’d move on and find a new job soon.

This tweet by Guy English couldn’t have come at a better time. It was a slap in the face. In a good way.


I held no delusions that I was anywhere near the top of my field. I knew I wasn’t, but this was a very clear indicator that I had farther to go than imagined. I don’t think I was exclusionary, but I was most certainly dismissive of JavaScript, JavaScript frameworks, and the people who pushed for them.

I had known for months that I had two choices. I either needed to get better at JavaScript in spite of not liking it or get a back-end job and never touch the front-end again. Since I wasn’t about to quit—being 1 year short of my 3 year job goal—a new job wasn’t an option. It was time to take off the blinders and learn JavaScript for real.

Huge Blinders

While I didn’t go from disliking it all to loving it overnight, the decision I made in October 2014 made an immediate difference. Instead of being annoyed all the time I started enjoying the act of learning a lot more. I also began to see JavaScript and its frameworks not as gross hacks that sometimes break, but as incredible tools that push the boundaries of the web.

People are doing amazing things with JavaScript—things I never would have built or even dreamed of because I was too busy congratulating myself for being part of the crowd that hates JavaScript.

Yes, there are lots of real issues with JavaScript and JavaScript frameworks. Speed is still a major issue, for example.

But the issues are being solved. They’re being solved by people who care. Tools and frameworks are improving because of people who see potential where others only see failure. The dismissive people aren’t contributing anything.

I haven’t ever been very involved in the communities built around programming languages. I’ve only answered a few questions on Stack Overflow. I haven’t done much open source work. I honestly haven’t figured out how people find time for any of it, but I’m going to attempt to get involved more. I don’t know what form that will take (maybe blog posts), but I do know for sure that I’m tired of only consuming and critiquing.

JavaScript is easy to make fun of. So is PHP. And so is Visual Basic, the language I started on. I liked working in Python not because I felt it was a better language, but because I finally felt like I was using a respected language. That mattered to me.

But now?

I don’t care.

Worrying if people respect the language I use is silly and pointless.

You think JavaScript is dumb? Don’t like web development at all? That’s cool. It’s okay to not like things, but there’s no need to be a jerk about it. Been there, done that.

All hating and being dismissive of JavaScript ever did for me was slow me down.

I still catch myself being dismissive and overly critical of new or old technology and I almost always regret it. I don’t have to care about everything thing in existence, but I also don’t need to create reasons to dislike them.

Have you failed if you use a Javascript framework? No. Is being dismissive of a technology you haven’t bothered learning the same as failing? Yes.

Suggested reading:

Learning to Slow Down and Think Under Pressure

Once upon a time I was in charge of a release for an important update to a large project. I had to coordinate the release with other teams in order for it to go smoothly.

Most projects I work on these days have release processes handled by a QA department wherein they press a button and things happen automagically. This project lacked a real release process. Here’s what a typical release looked like on this project:

git fetch origin

# manually review changes as a sanity check
git diff --name-only HEAD..origin/master
git diff HEAD..origin/master

# release if everything looks good
git merge origin/master

For the record, this is a terrile way to do releases, but it’s what we had.

For this big release I didn’t look at the full diffs because there were thousands upon thousands of modified files. I’d already spent days combing through the diffs. No need to do that again on production.

When the clock struck 12 and the office began to vibrate with the sound of the massive bells that we had set up just for this release, I hit return on git merge with great expectations and… there was a conflict. Surprise!

Now, in a normal situation with an unexpected conflict (i.e. there should be no modified files on production!), I’d perform a git status and git diff to see what was going on. If the modified files were important I’d do a git stash and then reapply the stashed changes after the merge.

But this was no normal situation. Other people were anxiously waiting for an update. We had a plan! My part of the release was supposed to take 30 seconds.

I tried to stick to the planned timeframe instead of doing the proper due diligence to see what was wrong. New information cannot slow me down! I’ve never seen this particular conflict on this server before! Surely I can plow onwards!

It’s like my brain threw an exception and I had no exception handling in place. All previous releases I’d performed on this server had been fine.

I did have the presence of mind to ask other people if the specific conflict mattered. It did not. So I proceeded with gleeful abandon and did a git stash without looking at what I was stashing. I thought I was stashing changes to one file and that file didn’t matter.

Unbeknownst to me, there were other files that had conflicts too.

I informed everyone that I had successfully deployed the code. Whew! Time for the next step, restarting the webserver!

This is basically what happened:


The server did not restart.

The site was down.

We all scrambled to figure out what had happened.

We eventually discovered that the server configuration was outdated and that it lived in the git repository (never do this). How it had become outdated, I had no idea. I hadn’t ever touched the file. It took an hour, but the server configuration was updated and the site came back online.

I didn’t realize what my mistake had been until the situation was resolved and my stress level dropped. At some point the webserver configuration had been updated on production. I didn’t know it was in the git repository. Had I looked at the output of git status or run a git diff I would have seen it and avoided the whole problem.

But I let the stress of the situation get to me. I placed too much importance on our timeframe and ignored the very obvious red flags staring me in the face.

I learned that when I am stressed I don’t naturally think through changes and new information clearly before acting. Instead, I panic and make things worse by trying to stick to an outdated or bad plan.

I haven’t completely solved this problem yet (being human and all), but I am getting better at it. I try to expect and plan for changes or complete failure. If we plan on a day at a water park and it pours rain, it’s okay to stay home and watch a movie. There’s no reason to be miserable in the rain all day.

It’s okay to slow down. It’s okay to rollback a release and evaluate what happened before proceeding. Arbitrary timeframes don’t matter. In fact, strict timeframes also don’t matter if you screw it up.

A good way to slow down in a high stress situtation is to eat cookies. The cookies will (hopefully) taste so good it’ll be hard to put them down, thus providing you with critical thinking time.

In fact, I’m so committed to this whole cookie thing that I’ve decided to pivot my entire career and become a Cookie Baking Release Engineer. Feel free to reach out if you feel this would be important for your business. I am also open to making donuts and ice cream.


Read more in the archives