I’ve been running Speed of Light since early 2010, and it continues to be a more rewarding experience with every passing day. I’ve used it as a place to explore my thoughts and expand my writing abilities, and I’ve made some friends in the process. Though my readership is modest, it is also thoughtful (and handsome).

There seems to be a trend when someone such as me has a website such as I do reaches a point in their website writing or readership when a decision is made to start making profit. This is not a bad thing, and many writers with numerous readers make this decision to go at least semi-pro with their writing.

I don’t think this is the right path for me, first and formost because I wouldn’t know where to begin without making it shitty and ensuring failure. I just don’t have enough readers to attract any kind of moderate money from this website, and nor do I want to resort to tactics to try and coerce such a readership. My articles may not make the rounds on Twitter or make it to the top (or even bottom) of Hacker News, and I may not get errant clicks because of the inflammatory or salacious headlines I choose not to write, but that’s something I’m damn proud of and I don’t intend on changing.

So instead of trying to convince myself of a goal I really don’t want, and then inflict upon my readers tactics to achieve that goal, I want to try something different.

I’m not taking this website full time, and I’m not even taking it semi-pro. I’m not adding advertising or sponsorships and I’m not adding a membership. In fact, you could have skipped this altogether and not seen any change, and that’s OK with me.

Enter the Tip Jar

What I’m doing is basically putting out a tip jar, nothing more and nothing less. It’s a way for people who like what I already write to encourage me to write more in the same vein. Here’s how it works:

1. If you like what I write so much that you want me to write more of it, you can go through my Amazon wishlist and buy me something from it.
2. If you don’t want to, then you don’t. Nothing changes.

I’m not trying to sway anyone to do this, I’m just trying this as an experiment to let you do it, if you’d like. The items on my wishlist tend to be about the topics I like to write about, so it’s a way for you, the reader, to encourage (or thank) me to write more like I do. Or maybe to expand my horizons. Or maybe you think something on the list is particularly awesome (the order of the items on the list shouldn’t indicate preference, I had to transfer them all over recently from an older Amazon account).

So there it is. My wishlist, it’s a way for you give me a tip if you so choose, or a way for you to just look at my interests if not.

Here’s to many more years of Speed of Light!

Anthony Doerr, writing about what we all collectively do to the planet, and what we all collectively don’t do to help it:

In most American feedlots, beef cattle live their lives standing in or near their own manure. E. coli O157:H7—often found in cow feces—infects about 70,000 Americans a year and kills about 52. Undercooked or raw hamburger has been implicated in many of the documented outbreaks.

What has been our solution? Take the cows out of their own shit? Not quite. Instead we’ve decided to ramp up the antibiotics and treat ground beef with ammonia-drenched filler. We love technological fixes that allow us to preserve our existing systems. Professional football players are getting too many concussions. What’s our solution? Lobby for better helmets. Cheap calories are producing heart disease in too many Americans. What’s our solution? Give people anti-cholesterol statins that may be linked to anxiety and depression.

Look, I wouldn’t trade the 21st century for any other. We have toilet paper and vitamin-fortified milk and a measles vaccine. We can buy avocados in Fairbanks in January. But sometimes, particularly in the United States, we tend to put too much faith into the transformative powers of technology. Is progress really a curve that sweeps perpetually, unfailingly higher? Wasn’t toy-making or winemaking or milk-making or cheese-making or cement-making sometimes performed with more skill 300 or 700 or 1,900 years ago? I think of a tour guide I once overheard in the Roman Forum. She pointed with the tip of a folded umbrella at an excavation and said, “Notice how the masonry gets better the earlier we go.”

Later:

There’s mercury on our mountaintops and antidepressants in our groundwater. Earthworms in American farm fields have been found to have caffeine, household disinfectant, and Prozac in them. Scientists have found antibiotic-resistant genes in 14 percent of the E. coli in the Great Lakes. Maybe even more astounding, they’ve found antibiotic-resistant E. coli in French Guiana, in the intestines of Wayampi Indians—people who have never taken antibiotics.4

With every year that passes, Earth becomes a little more like a gorgeous, huge, and mismanaged zoo. Is it really relevant anymore to argue that one thing is natural while another thing is not?

Remember that whole bit in Slaughterhouse Five about the zoo?

An alternative way to watch the Star Wars series:

How can you ensure that a viewing keeps the Vader reveal a surprise, while introducing young Anakin before the end of Return of the Jedi?

Simple, watch them in this order: IV, V, I, II, III, VI.

George Lucas believes that Star Wars is the story of Anakin Skywalker, but it is not. The prequels, which establish his character, are so poor at being character-driven that, if the series is about Anakin, the entire series is a failure. Anakin is not a relatable character, Luke is.

This alternative order (which a commenter has pointed out is called Ernst Rister order) inserts the prequel trilogy into the middle, allowing the series to end on the sensible ending point (the destruction of the Empire) while still beginning with Luke’s journey.

Effectively, this order keeps the story Luke’s tale. Just when Luke is left with the burning question “how did my father become Darth Vader?” we take an extended flashback to explain exactly how. Once we understand how his father turned to the dark side, we go back to the main storyline and see how Luke is able to rescue him from it and salvage the good in him.

Also, like the story itself, there’s a twist:

Next time you want to introduce someone to Star Wars for the first time, watch the films with them in this order: IV, V, II, III, VI

Notice something? Yeah, Episode I is gone. While I don’t think the “Hayden’s Anakin’s ghost at the end of ROTJ” is a real problem, Rod Hilton makes a great argument for this order of viewing. It’s at least worth reading through his argument, if you’re a Star Wars nerd yourself.

(via Ash Furrow (IRL))

DirkH:

The original trilogy gave us a window to one of the most interesting universes ever created. It is a fantasy, filled with amazing aliens and wonderful characters. The Phantom Menace was the film that could expand on this universe. We could have gotten more fantastical worlds, more foundation to the mythos. What we instead got was Tatooine……again. It could have traveled the entire universe but it instead gave us a planet we already know. This is but a tiny example of the unbelievable unimaginative feel this film has. This is most present in its plot. We start out this film with a dispute about tax regulations. Really? What a hook! I’m riveted!

Kevin Fanning:

“What is happening?” he said, staring blankly at the screen. “I don’t get it. What is this?” There was no one in the apartment to answer him. “These episodes feel so different! Why isn’t this more like what I remember? Why aren’t I laughing?”

The cop wanted the show to be as funny as he remembered. He wanted it to reveal itself more openly. He wanted it to make him laugh and not make him wonder what was going on. He slammed his Macbook Air shut and stomped around his apartment. He wanted to tweet about his frustration, maybe see if other people shared his feelings, but he didn’t want to be accused of spoiling season four for other people who hadn’t begun watching it yet.

“I’m so angry!” he said. He stopped and stood very still in the middle of his apartment. “Ugh! So mad!” he said. “I feel like I could …” his mind scanned every file in its memory for the aptest word, the metaphor, the action that would properly convey the feelings he was experiencing. “I feel like I could slap a vagina,” he thought.

Well written satire making me cringe all kinds about myself.

Ryan McCuaig on what’s actually the big deal about the new iOS UI (hint: it’s not the icons):

The frameworks for providing parallax effects based on the gyroscope and adding physics to enhance the illusion that real things are being manipulated are incredible. Motion effects and dynamics are now very easy to apply and play with, which democratizes them and makes it possible for the less technically-inclined among us to participate in building up the relatively uncharted design language around them.

The closest comparison I can think of is the effect the LaserWriter had on print design. I expect the same period of taking things way too far and backing off. But the LaserWriter completely transformed print design. I expect the same here.

If you’re following WWDC and wishing to build your own apps, check out my friend Ash’s new book. He put a ton of work into it, and it’s well done.

Or: Jason Brennan gets sentimental about discovering his Canadian pride only after become an expat.

After spending the first twenty-four-and-a-half years of my life living obliviously as a Canadian, in January 2013 I moved to the United States to live with my girlfriend in New York City. My time here has been nothing short of fantastic, but it wasn’t until I got here that I realized what my home country meant to me.

This is not the simple story of “you don’t know what you’ve got till it’s gone”, although there are some aspects of that. But I think the real crux of it is the culture of my home country was so subliminal to me, being immersed in it, that I didn’t even realize it existed until it was missing.

Growing up in the Maritimes I was submerged in — drenched by — CanCon, the CRTC (Canada’s version of the FCC, essentially) mandate to play at least 30 per cent Canadian content on the airwaves. This meant Canadian artists were given a government-backed promotion on the radio and television, to give them a fighting chance against the seemingly limitless American music industry. For someone developing a musical taste in the early 2000s, this meant hearing lots of Rush, The Guess Who, and The Tragically Hip (the latter I specifically loathed). But what I didn’t realise was, mandated or not, these artists (and many others, like 54-40, I Mother Earth, Our Lady Peace, Bare Naked Ladies, hell, even Nickleback) were indeed infused into Canadian culture, a culture in which I was unknowingly a member. To me, they were just overplayed bands, constant requests on the 105.3 FM (“The Fox”)’s “Drive At Five” request line, repetitive and unoriginal staples and traffic-jam anthems.

Almost always, the songs were written about subjects I could barely relate to, whether they were from the vast Canadian Prairies I’ve never seen, or even the coastal songs of choppy Atlantic waters. From the cushy every-town valley that is Fredericton, New Brunswick, I found little to relate to with the rest of Canada’s geography or the songs about her. What I never realised, however, was there was something subtle amidst. There was an effect I could not smell or taste or hear, and that was although I could never relate precisely to any of these stories, I could relate to them as a Canadian on some level. I could relate on the level of being aware and surrounded by diversity of all levels. Diversity of geography and of heritage and of language and of politic. These are some of the truisms of Canadian culture, and they were utterly invisible to me living in Canada.

Since leaving Canada, however, these things became almost instantly and painfully apparent to me. Even though I could never relate to the Prairies, they were at least a part of my culture, even if the culture of New Brunswick was “we don’t get the Prairies”. And now, I’m here and that’s sorely lacking. There’s a hole where a misunderstanding of my Canadian culture used to be. Now there’s nothing and I’m choosing to identify that as pride.

You can pry my u’s from my cold dead fingers. YYZ is a second Canadian anthem, and it’s pronounced zed, not zee, zed. I pretend to understand Marshall MacLuhan, the Tragically Hip’s lyrics, and Canada’s foreign policy. My name is Jason Brennan, and I Am Canadian.

A fantastic talk from Google IO 2013 about the human (mental and physical) aspects of building software. It’s like a quick tour of some of the things I’ve written about previously.

Yesterday I published an article asking Cocoa developers to rethink a common “Singleton” pattern and to improve it for our sanity:

I recommend hiding the sharedWhatever away from clients of your API. You can still just as easily have a shared, static instance of your class, but there’s no need for that to be public. Instead, give your class’s consumers class methods to work with.

I received three kinds of feedback for this article, the first kind being agreement, and that’s all there is to say about that.

The second theme was “It’s not the convention in Cocoa”. I think the reason for this is most of the time, developers are confusing a similar but different pattern used in Apple’s frameworks. The most common example is NSUserDefaults:

[[NSUserDefaults standardUserDefaults] setBool:YES forKey:SOLUsesStringConstants];

This looks a lot like a singleton but it isn’t. It’s just a way to access the standardUserDefaults, a pre-made object which your app will likely want to interact with. But it in no way implies or means you can’t create your own. The same pattern applies for other classes like NSNotificationCenter and NSFileManager to name but a few.

The third bit of feedback is where I’m a bit foggy, and that’s about the testability of hiding the shared object. I don’t do unit testing very often, but when I do I haven’t run in to any issues. From a fundamental point of view, I don’t understand why hiding the shared object should make testing any more difficult (I’m not being coy or shitty, I legitimately just don’t know). As far as I can tell, you’ll still be testing the public interface of your class, and that should be enough. But if I’m missing something (and this is entirely likely) then I’d love to know about it. Write about it on your website or email me.

It seems to me like if a foreign student trains at a US school, then it would make sense for the US to allow that student to work freely in the country, instead of incentivizing them to leave for another country.

Here’s a common pattern I see all the time in Cocoa development involving Singletons (let’s put aside any judgement as to whether or not the Singleton pattern is a good one and just roll with this for a moment): the singleton class Thing exposes a class method called +sharedThing which returns a shared instance of the class, and then has a bunch of instance methods to do real work. Here’s what the interface might look like:

@interface Thing : NSObject

+ (instancetype)sharedThing;
- (void)doYourStuff;
- (void)setGlobalToggleEnabled:(BOOL)enabled;

@end

It’s all your standard fare. When your client wishes to use it, you end up with the rather silly looking:

[[Thing sharedThing] doYourStuff];
[[Thing sharedThing] setGlobalToggleEnabled:YES];

Every time I want to do something with the singleton, I’ve got to first request it from the class, then I send that instance a message. It’s straightforward enough, but it gets tedious real quick, and it begins to feel like a part of the implementation is leaking out.

When I use a singleton class, I shouldn’t really have to care about the actual instance. That’s an implementation detail and I should just treat the whole class as a monolithic object. I’m sending a message to the House itself, I don’t care what houseling lives inside.

So instead, I’d recommend hiding the sharedWhatever away from clients of your API. You can still just as easily have a shared, static instance of your class, but there’s no need for that to be public. Instead, give your class’s consumers class methods to work with:

@interface Thing : NSObject

+ (void)doYourStuff;
+ (void)setGlobalToggleEnabled:(BOOL)enabled;

@end

@implementation Thing

+ (instancetype)sharedThing { /* return it as usual */ }

+ (void)doYourStuff {
    Thing *thing = [self sharedThing];
    thing.privatePropertyCount += 1;
}
// etc.

If your singleton class needs to store some state (and please try really hard to avoid storing global state), you can still use private properties (via the Class Extension) and expose necessary ones as class methods, too. Exposing global state this way is a bit more work, but doing this work is kind of a natural immune response of the language to discourage you from doing so, anyway.

Sometimes singletons are a necessary evil, but that doesn’t mean they necessarily have to be unpleasant. Hiding away the implementation detail of a “shared instance” frees other programmers from having to know about the internals of your class, and it prevents them from doing repetitive, unnecessary typing.

Let’s class up our singletons.

Ash Furrow:

When using gesture recognizers, it is almost always far, far better to use UIPanGestureRecognizer than UISwipeGestureRecognizer because it provides callbacks as the gesture takes place instead of after it is said and done.

If your app feels kind of wooden, this might be one reason why.

Jean Jullien:

“Allo?” is my first solo show in London, at Kemistry gallery Intrigued by everyday life and human interaction, Allo? explores our social and asocial behaviours, the relationship between people and how we communicate with one another.

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.