The scientists who designed nuclear bombs weren’t assholes. J. Robert Oppenheimer, the head of the nuclear bomb project, was a scientist’s scientist with left-leaning liberal political views.

From what I’ve read, it sounds like working on the atomic bomb was a dope time. You had a cool boss, unlimited money, job prestige, passionate coworkers and really interesting problems to solve at the intersection of physics, chemistry, metallurgy and bomb theory. You probably also got free lunch.

And then your work ships, and you realize you’ve fucked the world.

Will the internet of the next decade be an empowering force for human progress (like nuclear power) or for crimes against society (like nuclear bombs)?

Slapping Ethics in the Face 🙋🏻

<Insert something inspiring and uplifting here>, like: as designers and engineers, we have a moral imperative to build software that doesn’t mislead, divide and abuse people and society.

Duh. Of course we do. Nobody wakes up wanting to make shitty things for garbage people.

Whether it’s fascist regimes, the NSA, Facebook, or the Kardashians, bringing out the worst in humanity will always be easy money. There’ll always be developers that corporations and governments can throw money, prestige or interesting problems at and make what they want.

These developers aren’t assholes either. Some will be new to the profession, some will want the perceived safety or legitimacy of a large corporation, some will just really need the money. I’ve been that developer, I’ve made banner ads. I’ve seen some shit.

An Alternative to Outrage 🌚

You’ve got more power than you think to build what you want to exist.

Most programming is just turning text into another kind of text. With the helpful tools and services we’ve got today, writing code is less gross than it’s ever been (maybe, possibly, even fun).

There’s still so much good software to make:

• We’re still bad at connecting diverse people, with diverse perspectives, in meaningful and respectful ways.
• We’re still bad at building quality software for professionals. Ever used Blackboard? Quickbooks? Anything made by Oracle? Pretty much every human with a job is forced to use crap software to do their jobs.

Cash Rules Everything Around Me 💰

But how do we fund the good stuff? That’s also something we’re bad at.

Ideally if you’re solving a real problem for real people they’d pay you. But that’s really hard for some industries, like education, where your users (e.g. teachers) are cash strapped, and the organizations they work for only buy through RFPs and sales teams.

What’s a little guy to do?

On Patreon, I give 1041uuu a dollar a month, they make cool art. It’s pretty simple.

What would a Patreon for small software makers look like I wonder?

Comments…

In the course of my life, sometimes someone will bring up something semen related and I’m excited. Not because semen, but because there’s a chance we’ll get to talk about biology.

The neuroscience of poverty studies the relationship between brain pattern development in children and well, poverty. According to Newsweek, recent studies in the field have found that impoverished children tend to have less grey matter (associated with design thinking, problem solving, impulse control and emotional control) and lower brain surface areas than children from families bringing home $150,000 or more a year.

The nurture part is pretty straightforward; it’s no surprise that having a head start in life gives you a head start in life. The nature part, tying social success to inherent biological capability, is where things start to get umm.. shady.

The history of eugenics is the history of simple people thinking that simple correlations could explain the world. So it goes: if poor people tend to be mentally inferior than we’ll have a smarter society if we eliminate the poor. Oh what’s that? The poor are disproportionally colored too? Yeah I guess we should get rid of them too then. Context and reality? Too messy. TLDR.

Does brain size even matter? Why didn’t whales – with their much larger brains – create the iPhone? Neurologically speaking, we don’t know shit about how the brain actually works and adapts. We’re still just poking stuff and seeing what happens. The console.log approach.

To lighten the mood a bit, lets say you design something that, I don’t know, makes it easy for people to write cool web apps. It’ll only be a matter of time before,

Hey listen. Google Analytics told me that people who use [Esoteric Feature X] are 200% more likely to upgrade their account. So if we make sure everyone knows about it we’ll get twice as much money!

Um, we made [Esoteric Feature X] for people who aren’t our core user group and have a special workflow. It isn’t really relevant to most users.

Yeah, but no. Money son!

*Makes Feature X shout at users to use it*. Most people ignore it and nothing changes, except now the interface is worse because relevant features are harder to find.

This doesn’t mean we can’t ever know things. Actually, you can know the most important thing: what are people trying to get done with your product?

👷 “I’m a carpenter, I use this saw to cut wood to the right size”

🙋 “I’m a developer, I use HyperDev to get my ideas on the internet”

🐴 “I’m a horse, I wear this saddle so people can ride on me without their balls hurting”

Your cool product may do lots of things and have lots of features, but there’s always a core job-to-be-done that people are there for.

Correlations and metrics can be handy (“Does anyone actually use Feature X?”). Design isn’t neuroscience though, we don’t have to poke and hope. We can mindfully help people do the job they want to do quickly, conveniently, and make them feel good about it. They’ll feel good about you too.

Comments…

---

🎹 Updated to replace HyperDev with Glitch

---

So last week (in 2016) we launched Glitch (then known as HyperDev/Gomix), a cool way to write a real web-app. It’s been almost a year since DanielX and I first presented the idea to FogCreek.

Let’s look back 👀✨

If you turn off the lights, squeeze a lemon in your eye, and squint real hard, you might see some similarities to Glitch today. The asset management stuff wasn’t too far off though.

Real rough, but good enough to help us convey our vision for web development without the boring parts.

The next thing we were told to do is come up with some high-level product principles. These also started rough, but we’ve sharpened them up over time – and as the team has grown:

1. Be the fastest, easiest way to get your own web app and start working on it.
2. Glitch is real coding. Copy and pasting an answer from Stack should just work like it would on your local machine. If you want, you can take your code and run it on Heroku or wherever.
3. You should get instant, direct feedback when you edit your app.
4. You should always feel safe that you won’t lose your work and that you can try crazy ideas without irreversibly breaking your project.
5. The editor should be a fun place to be because it’s fast, approachable and puts the emphasis on your content and your team.

(Secret principle #6 is steal from Trello whenever possible)

While we haven’t nailed all of these yet, we’re steadily working towards them.

Having these tentpoles made it easier for us prioritize and push for doing the right things – and to figure out what to cut:

New Project Setup 👎:

Early on, starting a new project meant making a couple of tough feeling choices. And instead of actually making something, you’d be off researching the joys of Ruby, debating it’s performance and wondering whether you should use Ember, Angular or whatever’s hot on the streets this month.

This was also an example of us being too opinionated and trying to be too prescriptive about the ‘best way’ to code.

This clearly violated our first product principle of getting you started fast. So throwing this out and relying on our users to make interesting, remix-able projects felt like a better call.

Sidenote: I thought using emojis as an interface element would be at least slightly controversial in 2015. 🌈.

Inserting Snippets For Common Tasks 👎:

To make it easier to do common coding tasks, I wrote a feature that would let you search and insert pre-made code snippets into your document to do things like init a Slack bot in a js file or scaffold an animation with keyframes in some css.

This made sense in theory, and was easy to sell people on as a magical feature, but it turned out to be too magical to actually be good:

In user tests, no one seemed to know what they expected the feature to do. In FogCreek hackathons, nobody really used it even after they were told what it did.

There were also a lot of hard, scary questions around this feature like:

• Where would the snippets come from? Who would write and maintain them?
• How would we do non-trivial snippets that required changes across multiple files? (Silently editing files the user couldn’t see sounded sketchy.)
• Should we add packages to projects if a snippet required it?
• Would we be endlessly porting and updating snippets people relied on?

So eventually we cut the scope of this and simplified it into the ‘Add Packages’ button that appears when you’re in package.json. This feels way more predictable, and will be way easier to maintain and adapt to other languages and package management systems.

On-the-fly Language Selection 👎:

Another feature that lived for months in the beta was the ability to change the language of your document and have it auto-magically just work. So if I was in a js file and I wanted to step up my game, I could select coffee and be cool AF.

Language selection made it easy to experiment with languages and was a nice, contextual way to show users our currently supported languages. People seemed to like it. When it worked.

In order to do this you had to be using our hyperweb-init library in your project. hw-init did a bunch of things, like setting up express, language compilation and watching. In theory, I thought this might make getting started easier because new users wouldn’t have to trace through boilerplate init code in server.js

If you’ve ever started an XCode project with Core Data support, you know how shitty boilerplate code can be.

But actually what happened in testing is that people actually felt less comfortable when they couldn’t see their express init code. Again we crossed over into too magical territory.

Additionally, going from something like js to coffee was easy, but what about from coffee to python? How would hyperweb-init work in other languages that might not have existing libs for server-side compilation of coffee or less? If I changed server.js to swift, what impacts does/should that have on package management?

*phew* When your edge-cases have so many branching paths that they start to resemble an AI problem, it’s time to step back and try something else.

Over the next couple months we slowly trimmed the fat off the welcome-project, and removed any first-party dependencies to better walk the line between simple and transparent.

Wrapping Up For Now

So we talked about some things, had some laughs. But I’ve still got so many more Glitch rabbit holes to dive into for later posts.

In the meantime, If you’re curious, all of my design files are up on github. glitch.sketch is the window into my soul: it’s a little bit of a trash fire in there, but it’s pretty entertaining. I wear my inspirations on my sleeve in these files.

Glitch-design on github

Comments…

I’m glad HyperDev is finally out there, and I’m proud that people seem to really like it. But I also can’t not see all the other things we need to do with it.

I’m with this turtle life

🐢

Comments…