Design Gatekeeping, Initial Thoughts

Wednesday, February 6, 2019

I’ve been thinking a lot about “gatekeeping” in the workplace lately. As someone working in the software world, I have plenty of experience with co-workers directly judging my work (pull requests anyone?). But even so, I have a hard time understanding the level of gatekeeping and pretentiousness of the design community.

Anecdotally, it seems the entirety of the professional design community is incapable of open-mindedness or personal satisfaction. I don’t think I’ve met a designer, of any kind, that has done all(or most) of the following:

  • Like those before them
  • Like those around them
  • Been a positive influence to those below them
  • Felt secure in their own performance and value

From the view of someone adjacent to designers everyday, it feels like a whole group of people actively working against the success of their own peers. They also seem to completely disregard any one who isn’t a “designer”, and actively work against people entering into their industry. (See some of the links listed below)

It’s such a foreign way to work for me. The software world is built around a core concept of free and open software. Software anyone, anywhere can contribute to and build upon. Think Linux, or Android, or Postgres, or Vue. Our industry is also leading the way in introducing people to the field with bootcamps, mentorship programs, and falling education “requirements”.

Again, this is all anecdotal experiences. I’m 100% sure there are great members of the profession design community out there. In fact, I’ve worked with plenty of great and competent designers, I just wouldn’t call them an inclusive bunch.

To sum up, whether it’s design, software, or flipping burgers, a diverse and open community will always produce better, more unique, and more desirable results.

Some articles that sum up some of my points much better than I:

To Get More Creative, Become Less Judgemental

Stop Gatekeeping User Experience

Why are people in design so pretentious?

Final (and off topic) note:

To all digital product designers: there are more design systems out there than just Google’s Material Design and Apple’s Human Interface Guidelines. To name a few:

Please stop treating every product as if you need sign off from Matias Duarte or Jony Ive.

I’m sure some follow up is required. Maybe in another post. ¯\(ツ)

JavaScript, From an Idiot's Perspective

Monday, December 10, 2018

I’ve made no attempt at hiding my absolute distain for JavaScript throughout my career. It has many infuriating idiosyncratic gotchas’ (NaN === NaN is false?) it forces its users to learn, and nothing in the language is concrete (class v. prototype function, optional semicolons, etc.). JavaScript draws out the worse in developers by allowing them to make functional, pretty looking interfaces with relatively little effort or thought.

Not only this, but JS has some of the most widely recognized (and hated) libraries in the programming world. These libraries, though they are widely criticized both within the JS community and out, are used everywhere in the web. Every company I’ve ever worked for, every major UI framework, and even massive corporations like Google use these libraries.

Specifically, the JS world has been plagued by jQuery for the better part of 12 years. I’d wager jQuery is responsible for more unmaintainable code bases and software bugs than any other source. Ever. But the reasons for using jQuery are obvious. When jQuery came to consume the web, doing basic DOM manipulation with JavaScript was a nightmare. JavaScript was an immature dynamic page manipulator at best. So jQuery came along and everybody latched on it. And now every web developer from 2006 to 2106 will have to deal with maintaining and writing it.

But I digress, JavaScript is the focus here. So what else do I hate about JS? How about that every time a dev needs to write a decently complex bit of code they have to check to see which browsers support their code? Or how about that JS only “kind of” supports major programming paradigms like try/except, functional programing, or class inheritance. JS is a language forever stuck in a loop of catchup with every other good idea that’s out there.

But what is it that really sucks about JS? It’s toolchain. The numerous and ever-growing list of terrible design decisions made by ECMA-402, Mozilla, and Google has built an entire language, ecosystem, and industry for building and understanding the JS toolchain. From transpiling to frameworks, the JS toolchain is vast and convoluted. Honestly, understanding the ins and outs of the C compiler is easier than jumping into the JS toolchain world.

Want to build a dynamic site that works in 2018? Better learn how to use one of 50 frameworks, Webpack, Babel, and ES6. Best learn what transpiling is and what the differences between Webpack, Gulp, and Babel are. Need to use an external library? Well choose between one of ~3 package managers. What are the differences? Who knows just go with NPM because…? What’s Node.js? Why does it power everything? What’s jQuery? It powers the whole web… but it’s bad?

On top of that, in order to use any of that stuff, you should probably spend ~80 hours learning the basics of Webpack, NPM, Yarn, and ESLinter config files. All of this is just to get started with web development in 2018.

Again this is all from the perspective of an idiot.

I’ve been working with ES6, Vue, Webpack, Bootstrap, Babel, Electron, NPM, Node, and about 20 other JS related things since beginning work on mechanicalog again earlier this year. All of this to force myself to learn to work in an ecosystem that every fiber of my professional being hates.

And I have to say, JavaScript itself it a relatively nice language to work in. But I’ll continue to let vue-cli manage the toolchain disaster and rant endlessly about JavaScript.

Some other things to think about.

Go ahead and open basically any webpage and look at the number of JS files loaded into your browser. Here’s Polygon (297 JavaScript files for one page.): Polygon is a shitshow.

Terrible scoping:

function lookAtMeMichael(name) {
    if(name === 'Jackie') {
        var h = 'Hello'
        console.log(h + ' ' + name)
    return h  // h is still visible? Why?

TypeScript exists solely to get past the insane shitstorm that is JS typing. ‘strings’ are `string’s but not Strings. What? Why?

Some Thoughts on Markdown

Tuesday, December 4, 2018

John Gruber’s Markdown text markup is one of those invisible parts of the web most of us don’t think about. It powers some of the most well known web services like GitHub, Trello, and Bear; it’s something I’ve spent five years obsessing over.

I have many opinions on it stemming from my job as a software developer and the many side projects (web services, word processors, iOS apps..) I’ve built around it.

A Short History

Markdown was created in 2004 by John Gruber of Daring Fireball. While starting his career as a technology critic, John wrote a small Perl script to make HTML content easier to read and write. Essentially what Markdown allowed him to do was add simple markup to a text document that could be easily converted into HTML for a webpage.


  • *Italics* -> <em>Italics</em>
  • **Bold** -> <strong>Bold</strong>
  • [DuckDuckGo]( -> <a href="">DuckDuckGo</a>

The Good Parts of Markdown

Since its conception, Markdown has taken the writing and software programming worlds by storm. There are libraries available for it in every programming language. Plugins for every major publishing platform (WordPress, Ghost, etc.), and has become the defacto standard for writing software documentation.

On a technical level, Markdown is very fast at parsing and rendering HTML, easy to implement, and is conceptually easy to extend.

Many people have since altered, forked, and augmented Markdown. There are many flavors of Markdown, each one has it’s own additions and special sauce.

Which lead me to the bad parts of Markdown…

The Bad Parts of Markdown

First and foremost, the Markdown ecosystem is a wild west of differing standards and markup syntax. Meaning nearly every service that uses Markdown forces its users to learn its special nuances. (This sounds small, but try using GitHub with Jira everyday). This problem isn’t terrible in most cases. Every flavor of Markdown I’ve come across supports the basic Markdown syntax, but most extend it past John’s initial design.

Some flavors support video links, some defining image sizes, some text underline and strikethrough. Which sounds great!

Until it’s not and you need to rely on consistency. Say you’re using Trello’s Markdown and copy your text to a service that doesn’t use Trello Markdown? Well you may be out of luck.

Try it, paste some Trello Markdown into a Vanilla Markdown converter:

Some Trello Markdown: ~~crossed out~~

The many flavors presents an issue for developers as well. Many of these forks don’t have much coverage in third-party language libraries. Want to parse or render Trello Markdown in Closure? Good Luck.


Markdown is an imperfect perfection. I will always think of it fondly and John has single-handedly reshaped how information is created and shared on the internet. So I guess it can get a pass.

And We're Back

Monday, October 1, 2018

Hello World. It looks like mechanicalog is back. Look forward to ramblings, insights, and op-eds.

A Journey to Less

Wednesday, February 1, 2017

For the last few years I have tried to practice the ‘less is more’ approach. Meaning that I have been trying to own less, buy less, and worry about less, i.e. minimalism. Taco meat

Rewind a few years. Right out of high school and early into my college years, I spent all of my time trying to earn money, and all of money buying stuff. I bought computers, video games, clothes, food, drinks, phones, phones, and more phones. I was consumed with things, always having the newest thing.

The summer of 2012 was truly an eye opener for me. I had just finished junior college and was moving on to university. Moving to a new town and a new home was stressful. I had so much stuff, I didn’t know how to move it all myself. Combine that with my ever growing stress level, I wasn’t happy.

This is when I decided to scale it down. A couple of weeks before the move, I decided I would get rid of enough possessions so that I could move everything I owned in a Ford Escort, minus my bed. I donated, sold, and threw out more than half of my things. And at the end, I met that goal. Two weeks later, I moved in just my Escort and a shared moving truck with three others.

That experience began the last five years of my life, at least that’s what it feels like. I’ve tried to continuously live by that mantra. Every time I’ve moved, I’ve aimed at moving in just the car that I owned, and whatever my bed went in (thanks uHaul). I’ve moved a lot. Sometimes three times year. Some of those moves I’ve succeeded in that goal, some I’ve failed.

Then this last year I decided I was going to move to New York. I decided I was only going to take what I could fit in my car, nothing else. No bed, or dresser, no desk, no chairs. Just the things I could fit into the doors of the car. I told my friends and family. They wanted to know a lot of things, asked many questions. But one of the most asked was: “How are you going to get everything there”? Telling them I was moving in just my car always brought the same response: “I could never move with just a car”.

I found it a freeing experience. In fact one of the greatest opportunities in my life. Months before moving out east, I began the process of slimming down. I really got the chance to examine every individual item I owned and decided if I really needed it in my life. When the day came to move, I only had the following to bring with me:

  • 4 boxes of stuff (filled with all kinds of things)
  • 1 tote
  • 2 backpacks
  • 1 desktop computer
  • 2 monitors
  • 2 bags of clothes
  • 1 cat
  • 1 litter box
  • Every thing in my pockets

That was it. And it was amazing. And since then I’ve remove about a quarter of the clothes, one box of stuff, and one monitor that I had brought with me to New York. I have acquired some things as well (mainly a bed and frame), but for the most part I probably own a tenth of the stuff I had near the end of my years in junior college.

This is all to say that I am one of the lucky few who has been capable of increasing happiness and decreasing stress by just owning less. I know that this isn’t something that most are interested in trying. The appeal of owning a lot and having everything you want is strong. But I urge everyone to try walking a journey of less.

Mechanica Manifesto

Monday, November 30, 2015

an introduction

Hello World. I’ve decided to put pen to paper in an effort to collect, sort, and interpret an ocean of ever growing thoughts. This place exists solely to start a conversation and to explore future topics.

A bit about myself: My name is Aaron. I am a master’s student, a teacher’s assistant, and a web developer. My background is in film production, web development, graphic design, and a tad-bit of journalism.

I consider myself a student of minimalism, efficiency, and beauty. These three concepts are the founding principles I will try to instill in an effort to convey meaning.


Readers can expect most of my writing to consist of the following:

  • technology - Seven years ago I started following the tech industry regularly. It’s been a long, fast, and ever-changing road that I’d go down again if asked. My love for all things tech reaches from gadgets to media, and big companies to startups. I follow everything and have opinions on it all.

  • design - We have created everything. Cars, phones, computers, coffee cups, software, you name it. Somewhere down the line a human designed it. This reality has had me come to the conclusion that design may be the single most important aspect of our world. I think the world is generally an ugly place. Not figuratively, but literally. Therefore, expect many articles dedicated to the topic, and don’t be surprised if it finds its way into everything else.

  • media - Film, TV, music, news, and other consumables. My film production background has inspired me to look at every piece of media critically. Sometimes I’ll review a movie, sometimes I’ll just write about an actor/actress I’m into that week.

  • fitness, the financial market, coffee, taco trucks - The point being I will write about anything and readers should expect a myriad of topics.

Topics may be all well and good, but I really want to stress the importance of how I’ll look at things more so than what I’m looking at. I prioritize design and experience over technical specs. I won’t fall into the trap of bigger is always better. Readers can expect writing reflecting how a topic effects the everyday. If reviewing a phone I’ll talk about user experience and the feel of use more so than the number of cores, or gigabytes of anything. My thoughts always revolve around how technology, design, and media can make our lives better, easier, and more enjoyable. I write with intent to examine that philosophy.

One more thing:

I am based in the U.S. Most of my articles will be centered around U.S. topics. I am always trying to expand my horizons and will try to incorporate international issues into mechanica log.


Mechanica log is built from the ground up to be minimal and lean. Writing, publishing, and reading are meant to be fast and easy. I deployed, setup, and designed mechanica log in under three hours. This was in reaction to previous attempts to start writing portals that were always bogged down by my own perfectionism.

Mechanica log is barebones and it won’t be as feature full as many other online publications anytime in the near future. Don’t expect comments, tag clouds, or anything else gaudy to show up.

I promise you that I will present articles in a straight forward manner. Things like lists, top tens, etc, will always be one page. Headlines will try to convey meaning, not be clickbaity SEO monsters. Articles will be structured as to optimize readability and easy of use.

Lastly, mechanica log is an evolving experiment. I don’t have answers to everything and will be solving problems as I go.

Here’s to trying.