A Mismatch Between Expectations and Practices

We want performant, scalable, and quality software. We wish to build and test applications that our customers profess their love to and share to their friends.

And yet:

  • We have nonexistent to little unit, performance, API, and integration tests
  • The organization do not closely monitor feature usage statistics
  • Some of us do not exactly feel the pains our customers face
  • We don’t have notifications for outdated dependencies, messy migration scripts, among other failures
  • Some are not curious about understanding how the apps they test and own actually work
  • We have not implemented continuous build tools
  • It is a pain to setup local versions of our applications, even to our own programmers
  • We do not write checks alongside development, we lack executable specifications
  • Some still think that testing and development happen in silos
  • It is difficult to get support for useful infrastructure, as well as recognition for good work
  • Many are comfortable with the status quo

It seems that we usually have our expectations mismatched with our practices. We’re frequently eager to show off our projects but are in many instances less diligent in taking measures about baking quality in, and therefore we fail more often than not. What we need are short feedback loops, continuous monitoring, and improved developer productivity, ownership, and happiness. The difficult thing is, it all starts with better communication and culture.

Takeaways from Valve’s “Handbook For New Employees”

I recently read Valve’s (yes, the company who created the Steam gaming platform) very interesting Handbook For New Employees. I didn’t know before that they are self-funded, and I didn’t know that they do not have any management until now. Valve is flat, no hierarchy, even if there is a founder; a fascinating, curious way of working for a software and entertainment company, an entirely different way of building products compared to what most businesses do. It’s challenging to imagine how their software development processes really run in the wild, and it might not be applicable to what we do right now, but it is worth understanding why they do the things they do. Maybe some of those things can help us too.

Some favorite lines from the handbook:

  • If most of the value is now in the initial creative act, there’s little benefit to traditional hierarchical organization that’s designed to deliver the same thing over and over, making only incremental changes over time. What matters is being first and bootstrapping your product into a positive feedback spiral with a constant stream of creative innovation. Hierarchical management doesn’t help with that, because it bottlenecks innovation through the people at the top of the hierarchy, and there’s no reason to expect that those people would be particularly creative about coming up with new products that are dramatically different from existing ones – quite the opposite in fact. So Valve was designed as a company that would attract the sort of people capable of taking the initial creative step, leave them free to do creative work, and make them want to stay.
  • My observation is that it takes new hires about 6 months before they fully accept that no one is going to tell them what to do, that no manager is going to give them a review, that there is no such thing as a promotion or a job title or even a fixed role (although there are generous raises and bonuses based on the value to the company, as assessed by peers). That it is their responsibility, and theirs alone, to allocate the most important valuable resource in the company – their time – by figuring out what it is that they can do that is most valuable for the company, and then to go do it. That if they decide that they should be doing something different, there’s no manager to convince to let them go; they just move their desk to the new group and start in on the new thing.
  • It would be more useful to think about what high-impact things I could do that no one else was doing.
  • The Valve approach is to do experiments and see what we learn – failure is fine, just so long as we can identify failure quickly, learn from it, and move on – and then apply it to the next experiment.
  • Of all the projects currently under way, what’s the most valuable thing I can be working on? Which project will have the highest direct impact on our customers? How much will the work I ship benefit them? Is the company not doing something that it should be doing? What’s interesting? What’s rewarding? What leverages my individual strengths the most?
  • Screwing up is a great way to find out that your assumptions were wrong or that your model of the world was a little bit off. As long as you update your model and move forward with a better picture, you’re doing it right. Look for ways to test your beliefs. Never be afraid to run an experiment or to collect more data.
  • If your expertise is not in writing code, then every bit of energy you put into understanding the code-writing part of making software is to your and the company’s benefit. You don’t have to be an engineer, and there’s nothing that says an engineer is more valuable than you. But broadening your awareness in a highly technical direction is never a bad thing.
  • Would I want this person to be my boss? Would I learn a significant amount from him or her? What if this person went to work for our competition? We should hire people more capable than ourselves, not less.
  • Hiring someone who is at least capable seems (in the short term) to be smarter than not hiring anyone at all. But that’s actually a huge mistake. We can always bring on temporary/contract help to get us through tough spots, but we should never lower the hiring bar.

Personal Rules On The Job

I take full responsibility for bringing out my best work, in the things I can control, everyday, to the full extent of my abilities. And to the many other things that’s beyond my jurisdiction, I can only listen, I can only suggest probable solutions or try to provide possibly helpful information or opinion.

I can never manage other people’s lives, and it would be wrongful of me to even try doing so because that means I’ll deprive them of their freedom to think and live by and for themselves. If I do that I’ll take from them the chance to solve problems on their own and grow. This does not mean that I will not care for my teammates nor I will not help them whenever possible.

I have to take it upon myself to look for the learning that I need and digest what I can. I won’t held another person or an entity to be accountable for my growth. I am responsible for my own research and development.

I will not bash myself when I fail to perform in cases where I honestly forgot to do something. I am fallible. But I will certainly learn and will put up systems so I don’t make the same mistakes over and over.

I cannot shy away from leaving a contract where I feel that the other party willingly decides to stop caring for my welfare or where our goals do not match anymore.

I shall take care of my body so I can fulfill my best work, every working day, but family and my own health always takes precedence.

I will not force people to do things my way. I can only teach, I can only share stories of my experiences and lessons learned. I will always let the other party decide what’s best for him or her, even if I think that his or her decision may bring forth a mistake or failure.