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
Yes … You Can … Change Your Organisation Culture!
Some management consultants claim that you can’t change an organisation’s culture.
This is nonsense.
Numerous other management and change consultants claim they can change an organisation’s culture.
This too is nonsense.
You can change your organisation’s culture … from the inside.
Indeed, a leader’s responsibility includes Shaping their Organisation’s Culture.
I am going to share two successful stories of leaders driving change in their companies. On both occasions, I was engaged as an external consultant with the brief to co-design and facilitate the process and selected interventions.
Engineering Inc.
From a loss-making conflict-ridden environment where indifference and lack of trust reigned, to a profitable integrated company with engaged employees. The company is now a unit in a global corporation and a Centre of Competence for its product line.
The Situation: A new CEO had recently been appointed to a company which had changed owners 3 times and been making losses for 8 years. The environment was poisonous: chaotic production processes, cynical, continuous conflict with customers due to delivery and quality issues, abuse of the system by middle managers who themselves were not trusted by the production engineers and technicians. Closure was a possibility with 300 jobs at risk.
Changes and Process: Three new engineers were brought in to fill critical positions: Chief Engineer, Senior Project Manager, Site Manager. We conducted individual interviews with all managers, held focus groups at all levels, engaged the works council. Product demand fortunately was not an issue. Customer relations unfortunately were a serious problem. The CEO appealed for support. He laid out a clear strategy with a message of the environment and changes needed to continue operating. Changing the focus from inward (protectionist silos) to outward (the whole business with customer needs as focus) we used strength-based approaches to realign around real business Questions, whereby employees were invited to contribute. The production and logistics process was changed completely; skills deficits were alleviated; product design now involved production; the management team began to work as an integrated unit; employees wanted to contribute to improvements. Three middle managers who resisted the changes were forced to leave. Additional jobs were created in production as demand rose. Within two years, the site was making a profit.
Key Change Success Factors: The need: without change, the company was in serious danger of closing. Leadership: A driven leader who everybody trusted – he was visible, approachable and walked the talk. His messages were clear and he listened. Involvement: People learned not only that their contributions were desired, they experienced that the invitations they received were genuine.
Finance Inc.
From a small sleepy company in which employees had a lackadaisical approach to their work and customers, to a dynamic market leader whose customers praised service quality.
The Situation: A small specialist data processing company was acquired by a global corporation. A new CEO was installed together with two experts from the parent company. The environment was friendly and relaxed. There was little engagement, people worked with an eye on the clock, problems were referred to management, error rates were high, clients were irritated.
Changes and Process: The new CEO laid out clear guidelines, expectations and his vision of potential opportunities. All employees were invited to play an active role in working groups that defined and implemented new more efficient practices and new customer interface processes. Customer orientation was prioritised. The two new specialists were appointed to lead functional units, otherwise, the only hierarchy was towards the CEO. Processes were defined, personal and team responsibility was expected, engagement levels improved significantly, the environment was noticeably more dynamic, problems were solved at the level at which they occurred, customer satisfaction indices increased dramatically. Within two years, the number of employees increased three-fold as new clients came on board.
Key Change Success Factors: Leadership, Trust and Recognition: Clear consistent Leadership; clear guidelines; employees felt valued and freer. Involvement: employees were able to see the impact of their contributions.
Culture is the continuously evolving dynamic interaction of the mindsets and gutsets of all the actors in the system. It is the Soul of the Organisation that drives the behaviours we observe.
In many if not the majority of organisations, observed behaviours reflect not the values of the people within the organisation, but those hidden values of the organisation as a system, frequently driven by inappropriate leadership. By inviting and encouraging the people to engage with the system, leaders can lead a change from a negative to generative culture. Indeed, this is their responsibility.
And in the fast changing world of the early 21st century, shaping an adaptable organisational culture is becoming a survival essential.
Yes … You Can … Change Your Organisation’s Culture!
By: Eric Lynn from CultureQs
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
Save the date
Get ready to Spark, we’re happy to announce Spark the Change 2018 will be happening next June in Paris. We will announce speakers soon. We can’t wait to see you there!