There’s no perfect process for hiring great programmers, but there are plenty of terrible ways to screw it up. We’ve rejected the industry stables of grilling candidates in front of a whiteboard or needling them with brain teasers since the start at Basecamp. But you’re not getting around showing real code when applying for a job here. In the early days of the company, we hired programmers almost exclusively from the open source community.

Basecamp’s newest product HEY has lived on Kubernetes since development first began. While our applications are majestic monoliths, a product like HEY has numerous supporting services that run along-side the main app like our mail pipeline (Postfix and friends), Resque (and Resque Scheduler), and nginx, making Kubernetes a great orchestration option for us.

The vast majority of web applications should start life as a Majestic Monolith: A single codebase that does everything the application needs to do. This is in contrast to a constellation of services, whether micro or macro, that tries to carve up the application into little islands each doing a piece of the overall work. And the vast majority of web applications will continue to be served well by The Majestic Monolith for their entire lifespan.

For many, moving from everyone’s-working-from-the-office to everyone’s-working-at-home isn’t so much a transition as it is a scramble. A very how the fuck? moment. That’s natural. And people need time to figure it out. So if you’re in a leadership position, bake in time. You can’t expect people to hit the ground running when everything’s different. Yes, the scheduled show must go on, but for now it’s live TV and it’s running long.

Since the beginning, Basecamp has been marketed as a project management and collaboration tool for small businesses (or small teams inside larger businesses). However, over the years we’ve also heard from thousands of people who use Basecamp outside of work. They’ve gone off-label and turned to Basecamp to help them manage all sorts of personal projects too. No surprise there – it really works!

Here’s a common question that’s coming up about Shape Up, our new book on product development: People in my book club love all the principles, but they had one question: How did they build Basecamp 3 doing this? It seems like all the practices are for adding features to an existing product. There’s a new appendix in the book now to answer this question: How to Begin to Shape Up: New versus existing products.

I’ll be shocked if you’re shocked: Building social connection in a remote team is the hardest part of managing a remote team. According to a survey we ran this past fall with 297 remote managers and employees, “fostering a sense of connection without a shared location” was seen as the #1 most difficult part of being a remote manager – and the #1 most difficult part of working remotely, in general.

The #1 piece of information you should be focused on as a leader is sharing company vision. Here’s exactly how to do it.

Back in 2006, we self-published Getting Real: The smarter, faster, easier way to build a successful web app. It was our first foray into broadly sharing how we work at book-scale. It struck a nerve, turned heads, and changed minds. It offered product people, designers, and developers a way out – an escape hatch. They could finally ditch their way of working that wasn’t working for a new way that would.

The disconnect between how many companies claim that they only hire the best and how they try to actually do that is perverse. A depressing number of job postings are barely more than a list of technology or process requirements paired with an arbitrary desire for years of irrelevance. That’s then fluffed up by a bunch of trite rah-rah bullshit about the supposed glory of hiring company. Ugh.