I’ve never considered myself a car aficionado, even though it may have slumbered in me for years. One of the earliest childhood memories I have is climbing behind the wheel of my parents’ car in my grandparents’ garden, testing the lights before we drove the 20 miles back home.
Between 1991 and 2009, my parents drove home six brand-new cars from the dealership. That’s one car in three years.
I myself never saw the use of a car. Sure, I was dreaming about buying new cars. In reality, however, I biked to school, then used bus and train to get to college and later, work. It was a 90-minute commute to college, but it wouldn’t have been less of a hassle to get there by car. I’ve been proud owner of a monthly pass for public transport since school.
What would I need a car for?
All that changed when the first child arrived. Standing in the rain, waiting 19 minutes for the next bus to pick us up at my parents’ neighborhood, pushing a stroller and carrying what normal people considered a week’s supplies for the baby (when we only spent a couple of hours at my parents’ house), just to be back at home an hour later, that’s not exactly what we consider fun. Especially if it takes less than half the time with a car, and no waiting.
We were 27 when we bought our first car, and it was only by opportunity: My parents-in-law wanted to get a new one and asked us if we were interested in the old one.
Since the car was a bargain and quite old, we had a healthy relationship with it – that is, we saw it as a means and didn’t grow too fond of it. Unfortunately, it didn’t grow too fond of us either and started piling up repair bills.
That’s about the time we decided to buy a substitute. In 2012, we bought our dream car: excellent condition, a list of features that makes your jaw drop (built-in sat nav, entertainment system, backup camera), the model in general had an outstanding reputation for durability and high gas mileage. It was two years old at the time.
Our parents supported us, giving us a low-interest loan. They insisted, even though we assured them it was within our means. We paid the last installment after two years, in May 2014.
One afternoon in early June, my son insisted on walking a slight detour home. I discovered that the car wasn’t where I thought I’d last parked it.
Being unsure about the whereabouts of our car wasn’t an entirely new concept. We didn’t move the car every day, sometimes we didn’t need the car for weeks at a time. And with parking space in the city being a scarce resource, you park wherever you find a free spot, not necessarily close to home. On top of that, our car had been towed more than once.
All of this means: It can take a while to realize your car has actually been stolen.
In 2011, the probability for car theft was 18 times higher in Berlin than in other parts of Germany. In 2013, over 6000 cars were stolen in Berlin. That’s 18 cars every single day. Most cars stolen in this city are never seen again, supposedly because of its proximity to Eastern Europe. The police officer who handled my report said: “Don’t get your hopes up.”
All this happened less than two months before we wanted to go on vacation for two weeks.
What followed was a myriad of forms from the police and the insurance. The police wanted to know the details of the theft and the circumstances of its discovery. The insurance naturally wanted to know if there’s any way they could avoid settlement for our claim.
Three weeks prior to our planned vacation, the insurance paid the replacement cost value.
We started searching for cars. Because we still had winter tires and the roof rack (for bikes carriers) and never once doubted the car itself, we wanted the exact same model.
After a few days, we found one just like the previous car. Its price tag left us paying 5% more than what we got back from the insurance, which was okay, given the circumstances.
When we took the car for a test-drive, ours had been missing 5 weeks. We didn’t drive often, but getting behind that wheel felt strangely familiar. The car felt like home. In hindsight, the purchase may have been a bit too emotional (which is never good) but the clock was ticking: Our vacation was just three weeks away, and renting a car and passing up this offer might have been an expensive move. So we signed the contract.
My wife picked up the car the following week, more than 2 weeks before our vacation, and I parked it on a friend’s parking space, behind two electric barriers. We didn’t have our resident’s parking permit yet, and without it, it gets expensive quickly.
The following weekend, exactly 2 weeks before our vacation, we reported our second car stolen from that space.
]]>5 lesenswerte Artikel zu unterschiedlichen Themen aus der Softwarebranche:
Teamdynamik ist für sich genommen schon ein faszinierendes Thema. Was nimmt man aber erst mit, wenn man fast ein Jahr auf engstem Raum zusammenlebt und den Elementen trotzt? Was lernt man über sich und die anderen? Tony Haile hat es herausgefunden und gibt interessante Einsichten preis.
Tony Haile: Four things I learned on a round-the-world yacht race
Es ist kein Geheimnis, dass ich Ruby als Programmiersprache sehr schätze. Damit einher geht ein ungutes Gefühl gegen gewisse andere Sprachen, ohne recht zu wissen wieso. Steve Yegge hat einen sehr treffenden Punkt gegen Java aufgegriffen und ihm einen (langen!) Blogpost gewidmet.
Steve Yegge: Execution in the Kingdom of Nouns
Mit meinem Interesse an DevOps wächst auch jenes an der Arbeitsweise von Administratoren. Diese Liste ist ein wahrer Rundumschlag, wenn es um Methoden und Praktiken in der Systemadministration geht.
Everything Sysadmin: 32 Questions for Your Sysadmin Team
Programmcode muss vorsichtig entwickelt werden, wenn er bestehen soll. Um Wildwuchs zu vermeiden, gibt es mit dem Law of Demeter einen Daumenregel, um strukturelle Kopplung in den Code zu bringen.
Avdi Grimm: Demeter: It’s not just a good idea. It’s the law.
Zu guter Letzt noch etwas Wissenschaftliches: Wie die Architektur von Casinos den Umsatz in ihnen beeinflusst. Daraus lässt sich einiges zum Design von z.B. Landing Pages ableiten.
]]>Dahinter steckt ein Prozess, eine Verwandlung. Zoologen sprechen von der „Umwandlung der Larvenform zum Adultstadium“.
[caption id="attachment_25744" align="alignright" width="240" caption="Foto: Wooden Wings von MrClean1982 (Lizenz: CC-BY-NC)"][/caption]
Die Raupe wird zum Schmetterling.
Aber welche Stufen der Entwicklung durchlaufen Testautoren dabei nun genau?
Der Sturkopf ist der Meinung, er käme ohne Tests schneller voran. Verschleiert mit durchaus plausiblen „Vorbehalten“ (die er mit sachkundigeren Kollegen teilt) die Tatsache, dass ihm kaum Vorzüge von Tests einfallen und er Tests bisher praktisch nicht angewandt hat.
Hat wahrscheinlich nie ein komplexes Projekt über einen längeren Zeitraum im Team entwickelt. Oder von anderen übernehmen und dann erweitern müssen. Oder einen neuen Kollegen in eine umfangreiche Code-Basis einarbeiten dürfen.
Der Sturkopf gehört zu den bedrohten Arten, muss aber nicht geschützt werden.
Wenn der Sturkopf sich irgendwann doch noch von Tests überzeugen lässt, wird er zunächst…
Der Anfänger hat die Notwendigkeit von Tests begriffen, kämpft aber meist noch mit den Grundlagen von Tests: Wie teste ich richtig? Was ist wichtig? Wie strukturiere ich Tests?
Der Anfänger wählt häufig den kompliziertesten Weg, um einfache Dinge zu testen. Aber das ist durchaus in Ordnung, wir alle lernen jeden Tag.
Schlecht ist dagegen, wenn aus der anfänglichen Unsicherheit Übereifer und sogar Obsession wird. Der Anfänger wird dann mit einiger Wahrscheinlichkeit…
Der Test-Nazi schreibt Tests für alles, was nicht bei drei auf den Bäumen ist — völlig unbeirrt von der Frage nach dem Nutzen.
Beherrscht Stubbing und Mocking perfekt, ohne sich der Gefahren dieser Methode bewusst zu sein (oder schlimmer noch: sie billigend in Kauf nehmend).
Achtet auf 100%-ige Testabdeckung des Codes. Zählt andere an, wenn nicht alle Ausnahmen im Code getestet sind. Achtet peinlichst auf Test-Design (z.B. DRY).
Doch spätestens, wenn er das erste Mal einen Großteil des Codes under Test löschen konnte, ohne dass die betroffenen Tests fehlschlagen, erkennt er die Folgen seines Tuns. Er erreicht die höchste Stufe der Entwicklung und wird…
Der Pragmatiker ist von Erfahrung geprägt. Er weiß um die Notwendigkeit von Tests (auch in Vorbereitung auf umfangreiche Refactorings) und die Gefährlichkeit von Stubbing/Mocking — gebranntes Kind scheut das Feuer.
Setzt auf Vernunft bei der Testabdeckung, weil er den den geschäftlichen Nutzen im Blick hat. Schreibt auf diese Weise Tests, die auch tatsächlich wirtschaftlich sind.
Diese Liste erhebt nicht den Anspruch, vollständig zu sein, sondern beruht auf persönlichen Beobachtungen.
Was ist deine Erfahrung mit den Entwicklungsstufen auf dem Weg zu guten Testautoren? Welche Typen kennst du? Sag's uns in den Kommentaren.
]]>Matthias Marschall war so freundlich, einige grundsätzliche Fragen zu DevOps zu beantworten.
Matthias ist im Web-Umfeld tätig und befasst sich mit dem Thema, seit er vor acht Jahren neben der kompletten Entwicklung einer großen Web-App auch für den Betrieb Verantwortung übernommen hat. Er lehrt Agile Methoden in Augsburg, bloggt über Agile Web Operations und will mit Dan Ackerson Techniker bei der Umsetzung von DevOps unterstützen.
According to a friend in the space, all you need to do is walk through Silicon Valley and shout, "Devops," and 300 people will run to a meetup.
Und auch auf den DevOpsDays kommen immer wieder weit über 100 Leute zusammen.
Natürlich ist da die eigene Kreativität gefragt. Es kommt sehr genau auf das Umfeld und die aktuelle Situation an.
Vielen Dank für die ausführlichen Antworten!
]]>Everyone in the software field has seen a parade of patents which do nothing but try to claim rights on techniques that have already been in use for years, let alone developments that while new, are are still obvious to those of us with ordinary skills in programming.
Martin Fowler: Software Patents
Computerprogramme aus der DDR? Die brauchte nach der Wende nun wirklich keiner mehr, glaubte man damals in der IT-Branche. Einer sah das anders. Rolf Heinemann machte aus dem Großkombinat VEB Robotron mithilfe eines Freundes ein internationales Software-Unternehmen.
brand eins: Der Überläufer
Aus eigener Erfahrung kann ich sagen, dass ein Accent im Namen schon immer Probleme bereitet hat. Auch noch Jahre später.
Daher habe ich mich gefreut, dass Patrick McKenzie gleich eine ganze Liste über falsche Annahmen bzgl. Namen erstellt hat:
So, as a public service, I’m going to list assumptions your systems probably make about names. All of these assumptions are wrong. Try to make less of them next time you write a system which touches names.
Patrick McKenzie: Falsehoods Programmers Believe About Names
Das Intranet der Zukunft ist gleichzeitig auch soziales Netzwerk: Jeder ist mit einem Profil vertreten, aus dem Interessen und Kompetenzen hervorgehen. Die Mitarbeiter können eigene Inhalte einstellen und ihr Wissen mit den Kollegen teilen. So wird das Expertenwissen innerhalb eines Unternehmens transparent und nutzbar.
ZEIT online: Digitaler Arbeitsplatz — Das allumfassende Intranet
With all the time, effort and money that Adobe spends on creating a “code free” solution for designing websites, you’d think that they would be able to create something decently usable by now. So what’s holding them back? Today we’ll take a brief walk down memory lane, starting all the way back at PageMill, to see if we can discover any reoccurring themes in Adobe’s history with web designers.
Joshua Johnson: Why Adobe Doesn’t Understand Web Designers
]]>Da ist es nicht verkehrt, über die Hintergründe Bescheid zu wissen. Das ist nützlich, wenn du irgendwann bei der Fehlerbehebung oder Erweiterung helfen willst, weil deine Software auf der Dritter aufbaut.
Es ist aber auch eine interessante Lektion über Abläufe und Methoden in verteilten Teams, die deiner Karriere auf die Sprünge helfen kann. Denn meist lassen sich Lösungen aus der Community auf die Organisation von Teams in Unternehmen anwenden.
Hier soll es zunächst darum gehen, ein Gefühl für die Arbeitsweisen zu entwickeln, denn:
Wer sich an der Open-Source-Entwicklung beteiligen möchte, tut also gut daran, zunächst einmal die Gepflogenheiten des jeweiligen Projekts kennenzulernen. [via]
Die Frage ist nur: Wo fängst du am besten an?
Die Software-Branche hat sich in vielerlei Hinsicht professionalisiert, auch bei den (erfolgreichen) Hobbyprojekten. Also solltest du das auch.
Beherrsche verteilte Versionsverwaltung (Distributed Version Control System, DVCS). Versionsverwaltung an sich ist die Grundlage für jedes Arbeiten an Software — das solltest du verinnerlicht haben wie das Atmen. Verteilte Versionsverwaltung ist speziell auf die Arbeit in Teams zugeschnitten und wird daher in immer mehr Projekten verwendet. Dabei ist unerheblich, für welche Software du dich entscheidest. Mein Favorit ist Git. Andere bevorzugen Mercurial.
Beherrsche die Kunst der testgetriebenen Entwicklung (Test-Driven Development, TDD). Sie macht dich zu einem besseren Programmierer, denn Tests…
Sowohl der Umgang mit Versionsverwaltung als auch testgetriebene Entwicklung erfordern natürlich viel Übung. Deshalb:
Die Amerikaner nennen es treffend „pet project“. Andere müssen nicht unbedingt nützlich oder wichtig finden, was du da tust. Es ist dein Projekt, also mach was daraus. Lerne dabei. Probier Dinge aus. Amüsier dich. Beherrsche dein Handwerk.
Ich würde dir wärmstens ein GitHub-Account empfehlen, um dich mit anderen Entwicklern auszutauschen und Code freizugeben, vor allem bei Verwendung der Programmiersprachen Ruby, Python und Javascript (siehe GitHubs Top Languages)
Organisiere und vermarkte dein Projekt. Dabei hilft natürlich auch:
Folge den richtigen Leuten. Twitter erfreut sich unter uns Technikern großer Beliebtheit und ist dafür gut geeignet. Es mag vielleicht eine Weile dauern, bis man sein Netzwerk zusammengestellt hat, aber es ist den Aufwand wert.
Besuch User Groups in deiner Umgebung, um persönlichen Kontakt herzustellen und interessante Leute und Projekte zu finden.
Nimm an Konferenzen teil. Dabei ist der Preis nicht unbedingt ein Qualitätskriterium. Manche Community stellt für einen Bruchteil des Preises großartige Veranstaltungen auf die Beine.
Stell dich darauf ein, gewohntes Terrain zu verlassen. Bis vor kurzem habe ich noch nie einen Chat für technische Diskussionen betreten. Mailinglisten sind nicht (mehr) in allen Teilen der Szene gleich populär. Mach deine Mitarbeit nicht davon abhängig, welches Kommunikationsmittel du gern benutzt.
Aber mach deine Mitarbeit davon abhängig, wie du behandelt wirst:
Ich mag Ruby (und Rails) auch deswegen, weil man offen miteinander umgeht und Diskussionen sachlich und auf hohem Niveau geführt werden. Auch wenn so mancher das anders sieht.
Bleib, wo du dich wohlfühlst — denn das ist der Schlüssel zu großartigen Projekten.
]]>Scrum ist wie eine Beziehung: Du musst dran arbeiten.
Und zwar nicht nur dafür, dass Scrum sein volles Potenzial ausspielt und deinem Team ermöglicht, ihre Arbeitsweise und -ergebnisse kontinuierlich zu verbessern. Sondern auch gegen die Verwässerung des Prozesses von außen.
Damit euer Prozess sich nicht komplett auflöst, achte auf diese Warnsignale:
Normalerweise sollten die User Stories vom Product Owner geschrieben werden. Dabei kann er durchaus vom Team unterstützt werden, wenn es etwa um Formulierungen geht. Wenn der Product Owner nur noch eine Reihe von Anforderungen bellt und das Ordnen in User Stories dem Team überlässt, stimmt etwas nicht.
Retrospektiven sind das Mittel der Wahl, um Arbeitsabläufe zu verbessern sowie Produktivität und Zufriedenheit im Teams zu steigern. Manche sagen sogar, Retrospektiven können als Einstieg in die agile Entwicklung genutzt werden.
Fakt ist: Wer längere Zeit keine Retrospektive gemacht hat, läuft Gefahr, sich im Kreis zu drehen.
Scrum Master sorgen für eine störungsfreie Arbeitsatmosphäre des Teams und haben eine vermittelnde Funktion zwischen Team und Product Owner. Teams sollten durch sie nicht nur gegen den Product Owner, sondern auch vor sich selbst geschützt sein.
Für die Rolle des Scrum Masters muss Budget vorhanden sein. Die Rolle darf nicht einfach wegdefiniert werden. Sonst kann man den Prozess eigentlich gleich lassen.
Auch wenn Schätzungen in manchen Augen überbewertet sind, erfüllen sie ihren Zweck: Fortschritt messbar machen und Entscheidungshilfe sein für die nächsten Aufgaben — etwa wenn es darum geht, was bis zu einem Termin noch alles fertig werden kann.
Ohne Schätzungen arbeitet jeder nur vor sich hin, man weiß weder, was zu schaffen ist noch was geschafft wurde.
Der Burndown ist eine grafische Übersicht über den Fortschritt im aktuellen Sprint. Das geht Hand in Hand mit Schätzungen: Ohne Schätzungen kein Burndown. Ohne Burndown kein Indikator, ob die zweite Hälfte des Sprints zu schaffen ist. Ohne diesen Indikator keine Möglichkeit gegenzusteuern. Ohne Gegensteuerung keine Selbstorganisation.
Natürlich darf das Team einen Sprint abbrechen. Und natürlich muss ein triftiger Grund dafür vorliegen (wenn etwa am Tag nach dem Planning klar wird, dass einige Grundannahmen im Planning grundsätzlich falsch waren).
Kein Team bricht mutwillig einen Sprint ab -- dafür ist der zeitliche Aufwand viel zu hoch. Dem Team den Abbruch zu verwehren ist ein Eingriff in die Selbstorganisation der Gruppe.
Spikes sind minimale prototypische Implementationen einer Funktionalität und werden typischerweise zur Evaluation neuer Ideen und Technologien und deren Machbarkeit verwendet.
Solche Programmteile sind häufig nicht von der Qualität, die für ein Produkt in Frage kommt. Leuchtet ja auch ein: Wenn du etwas ausprobierst und damit möglichst schnell zu einer Entscheidung kommen willst, halten Qualitätsansprüche nur auf. Deshalb sollte Programmcode aus Spikes möglichst nicht wiederverwendet, auf keinen Fall aber im Ganzen ins Produkt übernommen werden.
Um gute Arbeit zu leisten, muss man gut informiert sein. Bei agiler Softwareentwicklung mag man zwar immer nur für einen kurzen Zeitraum detailliert planen. Aber trotzdem müssen solche Teams zwecks Orientierung die Vision des Produktes immer vor Augen haben.
An einer guten Beziehung muss man ständig arbeiten, sonst geht sie kaputt. Ähnlich sieht es mit Scrum aus.
Ich könnte natürlich sagen, dass beides Selbstläufer wären. Aber wir wollen hier doch ehrlich bleiben, oder?
Scrum ist harte Arbeit und Disziplin. Als Team muss man um den Prozess kämpfen, wenn man etwas davon haben will.
Diese Liste lässt sich sicher noch erweitern. Welche sind deine Warnsignale? Woran merkst du, dass du dich um deinen Prozess kümmern musst?
]]>Michael Lopp, Autor von Being Geek und Managing Humans, stellt ausführlich und unterhaltsam seinen Arbeitsplatz und seine tägliche Routine vor und erklärt, warum er seine Freundin anblaffen muss, wenn sie ihn dort stört:
Das Thema testgetriebene Entwicklung (test-driven development, TDD) hatte ich schon an anderer Stelle angeschnitten. Die Motivation dahinter, wie das alles zusammenpasst und welchen Einfluss die Methodik auf die Produktivität hat:
I Don't Have Time for Unit Tests
Sich selbst einzuschätzen fällt immer schwer. Diese umfangreiche Übersicht hält einem vor Augen, wie groß das Feld der Softwareentwicklung wirklich ist und hilft dabei, eigene Schwächen zu identifizieren:
Wie geht man als neuer Teamleiter mit Menschen um, die in der Vergangenheit aggressiv und unprofessionell auftraten und die Arbeit anderer als die eigene ausgaben? Interessante Fragestellung und einige sehr eindrucksvolle Antworten:
New Team Lead - How to deal with a resentful former peer
Wie schon in meinen Erkenntnissen über Produktentwicklung erwähnt, ist es wichtig darüber nachzudenken, ob man eine Veränderung als inkrementell oder als radikalen Bruch kommuniziert. Beim Wechsel von zentraler zu dezentraler Versionsverwaltung ist nach Meinung von Bill Wagner einiges schiefgelaufen:
]]>Wenn du dabei bist, die Software so grundlegend umzugestalten, dass kein Stein auf dem anderen bleibt?
Wenn du plötzlich und ungewollt dem ausgesetzt bist, was allgemein als Veränderungsmanagement bezeichnet wird?
Wenn du dir mindestens einmal in der Woche vornimmst, das Pinguin-Prinzip noch einmal zu lesen?
In unserer konkreten Situation haben wir Entwickler drei „Kunden“:
Dabei haben wir mit der ersten viel, mit der zweiten weniger und mit der dritten Gruppe so gut wie keinen direkten Kontakt. Entsprechend verteilt sind die Anfragen, die uns erreichen.
Hier sind meine Erkenntnisse aus den typischen Situationen, die sich daraus ergeben:
Produktentwicklung macht großen Spaß — nur selten hat man die Möglichkeit, sich praktisch fortwährend mit neuen Technologien beschäftigen.
Ausprobieren, evaluieren, umsetzen. So manches auf der grünen Wiese anfangen. Der Traum all jener Entwickler, die in den technischen Vorgaben von Kunden gefangen sind und zum Teil mit uralter Technik moderne Anforderungen umzusetzen versuchen. (Haltet durch, Jungs!)
Diese Arbeitsweise ist purer Luxus. Das sollte man unbedingt zu schätzen wissen.
Erkläre den anderen, warum Änderungen notwendig sind. Welchen Nutzen sie bringen. Stell dich darauf ein, das immer wieder erklären zu müssen.
Diese Kommunikation nach außen ist eine echte Gratwanderung. In technische Details zu verfallen kann genauso ins Auge gehen wie immer nur zu behaupten, es werde alles gut.
Achte darauf, das große Ganze dahinter richtig zu verkaufen: Um die gewünschte Adaption zu erwirken, müssen manche Ideen als radikaler Bruch vermarktet werden — auch wenn man im ersten Moment meint, dass kleine Änderungen besser verdaut werden können.
Teile deine Werkzeuge, Lösungen Erkenntnisse und Arbeitsweisen mit den anderen und schotte dich nicht ab. Nimm dir die Zeit, zwischendurch den aktuellen Stand oder kleine Nebenprodukte zu präsentieren.
Wer nicht in die Entwicklung involviert ist, neigt dazu, Annahmen auf Basis seiner Kenntnisse zu treffen.
So entstehen Gerüchte: Stimmt es, dass Feature X abgekündigt wird? Das wäre alles viel schneller gegangen, wenn... Und überhaupt — warum kümmert ihr euch nicht erstmal um die wichtigen Dinge?
Es ist unglaublich schwierig, Entscheidungen später zu rechtfertigen als andere früh darauf vorzubereiten und mitzunehmen. Wehe, wenn dann noch eine Sache nicht läuft wie geschmiert!
Hinterher ist bekanntlich, wenn man's vorher gewusst hat.
Erschwerend kommt hinzu, dass man sich als Produktentwickler viel zu schnell an den Zustand gewöhnt hat, dass viele Dinge kaputt sind, deaktiviert oder gelöscht werden.
Wenn du das falsch kommunizierst, ist das guter Nährboden für weitere Gerüchte.
Auch wenn Umsetzung und Kommunikation nach außen einen Großteil des Tagesgeschäfts ausmachen -- vergiss nicht, dass Feedback aus den Projekten überlebenswichtig für ein gutes Produkt ist.
Halt also die Ohren offen. Welche Lösungen sind im Einsatz? Was muss verbessert werden? Was wird gebraucht? Und viel wichtiger: Was kann wegfallen?
Gerade dieser letzte Punkt ist selten offensichtlich und wird oft nur zwischen den Zeilen erwähnt. Features zu streichen erfordert Mut auf der einen und Einsicht auf der anderen Seite.
Und zwischen all dem ist Software-Wartung vielleicht noch ein Thema.
Einfach mal einen ganzen Tag nur den Blick nach vorne richten? Vergiss es. Kontextwechsel sind an der Tagesordnung, wenn du dich auch noch um die aktuelle Version des Produkts kümmern, Fragen beantworten und Probleme untersuchen musst.
Daher ist es ratsam, sein eigenes Tempo zu finden, Anfragen zurückzustellen und stapelweise abzuarbeiten. Finde heraus, was für dich am besten passt, ohne die anderen vor den Kopf zu stoßen.
Kommunikation ist das A und O bei großen Veränderungen. Nimm die anderen mit.
Sonst haben sie schon keine Lust mehr, bevor ihr überhaupt fertig werdet.
]]>Kaum zu glauben, aber wahr -- in meinen drei Jahren als Vollzeit-Entwickler habe ich bisher weniger über den Vertrieb von Unternehmenssoftware gelernt als durch diese vierteilige Serie:
The very most basic things your company needs to know about sales
Du weißt schnell, wenn du einen vor dir hast. Aber was genau macht einen erfolgreichen Software-Ingenieur aus?
Top Three Traits of Successful Engineers
„Sollen wir den Button unten oder oben platzieren?“ — „Mach eine Option draus!“ Anpassbarkeit von Elementen ist nicht immer die beste Wahl:
The Pitfall of Customizability in UI Design
Wenn es um Tools geht, sind in der Softwarebranche die Fronten schnell verhärtet -- Linux gegen Mac gegen Windows, die ewige Editor-Diskussion, oder auch das Thema Versionsverwaltung. Um dem wiederkehrenden „Murmeltiertag“ ein Ende zu setzen, hat Benjamin Pollack einen Vorschlag:
Schätzungen sind ein Problemkind unserer Branche und mit ein Grund, warum agile Methoden wie Scrum so schnell populär geworden sind. Warum es nicht gut ist, Schätzungen zu viel Bedeutung zu geben:
]]>