Iâm Nick, a software developer based out of San Diego. In 2014, I wrote my first line of Rails, and Iâve been hooked on convention over configuration and optimizing for programmer happiness ever since.
Today, Iâm an engineer at Campsite. I previously built software at GitHub, Stripe, and Tuple.
Open PRs for tiny vertical slices. Letâs say youâre adding âwidgetsâ to your application. A PR thatâs all of the backend controller actions needed to support all CRUD operations on widgets is hard to review. Instead, start with a PR that introduces a blank page and a new URL behind a feature flag. Later, open another PR that displays some widgets on that page.
Even with all the magic that Rails provides, most apps need a whole bunch of things â like authentication, UI, background jobs, email sending, deployment â that arenât unique to my idea. Next time I have an idea, Iâll look for ways to write less code and maintain less infrastructure, at least to get started.
To-dos move the context of a problem about out of my brain and into a centralized place where others can consider it for their own work. A thoughtful explanation of a problem in prose is more discoverable than a commit message, a comment, or âself-documentingâ code. It can also bring more perspectives into the conversation by making the problem accessible to those who otherwise wouldnât be reviewing a code solution.
Heroku recommends hosting custom error and maintenance pages on Amazon S3, but it can be easy to upload pages there, forget about them, and have them fall out of sync with the rest of your application. One solution is to have them continuously deployed from your application’s repository.
Starting with a failing test means I know exactly what to work on: making it pass. Compared to an item on a to-do list, a failing test is better at returning my mind to the state it was in when I was focused deeply on the task.