From early on as a developer you quickly realise there are two types of people you work this: the doers and the talkers. Generally most CEO, marketing, sales and especially management people you deal with in any kind of bigger company, you quickly understand as being talkers. They talk about stuff but barely do it themselves and therefore have to deal with underlying sh*t they came up with. Coming from the Web-Agency-Business you also understand many of your clients actually are doers; to them it is more important to think and talk about a potential solution until every part is explored. But if software craftsmanship has taught us anything it is there are more possibilities than you can think of, which often comes back to you as there are more problems than you imagined in the first place, too.

As someone defining himself through the impact of his work, I naturally have a problem with talkers. Not only sometimes it feels like I am wasting time talking to them. And with OpenSource at my hand I am also very quick in finding out how much of a talker that other developer is. Because OpenSource taught me to read ones code and find the weak and really interesting points - aside from the usual glue code - and get to the bottom of what someone is able to do. Now I do see, that many projects, even OpenSource, are all build with certain restrictions around those and trade-offs you make. But the way you address those says even more: often the best solution is the quicker one.

The reason for that lies in the other major aspect of the world of doers, we work by the principles of “release early and release often”, because we learnt in software development, there is always time to fix stuff later. And more over we know that had we come up with in our head and we consider the best solution might as well be no solution at all. By releasing it early, we get feedback, not only from other developers but also from users and can very quickly figure out whether this is some worth pursuing. And more often than not, it actually turns out this problem we spend hours working on isn’t a problem in the first place, because the User actually never gets to that point and that part of the code it thrown away super quickly.

This is also very true for any kind of tech products. We really like to build these castles in the air but when it comes down to solving an actual problem, getting your solution out there and see how others use it, is of far more importance. So the way we work with Founders normally is by looking at the big picture, try to see what is the major, long-term goal and from that cut all back until we find the Minimum-Viable-Product, the absolute essence that needs to be there to proof this products value. And once we found this, we start building and try to ship it as quickly as possible.

There simply is no point imaging that huge castle at the end of the road, unless you know what the building bricks and walls are supposed to look like. And you won’t figure that out without trying. So, stop talking, get your head down and start building.