Unlimited PTO may be the second worst1 thing in the tech industry today that companies brag about. The main problem is that it’s an outright, obvious lie. Companies tell the obvious lie to avoid telling the truth. But there’s another problem: Unlimited PTO is really hard to do well. Let’s address the various gigantic fauna in the room: Unlimited PTO was dreamed up as a scam. In states where accrued PTO must be paid out by law, it’s a way for companies to avoid paying you what you’ve earned. What’s more, we know that people tend to take less vacation when they have an unlimited PTO plan. Whatever they might say out loud about vacation, be aware that your company’s …
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.
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 …
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.
On May 10 (2018), Josh Pigford kicked off some Twitter drama with a Tweet that he and a lot of people found pretty uncontroversial. Unfortunately for Josh, it was not uncontroversial. Allow me to dispel the myth of job hopping.
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. ↩
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!)