Published
Weekend Reading — Square knot
Design Objective
Building Products This is fantastic, go and read it right now. I can’t tell which is the best quote, so I’ll pick one at random:
When exploring solutions for a particular problem, go broad before going deep. Brainstorm 10, 20, 50 solutions for the problem before getting into the mindset of picking a “winner”. The first 5 ideas will be the obvious ones. Creativity happens when you start to explore the 11th, 20th, or 50th idea.
How We Lost 47% of Our Users After a Redesign Removing elements from the UI doesn’t necessarily make it simpler. Sometimes the opposite is true, the user struggles to make sense of the UI:
By trying to make the service simple and minimalistic we complicated user’s experiences. Getting rid of a few tiny details dissolved the whole sense of a queue and availability was lost, leading to a bunch of unanswered questions and reduced usage.
Get Dumb and Grow Rich, Leading Your Company Article How one person uses ignorance to design better products. It’s a profile piece, so rather long read, but worth it.
39 studies about human perception in 30 minutes
For the last several years, I’ve wondered about what we actually know from scientific studies about how humans perceive graphics. … This is an extreme distillation of these studies.
Inline validation in forms — designing the experience “For the default behavior I propose a hybrid — reward early, punish late — approach”
Hey, You Have Given Me Too Many Knobs! Understanding and dealing with over-designed configuration in system software, or as they call it, “over-delivered (or under-exploited) flexibility represented by configuration parameters”. (PDF)
Tools of the Trade
Falsehoods Programmers Believe Handy collection of “Falsehoods Programmers Believe About X.”
I’ve talked to maintainers from several different open source projects … and they all agree one of the hardest parts of being a maintainer is saying “No” to patches you don’t want. To make this rather unpleasant experience of closing someone’s patch request easier I have a few ways of going about it.
Typosquatting programming language package managers If you place blind trust in package managers, I’ve got some bad news for you:
In the thesis, the well known programming languages Python, NodeJS and Ruby were attacked. All their package managers were found to be vulnerable to typosquatting attacks.
omgees!!! Unix has a built in JavaScript module bundler:
$ cat file1.js file2.js file3.js > app.js
Why do people find DNS so difficult? It’s just cache invalidation and naming things.
Lingua Scripta
Functional Programming in JavaScript (disclosure: I did receive a free copy of the book to review)
Functional Programming in JavaScript teaches JavaScript developers functional techniques that will improve extensibility, modularity, reusability, testability, and performance. Through concrete examples and jargon-free explanations, this book teaches you how to apply functional programming to real-life development tasks
Making your JavaScript Pure A short introduction to writing pure functions in JavaScript.
rtsao/babel-preset-es2015-node This preset automatically determines which version of node you are using via process.version and sets the minimum necessary babel-preset-es2015 plugins accordingly.
The Shocking Secret About Static Types Mirrors my experience:
Bottom line: You want to reduce bugs? Use TDD. You want useful code intelligence tools? Use static types.
ErikWittern/TODOit The JavaScript framework for hassle-free TODO application development.
Lines of Code
Mastering Programming Want to be a better software developer? Hang this on your office wall and practice it daily:
The theme here is scaling your brain. The journeyman learns to solve bigger problems by solving more problems at once. The master learns to solve even bigger problems than that by solving fewer problems at once. Part of the wisdom is subdividing so that integrating the separate solutions will be a smaller problem than just solving them together.
So often:
- The team is going slow because the code is to hard to work with
- The code is hard to work with because the team went too fast
((Jason Scott))) "This is most bug reports"
Peopleware
The Virtues of Laziness and Impatience Don’t confuse “working long hours” with “working hard”; when we stretch the work week, we fill it up with low quality work:
Laziness and impatience. We focus so we can go home, and we encourage going home because it forces us to constantly focus. This is how great teams scale.
Product Management in Two Steps
It turns out there are, in fact, very good reasons to follow rules that you are pretty sure won’t work. Pain points often need to be felt to be fully understood. The rules that are likely to be omitted from a “bespoke” process are often the ones that an organization needs the most, precisely because they will be the most painful to implement.
Techtopia
Joel Latto "This is some @internetofshit stuff right here."
Locked Doors
Hacking the Mitsubishi Outlander PHEV hybrid Apparently you can run an internet search to find cars around you, access their WiFi network, and send them an alarmoff() command. Carhacking is the new carjacking.
Hacker News Onion: Announcing Let’s Decrypt, A SSL Certificate Authority Backed By The NSA
None of the Above
Self-Proclaimed 'Thought Leader’ Gives Talk on 'Thought Leadership'
How “Silicon Valley” Nails Silicon Valley
“Real startups go through all the shit you see on the show, as well as even crazier shit,” Roger McNamee, a venerable venture capitalist and a consultant to the show, told me. “If anything, the writers might have to leave out true things in order to seem more realistic.”
Why the World Is Drawing Battle Lines Against American Tech Giants
Nobody knows yet who will win these fights. The American tech giants are huge, but they need the blessing of national governments, and those blessings aren’t coming easily.
