via Riding Rails - home by David on 6/8/10

RailsConf 2010 is underway and what better occasion to do the final stage of the Rails 3 beta program. We’re very pleased to announce Rails 3 beta 4, which we’ll be hammering on and tuning during RailsConf.

At the end of RailsConf, we’ll be putting out the release candidate. So if you’re at the conference, and even if you’re not, now is the time to give upgrading a chance or even starting a new app. We’re all responsible for making this release solid, please join the fun.

You can install the latest beta with gem install rails --pre

Since we’re so close to release now, it’s also a great pleasure to introduce the new Rails 3 screencast series by Gregg Pollack and EnvyLabs. They’ve done an awesome job putting together six episodes and more are coming. You can also read along in their great Rails 3 slides from the RailsConf tutorial.

I also gave a keynote on Rails 3 this morning at RailsConf, so you can enjoy the slides.

Let’s race to the finish line together.

via Inter-sections.net : by daniel on 2/23/09

This is part 5 of my series on the hyperbrain. If you’re just joining us, please have a look at parts 1, 2, 3 and 4 before continuing. If you’re wondering why there was such a gap between parts 1-4 and part 5, try this.

When it comes to immediate distraction, you should do your best to block it by shutting down unnecessary browsers and chat, letting people know that you’re busy, and making an effort to keep focused on the current task. This standard advice applies to everyone, hyperbrain or not. At the same time, you should keep tasks closed so that when you inevitably do get distracted, it won’t cause too much damage.

However, there is a different kind of distraction that works on a much slower cycle. Sometimes it can be mistaken for a general low of energy (and sometimes that’s what it is), but very often, if you’re a hyperbrain, you’ll get progressively bored of a previously enthusing piece of work and basically not feel like working on it anymore for a while.

Confusingly, immediate distractibility will hit hardest at that time too - you’re bored of your main task, so almost anything (even perhaps examining some strange defect on the wall to your right), seems more interesting than what you’re supposed to be doing. Not only that, but because you’re supposed to do that big task and you don’t find the energy to do it, you end up not doing any other useful tasks either (after all, those other tasks are lower priority).

I have a technique to deal with that too, though it’s not so easy to apply consistently. Yet even when applied only part of the time, it is still useful, in my experience.

#4 The butterfly approach

Remember, back in the first technique I said that you should accept and embrace your limitations, while figuring out how to work with them in the best way.

So, you feel like you don’t want to work on your most important task. The natural response, what society tells us is right, is: tough luck. Just take it like a man and soldier on. And if you can’t, you’re a weak-willed loser. That’s the advice that we get throughout our childhood, and somehow it perseveres through adulthood (“when the going gets tough, the tough get going”).

Unfortunately, this approach stinks for hyperbrains. When you’re excited and “into” a task, everything is easy and you can chop through a forest in a few hours. But when you’re not into the work, when you don’t care for it, it will take a disproportionate amount of effort to get even the smallest thing done. What’s more, because you don’t care for it, you won’t do it well - and it will show, to others, but, more importantly, to you. This creates a negative feedback cycle where you feel even less like doing that thing (because you don’t like to do things badly). Feeling less enthusiastic leads to further strenuous efforts to get the smallest thing done, which leads to more fudged work, which leads you to feel even more dispirited, etc.

You have to break that cycle.

Here’s my advice: when you don’t feel like doing something, don’t do it. Do something else. Like a butterfly, when a task has lost its nectar, flit over to another. Keep that up, happily flying away from (closed!) boring tasks onto other ones that you find exciting.

It’s a very rational choice. Option 1 is to spend 10 units of effort to get 1 unit of result in task A (that you’re supposed to do). Option 2 is to switch to task B (the one that’s looking so much more appealing right now), spend 1 unit of effort and get 10 units of result in task B. If you want to maximise results, you have to take option 2.

Of course, if task A is what you committed to do for someone else, this will have negative consequences. And the solution to that is: avoid making hard commitments that will hurt you in that way. We’ll get back to that a little later.

The important practices are that you should be working on several loose “clouds” of tasks (some related, some not) rather than focusing on a single direction, and that you should allow yourself to switch between those things without guilt.

Loose clouds

Notice I said loose clouds, not loose cloud. I used the plural because this won’t work if all your tasks are still sitting under the same umbrella (e.g. “stuff I’m doing to get the next release out”). There need to be vastly different sets of tasks in your available “task-space” - things ranging from writing a blog post to coding some new functionality, from doing a bit of business administration to planning your holidays. If you find yourself dispirited by coding, switching to a different coding task is unlikely to improve your mode.

Those tasks should all be “productive”, in the sense that you should feel like you’ve accomplished something when you get them done. This is important, because this is what will break the negative feedback cycle. If you don’t feel like coding something and instead you spend a few hours playing World of Warcraft, you won’t feel any better about yourself afterwards - you’ll feel worse. This will vary for you, but for me, “worthless” tasks include things like shopping (unless I’m buying something very specific), cooking lunch… interestingly, cleaning my office or the flat doesn’t feel like a worthless task - but rearranging it would be. You’ll have to figure out for yourself which task are productive. Generally, if it falls under the category of “time-fillers” or “busy-work”, it’s not a productive task.

You may not get back to task A for some time. Don’t feel bad about it. So long as you’re doing worthwhile things, that are accumulating value for you and make you feel productive, you will be working to negate the cycle of low energy. At some point, maybe the same day, or maybe a few days later, you’ll feel like working on task A again. Then, you’ll be able to chop through it at your best efficiency, and you’ll probably catch up with where you would have been if you had stuck with task A. But you’ll have the added bonus of having also done tasks B, C, D, E and F in the meantime, instead of agonising over a single task for days.

This, if you play it right, will make you appear fearsomely productive, as if you were working 20 hours a day - because every hour that you do work will be at full efficiency.

Uncommit

To make this work, it’s important to not be too committed to doing tasks by a certain date. You need to influence your environment so that people don’t care when exactly you got something done, just that it was done.

Of course, not all tasks have this flexibility, so you’ll have to make allowances for things which have to happen at a certain time, but those tend to be a minority in careers that are good value accumulators.

For tasks which don’t require you to commit to a deadline, don’t. Be vague if you need to be. If you tend to deliver great stuff, most people will accept some element of vagueness.

Some of your coworkers will really dislike the vagueness and you’ll have to manage them appropriately. The ideal way to do this, in my experience, is to under-promise and over-deliver. If people won’t take “I think I’ll get it done in the next couple of weeks or so” as an answer, give them a clearly defined answer that leaves you plenty of leeway. “I can work on this next week on Thursday, for sure.” But then, try to deliver it this week on Friday instead. If you do this often enough, in my experience, people will stop pressing you for deadlines, because they’ll be happy enough that you seem to get everything done quickly enough for them to be able to rely on you.

Important caveat: put bread on the table

There is a subtle but necessary addendum to this technique: you must keep in mind which of those activities put bread on your table. It’s great to follow your interests and be super-productive every day, but it’s not so good if you end up starving. So when choosing tasks you should always bias yourself towards tasks which are fun and productive and also earn your salary.

This is actually the hardest part of this technique… because it’s easy to turn a bias into an overriding order - and then you fall back into the mode where you feel compelled to slog through the task that you “must” do at the expense of all the others. And yet, at the same time, you have to pay attention to your bread-winner, because otherwise you won’t earn money. I don’t have any specific tips for how to do this - this is something you have to play by ear, I’m afraid.

In conclusion

Beating the cyclical highs and lows is not easy, but you can really help yourself by following this advice:

  • Have many unrelated “clouds” of tasks that you can switch to at a moment’s notice
  • When you feel like your energy for a specific “cloud” is gone, switch to a different one
  • Don’t feel guilty about doing this
  • Avoid committing to hard deadlines where possible so that you have maximum flexibility to switch

I hope you find this useful. As always, your comments are welcome.

via Inter-sections.net : by daniel on 9/11/08

This is part 4 of my series on the hyperbrain. If you’re just joining us, please have a look at parts 1, 2, and 3, before continuing.

Some jobs are “process jobs”. They consist mostly of taking some sort of input (phone calls, support tickets, orders, sales leads), performing some work on them, and providing some form of output (a satisfied customer, a filled order, a new sale). These jobs exist at all levels and in all kinds of businesses - from a small business support technician to a large business sales director). A lot of people (in fact, most people) have jobs that fit this description, are happy with that work, and do it brilliantly.

If you’re a hyperbrain, however, this kind of job is your worst nightmare. Why? Because it is a job you will always screw up.

Imagine you’re a manager in charge of a process. What do you care most about when hiring people to put in the roles you’ve identified? Predictability. You don’t care if the person handling the support tickets is capable of churning through 200 tickets on a really good day. You want to be sure that, on any given day, they’ll handle the 20 or so tickets that come in on average. Unfortunately, the hyperbrain does not work like that. It can produce exceptional results, but it is lousy at being consistent.

This is a weakness that, once again, can be worked around. Read on for this technique.

#3 The value accumulator

As long as your worth depends on your consistency, you can never win in the long term. You might fool yourself and others into thinking that “this time, it will be different,” but it won’t. In order to win, you need to change those rules. The question is, what do you change them to and how?

First, the “what”. The best way I can come up with to describe what you should be aiming for is a “value accumulator”. You need to engineer your own job so that people focus on what you’ve accomplished rather than what you’re going to accomplish. You need to create a system that accumulates value and then rewards you based on accumulated value.

This can be done both in choosing a career or profession, and in deciding how to perform and evolve your work.

It’s worth noting that there’s another technique hiding in this discussion - how to smooth your output, within any environment - but I won’t be covering it in this article.

Careers that accumulate value

I believe that most smart and capable people benefit from doing work that accumulates value. For the hyperbrain, however, it’s essential, if you want a fulfilling, successful career.

Most human activities “accumulate value” in some respect, since experience is a form of value. Some careers, however, are better at it than others. Let’s look at some examples.

Let’s consider writing as a first example. You can be a writer in many ways: working directly for a newspaper, being a freelance writer, writing a blog, writing books… How do these compare?

While the first two (newspaper and commercial freelance) accumulate value in the shape of experience and contacts, they do little to turn the output of your previous work (your backlist, as Seth Godin calls it) into something you can keep deriving benefit from. Freelancing is sometimes anonymous, and writing a great article today will not keep returning you benefits for the months to come, unless you’re also the publisher. You’ll have to keep writing great articles over and over again.

On the other hand, writing a blog is a pretty good value accumulator. It takes time for the value of a blog to be realised, but, for example, I published my most popular post so far in November last year, and yet it keeps bringing several hundred visitors a day each day, and keeps my PageRank up.

A book is an even better value accumulator. Once written, it can be marketed and sold over and over again for many years, and you keep the credit for “having written a book about X” for your whole life. Of course, book writing is a difficult way to make money, but if you write just one brilliant book that captures people’s imagination, you can keep deriving value out of that even if you did little of value for years after writing that book.

As I touched on in this earlier article, a product business is a great value accumulator. The market doesn’t care how you built your product, through great spurts of inspiration or a long, consistent effort. It only cares about how great your product is. And a product is a natural value accumulator, since work that you’ve done on it remains there pretty much forever.

On the other hand, a services business might not be ideal for a hyperbrain, since clients naturally care about the work you’re doing for them now, rather than the work you did for other clients in the past. So if you’re running a service business, you might want to consider turning it into a product business instead.

Corporate jobs

In most corporate jobs, the high-level equation is not in your favour, since employers usually care more about your future output than your past achievements. However, even there, some jobs at least provide past achievements, whereas others are entirely process-focused.

Consider an IT support job, for instance. By default, it has no past achievements that you can point at. Your performance is mostly measured by the consistency with which you answer tickets. If you stop answering tickets for a week, you’ll take a very serious hit.

A development job, on the other hand, has natural “past achievements” in the form of features built, for example. A one-week lull in productivity won’t make anyone happy about you, but it won’t destroy you either, and if you can keep people focused on what you’ve done rather than what you were supposed to do, you can survive those lulls unscathed.

You should seek a job that naturally lends itself to accumulating past achievements that people care about, but even in the case where it doesn’t, you can still tweak the work in your favour, and slowly transform a process job into a project one. Read on to find out some ways to do that.

Accumulating value within a process job

Within a job, to make up for your inconsistency, you want to create value accumulators and then keep people’s attention firmly on those.

The best device for that is a “project”.

A project is a set of tasks that achieve a definite goal within a definite time. A project can be finished. This is important, because it means that once you’ve finished a project, it remains in your “achievement history” no matter what else you do (or don’t do) afterwards. If you wrote the competitor analysis report, you’ve done it, and no one can take the credit away from you. However, if you processed all the orders reliably for a couple of months and then go through a couple of weeks when you don’t process any, the credit for “processing orders well” will vanish immediately.

For a hyperbrain, it’s useful to structure every bit of work as a project. Even if you’re in a process-oriented environment, find projects to get involved in. If there aren’t any, create them.

You can create projects by looking for improvements that you could make to the process, and implement those improvements as projects. You can also create projects by packaging processes into chunks. If you can ensure that your work on a process has an end-point, it can be completed and put aside.

Find the projects, finish them, and then keep people’s eyes on the projects.

After you finish a project, keep other people aware of it. Blow your own trumpet, so to speak. Every once in a while, perform small additions to projects that you already completed, to give you an excuse to re-release them and keep them fresh in everyone’s mind. Those additions shouldn’t be planned, they should be things you do spontaneously.

As you accumulate more past projects and keep people aware of them, your credit will go up, since everyone will then be aware that you’ve done a lot of things, rather than seeing only the bits where you failed to do what you said.

Conclusion

In any work environment, look for ways that you can create value accumulators. Steer yourself away from work that’s purely process based. Ideally, find a career that allows you to accumulate value for yourself rather than for others.

I’ve been pretty busy this week, so haven’t had the time to write part 5 yet, but there’ll be another hyperbrain article coming next week. Keep your eyes peeled!

via Inter-sections.net : by daniel on 9/5/08

This is the third article in my series on the hyperbrain. If you haven’t read them yet, you might want to look at parts 1 and 2 first.

Subjectively, I think the greatest challenge about having a hyperbrain is distractibility. If not handled effectively, it can make you feel really useless. I’ve often sat in front of my computer, knowing that I’m supposed to be getting on with some piece of work that’s half done, and not been able to focus on it (whilst remaining quite capable of focusing on dozens of blogs and other wastes of time). Learning to work with your distractibility can make an order of magnitude of difference in your productivity.

Like a game

Have you ever played a computer game where your character could die at any point? First person shooters (Doom, Quake…) make for an excellent analogy to distractibility. What do you do when you have to complete difficult, complex, sometimes tedious tasks and your progress can be lost at any point?

A long, long time ago, there was nothing you could do. You just played the game until you died. A few palliatives were invented to try and deal with that, and eventually, they culminated into the ideal solution: saved games. Nowadays, if you’re playing a game like Quake, you can save whenever you’ve done something that was hard or lengthy. Then, if you happen to die in the next minute, you can reload from the saved game. If you save every minute, you can minimise the effects of dying to, at most, translating into one minute of lost time.

If you accept the fact that you are easily distracted (and, after years of fighting it, it’s something I’ve come to accept rather than fight), you could consider distraction to be similar to dying in a computer game. Accepting your own distractibility means that whenever you’re doing any work, you have to accept that you might be distracted and start doing something else for two hours, two days, or even two weeks.

So what can you do to mitigate this sword of Damocles? You need some sort of real-world equivalent of saved games.

#2 Keep tasks closed

A task is closed when you can ignore it for an indeterminate amount of time and there will be no direct negative consequences from doing so (other than the fact that this specific task won’t get done), and when it isn’t left in such a state that you will struggle to pick it up again.

A programming task (e.g. a refactoring) is closed when you can commit and push all your changes into the main codebase and not (knowingly) break the application.

A writing task (e.g. writing a book) is closed when you’ve finished a self-contained section or sub-section and can leave it without having to spend 20 minutes to re-immerse yourself in the subject to continue writing.

A managerial task (e.g. setting up a weekly meeting) is closed when no one is expecting anything else from you on that task.

A closed task is in a state of rest. It can be safely ignored while you do something more important. It’s like saving the game after killing all the monsters in the room, but before walking into the next room. An open task is either when you haven’t saved the game recently, or you’ve saved it in the middle of a fight.

Open tasks are risky

There are many risks with abandoning open tasks:

  1. They can prevent other people from getting on with their own tasks (which breeds resentment against you even though you’re working hard and enthusiastically);
  2. You might have been able to work on the task today on an inspired high, but you might be on the low for the next week. If you leave open a big, complex task, and go do something else, you may be incapable of picking it up productively again for some time;
  3. As long as the task is open, it will clutter your mind and your ability to do other things will be diminished. Keeping tasks open uses up your mental capacity and impacts every other task that you’re involved in;
  4. By the time you are finally able to complete the task, someone else might have rendered it irrelevant (if you’re working in a fast-moving environment);
  5. Say you finally complete the task and have taken five or ten times longer than expected; in hindsight, others may think it wasn’t worth spending that long on it - this will rob you of the praise that you need and expect when you complete something difficult.

And so on.

The key approach to surviving distractibility is to keep almost all tasks closed all the time. Only one task should ever be open at any one time, and it should only ever be open for a short amount of time. How long depends on your work. For programming, I like to make that time fifteen minutes. At least every fifteen minutes, I should be able to save all my changes and commit them to the central repository without any ill effects.

Some people present this advice as “you should not multi-task”, but that phrasing is not so useful to the hyperbrain. The reason is that the definition of a “task” is stretchy. A major restructuring of a codebase could be considered a single task, even though it is really composed of dozens or even hundreds of small tasks.

For the hyperbrain, the definition of single-tasking has to be time-based. You need to set yourself a limit for how long you will work on something before closing it.

If you don’t think you can close the task within that time, don’t do it.

Rethink the task until you can figure out a way to close it within a short time. If you can’t think of a way to do that, don’t start the task. You wouldn’t jump out of a plane before finding the parachute - don’t jump on a task without figuring out how to chip off a small chunk.

“Don’t multi-task” is correct advice, but not useful to the hyperbrain. Instead, think of it as: “Don’t do anything that you can’t close within fifteen minutes”.

This doesn’t mean that you need to break down the whole task into fifteen-minute chunks before starting. Don’t even try doing that, you’ll never finish. Instead, break off one chunk at a time. Ask yourself “what’s the next thing I can do that will help me get this task done, but that can finish in less than fifteen minutes?” Make sure that the next thing you work on can be finished in a short sprint. Each time you finish a sprint, break off another small chunk of the remaining work and do that bit.

Also, don’t feel that it’s a bad thing if it takes much less than fifteen minutes to complete a task. Some of my most productive stretches of work were long collections of 1-minute chunks.

What if you can’t seem to finish it?

What if you start a task that you thought could be finished within fifteen minutes, and you find yourself half an hour into it without any clear endpoint yet? This can easily happen with complex work, such as programming - after all, you don’t really know exactly what you’re going to do until you start doing it.

If that happens, you need to roll back to the previous closed state (discard your changes and reload the latest good version). Take the game metaphor: if you were playing your game and suddenly you find yourself dead? You simply reload. The unfortunate difference between a game like Doom and real work is that work doesn’t make it so clear when you’re dead. You can keep going like a zombie for a long time before you realise that you died three hours ago. And because, as a hyperbrain, you’re fairly optimistic about your own abilities, you keep soldiering on, thinking it will get better soon. Another way to phrase this advice would be: “When you’re in a hole, stop digging!” It won’t get better. You’ll just end up even deeper.

With work, it’s often hard to figure out whether you’ve lost your way and should back out, or whether it’s just a hard problem that you’re on the verge of cracking. Fortunately, there is an absolute, objective measure you can use to determine whether you should back out: time.

This is not a huge effort of discipline. It does take a little mental effort to “give up” on fifteen or thirty minutes of work that you’ve just done, and I’ll grant you that’s sometimes hard to accept. But if you can apply this simple discipline, you will see a several-fold improvement in your productivity (and that will make you happy and drown out any sorrow that you may have experienced when abandoning a small dead chunk of work).

Conclusion

You don’t need to be a super-hero to adapt to distraction, just to follow a handful of simple rules:

  1. Reduce the distractions in your environment as much as possible, but accept the fact that you will probably get distracted anyway, and be prepared for it
  2. Never leave a task open for more than X minutes (fifteen in my case, for programming tasks)
  3. Never open more than one task at a time
  4. If you are working on a task and it’s taking longer than your cut-off point, roll it back and try again from a different angle

I hope you’ve found this article helpful. Feedback is, as always most welcome.

tag:www.inter-sections.net:Article60 2008-09-03T11:32:47+00:00 2008-09-03T15:30:13+00:00 daniel Technology recruitment in an early start-up

So, you have an idea for a startup, but need a tech guy to build it… how should you find him?

Last week I ripped into a job advert with, I hope, some good comical results. Some people asked, more specifically, what I would do in Redline’s place (Redline was the company that produced the advert). How do you make that first technical hire?

Of course, you want the company to sound personable and friendly, and that was probably the noble impulse that drove the poor anonymous job ad writer to write that awful ad. A formal, stiff job ad is indeed not going to attract good early employees - let alone a start-up CTO, which I believe is what they were trying to hire in this case.

First of all, let’s define our terms a little. Everyone has different terms for these things, but there’s two general stages to recruitment of technical guys in a really early start-up (one with fewer than 10 techs). Please note that when a company grows beyond that size, things shift and evolve. This applies to very small technology start-ups only and, as ever in the start-up world, there are and will always be exceptions.

So, you have an idea for a startup, but need a tech guy to build it… how should you find him?

Last week I ripped into a job advert with, I hope, some good comical results. Some people asked, more specifically, what I would do in Redline’s place (Redline was the company that produced the advert). How do you make that first technical hire?

Of course, you want the company to sound personable and friendly, and that was probably the noble impulse that drove the poor anonymous job ad writer to write that awful ad. A formal, stiff job ad is indeed not going to attract good early employees - let alone a start-up CTO, which I believe is what they were trying to hire in this case.

First of all, let’s define our terms a little. Everyone has different terms for these things, but there’s two general stages to recruitment of technical guys in a really early start-up (one with fewer than 10 techs). Please note that when a company grows beyond that size, things shift and evolve. This applies to very small technology start-ups only and, as ever in the start-up world, there are and will always be exceptions.

The CTO

The first person that needs to be recruited is what I call variously the start-up CTO, the technology director, or the technical co-founder. For a technology start-up whose bread and butter will be developing a technical product that people will want to pay money for, this “hire” is the most important that the founder can make in the entire history of the company. Here, I’m assuming that the first founder is non-technical or not technically strong enough.

Strong enough to do what? Well, to develop the whole product by himself! Wait a second… can anyone develop a whole product by themselves? It depends on the product. I’ve done it. My best friend is doing it now on his own start-up. My current start-up employs only two people to build our product. So yes, it is possible, if you’re using the right technologies and if you’re building the kind of product that is amenable to being built by a very small team.

You might decide to hire more than just this guy, even though he can build the whole product by himself, in order to speed things up a little. After all, if your cofounder can write the whole product by himself, but it will take him 3 years to get to version 1, that’s probably not good enough. But you won’t be struggling to hire his team - he’s more than capable of doing that himself. Ah yes, that’s another thing a start-up CTO needs to be capable of: finding and attracting other technically talented team members to joint the start-up.

What else? Well, he also needs to have a good head for business, to understand where the start-up is going and be able to pick the technologies to meet those goals. He needs to be capable of working with maniacal productivity despite the chaotic, highly constrained environment of an early start-up. He needs to have enough managerial skills to manage the early start-up team once it comes into existence. What you (as a business-minded founder) might be doing for the business, i.e. pulling the entire thing from a mere idea into existence out of your sweat and determination, he needs to do for the product.

It’s worth emphasizing here: I’m not saying this guy will build the whole product by himself, only that he needs to be able to do so if need be.

He’s a One-Man IT Department. He’s the person on top of which you’ll build your company. He’s not a rock star. He’s a rock, and on this rock you can build your company.

The early employees

Early (technical) employees also need to be very competent, flexible and driven, but less so than the technical co-founder. They can specialise a bit more, and can focus on getting things done without quite so many business distractions. It will be the CTO’s job to figure out what technical skills are needed to continue to grow the start-up, once there’s budget for other people, and to find and hire the right people to fill those holes.

Early employees do need to be willing to have a go at whatever needs to be done at the moment. If it’s network administration that you need to do today, so be it. But they don’t need to bring all those skills to the job - it’s something they can learn from their colleagues, from howto’s downloaded from the web, books, etc.

As a start-up CTO looking for early employees, you should look not for someone who can do your job, but for someone who is reasonably well rounded and flexible, but more importantly is better than you in one of the key areas that really matter to the start-up.

Where to find them

So, where do you find these rare and wond’rous creatures? Let’s start with the CTO. Most important hire in the company. Defines the product that you will build. Is a job site a good place to look for one of those?

Of course not. You find technical co-founders the same way you find any co-founder: through personal relationships. If you want to start a technology start-up and you’re not technical, you need to locate your technical co-founder amongst your network of friends, and if there isn’t one there, you need to expand that network until there is. Until you have found your technical cofounder, your company cannot be started (at least not with any reasonable chance of success). Maybe there are even better ways of finding co-founders, but I don’t know them. Paul Graham’s experience seems to agree: “Usually the founders have been friends for at least a year before starting the company.”

I’m sorry if you were expecting a simple, easy answer, like “Go on find-a-CTO.com”. In my experience, the kind of people you want as technical cofounders are either doing it already, or productively employed. Finding your technical co-founder is hard work, but the pay-back from this work is huge.

What about early employees? Well, those are a little easier. At least, you can let your CTO do most of that job. He or she should have the network to find the people that he wants to hire. There, as well, I’d recommend networking as the primary means of finding great people to work with. However, for early employees, in some rare cases, you might use a carefully constructed job ad to fish for possible hires. Bear in mind, though, that at this stage, it’s usually better not to hire anyone than to hire the wrong person.

Taking on a cofounder: final note

One last note on cofounders: you can’t treat them as employees. They’re not employees, they’re cofounders. You want them to feel that it’s their company, and to do that, you have to give them equity - not options, not promises of options, but actual founder’s equity. Don’t feel like you’re giving stuff away here. If you’ve got the right person for the job, ensuring that they feel ownership of the company will ensure that your share is worth something. It’s better to own 70 or 80 or even 51% of something than 100% of nothing.

I hope you’ve found this post helpful! Comments are, as always, welcome.

tag:www.inter-sections.net:Article59 2008-09-01T11:30:01+00:00 2008-09-01T13:02:10+00:00 daniel Hyperbrain Owner's Manual - 2. Accept and reject your limitations

This article follows a previous article. It’s part of a series of yet undefined length. If you haven’t read the first instalment yet, it might be worth going back and reading it.

This is addressed mainly to people who recognise themselves in the description of the hyperbrain, although it may be of interest to others. When you count up all the different ways in which your hyperbrain differs from the average, you might be tempted to think you’re not normal. Well, it’s true, you’re not. You’re different from the norm, but that can be a good thing. After all, you can’t be normal and expect abnormal results. The focus of these articles is to make you more aware of how you can deal with those differences, counteract your limitations, and build on your strengths, to achieve what you’re capable of.

So what are you capable of? Well, you can do anything you want (that’s the good news). But in order to do those things, you need to learn to work with your hyperbrain, otherwise you will constantly fail in public and humiliating ways at the worst moments (usually, on the cusp of victory, at least in my experience). And that will hurt you more than the average person, because you are far more sensitive to negative feedback than you’d care to admit. Let’s look at the first practical step to take to improve your chances of success.

The first step to success with a hyperbrain is to both accept your limitations and reject them.

This article follows a previous article. It’s part of a series of yet undefined length. If you haven’t read the first instalment yet, it might be worth going back and reading it.

This is addressed mainly to people who recognise themselves in the description of the hyperbrain, although it may be of interest to others. When you count up all the different ways in which your hyperbrain differs from the average, you might be tempted to think you’re not normal. Well, it’s true, you’re not. You’re different from the norm, but that can be a good thing. After all, you can’t be normal and expect abnormal results. The focus of these articles is to make you more aware of how you can deal with those differences, counteract your limitations, and build on your strengths, to achieve what you’re capable of.

So what are you capable of? Well, you can do anything you want (that’s the good news). But in order to do those things, you need to learn to work with your hyperbrain, otherwise you will constantly fail in public and humiliating ways at the worst moments (usually, on the cusp of victory, at least in my experience). And that will hurt you more than the average person, because you are far more sensitive to negative feedback than you’d care to admit. Let’s look at the first practical step to take to improve your chances of success.

The first step to success with a hyperbrain is to both accept your limitations and reject them.

Accept your limitations

You are not built for consistency. Putting yourself in situations which require you to provide a constant output, and which hurt you the moment you fail to do so, is a recipe for disaster for you. Yet you might be tempted to set up just such a system in order to generate motivation. To succeed, however, you need to engineer your environment to focus on what you’ve achieved rather than what you’ve planned to achieve.

Your focus can shift radically in an instant. This means you cannot rely on continued focus in a period of time, so, to succeed, you need to structure your (focused) work in a way that allows you to abandon it at short notice without downside.

You crave validation from yourself. If you can’t feel that you’re doing something really worthwhile, your productivity will shoot down to a hundredth of what it might otherwise be. You need to ensure your work is always presented in a way that makes you feel it’s worthwhile.

You crave validation from from other people, too. Most people like a pat on the back, but without that pat, you can’t go on. Putting yourself in situations where no one really cares about what you’re doing will demoralise you fairly quickly, unless you can come up with elaborate rationalisations for why they don’t care yet (e.g. secret projects). So, paradoxically, to succeed, you actually need to be on the front lines, where it’s most visible and most dangerous to fail, because that’s where you’ll feel most energetic and driven.

When you’re on a high, you feel you can take on the world. And you could - if only you could maintain that high. But you can’t. So, on a high, you actually do take on the world, and then the world chews you up and spits you by the side of the road. To succeed, you need to moderate that eagerness to ensure you don’t set yourself up for failure.

You get involved in too many things. All successful people do that to an extent, but you’re really pushing the boundaries. At any given time, you’re reading 5 books, pursuing 10 pet projects, and working on 15 things - and you constantly shift between them. To succeed, you need to structure your environment to allow you to shift between those things without negative side-effects.

You are extremely sensitive to negative criticism. Most people dislike being told they’re wrong, but the wrong bit of criticism from the wrong person can shut down something that you genuinely cared about permanently. To succeed, you need to develop a healthy scepticism for people’s negative criticisms (if only because success is always, inevitably, accompanied by harsh negative criticism from people who are mean, jealous, in a bad mood, or just simply disagree in overly harsh terms).

You have a strong tendency to martyrdom and self-victimisation. How better can you gain other people’s positive feedback than by sacrificing yourself? If only I had the support I needed, I could do so well! To succeed, continue reading.

#1: Reject your limitations

One of the hyperbrain’s tendencies is self-victimisation. Well, that’s not unique to the hyperbrain. Many people feel misunderstood, although the craving for external validation makes it particularly acute in this type of mind, because the only way to fulfil that craving is to succeed, and you cannot succeed while you feel the odds are stacked against you. This self-victimisation is crippling, though. It’s oh so easy to slip into thinking that you are doomed to fail at everything you try, because you’re just that way, and there’s always some bit of the “support system” that’s missing (tip: it’s a catch-22 - you will only be able to build a full support system when you’ve already succeeded).

If you take only one thing from these articles, take this:

Your limitations are not an excuse for failure.

You should never throw up your hands and accept that you will fail because of your limitations. Analyse past failures in terms of your limitations to see how you can make up for them, but never accept defeat as a given. This advice goes for anyone, really, but it is especially important for hyperbrains because of these self-victimisation tendencies.

Your environment is not an excuse for failure.

You may try to dodge the above advice by saying something along the lines of: “Well, I can deal with my limitations, but my environment just doesn’t work with my personality.” Bullshit. You can succeed in any environment. The match (or mismatch) between your limitations and your environment is just a puzzle to be solved. In later articles, I’m going to drill down into specific techniques for how to counteract those limitations without taking away from your strengths, and you’ll see that almost no environment is incompatible with the hyperbrain, so long as you know how to handle yourself. You are the sole factor in whether you succeed or fail.

You don’t need to sacrifice yourself in order for others to succeed.

People don’t need you as much as you feel they do. How many times have you been in a situation where you thought the project couldn’t run without you, and you got moved somewhere else anyway, and the project still went on? Because of your ability to pick up many different skills, you’re involved in everything, so it’s easy to end up feeling you’re indispensable. Then, you feel that you can’t possibly go and do what you want because everyone is depending on you. It’s easy to turn this into another excuse for not achieving your potential. Don’t let it be so. People don’t need you as much as you think they do, and they will not appreciate your sacrifice at all - so don’t do it.

Unless you accept this key point, that the key to success lies within you, that there is no valid excuse for not realising your potential, then the rest of my advice will be worthless. I’ve started with this high-level “tip”, even though it really applies to everyone (not just hyperbrains) because it is so very important.

In part 3, coming later this week, I’ll present my most important approach for how to deal with distractibility and arrange your work to survive the hyperbrain’s attention deficit without losing out on its ability for extraordinary focus (no, it doesn’t involve some fancy variation on GTD).

tag:www.inter-sections.net:Article57 2008-08-27T13:15:15+00:00 2008-09-01T12:00:23+00:00 daniel How not to write a job advert

Recently, I found a Craigslist job advert that made me chuckle. It seems to manage to do almost everything wrong, from the point of view of recruiting the kind of person it appears to be targeting.

So, in the spirit of improving the web, here’s my blow-by-blow description of all (or most of) what’s wrong with this job ad.

Recently, I found a Craigslist job advert that made me chuckle. It seems to manage to do almost everything wrong, from the point of view of recruiting the kind of person it appears to be targeting.

So, in the spirit of improving the web, here’s my blow-by-blow description of all (or most of) what’s wrong with this job ad.

Here’s the advert, first, in case it’s taken down:

Senior Rails Developer (Toronto)

Reply to: jobs@redwirenation.com [?]
Date: 2008-08-26, 9:12PM EDT


Working Role Title: Senior Rails Developer 

Why People Want To Work for Us: RedWire Employees Are Rockstars 


Enabling Entrepreneurs To Connect on a Global Scale 
As far as missions go, ours is pretty cool. How many people get to say their job is to help others be successful? 

Innovating at Warp 9 
We are a small company, but we are driven to change the world. Our reason for being is to help entrepreneurs realize their ambitions. We are innovative, relevant and user-friendly, and we use these qualities to equip business owners with the tools they need for success. 

Fun-zilla 
Working for RedWire means being passionate and creative. We want awesome people to work with who will be contributing members of our team of rockstars. 

The top three reasons why working at RedWire rocks: 

1) You get to do good. People helping people—it’s a beautiful thing. 
2) Brainastics, whiteboards, candy and lots of coffee. Sometimes we have to remind our employees to go home. 
3) Flexible work hours. We don’t do “9 to 5”. 
Nuff said. 

We realize that a start-up environment doesn’t appeal to everybody, but if it works for you, then, please, read on. 


Current Needs: 

¼ Network Engineer 
+ ¼ Electrical Engineer 
+ 3⁄8 Senior Open Source Software Developer 
+ 1⁄8Mathematician 
= 1 RedWire Senior Developer 

We are looking for an in-house doer-thinker-fixer-betterer whose superpower is to fulfill all the functions of an IT Department. We need an autonomous and resourceful guru to join us in our quest and manage all things IT. You must be ridiculously passionate about the web, love the idea of working in a start-up, enjoy variety in your day-to-day and be able to handle the stress of being the go-to resource. 

Role Overview: 

This is a pivotal role for an ambitious, highly enthusiastic developer who’s excited at the thought of working in a fast-paced, high-growth web start-up. 

In this position, you will demonstrate your mental prowess as you coordinate a diverse flow of projects and initiatives. 

You will be responsible for: 

- Web application development 
- Network administration 
- Information storage 
- Network functionality 

In addition, you will also be responsible for helping set up email distribution, as well as any other relevant technically related projects as they arise. 

We are looking for a goal-oriented, naturally eager person who can work effectively and efficiently under tight deadlines and who is able to manage multiple projects at once. 

Qualifications:
• Provable guru status and devoteeism of Ruby on Rails with experience actually deploying applications 
• Strong experience with MySQL, version 5+ and beyond 
• Background in developing and optimizing GNU/Linux, *nix, and *BSD platforms for mission critical production environments 
• Familiar with network infrastructure and design concepts for small networks (25 machines). 
• Proven experience in designing security-hardened web applications, using open cryptographic standards 
• Familiarity with hardware prognostics and normal accident theory 
• Expertise in open-source programs and development 
• Familiarity with content versioning systems (e.g., Hg, SVN, CVS) 
• Experience breaking stuff 
• Experience fixing what you’ve broken 

If you are the personification of our long-winded wish list, then we’d celebrate your email’s alerting us to your existence. Interested potential rockstars should send their résumé to jobs@redwirenation.com. 

Right. *cracks knuckles* Let’s get started, shall we?

Rockstars helping people for brainastical whiteboard candies

The first problem: Why people want to work for us: Redwire employees are rockstars.

Really? Ok, I’ll sign up, but I want to get some free tickets to their concerts. Many employers still feel like calling future employees rock stars or ninjas is going to attract better developers. Here’s some news for you: most of the great developers you’re interested in can’t stand the term “rockstar programmer” (or ninja, or whatever alternative you may care to come up with).

Next: How many people get to say their job is to help others be successful?

Well, let’s see… off the top of my head, every single employee in the world? By definition, employees help others be successful. That’s what “having a job” means. Most people who join start-ups do it because they’d also like to help themselves be successful somewhere along the way, or because the work is more interesting. In any case, if you want to excite start-up developers, you’re gonna need a better “mission statement” than that (ideally, just scrap the mission statement altogether).

Fun-zilla

Well, nothing says fun like Fun-zilla, right? Who are you trying to hire? 10 year olds?

“We want awesome people to work with who will be contributing members of our team of rockstars.”

*puke*

Top three reasons:

1) You get to do good. People helping people—it’s a beautiful thing.

Oh puh-lease, I’m getting all teary-eyed already. Of course. How could I not see it? Tell you what, it’s such a beautiful thing, I’ll work for free too. Every start-up believes their goal is the best, the most worthwhile of them all, but your job in a recruitment ad is to convince other people who haven’t drunk the kool-aid that that’s so. This kind of vague nonsense isn’t going to help.

2) Brainastics, whiteboards, candy and lots of coffee. Sometimes we have to remind our employees to go home.

Translation: long hours, no concept of work/life balance. That’s acceptable for a start-up (though perhaps it shouldn’t be), it’s understood that you may work long hours on a start-up. But you shouldn’t brandish that about as a key selling point for your company, much in the same way that someone who’s changing jobs might be doing so because their current job sucks, but they probably shouldn’t say it outright in the interview. And since when are whiteboards a perk?? What’s next? “Our state-of-the-art office premises include a quality toilet seat”?

3) Flexible work hours. We don’t do “9 to 5
Nuff said.”

Normally, that would be fine, but in conjunction with the previous statement, it’s highly suspicious. “We don’t do 9 to 5” could just as easily mean “We do 10 to 10”, in this context. Nope, not “enough said” - more detail would have been preferable.

One cup of flour, two cups of milk, two eggs

1/4 Network Engineer
+ 1/4 Electrical Engineer
+ 3/8 Senior Open Source Software Developer
+ 1/8 Mathematician
= 1 RedWire Senior Developer

Oh boy. Maybe add another 1/32 janitor while they’re at it? What the heck is up with the /8 fractions anyway?

We are looking for an in-house doer-thinker-fixer-betterer whose superpower is to fulfill all the functions of an IT Department. We need an autonomous and resourceful guru to join us in our quest and manage all things IT.

Ok… so, what emerges here, is they’re looking for a CTO. That’s what a CTO is - a one-man IT department. But either they can’t afford one, or they haven’t figured out that’s what they’re looking for, or they don’t know that hiring a CTO in a company like that is the most important hiring decision in the whole history of their company (and should be achieved through intense networking, not through free job ads). Or perhaps, more likely, they just don’t really have a clue what they want, beyond the fact that it’s someone who knows stuff about IT.

In this position, you will demonstrate your mental prowess as you coordinate a diverse flow of projects and initiatives.

You will be everyone’s IT bitch.

…ambitious, highly enthusiastic…

And you will enjoy it!

Responsibilabilities and Qualifimications

You will be responsible for:
- Web application development
- Network administration
- Information storage
- Network functionality

Wow is that it. Oh wait, you’re not finished. Please continue.

In addition, you will also be responsible for helping set up email distribution, as well as any other relevant technically related projects as they arise.

Didn’t we cover this already? If you want someone with that breadth of skills, you’re hiring your CTO cofounder. And you better give them equity - lots of it. And you will never find them via a craigslist job ad. Also, what the heck is “Information storage”? Does this “Senior Rails Developer” also have to manage the shared drive, perhaps?

Provable guru status and devoteeism of Ruby on Rails with experience actually deploying applications

Devoteeism? Guru status? Come on, I need some lines that I can make fun of. This is so self-contained, I can’t possibly make it any more ridiculous than it already is.

Proven experience in designing security-hardened web applications, using open cryptographic standards

What does that even mean? My guess is, it translates to “is capable of setting up an SSL certificate on apache”.

Familiarity with content versioning systems (e.g., Hg, SVN, CVS)

Is it even possible to be a “Ruby guru” and not be “familiar” with source control? Another hint that the person who wrote this job ad doesn’t know what they’re talking about.

Experience breaking stuff
Experience fixing what you’ve broken

It’s always a good thing to let your company’s personality show through your ad. Well, not always, I guess. Not in this case, for example. After this litany of unintentionally awful propositions, this “joke” doesn’t really go down well.

In conclusion

Now, it’s possible that actually, Red Wire is a perfectly fine company, and they just happened to get someone’s friends sister to write and post up the job ad because they were too busy and, heck, craigslist is free anyway. But this is a terrible impression to make to prospective start-up employees and, if they indeed lack a CTO, it’s no way to hire one.

If you’re in a position to hire technical people for a start-up, try not to make quite so many mistakes.

tag:www.inter-sections.net:Article56 2008-08-27T00:38:09+00:00 2008-08-29T12:02:35+00:00 daniel Blizzard should be ashamed

Recent news has pointed out that gold farming in China has become a $500m industry.

Blizzard should be ashamed.

We have many challenges in the world today. Entertaining people (as Blizzard does with their main products) is a worthwhile activity for a business. Hard-working people do need it, and even though there are some extreme cases of “entertainment abuse” (similar, in many ways, to drugs abuse), the abuses of the few should not limit the many from enjoying a perfectly healthy, if somewhat fruitless, activity.

However, gold farming is not entertainment. Gold farming is an entirely sterile activity. It produces nothing other than a transfer of wealth from one part of the world to another. The “gold” that is being farmed is purely artificial. It represents no value creation whatsoever. It is merely a symbol of time that has been wasted on a pursuit that is designed to be entertaining. Each piece of gold farmed represents a small amount of wasted productivity for the human race. In aggregate, the $500m gold farming industry represents $500m of wasted human productivity.

Moreover, Blizzard could very easily stop this trade, by creating an official gold market where people can exchange dollars for gold. There would still remain some market for rare items, but those are necessarily less fungible than gold coins, and so would at least greatly decrease the $500m black hole.

If anything, Blizzard should see its own self-interest here: if it can get even a 10% slice of this $500m market (and there’s little reason to think that it couldn’t get 100%), that would represent $50m - not an amount to be sneered at. From a business sense, Blizzard should be ashamed not to have opened up a gold market yet.

Recent news has pointed out that gold farming in China has become a $500m industry.

Blizzard should be ashamed.

We have many challenges in the world today. Entertaining people (as Blizzard does with their main products) is a worthwhile activity for a business. Hard-working people do need it, and even though there are some extreme cases of “entertainment abuse” (similar, in many ways, to drugs abuse), the abuses of the few should not limit the many from enjoying a perfectly healthy, if somewhat fruitless, activity.

However, gold farming is not entertainment. Gold farming is an entirely sterile activity. It produces nothing other than a transfer of wealth from one part of the world to another. The “gold” that is being farmed is purely artificial. It represents no value creation whatsoever. It is merely a symbol of time that has been wasted on a pursuit that is designed to be entertaining. Each piece of gold farmed represents a small amount of wasted productivity for the human race. In aggregate, the $500m gold farming industry represents $500m of wasted human productivity.

Moreover, Blizzard could very easily stop this trade, by creating an official gold market where people can exchange dollars for gold. There would still remain some market for rare items, but those are necessarily less fungible than gold coins, and so would at least greatly decrease the $500m black hole.

If anything, Blizzard should see its own self-interest here: if it can get even a 10% slice of this $500m market (and there’s little reason to think that it couldn’t get 100%), that would represent $50m - not an amount to be sneered at. From a business sense, Blizzard should be ashamed not to have opened up a gold market yet.

via Inter-sections.net : by daniel on 9/1/08

This article follows a previous article. It’s part of a series of yet undefined length. If you haven’t read the first instalment yet, it might be worth going back and reading it.

This is addressed mainly to people who recognise themselves in the description of the hyperbrain, although it may be of interest to others. When you count up all the different ways in which your hyperbrain differs from the average, you might be tempted to think you’re not normal. Well, it’s true, you’re not. You’re different from the norm, but that can be a good thing. After all, you can’t be normal and expect abnormal results. The focus of these articles is to make you more aware of how you can deal with those differences, counteract your limitations, and build on your strengths, to achieve what you’re capable of.

So what are you capable of? Well, you can do anything you want (that’s the good news). But in order to do those things, you need to learn to work with your hyperbrain, otherwise you will constantly fail in public and humiliating ways at the worst moments (usually, on the cusp of victory, at least in my experience). And that will hurt you more than the average person, because you are far more sensitive to negative feedback than you’d care to admit. Let’s look at the first practical step to take to improve your chances of success.

The first step to success with a hyperbrain is to both accept your limitations and reject them.

Accept your limitations

You are not built for consistency. Putting yourself in situations which require you to provide a constant output, and which hurt you the moment you fail to do so, is a recipe for disaster for you. Yet you might be tempted to set up just such a system in order to generate motivation. To succeed, however, you need to engineer your environment to focus on what you’ve achieved rather than what you’ve planned to achieve.

Your focus can shift radically in an instant. This means you cannot rely on continued focus in a period of time, so, to succeed, you need to structure your (focused) work in a way that allows you to abandon it at short notice without downside.

You crave validation from yourself. If you can’t feel that you’re doing something really worthwhile, your productivity will shoot down to a hundredth of what it might otherwise be. You need to ensure your work is always presented in a way that makes you feel it’s worthwhile.

You crave validation from from other people, too. Most people like a pat on the back, but without that pat, you can’t go on. Putting yourself in situations where no one really cares about what you’re doing will demoralise you fairly quickly, unless you can come up with elaborate rationalisations for why they don’t care yet (e.g. secret projects). So, paradoxically, to succeed, you actually need to be on the front lines, where it’s most visible and most dangerous to fail, because that’s where you’ll feel most energetic and driven.

When you’re on a high, you feel you can take on the world. And you could - if only you could maintain that high. But you can’t. So, on a high, you actually do take on the world, and then the world chews you up and spits you by the side of the road. To succeed, you need to moderate that eagerness to ensure you don’t set yourself up for failure.

You get involved in too many things. All successful people do that to an extent, but you’re really pushing the boundaries. At any given time, you’re reading 5 books, pursuing 10 pet projects, and working on 15 things - and you constantly shift between them. To succeed, you need to structure your environment to allow you to shift between those things without negative side-effects.

You are extremely sensitive to negative criticism. Most people dislike being told they’re wrong, but the wrong bit of criticism from the wrong person can shut down something that you genuinely cared about permanently. To succeed, you need to develop a healthy scepticism for people’s negative criticisms (if only because success is always, inevitably, accompanied by harsh negative criticism from people who are mean, jealous, in a bad mood, or just simply disagree in overly harsh terms).

You have a strong tendency to martyrdom and self-victimisation. How better can you gain other people’s positive feedback than by sacrificing yourself? If only I had the support I needed, I could do so well! To succeed, continue reading.

#1: Reject your limitations

One of the hyperbrain’s tendencies is self-victimisation. Well, that’s not unique to the hyperbrain. Many people feel misunderstood, although the craving for external validation makes it particularly acute in this type of mind, because the only way to fulfil that craving is to succeed, and you cannot succeed while you feel the odds are stacked against you. This self-victimisation is crippling, though. It’s oh so easy to slip into thinking that you are doomed to fail at everything you try, because you’re just that way, and there’s always some bit of the “support system” that’s missing (tip: it’s a catch-22 - you will only be able to build a full support system when you’ve already succeeded).

If you take only one thing from these articles, take this:

Your limitations are not an excuse for failure.

You should never throw up your hands and accept that you will fail because of your limitations. Analyse past failures in terms of your limitations to see how you can make up for them, but never accept defeat as a given. This advice goes for anyone, really, but it is especially important for hyperbrains because of these self-victimisation tendencies.

Your environment is not an excuse for failure.

You may try to dodge the above advice by saying something along the lines of: “Well, I can deal with my limitations, but my environment just doesn’t work with my personality.” Bullshit. You can succeed in any environment. The match (or mismatch) between your limitations and your environment is just a puzzle to be solved. In later articles, I’m going to drill down into specific techniques for how to counteract those limitations without taking away from your strengths, and you’ll see that almost no environment is incompatible with the hyperbrain, so long as you know how to handle yourself. You are the sole factor in whether you succeed or fail.

You don’t need to sacrifice yourself in order for others to succeed.

People don’t need you as much as you feel they do. How many times have you been in a situation where you thought the project couldn’t run without you, and you got moved somewhere else anyway, and the project still went on? Because of your ability to pick up many different skills, you’re involved in everything, so it’s easy to end up feeling you’re indispensable. Then, you feel that you can’t possibly go and do what you want because everyone is depending on you. It’s easy to turn this into another excuse for not achieving your potential. Don’t let it be so. People don’t need you as much as you think they do, and they will not appreciate your sacrifice at all - so don’t do it.

Unless you accept this key point, that the key to success lies within you, that there is no valid excuse for not realising your potential, then the rest of my advice will be worthless. I’ve started with this high-level “tip”, even though it really applies to everyone (not just hyperbrains) because it is so very important.

In part 3, coming later this week, I’ll present my most important approach for how to deal with distractibility and arrange your work to survive the hyperbrain’s attention deficit without losing out on its ability for extraordinary focus (no, it doesn’t involve some fancy variation on GTD).

via Inter-sections.net : by daniel on 8/28/08

Do you have a hyperbrain?

A recent article posted up on HackerNews presented a list of symptoms (representing things that the author felt about himself). These symptoms are not common to everyone, but they are common to enough people to warrant this and further articles. Plus, I promised some of them that I’d write about this.

The characteristics exhibited there seem to touch on almost every so-called mental disorder out there: Bipolar-like ups and downs of energy and, sometimes, emotions; Obsessive focus (under certain circumstances); Compulsion to do certain things that just have to be done; Hyperactivity (with a tendency to start many things at once); Attention Deficit (hell yeah.. oh, shiny stuff!). Yet it is far from diseased. With that brain, you can achieve great things, so long as you apply a few simple, practical approaches to harness it.

(From XKCD)

Do you have a hyperbrain?

A recent article posted up on HackerNews presented a list of symptoms (representing things that the author felt about himself). These symptoms are not common to everyone, but they are common to enough people to warrant this and further articles. Plus, I promised some of them that I’d write about this.

The characteristics exhibited there seem to touch on almost every so-called mental disorder out there: Bipolar-like ups and downs of energy and, sometimes, emotions; Obsessive focus (under certain circumstances); Compulsion to do certain things that just have to be done; Hyperactivity (with a tendency to start many things at once); Attention Deficit (hell yeah.. oh, shiny stuff!). Yet it is far from diseased. With that brain, you can achieve great things, so long as you apply a few simple, practical approaches to harness it.

(From XKCD)

The hyperbrain is full of contradictions

On the one hand, the attention-deficited brain can be easily distracted by almost anything (a dire condition in the age of blogs, RSS feeds, and social news aggregation). On the other hand, it is also capable of extraordinary focus on the right task, and can turn that temporary obsession into a spike of productivity that has a nasty tendency to result in previously impossible things being achieved over the weekend. Unfortunately, the typical productivity approaches simply don’t work very well for this kind of brain, perhaps because they attempt to cure the symptoms, not the cause, and perhaps also because while temporarily decreasing one’s distractibility, they also obliterate the focus ability that gives the hyperbrain all its power.

On the one hand, it is practically incapable of multi-tasking. On the other hand, it can, under the right circumstances, plough through an enormous to-do list in an astonishingly short amount of time. This makes it particularly galling when you go through a low-productivity day. Not only you haven’t done much that day, but you did so much only two days before! Not living up to one’s potential is always disappointing.

On the one hand, it seems incapable of organising itself, working in a glorious mess that would drive most people nuts. On the other hand, this very habit is a side-effect of its ability to make sense of vast, churning oceans of chaos, where most analytical approaches would fail repeatedly or take forever. The hyperbrain can devour a new, ill-defined topic, organise it mentally into a fractal tree of practical thoughts, and successfully apply it to a problem at hand or explain it to others - all in less time than it would take the normal brain to even decide to go on a training course, let alone book it, endure it, and apply it.

On the one hand, it is often extremely good at grasping technical subjects, such as physics or hacking, which makes it very likely to settle for an engineering career. On the other hand, it has powerful artistic aspirations, and a sensitivity to the world that is usually found only in dedicated artists - not in your stereotypical engineer.

On the one hand, it suffers from a truly compulsive obsession with details - for instance, it might be incapable of going through a document without noticing almost every typo and grammatical error, as if they were circled with a red pen. It might listen to a piece of music and hear every false note. This can make one wonder: “Am I some sort of minor savant?” On the other hand, it is capable of rapidly leaping to the larger picture and drawing big picture conclusions at the highest levels.

On the one hand, it is capable of extreme highs of energy and enthusiasm. On the other hand, it regularly goes through days or even sometimes weeks of bored semi-depression, where it simply cannot be moved into any sort of productive activity. Well, it can, but we’ll get to that later.

On the one hand, this brain is, I firmly believe, capable of acts of genius. It surprises and delights its owner with its irregular achievements, even as it disappoints with its unpredictability. On the other hand, the enterprise world values predictability more than excellence, and the hyperbrain is thoroughly incompatible with that environment, and so is regarded by many as inferior, worthless, a nuisance. It can lead to misery, as described by lispy in his follow-up post.

Many of these characteristics exist in most people, to an extent, but in the hyperbrain, they are essential, primary, central, and acute. It is not a superbrain (though it can occasionally produce some extraordinary results), it is a hyperbrain - a more extreme version of the average brain. Because of that, however, it can be quite challenging to make the best out of it.

Do you own a hyperbrain?

If you recognise yourself in this, like many people, then do stick around (bookmark this in your RSS reader, perhaps), as I intend to publish a series of articles going into various aspects of this. If it doesn’t sound like you at all (which will be the case for a large percentage of readers), you might still wish to read it to understand some of your friends who might exhibit these traits (and perhaps point them this way). Don’t feel bad about it - hyperbrains are not superior, just different.

What makes me qualified to talk about this hyperbrain? Well, I happen to be the proud owner of one such specimen that I’ve been living with for a while - as long as I can remember, actually. Moreover, having had to survive for 4 years in a large business consulting firm, and having since started my own business - both of which are activities rather unfriendly to the hyperbrain - I’ve figured out a good number of approaches to harness this gift of nature, and, since others seem interested, I might as well share what I’ve discovered, in hope that it may be useful to others who are similarly blessed.

For it is a blessing, so long as it can be harnessed successfully. Out of control, it will make you miserable, as you constantly fail to live up to the potential that you know you have, the potential to achieve things both great and just plain normal, including, perhaps, things that will make you happier.

As I post up these items, please do keep in mind that this is not an absolute, objective guide to all cases, but a series of subjective observations from my own case as well as from the cases of people I know. You should take each piece of advice as you would any piece of advice found on someone’s blog - with a pinch of salt. Then again, do try some of these, and see if they work for you. At the very least, they should provide a starting point to develop your own techniques, or interesting ideas to enhance your existing approaches.

Next: part 2, High-level approach to getting the best of the hyperbrain.

tag:www.inter-sections.net:Article54 2008-08-26T15:35:32+01:00 2008-08-27T13:18:37+01:00 daniel Making money off facebook

Here’s an article from VentureBeat waving about some figures about how much money can be made with Facebook apps. Although the figures are a bit anecdotal, and I hope for their sake that no VC’s ever invest based on such hand-waving mathematics, the real gem is at the end:

Either way, the many naysayers suggesting that it’s impossible to make money on Facebook might want to think again.

I don’t know if anyone’s ever suggested it’s _impossible_ to make money from Facebook. The main backlash against Facebook applications as a business model has really been against the gold rush mentality of the early Facebook app “golden age”. In those days, the mental processes went a little bit like this:

  1. Facebook has lots of users
  2. Facebook is inherently viral
  3. If I make a Facebook application, it will be easy to reach millions of people
  4. An application that can reach millions of people is bound to make money.

That’s a nice story, and it explains why some many people (myself included) rushed into Facebook application development last summer. Since then, most of them have pulled out, and for very good reasons.

  1. Facebook became much more protective of its users (and quite sensibly). A large part of the changes to Facebook in the last year have been to protect its users from over-greedy and spammy applications
  2. Many changes entirely nerfed the virality, making it much, much harder for an application to magically spread from 10 users to a million within a few weeks
  3. Therefore, it’s become very hard to reach any large number of people on Facebook
  4. Even applications that did benefit from the early “golden age” conditions didn’t manage to make that much money. Their business models are still being proven. Slide and RockYou may have a few very successful apps, but they also have many developers, and it’s unlikely that their Facebook revenues cover their costs yet (though I’d love to hear some hard numbers on that).

The truth is, yes, it’s possible to make money with a Facebook app. But, and this is the key, it’s no easier than making money with a non-Facebook app. In many ways, it’s harder. Working with the Facebook platform and its many limitations is a challenge in and of itself. Even if you’re a consummate start-upper outside of the Facebook bubble-world, you’ll have to learn application development all over again in this new, different environment. That’s not a huge deal, but it should give pause to people who think they can just “make a Facebook version” of their otherwise successful application.

More importantly, building a Facebook application puts you in the thrall of Facebook. That is a huge deal, because Facebook is their own business, and they will always do things to their own advantage, even if that involves doing something that will completely destroy your business. The internet is fickle enough as it is. Do you need the extra risk?

Here’s an article from VentureBeat waving about some figures about how much money can be made with Facebook apps. Although the figures are a bit anecdotal, and I hope for their sake that no VC’s ever invest based on such hand-waving mathematics, the real gem is at the end:

Either way, the many naysayers suggesting that it’s impossible to make money on Facebook might want to think again.

I don’t know if anyone’s ever suggested it’s _impossible_ to make money from Facebook. The main backlash against Facebook applications as a business model has really been against the gold rush mentality of the early Facebook app “golden age”. In those days, the mental processes went a little bit like this:

  1. Facebook has lots of users
  2. Facebook is inherently viral
  3. If I make a Facebook application, it will be easy to reach millions of people
  4. An application that can reach millions of people is bound to make money.

That’s a nice story, and it explains why some many people (myself included) rushed into Facebook application development last summer. Since then, most of them have pulled out, and for very good reasons.

  1. Facebook became much more protective of its users (and quite sensibly). A large part of the changes to Facebook in the last year have been to protect its users from over-greedy and spammy applications
  2. Many changes entirely nerfed the virality, making it much, much harder for an application to magically spread from 10 users to a million within a few weeks
  3. Therefore, it’s become very hard to reach any large number of people on Facebook
  4. Even applications that did benefit from the early “golden age” conditions didn’t manage to make that much money. Their business models are still being proven. Slide and RockYou may have a few very successful apps, but they also have many developers, and it’s unlikely that their Facebook revenues cover their costs yet (though I’d love to hear some hard numbers on that).

The truth is, yes, it’s possible to make money with a Facebook app. But, and this is the key, it’s no easier than making money with a non-Facebook app. In many ways, it’s harder. Working with the Facebook platform and its many limitations is a challenge in and of itself. Even if you’re a consummate start-upper outside of the Facebook bubble-world, you’ll have to learn application development all over again in this new, different environment. That’s not a huge deal, but it should give pause to people who think they can just “make a Facebook version” of their otherwise successful application.

More importantly, building a Facebook application puts you in the thrall of Facebook. That is a huge deal, because Facebook is their own business, and they will always do things to their own advantage, even if that involves doing something that will completely destroy your business. The internet is fickle enough as it is. Do you need the extra risk?

tag:www.inter-sections.net:Article53 2008-08-26T14:50:15+01:00 2008-08-26T14:50:15+01:00 daniel Public Service Announcement

Ok.

So I’ve been a bit sparse on the posts lately.

Well, that’s all going to change. I intend to start posting a bit more often from now on, with shorter posts most of the time (although the odd big post will still come up every once in a while). I’ve been terribly busy with my start-up, and, well, I know it’s not an excuse, but hey, that’s life. I’ll probably be terribly busy in the future too, but I’ll make more of an effort on the blog.

In other news, I’ve actually published a couple of articles in the meantime, which you may be interested in reading. They appeared on Sitepoint, and are titled Why You Should Fire Your Clients And Launch A Product and Nine Deadly Startup Diseases—and How to Cure Them. If you like my usual start-up oriented articles, those should be of interest.

In any case, thanks for reading this blog, and I hope the new publishing regimen works out for both you and me.

Ok.

So I’ve been a bit sparse on the posts lately.

Well, that’s all going to change. I intend to start posting a bit more often from now on, with shorter posts most of the time (although the odd big post will still come up every once in a while). I’ve been terribly busy with my start-up, and, well, I know it’s not an excuse, but hey, that’s life. I’ll probably be terribly busy in the future too, but I’ll make more of an effort on the blog.

In other news, I’ve actually published a couple of articles in the meantime, which you may be interested in reading. They appeared on Sitepoint, and are titled Why You Should Fire Your Clients And Launch A Product and Nine Deadly Startup Diseases—and How to Cure Them. If you like my usual start-up oriented articles, those should be of interest.

In any case, thanks for reading this blog, and I hope the new publishing regimen works out for both you and me.

tag:www.inter-sections.net:Article52 2008-08-26T14:08:51+01:00 2008-08-26T14:08:51+01:00 daniel Bad bloggers copy, great bloggers steal

“Very deep is the well of the past. Should we not call it bottomless?” - Thomas Mann

Whenever working on anything remotely artistic, I feel compelled to try and be original. After all, what’s the point of creating something just like everything else that came before? That seems like a noble aim: add something new to the world, rather than re-hashing the same old thing. It’s a desire that all artists share, to an extent. History appears (on the surface) to recognise those who brought forth something entirely new, and, particularly, to recognise them for the very reason that they brought something entirely new into existence.

Recently, someone wrote an adaptation of a famous Russian fairy tale by Alexander Pushkin, ”The fisherman and his wife”, adapted to the topic of greedy SEO tricks, and called it ”The web developer and his wife”. On YCNews, someone commented: “Sometimes it is better to not make bad copies of good things.”

I couldn’t disagree more. In fact, I believe that this is the exact formula for making great things.

“Very deep is the well of the past. Should we not call it bottomless?” - Thomas Mann

Whenever working on anything remotely artistic, I feel compelled to try and be original. After all, what’s the point of creating something just like everything else that came before? That seems like a noble aim: add something new to the world, rather than re-hashing the same old thing. It’s a desire that all artists share, to an extent. History appears (on the surface) to recognise those who brought forth something entirely new, and, particularly, to recognise them for the very reason that they brought something entirely new into existence.

Recently, someone wrote an adaptation of a famous Russian fairy tale by Alexander Pushkin, ”The fisherman and his wife”, adapted to the topic of greedy SEO tricks, and called it ”The web developer and his wife”. On YCNews, someone commented: “Sometimes it is better to not make bad copies of good things.”

I couldn’t disagree more. In fact, I believe that this is the exact formula for making great things.

Bad artists copy

“Bad artists copy. Great artists steal.”

Quick. Who said this? Ah, of course, Picasso. Or was it?

“Immature poets imitate; mature poets steal.”

That one’s from TS Elliot. Ok, so they both said. it. Wait a minute… what’s this?

“A good composer does not imitate; he steals.”

Damn. This one comes from Stravinsky.

This is just from ten minutes of googling. It is likely that this quote can be traced not only to many contemporary artists, but also to many before them. There are many deep, interesting, worthwhile ideas in the world, but the world has existed for a long time, and mankind has been thinking up ideas for well neigh on ten thousand years. Jorge Luis Borges was an Argentine author who wrote many interesting, mind-bending short stories. He was also the Head Librarian in Buenos Aires and spent much of his time researching ideas.

I am not an erudite scholar, so I cannot reproduce the intimately wide knowledge of the history of ideas that Borges was capable of. However, to illustrate the depth to which one can go when looking for the true origin of an interesting ideas, here is a passage from André Maurois’ introduction to Labyrinths, a fantastic collection of Borges’s short stories that I warmly recommend:

“[Borges’s] sources are innumerable and unexpected. [He] has read everything, and especially what nobody reads any more: the Cabalists, the Alexandrine Greeks, medieval philosophers. His erudition is not profound - he asks of it only flashes of lightning and ideas - but it is vast. For example, Pascal wrote: ‘Nature is an infinite sphere whose centre is everywhere, whose circumference is nowhere.’ Borges sets out to hunt down this metaphor through the centuries. He finds it in Giordano Bruno (1584): ‘We can assert with certainty that the universe is all centre, or that the centre of the universe is everywhere and its circumference nowhere.’ But Giordano Bruno had been able to read in a twelfth-century French theologian, Alain de Lille, a formulation borrowed from the Corpus Hermeticum (third century): ‘God is an intelligible sphere whose centre is everywhere and whose circumference is nowhere.’”

Nothing new under the sun

Thousands of years ago, an unknown writer (purported to be Solomon the Wise) complained //www.gnpcb.org/esv/search/?q=Ecclesiastes+1%3A9>:

“What has been is what will be,
      and what has been done is what will be done,
      and there is nothing new under the sun.”

In today’s world, that seems hard to believe. Nary a week goes by without some new-fangled gadget or website. This especially affects the start-up world. Everyone is always trying to come up with the Next Big Thing, and here again, it is easy to confuse and merge the quest for success with the quest for newness or originality. As with art, the latter is misleading, dangerous, and futile.

There were auction sites before eBay. There were classified sites before Craigslist. There were money transfer sites before PayPal. There were social networks before Facebook. There were search engines before Google. Each and every online success had precursors, some of them very successful. None can honestly claim that they did anything really new. At best, they can claim that they did something better.

The truth is, being the first to come up with a great idea for an online site would be more a curse than a blessing. If it happened to be a really good idea, it would burn a hole in your mind and never let you rest until you had seen it implemented. However, any idea that is truly completely new would likely be alien and bizarre to most people. You would need many years of bashing people on the head before they finally realised your genius. In a way, having such an idea would condemn you to decades of never-ending failure until the world finally caught on — and by then it would probably be someone else’s implementation of it that took over. This is the hidden sting beneath Howard Aiken’s quote, “Don’t worry about people stealing your ideas. If your ideas are any good, you’ll have to ram them down people’s throats.”

Is it even possible to come up with something completely new, or was Solomon truly wise on this matter too? It all really depends on your definition of new, of course. What about the first person who created an online social network site. Well, it was new in the sense that it wasn’t online yet. But was it truly new? Hardly. Social networking is such a powerful concept on the web only because it is such a powerful concept outside the web. There have been many sorts of organisations, both businesses and others, who have focused on allowing people to extend their social networks. Societies, clubs, cafés, pubs and gala events, etc, are all social gathering places where people reinforce and extend their social network. Facebook, in a sense, is like an online club which optimises that process, but it is only new in small, ancillary ways.

Power concepts

The point that I’m driving at (and that I failed to quite explain in this comment thread on YCNews), is not that it’s impossible to come up with a new idea. Of course it is possible. Google’s PageRank algorithm was new in its application to search engines. I’m not denying the creativity of people who come up with new businesses or artistic creations. In fact, creating a successful new business doesn’t take one creative idea - it takes many thousands.

However, when you look at the ecosystem of ideas as a whole, there are only a few really powerful ideas out there. Depending on how you slice the cake, that “few” can be literally a handful or hundreds, but all of the key ideas have been uncovered already, and successful “new” business ideas are merely extensions and variations of existing, powerful business ideas in new directions. eBay is just a marketplace — that’s existed for many thousands of years — spread to the whole connected world. Facebook is the fireplace in the middle of the encampment — virtualised onto every computer. Craigslist is the town crier — multiplied by ten million.

When you’re looking for that new business idea, don’t bother trying to be original, or to come up with something completely new. If your idea is really different from each of those power ideas, chances are it won’t be a successful business. Far better to link your idea up to some powerful, key human concepts than to try and keep it separate.

Back to square one - the world inside your head

Let’s step back to the art world for a few more inspirational thoughts. Art is not just about what you express, but also about what the viewer, reader, listener — the appreciator of the art — takes in. A hundred million people throughout the modern and ancient world have probably said that “Beauty is in the eye of the beholder”. Even if your work seems unworthy, even if is is a bad copy, someone might see something in it.

Some years ago, I watched a movie, Jakob the Liar, which finished with a puzzling proposition. The protagonist was dead, shot in the head by a nazi officer for refusing to deny the hope of the people in the ghetto, and those people were packed into trains. The movie proposed two possible endings. In one, they ended up all dead in a concentration camp; in the other, they were rescued by Russian tanks halfway to Auschwitz. I’m grateful to this movie, as it presented a very powerful idea.

The world inside your head is yours to do what you please with. If you see something that is clearly a “bad copy of a good thing”, instead of putting it down, look for the good thing hidden inside, and see how it could be a better thing yet. If you feel so inclined and are capable of it, perhaps you should take that opportunity to make your own, better copy of that good thing.

Next time you catch a bad movie in the cinema, see if you can improve it in your head. You will be rewarded immediately with a better movie.

The web is an amazing thing for many reasons. One of them is that it makes the copying process quasi free and inherently allows anyone to copy anyone else. The result is a fascinating vortex things both great and appalling, many of them copies of copies of copies of something that wasn’t worth much in the first place. Start by making a copy of a good thing instead of a bad one, and you’re one step ahead already.

Even if your creation is imperfect, or even downright bad, let the world judge for itself. Others may see more into it than even you intended or imagined. I’ll close this with a translation of Yves Duteil, a French singer, from his song Regard Impressioniste:

“The world has the beauty of our own gaze upon it
      The garden of Monet, the sun of Renoir,
      Are only the reflection of their vision of things
      For which each of us can be the mirror.”

tag:www.inter-sections.net:Article51 2008-05-28T15:09:57+01:00 2008-05-28T15:13:26+01:00 daniel Awful marketing campaign

Sometimes, marketing efforts go awfully, terribly wrong. Sometimes, it’s nobody’s fault - it’s just the way things turned out.

However, sometimes, it’s absolutely and clearly someone’s fault. Some ad campaigns are really badly designed. They don’t necessarily come out of an obscure, inept company. The ad campaign I’m going to talk about today is from Forbes.

Sometimes, marketing efforts go awfully, terribly wrong. Sometimes, it’s nobody’s fault - it’s just the way things turned out.

However, sometimes, it’s absolutely and clearly someone’s fault. Some ad campaigns are really badly designed. They don’t necessarily come out of an obscure, inept company. The ad campaign I’m going to talk about today is from Forbes.

So, I was taking in my daily news intake, browsing a blog article that I picked up on Hacker News. At the bottom of the article, I saw a Flash advert that actually puzzled me. It seemed interesting, worth at least a click to see what it was about. After all, Forbes is a respectable company, and I figured they wouldn’t advertise something like this unless there was something reasonably cool on the other side of that click.

So, expecting some information about this “most innovative and smart blog community”, I clicked. Woe unto me. This is where I landed:

No information, just a dubious, unfriendly signup form. I don’t know the exact stats, but I’d wager that they lost 99% of the click-throughs on this page. Way to go, Forbes. Such appalling ineptitude seemed worth poking a bit further. What exactly was this thing they were trying and likely failing to get people to sign up to? Fortunately, there was a help link in the top right:

I clicked it. Information about the service? Nah, of course not.

More clicking…

Perhaps now…

Fantastic. A completely useless blurb. Let’s give it one last shot. Adify’s website:

Dear god. Even their website is a failure. The only sentence 90% of people are likely to read if they ever get that far is “Are you ready to Adify?”. More than half of the above-the-fold space is wasted. Now, I don’t know about you, but my natural reaction to this is to close the window. Nevermind the text below that perhaps holds some sort of amazing information that will change my life. I’ve clicked about 10 times to get to this page and it still fails to tell me what I need to know to decide what this Forbes thing is all about.

This is doubly ironic considering that “Adify” is plainly some sort of blog advertisement venture. That an advertisement venture would fail so spectacularly at even advertising itself is just plain sad.

What should they have done?

How about make the advert link to a page with a clear set of straighforward, 5-7 words bulletpoints that immediately explain to the would-be member why they should join. Then, below that, a simple sign-up form asking people to just enter their email address to get more information. This isn’t rocket science, it’s just very basic online marketing.

If you’re going to pay good money to get people to click on your adverts, make sure you have an effective, self-contained, simple page on the other side that visitors can grasp and interact with within 5 seconds. Because most people will leave after about that amount of time if their interest hasn’t been piqued.

tag:www.inter-sections.net:Article50 2008-05-28T00:11:21+01:00 2008-05-28T00:14:20+01:00 daniel New blog design, new blog engine

I can never leave well enough alone. After my article blasting perfectionism, I guess it was inevitable that I should engage in a bout of it myself :-)

Not that the blog is perfect now, by any means.

Anyway, so I’ve moved over to a new blog engine, from Wordpress to Typo. Typo is written in Rails, and supports all the key features I want on my blog (e.g. Trackbacks). This means I can extend and reprogram it as I want, something I could not do with Wordpress and its mountains of spaghetti code. I’m planning to add a few cool features now that I’ve got full control over the code. Keep your eyes peeled for funky things like hit counts on posts, and other things you probably don’t care much about but which will make me feel happier :-)

As you can see, there’s also been a redesign! I have my friend Kelvin Koh to thank for the lovely new header, which not only looks 20 times cooler, but also only takes 19 kilobytes (as opposed to the humongous 75k of the previous one!). Here’s the old one one last time so we can all say good bye to it.

Looking forward to posting many more interesting articles for your reading pleasure.

Ciao,

Daniel

PS: If you love or hate the new design (or if you find anything broken anywhere), please don’t hesitate to let me know in the comments below!

I can never leave well enough alone. After my article blasting perfectionism, I guess it was inevitable that I should engage in a bout of it myself :-)

Not that the blog is perfect now, by any means.

Anyway, so I’ve moved over to a new blog engine, from Wordpress to Typo. Typo is written in Rails, and supports all the key features I want on my blog (e.g. Trackbacks). This means I can extend and reprogram it as I want, something I could not do with Wordpress and its mountains of spaghetti code. I’m planning to add a few cool features now that I’ve got full control over the code. Keep your eyes peeled for funky things like hit counts on posts, and other things you probably don’t care much about but which will make me feel happier :-)

As you can see, there’s also been a redesign! I have my friend Kelvin Koh to thank for the lovely new header, which not only looks 20 times cooler, but also only takes 19 kilobytes (as opposed to the humongous 75k of the previous one!). Here’s the old one one last time so we can all say good bye to it.

Looking forward to posting many more interesting articles for your reading pleasure.

Ciao,

Daniel

PS: If you love or hate the new design (or if you find anything broken anywhere), please don’t hesitate to let me know in the comments below!

tag:www.inter-sections.net:Article49 2008-05-19T12:44:16+01:00 2008-05-25T14:55:47+01:00 daniel Perfection does not exist

1. The idealistic path to ‘perfection’

You’re sitting at your desk, alone with your idea. Or perhaps you’re with some friends or colleagues or both. This is a great idea. You’re excited! Now all you need is to implement that perfect vision, and you will become rich and famous.

You’ve heard that ideas are nothing without implementation. You’ve heard that ideas are a dime a dozen, you know that what will make or break your idea (and your business along with it) is how well this idea is implemented. The devil is in the detail, and you’re going to make damn sure that every detail is right. All you need is to make something people want, to make it the best damn implementation out there, and you’ll be laughing all the way to the bank!

Unfortunately, there’s a fatal flaw in your plan: you and your brilliant idea. You, I’m sorry to say, don’t have the first clue what your users really want. Oh, you have some vague idea — and at this stage, a vague idea is a pretty good start — you know roughly where you want to go, but the truth of the matter is, if you took your vague idea, concretised it, and implemented it perfectly as it is currently in your head, it would be a very, very bad product, a monumental flop. This is true whether you have detailed knowledge of the business domain, are a technical expert, or both.

1. The idealistic path to ‘perfection’

You’re sitting at your desk, alone with your idea. Or perhaps you’re with some friends or colleagues or both. This is a great idea. You’re excited! Now all you need is to implement that perfect vision, and you will become rich and famous.

You’ve heard that ideas are nothing without implementation. You’ve heard that ideas are a dime a dozen, you know that what will make or break your idea (and your business along with it) is how well this idea is implemented. The devil is in the detail, and you’re going to make damn sure that every detail is right. All you need is to make something people want, to make it the best damn implementation out there, and you’ll be laughing all the way to the bank!

Unfortunately, there’s a fatal flaw in your plan: you and your brilliant idea. You, I’m sorry to say, don’t have the first clue what your users really want. Oh, you have some vague idea — and at this stage, a vague idea is a pretty good start — you know roughly where you want to go, but the truth of the matter is, if you took your vague idea, concretised it, and implemented it perfectly as it is currently in your head, it would be a very, very bad product, a monumental flop. This is true whether you have detailed knowledge of the business domain, are a technical expert, or both.

The real “perfect” implementation is somewhere else. This is easily illustrated by the following diagram:

From A to B (but actually you want C)

Even if you can go from A to B directly and perfectly, that won’t do it, because, in fact, you want to be at C, but it is impossible for you to have any idea where C is.

2. The practical path to ‘perfection’

I’m sorry to say, but there’s another flaw with your plan: you again! You’re not alone in this one, though: your whole team is guilty! Real projects are fickle, difficult things. It takes all the willpower and social skills of a competent project manager to keep them aiming roughly in the right direction. Even then — especially if you’re lucky enough to be working with very smart people — there will be many side-steps, jumps and skips along the road. These are all perfectly natural and to be expected.

You will discover new things along the way, and that’s a good thing! Those will shift your end goal, and they will shift your direction too. By the end, your history of targets will be spread over a large area.

Your path to your end point(s) is likely to look something like the following picture.

From A to B (even a straight line isn’t so easy)

On the good side, this means that your product will be more practically consistent. On the bad side, there’s no telling whether those changes will actually bring you nearer to perfection. Consistency doesn’t make or break a product. Users do.

3. The use(r)ful path to ‘perfection’

What a disaster. Not only you don’t know where you’re going on a high level, but you also don’t really have a clue from week to week. Surely there must be a solution to this quandary. Someone in the world can tell you what the perfect product is. Just hire them and you’ll be sorted.

Problem is, you can’t hire them. The only people in the whole world who can tell you where your product is going wrong are your users. The minute users get into the equation, you suddenly have some way, as uncertain, fickle, and vague as it might be, to tell whether you’re going in the right direction. You need them to provide you with timely, accurate, effortless feedback throughout your development process.

If you followed my tips and released a beta, or even alpha, and listened to your users, your path might look a little bit more like this:

From A to B (with some feedback about where C might be)

And if you do this, chances are, you will probably turn out a pretty damn good product.

4. But… perfection does not exist?

Now, you might point out that I’ve made a pretty good case for why perfection is very hard to achieve. However, what I haven’t yet done is to explain why perfection doesn’t exist.

There are two good reasons why a perfect product doesn’t exist.

The first one is that there is an enormous variety of users out there. What’s perfect to one will be unbearable to another. You can, with some uncommon concentration of talent, build something that’s almost perfect for a lot of people. Apple have done it. Google have done it. And there are many other unsung heroes (though none seems to be quite as consistent as Apple), delivering fantastic products that are almost perfect for almost everyone. But every single one of these products is flawed in some ways for some people. In this sense, “perfection” is meaningless, a red herring. There is no perfection, only a good fit for a common denominator.

Actually, C can’t be pinpointed

The second one, much more vicious, is that all those diagrams tell a pernicious lie. They completely hide the vicious, dynamic, crowded, unpredictable nature of the marketplace of desires, of what people want and how they want it. People’s needs change. Trends change. Impressions, desires and public perceptions shift each and every day.

Even if you could build a product that would hit the sweet spot in everyone’s heart and feel just perfect to your entire target market, that sweet spot will shift, implacably relegating your ‘perfect’ product to the dustbins of time. In short, even if perfection was theoretically possible, if you built a product that was perfect today it would be imperfect tomorrow.

Also, C keeps moving about with time

5. What to do about it?

The main point of this article is to convince you to stop chasing perfection as a concrete goal. Striving towards building the best possible product is a good goal. Striving towards building a perfect product is an illusion, and a dangerous one at that. Striving to achieve perfection (or its sneaky twins, excellence and near-perfection) every step of the way is a deadly mistake.

Once you make it your aim to “build the perfect product”, you find yourself paralised by lengthy design work, longer iterations, and significant periods of “making the features perfect” without releasing anything to the users. This can and probably will kill your startup. Don’t make that mistake.

A much better modus operandi is to aim to move forward a little bit at a time, to build small increments of functionality that you can show to users as soon as possible. This, incidentally, is also the way agile projects are supposed to work (but often don’t). Aim small, shoot often, re-adjust each time. You need to influence the culture of your project so that it’s ok to make mistakes, and to make them often. A development model that allows lots and lots of cheap mistakes is far superior to one that tries to achieve perfection at every step, and thus makes each mistake very costly.

My own projects have fallen into this trap regularly, so I think it’s not an easy one to avoid. In the contagious enthusiasm of having built something that users love it’s easy to fall into the perfectionist pattern and decide that because the users like the system now, we need to ensure that they like every single release of the system. This even applies to other things than products. It takes a lot of discipline to fight that behaviour and say something that may well resonate, to your coworkers, as “let’s build crap”, but in fact means “let’s just release something quickly, no matter how bad it may seem, and see what the users think”.

But if you want your product to succeed, it must be done.

tag:www.inter-sections.net:Article48 2008-05-07T14:27:27+01:00 2008-05-25T14:56:09+01:00 daniel 13 Tips for creating a successful new online product

There is much talk these days about building a product for a niche and making a lifestyle business out of it. Much of the online literature about starting up is focused on how to create some fantastic product which will gather millions of visitors and make you a billionaire, and the “new wave”, so to speak, proposes that rather than taking a 1 in 10’000 bet that you can make billions, it is better to take a 1 in 10 bet that you can make millions.

Since I have started two such businesses already, here are thirteen tips from my own experience.

There is much talk these days about building a product for a niche and making a lifestyle business out of it. Much of the online literature about starting up is focused on how to create some fantastic product which will gather millions of visitors and make you a billionaire, and the “new wave”, so to speak, proposes that rather than taking a 1 in 10’000 bet that you can make billions, it is better to take a 1 in 10 bet that you can make millions.

Since I have started two such businesses already, here are thirteen tips from my own experience.

Target a niche

What to build

1. Build for someone specific

It’s very tempting to create a product for the widest audience. “Everyone can use our product, therefore if even a tiny proportion use it, we’ll be rich!” Beware the generalised product. If your product is not built for anyone in particular, it will not be good for anyone in particular. The worst possible market for a product is “small businesses on the web”.

On the other hand, if you build something that is directly useful for even just one real human being, chances are there will be others like that user and your product will have some success.

2. Don’t be afraid of targeting a narrow niche

Niches have numerous advantages. There’s less competition in niches, which means that your marketing dollars will go further to get you new customers. It’ll be easier to target likely buyers since there are probably already channels (blogs, magazines, trade shows) targeting that niche, that you can make use of.

Niches also tend to be very badly served in today’s world. If you look into almost any niche you will find a plethora of awful products that are just begging to be replaced by something better suited. Being able to build great products cheaply is a fairly recent development, and most pre-existing businesses have had to make do with duct-taped, poorly conceived solutions that are begging to be replaced. The smaller the niche, the lower the bar to success.

3. Solve a real problem that costs money

As DHH pointed out, the way to realistic profitability is not through gathering an outrageous number of eyeballs, but through creating a product that people are willing to pay for. The easiest way to get someone to loosen their purse strings is to convince them that using your product will pay for itself.

This can be either by enabling them to do something new to earn money or by saving them time and effort (and hence money).

Evolution

How to build it

4. Test the market with a working prototype as soon as possible

To win in this game, you need to build a great product. The problem is, no one on your team can tell you what the best product is — only your users can do that. You need a vision to get started on a product, but that vision is critically flawed in ways that you can’t see. User feedback is the most powerful force to point out those flaws, and until you have users (whether free or paying), you cannot use that force.

For this reason, it is important that you release something, anything, as embryonic as it might be, to people who can start to use it and let you know what you’re doing wrong. Listen to your users — and, to do this, give them a chance to tell you.

5. Develop iteratively

Your product is ambitious. It will solve many great problems for your users. However, if your product never gets finished, it will solve nothing. Be ambitious in your dreams, but conservative if your immediate goals. Aim for the result of each iteration to be useful in and of itself, but keep each iteration as tiny as possible.

Developing something small does not mean giving up your dreams, only delaying them. Cut every feature and every part of a feature that you can cut, but keep it on a list to work on later. If there is any way you can do it later, do so. Often, features that you thought were essential turn out to be unimportant when you have more user feedback.

6. Get things right, and be decisive in correcting the wrongs

As your product takes off (if it does), you will have less and less time to make up for earlier mistakes. As users pile on, it will become more and more difficult to make big, drastic changes. However you make your bed, that’s how you’ll sleep. As much as possible, take hard decisions early rather than letting problems fester. Don’t delay necessary change just because you’re already committed into a different direction.

7. Don’t spend the time correcting until you know what you’re aiming for

At the same time, it’s easy to end up spending all your time refactoring the codebase every time a new feature is brought in. Refactorings must be done to maintain development speed and build a scalable, clean product. However, a refactoring effort should consist of two parts: 1) figuring out what to refactor to, 2) doing it. The first part can take weeks, the second part is often a mere few days long. The first part should never be an excuse to stop work completely.

This applies to design changes too. If you realise that you need to change the direction of the product significantly, figure out your new goals for before implementing the change.

8. Don’t let your programmers design the user interface

I’m a programmer, among other things. Like many in this profession. I suck at designing UIs (though sometimes I believe I don’t). When you let programming-focused people like me build your user interface, you will get things like this.

Some people are naturally gifted at user interface design. They feel physically sick about adding a button that clutters the interface or messes up the user’s workflow. Make sure you have a gifted UI designer on your team (whether or not he or she doubles up as a different role — including programmer). It will make a world of difference when you get your first users — the difference between a lukewarm response and “Wow, it’s great! I love it!”

Virtuoso Violinist

Who to build it with

9. Make sure every member of the development team is passionate about the product

Your development team is to your product like parents are to a child. If they do not care about your product, it might turn out well anyway — but the overwhelming likelihood is it won’t. Anyone who’s not passionate about building your product should not be involved in building your product.

For this reason, it is very unlikely that outsourcing your product development will be successful. Build your product in-house, and make sure the team is fully bought into the concept and committed to make it a success. It is better to give up 50% of your equity for a great product team than to give up 5% for a poor product team. 95% of nothing is still nothing.

In yesterday’s world, this was very hard to achieve, since even a relatively simple web application required a fairly large team to implement, and the larger the team, the harder it is to remain passionate. With today’s web development technologies, it is possible for a team of 2 or 3 to build an entire business within 3-6 months, but those 2 to 3 must be passionate and dedicated.

It is very hard to make up for your team’s lack of passion through your own passion.

10. Be sickeningly elitist about your development team and sickeningly inclusive about your users

No one should be considered too stupid to use your product. For each person who you know had trouble using your product, there will be many more who had the same trouble but never told you. It’s never the user’s fault, it’s always your product’s fault for not being clear and intuitive enough.

At the same time, your development team needs to be the best. You cannot create greatness out of mediocrity. These days, elitism is regarded almost as a flaw. Actually, it is the only way to greatness. If you want to create the best product, you need the best people.

11. The best hiring strategy is to hire no one

Hiring employees is a nightmare. There are a lot of legalities to be considered, and it is a lengthy, time-consuming, and expensive process. Fortunately, you don’t need to hire employees. You need to recruit a development team to work with you, not for you.

Your development team is like the heart and lungs and brain of your business. They should be as committed and passionate as you are. For this to happen, you need to treat them as equals, not as subordinates.

You don’t need job adverts, you don’t need resumes, and you don’t need contract negotiations. What you need is to network in the right communities, whether online or offline, to recognise the people you need, and to bring them in not as employees but as partners in your vision.

12. Include at least one target user on the development team

By development team, I mean the team involved in the day-to-day or week-to-week iteration meetings. If you fail to do this, it will cost you a lot to readjust when a real user finally approaches your application and, inevitably, finds it lacking. If you’re a small startup on a tight budget, this extra cost can kill you. Survival is worth giving up equity to get a target user on your development team.

13. Ensure everyone on your development team understands the problem they’re solving

Immerse your development team in the users’ environment for a short period of time and let them see for themselves just how bad the current systems and processes are. Presumably, you have some contacts who work in the niche that you are targeting (if you don’t, then it’s probably not the right niche for you). Convince them to let one or more of your development team sit in their office and experience the pain points for themselves.

This is the opposite of embedding an end-user in the development team. Embed your development team into the end-users’ environment — at least for a time.

Conclusion and Bonus Tip: Break any and all of these rules rather than do something stupid

Creating a new, successful product is like writing a book, creating a movie, or raising a child. It’s a fiendishly complicated task that requires great adaptability and creativity. Rules can only get you so far. No amount of advice can guarantee you success. Sometimes, the rules fail, and you need to adapt to those situations and do what needs to be done, even if it flies in the face of accepted wisdom. For every rule of product development, there is a dozen examples of teams which did it differently and still succeeded.

Good luck!

As ever, please do share your thoughts and additional tips in the comments below, or on your own blog (I have trackbacks enabled).

via Phusion Corporate Blog by Jean Pierre Hernandez on 3/12/10

People always ask me why I never find a programming language for the Mac and settle down down down. C’est absolument incroyable indeed as the answer should be pretty straight forward to those who have already written an application for the Mac using Objective-C.

As a matter of fact, in France, raising such a question is like asking whether or not Camembert goes well with French fries or not. The answer to this question is obvious as it’s a known fact that Camembert goes well with everything. Seeing as not everyone is blessed with a taste for fine French cuisine and/or is from French héritage however, I’ll try to give an approximation in this blog.



For this, we need to emphasize the differences of developing Mac applications with and without MacRuby.

After setting up MacRuby as described in our previous blog post and having set up Xcode, it is now time to create our very first Mac application in Ruby. In this series of articles, we assume that you have the latest version of OS X installed on your Mac. By the time of this writing, that is Snow Leopard and it is important to emphasize this seeing as some Cocoa API methods have been deprecated or added since its last iteration. Without further ado, allons-y!

Creating a new project

After starting up Xcode:

  1. Select File
  2. Select New Project

A dialog window as shown below should appear.

From this window

  1. Select MacRuby application
  2. Click on Choose…

A file save dialog should now appear as displayed below.

In this window:

  1. Type in BornToBeAlive as our project name.
  2. Click on Save.

A new window should now appear representing the newly created project in the Xcode environment.

By the time of this writing our environment is setup to target OS X 10.5 (Leopard). As mentioned before, we’re going to target OS X 10.6 (Snow Leopard) seeing as we want to utilize the most mature Cocoa API and platform. As such we need to set this target environment to OS X 10.6 in the overview popup menu.

Now that that’s been dealt with, we can finally really start working on our application.

Designing our Interface

Before we’re going to write even a single line of code, let’s first start off by designing the user interface to our application. To do this, we first need to discuss how our programming environment deals with this kind of information.

Certain information about our interfaces, in particular the one’s we’ve created using Interface Builder (the UI design application of Xcode) are usually stored in bundles called NIB files.

As of Xcode 3, these are actually stored in files with the xib file extension as opposed to the nib file extension. Worry not however, as they are just different formats for storing the same information: where xib files appear to be represented as XML text files, a nib file is an archive. More importantly however, the difference between xib and nib files are that the former will be compiled within the executable and will not appear in the final .app bundle.

In general, Xcode will ultimately know what to do with these files and how to treat them. It is for this reason that we’ll refer to both formats as nib files and basically assume no distinction between them.

In the Groups & Files panel, expand the NIB Files group.

In this panel

  1. Double click on MainMenu.xib

This action should result in Interface Builder firing up for this MainMenu.xib file. Various windows of Interface Builder should now be visible to you.

In the MainMenu.xib window:

You see a collection of objects and proxy objects that are necessary for describing our user interface. The objects displayed in this window are objects that describe our application’s user interface and are stored in a freeze dried manner, i.e. serialized. Upon loading the NIB file, they get thawed and instantiated again.

In light of this, it is considered good practice to store only one window object per nib file. This way, we only load in the windows when we really need them (thus conserving memory) and will keep our design more maintainable too as each window and its components will be contained by its own NIB file. The latter will allow us to possibly recycle NIB files too in other projects.

Strictly speaking, we also shouldn’t store a window in our MainMenu.xib as is now the case, but in order to load this in, we require a notion of delegates. The latter is something we’ll discuss in a later article so for now, we’ll keep the window object in MainMenu.xib.

For now:

  1. Double click on Window

This should put the focus on our initial window and via the inspector, we can edit some of its properties, such as the title of the window instance.

While having selected the Window in the MainMenu.xib window, in the inspector window:

  1. Select the first tab, so that the inspector window is displaying the Window Attributes.

  2. Edit the Title field to Born to be Alive

  3. Hit the enter key

Your window should now bare the title Born to be Alive. How exciting!

Let’s add a Label to this window proclaim this message of life even bigger. To add cocoa components to our window, we need to drag and drop them from our Library panel to the window we want to add them to.

In the Library panel:

  1. Set the focus on the search field at the bottom of the Library panel.
  2. Type in Label. Notice that as we type character per character, the components get filtered based on our query.

Your Library panel should now display a few options for labels and should look something like the following:


Note that my Library panel will most likely display more options here in terms of labels as I’ve also installed the BWToolkit palette too. We won’t be using any of those components for our MacRuby applications though, so it’s safe for you to ignore them for now.

Now it’s time to actually add the Label component to our window. As mentioned earlier on, we do this by simply dragging and dropping the Label icon from our Library panel to the window we want to add it to. Doing so should result in something similar to the following:

Great! Let’s rename the newly added Label to something more fitting. In the window displayed above:

  1. Double click on the newly added Label. This should now open up the ability to edit value of this Label.

  2. Type in Born

  3. Hit the enter key.

Your window should now look something like this:

Wouldn’t it be fun if we would have a button that we could press to unveil the full message of life? Let’s do just that by adding a button to the window we’re designing.

In the Library panel:

  1. Type Button in the search box at the bottom of the Library panel. In a similar fashion as the label, it should filter away the components that do not match the Button search description.

    Whoah, so many buttons! Let’s just stick with the first shiny one for now.

  2. Drag and drop the first button that appears in the filtered selection to our window. Depending on where you dragged and dropped the button to, your window should now look something like this:

  3. Double click on the newly added button to be able to edit its title.

  4. Type in Unveil full message

  5. Hit the enter key.

Your window should now be shaping up pretty nicely and look something like:

We can actually build this project at this stage and see what we’ve just designed in the form of a real application! Indeed, the standard MacRuby cocoa template has set up most of the boilerplate to get us started. At a later stage, we’ll dive into the details of the bootstrapping process, but for now let’s just assume that it set it up all correctly and save our changes by selecting File->Save from the Interface Builder main menu.

Compiling is not the task of Interface Builder, but the task of Xcode so let’s switch back to Xcode. In the project window, click on the Build and Run button in its toolbar.

After compiling for a few seconds and linking all the dependencies, your new application should launch in your OS X dock, and in particular, the window you just designed should show up.

Clicking on the Unveil full message button doesn’t do a lot though, but that should come as no surprise seeing as we’ve only been designing the interface up to this point. We haven’t yet specified what should happen if one presses the Unveil full message button button.

In terms of Model-View-Controller (MVC) (a separation of concerns design pattern Cocoa relies heavily on), we need a controller to handle this kind of user input.

Writing our very first controller in MacRuby

As mentioned in the previous section, Cocoa was designed with the MVC paradigm in mind. Within this paradigm, we need some kind of controller layer to process the input provided by the user. This input ranges from keyboard events to mouse events. For our intents and purposes, we’re interested in handling mouse events on our Unveil full message button. In order to be able to do that, we need to create a controller that will be able to deal with that.

Also, we may want to process events employed by the user onto the window itself. This would normally require a NSWindowController instance. Taking in mind we want to process events from components within the window as well, we could choose to create a separate controller for these components as well, but that would likely make things overly granular, especially for the simple scenario we’re currently dealing with.

So in place of the latter, we can also just choose to consolidate the ability to process the events of a window and its components all together into a subclass of NSWindowController. This allows us to handle the general case of controlling an NSWindow as well as specify our own actions for handling the components contained by our NSWindow.

To do this, in the Groups & Files panel, expand the BornToBeAlive project as displayed below by clicking on the triangle next to it.

In this expanded project outline view:

  1. Right click (or ctrl+click) on Classes
  2. Select Add->New File

A new window should now appear giving you the options of what kind of new file you would like to add.

  1. From the Ruby user templates, select Ruby File.
  2. Click on Next

This will open up a Save File dialog.

  1. Type in MyWindowController.rb as the name for the new Ruby file.
  2. Click on Finish.

Your window should now look something like this:

As decided upon earlier, we now need to implement our MyWindowController class in a consolidated way such that it can control both the window and the elements contained by that window. We will achieve this by implementing MyWindowController as being a subclass of NSWindowController, and in doing so, specialize the NSWindowController class for our window.

In the code editor, type in:

class MyWindowController < NSWindowController
end

Tres bien! But how do we access the label to modify its value after a user has clicked on the Unveil full message button?

Well, according to the Apple cocoa documentation on NSWindowController, it is capable hold a reference to the window it controls/manages. Instinctively, we assume that through this reference, we could access the elements of the window.

Even though this is kind of true, the NSWindow class was designed for general cases as well and not just our specific window. This means that its design is well composed and that it will be rather tedious to acquire a reference to the element of the window we’re interested in manipulating. Most likely, it will involve a lot of chaining query calls which violates the principle of least knowledge.

To drive the point home, accessing an element in such a fashion in general will look something like: window.view.subviews[0]

A non-food solution to this would be to subclass our NSWindow to hold a direct reference to the elements we’re interested in manipulating, but that would require an assumption in terms of type seeing as our NSWindowController only deals with NSWindow and not OurSpecificWindow.

Taking all this into account, it’s probably just better to give our MyWindowController a direct reference to the element of the window we’re interested in manipulating.

In our particular case, we’d like to change the label’s string value after the user has clicked on the Unveil full message button to show the true message of life. This means we need a reference to the label within our MyWindowController and as such our code listing of MyWindowController now is:

class MyWindowController < NSWindowController
    attr_accessor :my_label
end

In Cocoa, such a reference is usually referred to as an outlet, in our case, representing the metaphor of “being able to plug a label object into the outlet”. C’est bon indeed!

We now need to define the action to be taken when a user has clicked on our Unveil full message button. You might be wondering right now whether or not we also need a reference to the button from within MyWindowController as was the case for the label. This however, is not necessarily the case for us seeing as the button — an instance of NSButton — is an action emitter. More specifically, an NSButton inherits from NSControl and NSResponder allowing it to receive user input (e.g. mouse events) and convert these to action events and dispatch the latter to our code. We may touch base on this subject in more detail in a later article, but for now, suffice it to say that we don’t need such a property reference.

When the button receives a mouse event from the user that is of our interest, i.e. a click event, it will convert this event into a click action and try to dispatch the action message to our code. To that end, the button expects us to provide an object with an action handler method to handle the action on delivery. In Cocoa terminology, this object containing the action handler method is referred to as the target of the button.

An action handler method in MacRuby has a distinct method signature: it is a method with one parameter named sender. It is important to adhere to this rule for action handler methods as Xcode and Interface Builder will only then recognize them as being actions.

Let’s open up our code editor in Xcode for MyWindowController.rb and change the listing to:

class MyWindowController < NSWindowController
    attr_accessor :my_label

    def unveil_full_message_clicked(sender)
        @my_label.stringValue = "42"
    end
end

Here, we’ve added the unveil_full_message_clicked action, which will change the stringValue property of our label to the true message of life. Excellent! We’ve now set up all our code, and what remains now is to tell our button to who it should dispatch its action to.

We can setup this target-action for our button programmatic, but Interface Builder provides us with a visual solution for setting these up as well. For the sake of clarity and convenience, the visual solution that we’ll go over with in a few moments enjoys our preference for now.

Hooking our MyWindowController up to our window

In the previous sections we’ve gone from designing our window to providing an implementation for our MyWindowController class. They still need to be hooked up to one another however as they are now still disjoint entities that don’t know of eachothers existence. In this section, we’ll describe how we’ll be able to hook these things up visually using Interface Builder.

In Xcode:

  1. Double click on MainMenu.xib to open up Interface Builder for this nib file.

As we’ve discussed earlier, objects are stored in a freeze dried manner in our NIB file that get “thawed for use” when the NIB file is loaded again. In this case, we need an instance of MyWindowController to hook it up to our freeze dried window instance.

In Interface Builder in the Library Panel:

  1. Type in NSObject in the search field.

  2. Drag and drop the Object from the panel to the MainMenu.xib window of Interface Builder. This will create a new freeze dried object in the NIB file that will be instantiated when the NIB file gets loaded in.

  3. Select the object.

In the Inspector panel:

  1. Click on the Object Identity tab.

    As we can see, the object is of class type NSObject. We need to change this to be MyWindowController to let this object be an instance of that type.

  2. In the class identity field, type in MyWindowController.

    Our object is now of type MyWindowController. Tres bien!

Now that we’ve created a freeze dried MyWindowController object, it’s time to hook it up to our window instance.

Recall from the code listing on MyWindowController that we have defined an accessor — i.e. outlet — for our label, but have not yet set this property. In particular, we need to set the my_label property of our MyWindowController instance to point to the label of our window. In Cocoa jargon, we need to “plug our window’s label into our MyWindowController’s my_label outlet”.

In the MainMenu.xib window of Interface Builder:

  1. Hold down the right button (or hold ctrl+click) on the MyWindowController object and drag your mouse to the label in the designer.

  2. Release the right mouse button above the label. A popup menu as displayed below should now appear showing you the outlets to which you can hook the label up to.

  3. Click on my_label in the Outlet popup menu to hook the label in the window up to our MyWindowController’s my_label property.

Our MyWindowController now knows what object it should refer to when we use @my_label in MyWindowController. What remains is to set up the target-action for our button to our controller’s action handler method. We’re almost there indeed!

To set the target-action for our button:

  1. Hold down the right mouse button (or ctrl+click) on the button in our window and drag to our My Window Controller object in the MainMenu.xib window as illustrated below.

  2. Release the right mouse button. A popup menu should now appear displaying the controller’s action handler methods we can dispatch the button’s (click) action to.

  3. Click on unveil_full_message_clicked: to allow the button to dispatch the click action event to this method of our MyWindowController instance.
  4. Hit cmd+s to save our changes in Interface Builder.
  5. Return to Xcode. Make sure we’ve saved all the changes we’ve made to the files here too via cmd+s.
  6. Hit the Build & Run button in the toolbar as we’ve done before.

Congratulations, your very first MacRuby application should now be in working order! Go ahead, click on the button to unveil the full message of life!

Download code

BornToBeAlive MacRuby App Example

Epilogue

For the sake of brevity — something I know is hard to believe looking at the volume of this first tutorial — we’ve omitted a few steps you’d normally like to take into consideration.

For instance, we’ve not connected the window outlet of MyWindowController (an outlet it inherited from NSWindowController) to our window instance to allow it to manage the window. Connecting this outlet occurs in a similar fashion as was the case with connecting the label outlet by holding down the right mouse button on the MyWindowController instance and dragging it to the window instance.

Releasing the right mouse button will display a popup menu outlining the outlets we can connect the window to. Clearly we should select the window outlet here.

We’ve also not yet discussed how we can adhere to the one window per nib file, moving the window object from our MainMenu.xib to its own nib file and load it in programmatically. As mentioned before, this will require knowledge of a programming concept called delegates which we’ll discuss in our next tutorial. This will also allow us to explain the concept of File’s Owner and so on, which will require us to refine some of the techniques we’ve explained up to this point.

For now, go out and celebrate your victory of writing your very first MacRuby application.

Homework Assignment

Port the following Born to be Alive application by Johannes Fahrenkrug to MacRuby! Post your GitHub links in the comments for extra street credit ;-) Having a hard time being able to do so? Stay tuned for our next installment in the MacRuby series with moi as we’ll dive into objective-c for rubyists!

via slash7 with Amy Hoy by Amy Hoy on 10/13/09

It’s Time to Redesign The Sales Page! Part 2 (Part 1)

So, last time on “It’s Time to Redesign The Sales Page!” we talked about why I decided the Freckle Time Tracking sales page had to be totally redone.

Namely:

  1. We weren’t proud of the design, so we didn’t promote it
  2. We didn’t believe it was effective at reaching our visitors, so we didn’t promote it

So these problems break down into two categories:

  1. Visual appearance
  2. Message/content

Because the message/content issue is much harder than the visual appearance, that’s where I started.

Tune in next time for the design.

Pre-work: Why, and Who?

To figure out what to say on a marketing site, you first have to figure out:

Why the hell should anyone care?

Once you have the Why, you also have the Who.

Why… and Who

Freckle is focused on freelancers and small teams. 

Freelancers and small teams who do what? you may ask. Well, to us, it doesn’t really matter. We designed it around our needs—and we’re designers and developers—but, across most industries, freelancing or consulting is pretty much the same. It’s different in the same ways, too. There’s as much variation among designers in their freelance habits, as there are among all freelancers, of all types.

This is why “freelancers and small teams” isn’t really our Who.

The real difference between our customers, and people who’d be better suited with our competitors?

Attitude. And outlook.

If you like this, you’ll like us

Nobody has ever accused me of being nuanced. It’s not that I’m incapable of nuance, but it’s not my highest priority. I like bold statements, bold moves, and bold designs. 

Freckle, too, is bold. It’s got nuance to it—to quote one happy customer, it’s got “a thousand little touches”—but, at heart, it’s a bold and decisive tool. We made it to be, in many cases, the opposite of what’s out there currently for time tracking. Because, well, we used those systems, and we hated them.

We’ve thrown out a lot of time-honored time tracking tropes (teehee) in order to make Freckle what it is. But this isn’t a case of cargo-culting “less is more,” it’s less with a purpose.

Two examples of “features” we cut out: required client/project hierarchy, and the need to define tasks before you could track time for them. Those things have their place in the enterprise. 

But they’re not features for small teams, or soloists, with a flat hierarchy, a high level of trust, and a culture of independence. They’re hobbles. Annoyances. 

And those people, the ones who trust their team members, who crave freedom, efficiency, flexibility, and a 10,000 ft view of their time, are our audience. 

To be even more specific, they like bright, happy software with bright, happy colors, and a little friendly snark now and again.

And we deliver.

That’s our Who and our Why, so intimately entangled.

Now, to write the site content itself

So, after an exercise just like this one, on paper, I was able to articulate why. And who.

Now the question becomes: How?

  • How to reach people who believe in trust, freedom, efficiency, and flexibility? 
  • How to speak to them? (As in, “that really speaks to me” as opposed to “talking with your mouth”)
  • How to communicate that we help them with the 10,000 ft view? 
  • And the bright cheery bit?

Freedom, efficiency, and flexibility

I made a list of the most important aspects of Freckle, and I worked my butt off to figure out how to describe them purely in the terms of benefits: 

How does this help you, the user, kick ass? (Thanks to Kathy Sierra for this mantra.)

Features are in bold, benefits are in italic:

  • Quick entry? Enjoy entering your time, and get it done in as little as 3 key strokes, no mousing.
  • No up-front configuration? Create new clients or projects when you need them—the first time you log time for ‘em.
  • Flexible tags & description? Describe your time however you want, when you want. Use tags with reports to get as granular as you want.
  • Inline indication of time budgets? Always know exactly where your project stands, on every page.
  • The Pulse? Learn the days where you & your team work the most—and least—and on what. Get a feel for your rhythm.
  • Bright & cheerful? Lift your spirits, even if time tracking’s not your idea of The World’s Funnest Thing To Do.

Are these a little bit overblown? Of course. But they’re an example of a draft. Gimme a break.

All positive

Did you notice that the benefits I listed here (and on the actual site) are all phrased in the positive? That was on purpose. I don’t want negativity to creep in.

Even though it’s so easy to frame Freckle in terms of what it’s not: Not painful. Not ugly. Not full of horrible, evil select lists. Not disrespectful. Not ignorant of the fact that time is a business (e.g. our competitors mostly don’t offer any kind of non-billable time tracking). 

Psychological research has shown that when people hear a negating phrase (”I am not a crook!”), they forget the negative and remember it as a true, positive statement (”I am a crook!”). 

Freckle’s not an asshole. (Freckle’s an asshole! With a bad toupee!)

That’s why responding to your competitor’s claims with denials is a weak position, whereas stating things about your product that are positive is a strong one.

Headline: Setting the tone

The headline is the first thing a person will see when they load the page. ( Well, in theory, anyway.)

So, I spent my time brainstorming potential headlines that would set the tone for the rest of the page. Tone, of course, being a bit playful and irreverent, but still smart and get-down-to-business, because that’s how we roll (as a company, and as a software product). 

I decided up front that “Freckle Time Tracking” wasn’t good enough. If you tell people “Oh, we do time tracking software,” their eyes immediately glaze over. 

More importantly, if I tell you “time tracking” you immediately think of all those other apps that do time tracking. Those apps are mostly the same. It sets (incorrect) expectations: Oh, a time tracking app. I know what that looks like. 

If your app takes a really different approach, like ours, you’ve just screwed the pooch, and you haven’t even closed your </h1> yet!  

So really, my number two goal was to set the tone—the number one goal was to provoke a bit of curiosity. 

One headline I toyed with was: Sorry, control freaks!

The one that won, for now? 

Goodbye, Administrivia.

Is it perfect? No. But it’s surely better than “Freckle Time Tracking.” Or something nauseatingly self-congratulatory, like “Time Tracking: Solved” or some such. 

The others aren’t worth mentioning; they were various shades of boring, predictable, and ho-hum. That’s how it always is when you want to do good shit. Gotta keep cranking through all the predictable stuff until something cool sneaks through by accident.

Set the stage: highlighting the problem

But you can’t just drop benefits into a potential customer’s lap, and expect to get anywhere. It’s like trying to walk through a door that isn’t open. You’re just going to walk away with a big embarassing bruise on your forehead.

So, before popping out benefits, I tried to open the door. I tried to get the visitor in the mood to hear about benefits. That means getting them to think about their current lack of benefits.

My goal with the first two paragraphs on the page was to set the stage:

Frustration—many people find time tracking to be a truly ornerous task, because of bad software, mostly. So, first, I bring up the image of how awful it usually is, followed by the premise: Freckle can make it better.

Raising the question—does the visitor’s current system support the visitor in these critical ways? Freckle does.

Deliver the solution: benefits

And then, with the benefits work I did above, I wrote the copy for the benefits section—below the call to action for the tour. In case people weren’t ready for the tour yet.

This section I edited, over and over. Every time I wrote anything that sounded like a feature, I ripped it out and started again. I kept bringing the focus back to you, you, you. Our potential customers don’t want to hear about us unless it’s how we can help them. (Fundamental human fact: Your customer is the most important person in the world. Everybody goes through life looking at everything relative to them. You, too.)

I tried to make headlines for these mini-sections that would be descriptive, but, like the big heading up top, create a tone that fits with our software and our audience, and create curiosity as well.

I selected screenshots, especially, that showcased the little touches in Freckle, and the brightness and cheerfulness.

Lay it all out: features

Finally, for those who are less interested in touchy-feely benefits, who want cold hard facts: a feature list. 

I grouped the features by broad category, situating them in context to show how they created the great user experience.

Everything we say about Freckle, I want to always bring it back to that user experience. Even though we’ve got a lot of features that the competition don’t, what really ties it all together is the experience of using it. 

Now, your turn

Do you have a product with a sales page? How’d you decide to create your content?

And…Would you like more articles like this?

via good coders code, great reuse by Peteris Krumins on 11/11/09

As you all may know, I watched and posted my lecture notes of the whole MIT Introduction to Algorithms course. In this post I want to summarize all the topics that were covered in the lectures and point out some of the most interesting things in them.

Actually, before I wrote this article, I had started writing an article called “The coolest things that I learned from MIT’s Introduction to Algorithms” but quickly did I realize that what I was doing was listing the topics in each article and not really pointing out the coolest things. Therefore I decided to write a summary article first (I had promised to do so), and only then write an article on really the most exciting topics.

Talking about the summary, I watched a total of 23 lectures and it resulted in 14 blog posts. It took nearly a year to publish them here. The first blog post in this series was written in August 2008, and the last in July 2009. Here is a list of all the posts:

I’ll now go through each of the lectures. They require quite a bit of math knowledge to understand. If you are uncertain about your math skills, I’d suggest reading Knuth’s Concrete Mathematics book. It contains absolutely all the necessary math to understand this course.

Lecture 1: Analysis of Algorithms

If you’re a student, or even if you’re not, you must never miss the first lecture of any course, ever! The first lecture tells you what to expect from the course, how it will be taught, what it will cover, who the professor is, what the prerequisites are, and a bunch of other important and interesting things.

In this lecture you also get to know professor Charles E. Leiserson (author of CLRS) and he explains the following topics:

  • Why study algorithms and their performance?
  • What is the analysis of algorithms?
  • What can be more important than the performance of algorithms?
  • The sorting problem.
  • Insertion sort algorithm.
  • Running time analysis of insertion sort.
  • Asymptotic analysis.
  • Worst-case, average-case, best-case running time analysis.
  • Analysis of insertion sort’s worst-case running time.
  • Asymptotic notation - theta notation - Θ.
  • Merge sort algorithm.
  • The recursive nature of merge sort algorithm.
  • Running time recurrence for merge sort.
  • Recursion trees.
  • Running time analysis of merge sort by looking at the recursion tree.
  • General recurrence for divide and conquer algorithms.

I personally found the list of things that can be more important than the performance of the program interesting. These things are modularity, correctness, maintainability, security, functionality, robustness, user-friendliness, programmer’s time, simplicity, extensibility, reliability, scalability.

Follow this link to the full review of lecture one.

Lecture 2: Analysis of Algorithms (continued)

The second lecture is presented by Eric Demaine. He’s the youngest professor in the history of MIT.

Here are the topics that he explains in the second lecture:

  • Asymptotic notation.
  • Big-o notation - O.
  • Set definition of O-notation.
  • Capital-omega notation - Ω.
  • Theta notation - Θ.
  • Small-o notation - o.
  • Small-omega notation - ω.
  • Solving recurrences by substitution method.
  • Solving recurrences by recursion-tree method.
  • Solving recurrences by the Master’s method.
  • Intuitive sketch proof of the Master’s method.

An interesting thing in this lecture is the analogy of (O, Ω, Θ, o, ω) to (≤, ≥, =, <, >).

For example, if we say f(n) = O(n2) then by using the analogy we can think of it as f(n) ≤ c·n2, that is, function f(n) is always smaller than or equal to c·n2, or in other words, it’s bounded above by function c·n2, which is exactly what f(n) = O(n2) means.

Follow this link to the full review of lecture two.

Lecture 3: Divide and Conquer

The third lecture is all about the divide-and-conquer algorithm design method and its applications. The divide and conquer method solves a problem by 1) breaking it into a number of subproblems (divide step), 2) solving each problem recursively (conquer step), 3) combining the solutions (combine step).

Here are the topics explained in the third lecture:

  • The nature of divide and conquer algorithms.
  • An example of divide and conquer - merge sort.
  • Solving for running time of merge sort by Master’s method.
  • Binary search.
  • Powering a number.
  • Fibonacci numbers.
  • Algorithms for computing Fibonacci numbers.
  • Fibonacci by naive recursive algorithm.
  • Fibonacci by bottom-up algorithm.
  • Fibonacci by naive recursive squaring.
  • Fibonacci by matrix recursive squaring.
  • Matrix multiplication
  • Strassen’s algorithm.
  • VLSI (very large scale integration) layout problem.

I was the most impressed by the four algorithms for computing Fibonacci numbers. I actually wrote about one of them in my publication “On the Linear Time Algorithm For Finding Fibonacci Numbers,” which explains how this algorithms is actually quadratic in practice (but linear in theory).

Follow this link to the full review of lecture three.

Lecture 4: Sorting

Lecture four is devoted entirely to the quicksort algorithm. It’s the industry standard algorithm that is used for sorting in most of the computer systems. You just have to know it.

Topics explained in lecture four:

  • Divide and conquer approach to sorting.
  • Quicksort algorithm.
  • The partition routine in the quicksort algorithm.
  • Running time analysis of quicksort.
  • Worst-case analysis of quicksort.
  • Intuitive, best-case analysis of quicksort.
  • Randomized quicksort.
  • Indicator random variables.
  • Running time analysis of randomized quicksort in expectation.

I loved how the idea of randomizing the partition subroutine in quicksort algorithm led to a running time that is independent of element order. The deterministic quicksort could always be fed an input that triggers the worst-case running time O(n2), but the worst-case running time of randomized quicksort is determined only by the output of the random number generator.

I once wrote another post about quicksort called “Three Beautiful Quicksorts” where I summarized what Jon Bentley’s had to say about the experimental analysis of quicksort’s running time and how the current quicksort algorithm looks in the industry libraries (such as c standard library, which provides qsort function).

Follow this link to the full review of lecture four.

Lecture 5: Sorting (continued)

Lecture five continues on sorting and looks at what limits the running time of sorting to O(n·lg(n)). It then breaks out of this limitation and shows several linear time sorting algorithms.

Topics explained in lecture five:

  • How fast can we sort?
  • Comparsion sort model.
  • Decision trees.
  • Comparsion sort algorithms based on decision trees.
  • Lower bound for decision-tree sorting.
  • Sorting in linear time.
  • Counting sort.
  • The concept of stable sorting.
  • Radix sort.
  • Correctness of radix sort.
  • Running time analysis of radix sort.

The most interesting topic here was how any comparison sort algorithm can be translated into a decision tree (and vice versa), which limits how fast we can sort.

Follow this link to the full review of lecture five.

Lecture 6: Order Statistics

Lecture six deals with the order statistics problem - how to find the k-th smallest element among n elements. The naive algorithm is to sort the list of n elements and return the k-th element in the sorted list, but this approach makes it run in O(n·lg(n)) time. This lecture shows how a randomized, linear-time algorithm (in expectation) for this problem can be constructed.

Topics explained in lecture six:

  • Order statistics.
  • Naive order statistics algorithm via sorting.
  • Randomized divide and conquer order statistics algorithm.
  • Expected running time analysis of randomized order statistics algorithm.
  • Worst-case linear-time order-statistics.

An interesting point in this lecture is that the worst-case, deterministic, linear-time algorithm for order statistics isn’t being used in practice because it performs poorly compared to the randomized linear-time algorithm.

Follow this link to the full review of lecture six.

Lecture 7: Hashing

This is the first lecture of two on hashing. It introduces hashing and various collision resolution strategies.

All the topics explained in lecture seven:

  • Symbol table problem.
  • Direct-access table.
  • The concept of hashing.
  • Collisions in hashing.
  • Resolving collisions by chaining.
  • Analysis of worst-case and average-case search time of chaining.
  • Hash functions.
  • Division hash method.
  • Multiplication hash method.
  • Resolving collisions by open addressing.
  • Probing strategies.
  • Linear probing.
  • Double hashing.
  • Analysis of open addressing.

Follow this link to the full review of lecture seven.

Lecture 8: Hashing (continued)

The second lecture on hashing. It addresses the weakness of hashing - for any choice of hash function, there exists a bad set of keys that all hash to the same value. An adversary can take an advantage of this and attack our program. Universal hashing solves this problem. The other topic explained in this lecture is perfect hashing - given n keys, how to construct a hash table of size O(n) where search takes O(1) guaranteed.

All the topics in lecture eight:

  • Weakness of hashing.
  • Universal hashing.
  • Construction of universal hash functions.
  • Perfect hashing.
  • Markov inequality.

Follow this link to the full review of lecture eight.

Lecture 9: Search Trees

This lecture primarily discusses randomly built binary search trees. (It assumes you know what binary trees are.) Similar to universal hashing (see previous lecture), they solve a problem when you need to build a tree from untrusted data. It turns out that the expected height of a randomly built binary search tree is still O(lg(n)), more precisely, it’s expected to be 3·lg(n) at most.

Topics explained in lecture nine:

  • What are good and bad binary search trees?
  • Binary search tree sort.
  • Analysis of binary search tree sort.
  • BST sort relation to quicksort.
  • Randomized BST sort.
  • Randomly built binary search trees.
  • Convex functions, Jensen’s inequality.
  • Expected height of a randomly built BST.

The most surprising idea in this lecture is that the binary search tree sort (introduced in this lecture) does the same element comparsions as quicksort, that is, they produce the same decision tree.

Follow this link to the full review of lecture nine.

Lecture 10: Search Trees (continued)

This is the second lecture on search trees. It discusses self-balancing trees, more specifically, red-black trees. They balance themselves in such a manner that no matter what the input is, their height is always O(lg(n)).

Topics explained in lecture ten:

  • Balanced search trees.
  • Red-black trees.
  • Height of red-black trees.
  • Rotations in binary trees.
  • How to insert an element in a red-black tree?
  • Insert-element algorithm for red-black trees.

Follow this link to the full review of lecture ten.

Lecture 11: Augmenting Data Structures

The eleventh lecture explains how to build new data structures out of existing ones. For example, how to build a data structure that you can update and query quickly for the i-th smallest element. This is the problem of dynamic order statistics and an easy solution is to augment a binary tree, such as a red-black tree. Another example is interval trees - how to quickly find an interval (such as 5-9) that overlaps some other intervals (such as 4-11 and 8-20).

Topics explained in lecture eleven:

  • Dynamic order statistics.
  • Data structure augmentation.
  • Interval trees.
  • Augmenting red-black trees to have them perform as interval trees.
  • Correctness of augmented red-black tree data structure.

Augmenting data structures require a lot of creativity. First you need to find an underlying data structure (the easiest step) and then think of a way to augment it with data to make it do what you want (the hardest step).

Follow this link to the full review of lecture eleven.

Lecture 12: Skip Lists

This lecture explains skip lists, which is a simple, efficient, easily implementable, randomized search structure. It performs as well as a balanced binary search tree but is much easier to implement. Eric Demaine says he implemented it in 40 minutes before the class (10 minutes to implement and 30 to debug).

In this lecture Eric builds this data structure from scratch. He starts with a linked list and builds up to a pair of linked lists, to three linked lists, until it finds the optimal number of linked lists needed to achieve logarithmic search time.

Next he continues to explain how to algorithmically build such a structure and proves that the search in this data structure is indeed quick.

Follow this link to the full review of lecture twelve.

Lecture 13: Amortized Analysis

Amortized analysis is a technique to show that even if several operations in a sequence of operations are costly, the overall performance is still good. A good example is adding elements to a dynamic list (such as a list in Python). Every time the list is full, Python has to allocate more space and this is costly. Amortized analysis can be used to show that the average cost per insert is still O(1), even though Python occasionally has to allocate more space for the list.

Topics explained in lecture thirteen:

  • How large should a hash table be?
  • Dynamic tables.
  • Amortized analysis.
  • Accounting method of amortized analysis.
  • Dynamic table analysis with accounting method.
  • Potential method of amortized analysis.
  • Dynamic table analysis with potential method.

This is one of the most mathematically complicated lectures.

Follow this link to the full review of lecture thirteen.

Lecture 14: Self-Organizing Lists and Competitive Analysis

This lecture concentrates on self-orginizing lists. A self-organizing list is a list that reorders itself to improve the average access time. The goal is to find a reordering that minimizes the total access time. For example, each time an element is accessed, it’s moved to the front of the list, hoping that it might be accessed soon again. This is called move-to-front heuristic.

Competitive analysis can be used to theoretically reason how well such a strategy as moving items to front performs.

Topics explained in lecture fourteen:

  • Self-organizing lists.
  • Online and offline algorithms
  • Worst-case analysis of self-organizing lists.
  • Competitive analysis.
  • Move-to-front heuristic for self-organizing lists.
  • Amortized cost of move-to-front heuristic.

Follow this link to the full review of lecture fourteen.

Lecture 15: Dynamic Programming

This lecture is about the dynamic programming algorithm design technique. It’s a tabular method (involving constructing a table or some part of a table) that leads to a much faster running time of the algorithm.

The lecture focuses on the longest common subsequence problem, first showing the brute force algorithm, then a recursive one, and finally a dynamic programming algorithm. The brute force algorithm is exponential in the length of strings, the recursive one is also exponential, but the dynamic programming solution is O(n·m) where n is the length of one string, and m is the length of the other.

Topics explained in lecture fifteen:

  • The idea of dynamic programming.
  • Longest common subsequence problem (LCS).
  • Brute force algorithm for LCS.
  • Analysis of brute-force algorithm.
  • Simplified algorithm for LCS.
  • Dynamic programming hallmark #1: optimal substructure.
  • Dynamic programming hallmark #2: overlapping subproblems.
  • Recursive algorithm for LCS.
  • Memoization.
  • Dynamic programming algorithm for LCS.

The most interesting thing in this lecture is the two hallmarks that indicate that the problem may be solved with dynamic programming. They are “optimal substructure” and “overlapping subproblems”.

The first one means that an optimal solution to a problem contains the optimal solution to subproblems. For example, if z = LCS(x,y) - z is the solution to the problem LCS(x,y) - then any prefix of z is a solution to LCS of a prefix of x and prefix of y (prefix of z is a solution to subproblems).

The second one means exactly what it says, that the problem contains many overlapping subproblems.

Follow this link to the full review of lecture fifteen.

Lecture 16: Greedy Algorithms

This lecture introduced greedy algorithms via the minimum spanning three problem. The minimum spanning tree problem asks to find a tree that connects all the vertices of a graph with minimum edge weight. It seems at first that dynamic programming solution could solve it effectively, but if analyzed more carefully, it can be noticed that the problem exhibits another powerful property — the best solution to each of the subproblems leads to globally optimal solution. Therefore it’s called greedy, it always chooses the best solution for subproblems without ever thinking about the whole problem in general.

Topics explained in lecture sixteen:

  • Review of graphs.
  • Graph representations.
  • Adjacency matrices.
  • Adjacency lists.
  • Sparse and dense graphs.
  • Hand shaking lemma.
  • Minimum spanning trees (MSTs).
  • Hallmark for greedy algorithms: greedy choice property.
  • Prim’s algorithm for finding MST.
  • Running time analysis of Prim’s algorithm.
  • Idea of Kruskal’s algorithm for MSTs.

Follow this link to the full review of lecture sixteen.

Lecture 17: Shortest Path Algorithms

This lecture starts a trilogy on shortest path algorithm. In this first episode single-source shortest path algorithms are discussed. The problem can be described as following — how to get from one point on a graph to another by traveling the shortest distance (think of a road network). The Dijkstra’s algorithm solves this problem effectively.

Topics explained in lecture seventeen:

  • Paths in graphs.
  • Shortest paths.
  • Path weights.
  • Negative path weights.
  • Single-source shortest path.
  • Dijkstra’s algorithm.
  • Example of Dijkstra’s algorithm.
  • Correctness of Dijkstra’s algorithm.
  • Unweighted graphs.
  • Breadth First Search.

The most interesting thing here is that the Dijkstra’s algorithm for unweighted graphs reduces to breadth first search algorithm which uses a FIFO instead of a priority queue because there is no longer a need to keep track of the shortest distance (all the paths have the same weight).

Follow this link to the full review of lecture seventeen.

Lecture 18: Shortest Path Algorithms (continued)

The second lecture in trilogy on shortest paths deals with single-source shortest paths that may have negative edge weights. Bellman-Ford algorithm solves the shortest path problem for graphs with negative edges.

Topics explained in lecture eighteen:

  • Bellman-Ford algorithm for shortest paths with negative edges.
  • Negative weight cycles.
  • Correctness of Bellman-Ford algorithm.
  • Linear programming.
  • Linear feasibility problem.
  • Difference constraints.
  • Constraint graph.
  • Using Bellman-Ford algorithm to solve a system of difference constraints.
  • Solving VLSI (very large scale integration) layout problem via Bellman-Ford.

Follow this link to the full review of lecture eighteen.

Lecture 19: Shortest Path Algorithms (continued)

The last lecture in trilogy deals with all-pairs shortest paths problem — determine of the shortest distances between every pair of vertices in a given graph.

Topics explained in lecture nineteen:

  • Review of single source shortest path problem.
  • All-pairs shortest paths.
  • Dynamic programming.
  • Idea from matrix multiplication.
  • Floyd-Warshall algorithm for all-pairs shortest paths.
  • Transitive closure of directed graph.
  • Johnson’s algorithm for all-pairs shortest paths.

An interesting point here is how the Floyd-Warshall algorithm that runs in O((number of vertices)3) can be transformed into something similar to Strassen’s algorithm to compute the transitive closure of a graph (now it runs in O((number of vertices)lg7).

Follow this link to the full review of lecture nineteen.

Lecture 20: Parallel Algorithms

This is an introductory lecture to multithreaded algorithm analysis. It explains the terminology used in multithreaded algorithms, such as, work, critical path length, speedup, parallelism, scheduling, and others.

Topics explained in lecture twenty:

  • Dynamic multithreading.
  • Subroutines: spawn and sync.
  • Logical parallelism and actual parallelism.
  • Multithreaded computation.
  • An example of a multithreaded execution on a recursive Fibonacci algorithm.
  • Measuring performance of a multithreaded computation.
  • The concept of speedup.
  • Maximum possible speedup.
  • Linear speedup.
  • Super-linear speedup.
  • Parallelism.
  • Scheduling.
  • Greedy scheduler.
  • Grand and Brent theorem of competitiveness of greedy schedules.
  • *Socrates and Cilkchess chess programs.

Follow this link to the full review of lecture twenty.

Lecture 21: Parallel Algorithms (continued)

The second lecture on parallel algorithms shows how to design and analyze multithreaded matrix multiplication algorithm and multithreaded sorting.

Topics explained in lecture twenty-one:

  • Multithreaded algorithms.
  • Multithreaded matrix multiplication.
  • Performance analysis of the multithreaded matrix multiplication algorithm.
  • Multithreaded sorting.
  • Multithreaded merge-sort algorithm.
  • Parallel-merge subroutine.
  • Analysis of merge-sort with parallel-merge subroutine.

Follow this link to the full review of lecture twenty-one.

Lecture 22: Cache Oblivious Algorithms

Cache-oblivious algorithms take into account something that has been ignored in all the algorithms so far, particularly, the cache. An algorithm that can be transformed into using cache effectively will perform much better than a one that doesn’t. This lecture is all about how to lay out data structures in memory in such a way that memory transfers are minimized.

Topics explained in lecture twenty-two:

  • Modern memory hierarchy.
  • The concept of spatial locality and temporal locality.
  • Two-level memory model.
  • Cache-oblivious algorithms.
  • Blocking of memory.
  • Memory transfers in a simple scanning algorithm.
  • Memory transfers in string-reverse algorithm.
  • Memory analysis of binary search.
  • Cache oblivious order statistics.
  • Cache oblivious matrix multiplication algorithm.

Follow this link to the full review of lecture twenty-two.

Lecture 23: Cache Oblivious Algorithms (continued)

This is the final lecture of the course. It continues on cache oblivious algorithms and shows how to store binary search trees in memory so that memory transfers are minimized when searching in them. It wraps up with cache oblivious sorting.

Topics explained in lecture twenty-three:

  • Static search trees.
  • Memory efficient layout of static binary search trees in memory.
  • Analysis of static search trees.
  • Cache aware sorting.
  • Cache-oblivious sorting.
  • Funnel sort.
  • K-funnel data structure.

This is the most complicated lecture in the whole course. It takes a day to understand the k-funnel data structure.

Follow this link to the full review of lecture twenty-three.

That’s it. This was the final lecture. I hope you find this summary useful.

Upcoming on my blog — review of MIT’s Linear Algebra course.

At first I thought I’d post Linear Algebra to a separate blog section that does not appear in the RSS feed but then I gave it another thought and came to a conclusion that every competent programmer must know the linear algebra and therefore it’s worth putting them in the feed.

You can surely be a good programmer without knowing linear algebra, but if you want to work on great problems and make a difference, then you absolutely have to know it.

Stay tuned!