The two kinds of Developers

Hi…

have you ever thought about the two fundamental types of developers?? OK, let me introduce my model to you:

Product Group versus Laboratory

Let us start with Lab guys first:

The laboratory developer:

* Short winded, things need to show quick results

* No care about architecture

* No care about security or performance

* Lots of ideas, very creative, thinks out of the box

* Willing to take risks

* Fails often but quick

* Typical work cycle: Idea – Prototype – Evangelize Prototype for broad usage

* Work cycle breaks on any position regularly because product fails

* Language of choice: Ruby, Python, Visual Basic, Expression SketchFlow was made for them

 

The product group developer:

* Stamina

* Cares a lot about architecture, security, quality, documentation

* Lots of ideas but within the box

* Failure is no option

* Risk avoidance

* Typical Workcycle is defined by a software development process

* If the workcycle breaks something severe has happened

* Language of choice: C#, C++, Java, UML

 

To bring it down to one word: Product Developers are all about engineering, Laboratory Developers are all about design. I went through my team and found good examples for both groups.

The better developer – product or lab? Both.

The answer is: You need both!! The lab guy helps you to be really creative and innovative but will hardly be able to deliver a profound quality product. While the product guy will struggle down any idea reaching to far beyond what we have today, those guys are able to build, deliver and maintain a quality product. Funny enough the lab guys normally take well build (product group) stuff and build on top. A shaky tower needs a strong basement.

More innovation – product or lab? Both.

Here again the answer is that both are innovative but on different types. While a product group does innovation in baby steps (start from the good that we have and extend a bit – not too risky – in a certain direction), the lab makes huge jumps but does not care on steady increase (I mean over several product releases).

Product and Lab – never mix!

Interestingly enough I heard a guy from a lab within Microsoft telling me that he normally tries not to hire somebody from product teams. In his opinion those guys are poisoned in their thinking (hey, he is a lab guy, ok?). He also told me that lab guys normally cannot switch to product groups because they tend to kill the process.

It is all about the handover. A company that is able to hand over ideas from the labs into the product groups is a killer…

CU

0xff

Teenager schafft Ruby Performance Boost… cool und peinlich

Hi…

ich habe das hier gefunden http://yokolet.blogspot.com/2009/11/japanese-teenage-boy-improved-ruby-19.html und es ist ja total cool was japanische Teenager schon so alles hinbekommen. Gratulation und Respekt. Eigentlich aber wieder eher ernüchternd…

Der Kollege fand einige Macros, die in wesentlichen Ruby Routinen stets zum Einsatz kamen und hat diese dann optimiert (keine erneute Berechnung wenn statische Werte vorkamen). Man würde jetzt so landläufig davon ausgehen, dass jeder Debugger bzw Profiler dies hätte zu Tage fördern müssen. Ergo: Scheinbar hat niemand mit solchen Tools den Code mal durchkämt.

Aber wie kann das gehen? Gibt es bei Open Source nicht das Prinzip der 1000 Augäpfel, die Aussage, dass irgendwo auf diesem Planeten ein hochintelligenter, hochmotivierter, zugegeben etwas masochistischer Programmierer lebt, der nicht schläft und daher in jeder Sekunde seiner Existenz nur Performance- und Security-Probleme löst??

OK, wieder einmal kann ich nur Damir Tomicic zitieren: “Ich verstehe umsonst, ich verstehe nicht Open Source!”.

CU

0xff