Soft Skills

A bitter guide to open source

Ken Wheeler writes open source JavaScript libraries (Slick Carousel and Webpack Dashboard are two notable projects). He recounts his experiences with open source so far—the good, the bad and the ugly—tells us why we should be part of the open source community and how we should maintain our open source projects.
Whats the worst that could happen? People are gonna talk shit? I got news for you kiddo, you could put out the most perfect, useful, fuckin mind blowing code that ever touched GitHub and guess what? Some asshole is gonna come in and whine about something. Its an inevitability. Worst case scenario, you learn something. Someone will be like, “Hey this makes performance suck” and you can either be like, “Ugh I’m bad at programming, I quit” or you can be like “Oh wow, thanks for the tip, just fixed it, now its better”. Be the person who makes it better.

How to take criticism

As developers and designers, we face criticism on a daily basis. Criticism can come from anywhere: clients, colleagues, other peers, social media; that's why it's important for us to be able to take (and give!) criticism in a constructive manner.
I firmly believe you can be a critic while being kind and open-hearted. I don’t even care if that sounds naive. Most people think the number one goal of a critic is to judge whether work is good or bad. They are wrong. #imo The number one goal of a critic should be to make things better. That’s it. None of this binary good/bad stuff.

Writing is thinking

Steven Sinofsky started a Twitter thread about a company's writing culture. In this article, he annotates that thread with further articulation.
The biggest thing about writing down strategic choices is that they serve to build a corporate history (over a year or two, not really thinking about decades). Why decisions are made is rather important because companies, like people, can make the same mistakes over time without history.
This paragraph resonated hard with me, not related to company strategies, but to code. I've been working on a few larger projects the past year, the kinds that require decisions which aren't clear "rights or wrongs", but benefits and tradeoffs. 

It's important to be able to look back at those decisions. They can be critical for the future of the project; "Why did we create this abstraction? Can't we just refactor it to something simpler?" A written account could answer that question that in a heartbeat. Or maybe you need to make a similar decision in a different project: your documentation would allow you to hop back in to the decision-making process instead of starting from scratch.