The never ending project...
-
Manche Menschen sind unbewusst nur am Prozess des Planens interessiert. Diese euphorischen Überlegungen im Voraus bremsen dann die persönliche Entwicklung ab, wenn etwas in der Wirklichkeit scheitert. Und hier geht man zu leichtsinnig mit dem Scheitern um und macht sich durch den falschen Mut nur noch mehr Druck.
Wenn du Freude an Konzeptentwürfen, Theorien und Gedankenspielen hast, solltest du es einfach hauptsächlich tun! Ich bin mir ziemlich sicher, dass du auf Dauer dadurch mehr Erfolg im Allgemeinen haben wirst. Auch wenn du später etwas ganz anderes entdeckst, so wirst du so bereits heute einen wichtigen Schritt tun. Du gehst quasi gegen deine Natur, wenn du Sachen machst, die dich vom Wesentlichen ablenken oder für die du noch nicht bereit bist.
Versuch, einen passenden Partner zu finden, der mehr für die Praxis hat als du. Wenn man sich gegenseitig ergänzt, kann man das gemeinsame Ziel durchaus ohne solche Stolpersteine verfolgen. Ich meine, dass ein Hobby keine Voraussetzungen außer Interesse braucht. Es soll dir Platz zur Selbstverwirklichung bieten und dich nicht durch strenge Disziplin "herrichten", um um jeden Preis Ziele zu erreichen.
-
TdZ schrieb:
...Und schon ist das ursprüngliche Projekt vergessen und man wurschtelt stundenlang irgendwelchen Müll zusammen, obwohl man gar nicht müsste. Oder noch schlimmer: Man verwirft andauernd sein Konzept und beginnt von vorn, weil irgendeine Kleinigkeit nicht perfekt ist.
Das deprimierende an der Sache: Nie wird was fertig... Nie!...
Kenne das nur zu gut. Ich muss regelmäßig meinen Dev Ordner leerräumen und die ganzen Sub- und Testprojekte rausschmeissen oder (in den seltensten Fällen) was archivieren. Ich sehe das einfach als Teil des Lernprozesses.
-
SideWinder schrieb:
Dafür hat man Manager erfunden. Sie sagen dir, falls du nicht bis morgen früh fertig bist hast du deinen Job die längste Zeit gehabt. Danach lässt man alles unnötige weg und programmiert zielstrebig und ohne lästige Log/Debug-Ausgaben (und jedenfalls ohne Kommentare).
Warum sollte sowas für private Projekte erstrebenswert sein? So einen Quark tu ich mir nur gegen Geld an.
-
TdZ schrieb:
Meine Freundin weiß grad mal, wie rum man die Tastatur hält, die kann mir schlecht was erzählen von dem, was ich so tu
Womit sie schon mehr weiss als so mancher Manager.
-
SideWinder schrieb:
Vielleicht kannst du deine Freundin oder jemand anderen bitten dein Manager zu sein?
Als ob die ein Interesse daran hätte dass er vor der Tastatur hockt...
-
Ich wollte ein Strategiespiel mit C++ und OpenGL programmieren; rausgekommen sind dabei bisher ein recht komplexer Raytracer, eine eigene Programmiersprache, ein Side-Scroller mit C# und ein Haufen Druckvorlagen für die Resultsets von SQL-Datenbankabfragen
Das Problem ist, dass ich mich so sehr in etwas hineinknien kann, dass ich vergesse, wo das grosse Ganze ist
MfG
-
-
Also wenn ich was gelernt habe ist es das man alleine bei Projekten nicht weit kommt, da man sehr schnell mit details abgelenkt wird. In einer Firma hat man ein klares Ziel und keiner will irgendwelche Spielereien haben.
Oft ist die Philosophie: 'Get it done and get it done fast no matter how'Als ich damals angefangen habe als Softwareentwickler zu arbeiten hatte man mir nur gesagt: 'Halte dich nicht lange mit dem Design auf. Schreib es einfach runter'
Das Problem an der Sache war dann natürlich am Ende, als mehr und mehr Features hinzugefügt wurden, das es ein einziges dependency Chaos wurde und features regelrecht reinhämmert wurden. Ich hatte das damals einfach damit abgetan das wir nur 2 Leute waren und wir im Grundegenommen kaum Zeit gehabt haben.
Aber wenn man aber bedenkt das eine Menge tools, die heute relativ häufig verwendet werden und aus dem Privat/OpenSource Sektor kommen, einfach mal eben so zusammen gehackt/gewurschtelt wurden, sollte einem klar werden das viele Projekte die lange brauchen um etwas zu stande zu bekommen eigentlich schon zum Scheitern verurteilt sind.
Lange Planphasen sind genauso tödlich wie die Verstrickung in unnötige details. Genauso wenn man sich dann darauf versteift alles selbst zu implementieren anstatt auf bestehende Libraries zurück zugreifen.
Ich grade was Privatprojekte angeht aus Erfahrung sprechen, ich habe mir schon viel vorgenommen was am Ende dann zu Vaporware wurde. Ich habe zwar ein paar kleinere libraries umgesetzt aber das war es dann auch schon.
Mein erstes richtiges Projekt das ich umgesetzt hatte war ewido anti-spyware 4.0 welches später dann AVG Anti-Spyware 7.5 wurde und heute nicht mehr existiert (wurde Ende 2008 als eigenständiges Produkt eingestampft) Das war mein erstes Projekt/Produkt an dem ich als Softwareentwickler gearbeitet habe.In größeren Firmen bei großen Projekten hingegen ist Design viel wichtiger da viele Leute an verschiedenen Teilen arbeiten die möglichst unabhängig von einander Entwickelt werden müssen. Das macht die ganze Sache natürlich auch ziemlich träge und die Entwicklung benötigt viel weniger Zeit als die Planung, da aber viel mehr Leute involviert sind verteilt sich die Arbeitslast auch.
BR
VinzenzEdit: PS: In diesem Post spiegelt sich nicht die allgemeinheit nieder, nur meine Erfahrungen auf diesem Gebiet.
-
/rant/ schrieb:
Ich wollte ein Strategiespiel mit C++ und OpenGL programmieren; rausgekommen sind dabei bisher ein recht komplexer Raytracer, eine eigene Programmiersprache, ein Side-Scroller mit C# und ein Haufen Druckvorlagen für die Resultsets von SQL-Datenbankabfragen
Das ist doch das Schöne an Hobbyprojekten, dass oft was ganz anderes rauskommt.
-
Das Faszinierende ist ja, dass man, sobald es um Geld oder Belohnung geht, sofort völlig anders arbeitet. Ich hab das zu Eingangs nicht erwähnt, aber ich bin ansonsten noch in Sachen Webentwicklung selbstständig und sobald dort die Kunden mit den Scheinen wedeln, gehe ich völlig zielstrebig und konsequent vor.
Daher wär es doch vielleicht eine Überlegung, sich selbst virtuelle Belohnungen zu erschaffen... nur wie?
Ach ja:
witte schrieb:
SideWinder schrieb:
Vielleicht kannst du deine Freundin oder jemand anderen bitten dein Manager zu sein?
Als ob die ein Interesse daran hätte dass er vor der Tastatur hockt...
Das kommt natürlich erschwerend hinzu
-
Ist es denn erstrebenswert das im Hobby Sektor genauso zu machen?
Mir macht es nichts aus wenn ich abschweife, oder mich in manche Sachen vertiefe die eigentlich "nichts bringen". Ist doch egal, solange es Spass macht...
-
blub² schrieb:
Ist es denn erstrebenswert das im Hobby Sektor genauso zu machen?
Mir macht es nichts aus wenn ich abschweife, oder mich in manche Sachen vertiefe die eigentlich "nichts bringen". Ist doch egal, solange es Spass macht...
Sehr richtig, es soll primär Spass machen. Wenn ich fürs Geschäft etwas programmieren soll, dann gehe ich das sowieso anders an (wobei ich in letzter Zeit bemerke, dass ich auch dort zum Perfektionisten geworden bin, auch wenn es um zerschossene Dinge wie JavaScript geht
); das wichtigste ist, dass die Vorgaben rechtzeitig erreicht werden.
-
Mir geht es ähnlich, habe soviel vor und bemängle oft das ich für das alles keine zeit habe.
Berufstätig, Verheiratet, da bleibt nicht viel Zeit.
Nur, wenn ich dann mal Zeit habe, fehlt mir plötzlich der Antrieb.
Meine jetzigen Libraries sind recht stabil, da ist derzeit nicht viel zu machen.
Meine Artikelserie zum Thema Lokalisierung wartet auch auf mich, und meine Privaten Projekte auch.Was mir sehr hilft sind die Projekte wo jemand auf etwas wartet.
Ich baue derzeit an ein Tool für ein Freund, er hat es bei mir in Auftrag gegeben und will es auch vergüten.
Auch ohne Vergütung, solch ein leichten druck brauch ich vermutlich. Das Tool ist schon sehr weit und braucht nicht mehr lange.Ich bin was Code an geht auch sehr genau, meistens, wenn mir die Architektur nicht gefällt, zieh ich mir ein paar Serien rein (derzeit Dexter) und überlege mir dabei eine neue Architektur, dann passt es und es geht voran. Aber ich schweife ab.
Mein derzeitiger Trick ist:1. Gute Architektur überlegen
2. Erstmal nur das nötigste implementierenWenn ein Feature etwas länger braucht bis es sauber ausgearbeitet ist, dann stell ich das Feature gleich hinten an, entweder ich implementiere es gleich und verrenne mich in Details, oder ich lass es erst mal komplett weg und implementiere es wenn die Hauptfunktionalität steht und das Tool benutzbar ist...
Merke:
- Refactoren kann man immer, wenn das Grundgerüst sauber ist, ist das kein Problem
- Nicht gleich in Details verrennen
- Nicht alle Features auf einmal implementieren, immer schön der reihe nach
- Entwickle in kurzen Sprints mit zwischen zielen. (scrum?)