Arbeite hart – nicht smart?

Sollten wir wirklich alle härter arbeiten und uns diesem ganzen Optimierungs- und Automatisierungs-Kram nicht hingeben? Ist harte Arbeit wirklich die bessere Arbeit?

Mein lieber Podcast-Kollege Serge, hat vor zwei Wochen eine interessante Episode zum Thema harte Arbeit vs. smarte Arbeit veröffentlicht.

Die Essenz seiner Episode: Arbeite lieber erst einmal hart, bevor du anfängst Dinge zu optimieren.

Dem muss ich leider widersprechen.

Hart nicht smart

Serge fußt seine Aussage auf einen Spruch, den er in letzter Zeit immer häufiger hört: Arbeite smart, nicht hart. Und ich kann verstehen, dass ihn diese Aussage stört und ich weiß auch, worauf er hinaus will. Ich bin allerdings der Meinung, er zieht die falschen Rückschlüsse.

“Work smart, not hard!” ist ein Spruch für Faule, die ihre Arbeit nicht lieben

Sorry Serge, aber das ist falsch.

Der Fehler in der Aussage

Serge spricht in seinem Podcast davon, dass man, bevor man anfängt zu optimieren und zu automatisieren, erst einmal viel harte Arbeit investieren muss.

Da horche ich als Entwickler sofort auf!

Hat er das gerade wirklich so gemeint? Ich glaube ja nicht wirklich. Ich glaube Serge hat einen Schritt zu kurz gedacht oder er hat als Kreativer (Designer, Fotograf, Musiker) einfach einen anderen Blick auf die Dinge.

Ich bin nun schon seit über 10 Jahren hauptberuflich Entwickler und wenn ich eine Sache gelernt habe, dann dass ich ständig optimieren und automatisieren muss!

Der Fehler, den Serge hier begeht, liegt im Detail und vielleicht auch darin, wie der oben genannte Spruch mit der Zeit verdreht wurde:

Smarte Arbeit schließt harte Arbeit nicht aus. Im Gegenteil.

Smarte Arbeit, Variante 1: Optimieren und Automatisieren

Wie in jeder Branche, gibt es auch in meiner gute Entwickler und schlechte Entwickler. Ein Indikator dafür, auf welcher Seite man sich befindet, ist die Herangehensweise ans Programmieren.

Der schlechte Entwickler arbeitet durchaus hart und viel. Er produziert viel Quellcode, was auf den ersten Blick sehr produktiv aussieht.

Er bekommt eine Aufgabe und löst diese. Arbeitet an einer anderen Sache weiter und muss auch dort das gleiche Problem lösen. Also erinnert er sich an das vorherige Projekt und kopiert die Lösung, passt sie vielleicht noch ein bisschen an.

Der gute Entwickler arbeitet auch hart und viel. Er produziert nicht so viel Quellcode, leistet er deswegen weniger?

Er bekommt eine Aufgabe und löst diese. Arbeitet an einer anderen Sache weiter und muss auch dort das gleiche Problem lösen. Also erinnert er sich an das vorherige Projekt und kommt ins Grübeln…

Wenn ich als Programmierer eine Lösung mehr als einmal verwende, dann schrillen bei mir sofort die Alarmglocken los. Ich will diese Lösung nicht etliche Male über Projekte verteilt kopieren. Ich mache mal hier eine Änderung, mal da und irgendwann weiß ich gar nicht mehr, wo ich was gemacht habe.

Als guter Entwickler fange ich also an zu optimieren. Ich schaffe mir eine Lösung die ich übergreifen nutzen kann. Und am besten so, dass ich keine doppelte Arbeit mehr investieren muss. Ich optimiere und automatisiere.

Für mich als Entwickler macht das meinen Code besser handhabbar und kleiner. Ich mag am Ende weniger Quellcode produziert haben, aber dieser Quellcode ist effektiver!

Ohne zu optimieren und zu automatisieren könnte ich meinen Job auf dem Niveau, das von mir verlangt wird, nicht mehr machen. Punkt.

Wenn ich etwas am Quellcode ändere und speichere, dann laufen etliche Prozesse automatisiert los. Sie prüfen meinen Quellcode auf Fehler, verkleinern ihn, kopieren nötige Dateien, packen alles zusammen und schieben es auf den passenden Server oder in die passende App.

Wenn ich das alles ständig selber machen müsste, würde ich kaum noch zum Programmieren kommen.

Projekte werde immer umfangreicher, immer komplexer. Die Technik ändert sich laufend. Ich muss automatisieren, weil ich sonst zu viel Zeit in Dinge investiere, die mich nicht voranbringen! Ich würde sonst meine Arbeit nicht rechtzeitig fertig bekommen und könnte manche Jobs gar nicht annehmen.

Smarte Arbeit, Variante 2: s.m.a.r.t.

Hierzu will ich gar nicht so viel schreiben, weil ich darüber schon ausführlich in meinem Podcast erzählt habe.

Es geht um das s.m.a.r.t. Prinzip. Auch das ist oft mit smarter Arbeit gemeint. Um es kurz zu machen: smart heißt in diesem Fall, ich plane meine Arbeite so, dass ich ein klares Ziel habe, welches ich messen und in einer gewissen Zeit auch abschließen kann.

Mehr dazu kannst du hier hören.

Warum erzähle ich das alles?

Weil ich die Punkte Optimierung und Automatisierung als extrem wichtig empfinde. Ich glaube, dass man künftig ohne diese Faktoren nur noch schwer erfolgreich sein kann, irgendwann wohlmöglich auf der Strecke bleibt.

Darum geht es mir bei Hack Your Business. Das ist der Kern des Ganzen. Es geht darum Prozesse zu optimieren, zu automatisieren, sich Tools zu schaffen, die einem das ermöglichen.

All das schließt harte Arbeit nicht aus, es sorgt nur dafür, dass wir uns mehr auf die wesentlichen Dinge konzentrieren können.

Niemand der ernsthaft ein Business aufbauen will, wird optimieren, automatisieren und sich dann auf die faule Haut legen können. Darin sind wir uns einig, Serge.

Aber dank Optimierung und Automatisierung sind wir in der Lage, die Geschwindigkeit zu erhöhen und effizienter zu arbeiten.

Darum geht es letztendlich.
Work smart - and hard!