An ambitious young programmer asked me recently, “how do I balance learning new specialties with producing good results?” It’s a great question, and a hard balancing act.
It took me too many years to learn this. I hope the rest of you learn it much faster than I did.
A Tale I Will Thee Tell
If you find a project that your management considers highly productive that uses a new-to-you technology, then you can learn and be productive. That’s a best-case scenario, but it happens semi-often.
Watch for it, just in case.
But if one of those was obvious, you wouldn’t have asked me. As Michael Church writes, those opportunities are often reserved for the programmers who play the politics game best — if you do well, many of those will mysteriously open up to you.
But let’s say you can’t get that, not yet.
Your Goal: Be Like Old Google
Next best is to have a perceived-as-high-value activity that doesn’t take all of your time. This is much, much easier than it sounds. If you can do that, you can declare your own old-Google-style 20% time, especially if you don’t declare it out loud. The keys to being perceived as highly productive are, roughly:
1) Be sure to ask your managers, and occasionally their managers, what the company values. Patrick McKenzie’s article talks about doing this during your interview — and yes, do that, but don’t stop doing it once you work there.
Also, ask business-critical groups (e.g. Sales, Marketing) and politically powerful groups (e.g. Product, Finance) what they get from Engineering. You ask because they remember the stuff they value and forget the stuff they don’t. So their answers will not be a good match for what Engineering thinks that Engineering gives them. Their answer tells you what you want to be working on. Those are projects they consider valuable and noteworthy. If you do a good job on projects like that, they will remember you personally. At least, they will if you do steps 3 and 4 correctly.
You’re going to need to take control of your own deployment. Heroku, for instance, isn’t going to handle that well.
But first, here’s a little parable about Bob (who is, um, totally not an alias for my early mistakes… Probably.)
The Parable About Bob
Bob was an old-time C programmer. When he built C programs in his spare time, nobody ever saw them. You can give people source code, but usually they can’t use it in that world. And building an installer is horrible, especially if you have any friends with a different OS than you use. That used to happen, back in the day.
Ruby on Rails was awesome and Bob loved it. You could put something on a server and then your friends could use it. How cool is that?
When I create and promote fun content, I get more subscribers, more goodwill and more engagement.
When I ask my audience to buy things, or even sit through being asked to buy things, I lose those things, by and large.
So this product trek is kind of an alternation — "power up" my audience by giving good things, and then turn that into "hey guys, buy my class" or "please fill out this survey" or whatever I’m asking of them.
Unrelatedly: I don’t feel like a person who sells products when I have successes. I feel like a person who sells products when I’m mid-slog and I know exactly what part comes next.
Deployment comes with far too many tools. For instance, this whole set is often used together:
And that’s not counting the smaller things like Vagrant plugins, Capistrano plugins, the many Chef cookbooks and so on, which would also be used with these. And it’s definitely not counting the many, many competitors. That whole list is just one stack of tools.
For some of them, it’s clear why you use them. VirtualBox? Yeah, okay, something has to make a VM if you test locally.
But why do you need both an “app deploy” tool (Capistrano) and a “server configuration” tool (Chef)? Can’t your server configuration just include your app? For that matter, if your “app deploy” tool runs scripts as root, can’t it configure your server?
There Can Be Only One?
Some people do use just one. It’s possible to deploy apps through Chef, but please don’t! It’s possible to do all your server configuration through Capistrano — really, really don’t.
For best results, think of Chef and Capistrano as two separate tools for two different jobs.
So what are those jobs?
Some famous people told me how to get superpowers. I did. They all happen to agree on this topic. Now I’m going to tell you the same secret. I’ll even help you out a bit more.
The most powerful, important thing you can do is to get your code in front of the people who will use it. Do it as fast as possible. Do it when it’s not ready yet. Do it when it makes you uncomfortable.
What does that have to do with superpowers, though? We’ll get there. But first, more about shipping code.
But It’s Not Ready!
In the end, it boils down to this. You’re somebody who is reading about software when you don’t have to. Right here in this post, even! You care about your craft.
First off, let’s just say: Heroku is awesome. There are all kinds of great reasons to use it, and I would never, never claim that Heroku is wrong for all deployments.
But it’s also not right for all deployments. Let’s talk about when it’s wrong and when it’s right.
Heroku’s big advantages are:
- really easy to deploy
- really easy to scale
- mostly everything just works
Those are big advantages. Sometimes they’re the most important thing for your project. When they are, you should absolutely use Heroku.
But why might you not?
First, the elephant in the room: the cost. Heroku gives you limited free hours per month, and after that it’s expensive. Background threads or processes also cost extra.
A single minimum-power dyno runs you $36 per month, assuming you need barely any space in Postgres. Heroku is basically going to cost you at least twice what a VPS would cost (e.g. Linode or Digital Ocean) and give you much less power. If you process many simultaneous requests or run many background threads, it will be at least three or four times as expensive for the same power.