Work With Me

“Rails Can’t Scale!”

A few years ago, you chose Rails because it was phenomenal for building prototypes quickly. Your startup needed to move quickly, find product-market fit, validate your idea.

Devise, ActiveAdmin, stripe-rb — boom, there’s half your app, so you can focus on spending your innovation tokens on what makes you money.

But now it’s two or three years later and your stack is a hot wreck. Some of these probably sound familiar:

  • Features take longer to build
  • There’s so much unplanned work caused by unexpected bugs
  • You could drown yourself in the complexity of the code
  • Onboarding new developers takes a month
  • Your tests require huge amounts of setup, and they don’t actually prevent much breakage or give you much confidence.
  • You think it might be time to scrap this all and rewrite everything.

You’d Have These Problems In Another Stack, Too.

The biggest issue with Rails is not that it doesn’t scale. The dirty secret is that Rails can scale in able hands. You only need to look at Shopify and Github to know this.

The big issue is that the framework doesn’t really care about scaling. The only tool that Rails puts in the hands of developers for managing complexity is engines, and engines are complicated to set up and have major drawbacks that still haven’t been solved in Rails 6. (We’ll see about Rails 7, but I’m not holding my breath.)

Because Rails doesn’t deliver on community standards to manage complexity, most engineers that learn Rails are never exposed to methods of managing complexity. And it gets worse: most engineers internalize that going off the Rails means pain pretty early.

Rails’s best feature is also a double-edged sword: ease of development means it’s easy to build a hot mess.

If you had all your engineers pick up and move to $FASTER_LANGUAGE, you’d likely have the same problem. Because it’s not the speed of the framework or of Ruby that’s the problem, 9 times out of 10.

It’s the lack of tooling and techniques to manage complexity within a large application.

Senior Technical Leadership and Scaling Rails Teams

The great news is that you don’t have to re-write your application. You just need to augment your team with someone who has experience navigating these muddy waters. That’s me!

Who am I? My name is Rob Yurkowski. I’ve been a professional software developer since 2008 and a consultant since 2012. I’ve worked with exceptionally small, budget-limited clients whose projects were critical to their survival, up to Series-D-funded startups. These companies have varied in industry, including those in real estate, e-commerce, marketing, ‘quick’ commerce, health care, arts, and nutrition.

When I’m not working as a CTO these days, I’m working directly with them.

My expertise is in helping companies get over the hump and get back to productivity.

The first month from me often looks something like this:

  • I read your onboarding material for engineers, and take notes about where there are gaps or problems. Then I fix the gaps.
  • No bootstrap script? I help set up a minimal Dockerfile to make sure it’s easy to run your application in isolation in development.
  • I work on comprehending your data model, generating notes on entities and creating an ERD.
  • I update your README to document essential knowledge of your problem space, as well as unintuitive parts of your solution and application — the sort of stuff a new SVP Engineering would ask for on day one.
  • I ship a few features to understand how regular development works and feels.
  • If you don’t have decent telemetry and monitoring, I help set this up. Then I do a little bit of profiling to see where the biggest gains can be made.
  • We meet, and discuss where the best opportunities are for boosting your team.
  • All the while, I participate actively in code review, help chair technical meetings, and assist your engineers by bringing a principal-level and customer-focused perspective to the team.

If that sounds pretty great to you, I want to hear from you.

Select Past Clients

FastAF

fastaf-logo.png

Technical Leadership and Process Creation / 3 month engagement

  • Led creation of engineering on-boarding and off-boarding procedure
  • Heavy focus on improving code review culture
  • Led high-stakes migration from GoodJob to Sidekiq
  • Introduced several architectural patterns to streamline and de-complicate workflows across the API app
HoodQ

HoodQ_Assets_Branding_HoodQcom_icon.png

Principal Engineering / 2 year engagement

  • Led near-zero-downtime transition from EOL managed VMs to AWS Fargate, cutting monthly spend by more than 50% and increasing operational independence for engineering
  • Led decoupling of monolith on domain boundaries, creation of SOA / Evented architecture using RabbitMQ, and creation of new Accounts service
K-Rae Transportation

k-rae-logo.png

Principal Engineering / on-going 8 year engagement

  • Developed greenfield operations-critical Trip Management System
  • Maintained and upgraded from Rails 3.1 to Rails 6.1 over the course of work