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
Rejecting roles
Rejecting roles: That’s marketing’s job. You need to talk to IT.
Having roles is considered essential by most organisations. We’ve read dozens of business blogs, HR advice articles and even management training courses that insist clearly defined roles lead to better results, greater productivity and higher motivation. Without clear definition of roles, they warn that tasks get missed, no-one takes responsibility, the office is chaotic and individual motivation drops.
We disagree.
The writers of this advice have grasped the outcomes they want – people taking pride in their work, everyone focusing on delivering value, individuals coordinating and collaborating – but they’ve applied the wrong solution.
They’ve confused roles with responsibilities.
That may not sound like a big deal, but we think it is. Rigid role definition has some major downsides. We believe it hurts companies and individuals, costing them in creativity and happiness.
Most organisations intend their role definitions to be a way of signalling particular specialisations, expertise and responsibilities… but instead, the definitions swiftly harden into barriers, marking out territory which is defended against ‘interference’ from others. Have you ever been told to back off by the marketing manager for commenting on the new advert? Been refused access to the code base by the developers, ‘in case you break something’? Been told to leave presentations to ‘the sales guys’ or forecasts ‘the finance guys’? At the extreme, you may have your opinion rejected with a straight-forward ‘well it’s not your job to worry about x, it’s mine!’.
Individuals may also use their role definition as a way of avoiding unpleasant or boring tasks. This ‘that’s not in my job description’ approach ends up making the company less efficient as well as eroding team motivation. I remember organising a last-minute marketing stunt when I worked at Unilever. I was booking a double-decker bus to turn up and I wanted to check it would actually fit into the office forecourt. The marketing assistant nipped down to Reception to check. An hour later, she returned. The security guard had refused to measure the gateway and if it was beneath the dignity of a security guard, then she reckoned it was beneath the dignity of a marketing assistant as well. So I borrowed the security man’s tape-measure and checked the gateway (you could – quite literally – have fitted a bus through there). Anything wrong with doing my own measuring? Absolutely not. Anything wrong with wasting an hour of time arguing about whose job it was? Plenty.
Roles are comfortable – but bad for us
It’s very human to defend our own work and our own opinion. When we can dress this up with the authority of experience, expertise and organisational separation – all the better. Except it isn’t. Rigid role definition acts as a barrier and can stifle innovation. It can also make things slower and less efficient.
If a customer rings up with a problem, they want a solution, not to be told that only part of their problem can be dealt with by this department, and they must be passed on to billing or whoever to deal with the rest of it.
It’s not great for individuals either. Sticking to just one thing may mean our knowledge gets deeper, but also narrower. We can get bored or worse, so convinced of our own expertise that we can’t take on other points of view.
Being Radical: Sticking to the start up way
In many start ups, a lack of defined roles is the default position. There is not enough money to hire specialists – instead developers must learn to present to investors, marketing managers must be able to create and manage their own customer data, and everyone must have a grip on the financial assumptions as well as a grasp of the their product (this often means some grasp of the technology).
When entrepreneurs look back on the early stage of their companies, they often comment on wistfully on the diversity of work and of how close to the customer it meant they were.
Jeff Bezos, CEO of Amazon, recalled being the ‘mailroom grunt’ in the company’s early days, driving books to shipping and courier companies in his 1987 Blazer. But this doesn’t scale, right? Jeff Bezos is not still doing deliveries. Actually, he is. He spends a week every year in the warehouse. It’s not a PR gimmick, because he refuses to set up interviews when doing it. It’s an opportunity to stay connected to his responsibility – leading Amazon – and not the role of CEO. That includes really understanding conditions for employees – something for which Amazon has received a lot of criticism – and staying close to core services like order fulfilment.
Another trick used at Amazon is to have individual employees who have no role at all. Bezos has ‘shadows’, people who simply follow him around. It means there’s always someone free to chase a wild idea or set up an experiment – and it recognises that a responsibility like ‘envision Amazon’s future’ requires several people, not just a single role.
So what should we do?
1. Responsibilities not roles
Some radical companies go for a very broad responsibility ‘provide value to the company’ and say that how this is fulfilled is up to the individual. Others go for more precise responsibilities: ‘help the customer’ or ‘make sure we comply with financial regulations’.
The point is that how you fulfil these needs can require doing tasks which, in other companies, would be seen as belonging to differing roles.
2. Trust people
A lack of roles makes people more responsible, not less. Tasks rarely get missed because everyone knows they have total responsibility for the work – no tester will come pick up the programmer’s bugs; no finance controller will correct over-optimistic projections.
3. Trust people some more
A lack of roles doesn’t mean that everyone will try to do everything. People naturally gravitate towards what they’re interested in and what they’re good at. If someone is convinced she’s a brilliant illustrator and everyone else insists the stick men cartoons are rubbish, she will soon stop.
4. Value dissent not consensus
No roles doesn’t mean you have to design by committee. Heated arguments are common, and that’s fine. Even if people don’t agree at the end of the debate, the important thing tends to be to air the problem. Opinions can be rejected; a decision can still be made, risks can still be taken…
By: Helen Walton from Gamevy
Free the office slaves
Free the office slaves: No more working day.
The 9-5 working day has come to signify office slavery.
In actual fact though, most knowledge workers work longer than 8 hours a day. A 2011 survey (ASHE) suggests that the average manager in the UK works over 9 hours per day, while extreme hours among certain groups (bankers and lawyers in particular) regularly involved sustained periods of working up to 120 hours a week.
What do set working hours signify?
Extreme hours hurt us. A study by Alexandra Michael, published in 2012, followed investment bankers over a 9 year period. The report concluded that people suffered physical, mental and emotional problems, including depression, a greater number of sick days and relationship breakdown.
Even normal hours often hurt us though. Studies suggest that those in the office spend a large proportion of their time unproductively. They might be checking personal emails or social media sites, or simply carrying out their basic work in a very un-productive fashion. Anyone spent ages staring at a spreadsheet unable to make head or tail of it? Ever fallen asleep in a meeting when supposed to be coming up with ground-breaking new ideas?
The energy cycle
Energy, creativity and brilliance rarely arrive on demand. Instead, human beings work in cycles. We can focus for limited amounts of time. After that we need rest in order to recover.
The ‘ultradian’ pattern, as it is known, normally depends on working in cycles of 90 minutes, with energy troughs in between – normally of about 20-30 minutes. The working day takes no notice of this, however.
Sometimes of course, we enter that wonderful state that Mihaly Csikszentmihalyi referred to as ‘flow’ – where we are hardly aware of the passing of time because we are so absorbed by what we are doing. When we manage to achieve this, the idea of cutting it off with a commute home or a lunch hour seems crazy.
Manage energy, not time
Radical companies understand the need to manage energy, not time. Sometimes that means that workers can work far in excess of the normal working day – developer stories of being so absorbed in a problem they didn’t leave the office until 3am are common. At other times it means workers do far less than the traditional 8 hours and in a different way – starting late, for example, leaving early to pick up children; taking a walk.
No working day means that life and work are more closely blended. It’s not unusual for radical managers to answer emails late at night or to come up with ideas as they sit on a beach with their family. They are not oppressed by this (“oh no! the phone is beeping again!”), partly because they are just as capable of taking a nap when they feel like it or running errands in the middle of what others would call the ‘working day’.
Being Radical
Leo Widrich is a co-founder of Buffer, a company which allows people to manage multiple social media accounts more easily. He manages his own day by splitting it into 90-minute windows and then achieving a certain number of tasks – one per window. A side benefit is that this helps increase focus on just one task at a time, eliminating much of the cost of task-switching. He then tries to plan his rest periods. Instead of allowing these to be filled up with emails or meetings, he goes out for a snack or reads a book. This ensures genuine downtime that allows the brain to recharge and creative ideas to swim up from the subconscious.
So what should we do?
It’s simple really – set people free to work as much as they want, when they want.
There’s no need to say ‘do you mind if I leave early today because blah blah blah’. Just go. It can help to share with others what you’re doing and how to get hold of you so they can co-ordinate with you, but there’s no need to ask permission.
Nor is there any need for that irritating parade of being the last to leave the office, or the first to get there. If someone is emailing late at night it’s because she had a thought and wanted to communicate it, not to demonstrate how dedicated she is.
Some managers might start sweating in light anxiety. How do you know the person won’t bunk off, won’t take advantage, won’t drop their productivity etc.? The answer is that regardless of hours put in people know if someone isn’t pulling their weight or isn’t performing. You can still ask poorly performing people to buck up or get out. But most people want to do well and want the company to do well so they work hard, but you’ve created an environment that helps them work effectively.
You can just trust them.
And just that one piece of advice – trust – frees up a lot of your own time in or out of the working day.
By: Helen Walton from Gamevy