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.

Examples:

  • *Italics* -> <em>Italics</em>
  • **Bold** -> <strong>Bold</strong>
  • [DuckDuckGo](https://duckduckgo.com) -> <a href="https://duckduckgo.com">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.

But..

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.

Hyper