Skip navigation
Help

Objective-C

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.

Photo

Oliver Reichenstein is the founder and director of Information Architects, the Tokyo, Zurich, and Berlin-based design agency. iA's usual trade is website design and consultancy along with the odd concept like the Twitter strikethrough, but the company has also found recent success in iOS and Mac app development. Writer for iPad is a pioneering minimalist text editor, and its focus-enhancing combination of sparse visuals and refined typography has since made the leap to OS X and the iPhone.

Reichenstein recently took the time to answer some of my questions on design and development. Since iA's work is informed by its presence in Europe and Asia, I wanted to know his thoughts on the differences between the two, and in particular where he...

Continue reading…

0
Your rating: None

If I had to make a list of the top 10 things I've done in my life that I regret, "writing a book" would definitely be on it. I took on the book project mostly because it was an opportunity to work with a few friends whose company I enjoy. I had no illusions going in about the rapidly diminishing value of technical books in an era of pervasive high speed Internet access, and the book writing process only reinforced those feelings.

In short, do not write a book. You'll put in mountains of effort for precious little reward, tangible or intangible. In the end, all you will have to show for it is an out-of-print dead tree tombstone. The only people who will be impressed by that are the clueless and the irrelevant.

As I see it, for the kind of technical content we're talking about, the online world of bits completely trumps the offline world of atoms:

  • It's forever searchable.
  • You, not your publisher, will own it.
  • It's instantly available to anyone, anywhere in the world.
  • It can be cut and pasted; it can be downloaded; it can even be interactive.
  • It can potentially generate ad revenue for you in perpetuity.

And here's the best part: you can always opt to create a print version of your online content, and instantly get the best of both worlds. But it only makes sense in that order. Writing a book may seem like a worthy goal, but your time will be better spent channeling the massive effort of a book into creating content online. Every weakness I listed above completely melts away if you redirect your effort away from dead trees and spend it on growing a living, breathing website presence online.

A few weeks ago, Hyperink approached me with a concept of packaging the more popular entries on Coding Horror, its "greatest hits" if you will, into an eBook. They seemed to have a good track record doing this with other established bloggers, and I figured it was time to finally practice what I've been preaching all these years. So you can now download Effective Programming: More Than Writing Code for an introductory price of $2.99. It's available in Kindle, iPad, Nook, and PDF formats.

 More Than Writing Code (Jeff Atwood)

I've written about the ongoing tension between bits and atoms recently, and I want to be clear: I am a fan of books. I'm just not necessarily a fan of writing them. I remain deeply cynical about current book publishing models, which feel fundamentally broken to me. No matter the price of the book, outside of J.K. Rowling, you're basically buying the author a drink.

As the author, you can expect to make about a dollar on every copy that sells. The publisher makes several times that, so they make a nice profit with as few as, say, five thousand copies sold. Books that sell ten or fifteen thousand are rare, and considered strong sellers. So let's say you strike gold. After working on your book for a year or more, are you going to be happy with a payday of ten to fifteen grand?

Incidentally, don't expect your royalty check right away. The publisher gets paid first, by the bookstores, and the publisher may then hold on to your money for several months before they part with any of it. Yes, this is legal: it's in the publisher's contract. Not getting paid may be a bummer for you, but it's a great deal for the publisher, since they make interest on the float (all the money they owe to their authors) - which is another profit stream. They'll claim one reason for the delay is the sheer administrative challenge of cutting a check within three months (so many authors to keep track of! so many payments!)... a less ridiculous reason is that they have to wait to see whether bookstores are going to return unsold copies of your book for a full refund.

Here's one real world example. John Resig sold 4,128 copies of Pro Javascript, for which he earned a grand total of $1.87 per book once you factor in his advance. This is a book which still sells for $29.54 on Amazon new.

Resig-book-check

Tellingly, John's second book seems permanently unfinished. It's been listed as "in progress" since 2008. Can't say I blame him. (Update: John explains.)

When I buy books, I want most of that money to go to the author, not the publishing middlemen. I'd like to see a world where books are distributed electronically for very little cost, and almost all the profits go directly to the author. I'm not optimistic this will happen any time soon.

I admire people willing to write books, but I honestly think you have to be a little bit crazy to sit down and pound out an entire book these days. I believe smaller units of work are more realistic for most folks. I had an epic email discussion with Scott Meyers about the merits of technical book publishing versus blogging in 2008, and I don't think either of us budged from our initial positions. But he did launch a blog to document some of his thoughts on the matter, which ended with this post:

My longer-term goal was to engage in a dialogue with people interested in the production of fast software systems such that I could do a better job with the content of [my upcoming book]. Doing that, however, requires that I write up reasonable initial blog posts to spur discussion, and I've found that this is not something I enjoy. To be honest, I view it as overhead. Given a choice between doing background research to learn more about a topic (typically reading something, but possibly also viewing a technical presentation, listening to a technical podcast, or exchanging email with a technical expert) or writing up a blog entry to open discussion, I find myself almost invariably doing the research. One reason for this is that I feel obliged to have done some research before I post, anyway, and I typically find that once I'm done with the research, writing something up as a standalone blog entry is an enterprise that consumes more time than I'm willing to give it. It's typically easier to write the result up in the form of a technical presentation, then give the presentation and get feedback that way.

Overhead? I find this attitude perplexing; the research step is indeed critical, but no less important than writing up your results as a coherent blog entry. If you can't explain the results of your research to others, in writing, in a way they can understand, you don't understand it. And if you aren't willing to publish your research in the form of a simple web page that anyone in the world can visit and potentially learn from, why did you bother doing that research in the first place? Are you really maximizing the value of your keystrokes? More selfishly, you should always finish by writing up your results purely for your own self-improvement, if nothing else. As Steve Yegge once said: "I have many of my best ideas and insights while blogging." Then you can take all that published writing, fold in feedback and comments from the community, add some editorial embellishment on top, and voilà – you have a great book.

Of course, there's no getting around the fact that writing is just plain hard. Seth Godin's advice for authors still stands:

Lower your expectations. The happiest authors are the ones that don't expect much.

Which, I think, is also good life advice in general. Maybe the easiest way to lower your expectations as an author is by attempting to write one or two blog entries a week, keep going as long as you can, and see where that takes you.

[advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you.

0
Your rating: None

In What You Can't See You Can't Get I mentioned in passing how frustrated I was that the state of the art in code editors and IDE has advanced so little since 2003. A number of commenters pointed out the amazing Bret Victor talk Inventing on Principle. I hadn't seen this, but thanks for mentioning it, because I definitely should have. Maybe you haven't seen it either?

It's a bit long at 54 minutes, but worth viewing in its entirety. What Bret shows here is indeed exactly the sort of thing we should be doing, but aren't.

In some ways we've actually regressed from my ancient Visual Basic 6.0 days, when you'd get dynamically notified about errors as you typed, not just when you compiled or ran unit tests. The idea that you should be able to type (or gesture, or speak) and immediately see the result of that change is simple, but extremely powerful. It's speed of iteration in the small. That's essentially the basis for my argument that showing markup and rendered output side-by-side, and dynamically updating them as you type, is vastly superior for learning and experimentation compared to any attempt at WYSIWYG.

But Bret goes further than that – why not show the effects of predicted changes, and change over time? Time is the missing element in a static display of code and rendered output; how do we show that?

Braid-jump-code

Again, watch the video because it's easier to see in action than it is to explain. But maybe you'd like to play with it yourself? That's sort of the point, isn't it? As I wrote in 2007:

I yearn for the day when web pages are regularly illustrated with the kind of beautiful, dynamic visualizations that Ben Fry creates.

That day, I'm happy to report, seems to have arrived. Bret's article, Up and Down the Ladder of Abstraction is extremely interactive in plain old boring HTML 5.

Interactive-ladder-abstraction

Yes, it's artsy, yes these are mostly toy projects, but this isn't entirely abstract art house visualization nonsense. Designing tools that let you make rapid changes, and see the effects of those changes as soon as possible can be transformative.

Paul realized that what we needed to be solved was not, in fact, human powered flight. That was a red-herring. The problem was the process itself, and along with it the blind pursuit of a goal without a deeper understanding how to tackle deeply difficult challenges. He came up with a new problem that he set out to solve: how can you build a plane that could be rebuilt in hours not months. And he did. He built a plane with Mylar, aluminum tubing, and wire.

The first airplane didn't work. It was too flimsy. But, because the problem he set out to solve was creating a plane he could fix in hours, he was able to quickly iterate. Sometimes he would fly three or four different planes in a single day. The rebuild, retest, relearn cycle went from months and years to hours and days.

Eighteen years had passed since Henry Kremer opened his wallet for his vision. Nobody could turn that vision into an airplane. Paul MacCready got involved and changed the understanding of the problem to be solved. Half a year later later, MacCready's Gossamer Condor flew 2,172 meters to win the prize. A bit over a year after that, the Gossamer Albatross flew across the channel.

Don't get me wrong, we're failing plenty fast with our existing tools. But I can't shake the feeling that we could we fail even faster if we optimized our IDEs and code editors to better visualize the effects of our changes in real time as we make them.

[advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position!

0
Your rating: None



This Q&A is part of a biweekly series of posts highlighting common questions encountered by technophiles and answered by users at Stack Exchange, a free, community-powered network of 80+ Q&A sites.

Nupul asks: A lot of my peers seem ready to dive in to learn "the next new thing"—lately Python, Ruby or PHP. But it seems that just "knowing" the language is futile. You also need to know the frameworks, learn their usage/APIs and become familiar with good implementation practices.

Read the rest of this article...

Read the comments on this post

0
Your rating: None