Articles tagged 'favourite'

How to Commit to Mastery


In a moment, all of you readers are going to hate Matt Bird. I get it. I hate him too.

He’s a professional screenwriter who also wrote a great book about how to write. You’d think that might excuse him a bit, but no, I’m not letting him off the hook. Some crimes are unforgiveable. You’ll see.


The Water We Swim In: The Software Developer's Mindset


I’ve been fortunate to work in DevOps and with great Ops folks in my career, including doing enough of that work to get a feel for it. The tools are fun and it’s nice to be able to do basic tasks, but the incredible, invaluable thing was just watching how experienced OpsFolk responded to different events.

It’s not just the smooth, immediate way that they handle warnings and outages, though that is impressive. It’s also their basic understanding that new features, even features meant for robustness and resilience, are basically trouble. It’s not that an undisturbed system will necessarily keep working… But a system you disturb will invariably develop problems of some kind. Deployments tend to break things, and deploy-free weeks like holidays tend to be downtime-free.

But the important part isn’t the fact that they’re right. The important part is seeing a completely different attitude toward the software we write. Our way is valid for what we do, their way is valid for what they do, but it gives us completely different principles (that is, “unwritten rules that underlie everything we say and do”) about software.

Just like “everybody else has an accent,” it feels like everybody else has a mindset - our mindset is just “the right thing.” But seriously, what are the unwritten rules in software development?

And it’s not even just Ops or DevOps. There are a lot of mindsets in the world, and developers are just one of many.

If we’re the fish in the bowl, what does the water look like?

And what would the opposite look like? If software developers get our superpowers from this mindset, what superpowers do other folks get from very different mindsets?

A Simple Coding Study

It’s fun to write about different ways to practice coding. But “how to practice” only gets you so far - at some point you have to actually do the practice.

There are a lot of neat programming exercises in the world. This is an example of one I call a “coding study”, and I think it fits my definition of a good exercise.

A coding study is like an artist’s life study, but for code. You’d normally pick your own design. But this is meant as a simple introduction, so I’ll suggest a little more than usual.

The theme today: ivy on a window. I’ll refer to the picture below repeatedly in this post - have a look, then scroll back here as needed or save a copy locally.

One hard thing about exercises is that you need different habits for them than for production code: you’re not trying to write polished, production code. Instead, you’re trying to learn as fast as possible. So at the end, I’ll talk about some intentionally weird things I do in this code and why.

Up-close picture of ivy growing on a windowsill, houses visible through the window
Ivy on my windowsill

There's No Such Thing as Knowing Your Computer 'All the Way to the Bottom'


(You can see the five-minute video version of this post on YouTube.)

I’m an old-school programmer. I’ve been doing this for 30 years. I worked for over a decade in C and C++, often on operating systems and device drivers.

If you ask, “how do I get better at programming,” I’m supposed to tell you:

  • you should learn C (or C++ or assembly) — a language that works like the computer hardware does
  • you should write code that directly messes with the hardware, preferably an operating system
  • you need to learn the highest-performance languages because otherwise what will you do if your code is too slow?

These are all terrible advice.

And they’re all variations on a different, wrong idea: that you should learn about computers and software past all the abstractions, “all the way to the bottom.”

That’s also terrible advice. Let me tell you why.

How to Stop Being Afraid of 'The Computer Science Thing'


I often teach developers for my job, so I collect fears. Most teachers do. Your grade school teacher probably told you that you had to pay attention to boring math and/or history so that you could get a job (and not, by implication, live in a van by the river.)

So when I hear the same fear a lot, from a lot of different people, I pay attention.

I’ll bet that you don’t think you know “The Computer Science Thing” well enough. New folks like Boot Camp grads think so. So do recent college grads. And not-so-recent college grads. And veterans who “haven’t been keeping up.”

The Tragedy of Yelp: Forced Into Extortion

If your startup does certain things, you wind up with the same business model as Yelp. It turns out you really, really don’t want the same business model as Yelp.

Not the same Emma (credit: Wikimedia commons.)

Let’s tell the story of the fictitious Emma Goldfarb founding a seed-stage startup called (unrelated to the URL shortener.) is going to be a site where people leave reviews of some kind of business. Emma isn’t quite sure about the details. She’s working on it.

Spoiler: she’s in an ugly situation because her startup wants to be like Yelp… And she really doesn’t want it to be.

Follow the Money

Where does Emma’s money come from? Advertising doesn’t pay much, unless you have people who are about to buy something online in a trackable way. Emma doesn’t. Most of her reviewers have already bought their thing. Users looking for reviews are (in her case) not going to buy through her, so she doesn’t get paid that way. Some sites can avoid that, but Emma can’t.

What's Deployment versus Provisioning versus Orchestration?

dubious search results Hey, Ruby web developers! Having trouble asking deployment questions? Not sure what Provisioning or Orchestration are? Getting bad results Googling your questions, but not sure why?

Let’s go over some deployment vocabulary from your point of view — that makes it a lot easier to Google and to read information about deploying your app to a server, and setting up that server in the first place.

As a nice side effect, you may have an easier time talking to your Ops guy at work.

First, let’s go over what the word “deployment” means:


‘Deployment’ is the process of putting a new application, or new version of an application, onto a prepared application server.

If you are talking to a developer, it may also mean the process of preparing the server, perhaps by installing libraries or daemons. If you are talking to an operations professional, it DOES NOT. They use the word “provisioning” for that.

(Developers are going to keep using the word “deploy” for everything involved in getting our app and its dependencies installed. That’s cool. But don’t be surprised if you confuse your Ops guy.)

Why Do They Say Rails Doesn't Scale?

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.

The Rails logo and a scale with a circle-and-slash over top.

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.

What is Rack?: A Primer

If you do Ruby web programming, you’ll often hear about “Rack.” You might hear about it from a Ruby dev you respect, and that you won’t get better at Ruby web stuff until you know what’s underneath.

Or you might have to write a to use Heroku and you’re thinking, “what’s”. It...

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.)