Jan Kubr

Archive for May 2008

, ,

The middlemen left, the floor is all yours

In Uncategorized on May 29, 2008 at 21:46

Today I bought some decoration for my room: wall stickers. It is exciting for me; probably not so much for you. What is interesting though is the way the purchase was made.

I bought these wall decals directly from its author, Shannon Jernigan from Fort Lauderdale. I negotiated the shipping costs with her and had a little chat about her marketing.

It is unbelievable how small you can be these days and how all the middlemen are gone even when you sell physical goods. You just get in touch directly with the craftswoman. She doesn’t need any distribution network, she just needs Etsy and the Internet network. She’s talking directly to her customers and thus gets the most direct feedback possible (right after meeting them in person). She can do for living what she loves doing (just needs to find enough people around the world who love what she makes) and be her own boss. The world is moving somewhere where I’ll like it to see.

, ,

A book read: Maus by Art Spiegelman

In Uncategorized on May 29, 2008 at 21:11

Maus is a comic book about Art’s father’s experiences during the Second World War. Jews are expressed as mice, nacists are cats, and other people dogs. This distinction makes it kind of easier to orientate in the story and to read through it faster. I’m not sure it was the author’s intent..

I guess you’ve heard a bit about holocaust. Right? You can get the sense of it again by reading this book; you can ask again how it is possible there could be so much hate against one race. What was so wrong with the Jews they were supposed to be exterminated? I just don’t get it.

Was the proper solution though just to take someone else’s ground and give it to them? And let them keep Palestinians in camps just like their fathers and grandmothers were?

Is all this because people won’t change but be cruel forever?

, ,

Pitched Flempo at Techcrunch Meet-up

In Uncategorized on May 25, 2008 at 10:46

Had the chance to pitch Flempo at the Prague Techcrunch/CrunchGear Meet-up. Except no one could hear me (just like all the other presenters), it was a good experience and another step for me to improve my (so far quite poor) speaking skills. Here you can see all the pitches of the night (mine starts arond 12:25).

,

Flempo: moving forward by removing features

In Uncategorized on May 18, 2008 at 19:48

Simple is hard. You can see it everywhere.

I worked with many programmers and most of them were able to produce working code. But only the code of the superstars was easily readable and looked simple although it did complicated things.

If someone works in a sort of complicated field (who doesn’t these days), it is very easy for them to confuse you within the first ten seconds of his explanation of their job. Although it is quite hard to understand these complicated things, it is much more difficult to explain them simply.

Flempo is mostly about people assigning tasks to each other. The idea seemed simple: You distribute people in teams and let the teams assign tasks to each other. The two teams represent a provider-customer relationship. Great. Now it turned out to be very confusing when implemented. If you want to assign tasks within one team, you need to set it as its customer or provider. When someone from a provider’s team wants to assign a task to someone for the customer’s team, it is not possible until you create the relationship in the other direction. (And you have to communicate this need to the users somehow). When setting up the relationship in the first place, you need to think which party is which. And so on. Although this was a very powerful and flexible concept, in practice it was too complicated to follow.

OK so the second step was making the relationship bidirectional. Instead of customers and providers, you just had partner teams. Partner teams could assign tasks to each other. Better. The need to create a team a partner of itself was still here, however. Now I didn’t mention that you can actually configure the attributes a task can have when created for certain team-team relationship. This is very powerful: you might require a deadline from someone, while only an affected component from someone else. However, when creating a task, this creates the need to explicitely state as a member of which team you are creating this task. Because if you create a task for the team C, it might have different attributes depending on whether you’re a member of A or B. This made the new task form confusing. Also, if you send a message to the team’s e-mail address, it creates a task for that team. Very neat. But which would be the team you created this task on behalf of? Unless forced to put something cryptic in the subject, no one knew.

Final step (at least for now): each task belongs to only one team. There is no two parties relationship, tasks can be assigned only by people within one team. This is enough for a project-oriented teams, but not so great for customer-provider relationships (people from both parties need to be in the same team “Providing services for C”), but reduces the complexity so much, that it was worthy of the change. I’ll need to come up with something that will support this kind of relationship better. But it needs to be.. yeah simple. And simple is what.. yeah hard.

, , ,

A book read: The Pragmatic Programmer by Andrew Hunt and David Thomas

In Uncategorized on May 17, 2008 at 20:57

The Pragmatic Programmer is a book that will help you become a better programmer. At least that’s what the authors say in the first sentence of it. I have to say.. they are right!

First a general remark. I’ve been discussing approaches to work with anyone I could ever since I started working more than a few hours a week and even more after reading The 4-Hour Workweek. In my opinion, going to work just because you “have to” (there are bills to pay) is the saddest thing ever. What more though, if you want to feel “comfortable”; meaning you don’t want to face any major challenges, you just want to do what you usually do and don’t care much, you might very well die now. If you don’t evolve, if you don’t learn, you stand at the same place while the world is moving. And it’s moving fast these days. I warned you.

Anyways, the great thing about The Pragmatic Programmer is that not only does it challenge you to be better at your job, but it also encourages you to never stop improving. And to care. That’s probably the crucial part. If you don’t care what the results of one third of your day are, you might just very well die now. (For the second time already, too bad.)

Now the book is a bit older (2000) and the authors are not the youngest folks either, so some of the technical aspects seem to be a bit obsolete. However, that is not the main strength of the book and thus no big deal. The book is full of great tips on how to improve your skills as well as the usefulness and maintainability of the code you produce. My take-aways from these three areas:

  1. Skills (& attitude): Care about your craft, think about your work, don’t make lame excuses (provide options instead), don’t live with broken windows (fix results of bad or obsolete decisions early), be a catalyst for change, make quality a requirement, invest in your knowledge portfolio, use a single editor well, don’t blame (fix the problem instead),  organize teams around functionality, don’t use manual procedures.
  2. Usefulness: Remember the big picture, prototype to learn, don’t gather requirements - dig for them, work with a user to think like a user.
  3. Maintainability: Write code that writes code, crash early (use assertions and raise exceptions in cases when something that “should never happen” happened), minimize coupling, design using services, refactor early and often, design to test and test (or your users will), test your tests (use saboteurs), find bugs once.

There are a lot of technical tips in the book (from not mentioned ones “Don’t repeat yourself” or “Make it easy to reuse”) and although some are a bit contradictory to each other, vast majority of them is crucial and very important. Thankfully, I was taught most of them in college (fortunate to go to a good school) and thus they weren’t such a big surprise for me anymore. If you haven’t heard them yet though, read twice!

That said, there was one technical abstraction I enjoyed: the principle of orthogonality. Two lines are orthogonal if moving along one of the lines doesn’t change your position projected onto the other one (e.g. they meet at right angles). This makes it great analogy to software design: making a change to one component shouldn’t affect any other component. Although it is almost impossible to achieve 100%, I found that analogy very interesting.

The last tip in the book summarizes it for me pretty well: Sign your work! Work to be proud of your results.

, , ,

A book read: “The Game: Penetrating the Secret Society of Pickup Artists” by Neil Strauss

In Uncategorized on May 6, 2008 at 14:07

This book took me forever to finish. Another one I wouldn’t buy myself, but was given by a friend and didn’t want to leave it half-read. The first third is fun an interesting, then it’s get super boring and in the end it states the obvious.

What’s crazy though is that it’s based on a real story! I thought it wasn’t true  (although the author claims the contrary in the beginning) after I found plenty of videos with the author proving that yes, he dates (dated?) a member of Courtney Love’s band, got Britney Spears’ phone number etc. Puts the whole story into a different light, actually.

Yes, so what is this book about you wanna know? It’s about how a writer who had had huge problems dating girls discovered online forums where men were exchanging tips on how to pick up women most effectively. And the best ones even had seminars where they taught their skills. You guessed it, what Neil did was that he went take these lessons to become a guru himself.

And that’s just the beginning of the story, but you won’t care much because it’s not all that interesting. You might pick this book up (how appropriate wording) to discover how to become a pickup artist yourself. Well, I guess they are better sources for that, but this book has some interesting tips, too. If you prefer quantity over quality, you might try one of these:

  1. You have three seconds to start talking to a girl after you notice each other. After that you can become too scared, she’ll think you’re weird, and the situation gets awkward.
  2. If your target is in a group of people, focus on men and less attractive women first. Make the group like you.
  3. If you’re easy to get, she won’t care.
  4. Be happy and smile.
  5. Be different than others (e.g. in what you wear, that you don’t buy her drinks, ask the same questions as everyone etc.)
  6. Dinner is too long for a first date. If you find out there’s not much you can talk about, it’ll be awkward (and she might deny your invitation because of this).

And many more. The good thing about these tips is that it might help you become a better communicator / deal maker / social person instead of (or together with) getting hundreds of women to bed. Basically many of them simply make you a better and more interesting person. And, oh, they will improve your chances of getting and keeping the one woman you’ll actually care about.


The practical alternative to work

In Uncategorized on May 5, 2008 at 18:19

Meetings. Hilarous.

Via Seth Godin’s Let’s skip the meeting.

,

Users won’t tell you what to do

In Uncategorized on May 4, 2008 at 21:19

When I released the first version of Flempo, I had this naive idea about user feedback. You just release something (anything) and people will tell you what to do next, right? No. Here’s a few observations I made (not only based on my experience with Flempo):

  • If people find something annoying, hard to use, or confusing - in other words something is not clear enough for them - they won’t run to tell you. They just go away or work around the problem. Even if they’ve invested a lot of time or money in the product, the fact that they have a problem with it might not get to you at all. They don’t care about you. They care about themselves.
  • Feedback buttons don’t do much. If you go talk to people (or run a survey, perhaps), they’ll tell you what they think about your product, what they do or don’t like. They don’t bother submitting any feedback though, unless they can significantly benefit from it.
    If you have thousands of users, maybe ten percent of them might give you some feedback. But are the loud ones a good enough sample to represent the whole user base? I doubt it.
  • The main thing you’ll hear from users are feature requests. People will have a lot of ideas about what to add to your product. Your job is to find the right reason they want that particular feature (Paul Buchheit has some interesting thoughts on that ) and think how you can help them do that without adding anything to your product. Right?
  • The only real feedback people give you is in using your site. That is the feedback you should use to improve it. Watch what people do and try to understand their needs and problems. Measure. Improve. Repeat.

To summarize, don’t expect your users to tell you what you should do. They might give you pretty good hints, but it will always be up to you to figure out where to take your product. But otherwise it would be far too easy, wouldn’t it?

, ,

Outsource what is not your core business

In Uncategorized on May 4, 2008 at 11:49

It’s come to me again. A while ago I wrote a few posts about Amazon S3 including how it gives you more freedom. Recently I’ve seen Jeff Bezos’ talk from Startup School 2008 where he shows how 300 years ago, if a company needed electricity, they had to have their own electric power generator. I can imagine that not so long ago, if you wanted a server connected to the Internet, you wouldn’t just rent one from your ISP and leave it in their hosting center, but you had to have your own DSL (or whatever) line and make sure it never goes down.

Now it would seem crazy to generate your own electricity or try to build your own hosting facilities if it’s not your core business. However, it’s not yet so obvious that you should outsource more than that. Any “heavy lifting”, as Jeff puts it, that is not your core business (and someone else can do it better and cheaper), should neither distract nor slow you down.