Archive for the ‘Uncategorized’ Category

The Ultimate Sophistication

Friday, August 6th, 2010

Note to self: from now on, if people ask me what I do for a living, this is what I should tell them.

“If you read the Apple’s first brochure, the headline was ‘Simplicity is the Ultimate Sophistication.’ What we meant by that was that when you first attack a problem it seems really simple because you don’t understand it. Then when you start to really understand it, you come up with these very complicated solutions because it’s really hairy. Most people stop there. But a few people keep burning the midnight oil and finally understand the underlying principles of the problem and come up with an elegantly simple solution for it. But very few people go the distance to get there.” –Steve Jobs (1984)

Startups vs. the “normal” world

Sunday, September 6th, 2009

By inverting this list [of startup company characteristics], we can get a portrait of the “normal” world. It’s populated by people who talk a lot with one another as they work slowly but harmoniously on conservative, expensive projects whose destinations are decided in advance, and who carefully adjust their manner to reflect their position in the hierarchy.

From What Kate Saw in Silicon Valley by Paul Graham.

Obvious truth

Sunday, August 30th, 2009

[Is it] obvious because it’s true, or true because it’s obvious[?]

A typical Seth Godin‘esque soundbite, but interesting when you think of it.

Maker’s schedule, manager’s schedule

Wednesday, July 29th, 2009

Let me start off by saying that I do not hate meetings for what they are (or at least should be), which is an opportunity to connect with other people (for whatever purpose). The problem with them is just that they tend to not get along very well with being creative (as in creating stuff).

Paul Graham, whom I admire greatly, totally understands what I am talking about:

There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.

(…)

But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.

From Maker’s Schedule, Manager’s Schedule.

The profession of programmer

Monday, July 27th, 2009

We’re still waiting for any programmer to become a household name. The social status of our profession is somewhere between busboy and dishwasher by the larger public, assumed to be boring, unintellectual (yes they think that), and generally meaningless. The frustration that regular people feel when wrestling with a Microsoft Word document that has collected some particularly nasty invisible formatting codes—this must be what programming is like.

(…)

As we know, it just isn’t like that. Most of us do work with passion to produce things of value and of beauty, that will please their users and last for years to come. The many little decisions that make up our days affect software products much more than the back scratching, eye clawing theatre of the conference room. And we know software better than anyone that doesn’t write it: what is possible now, what will be possible soon, and what really needs to happen for the next breakthrough. This passion for the how of computing, nerdy as it sounds, isn’t any more pathetic than tweeting a photo from an iPhone is pathetic. Computing is what humans do these days, and we make it possible.

From Codecraft by Nathan Hamblen.

What anyone who works with software developers should know

Saturday, July 25th, 2009

We all know that knowledge workers work best by getting into “flow”, also known as being “in the zone”, where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. This is when they get all of their productive work done. Writers, programmers, scientists, and even basketball players will tell you about being in the zone.

The trouble is, getting into “the zone” is not easy. When you try to measure it, it looks like it takes an average of 15 minutes to start working at maximum productivity. Sometimes, if you’re tired or have already done a lot of creative work that day, you just can’t get into the zone and you spend the rest of your work day fiddling around, reading the web, playing Tetris.

The other trouble is that it’s so easy to get knocked out of the zone. Noise, phone calls, going out for lunch, having to drive 5 minutes to Starbucks for coffee, and interruptions by coworkers — ESPECIALLY interruptions by coworkers — all knock you out of the zone. If you take a 1 minute interruption by a coworker asking you a question, and this knocks out your concentration enough that it takes you half an hour to get productive again, your overall productivity is in serious trouble. If you’re in a noisy bullpen environment like the type that caffinated dotcoms love to create, with marketing guys screaming on the phone next to programmers, your productivity will plunge as knowledge workers get interrupted time after time and never get into the zone.

With programmers, it’s especially hard. Productivity depends on being able to juggle a lot of little details in short term memory all at once. Any kind of interruption can cause these details to come crashing down. When you resume work, you can’t remember any of the details (like local variable names you were using, or where you were up to in implementing that search algorithm) and you have to keep looking these things up, which slows you down a lot until you get back up to speed.

From Where do These People Get Their (Unoriginal) Ideas? by Joel Spolsky.

Neatness is for historians

Wednesday, July 1st, 2009

Neatness is for historians. For a long time, all the markets for attention-based goods are going to be messy, which means that there are going to be huge opportunities for people (like you?) able to get that most precious asset (our attention) for free. At least for a while.

So true. Want to be a successful marketeer? Don’t expect too much from marketing school, but try and err, try and err, try and err.

From Malcolm is wrong by Seth Godin.

“Scalable,” a politician of a word

Saturday, June 27th, 2009

“Scalable” is a politician of a word. It has attractiveness to obtain solid backing from diverse factions- it has something to offer both the engineericans and the marketerists. At the same time it has the dexterity to mean different things to different people, so that the sales team can always argue that the competition’s product lacks “scalability”. The word even supports multiple mental images- you can think of soldiers scaling a wall or climbers scaling a mountain; a more correct image is that of scaling a picture to making it bigger. Even technology cynics can get behind the word “scalable”: if a technology is scalable, they would argue, that means it hasn’t been scaled.

From Is Semantic Web Technology Scalable? by Eric Hellman.

Simultaneous JavaScript unit testing and profiling using QUnit and FireUnit

Saturday, June 20th, 2009

This weekend I’ve been playing around with JavaScript unit testing. Since most of my JavaScript work is based off jQuery I quickly ended up at its QUnit test runner, which turned out to be pretty decent stuff.

That was not enough though. A while back I had stumbled upon John Resig’s work on FireUnit — a FireBug extension for unit testing — and I liked the idea. The main reason for my excitement was an opportunity to link FireUnit to FireBug’s JavaScript profiling features. That would make for an extremely powerful JavaScript testing and optimization tool. I even posted a comment with this idea to John’s article announcing FireUnit.

This weekend I jumped back on the FireUnit train to find out that my prayers have been answered! It turned out that FireUnit has been extended with some profiling goodness, exactly like I had imagined.

All that was needed now was an easy way of hooking in FireUnit and its profiling capabilities into existing QUnit test pages. Therefore I wrote a quick and dirty QUnit extension which does exactly that. You can simply load the plugin from any page and the QUnit tests on that page will be automatically run through FireUnit. On top of that, with just a few minor changes to the test code you can automatically run all units through FireBug’s profiler and get a nice ranking of their efficiency.

Check out the code and let me know what you think! (Disclaimer: it’s all très fraîche, so do not expect it to be flawless. Please contribute if you can!)

How to use

Behavior is configured using two setting variables:

  • QUnit.profiling (boolean)
    Set to true in order to enable profiling. This will only work for tests that supply their test code (first argument to ok, equals or same) as a function, rather than a value which is QUnit’s default behavior. Also you will need to have QUnit.testIsFunction set to true.
  • QUnit.testIsFunction (boolean)
    This settings enables you to plug in any existing QUnit test code and not run into problems. By setting it to false you signal the fact that no functions should be expected as test code. This also implies that profiling is not possible.

Make sure you set these variables after including QUnit (testrunner.js) but before including my plugin (qunit.fireunit+profiling.js).

Example:

<script type="text/javascript" src="jquery-latest.js"></script>
<script type="text/javascript" src="code-you-want-to-test.js"></script>
<script type="text/javascript" src="testrunner.js"></script>
<script type="text/javascript">

	jQuery(function() {

		QUnit.profiling = true;
		QUnit.testIsFunction = true;

	});

</script>
<script type="text/javascript" src="qunit.fireunit+profiling.js"></script>
<script type="text/javascript">

	jQuery(function() {

		// Your tests go here, for example:

		equals(function() {
			return "test value";
		}, "test value", "test message");

	});

</script>

Why you shouldn’t announce your plans

Wednesday, June 17th, 2009

Shouldn’t you announce your goals, so friends can support you?

Isn’t it good networking to tell people about your upcoming projects?

Doesn’t the “law of attraction” mean you should state your intention, and visualize the goal as already yours?

Nope.

Tests done since 1933 show that people who talk about their intentions are less likely to make them happen.

(…)

Once you’ve told people of your intentions, it gives you a “premature sense of completeness.”

You have “identity symbols” in your brain that make your self-image. Since both actions and talk create symbols in your brain, talking satisfies the brain enough that it “neglects the pursuit of further symbols.”

From Shut up! Announcing your plans makes you less motivated to accomplish them by Derek Sivers.