Umfrage: Eure größten Produktivitäts-Boosts?
-
Ich suche nach guten Ideen, um typische Arbeitsabläufe beim Entwickeln zu verbessern.
Mein größter "boost" für meine persönliche Produktivität war das Verkürzen der Compile-Zeiten. Ein Projekt, an dem ich arbeite, musste für Mac als fat binary ausgeliefert werden, das heißt kompiliert und zusammengelinkt für ppc, i386 und x86_64. Das war in den Projekteinstellungen so vorgegeben, und wurde bei jedem Build-Vorgang so gemacht. Dann habe ich irgendwann mal lokal für mich nur noch für x86 gebaut und den multiple-architecture build nur noch ein- zweimal am Tag, zur Kontrolle. Seitdem kostete mich ein editieren-kompilieren-testen Zyklus nur noch 10 Sekunden statt knapp 40.
Worauf ich hinaus will, ist dass diese kürzere Kompilierzeit nicht nur 30 Sekunden spart, sondern 10 Sekunden zum kompilieren mir nicht genug Zeit lassen, in der Zeit "mal schnell die Mails zu checken, während es kompiliert". Nicht dass es 30 Sekunden weniger kompiliert, ist entscheidend, sondern dass es mich gedanklich im Entwicklungsprozess hält, statt mich zum Abschweifen zu verleiten.
Das hängt eng zusammen mit der Konzentrationsfrage, die ich hier auch gestellt habe.Was waren für euch die größten Verbesserungen im persönlichen Workflow, sei es Schreibtisch anders aufgestellt, zweiten Bildschirm angeschafft, neues Tool X eingesetzt, etc.. ?
-
Spontan denke ich da an Visual Assist X. Das hat schon den Komfort und die Produktivität erhöht. Monitor 2 und 3 aber auch.
-
PhilippM schrieb:
Seitdem kostete mich ein editieren-kompilieren-testen Zyklus nur noch 10 Sekunden statt knapp 40.
Wow. Bei unserem Projekt dauert schon das kompilieren und linken einzelner Dlls locker 10-20 Minuten, von dem ganzen Projekt 5-11 Stunden.
-
Mechanics schrieb:
PhilippM schrieb:
Seitdem kostete mich ein editieren-kompilieren-testen Zyklus nur noch 10 Sekunden statt knapp 40.
Wow. Bei unserem Projekt dauert schon das kompilieren und linken einzelner Dlls locker 10-20 Minuten, von dem ganzen Projekt 5-11 Stunden.
Ich kompilier ja nicht jedesmal das gesamte Projekt neu, sondern mach ein "make" und das kompiliert ja nur die Dateien, die ich wirklich verändert habe... "make clean; make" dauert schon _erheblich_ länger
-
10 Sekunden ist aber eher schon zu viel.
Gibt Untersuchungen zu dem Thema, ich glaube die "magische Grenze" die sie da gefunden haben war so ca. 3-5 Sekunden.
Wenn man von über dieser Grenze auf unter diese Grenze kommt, dann hat man nen irren Produktivitäts-Boost. Alles was sich oberhalb der Grenze abspielt ist wesentlich weniger wert. Und unterhalb der Grenze gibt's ebenfalls wieder "diminishing returns".Also von 3 Minuten auf 15 Sekunden bringt deutlich weniger als von 15 Sekunden auf 2 Sekunden, obwohl der Step 3 Minuten => 15 Sekunden sowohl absolut als auch prozentuell grösser ist.
(Ich könnte mir aber auch vorstellen, dass sich die 3-5 Sekunden etwas "strecken" lassen, wenn man dazwischen immer wieder "Progress-Updates" bekommt, also sich am Bildschirm irgendwas tut. Was beim Compilieren ja normalerweise so ist, es sei denn man leitet den Output in ein Logfile um)
p.S.: Visual Assist X ist cool, ja
Vor allem die Funktion "Refactor Rename" bringt mir sehr viel...
-
hustbaer schrieb:
Also von 3 Minuten auf 15 Sekunden bringt deutlich weniger als von 15 Sekunden auf 2 Sekunden, obwohl der Step 3 Minuten => 15 Sekunden sowohl absolut als auch prozentuell grösser ist.
Dann würds aber echt viel bringen, auf C# umzusteigen, weil da dauert das Kompilieren wirklich nur ein paar Sekunden, auch bei größeren Projekten. Bei C# sehen meine Testzyklen aber auch wirklich anders aus, als bei C++. Wenn ich C# programmiere, kompiliere und teste ich alle paar Zeilen, bei C++ schreib ich vielleicht erstmal einen Haufen Zeug und versuch dann vielleicht nach paar Stunden zum ersten mal zu kompilieren.
@PhilippM... Ich würde trotzdem nicht auf 10 Sekunden kommen... Zum einen dauert das Linken bei uns wesenttlich länger. Vor allem wenn die Festplatte grad etwas ausgelastet ist, kann das schon unerträglich lang dauern. Und das andere ist, unsere Codestruktur ist wirklich schlecht aufgebaut, es gibt zu viele wichtige Klassen, und wenn man eine der zentralen Headerdateien ändert, was doch häufiger vorkommt, muss man sehr viel neukompilieren, weil sie zumindest indirekt so ziemlich überall eingebunden werden. Aber das ist ein anderes Thema...
-
Mechanics schrieb:
Dann würds aber echt viel bringen, auf C# umzusteigen, weil da dauert das Kompilieren wirklich nur ein paar Sekunden, auch bei größeren Projekten.
Auch mit C# ist man schnell an dem Punkt angelangt wo das Kompilieren mehr als 3-5 Sekunden dauert. Zumindest wenn man an einer Klasse was ändert auf die fast alle Teile ne Dependency haben.
-
hustbaer schrieb:
p.S.: Visual Assist X ist cool, ja
Vor allem die Funktion "Refactor Rename" bringt mir sehr viel...Jo, bei mir auch. Die Funktion ist Gold wert. Und es ist wirklich unverständlich, dass sowas nicht schon im VS integriert ist. Kostet ja schließlich ein paar Mücken.
-
Tja, Eclipse kann das von Haus aus.
-
Lustig wie sich C++ Leute an einem primitiven rename refactoring oder 15 Sekunden compilezyklen aufgeilen können, wir sind doch nich mehr in den 70ern eh
-
314159265358979 schrieb:
Tja, Eclipse kann das von Haus aus.
Tja, das interessiert keine Sau.
-
Nur weil Leute skeptisch sind. Java IDE für C++ und so.
-
314159265358979 schrieb:
Nur weil Leute skeptisch sind. Java IDE für C++ und so.
Ja natürlich. Das KANN ja gar nicht funktionieren!
-
Mal was nicht Softwaretechnisches:
Der zweite Bildschirm tat schon sehr gut. Und US-Tastatur ist auch ganz, ganz wichtig. Nehme ich kaum mehr wahr, daher hätte ich sie fast vergessen.(Und die schnelle Kaffeemaschine
)
-
Wie tippst du denn die Umlaute und das ß?
-
Oh ja, Tastatur. Bei mir flutscht es viel besser, seit ich auf der Arbeit eine G15 mit Makro-Tasten nutze. Auf die habe ich mir einige VAX-Funktionen gelegt. Sehr komfortabel.
-
Sachen, die man mit vergleichsweise wenig Geld erschlagen kann:
- mehr Displays
- SSD
- genug Arbeitsspeicher um im Alltag nie darueber nachdenken zu muessen
Sachen, die sich mit leichten Gewohnheitsaenderungen erschlagen lassen:
- exzessive Versionskontrolle
- Bug-Tracking auch fuer kleine Projekte (notfalls ein simples BUGS-Textfile)
- Automatisierung/Reduktion von "Mach A, B und C, dann sollte das gehen" auf einzelne automatisierte Tasks
- automatisiertes Testen
Weniger leicht zu bewerkstelligen: Unterbrechungsfreie Arbeitsumgebung, Code-Review/Design-Sessions mit kompetenten Partnern.
Leicht und billig zu bewerkstelligen: Arbeit in kurze (1-1.5h funktionieren fuer mich gut) aber unterbrechungsfreie und konzentrierte Timeboxen aufteilen, nach jeder Timebox eine kurze Pause machen und diese nicht am Bildschirm verbringen, sondern ein paar Schritte auf und ab gehen, Tee nachfuellen, etc.
-
314159265358979 schrieb:
Wie tippst du denn die Umlaute und das ß?
AltGr+a = ä
AltGr+s = ßMit einem reinen US-Layout geht das natürlich nicht.
-
Ich arbeite gerne mit reinem US-Layout und kompensiere das dann in meinem Emacs durch sowas, falls ich Umlaute brauche:
(add-hook 'text-mode-hook (lambda () (set-input-method "german-postfix")))Damit werden ae, ue, oe, sz und Konsorten automatisch zu Umlauten ausgebessert und wenn man mal wirklich einzelne Buchstaben tippen moechte, schreibt man zB. aee.
Unter GNU/Linux laesst sich via Compose-Key auch recht viel machen, aber ich war immer zu faul, mir das genauer anzusehen. (Zumal ich ohnehin an sehr vielen verschiedenen Rechnern und Betriebssystemen arbeite, da waere es auch muehsam ueberall alles umstellen zu muessen.)
-
Bashar schrieb:
314159265358979 schrieb:
Wie tippst du denn die Umlaute und das ß?
AltGr+a = ä
AltGr+s = ßMit einem reinen US-Layout geht das natürlich nicht.
Genau so mache ich es auch. Ist dann lustig, wenn ich versuche auf deutscher Tastatur zu schreiben, dann sieht das immer so aus, als würde ich auf einer Tastatur ohne Umlaute schreiben
.
Ja, ist natürlich kein reines US-Layout, sondern stark gepimpt (ich habe auch so Sachen wie ¹²³µé usw. als Drittbelegung). Aber der entscheidende Vorteil ist noch vorhanden, nämlich das alle primären Zeichen dort zu finden sind, wo sie die Leute die Programmiersprachen und Software entwickeln auch haben. Ich konnte als Kind zum Beispiel nie verstehen, was in die Macher von MS-DOS gefahren ist, als Verzeichnistrennzeichen '\' zu nehmen. Selbst '/' wäre wenigstens nur Zweitbelegung gewesen (ich hatte als allererstes noch eine Tastatur ohne AltGr). Oder die Bedeutung von ' und ` und welcher Mensch die beiden beim Blick auf die Tastatur unterscheiden kann. Oder wie man '|' überhaupt tippt. Im Nachhinein gesehen ist all dies natürlich absolut logisch, wenn man die Tasten nur an der richtigen Stelle hat.
