Engineering is the easy part except when it's not

I've been hearing it a lot lately. Maybe you've been hearing it, too. "Engineering is the easy part," they say.

Try telling that to Twitter in early 2007 when they faced massive growth and intense scaling issues. I don't think you'd find many engineers at Twitter telling you how easy it is to manage 600 requests per second and 180 Rails instances backed by 1 database server.

The point is: engineering is hard. Everything is hard.

Ok, maybe I'm exaggerating a bit here. There is one case where "engineering is the easy part."

Let's say you have an idea. You want to build that idea into a weekend project. You've probably heard of this happening quite a bit. How many "I built this in a weekend while watching every episode of House of Cards" blog posts have you read over the years? Building a project in a weekend is easy. You shouldn't be focused on perfection. Most everything works the way it should, but it definitely isn't refined. If you overcome your lizard brain, you can ship it and see what people think.

Let's say a few people like what you've built. You have users! They start using the app as any good user should do. Guess what? They find bugs. Now, you've got to fix them (if you want your users to continue liking what you've built). Better yet, it's not just one bug. This bug, that bug. You have to prioritize bugs. You can't fix them all at once - even if each user cares passionately about the bug they reported.

Still easy?

BUT! Remember, you took some shortcuts so you can finish your project in a weekend? You have a choice to make. You can put a band-aid on it and simply patch it up, or you can do some refactoring for the future to make sure it doesn't happen again. You might even want to write a test for it - you know, because TDD 4 lyfe.

Now you've fixed those bugs and your users are happy again. Slowly, they're telling their friends and you start to get some SEO juice with Google. But, guess what? You're not done yet. These new users want new features. Surprise, surprise - your weekend project can't do everything a user might want. Better yet, you're in the same situation as the bugs. Just like all the bugs, every user has a feature they need.

You have another engineering decision to make. How does this new feature integrate into the code you've already written? You'll need to plan for the future. There will always be new features. You don't want to screw yourself over in six months. Granted, some features are pretty easy and you've done them before, but there's always a slight variation. There might even be a library out there to help you, but once again, you'll likely have to alter its behavior - even if it's just a little bit.

Still easy?

Your weekend project is starting to turn into an actual product. You have a faithful group of early adopters. They're always looking out for you and sharing what they're thinking. You've been able to keep them happy through bug fixes and new features. You still have bugs and you have a giant backlog of new features; however, you've been able to navigate successfully until this point. Your app is still fast, but not quite as fast as when you first started. Your app works - there are some bugs, but for the most part people can use your app with success. For the most part, people are happy.

You're starting to grow faster now. People are paying attention. Remember Twitter? You might start feeling their pain. Not many apps have massive scaling pains like Twitter, but most apps go through periods where you have to adjust. Your weekend project was built and tested with one user, you. Now, you might have hundreds, maybe thousands, of people using your app on a daily basis. This is entirely different than one user. New problems will popup because your app is serving more than just one user.

These are great problems to have, but they definitely aren't easy.

Engineering is the easy part only applies to companies that stop at Version 1.0. How many companies do you know that stop there? None. The engineering team gets you to Version 20.0. Through bug fixes, new features, scaling, migrations, architecture, data centers, etc., your engineering team is there every step of the way.

It took Twitter months of hard work to straighten out their scaling issues. It most certainly wasn't easy. They failed - quite a bit, but they didn't give up. Through months of pain, they eventually came up with solution after to solution to fix the fail whale. Their solutions were most definitely not easy. Keep in mind - they did all of this while people were still using Twitter. Downtime is just unacceptable in this day and age.

On the flip side, I had the opportunity to observe what happens when you have an engineering team that runs into major problems when upgrading a product. Now, I'm positive this team had the best of intentions and I'm positive they were trying as hard as they could to avoid these issues. I'm also positive they'll learn from these mistakes. However, they failed massively, and they know it.

Engineers are responsible for many different things. If you don't do one of those things right, it can snowball into other problems.

Communication is key. As an engineer, writing code is a small part of the job. In practice, most engineers write code for a fraction of their day. Instead of writing code, they're communicating with project managers to estimate time to production. They're talking with the designer about ways to work a new design into the existing product. They're thinking about what's next and how they'll manage the next database update required for that upcoming feature in three months. They're worrying about how their code base isn't as stable and well-tested as they had hoped for.

Most importantly, all of this isn't easy - not by a long shot. This is hard stuff. Don't buy into the link-bait. Engineering is not easy. Just like customer support, project management, and product ownership - engineering is a key part of your organization. If you think you can just throw bodies at an engineering problem, you're wrong.

Those bodies might be able to solve the problem at hand. They might get you somewhere and help you raise funding. However, those bodies certainly aren't worried too much about the future. They aren't setting you up for long-term success. You'll pay dearly for it later on.

Engineering isn't easy if you're doing it right. Engineering should be invested for the long-term. When you finally get there, you'll have an engineering team fully invested in your organization. Your engineering team will be a valuable asset full of talented people that know every tool, piece of software, and server your company has in its possession.

Don't say engineering is the easy part. It's not.

Thanks to @andrewwicklandr and @alexlaprade for reviewing this and providing some ideas for making it better.

Minimizing distractions: No phone during the work day.

I've decided to try something new. After reading In Real Life by Nev Schulman, the host of Catfish on MTV, I've been inspired.

It's time to kill my phone.

Not forever, but just enough to reduce daily distractions. I started today. My phone is far out of reach - in another room - so I'm not tempted by anything. It's no longer begging for my attention. I even went so far as to uninstall all social media apps and disconnect my email accounts.

Here's someone else who has tried the distraction free phone with great success. Jake, the author of that post, was also an inspiration for me to try this.

Instead of picking up my phone whenever I have a spare minute or being intrigued by a notification, I hope to stare at the wall. I hope to stand up and stretch more often. I'll be able to think and reflect instead of reading something I saw on Twitter, browsing Reddit, or scouring Hacker News.

It's the equivalent of distraction yak shaving.

My phone constantly tempts me. There's not a moment that goes by without some type of notification. It might be an email, an app telling me to do something, or a calendar notification. There is always another inbox to check.

So, I've asked myself, why do I need my phone during the day? I never talk on it. Hopefully, by doing this, I'll better schedule my time with friends and family. I won't be responding to texts during the day. I won't be planning my evenings during the day. Instead, I'll have to improve my actual meaningful communication.

I want to try this out for two weeks and see what happens. Stay tuned for a follow-up.

A new definition for SaaS

The Software as a Service model, in large part because of it's name, has incorrectly led a lot of people to believe there's a fantasy universe that exists where they can light up some code, sit back, and collect some of that elusive passive income.

It's a ridiculous notion that needs to be shot in the face.

I know people questioning promising businesses because they're worried about the fact that there are humans involved with the running of the business. It's becoming an epidemic in the software industry that people think the goal is to reach some finish line where they can sit back and collect cash and have nothing running their company but a few servers.

It's insanity.

Moving forward, to me, my company and anyone that works with us, SaaS stands for Software and amazing Service. They cannot and they should not be separated.

Amazing service is server uptime. It's rapid fixes to bugs. It's responding to customer requests quickly. It's building new features that you know your customers want, it's experimenting, it's trying things, breaking things and trying again. 

Too many people in our industry have built once solid products that have become stale (not simple, stale) and have not advanced with the web in the way they should have. The worst culprits are bootstrappers who got a taste of victory and instead of working their asses off while they were gaining momentum had the delusional thought that they could sit back and collect monthly payments forever.

And then they learned about a thing called churn.

If you're not willing to get into the services business, don't bother getting in the software business.

The SaaS model only works for companies that understand that the software can only provide so much service.

 

Everything is hard

It's taken me a while to learn this reality, and I often forget it, but it's something that helps bring me back to center when I feel like I'm dealing with something that's more difficult than it ought to be.

Everything is hard.

I don't mean 'everything' obviously (it's pretty easy to take a nap), I mean anything we work on. Anything we're trying to improve, any thing of value that we're trying to preserve, any meaningful gift we want to impart to the world...it's all hard.

Writing one blog post is easy, building an audience of millions is hard. Going to startup weekend is easy, building a SaaS product that can sustain a team of people is hard. Kissing a baby is easy, being a parent is hard.

The trick of course is figuring out when something hard and worthwhile, or whether it is in fact being harder than it should be - and listening to what that is telling you.

But that's hard.

Because everything is hard.

 

It's all just construction

For the first time in years, I went on a proper backpacking trip and disconnected completely for a week. Maile's studio was putting on a retreat in Yosemite, and I had the good fortune of being able to tag along (I was also the van driver!) with her and the students.

From Monday morning through Saturday afternoon I completely disconnected from the internet, my mobile phone, and even my children. It was Maile, myself, 8 students and 2 guides.

It was heaven.

We did yoga, swam in the streams, day hiked, sat around the campfire, ate good food and had an entire week where the mind was freed from just about all the cognitive load that comes with daily life. During the course of said wonderfulness, I had a conversation with one of the guides who was a very kind man named Jesse. I pondered something about how we could take the lessons from this beautiful land and make it relevant in our homes and our day to day lives. 

Jesse's response was great: "It's all just construction."

It really struck a chord with me. As hard as we might try to separate ourselves from the laws of nature, the earth and anything that might get us dirty, in the end, it's all just construction.

What's interesting is when you look at things like this, you start to see a lot of other kinds of construction. Not necessarily good, not necessarily bad, but something interesting to notice. Our financial system is a form of construction, businesses are construction, our legal system and even to a certain extent our relationships.

Maybe only be taking a step back to see the construction can we see something a little bit deeper and more meaningful, whatever the context might be.