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
Great Leaders Ask Great Questions
For the last few years, I’ve been working with and studying some of the best teams in the world; Red Arrows teams, SAS and US Navy SEAL units, Racing yacht crews, a Formula One pit crew, etc. I set out to study teamwork. In particular, I wanted to know how these teams have become world class. In the course of my studies, I identified six common characteristics, which differentiated these incredible teams.
Interestingly, I didn’t set out to study world class leadership. However, when I found world class teams, I also found world class leadership (I know, I probably should have expected that!). So, as well as studying teamwork, I also began to look at the characteristics that differentiated world class leadership. One of the most powerful insights that I discovered is this…
Great Leaders Ask Great Questions.
In fact, the great leaders that I encountered often didn’t provide any answers! Instead, they realise that the group has the potential to generate a better answer than they could on their own. It’s a principle that James Surowiecki outlines in his book, Wisdom of Crowds. When I shared this idea at an educational conference last year, a Head Teacher responded by saying, “That’s rubbish. Are your trying to tell me that Einstein should ask his class for the answer, and that the class will have a better answer than Einstein?”. “No”, I said, “Einstein is part of the class. So by engaging the class you get Einstein plus the class, not instead”.
Knowing that great leaders ask questions is one thing. Knowing what constitutes a ‘Great Question’, is another. So, what makes a question ‘Great’?
Here are some of my thoughts and reflections…
To me, ‘Great Questions’ are simply the right question, asked at the right time. To ask great questions, we need to understand the problem we’re trying to solve and where we are in the process. Do we need to ask a strategic question, or a tactical question, or one that’s related to implementing and executing a plan?
Strategic Question – Why?
Tactical Questions – What? …. How?
Action & Implementation Questions – Where? …. Who? …. When?
Very simply, it makes sense to understand why we are doing something (and whether we should be doing it), before deciding what we’re doing or how we will do it? Equally, it makes sense to know what we’re going to do, before deciding who will do it, when and where.
To me, ‘Great Questions’ are also well defined and simple. Sometimes it takes time and thought to frame a question well. The world class leaders that I saw at work often ask simple questions, which engage their team to collectively solve a problem. Some of the most powerful questions I’ve heard simply begin with the words, “How could we…?”.
To find out more, read Stronger Together; How Great Teams Work and hear from world class leaders sharing their wisdom on Be World Class TV.
By: Simon Hartley, Founder of Be World Class.
Remote Work: Stories of People and Teams Doing Great Things
Get ready to pack up your laptop and hit the road!
Today, I specialise in facilitating remote work. And it was an experience ten years ago that turned a light bulb on for me — in a way I would have never expected.
I was living in California at the time and belonged to a social community interested in the future, technology, and staying healthy. Every Sunday, we’d meet up for a hike together. One member of the group was particularly interesting to me because he was working on a startup idea I’d never encountered before: he wanted to eradicate death.
To the outside world, it appeared that he was building an online project management tool. That was a very “normal” startup idea, even for ten years ago. But what most people didn’t know was that he was building the tool so that longevity scientists from all over the world could collaborate and solve the “problem” of aging.
He had found that the best people needed for this unusual collaboration were not living in the same place. So his vision was to build a tool that they could use to work together remotely.
It was a true “aha experience” for me. Once we remove the issue of being geographically dispersed, we can gather the best, most enthusiastic people together virtually to work on the most challenging problems imaginable.
I was hooked by the concept and started interviewing people and companies working remotely to see what they were doing. Down the rabbit hole I went!
In the past, we had to go to a specific geographic place in order to access the information we needed for our work. Now, that information is likely accessible from anywhere. And this gives us the opportunity to play with new ways of working and new business models.
I’m increasingly seeing a move from a model of work-life balance, which assumes that work and life shouldn’t overlap or blend, to work-life fusion, where the lines between work and life blur.
Work and Life: No Longer at Odds
Jeffry Hesse is an agile coach working with a distributed development team of approximately 40 people at a company called Sonatype. He loves his work. He also loves mountain climbing, photography, and spending time with his grandmother.
Because he can work from anywhere, Jeffry combines his passions by working while traveling. He started by trying an experiment with his remote team. He spent one month traveling in Argentina — and didn’t tell his colleagues he would be on the road.
He wanted to test how productive he could be while traveling, and if anyone on the team would notice.
Admittedly, it was hard. Finding a decent internet connection in Argentina was one of the most challenging aspects. He tried coworking spaces and staying with friends — and his technical know-how came in very handy while experimenting with various VOIP phones. But while it was hard work, and sometimes shaky, he managed to get his work done without the distributed team noticing that he was on the road.
While being a digital nomad may seem like a radically unconventional way of working compared to the traditional 9 to 5 job, it gives us a glimpse into what’s becoming possible…and increasingly common.
What Does It Mean Today to Be “Present”?
The tools that allow us to work in new ways are developing at breakneck speed. One of the most exciting examples of this is telepresence. Telepresence is a combination of technologies that give you presence somewhere other than your actual location. Your smartphone and standard video conferencing tools — even Facetime — can all be considered forms of telepresence.
My favorite form of telepresence? Robots.
The Revolve Robotics Kubi, for example, allows someone to call in (via video conferencing) to any tablet device. The difference is that you can move the tablet from side-to-side and up and down and control where you are looking from your own laptop.
For instance, if you are a remote participant at a meeting where everyone else is sitting together in a room, you can turn yourself to see who is talking. Other telepresence robots allow you to beam in to what is basically a tablet on wheels, and drive yourself around using the arrow keys of your keyboard. Schools use these for kids who can’t attend classes in person. Museums use these to give remote tours. Even doctors use them when specialists are scarce.
These interactive sensory experiences bring us closer to replicating what it’s like to be together in the same room. And the technology gets better and less expensive every year, opening new options all the time. Holograms are just around the corner!
How Businesses Are Changing
Because of these new technologies, more and more people are like Jeffry, seeking to balance their work with the freedom to pursue their passions. What it means to actually “be at work” is changing rapidly — businesses are evolving as well. Here are three examples:
A Virtual Network With Global Impact
Happy Melly is a social entrepreneurship network of individuals and small businesses dedicated to happiness at work. Supporters include coaches, creatives, authors, speakers, managers, and entrepreneurs. Members of Happy Melly help amplify and globalise great business ideas through virtual and in-person workshops, blogs, guides, books, tools, and videos.
I joined the network to get business advice from people who shared my same purpose and values. With the help of “colleagues” from all over the world, I learned how to structure and scale my company, Collaboration Superpowers, so that myWork Together Anywhere workshop could be offered online and in person around the globe. I’m also now the remote team manager for Happy Melly.
Serendipity Turned Them Into a Team
The team at StarterSquad first started working together (remotely) when a client hired them for a software development project. They didn’t know each other before the project started, but over time, the team clicked.
At one point, the client unexpectedly ran out of money — but the team members weren’t ready to part ways. They decided to find other clients so they could stay working together. They now operate as a self-organised team of entrepreneurs, specialising in building minimum viable products for software startups. In addition, they offer seed funding for startups whose ideas they believe in.
Forget About Facetime
Another company, Teamed.io, prides themselves on having no central office, no meetings, and no phone, Skype, or video calls. The company is made up of a large group of freelance software developers that have never met or spoken to each other. They work entirely through chat on task management systems.
Specific people are brought together for projects depending on the skillset that’s needed. Projects are broken down into very small tasks. Programmers are paid as they complete tasks, and they are not paid if the tasks are not completed. When the project is over, the team is dissolved and everyone moves on to other projects.
Extreme? Perhaps. But it does show ways of working that were never before possible.
Leveraging the Remote Advantage
There are numerous benefits to being able to work from anywhere. Some resonate most for solopreneurs and digital nomads as a source of empowerment to work and travel. Others please HR departments and hiring managers who need to build virtual teams or want to offer flexible benefits to their employees. A few are aiming to raise visibility around worker happiness and the environmental benefits of not commuting.
The ability to tap into information and collaborate with colleagues from anywhere has opened up new possibilities for work-life freedom. People can work on the things they are most passionate about, and businesses can hire people who love what they do versus people who are just doing their jobs.
If you haven’t thought about what’s possible with remote collaboration options in a while, you might be surprised by what’s happening — and what’s possible for you as well! I encourage you to do some more exploring. We’ve come a long way, and it’s only getting better from here.
By: Lisette Sutherland from Collaboration Superpowers
Self selection – How to restructure your team for greater autonomy.
One of our largest departments within Ocado Technology recently undertook a revolutionary self-selecting restructuring exercise, changing the entire structure of the department whilst allowing all team members to choose which team they would like to work in going forward. The need came about because multiple teams were stretched, working across two major business propositions and context switching between them. The goal was that following the restructure there would be a clear split between teams working on two different business propositions, such that each of those teams could really focus on that product.
The overall aim of this restructure was to achieve greater alignment, autonomy and purpose.
Following the principle that a collaborative and distributed approach is often the best way to solve a complex optimisation problem, we decided to take a full day as a whole department to stop work and have a facilitated event to negotiate the moves amongst the five new teams. We did a lot of thinking and preparation prior to this day and the teams used a set of constraints around team size and experience levels to guide their decisions.
The plan going into the event was shared well ahead of time to allow people to get their questions in (and added to a shared FAQ forum) and to be sure the concepts were clear going into the day. Alongside this, we ran multiple “townhall” sessions where people could air their concerns and ask their questions openly. We hoped that at the end of the process we would have well-rounded, committed teams ready to face the new challenge.
There was a certain amount of ad-libbing and practical adjustments on the day, but on the whole it unfolded according to the plan:
– First, a pitch for each team by the Product Owner, covering the vision/roadmap and why the team is super cool and awesome. There was also a set of target criteria for each team as a guide for what we were looking to achieve in each area.
– Next, multiple iterations where we:
1. Assigned or moved ourselves/each other between teams until we’ve addressed any identified issues in the previous iteration.
2. See if we had met the pre-defined criteria for each team.
3. Repeat until we run out of time or we meet all of the requirements and everybody is happy and committed to the team that they are in.
Fuelled by 18 pizzas, we completed three exhausting rounds of moves and peer voting. At the end of each round, we (everyone, including Product Owners and Team Leads) voted on the viability of each team. From this we measured two scores: an intra-team score (the people in that team scoring the viability of the team), and an inter-team score (the rest of the people scoring the viability of that team). This lead to a few interesting dynamics, for example one of the teams gave themselves a high intra-team score, but scored low on the inter-team vote. They then gave a pitch justifying their viability as a team, and were able to dramatically increase their inter-team score in the next round.
The first round was deliberately obviously suboptimal, so that everyone was motivated to suggest changes and improvements and become comfortable with doing so in a very “safe” way. Naturally, this configuration had dramatically lower scores! This encouraged a large amount of movement in the following rounds, as we had hoped.
Essential to finding a viable solution was an appreciation from all of the ‘greater good’ of Ocado Technology. On the day, some people chose to make some really big compromises in order to serve the greater good and allow us to form balanced teams that are all capable of smashing out quality software.
After the final round of voting we then took a quick anonymous happiness reading by each dropping a green, yellow or red lego piece into a box. Although they were not perfect, we were extremely pleased the results, considering that our original goals was “at least 50% happy”.
The very next morning we did a big-bang desk move:
We’ve since kept a close eye on the impact of the shuffle-up by measuring the things that matter most to us: throughput and team happiness. There was an expected initial dip in throughput as many people got up to speed on new products they had not worked on before and as new teams gelled and got to know each other. But the throughput three months on has risen higher than before the change and still rising. Improvements in team happiness (measured before and after by Spotify’s “health-checks”) were noteworthy from straight after the restructure.
In terms of the solution itself: we are delighted. Every team has a reasonable level of experience whilst a healthy number of people have chosen to change domain. It is a vastly better result than we could have hoped for had we chosen a top-down approach and the sense of autonomy it has created is invaluable. It seems that teams and individuals have a stronger sense of ownership than ever before and that they are taking quality more seriously than ever before. This did have an up-front cost in terms of short term throughput, but the long term benefits certainly justify it.
James Lohr, Ocado Tech Department Head