DEV Community: Josh Pullen

The best programs put users at the wheel.

Josh Pullen — Mon, 08 Jun 2020 01:18:07 +0000

Spreadsheets are everywhere. They are the go-to tool for people who need to do powerful work on computers but don't know how to code.

Spreadsheets are both powerful and approachable. These qualities usually act in opposition, but spreadsheets are able to span both worlds. Beginning as a simple table, a spreadsheet is easily approachable, but there is great power lurking just beneath the surface.

These two qualities make the spreadsheet one of the most productive and widely-used tools in computing. How is this dual approachability and power achieved?

When creating a spreadsheet, the program is the output.

In almost all other forms of software, there is a clear distinction creating and consuming programs. Coding an app and using it are separate activities, performed by different people. Programmers know best, and users are told to accept what they are given.

Spreadsheets take a different approach. To use a computer is to command it, and the most powerful command is code. Spreadsheets openly encourage users to program for themselves—to work with the computer, not against it.

Unlike in most traditional programming languages, spreadsheets make no distinction between the program and its output. The code and the output exist in the same space, and this dramatically lowers the barrier to entry. By intermixing program and output, spreadsheets lower the barrier to entry of coding, and make programming a natural part of using a computer.

In particular, starting with the output allows for a natural induction-based approach to building programs. A traditional programming experience begins with code and ends with output. Spreadsheets flip this process around. Users begin by manually specifying the output they desire. A novice spreadsheet user might enter data and perform calculations manually. Only when the desired output is entirely obvious and its manual generation too strenuous, a user writes the program necessary to automate the computation. By beginning with example outputs and only then writing the program, there is never any confusion about what the code needs to do or how it should work. This reversed process makes the act of programming a computer vastly more approachable.

This kind of programming-oriented interface is rare, but not entirely unique. Minecraft, for instance, allows players to program within their own worlds using redstone. The lights, wires, switches, and other components exist within the world being programmed. The code and the output are, again, unified. As with spreadsheets, this paradigm led Minecraft to massive success. Minecraft is the #1 most-purchased video game of all time, despite being incredibly buggy and artistically primitive. Its willingness to make the user a programmer in their own world is the killer feature that transforms Minecraft from a game to an art form.

One up-and-comer in the field of programmable products is Notion. It is a note-taking tool that allows notes to be sorted, filtered, and creatively displayed based on user-defined properties. The tool isn't as powerful as a spreadsheet, but it's far more customizable than most note-taking apps, and again, the programming and the content both exist in a unified interface. Notion, too, has seen incredible success, with a $2 billion valuation despite continually turning down investors.

Spreadsheets, Minecraft, and Notion are all unparalleled success stories, and they share one feature in common: to use the tool is to program it. These tools lower the barrier to entry to programming by making programming a natural part of computer usage.

Despite existing for a long time, this area of software is woefully underexplored. There is a vast landscape of programmable formats yet to be discovered. These new tools will empower users to do more, and experience great success as a result. We haven't yet seen all that computers can do; that power will only be unlocked with users at the wheel.

This was originally posted on my blog under a different name.

I need a new project.

Josh Pullen — Fri, 05 Jun 2020 04:18:41 +0000

I spent much of my life creating Scratch projects. When I was still using Scratch, there were a few key elements that made it great:

It was an outlet for creative ideas. Creativity is a faucet that can't be turned off. I generally have a constant stream of ideas, and when I don't act on those ideas it's frustrating. Scratch gave me a platform for channeling creative energy into the production of something real.
It taught me a lot. You learn the most when you're working in the zone. The zone is that area outside what you already know, but only by a little bit. With Scratch, I was able to consistently hit the mark.
It was quick. Fast projects are great because I have a short attention span. I really enjoy coming up with project ideas, but execution can become a slog. With Scratch, I could have an idea, execute quickly, and share.
It was easy to share. Sharing projects was great because I often got useful feedback and just enough encouragement to keep me going.

I've slowly stopped creating Scratch projects, mostly because I don't think I have much left to learn. After 500+ projects, Scratch is no longer gives me the feeling that I'm in the zone.

Unfortunately, I don't have a replacement activity.

Web development has served as a kind of stand-in, but it has never been quite the same. Websites tend to be much slower to create, and they're harder to share.

Blogging is okay, but the final product doesn't particularly excite me. When I created a Scratch project, I really enjoyed repeatedly playing my own game. Reading my own blog posts doesn't feel the same.

I keep searching for something else to try, but I'm feeling a little stuck.

This post was originally published on my blog.

The Transformative Power of Free

Josh Pullen — Wed, 25 Mar 2020 18:41:59 +0000

About a week ago, I made my website Rocket Spelling completely free:

// Detect dark theme var iframe = document.getElementById('tweet-1239688897703141376-407'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1239688897703141376&theme=dark" }

The response since then has been amazing. Before making it free, Rocket Spelling had 115 paying customers. In the past week, over 1,500 teachers have joined. Here's the graph of unique users per day for the last 28 days:

The response took me totally off guard. I wasn't expecting this kind of spike, so I've been trying to decipher what went on.

What's up with money?

Money clearly acted as a real roadblock to teachers, but it isn't immediately obvious why. Is Rocket Spelling too expensive to afford? This may sometimes be true, but I suspect that most schools with access to computers can afford to pay. If a teacher wants to use the website, all they need to do is ask the district for funding!

So why is money such a hinderance? I suspect that "all they need to do" is the problematic phrase.

The problem isn't price. It's pain.

Paying money takes effort. To pay for an account, a teacher needs to get other people involved. It's a lot of work, which poses a real barrier to getting started. Every barrier reduces the number of people who will use the service massively.

Before this week, I had read about "sales funnels" and "removing friction from the customer journey" and other business jargon, but it all felt too impersonal to matter. Now I get it. Here's the message:

If you want people to do something, make it easy. Then make it easier. Then easier again. Here's how:

Make it free
Make it fast
Make it obvious

Remove barriers.

The recent spike in traffic has taught me that there are massive gains to be made by simply removing barriers to entry. Breaking down walls, even little ones, makes your service much more valuable to potential users.

This is exciting news! It means that improving conversion is simple. Every time there's a button, instruction, or input, ask yourself:

Is this action 100% necessary?
Can it happen later?

Does the user really have to make a password, or can they sign in using their favorite social platform like Github, Google, or Twitter? Do they really have to sign in at all? (The answer might be no: Wikipedia lowered the barrier to entry by allowing anyone to edit pages, even without an account.)

Do they really have to pay? If yes, do they have to pay now?

Removing barriers is a simple way to massively improve the user experience, and it doesn't take a genius to ask the question "Is this step necessary?"

Cover photo by Ali Yahya on Unsplash

Why is zoomed-in text red and blue?

Josh Pullen — Sat, 14 Dec 2019 03:13:21 +0000

If we want to draw something on a computer screen, we do it by setting the colors of individual pixels:

This is pretty useful, but it isn't great if we want to draw something like this:

We can only set each pixel to one color, so in reality we might choose to set the pixels like this:

That's... not ideal. The boxiness of the pixel grid really cramps our style. Fortunately, there's a fact that helps us improve the situation.

When screen manufacturers create LCD screens, each pixel they make is built using three lights: a red, a green, and a blue. The lights are too small for your eye to distinguish, so the three primary colors blend together. When we set the color of a pixel, these three lights turn on or off accordingly.

We tell the screen to do this

But it secretly does this instead

Since we know the arrangement of the little lights (the "subpixels"), we can fill in just half a pixel by giving it a funky color:

We're telling the computer to render red and blue, but it won't look that way!

When rendered, the red and blue pixels become left-half and right-half pixels respectively. This looks a lot smoother!

Rendering half-pixels allows us to draw much more smoothly. In practice, this effect is most obvious when you zoom in on well-rendered text:

Pretty cool!

Project Idea: The RSS Reader for the End Times

Josh Pullen — Tue, 05 Nov 2019 14:50:20 +0000

Linus Torvalds once said "Talk is cheap. Show me the code." I am cheap, so I'll just talk. If you're a restless developer looking for something to do, you may wish to take this project on yourself. If you do, there are two possible outcomes:

You spend a few afternoons improving your web development skills.
You save the internet.

The RSS Reader for the End Times

RSS is dead, and soon we will be too. With massive corporations eating us all alive, it's easy to see why the internet isn't quite as playful as it used to be.

There are plenty of people working hard to improve the situation, but more need to join the fight. RSS may be dead, but it can be revived.

Our goal with this project is to solve a fundamental problem: Content on large networks wins because it's easy to access, not because it's better. If we can make it easy to access content that lives on personal sites and other niches of the internet, we can level the playing field and allow the best content to get eyeballs without going where the people are.

It's not about RSS

First, let's be clear: RSS itself is on the decline. As far as XML nitty-gritties go, you can't expect every source of content to have an RSS feed available. What I'm saying is that if you want to Syndicate, it won't be Really Simple.

Fortunately, if you're clever, it's a solvable problem. Although the feed format is no longer standardized between most websites, it is usually still internally standard within a single source. If I want to get a feed of content from jakearchibald.com, I can just scrape it myself. Searching the HTML of the home page for elements with the selector .h-2 > a gives me a set of links to the ten most recent posts. If I'm really clever, I could probably even figure out how to get the next ten too.

If you're willing to get dirty and start scraping, you can generate feeds for a lot of content in a lot of places, even if RSS isn't there to do the heavy-lifting.

Selecting elements is hard

Figuring out how to scrape each website differently to find its content is no small task. Fortunately, ad-blockers already have the solution: A browser extension with an "element picker" can help users to generate the selector themselves. Plus, once one person figures it out, you can store that selector in a database somewhere to help out others who want the watch the same feed.

For some services, it may also make sense to allow users to sign in with OAuth. Maybe a user wants a mirror of their YouTube subscriptions in their RSS reader. No problem! Just sign in with Google!

It is about relationships (and 💰)

One of the benefits of a centralized system is that it allows for relationships between people who make online content (like articles, comics, and videos) and those who consume it. These relationships can include internet comments, or, surprisingly, money! Patreon is shockingly successful because users want to pay people they appreciate.

An RSS Reader for the End Times understands this and facilitates it. Each item in the feed can have a public comment section attached, and -- more importantly -- a way to support the creator.

Imagine that you're subscribed to 100 feeds and want to support all the creators. Each month, you want to donate $20 and divvy it up between them. An RSS reader with donation functionality can facilitate this.

Every creator who likes money can sign up to receive payouts when users who are subscribed to their content choose to donate. Then, each donation is split up among the feeds (as dictated by the donating user), and once a creator has a few dollars of total donations in the system they can cash out at their leisure.

If you want your RSS reader to be financially viable without selling users' data or resorting to ads, you could probably even take a little cut yourself. 😉

Why Scratch is the Ideal Development Environment

Josh Pullen — Mon, 01 Jul 2019 19:29:03 +0000

I don't need to tell you that Scratch is not a professional tool. Certainly, there are some very impressive people creating very impressive projects, but they are the exception, not the rule.

Scratch is designed for children. It isn't built to be powerful. It isn't designed to be fast. You can't pass around arrays or objects as data, and you can't create a function that returns a value. As a tool for real development, Scratch is worthless. But Scratch gets one thing right: It makes programming intuitive.

You Know Your Options

In Scratch, every "block" — every feature and method available to you — is visible on-screen in a single scrolling panel:

You don't need documentation because everything you can possibly do is right there in front of you. And if you don't know what something does, you can just try it.

Experimentation is Everything

Want to run some code? Just click it. It's that simple. If you have a block or two, you can click them and they will run. Always.

This means that you don't need documentation, tutorials, or anything except a willingness to try. If you find a block that looks like what you want to do, you can click it — even while your project is running — and see the result immediately.

Military-Grade Hot Reloading

In Scratch, your project is a stage and you are the director. Code is merely a way of communicating with your actors (technically, "sprites"). You can, of course, give your actors a script ahead of time, but there's nothing stopping you from giving additional directions as the scene unfolds.

The Scratch interpreter is baked directly into the editor, which means that when you interact with your code you are manipulating the world directly. You can change a script while it's running, and it will just work. That's magic.

The Result? Insight and Intuition.

When you combine these elements together, what you get is a very intuitive programming experience. It's underpowered, of course, but it's also empowering. By giving you as many tools as possible to see into your project and manipulate it, Scratch makes it easy to get a grasp on how code works. When you want to make something, you just start clicking bricks. You can see how they fit together in a way that feels tangible. Code is no longer a black box.

I Want Scratch Back

I spent a lot of time with Scratch in my early years, but eventually moved on to bigger and better(?) things. There's a lot to love about the broader programming landscape, but I'm honestly not thrilled to have left behind the editing experience that was once so near and dear to my heart.

But why are intuitive programming environments reserved for children? Surely even the big kids could use a little extra assistance. The challenge of programming is understanding what's happening inside our little black boxes. But the more that we can poke holes in the box — the more that we can give insights into how our code looks and feels from the inside — the better software we will be able to create.

What are you making?

Josh Pullen — Tue, 18 Jun 2019 21:05:02 +0000

Code or otherwise, I want to know: What's your latest creation?

(Thanks to Kevin Jarrett for the cover image.)

Why do you love dev.to?

Josh Pullen — Fri, 07 Jun 2019 01:32:25 +0000

Dev is, I believe, the best online community for developers that exists today. So I want to know: What's your favorite part of the dev.to experience?

What about this website is different than Twitter, Medium, or any of the other places that developers live?

As a bonus: What would you like to see improved?

How Portals Will Restructure the Internet

Josh Pullen — Tue, 21 May 2019 13:20:31 +0000

The Chrome team has a new proposal for the web, and the very preliminary implementations are already beginning to ship in Chrome Canary. It's called "portals", and it's a little bit like iframes on steroids:

// Detect dark theme var iframe = document.getElementById('tweet-1125886955542106112-544'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1125886955542106112&theme=dark" }

Portals are crazy because they make it really difficult to follow which website is serving you content. Even with the current URL highlighted in the twitter video, it can be quite hard to understand exactly where everything is coming from.

At first I found this concerning, but over time I've begun to believe that portals correctly identify that organizing web browsing by URL is not useful for users in the general case. (URLs are, of course, excellent for sharing links to pages. But when clicking around, they aren't nearly as important as we make them seem.)

I've been thinking a lot lately about orthogonal methods of grouping ideas, and how the obvious grouping is not always the most useful one. In the frontend world, we collectively realized that grouping by language is less sensible than grouping by components:

I spent too much time on this to only include it in one post.

To me, portals seem like the same type of (controversial) shift. Rather than grouping the content we view by the domain it's served from, we choose to group it by the content it contains. This means that links, the original "strings" of the internet, will no longer be needed to tie separate locations together. Instead, pieces of similar content will naturally be grouped regardless of origin.

I don't foresee this change coming to pass without some sort of major uprising first. We saw it with JSX, and I believe we'll see it again. But I'm also going to make the claim that portals will drastically improve the internet experience by forcing website owners and users alike to care less about where content is hosted and more about how it's connected.

Concerns with Separation of Concerns

Josh Pullen — Tue, 21 May 2019 02:48:39 +0000

The Old Way: Splitting Code by Language

Before components were cool, we often split our code up into separate HTML, CSS, and JS files. This division kept tangles of related code pulled apart into separate chunks with only the necessary strings between them.

Splitting code by language was better than putting everything into one file because it lowered the stress on our scroll wheels and allowed us to sleep at night under the false presumption that our code was properly organized.

But the connecting strings were there, and they haunted us.

All three languages were necessarily intertwined (if you change a class name in HTML, you have to update your CSS and JS too), so we were constantly jumping back and forth between related files.

The New Way: Splitting Code by Component

A far better system, with less jumping involved, is to split code up based on what goes together. Components help us do that! Components are a recognition that splitting up our code into files based on the programming language is the wrong approach.

It was controversial in the beginning. There were outcries. The public made clear that such a convolution of concerns was an infringement on the very foundations of a civil society.

For a while we were convinced that this generous bloke was actually a witch!

But, as it happens, combining HTML, CSS, and JS all together is actually a really great idea. The key condition? You must instead divide up your code based on which pieces of HTML, CSS, and JS work together to form a coherent whole. That's what happens when we split our code into files at the component level.

The key benefit is that we no longer have strings attached between each of our files. (If we change a class name, everything happens in one place.) In an ideal world, every component is entirely self-contained and does not rely on the implementation details of other components to function properly. This means that we no longer need to jump between files nearly as often.

Change is the Only `const`

Changing deep-rooted ideals (about, for instance, separation of concerns) is incredibly difficult. Fortunately, web developers seem to be quite good at it. The industry moves fast, and it can sometimes seem like we're reinventing the practice too often. But looking back at old ideas is a reminder that the adaptations are worth the pain. Keep up the good fight, y'all! ✌

Blind in a Blindfold

Josh Pullen — Fri, 10 May 2019 23:10:40 +0000

A few years ago I discovered something strange: "Mental image" is a far more literal phrase than I had ever believed. It turns out that the majority of people really can "see" things that aren't in front of them. I cannot. It's a condition known as Aphantasia, and — although little is known about it — there are many people who have recently come to the same discovery.

Fortunately, people with Aphantasia seem to be faring pretty well. Ed Catmull, for example, was president of Pixar despite having Aphantasia. In fact, I would argue that limitations like Aphantasia can be beneficial in certain fields.

Imagine this...

Imagine, if you can, blindness of the eyeballs, not just the mind. A blind person must, necessarily, become a talented sightless navigator. Years of practice accumulate until a blind person can navigate nearly as well as a sighted one. They'll never be quite as quick at getting around, of course, but they can come pretty close.

But if you took a blind person and a sighted person and put them both in blindfolds, the tables would turn. The blind person — with years of practice — would be able to navigate quite well. But the usually-sighted person would struggle with even the most basic skills.

What Does it Mean for Me?

Aphantasia, I believe, is similar to the blindfold analogy. In the general case, I (and other aphants) will underperform in mental tasks. My reading comprehension of fiction, for example, is atrocious. But in certain cases everyone's mind is blinded, and my intense practice helps me in those areas.

I believe programming is one such occasion. Programming, as far as I can discern, is not a skill which is particularly aided by visual imagery. Almost everyone who is writing code needs to think in data, which can be a challenge for many. As a person with Aphantasia, I — like the blind in a blindfold — feel no less comfortable writing code than I do thinking about anything else.

The general principle, it seems, is that challenges and limitations can result in surprising benefits. I, for one, will be capitalizing on the good parts.

Be Mindful What you Measure

Josh Pullen — Tue, 30 Apr 2019 23:48:56 +0000

When you measure something, you change it.

Observer Effect:
"In physics, the observer effect is the theory that the mere observation of a situation or phenomenon inevitably changes that phenomenon."

Quantum physics are pretty weird, but it turns out that humans are weird in much the same way. Who knew?

In my life, standardized tests are a big deal. AP tests are coming up, and the ACT is still on the horizon. SAT results come out Thursday. I work tirelessly to resist the idea that my education is about beating a test, but it's not easy to avoid.

In the pursuit of more data, we've created tests that attempt to evaluate students' abilities. These tests aren't perfect, of course — you can't effectively measure skills like interpersonal communication on a multiple choice exam — but it seems reasonable to expect that more data will result in better decision-making. Unfortunately, when we measure what students have learned, we change what they learn.

It's no secret that schools, if they want to do a "good" job (according to the measurement tools at our disposal), must teach the skills that are testable and overlook the ones that aren't. But the compatibility of a skill with a multiple-choice exam is not at all correlated with its usefulness in the real world. (Or, if you're feeling really spicy, you might even argue that a correlation exists and is downward-sloping.) As a result, our choice to collect more data has caused the quality of education to decline.

We must be careful what we measure.

If measurement can affect an outcome then we need to be thoughtful about what we measure and how we might change things as a result. We all know that measuring a programmer's success in "lines of code" is a futile exercise.

// Detect dark theme var iframe = document.getElementById('tweet-837749167049031681-238'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=837749167049031681&theme=dark" }

On my best days, I write negative code. But if you want me to make that number big, it's an easy game to play:

if (
  true
)
{
  console.log('6 lines already! 🎉 Am I a rockstar developer?')
}

We encourage what we measure, so we have to be sure that we're measuring the right thing.

Fortunately, this measurement effect can be weaponized for good too. That's why Discourse displays the amount of time a user has spent reading, not how much they have written:

"Printing a post count number next to every user's name implies that the more you post, the better things are. [...] Is this even true?

I find that the value of conversations has little to do with how much people are talking. I find that too much talking has a negative effect on conversations."

- Jeff Atwood (Coding Horror)

Instead, by measuring time spent reading, the system encourages people to read more. It's not complicated, but — as is often the case with simple things — it's startlingly effective.

How can we apply this idea ourselves?

When we are developing our own products, we can — we must — think about the effects that our measurements will have, and choose to emphasize the measurements that we believe matter. If you're making a social media app, think about the numbers you display next to users' posts. Do they promote the kind of interactions you're looking for?

// Detect dark theme var iframe = document.getElementById('tweet-1118970853654290432-986'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1118970853654290432&theme=dark" }

There are no set rules. The answers to questions like these will change depending on your circumstances and goals. But there's no doubt in my mind that simply measuring and displaying data is a great way to manipulate it.

Perhaps we can measure how we measure. That might do the trick.