View Post

Fair Pay: A Blueprint

In Programming, Solving the World's Problems, Technology by Pete

As an engineering leader, one of the most important things I do is make sure that we pay people fairly for their work. The challenge, of course, is that pay is the result of a bunch of different variables, almost none of which are objective. How do we get to fair pay when there are so many opportunities for our own biases to slip in? The answer is to design processes and systems to eliminate or counteract bias. This is usually easier said than done, but I’ve found a compensation model that I think helps.

View Post

Lambda School: Innovation or Scam?

In Programming, Technology by Pete

One of the newer code schools on the block is Lambda School. Their financing model recently came to my attention. It looks too good to be true. For many people it might be. Lambda School offers two products: A code school that charges $20,000 for a 30 week program Financing for said school The financing is important because they’re not accredited; traditional student loans aren’t available. They describe their financing mechanism on their front page: Pay Nothing Until You Make It No loans, no debt, and no up-front tuition. You’ll pay a percentage of income after you’re hired, but only if you’re making at least $50k/year. Their Austen Allred, their CEO, provided some extra details on Twitter: $50k Salary repayment …

View Post

Killing the Coding Interview

In Programming, Solving the World's Problems, Technology by Pete

You don’t have to see a person’s code to figure out whether they’re a good developer. Over the past ten or so years, I’ve interviewed a lot of engineers. In that time, I’ve developed a set of techniques that allow me to quickly and accurately evaluate a developer without seeing their code. I’m now convinced that it’s not only possible, but objectively better to do it that way.

View Post

Don’t Make API Calls in Tests

In Programming, Technology by Pete

I recently had a great conversation about application testing strategy and remote API calls. The question we were trying to answer was this: In an application which makes external API call, when should you mock those calls in your test suite, and when should you make live calls in your tests? My take on this issue: always always always mock external1 API calls. Here’s why: This gets more tricky when you own both systems, but I still stand by this as a best practice for that situation as well, for slightly different reasons. ↩

View Post

Compiling the Best Possible Code Sample

In Programming, Technology by Pete

Aspiring software engineers are often asked for code samples to demonstrate that they’ve got some clue what they’re doing. This is pretty terrifying and it’s incredibly difficult. When they’re not done well, they don’t provide much in the way of useful information. I’m a lead engineer at a pretty cool software company. I’ve been in a lot of interviews and I’ve read a lot of crappy code samples. I decided to write about what would get me excited about a candidate’s code sample (and, by extension, them). Other people might feel differently. That’s cool; this isn’t a math test. (But I would love to hear those counter-points in the comments below!)

View Post

Rails vs. Phoenix

In Uncategorized by Pete

Over the past week I’ve been diving into Elixir and Phoenix. As it is with most languages, there some good and some bad with Elixir. That said, anyone announcing the death of Rails at the hands of Phoenix is probably a bit early. While I didn’t do any benchmarks myself, that path is well worn. It seems fair to say that Elixir is probably faster than Ruby and Phoenix is probably significantly faster than Rails. It’s also likely that Phoenix will handle WebSockets far better than Rails will, even with ActionCable. On top of all of that, Elixir seems to also have a slight edge over Rails in terms of asynchronous jobs, since they can be done directly. For truly heavy jobs, Elixir …

Elixir Getting Started: First Impressions

In Programming, Technology by Pete

I’ve worked through the Elixir getting started guide as the first step in my goal to build something in Elixir. So far, there are lots of things I like and a lot of things I find kind of strange. The Good The fact that Elixir is up front about the performance profiles of lists and tuples is encouraging. Understanding when certain operations will be slow helps us make good decisions about design. The string support seems amazingly robust. The guide claims that Elixir passes every test contained in The String Type is Broken. Being able to avoid dealing with terrible string implementations is a huge benefit and, in the long run, probably worth putting up with a lot of other issues. Parallelism is a …

Is Elixir Worthy of the Hype?

In Uncategorized by Pete

During RailsConf this year, a blog post made the rounds which suggested that, more or less, Rails was dying and Elixir and Clojure were the places to be. I was pretty skeptical. After all, there are still production systems running Fortran and COBOL — the odds that a framework as widespread as Rails is going to dry up any time soon is basically nil. Also, Rails is pretty good at what it does. Most of the “problems” Elixir proponents are solving with Rails are not things Rails was really built to do. It’s a bit like saying everyone is going to give up cars because they can’t make it to the moon. Still, some people are pretty excited about Elixir, …

The Ultimate Password Solution

In Solving the World's Problems, Technology by Pete

Few things are more annoying than passwords. In theory, they’re fantastic. You keep a secret locked away in your super-computer-brain, and nobody else knows what it is, then you use that secret to prove that you’re who you say you are. Brilliant. Except that, in reality, passwords are beset by several tough problems. First and foremost, you don’t have any control over what the website you plug your password into does with it, so using the same password for everything is foolish. That means that instead of having to remember one password, you have to remember a bunch of them and what services and websites they match up with. Don’t write them down, either, or someone with physical access to …