Justin Elliot:

Twice a day, seven days a week, a tractor trailer carrying 8,000 gallons of watery, cloudy slop rolls past the bucolic countryside, finally arriving at Neil Rejman’s dairy farm in upstate New York. The trucks are coming from the Chobani plant two hours east of Rejman’s Sunnyside Farms, and they’re hauling a distinctive byproduct of the Greek yogurt making process—acid whey.

This isn’t just the most beautiful farming related websites I’ve ever seen, but also one of the most beautiful websites I’ve seen period.

Powerful and moving words by Chris Granger of LightTable:

I’ve never met a stronger person. She has lasted through doses of poison that would’ve easily killed any one of us “healthy” people, and she has done so with a degree of poise that is truly unfathomable. In our little startup world, the words tenacity and perseverance are thrown around a lot, but in that context they seem hollow and largely meaningless. Tenacity is far more than simply making it through tough times, and it’s not just a matter of finding a way “back to good.” Kristie has shown me that tenacity comes from living for a purpose, from believing in something so fully that it keeps you alive through six rounds of injecting drain cleaner into your veins. By that definition, I haven’t seen much tenacity in the Silicon bubble many of us call home. […]

I’m doing this because I believe that this is the greatest contribution I can make.

I could’ve become a doctor. All signs pointed to me likely being a very good one. In doing so, I would have gone to work and done my best to save lives every day. In that context, how is some programming environment a greater contribution to the world? Truthfully, it wouldn’t be if I just set out to build an IDE. But that’s not what I did - Light Table is just a vehicle for the real goal. While an IDE probably won’t directly save someone’s life, the things people are able to build with it could do exactly that. My goal is to empower others, to give people the tools they need to shape our lives. Instead of becoming a doctor, I have an opportunity to improve an industry that is unquestionably a part of the future of all fields. Software is eating the world and analytical work is at the core of advances in medicine, hard science, hardware… Human innovation throughout history has been driven by new tools that enable us to see and interact with our mediums in a different way. I’m not building an IDE, I’m trying to provide a better foundation for improving the world.

It’s something I think about a lot too, although thankfully not under such tragic circumstances. But it’s important for every software developer to consider what impact they’re having on the world. It’s important to consider if what I’m doing is making the best contribution to the world, or am I just following trends and making a buck.

I’ll probably never write software for medical patients, and I’ll probably never write software which lands a rocket full of people on Mars. But if I can write software that helps someone who will do those things, then I will have done my job. If I can enable a scientist or a researcher or even enable a child to express creativity or ideas more clearly, then I will have made my contribution.

The question we should all ask ourselves is: Am I doing that?

Glen Chiacchieri:

In a blog post, the meteorologist Dr. Jeff Masters talks about the largest US wildfires of 2012. Masters mentions that the largest fire burned about 300,000 acres before it was contained. I have no idea how much 300,000 acres is or what types of things are similar sizes and I suspect few other people do, either. But we need to understand this number to answer the obvious question: how much of the United States was on fire? This is why I made Dictionary of Numbers.

I noticed that my friends who were good at math generally rely on “landmark quantities”, quantities they know by heart because they relate to them in human terms. They know, for example, that there are about 315 million people in the United States and that the most damaging Atlantic hurricanes cost anywhere from $20 billion to $100 billion. When they explain things to me, they use these numbers to give me a better sense of context about the subject, turning abstract numbers into something more concrete.

When I realized they were doing this, I thought this process could be automated, that perhaps through contextual descriptions people could become more familiar with quantities and begin evaluating and reasoning about them. There are many ways of approaching this problem, but given that most of the words we read are probably inside web browsers. I decided to build a Chrome extension that inserts human explanations of numbers into web pages.

From a Michael McDonough talk. Some of my favourites:

5. Start with what you know; then remove the unknowns.

In design this means “draw what you know.” Start by putting down what you already know and already understand. If you are designing a chair, for example, you know that humans are of predictable height. The seat height, the angle of repose, and the loading requirements can at least be approximated. So draw them. Most students panic when faced with something they do not know and cannot control. Forget about it. Begin at the beginning. Then work on each unknown, solving and removing them one at a time. It is the most important rule of design. In Zen it is expressed as “Be where you are.” It works.

Getting something “onto the paper” is an under-appreciated tool.

9. It all comes down to output.

No matter how cool your computer rendering is, no matter how brilliant your essay is, no matter how fabulous your whatever is, if you can’t output it, distribute it, and make it known, it basically doesn’t exist. Orient yourself to output. Schedule output. Output, output, output. Show Me The Output.

I’ve got two thoughts on this:

1. Dissemination trumps innovation nearly every time. You might have invented the greatest thing ever, but if someone else can get out their lesser invention to more people, it’s going to beat you out. I don’t think this is really what the above quote is referring to, but it reminded me of this.

2. Get in the habit of regular “releases”, whether this is actually releasing your product, or just checkpoints, or even just having a weekly or daily structure. Aim for completion on this schedule and get in the habit of getting something “out”.

(via Ryan McCuaig)

Bret Victor:

Last week, I released a talk called Drawing Dynamic Visualizations, which shows a tool for creating data-driven graphics through direct-manipulation drawing.

I expect to write a full research report at some point (at which I’ll make the research prototype available as well). In the meantime, here is a quick and informal note about some aspects of the tool which were not addressed in the talk.

Lydia Krupp-Hunter on Sheryl Sandberg’s “Lean In”:

This book is incredibly empowering, but also terrifying in that Sheryl confirms the vast majority of my fears in my career. It’s frightening because to have my fears enumerated and validated by such a successful woman, along with an equal amount of incredible advice for combating these concerns and succeeding in our chosen careers leaves little reason to not confront them head-on. She confirms the ramifications of female success that are easy to imagine for any woman who was bullied for good grades in school or who has ever watched a comedy movie about a working woman trying to ‘have it all’. She confirms that success for women will make us less likeable, and that we underestimate ourselves, and that we pass on opportunities that men with the same skills would seize. Read this book and Sheryl Sandberg will effectively deny you of the option to let your fears control any of future decision making.

This sounds like mandatory reading for people of any gender in our industry.

Joe Cieplinski on his and Charles Perry’s new podcast:

A little while back my friend Charles Perry and I decided to try our hand at putting together a podcast. While we’re fully aware there are lots of great tech podcasts out there vying for your precious listening time, we thought together we could offer our own spin on things and add a bit more to the conversations going on in the independent iOS and Mac development communities.

I’m a big believer in giving back to the community in any way I can. While my occasional rants on this blog are one of my favorite ways to do that, I also thought maybe it was time to start using my physical voice as well as my internal one. Plus, having a discussion with another developer who might actually disagree with me on occasion could certainly be interesting and beneficial to shaping my views. Charles is a really smart, opinionated guy, so hashing out these topics with him made perfect sense to me.

In the first episode they discuss tech conferences, and I was nodding my head in agreement the whole time.

Smile. Everyone gets a free terabyte.

Jonathan Edwards, creator of the Coherence Programming Language on why he thinks programming is difficult:

There is one gigantic problem with programming today, a problem so large that it dwarfs all others. Yet it is a problem that almost no one is willing to admit, much less talk about.

[…]

Too goddamn much crap to learn! A competent programmer must master an absurd quantity of knowledge. If you print it all out it must be hundreds of thousands of pages of documentation. It is inhuman: only freaks like myself can absorb such mind boggling quantities of information and still function. I wager that compared to other engineering disciplines, programmers must master at least ten times as much knowledge to attain competence.

I agree. There are so many things you have to learn in order to get anything “on the page” for any kind of programming. The thought of teaching any of my non-programmer friends or relatives how to write even a simple iPhone app gives me a shudder. There are so many necessary parts to deal with before any real work can be done.

Thankfully, there are some other languages which involve significantly less up-front cost to get something onto the page, but in order for a newcomer to understand what they can put on the page, they’re still limited by needing to look it all up.

Jonathan suggests how to fix this:

By far the most effective thing we can do to improve programming is: Shrink the stack!

I am talking about the whole stack of knowledge we must master from the day we start programming. The best and perhaps only way to make programming easier is to dramatically lower the learning curve.

[…]

To shrink the stack we will have to throw shit away.

I agree we need to lower the learning curve by requiring less of newcomers to get started, but I don’t think this comes by eliminating things necessarily. I don’t think he’s suggesting we remove features in the sense of what a language can ultimately express, but instead cruft like vestigial APIs. It’s cool to abstract them away but I still think that’s missing the mark a little bit.

That would be like trying to get more people interested in writing fiction by either removing words from the vocabulary or by creating new metaphors/symbols for complex ideas. Creating new metaphors for complex ideas is a great skill and tool for writing, but it’s not necessarily one that makes writing itself easier.

I think one of the keys to creating a society where everyone can program is to change the nature of what it means to write a program. I think we need to have it possible for people to express their intent in a more natural way. When humans don’t know what a word means, they infer it from the surrounding language. When humans don’t have a word for a certain meaning, they create one to fill that gap. Why can’t programming be so natural?

Any one of these could be me.

Joe Cieplinski, writing about App Store trials in response to Marco Arment:

I just want my phone and my iPad to do a lot more than “apps-as-entertainment” allow them to do, too.

We’re not seeing a more sophisticated level of software on iOS not because the iPad is a weak computer. Not because touch interfaces are toys. But because the economics of the App Store make sustaining such an app near impossible. It’s simply not worth the investment.

Exactly. If you charged 50 bucks for an app that actually did something, you’d probably lose a lot of sales vs selling for 99 cents. But I think software developers shouldn’t let that scare them away from making sophisticated apps. Short comic strips probably get a much larger distribution than novels, but that doesn’t mean novels shouldn’t still be written.

It’s basically all you hear about in the Apple nerd press: “Apple’s working on a new device that’s going to revolutionize something or other”. It might be a watch, it might be a television, we don’t know what it is but all we know is somehow the device — the hardware — is going to make our lives better. I think that’s a myopic outlook that really offers nothing novel other than a new piece of metal and plastic to hold or gawk at. I don’t think we need new hardware.

Joe Cieplinski also ponders the merits of the rumoured “iWatch”:

What Apple does is identify a category of product in which there’s a lot of potential, where there will clearly be an audience, but where there’s currently no product that doesn’t completely suck. Then it makes a product that doesn’t suck in that category and mops up. It’s a beautiful strategy. And it happens to work.

So where are the crappy wrist computers? There’s the Pebble, I guess. A scrappy Kickstarter project that got some of us nerds excited last year. It’s severely limited in features and not altogether fashionable. So there’s potential for ass-kicking, no doubt. But is that all there is out there today? Where’s Microsoft’s wrist computer? Google’s? Sony’s? Samsung’s?

[…]

My point is, if this were the Next Big Thing, wouldn’t others be trying to do it already? Where’s the clear existing audience Apple wants to tap?

I agree with Joe: an “iWatch” certainly doesn’t match the pattern Apple usually follows, and I would say for a good reason: most customers aren’t asking for it and a newer, micro-device which (probably) runs iOS offers almost nothing above the current hardware we already have.

I don’t think Apple needs any new hardware at all in order to bring the world innovative new products; instead they need to provide us with new ways of working with software.

Chuck Skoda is also sick of only hearing about hardware:

If you have an ear turned to the Apple news beat, it seems as though new hardware product launches are all anyone cares about. While actually, software is responsible for an overwhelming majority of our experience using Apple platforms. This fact has been deemphasized by the Apple community over the last few years as we rush to see the next new device for our pockets, and it’s about time software gets its share of the attention.

[…]

Software is the real frontier on our new mobile platforms. Apple’s new hardware breakthroughs come on the order of decades, not years. Yes, I’m judging iPhone and iPad as a single line of innovation, because that’s how it really shakes out. Do the platforms serve different needs, yes, but they come from the same core ideas and design compromises. If you’re waiting for a watch to come change your life, you might as well buy Google Glass (is that supposed to be plural, I can never tell) and get it out of your system.

Whether or not Apple continues to release new hardware platforms is still an unknown, but my disdainful guess is they probably will keep releasing gizmos and ignore the bigger picture of the software that runs on them. It’s what people seem to care about, and it’s what sells in the press.

And why do we care so much about the hardware anyway? I think it’s because, nerds though we may be, it’s still much easier for us (and especially for non-nerds too) to understand something physical than it is to understand something abstract like software. Physical things are tangible but they ultimately depend on the abstract. Of all the physical inventions through the history of humans that we know of, all of them have arisen from a mental, abstract thought. And the best ones, written language, the printing press, the World Wide Web, and even in some regards the handaxe, all of these best inventions allowed for expanded thought and new physical inventions. But none were purely physical.

And a technological society based solely around physical devices is one that lacks imagination to truly take advantage of all those lovely hardware platforms anyway. It would be like a literary society obsessed with printing presses and cover stock. And yet that’s exactly what we expect of Apple and Google and Facebook and all the other tech companies.

I’m not saying there is no room for hardware improvements either evolutionary or revolutionary. I think it’s great for Apple to continue iterating on the Mac, iPhone and iPad and continue to bring us better battery life, performance, and graphics. And I think there are still many more revolutionary improvements which can be made to products of their ilk: things like print-resolution displays (Retina displays are a great step, but they still pall in comparison to the information density we expect from a printed book or newspaper); light, thin, and flexible computers that can be carried around and manipulated as easily as paper; and tactile interfaces so that we can make better use of our extremely dexterous and sensitive hands and fingers when exploring software.

But all of these hardware advancements should come to facilitate the software, not to sell more hardware or to fulfill some science fiction pipe dream. It’s not time to stop thinking inside the box or outside the box. It’s time to stop thinking about boxes altogether.

Bret Victor published a long essay entitled “Learnable Programming” in September 2012 in which he described principles for creating both better programming languages and better programming environments for beginners and experts alike. But unfortunately, not everyone agrees with his stance.

Many expert programmers still exhibit forms of machoism when it comes to programming, which I find does more harm than good. Instead of acting like a voice of skepticism, it comes off as a voice of elitism with a disregard for the difficulty of beginners to develop computer program writing skills, the difficulty of programming as an expert, and the importance of a computer-literate population.

Mark Chu-Carroll objects to Bret’s stance, and the idea of programmer’s making it hard for beginners to program on purpose:

For some reason, so many people have this bizzare idea that programming is this really easy thing that programmers just make difficult out of spite or elitism or clueless or something, I’m not sure what. And as long as I’ve been in the field, there’s been a constant drumbeat from people to say that it’s all easy, that programmers just want to make it difficult by forcing you to think like a machine. That what we really need to do is just humanize programming, and it will all be easy and everyone will do it and the world will turn into a perfect computing utopia.

I don’t think Bret is arguing that at all. He’s not saying programmers have intentionally made it difficult for outsiders to join our circles, but that, well, it just is hard for outsiders to join. That instead of explicitly not doing our best, we have been doing our best but that our best isn’t good enough, and the sooner we can admit that and start improving, the better. This is not a bad thing. Improvement is what programmers do all day long, so why not also improve programming itself?

Mark continues:

To be a programmer, you don’t need to think like a machine. But you need to understand how machines work. To program successfully, you do need to understand how machines work - because what you’re really doing is building a machine!

Again, I don’t think Bret is advocating not understanding how a machine works. In fact, I think he’s advocating quite the opposite — by creating a better programming environment and language, it can better enable a new generation of programmers to visualize and understand their programs than ever before. I’ll return to this point in a moment.

John Palvus, writing for the MIT Technology Review backs this up:

Victor thinks that programming itself is broken. It’s often said that in order to code well, you have to be able to “think like a computer.” To Victor, this is absurdly backwards—and it’s the real reason why programming is seen as fundamentally “hard.” Computers are human tools: why can’t we control them on our terms, using techniques that come naturally to all of us?

The main problem with programming boils down to the fact that “the programmer has to imagine the execution of the program and never sees the data,” Victor told me.

Or as Bret wrote in his essay:

Maybe we don’t need a silver bullet. We just need to take off our blindfolds to see where we’re firing.

Neil Brown retorts to this statement that while showing visualizations to newcomers is useful, it’s a nuisance to experts:

One of the first things beginners do in any area is learn the terms, after which I believe the labelling of program constructs becomes annoying rather than helpful. We wouldn’t have a mouse-over helper in Maths saying ” ‘+’ is the symbol meaning add two numbers” or in French saying “Je means I” — you learn it early on, quite easily, and then you’re fine. The point of the notation is to express concisely and unambigiously what the program does. I can understand that the labels are a bit more approachable, but I worry that for most cases, they are not actually helpful, and very quickly end up unwieldy.

But again I feel like this is missing the point. I think the example of labels in the programming environment are really just a stepping stone — one stop on the road to being able to see and understand what a program is doing — but it’s not the only thing. Labeling the environment is one thing, but the concept can extend further to enable the experts to reach a higher ground. Sure, experts already know the syntax and probably most of the library functions too. Great, now that can be trivialized, and even better, new and more specific program parts can be visualized. Now things which are specific to the application can be labeled and explained, in context, for all developers of a given project.

Neil continues on other topics of visualization:

I propose that visualisation doesn’t scale to large programs. It’s quite easy to visualise an array of 10 elements, or show the complete object graph in a program with 5 objects. But how do you visualise an array of 100,000 elements, or the complete object graph in a program with 50,000 objects? You can think about collapsible/folding displays or clever visual compression, but at some point it’s simply not feasible to visualise your entire program: program code can scale up 1000-fold with the tweak of a loop counter, but visualisations are inherently limited in scale. At some point they are all going to become too much.

I think this is a very narrow-minded way to approach Bret’s essay. As someone who writes code blindly like we currently have to do, of course we’re going to have a hard time coming up with ways to visualize our data, but fortunately for us there’s a whole field to solve this very problem: Data Visualization (for anyone who’s interested in learning more on this topic, you absolutely should read the works of Edward Tufte). As programmers, we’re bad at visualizing data because we’ve never thought of it as a necessary skill. But once our eyes are open to the benefits of data visualization, then not only does it not seem impossible, it also starts to seem necessary.

Neil thinks we don’t have to see to understand:

Someone once proposed to me that being able to create a visualisation of an algorithm is a sign of understanding, but that understanding cannot be gained from seeing the visualisation. Visualisation as a manifestation of understanding, rather than understanding as a consequence of visualisation. I wonder if there’s something in that?

I disagree, and believe there’s much to be gained from understanding the relationship of seeing and understanding a concept. Alan Kay, building on the work of Piaget and Bruner had the insight which he summarized as follows:

Doing with Images makes Symbols.

This is a relationship between three human mentalities, where we work with body, the visual system, and the symbolic mind in different but complimentary ways. These act as a continuum of thought and interaction and movement within that continuum is essential. So to have real understanding of something on the symbolic level, it’s so much more natural to achieve this if you not only have images to work with, but also actually interact with those images as well. This is one of the essential, founding principles of the modern graphical user interface, a fact which is lost on almost all of its users.

Neil concludes his argument:

I like the blindfold metaphor, because it fits with our understanding of expertise: “he can do that with his eyes closed” is already a common idiom for expertise in a task. Beginner typists look at the keys. Expert typists can type blindfolded. Therefore at some point in the transition from beginner to expert typist you must stop looking at the keys. So it is with programming: you must reach a stage where you can accept the blindfold.

Which unfortunately also brings to mind The blind leading the blind metaphor. Lots of experts claim to be able to do something “with one hand tied behind my back”, but none would elect or suggest always working under such conditions. Nobody should be proudly held back at doing the best they possibly can at their work! Accepting the blindfold conditions for both beginners and experts alike is accepting the current state of programming as the best it can be, without any hope for improving the situations for generations to come.

At the end of the essay, Bret says what I believe is the real crux of his argument:

These design principles were presented in the context of systems for learning, but they apply universally. An experienced programmer may not need to know what an “if” statement means, but she does need to understand the runtime behavior of her program, and she needs to understand it while she’s programming.

Our society has deemed book literacy an essential skill as it’s a key mechanism in which our society thinks. Computers can offer an even better medium for society to think in, but only if we strive for computer literacy as well. And as with written literacy, this means both reading and writing. Expecting an entire society to write programs the way “experts” write them today is ludicrous, inscrutable, and counterproductive. If we’re to expect members of society to be computer literate, then we must create for them an environment where thinking can be expressed even better than on paper*.

*Yes, this is one reason why Cortex has yet to be released. I’ve yet to solve the problem of understanding and visualizing a Cortex plugin, and without that, it’s cripplingly difficult to create useful programs. This needs to be solved, because it’s irresponsible to expect developers to imagine it all in their heads.

I get really fired up when I think about one of The Greats, one of the people or teams of people in my field who I think are truly exceptional, who have contributed substantial work and who are rewarded copiously for it. They’re loved by some and reviled by others, but the common quality is they change things.

These are my heroes, the ones who make me want to get out of bed every day and be better than the day before at what I do. They set a bar for me, and I don’t want to be just like them, but I want to be great in my own ways. I’m not looking for fame, I’m only looking to be one of the Greats. I’ve been studying them for a while now and here’s what I’ve picked up so far, that they all have in common:

1. They have Powerful Ideas.

2. They act on those ideas.

In the simplest, most essential distillation, that’s what they do.

A Powerful Idea isn’t just a good idea, but instead one that lets us see farther. John W. Maxwell has this to say:

What makes an idea “powerful” is what it allows you to do; […] Powerful ideas are those that are richly or deeply connected to other ideas; these connections make it possible to make further connections and tell stories of greater richness and extent (p 187).

These are ideas like Hypertext, the Graphical User Interface, Cut Copy and Paste. Things that are simple in their own respect, but enable a tremendous new reach for humanity. They are not goals or destinations, but instead vehicles for getting us to the next step.

These ideas often don’t appear in dreams or apparitions but are instead culminations of years of dedicated study across a diverse set of fields. Alan Kay studied biology in university, which enabled him to see and create a design for Object Oriented Programming. He modeled computer programs after living cells. Many of Bret Victor’s great insights arise from an application of Edward Tufte’s information visualization principles: Show the Data and Show Comparisons.

When you study the powerful ideas of any field, you’ll almost always see the ideas emerging from analogy and synthesis of ideas from many other, seemingly unrelated fields. The insights often become obvious once you start looking past your own domain.

But a powerful idea is often not enough. Vannevar Bush’s As We May Think described the Memex, a mechanical, computerized contraption resembling a steampunk lovechild of the World Wide Web and Wikipedia, in 1945, and yet Bush’s work largely remained in obscuria for nearly fifty years. Why? Because the ideas were ahead of the technology at the time and they couldn’t be built. It’s not a failing of the quality of the invention (da Vinci hardly never could build any of his own designs at the time), but it strikes an important chord: to be a Great, you really need to be able to build it.

I think it’s critical to get these ideas into some form of tangible space, whether it’s a working prototype or a full-fledged product. People need to be able to see and use it, because an idea isn’t set in stone. It needs to be living and evolving. There needs to be a discourse and that’s certainly part of what makes the Greats so great, is they participate in this discourse.

These aren’t the only things the Greats seem to do, but they are the most fundamental and everything I’ve noticed seems to emerge from them. They’re important traits to know, but the most important thing isn’t to set out to emulate. It’s important not to walk in their footsteps but to instead stand on their shoulders.

A friend and I were talking about Kay’s original intentions for OOP the other day, so I thought this link might be interesting to others, as well. It turns out, OOP is a lot less about encapsulated data and methods on the data, and a lot more about messages between “little computers”:

The original conception of it had the following parts.

• I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning – it took a while to see how to do messaging in a programming language efficiently enough to be useful).

[…] OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them.

Gus Mueller (who knows a thing or two about image editors:

There’s my vote. Acorn has been using SQLite as its native file format since version 2.0, and it has been wonderful. When writing out and reading in an image I don’t have to think about byte offsets, I mix bitmap and vector layers together in the same file, and debugging a troubled file is as simple as opening it up in Base or your preferred SQLite tool. This sure beats opening a PSD file in a hex editor to figure out what’s going on.

If you’re looking for an alternative way of interacting with drawn artwork from Bret’s talk.

Bret Victor:

People are alive — they behave and respond. Creations within the computer can also live, behave, and respond… if they are allowed to. The message of this talk is that computer-based art tools should embrace both forms of life — artists behaving through real-time performance, and art behaving through real-time simulation. Everything we draw should be alive by default.

There’s a common superlative you hear, especially if you’re in the aspirational period of a high school Guidance Counsellor meeting, where you’ll hear “Anything’s possible!” And as you grow up, you learn to sort of filter out that sentiment. You learn there are limits, you learn there are things in the universe which seemed obvious, but really presented hidden meanings. Maybe you learned this literally and ran into a sliding glass door. It happens.

Learning limits is an important method of survival, but becoming a slave to those limits can turn you from living to coping. It can do more harm than good.

If you’re a software developer, you’re in a lucky place, because almost anything you can imagine is possible. Yes, there are limits to what hardware and software can currently do, and there are limits in what they can do eventually, too. But far and away, what is possible with a computer is quite limitless.

If you accept this, then new things start to become quite clear to you. You begin to see software as an illustration of your thought, as a way to explore the logic in your head. In a book you can write what you’re thinking, but in software you can express not only what you think, but you can see how that thought holds up to scrutiny. This is a small and simple truth with vast and curious implications. It means your thoughts can not only be heard, but explored, by generations both present and future.

When you don’t accept possibilities of software, you become limited in the world as it currently exists. We have so many inventions in software which exist merely because the inventor didn’t know they weren’t impossible.

When asked how he had invented graphical user interfaces, vector drawing, and object oriented displays all in one year, Ivan Sutherland replied “Because I didn’t know it was hard”. He had no preconceived notion of what was possible, so there was no hinderance. He just invented what he felt he needed in order to express his ideas.

Bill Atkinson infamously didn’t know overlapping windows were hard, but he invented them anyway. As an early Apple employee, Bill was one of the visitors of the famed Xerox PARC visits where he observed early versions of the Alto computer. He thought he’d seen a system with overlapping windows, so when he had to design a graphics system for the Mac, he had to build those too. Little did he know, the Alto never had overlapping windows to begin with. He had invented them because he was under the impression they were possible. Imagine!

Software today exists with much already established before us, but we’re still in the Incunabula stage. We’re still establishing the rules. Although there might appear to be much precedent in how something works, the truth is we’re in the very early stages. The rules are mutable and many are still yet to be written. We’re at a point where it’s critical to continue to explore new ideas, even if there’s only the slightest tinge of possibility, more often than not it turns out to be not only possible, but a superior approach.

Don’t ever let what you think you know dictate what you feel might be possible.

When I published my review of Linger the other day, I neglected to link to the trailer, so I’m doing that now. It’s so well done, it deserves a link of its own.

I’m going to get right down to it: you should buy Linger for iOS (here’s an App Store link). The app lets you explore the Prelinger Archives, a collection of short movies, ads, PSAs and propaganda from the 20th century all on your iPad (it works great for iPhone too).

Even if you’ve never heard of the Prelinger Archives before, you’re probably still familiar with the style of videos you’ll find there, the old black and white movies, showing assorted clips with a wholesome-sounding narrator. Think “Duck and Cover” or “Reefer Madness”, and you’ll get the idea.

The app, which requires iOS 6, is a perfect display for the content. From the welcome tour to the multiple ways to browse content, you can tell the developer has put a lot of thought and care into the experience. It basically looks like what an iPad app from the nineteen-fifties would look like, replete with poster themes and the perfectly chosen fonts. This app nails the style for its content.

So once you pick a video to watch (the videos are usually short in length, but there are some longer ones in there, too) the presentation works just as you’d expect. Most of the videos are in black and white, although there are some colour films as well.

The app is fast, responsive, beautiful and clever. It’s a great way to learn about early film culture, and it’s a great contribution to the App Store, but I wanted to find out more about the motivation behind it, so I interviewed the man behind it, Chuck Shnider to find out more.

Jason: Where did the idea for Linger come from?

Chuck: Linger was really a classic “scratch an itch” software project. I’d spent time off-and-on watching ephemeral films on my iPad, but was always frustrated by how difficult it was to browse online to find good stuff to watch. Some of those difficulties are rooted in limitations of simple webpages, while others were related to inconsistencies with the films’ metadata. Sometimes it boiled down to something as basic as a film being split into multiple parts, but there being nothing obvious to tell you that there were multiple parts, and where they could be found.

The iPad itself is very well-suited for the task of one person exploring a series of short films. At some point I just got sick of the hassle of watching the films on the web and started looking at what sort of open data I could get from archive.org, and started coding up an app.

Jason: How was the app developed (and how long/when did you work on it, etc.)?

Chuck: The app was developed over a period of 9 months as a side-project. Along the way, I also wrote a Mac app to process and analyze the raw metadata from Prelinger Archives. I mentioned earlier about inconsitencies with the source metadata. By applying some love to the data, users of Linger are spared some of that. However, there are few shortcuts when it comes to cleaning up that data. I do what I can with automation, but many of the corrections I did were applied by hand based on errors that were discovered by hand.

Jason: Did you build on any existing 3rd party technologies or do anything exciting with Apple’s frameworks?

Chuck: Most of the third-party stuff I use is pretty mainstream: AFNetworking, mogenerator, TransformerKit, HockeySDK. Beyond the more common libraries, I use a third-party library called KSScreenshotManager to help automate production work for App Store screenshots, and also for images which form the basis of the app’s launch images.

The app requires iOS6, and makes heavy use of UICollectionView, Auto-Layout, and Storyboards.

For graphic assets, I’m using stuff from The Noun Project and Subtle Patterns. I also spent a considerable amount of time searching for suitable fonts which had licenses that permitted embedding within a mobile app.

These aren’t technologies per se, but I’d be remiss if I didn’t also mention the great support I’ve received from Rick Prelinger, plus the video and metadata hosting provided by the Internet Archives. For an individual developer to ship an app like this, it’s essential to find a way to host all the video content for little or no cost.

Jason: Why are you highlighting the Prelinger archives? Why are they important for people to see?

Chuck: The heyday of ephemeral films was really from the 1930s to 1960s. This was also the period where corporations and governments really learned to use moving images to influence public opinion through advertising, education, and propaganda. For anyone who is a student of media literacy, consumer society, or 20th century American history, I think there is much to learn from watching these films. If you like kitsch, of course there is tons of that. Watch a little longer, though, and it’s almost inevitable that deeper themes come to the surface.

There are a few large collections of ephemeral films online. Prelinger Archives was particularly suitable for making into an app because the collection is well-researched, and they have clear terms of use for both the films and associated metadata.

Jason: What do you imagine for the app in the future?

Chuck: In the near-term, I have a few features planned that are “creature comforts” for more habitual users. Beyond that, I plan to focus on helping new users find interesting films to watch. There is definitely a lot of room for improvement there, and I think it would help new users to become the sort of habitual users who end up recommending the app to friends, etc.

Jason: Do you have or plan to have any kind of analytics in the app to figure out what viewers are watching? It seems like that might help to fuel more people to discover new gems in the app.

Chuck: No formal plans, but if a large-enough community of viewers does form to make the numbers meaningful, then it is something worth looking into. I’d also want to feel like the extra value from “top viewed films” was worth it to users in exchange for the anonymized usage data they would need to provide. With an app like this, I think of the user experience as more like visiting a library than watching videos on YouTube. What films you are viewing should be considered private, unless you decide to share on-purpose.

On a related vein, I’m looking into creating a venue where I can write a bit about films I’ve personally found interesting. One side-effect of developing an app like this is you get to watch a lot of the films. I haven’t settled on a format yet, but it may start out as a blog, and in time also incorporate the blog content directly into the app as well.

You should check it out.

Rob Dobelli:

News is irrelevant. Out of the approximately 10,000 news stories you have read in the last 12 months, name one that – because you consumed it – allowed you to make a better decision about a serious matter affecting your life, your career or your business. The point is: the consumption of news is irrelevant to you. But people find it very difficult to recognise what’s relevant. It’s much easier to recognise what’s new. The relevant versus the new is the fundamental battle of the current age. Media organisations want you to believe that news offers you some sort of a competitive advantage. Many fall for that. We get anxious when we’re cut off from the flow of news. In reality, news consumption is a competitive disadvantage. The less news you consume, the bigger the advantage you have.

News has no explanatory power. News items are bubbles popping on the surface of a deeper world. Will accumulating facts help you understand the world? Sadly, no. The relationship is inverted. The important stories are non-stories: slow, powerful movements that develop below journalists’ radar but have a transforming effect. The more “news factoids” you digest, the less of the big picture you will understand. If more information leads to higher economic success, we’d expect journalists to be at the top of the pyramid. That’s not the case.

He adds, and I agree, long-form, exploratory journalism is still very important and should exist. It’s time we have a method of expressing such inquiries in a way readers can better grasp and evaluate the ramifications they present. Videos and slideshows are not enough.

(See also Aaron Swartz’s thoughts on the matter)

A web service that doesn’t exist any more, but sounds really cool. Merlin Mann wrote about it when it was still a thing:

As promised, I wanted to start sharing some of the reasons I’ve been digging Stikkit, so I thought I’d begin at the beginning: Stikkit’s use of “magic words” to do stuff based on your typing natural (albeit geeky) language into a blank note. There’s a lot more to Stikkit than magic words, but this is a great place to start.

More like this please!

Computer Science education at universities in North America is typically a mix of Computers (learning programming language concepts, formal languages and proofs, data structures and algorithms, electronic architecture, etc.) and Math (algebra and calculus, linear algebra, statistics, number theory) but I think this education misses entire broad strokes of the elements involved in building software: making something to augment a human’s abilities.

Having a solid base in the Computer bits of Computer Science is essential as it enables the How of what a software developer makes. But it doesn’t shine any light on the Why a software developer is making something. Without knowing that, we’re often left shooting in the dark, hoping what we make is good for a person.

I’m proposing the education should focus less on mathematics and instead focus more on Human factors, specifically (but not limited to) Psychology and Physiology, the study of the human mind and the human body, respectively, and how the two parts interact to form the human experience.

By understanding the human body, we learn of its capabilities, and just as importantly, of its limitations. We learn about the ergonomics of our limbs, feet and hands, all of which inform the physical representations of how software should be made. We learn about a human’s capacity for sensing information, specifically from the eyes (like our ability to read, understand and parse graphical information like size, shape, and colour) and the hands (like our sophisticated dexterity and sense of tactility, texture, and temperature). Instead of pictures under glass, we’d be more informed to interact in more information rich ways.

By understanding the human mind, we learn how humans deal with the information received and transmitted from the body. We learn about how people understand (or don’t understand) the things we’re trying to show them on screen. We learn how people model information and try to represent our software in their minds. We learn that people represent some things symbolical and other things spatially, and we learn why that difference is important to building useful software.

We also learn how people themselves learn, how children are capable of certain cognitive tasks at certain ages, and how they differ, cognitively, from adults. This allows us to better tailor our software for our audience.

Psychology does even better than teaching us how a person works inside because it also gives us the beginnings of how people work amongst themselves, and how people share their mental models with each other. Since humans are inherently social beings, we should be taking advantage of these details when we build software.

All of these details are crucial for building software to be used by people, and nearly all of them are ignored by the current mandatory parts of Computer Science curriculum. We learn lots about the mechanics of software itself, but nothing about what we’re making. It’s like learning everything about architecture without ever having once lived inside a building. We build software with our eyes closed, guessing as to what might be useful for another person when there are libraries full of information telling us exactly what we need to know.

We need to stop guessing and we need to learn about who we’re building for.

Chrome engineer Alex Russell:

By now you’ve seen the news about Blink on HN or Techmeme or wherever. At this moment, every pundit and sage is attempting to write their angle into the annoucement and tell you “what it means”. The worst of these will try to link-bait some “hot” business or tech phrase into the title. True hacks will weave a Google X and Glass reference into it, or pawn off some “GOOGLE WEB OF DART AND NACL AND EVIL” paranoia as prescience (sans evidence, of course). The more clueful of the ink-stained clan will constrain themselves to objective reality and instead pen screeds for/against diversity despite it being a well-studied topic to which they’re not adding much.

And:

And that’s what you’re missing from everything else you’re reading about this announcement today. To make a better platform faster, you must be able to iterate faster. Steps away from that are steps away from a better platform. Today’s WebKit defeats that imperative in ways large and small. It’s not anybody’s fault, but it does need to change. And changing it will allow us to iterate faster, working through the annealing process that takes a good idea from drawing board to API to refined feature. We’ve always enjoyed this freedom in the Chromey bits of Chrome, and unleashing Chrome’s Web Platform team will deliver the same sorts of benefits to the web platform that faster iteration and cycle times have enabled at the application level in Chrome.

Calling

Calling

Mom is unavailable for FaceTime

Calling

Connecting…

Connecting…

Connecting…

[A blurry image of your mother appears]

“Hello!”

[The image freezes; you hear no more sound]

Disconnected

Calling

Connecting…

Connecting…

[A blurry image of your mother appears]

“Hi, sorry about that. No, it happ—”

[The image freezes again, audio gets choppy]

“Hello? Hel—yeah I’m still here. No it’s just the internet. Are you downloading anything on your computer right now? No? Well maybe tr—”

[The video resumes and audio comes back]

“Oh there we go, hi! Yeah things are great how are you?”

[You both talk at the exact same time because the audio is lagging so hard]

“What? Can you repe—”

[You both do that again]

“Yeah sorry, I think it’s just—”

[The image freezes; you hear no more sound]

Disconnected

“…”

*Calling”

Mom is unavailable for FaceTime

“…”

[You put down your iPad, walk over to your phone, and call your mother and actually have a conversation with her, implicitly admitting to yourself and to her that sometimes newfangled technology is done for our own sake, long before it’s ready for people and the world they live in, and giving her one more reason to think she’s bad at technology, when in reality it’s the technology that’s bad at people. You’ll also realize, if only slightly more than before, that you need to reconsider the next time you decide to add a “cool new feature” nobody was actually asking for if it won’t actually fit into the way they live just quite yet.]

Wide-ranging interview with Alan Kay from July 2012. Some highlights:

Binstock: You once referred to computing as pop culture.

Kay: It is. Complete pop culture. I’m not against pop culture. Developed music, for instance, needs a pop culture. There’s a tendency to over-develop. Brahms and Dvorak needed gypsy music badly by the end of the 19th century. The big problem with our culture is that it’s being dominated, because the electronic media we have is so much better suited for transmitting pop-culture content than it is for high-culture content. I consider jazz to be a developed part of high culture. Anything that’s been worked on and developed and you [can] go to the next couple levels.

Binstock: One thing about jazz aficionados is that they take deep pleasure in knowing the history of jazz.

Kay: Yes! Classical music is like that, too. But pop culture holds a disdain for history. Pop culture is all about identity and feeling like you’re participating. It has nothing to do with cooperation, the past or the future — it’s living in the present. I think the same is true of most people who write code for money. They have no idea where [their culture came from] — and the Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs.

On the Web:

Binstock: Well, look at Wikipedia — it’s a tremendous collaboration.

Kay: It is, but go to the article on Logo, can you write and execute Logo programs? Are there examples? No. The Wikipedia people didn’t even imagine that, in spite of the fact that they’re on a computer. That’s why I never use PowerPoint. PowerPoint is just simulated acetate overhead slides, and to me, that is a kind of a moral crime. That’s why I always do, not just dynamic stuff when I give a talk, but I do stuff that I’m interacting with on-the-fly. Because that is what the computer is for. People who don’t do that either don’t understand that or don’t respect it.

(I originally tried to link to the article on Instapaper but the link wasn’t public. If you use Instapaper, read it there so the article isn’t spread across four pages.)

Software developers have really crappy tools. If we’re lucky, we’ve got some limited graphical tools for creating user interfaces and some form of rudimentary auto-complete, but our programs still exist in text files, which amount to little more than digital pieces of paper. We want to augment programming languages with new IDEs and tools, but it’s often painful to graft these features on existing languages. What we need are languages built around our tools, not the other way around.

The current best effort for better technical tools in my opinion is Apple’s Xcode, specifically the Interface Builder tool. As the name suggests, IB is a tool for creating user interfaces graphically. Instead of writing code to layout your interface elements, you use IB to position them. You get the benefit of seeing what your app is going to look like as you’re working on it, without the need to stop and rebuild your project with every modification.

Putting aside my qualms with how Interface Builder really works in practice, I do think it’s a great idea. But it’s really not enough, because the interface elements laid out are pretty dumb — you can’t really interact with them much until you actually build the application — which stops pretty short of allowing you to feel how your application really works in practice. You see how it looks with skeletal data, but you don’t get to see how it works.

Another element of Interface Builder are interface Bindings (these are Mac only), which, in theory, allow you to wire up your data to interface elements in your application without having to write any code to do so. Another incredible idea in theory but in practice it’s very difficult to get right, and it’s maddening to debug.

Why are these tools so hard to get right? It’s because we start with a programming language, which in many cases was developed decades ago during different constraints and conditions, and we try to graft modern tools and ideas atop it. In Objective C’s case, the language has its roots in the 1980s (or 1970s, due to C). We’re trying to solder on modern bits to old harnesses, what Wolf Rentzsch refers to as bolting on an air conditioner to a go-kart. Sure, it’s possible, but the effect feels pretty bad. It doesn’t mean air conditioning is bad, it just needs to be installed in the right environment.

Language makers need to change what they focus on. Instead of trying to add nice things to the environment (IDE, Tools, etc) that fit the language, they should instead design a good environment for building software and then design the language around that. Instead of taking decades-old programming language and grafting on an environment, I think it would better to first design a programming environment and then build a language to suit it.

As an example, I’m going to list some things I believe would be good in such a programming environment, and although this list is neither perfect nor exhaustive, I hope it illustrates the point of how programming languages can be designed in the future.

1. Programmers should be able to see their changes reflected immediately. I’m definitely not the first one to believe in this principle and I’ve made my own stabs at it with the Super Debugger too. But it’s really tricky to get this right with programming languages which weren’t designed with this principle in mind. Imagine how much more flexible the language could be if this were intended behaviour?

2. The environment should allow for connecting data to graphical representations without the need for excessive glue-code. This is what Bindings on the Mac attempt to solve, but they themselves are glued on. The environment should support this from the ground up so that programmers can easily do the repetitive task of attaching their database or web service data model to a graphical display.

3. The environment should allow for better traversal of program code than just classes in files. Groups of related functions and methods should be brought together as the programmer is working with them. The programmer shouldn’t have to hunt for method declarations or implementations, nor should they have to hunt for documentation on the functionality. This should be brought to the developer’s field of vision as it’s needed.

   Relying on plain text files for source code drastically reduces the flexibility of the programming environment. Instead, the files can be stored in a smarter format as required by the programming environment. We already rely so heavily on our environments as is, as we have long method names which require auto-complete and stub/generated functions that we can never remember. And yet we feel shameful when we use a plain-text editor but we can’t remember how to code without the IDE. Why not instead embrace the IDE and not be ashamed when using a language-ignorant text editor?

   Features like auto-complete are great, when they work. But imagine how much better they would be if the language was designed from the beginning to support them?

These are just examples and many of them have existed as ideas for decades at this point, neither of which is important. The point I’m trying to make here is that whatever the principles of programming environment design are, it should be those principles which dictate how the programming language should work. We should strive to figure out the kinds of tools developers need to create exceptionally powerful programs, and then design programming languages to enable those tools. It doesn’t mean the IDE has to be written in the new language, but just that it should be written with it in mind.

Software is currently the best medium we humans have to express our explanations and explore our ideas. And yet the way we express these programs is limited to what are essentially digital versions of pieces of paper. It’s time we start building better ways to express ourselves with interactive media, and that means building the backbone language around the environment in which it lives.

If you find this idea intriguing, you should definitely come hear me speak at NSNorth in April 2013 in Ottawa. It’s going to be the start of something great.

There are many apps which try to help you out by aligning some of their functions to happen on a per-day basis, whether it’s a reminder or a calendar event, or some other kind of task which has a day-bound relevance. This is a good idea dogmatically but I’ve found all implementations to fail in a pragmatic way: the day doesn’t start at midnight.

The best example of an app violating this is Things (both for Mac and iOS), which has a handy feature for recurring todos. The gist of the feature is “repeat this task every X days (or weeks or months, etc.) after I’ve completed it” with the idea being, I’d like a repeating task, but I only ever want to see it at most once in a list — if I haven’t completed it by the time it’s scheduled to appear again, don’t show it until I’ve marked it as complete and the proper time has elapsed.

In theory this works really well. I’ve got a task to “do some dishes” once per day, but if I happen to miss a day, I don’t get two todos the next day, I just stick with the one. Once I check it off, it recurs again the next day, where the day starts at midnight. Here’s where the problem is:

I stay up a little late at night and usually go to bed between midnight and 2AM. As I’m getting ready for bed, I’ll often review the day’s tasks in Things and mark off my stuff as completed, often things I’ve forgotten to mark as completed while I was going about my day. So let’s say it’s 1AM on Tuesday (technically this is Tuesday, but since I haven’t yet gone to bed, it’s really still Monday to me) and I mark off my recurring “do the dishes” todo. That’s great, and I expect to see the todo again tomorrow (during the daytime of Tuesday). But this is where my view of the situation diverges from that of the software: to me, “tomorrow” means “any time after I wake up and get dressed but before I go to sleep at night”, but to the software it means “any time after midnight”.

What ends up happening, because of our silly disagreement, is Things thinks I’ve already marked the task as being done for what I’d consider “the next day” and instead won’t show me the task again until after the next midnight rolls around. So in this case, I don’t see the task at all on Tuesday and it doesn’t show up until I start using the app Wednesday morning.

In this case, it’s not so grave because, well I’ll probably see the dishes and remember to do them anyway. But it’s still an error in pragmatism for the software to do something like this. There are probably way more users who go to bed at 2AM than who wake up and start their day at 2AM. And yet our software almost always treats us as though we’re mechanically bound to clocks, that our lives are grasped tightly by their hands.

A slightly better example of software handling this is with Siri. If it’s a little after midnight on Monday (so technically Tuesday) and you say “Siri, remind me to do the dishes tomorrow morning”, Siri will respond with something to the tune of “Just to be sure, did you mean Tuesday or Wednesday”. This is a step in the right direction, but it’s still an extra step the person almost never needs to take.

How to solve this problem

The obvious first solution to this problem is to simply have a setting in your application which says “The day starts at X” and let the user pick a time. That works, but it still pretty much stinks because the user is going to have to set this for every app which supports it, and it might change over time as the user’s habits change (student life to working life to parenthood, for example), not to mention many users probably won’t dive through the settings and designate a particular time anyway, so the program remains daft, treating the user as if they’re a clock.

The better solution is to infer what time the person starts and ends their day. It’s pretty easy to figure out with some simple usage statistics, by using what times of day the app is used (of course treating weekends slightly differently). If the app is used late at night, then you learn usage patterns and adjust the day cutoff to match the usage. If the app doesn’t get used late at night, then you don’t learn anything, but you don’t need to because the app doesn’t get used late anyway, so it doesn’t matter. A simple example of usage recognition can be found in Bret Victor’s Magic Ink in the “Engineering inference from history” section.

If you have to, be smart by being stupid

At the very least, consider solving the problem by making the day end later than midnight. You won’t throw off anyone by making the day end at 3AM vs midnight, and there’s no sense pandering to the edge case of those starting their day that early anyway. It’ll make your software work more like people do.

In January, while still at Shopify, I released the Super Debugger for iOS, a wireless, interactive, and realtime debugger for iOS applications. That means you can debug your applications over wifi (and potentially, cellular), without needing to set breakpoints. You can send messages to your objects, you can see their state, and you can change their state all in real time. The project is open sourced on Github, too.

From the project’s homepage:

The Super Debugger (superdb) lets you debug in new ways lldb can’t: it allows you to send messages to the objects in your app, without the need to stop on breakpoints.

Use the powerful Shell on your Mac to inspect your objects, see changes instantly, and speed up development.

The project started as an internal “Hack Days” project at Shopify, where we got two days to start and “ship” (or at least demo) a project. As I’m a Cocoa developer, I had been thinking of ways to make development easier, and superdb was the result.

The Details

The Super Debugger builds upon F-Script, a Mac project by Philippe Mougin. F-Script has been around for probably close to a decade now, and it works as an object browser for Cocoa objects. Philippe refers to it as “a Finder for your objects”, which I think is a great description. It’s a programming environment with a Smalltalk-like syntax where objects can be inspected and messaged.

The project itself doesn’t appear to be maintained very much anymore and it was Mac only until Github user “pablomarx” got a version of it running for iOS. Even though the iOS code had rotted since pablomarx had ported it, it was still a great accomplishment, but it was more of a proof-of-concept than anything else. The testbed was an iOS application with a text field and an output log. It showed that it worked, but it wasn’t exactly useful.

The technology had been around for a while, and yet nothing useful was coming of it. I thought about it for a while and decided my Hack Days project was going to make use of this technology.

So I started by modernizing the iOS port of F-Script, wrapped it up in a network service, used some Bonjour magic to find running instances of it on a local network, wrote a socket protocol between the F-Script interpreter and a Mac app, wrote a command shell for the Mac app and presto, the Super Debugger was born.

Even though it might sound like a lot, the real meat of the operation took only those two days at Shopify. The technology had existed for years and yet all it took was a couple of days to make something tremendously useful out of it. It might sound kind of self-congratulatory, and it is as I’m very proud of what I’ve made, but my point is sometimes wonderful things are hidden under the word “just”. Sometimes there are brand new avenues we’d never even considered and all that was missing was the tiniest of pieces.

The bigger moral of the story is just because what you’re adding to something doesn’t seem like much, or isn’t difficult to create, doesn’t mean it can’t have a profound impact on what you’re making. Slapping a network layer on an interpreter someone else wrote and adding a few stolen interaction tricks may sound like cheating, but it’s thinking like this we desperately need more of in this world.