There’s an old lightning talk from RubyConf 2019 that I love, about how there’s no such thing as knowing your computer “all the way to the bottom.” At no point does it stop being a stack of leaky abstractions.
An unsuspecting fellow emailed me in response, asking, “yes, but isn’t there one, final...
On Mastodon, FullStack Ruby asks:
It’s a strange sort of environment to be living in as a Ruby programmer.
On the one hand, so much momentum behind low-level “systems” programming languages with strong, static typing.
On the other hand, the “future of programming” is guiding the education of...
A fellow recently asked me for advice about running a Ruby workshop. And folks, I had forgotten I knew so much about it before he asked!
Before Rebuilding Rails had a video class, I had written a lot of the material for Rebuilding Rails workshops that I gave at Southeast Ruby and at Railsconf. I...
A gentleman on Twitter suggested that to make a new SaaS app, you should do these things:
This is pretty good...
I started working for myself at the beginning of February, after taking a month off. For close to eight years I sold my book as essentially a hobby business. It made around $40,000 over those years, which certainly isn’t terrible. It’s been doing slightly better since I started actually putting time...
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.
Occasionally, you’ll see people put up a “why you should hire me” page, such as the one that got Jason Zimdars a gig at 37signals. These pages are effectively sales pages for people, though they read a little differently from a sales page for a book.
(If you don’t believe that a “hire me” page is a sales page, I recommend reading a bit more Patrick McKenzie.)
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.
And I thought, “hey, what if I tried that?” As a great fictitious man once said, “we try things. Occasionally they even work.”
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?
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 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:
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.
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.
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.
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.
