Hey, tech companies. Hey, engineers working at tech companies.

There’s a great post by Chad Fowler going around with a job description for an engineer we’d all love to work with.

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 going to read Chad’s post unbiased, do it now. Otherwise I’ll summarize that engineer for you:

• Very reliable with a great attitude about the job and the work.
• Serious empathy for co-workers
• Communicates clearly and constantly
• Makes technical decisions humbly, focusing on the users and the company, not the developer him/herself; no “science projects”
• Lots of experience, so s/he knows all kinds of development methodologies, and which parts actually work
• Hates “ceremony” — no-nonsense
• Willing to adapt to frameworks, tech, constraints and people except when it will have a “materially negative impact”
• Make boring tech choices at work, play in free time (or “whenever it’s appropriate”)
• Don’t mind looking bad when s/he deserves it
• Love to teach and learn
• Confident in lots of programming languages, architectures and operating systems, but not dogmatic about focusing on one

So: do you see why these people are very rare yet? It’s not just that this describes three or four full-time jobs to stay current (though it does.) It’s that several of those jobs conflict with each other and with your company.

Here’s an example:

• Puts his/her primary focus on users and company, makes boring tech choices
• Plays around only in spare time
• Super competent at many dev methodologies and technologies

See the problem?

Here’s another set:

• No time for ceremony; hates it
• Communicates clearly and constantly
• Always perceived as having a good attitude

Not a Contradiction

It’s totally possible to do all of these, of course. You can go gain a lot of skill in technology, then stop gaining more for awhile, or gain it more slowly (i.e. not at work with “science projects”.)

The communication/attitude thing is possible too — it requires a level of humility and empathy that doesn’t come without a lot of practice and a fair quantity of screwing up over a number of years.

It’s just that you want somebody who has put a short teaching career worth of effort into teaching. And a long programming career worth of effort into programming. And architecture. Plus you want them to be constantly positive, effectively humble and a clear, constant communicator. Let’s call that one more job worth of preparation.

Why You Wouldn’t Hire One Right Now If S/He Interviewed

Imagine somebody like the above — a great communicator, great teacher, broadly experienced with many methodologies and many technologies. You’re talking about somebody older. With a minimum of three full careers’ worth of skills, they’re not 22 any more.

So: somebody older, very experienced, highly skilled, but not currently trying to learn new stuff at work.

Do you see why s/he has about two years before s/he can’t get a new job?

Do you see why at your small startup, you wouldn’t hire him/her now?

An engineer fitting this description is committing career suicide. You won’t find many of them because only a small number of highly talented people have decided they’re done as programmers but haven’t yet left the field or switched to another.

The first thing your company does with older programmers is to “make sure s/he is keeping current and hasn’t just stopped learning.”

Could We Have Nice Things?

Would it be possible to have an industry that allowed such people to keep working? Absolutely. Do we have one now? Nope.

If you had enough stability that making humble technical choices wouldn’t result in career suicide in two years, that would do it (we don’t.) If would help extra if older people weren’t required to demonstrate how current they are with any technology they couldn’t have learned five years ago. This is often true at, say, defense contractors, and sometimes that allows such engineers to thrive.

If you put aside a specific chunk of time, regularly, for keeping skills up to date, that might allow somebody like this to work for you — see Google’s now-defunct 20% time for one possible method.

Or, if we were willing to pay these engineers as much as a decent lawyer or doctor, they could stay this good and still make choices that would put them out of work in two years. Two years working at 150% salary, six months off to refresh skills, repeat.

I’m sure there are other methods. Some day, perhaps our industry will adopt one.

What If I Want To BE ONE?

You could get an uncommon concession like the ones above. Please try to get it in writing — it can be hard for your manager to justify honoring an only-verbal agreement for an unusual concession. You know how it is.

Or you could put in the much lesser effort to start your own company, become a freelancer or otherwise work for yourself. I suspect you’ll pay yourself more and respect yourself more than almost any company.

Also, have you thumbed through a copy of John Sonmez’ “Soft Skills”? That’s another technique to get good, work for yourself, and genuinely get the benefits of being something as awesome as the above.

Being humble gets easier when you’re being treated well. Being treated well gets easier when you can just walk away.

I’m writing this because I do know people that match that description. And I see how they’re usually treated.

I want better for you.

The Upshot

If you’re a company trying to hire one of these, now you know why you can’t find them. You can treat them better, or you can keep never finding them. You have no other options.

Are you deploying a Rails app? Here are lots of things you’ll probably have to watch for as you do… I’ve been writing an open-source gem and a for-pay online class about this for months now. Let me share some things.

There are lots of big reasons that deploying a Rails app is hard. And lots of well-known, big tasks. But when you’re provisioning a server and deploying your application to it, lots of little things go wrong too.

I feel like the big things get a lot of respect already. Let’s look into some of the under-appreciated little things you have to get right in order to make a good deploy happen.

For starters, a lot of these small issues can require a lot of debugging. You know those two-line fixes that take three hours to find? Deployment is full of those. Here are some of mine to speed you on your way.

All Things Great and Small

• You can’t compile recent Ruby on a VM with less than approximately 1GB of RAM. The amount varies a bit, of course.

• When you try, you discover that GCC gives an internal compiler error as its “out of RAM” notice. Also, that the RVM cookbook tells you a completely wrong directory for the six logfiles to check for errors. At least, if you install RVM in user directories.

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.

I had the good luck to be an early reviewer of John Sonmez’s excellent book “Soft Skills: The Software Developer’s Life Manual”. So you get a review!

I’m a huge fan of teaching developers more communication skills and especially more about their careers. I love Edomond Lau’s ‘The Effective Engineer’, for instance.

Soft Skills is a book like that — more career than communication skills, and especially a lot of very frank talk about how to promote yourself in your career. It also includes several other chapters of how to take care of yourself as you develop for a living; that means fitness, investing, and even morale.

Oh! And don’t miss the story of how he got the review, at the last minute, from Uncle Bob Martin. Even if you’re not a big fan of Uncle Bob.

Open Secrets

This is powerful stuff, and stuff I’ve never seen another book teach. In fact, go read the chapter names in the table of contents before you come back. I promise, it’s worth your time. And the table of contents will tell you far better than I did just what the book is about.

As Patrick McKenzie celebrates his 9th year in review and many other folks write theirs up, I believe I’ll write my first. It’s been a big year, and I have a lot to be thankful for.

Don’t know me? Makes sense. I wrote Rebuilding Rails, an ebook about understanding Rails by building a Ruby web framework from the ground up, as a result of Amy Hoy’s excellent 30x500 class. I’m writing a Ruby web app deployment class called Rails Deploy In An Hour. I’m employed full-time as the Analytics lead at OnLive, a cloud-gaming company. I have a wife and two kids, so selling products on the side is an adventure I don’t really have the time for — but I don’t let it stop me :–)

Let’s start with dollar amounts before explanations. That’s why I’d be reading if I were you.

Revenue in 2014

Amounts are net of processing fees and refunds. Also, it’s Dec. 23rd, so not quite done. But pretty darn close. Tell you what: if anybody buys a professional package of Rails Deploy In An Hour, I’ll update this to reflect it :–)

• Rebuilding Rails: $7,679.35 – 208 non-refunded sales, 6 refunds
• Rails Deploy In An Hour: $1,277.70. That’s three pilot students and one professional package buyer. Plus 1 sale-and-refund of developer package from a guy who thought I was farther along than I was.
• Misc – affiliate sale, guest episode: $600.00

Rails Deploy In An Hour is doing… okay. I reopened the class a few weeks ago and I haven’t done much for it since then. I’m waiting until more of the class is finished to seriously advertise for it, which means no sooner than January and more likely February.

Rebuilding Rails is basically flat year-over-year. That’s not amazing, but honestly better than I expected. My flurry of activity for the new class is breathing more life into it. I’m not doing much marketing for Rebuilding Rails itself right now. It has some nice posts that still bring in visitors, and an autoresponder email class. I’m playing with the idea of doing more of a second edition of Rebuilding Rails, but I just can’t justify it right now. Maybe in 2016?

(Do you just want more dollar amounts? My First $1000 in Product Revenue may be the right place for you.)

Products

Last Year’s Goals: I knew I wanted a new product. I didn’t think about much more.

This year I launched Rails Deploy In An Hour to its pilot class of three people, and I’ve made one continuing sale. It’s a deeper, more involved and more expensive product than Rebuilding Rails and it’s going to take awhile to really finish — not that such a product is ever 100% finished. I have three chapters done of seven, and two videos of at least ten, plus several miscellaneous guides well under way. Overall the class is probably 35%-40% done, though the software works fine now. This class? It’s too many pieces. I’m managing, but it’s a lot.

(Also known as “why doesn’t Capistrano pick up my changes???”)

One of the cool things about Capistrano is that you don’t even have to put your Capistrano files into your app repo. You can put the Capfile and config/deploy.rb and so on in a different repo, or its own repo, or no repo or whatever.

One of the really infuriating things about Capistrano is that it’s designed to allow you to do that. See the bottom of this post for a quick workaround, or just keep reading.