My favorite article on salary negotiation of all
time talks about “fully-loaded costs” of an employee. The idea is
that when figuring what it costs a company to employ an engineer (or
whoever) it’s short-sighted to just take their salary and multiply by
time. Patrick suggests that “a reasonable guesstimate is between
150% and 200% of their salary” and that the “extra” tends upward
as salary does. Of course it depends on benefits and whatnot.
Many
people think that’s complete baloney. Specifically, they tend to
think that the “extra” is fixed (e.g. $30k extra,) rather than a large and increasing
percent of salary.
But when you’re negotiating salary, or otherwise asking, “what does
an employee’s time cost a company?” he’s right. Let me explain why.
Most frequently you see pages for less-established entry-level people
— people who try using a sales page because they have to, not
because they want to.
So when my last company went out of
business, I put a
“hire me” page together. I had a little breathing room before
missing a paycheck and reasonable savings. Why not try it?
He says he can’t find any of those engineers to hire. Spoiler: neither can your company. I’m going to tell you why
not, and what it would take to fix it.
If you’re new to Ruby on Rails, you may be new to the old debates (pro and con) about how “Rails doesn’t scale.” You might wonder why people say that, or where it came from.
Let’s talk about that.
As far as “Rails Doesn’t Scale”, the main arguments go something like:
1) Ruby is slow, often up to 50x slower than C, so the server will eventually collapse.
This isn’t actually a scaling argument. But it’s true that Ruby is slow. Not 50x any more, closer to 5x (up to maybe 20x), but still, that’s not terribly speedy.
Rails doesn’t help Ruby here. A lot of the metaprogramming techniques it uses are among the slowest things Ruby does. I wrote a book about how Rails uses those techniques called Rebuilding Rails. They’re awesome, but they’re not speedy.
In practice, Ruby and Rails apps often “farm out” the slow stuff. The database is the traditional place to put the heavy lifting, but you’ll see Redis and Cassandra used in similar ways. Want Ruby to be fast? Call to something that isn’t Ruby, and is designed for speed :-)
Pure Ruby is quite slow, but just as scalable as any other language or library. It doesn’t get somehow slower as you add more.
2) Ruby/Rails leaks resources, so large or long-running projects don’t work
There was once more truth to this. Ruby had a few leaks and Rails exercised Ruby like nothing else. Also, ActiveRecord encourages large amounts of garbage per request, which was easy to mistake for leaks.
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.
As you’d expect, 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.
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.
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.
Subscribe to get free ebook chapters and an emailed coding class now, plus videos and articles a few times a month.
Why this specific newsletter? You want to be an expert. Expertise comes from learning the fundamentals, deeply. And that comes from the best kind of practice.
I write with that in mind. I won't waste your time.
(Yes, I also sell things. They're good, but I'm fine if you don't buy them.)