It’s coming up on nine years since I first started slinging code in a professional setting. Professional here meaning with a salary, in an office, with other engineers, decent coffee and unreasonable deadlines.
Back then I was barely newly minted from school, and what I lacked in understanding I certainly carried in hubris. I remember being vaguely offended not to be on the list of Sweden’s top coders that year. No idea how they would’ve found me, but I still remember being annoyed by it.
What I’ve lost in hubris in the last nine years, I’ve gained in experience. I thought it’d be useful to punch down a few things that it would have been nice to know nine years ago — maybe it can help you, if you’re just about to take your first steps out of school.
In no particular order, here are nine things I wish I’d known when I started out:
- Experience counts for something. This is obvious, and maybe a bit condescending. But I remember the first time I saw a colleague in a live, heated situation pull up YourKit and hone in on the fact that we’d have two ServerInstanceFactories, not one, and that caused the entire app to go belly up. Or when I got literally smacked on the fingers for not using two-phased locking correctly. And a thousand other things. My first two years of working, what I mainly learned was that I basically didn’t know shit.
- People are messy. I’d love to know how many hours humanity as a total spends every day mediating between two or more angry 40-year old men. Most of the time, you’ll find reasonable people that don’t share your point of view on things, and you are not obviously right. There are tradeoffs. And sometimes people hold on to stupid ideas longer than they should, simply because they’re people. It’s a great irony that software development demands literal, logical, unambiguous reasoning while being complicated enough that you need to collaborate with ornate, arbitrary, ambiguous humans.
- You’re not logical, you’re biased. If there was one thing I was certain of was that I reasoned with logic and soundness and that I thought things because they were true. Things such as — we hire people only because of merit. Obviously. What I’ve learned is that any point can be argued from many angles, and who I am, where I was raised, what I studied and who my friends are all influence what I think is obviously true. I’ve also learned that I’ll likely never be Spock, and that the only reasonable defense is to invite different points of view, and accept that reasoning from different premises can lead to different conclusions, and still be logical and sound.
- You can use engineering for other stuff. As a flipside to above, I’ve also learned that the method of engineering that you learn in school and hone over the years is useful for a ton of other stuff than just programming. What engineering is to me is a way to define, decompose and reduce a problem space, and from that reason a solution under balanced constraints. Really, figuring out what you’re asking, and then answering that. And turns out that anything from sales, marketing, finance, design to analytics are super-susceptible to this. Don’t be afraid to dive in. It’s usually pretty simple to get stuck in.
- Users are not stupid. This one is a big one. When users complain about your product, it’s usually not because they’re stupid. Your dad, uncle or whatever that don’t really understand Facebook are not stupid. They just know other shit, and they haven’t learned this stuff yet. And that’s Facebook. They have literally hundreds of user researchers making Facebook simple. When your uncle doesn’t understand your app, it’s probably because it’s pretty unusable. Don’t blame users for that.
- Engineers have professional responsibilities. If you work with software in a company that makes money, chances are you have users. Even if you’re building Spotify, not a pacemaker, you still have a responsibility to your users. They’ve chosen your product, and if it sucks, they’re suffering and it’s your fault. This means that if you’re out chugging beer, the systems you maintain go down, and no one else can pick them up, you get a cab home and fix it. Obviously, don’t let a company take advantage of this responsibility. You should get reasonably compensated. But it’s still a responsibility. You can’t laugh off service disruption.
- Inverting a tree is useful, but not in the way you think it is. I’ve always been a strong believer in academic knowledge, and I loved taking the hardest courses. Particle filtering, non-linear signal processing, abstract algebra, advanced algorithms, etc. If it looked hard I wanted to know it. However, the point of Red-Black trees is not Red-Black trees. The point of graph traversal is not graph traversal. The point is, the tools you have shape how you solve problems. And the deeper the understanding of graphs you have, the easier it will be for you to see that a problem is a graph problem. Just like if you know enough economics, you can see business problems as market problems. And so on.
- Integrating early is always better. This is really mundane compared to all the other grand advice, but if you’re a bunch of people working on a piece of code, avoid branches and avoid submodules as much as possible. It’s really not better to work on your own branch until all is nice and then merge back. Merge early. Merge often. Otherwise you’ll spend a month merging. I promise. Like, I really, really promise … and actually, I guess there is grand life advice here as well. If you and someone you depend on disagree on something fundamental, don’t hold a grudge. Hash it out, as early as possible. Make sure you see eye to eye. The process and the product will be all the better for it.
- Simpler is literally always better. I saw someone write something like “Software engineers spend their first two years building complexity, and the rest of their careers managing it”. This is true. Really true. If you can avoid it, never write a dispatcher. Never write an orchestration framework. Don’t use Java if a bash script will do. Solve the problem you have now, not the problem you might have later. Nothing makes you feel as smart as a well architected, abstract framework for solving really complicated, general problems. Nothing makes you feel as stupid as not understanding how to debug it.
Anyway. This is my list. The nine things I wish I knew nine years ago. It strikes me now that current me would love to see the list Nine Things I Wish I’ll Remember In Nine Years. What stuff have I forgotten that would warp my perspective? I’d love to hear your take on either this, or what I missed on this list.
By: Marcus Frödin from Spotify
https://medium.com/@marcusf/nine-things-i-didn-t-know-nine-years-ago-fcbc757b268b#.9xksp8f8t
Your Engineering Team Is Not an Island: Success Demands a Holistic View of the Business
I just re-read the awesome post from my friends David Loftesness and Raffi Krikorian, What Does A VP of Engineering Do Again? And while I agree with everything that they say, I think there is one crucial item missing, which has been present in every job I’ve had because all of them were user-facing internet services and a majority of my job has been working with product teams. Collaboration with stakeholders (especially with product) is key, but if you take it one step further, a VP of Engineering is actually measured by execution in a wider context across many teams or departments. You cannot look at engineering in isolation for your successes or failures.
But first a short story about my first months at SoundCloud. The CTO wanted more front-end work done because an important release was nearing. He asked me to hire more engineers to accomplish that goal. I started recruiting, but then I looked at why the velocity of the existing team was not meeting expectations. So, I went to all of the front-end teams (at that time it was Web, iPhone, and Android) and asked a very simple question “What slows you down the most in your day-to-day work?” To my surprise, everyone gave the same answer “We only have one designer.” They went on to say that although the designer was very good, she was completely overloaded so designs, changes, and simple clarifications took forever to get done.
Now that I knew design was actually the cause for delays, the solution to my problem was not to hire more engineers (which might have even made the problem worse with more work for the designer), but to start building a design team.
Engineering leads need to look at the whole product process (together with the responsible stakeholders) and not just at engineering in isolation. What I did was a very simple (but, in this case, effective) form of value stream mapping. Our self-improvement at SoundCloud continued. You can read Phil Calcado’s excellent post about the organizational aspects of microservices at SoundCloud.
The Best Engineering Leads Will Stop and Assess the Situation
Continually assessing situations in a holistic way isn’t just the job of an engineering lead — everybody involved should take responsibility. But, in my experience, the problem usually surfaces in engineering because when things are not moving fast enough (and when do they ever?) management’s first reaction can be to throw more engineers at the problem so more work will get done, but also (and this is the not so nice scenario), management thinks the engineers are not working hard enough. Other common responses from management include reorganizing the teams or adopting new methodologies. However, as an engineering leader, you are a lot like a doctor: you need to diagnose the illness before treating the symptoms.
Engineering leaders need to look at the whole value chain and to sit with the leaders from affected departments to review at the problem. The solution to a problem might not be to hire more people (which a lot of startups do), but to organize product development in a better way. And if you have to hire, it might mean that you have to move headcount around. When everyone has the same goal goal — delivering more business value — shifting headcount from engineering to design or to recruiting shouldn’t be an issue. Afterall, the goal is more business value, not having the biggest department. So, when I realized our problem at SoundCloud wasn’t going to be fixed by adding more engineers, we created a design team. But this was just the first step towards a better setup.
Even after creating a larger design team, it remained isolated from other departments and was not fully integrated with our workflows. The problems of turnaround and wasted resources were exacerbated by the increasing risk of misalignment between product, design, and engineering. Therefore, the next logical step was to improve the organization by creating a delivery team per product.
Shifting Organizational Structures to Deliver Business Value
A delivery team is a team that can deliver the vast majority (95%) of its backlog items to production without dependencies on other teams. Unlike more horizontally-oriented teams (for example, a front-end engineering team that relies on the back-end engineering team for any back-end changes), a delivery team has all the necessary skills inside their team. So, depending on your company and your product, these teams can look very different. In engineering teams that are infrastructure focused, these teams can consist of only engineers; but if you look at a team that delivers a consumer-facing web app, then the team looks more like this:
Creating these delivery teams and then making sure you have the right staffing for them should eliminate a staffing mismatch between the affected departments. Some team members (like support) might just be a pointperson for the team, e.g., the support person only attends the daily standup and reports what is going on.
So, don’t look at engineering in isolation when trying to solve delivery problems. It is critical that each engineering leader (and especially the VP of Engineering, who can really influence the organizational setup) ensures that the overall product development process is set up in a way that reduces waste and delivers value to the customer which is the whole point of product development in the first place!
This post includes material from the upcoming book “Scaling Teams” by myself and David Loftesness, which will be published by O’Reilly in 2016. In this book, we will explain in detail the various scaling challenges of software startups.
Thanks to Laurel Ruma and David Loftessness
By: Alexander Grosse from issuu
Gig Economy
You could drive yourself steadily insane compiling a list of all the trends that were supposed to fundamentally reshape business. Once upon a time we were all “flexi” workers, then “mobile learners”. Both terms seem antiquated now, the corporate equivalent of a Segway – perfectly sensible in principle but somehow faintly ridiculous in reality.
What makes the “gig economy” – the legion of individuals taking on piecemeal work, enabled by online talent platforms – feel different is that it’s being driven not by hip early adopters in co-working spaces (though there are plenty of them involved too) but by genuine need, both in the “real” economy and, crucially, in boardrooms.
If you were staffing a major new project from scratch today, it would seem an act of faint lunacy to bring in a raft of full-time employees with cumbersome overheads (and personal taxes) when you could go online and find experienced, verifiable individuals you could pay by the hour and dispose of when required. Similarly, if you were a coder, IT contractor or other technical specialist, why would you harness yourself to one organisation when you could enjoy both variety and a more lucrative income hopping from gig to gig (along with the attendant tax advantages of being self-employed)?
So many businesses are waking up to this recalibration that 450,000 people with full-time jobs now have second jobs, many of them via TaskRabbit, Elance or their multitude of competitors. PwC has tried to cut out the middleman by setting up its own talent “market” of registered suppliers its offices can bid on. There are individuals in greater London making a handsome living assembling flat pack furniture on a piecemeal basis for an hourly rate – an occupation that would have been almost logistically impossible just a couple of years ago.
You can understand the appeal of living by the gig, beyond the financial benefits. The conventional career has been an awkward fit for many people over the years, and few jobs are capable of maximising all our skills and intelligences. Besides, most work is boring, which is why those lucky enough ever to have had a job for life employed the conversational repertoire of the prison system (“putting in hard graft”, “serving your time”) to describe it.
Gigs, by contrast, are exciting and ever-changing, even though they ask some deep questions of the psychological contract (why would I exercise discretionary effort for a business that only employs me for a matter of days? Can I trust someone who could work for my biggest rival tomorrow?). But they aren’t an untrammelled good, either. For every actuarial scientist earning a small fortune for a short-term job, there’s a hotel chambermaid who is now being paid by the room rather than the day. The huge rise in self-employment in the UK has as much to do with businesses shifting such workers – we should include the small army of couriers and delivery drivers in this calculation – off their books as it does people discovering new freedoms. Palpably, none of them are enjoying the benefits of the gig economy, not least because they cannot practically control where and how they work. They are left, instead, to feed on scraps.
Uber, the erroneously attributed poster child of the gig economy, faces a legal challenge over whether its drivers are technically employees. It maintains they are self-employed. This is a vital point for the courts to consider – cycle couriers and plumbers are engaged in similar cases – but in Uber’s case we should also note that it controls the supply of drivers into the market, and their pricing. This is assuredly not the “freedom” gig economy enthusiasts speak of.
Governments will have to decide the legal and ethical boundaries of such behaviours, not least because if gigs take off, their tax revenues will rapidly vanish. Already, there is serious talk of the need for a third kind of classification, between “employee” and “self-employed” which recognises the shared responsibilities (both financial and relating to holidays, sick pay and other benefits) between giggers and those they work for.
Pioneers like Wingham Rowan, who runs the Beyond Jobs consultancy, are trying to imagine a market that will ensure the gig economy brings mutual benefits and conveniences without being open to abuse. Businesses who want to enjoy the flexibility such arrangements provide should not absent themselves from such discussions – but neither should they fear this will turn out to be just another fad.
By: Robert Jeffery, Editor of People Management magazine
Spark the Change : inspirer les entreprises françaises grâce à des retours sur expérience concrets
Selon un sondage récent de l’Ifop, 91 % des jeunes cadres français pensent que leur entreprise est en train ou va se transformer. Mais pour 47 % des entreprises, la transformation reste aujourd’hui synonyme de « digitalisation ». Elle ne concerne l’évolution du style de management que dans 21 % d’entre elles et la relation client dans seulement 20 %. Pourtant, ces cadres pensent que la priorité devrait être mise sur l’évolution des modes de rémunération des salariés (37 %), l’évolution des styles de management (33 %) et la formation et le développement de compétences (33 %).
Les jeunes cadres français ont bien compris que loin de se cantonner à la digitalisation des processus, la transformation concerne de nombreux aspects de la vie de l’entreprise, et surtout sa culture et son organisation. « Une entreprise ne peut réussir sa transformation digitale si elle n’a initié une profonde transformation en interne » explique Jean-Christophe Conticello, fondateur et CEO de Wemanity.
« L’apparition d’Internet et des technologies associées a bouleversé en profondeur le monde de l’entreprise. Les modes de consommation ont évolué, le temps s’est accéléré, ce qui a entrainé également une profonde évolution des modes de travail. La nécessité de changer est devenue vitale : on ne compte plus les entreprises qui, en hésitant à changer de recette, n’ont pas réussi à se renouveler et ont disparu : Kodak, Virgin Megastore, Nokia, BlackBerry, Yahoo!, etc. Non seulement, la nouvelle génération a compris cette nécessité de changement, mais elle le suscite avec les nouveaux modes de travail qu’elle privilégie. »
« Spark the Change » : décrypter et inspirer les bonnes pratiques 
Pour illustrer et expliquer cette évolution, l’événement « Spark the Change » a été créé à Londres en 2014 par Helen Walton et ses associés de Gamevy, avec le soutien de Wemanity, puis décliné en Australie, aux Pays-Bas, en Inde et au Canada. La première édition française sera organisée à Paris, le 26 juin prochain au Théâtre de la Madeleine.
Centré sur le futur du travail et les moyens de repenser l’entreprise de demain, « Spark the Change » propose aux entreprises françaises un programme de conférences de qualité, basé sur des retours d’expérience.
18 experts se succèderont sur scène pour décrypter les tenants et aboutissants de la transformation des entreprises. Parmi eux : Ludovic Huraux, CEO et fondateur de Shapr ; Dirk Ahlborn, CEO Hyperloop Technology ; Anthony Gooch Galvez, Directeur de la communication et des Affaires publiques à l’OCDE ; Anamita Guha, Product Manager, IBM Watson ; Marianne Syed, Executive Director chez Positive Planet UK. Et bien sûr, Arie Van Bennekum, seul rédacteur européen du Manifeste Agile, aujourd’hui Agile Thought Leader chez Wemanity et Jurgen Appelo, CEO et fondateur d’Agility Scales et expert du management 3.0.
3 thèmes principaux
Animées par des professionnels de toutes nationalités qui souhaitent faire évoluer le monde du travail, les conférences « Spark the Change » sont réparties dans trois sessions principales :
- Créer l’entreprise de demain : les différentes étapes pour insuffler un véritable changement dans l’entreprise, sur la base d’un apprentissage continuel, d’une maîtrise totale des technologies et d’une organisation plus agile et réactive.
Jurgen Appelo, CEO et fondateur d’Agility Scales, expliquera notamment dans quelle mesure il est essentiel pour une entreprise d’aider ses collaborateurs à maîtriser continuellement le changement, par exemple via la ludification et d’autres nouvelles pratiques. - Libérer les talents : développer le potentiel de chaque collaborateur, instaurer le bien-être au travail, booster la collaboration et créer un environnement de travail basé sur la confiance.
Anthony Gooch Galvez, Directeur de la communication et des Affaires publiques à l’OCDE, détaillera ainsi « l’Indicateur du vivre mieux » de l’OCDE qui permet de comprendre ce qui contribue au bien-être des individus et des pays, et d’identifier comment susciter plus de progrès pour tous. - « Sparking disruption » : privilégier l’innovation, voire la disruption ; remettre en cause le statu quo ; et valoriser le progrès social, technologique et culturel.
Dans cette session, Dirk Ahlborn, CEO Hyperloop Technology, dévoilera la genèse de la création d’Hyperloop qui, au-delà des records de vitesse et des nombreuses innovations qui le caractérisent, propose surtout de révolutionner l’expérience des usagers du train.
« Spark the Change a été créé pour inspirer les entreprises, à l’heure où elles sont confrontées à plusieurs évolutions stratégiques : la transformation numérique, l’évolution démographique, la co-innovation voire la “coopétition” sur des marchés mondialisés » explique Sabri Ben Radhia, Responsable de l’événement chez Wemanity. « Si Wemanity était présent lors des premières éditions internationales de Spark the Change en tant que sponsor, nous avons repris la marque et sommes devenus son organisateur principal. Réservé à la fois aux entreprises et aux institutions publiques, l’événement a pour objectif de couvrir l’ensemble des aspects relatifs à la transformation des entreprises, sur la base de très nombreux retours d’expérience. Il vise également à aider les entreprises à développer les compétences nécessaires pour mener à bien leur transformation ».
Le programme de la journée a été construit pour privilégier l’échange d’expériences et le networking. 750 personnes issues de l’ensemble de l’écosystème de l’innovation européen sont attendues le 26 juin prochain au Théâtre de la Madeleine.
Aurons-nous le plaisir de vous compter parmi eux ?
Plus d’information sur l’événement : http://sparkthechange.fr/about-us/
Les experts qui interviendront dans les conférences : http://sparkthechange.fr/speakers/
Inscription : http://sparkthechange.fr/tickets/
Also published on Medium.