DEV Community: Nick Holden

Is $170,000 top 10% pay for software developers in San Francisco?

Nick Holden — Wed, 13 Mar 2024 17:08:06 +0000

The short answer: no. According to the U.S. Bureau of Labor Statistics, the 90th percentile annual wage for software developers nationwide is $198,100.

Developer salaries are much higher in San Francisco. According to Gusto, the 90th percentile annual salary for software engineers in San Francisco is $215,000. They note that "offering a total compensation package that includes employee benefits and bonus pay to incentivize performance, in addition to competitive base pay, can help attract and retain top talent."

37signals claims they pay "in the top 10% of the industry based on San Francisco rates" and that the salary for Programmers is $170,000. Can that be accurate?

It's not clear what "industry" 37signals refers to in their statement. We know that software developer salaries at non-tech companies can be lower than software developer salaries at all companies in general and much lower than software developer salaries at tech companies. Gergely Orosz covers this well in The Trimodal Nature of Software Engineering Salaries in the Netherlands and Europe.

Is 37signals a tech company? Their business is building and selling software. When they accepted investment from Jeff Bezos in 2006, they wrote about this him: "What we’ve been looking for is the wisdom of a very special entrepreneur who’s been through what we’re going through." 37signals looks like a tech company.

It's also not clear what 37signals means by "San Francisco rates" in their statement. One portion of pay that San Francisco software developers receive is salary, the 90th percentile of which is $215,000 according to Gusto. Many San Francisco software developers also receive equity compensation, and it's not uncommon for the equity portion to be larger than the salary portion. In all public companies and even some private companies, workers can sell that equity portion for dollars.

37signals does not offer traditional equity compensation. They do offer profit sharing, in which employees with more than two years at the company split 10% of the profits based on tenure, and a liquidity pool that they never intend to use.

So can it be true that 37signals pays in the top 10% of the industry based on San Francisco rates, which includes paying programmers $170,000? Possibly. We'd need to know their definition of "industry" and "rates." At best, the statement is unhelpful and misleading.

I love that 37signals is transparent about salaries. It allows applicants to self-select and stops workers from wondering if they're being paid unfairly.

37signals is a proudly independent company, and they can pay any rate that the law allows. At $170,000, they'll receive many highly qualified applicants for the position. I wonder why they don't remove the unhelpful and misleading "top 10%" statement.

Hacking Code Review: Share a resource

Nick Holden — Tue, 07 May 2019 13:41:07 +0000

This is part of Hacking Code Review, a series of bite-sized hacks you can start using today to make your code reviews more impactful. Subscribe to be the first to know about new hacks.

Reviewing code requires some original thought. When I read through proposed changes, I think about how the code makes me feel and what my future self might think when I come across it. I spend time collecting my thoughts and feelings and putting them into words that will be helpful and persuasive.

Often though, somebody else has already said what I’m thinking in a better or more comprehensive way. Developers are fortunate that the internet is chock-full of ideas and prior art that we can borrow from. Sharing resources in code review is a great way to make your reviews more impactful without much extra effort.

What to share

Sharing API documentation is great for making sure that the reviewer and author are on the same page. It’s easy to develop assumptions about an API’s functionality that may or may not be true, especially as developers become more comfortable with the syntax and conventions. Linking off to documentation ensures that the reviewer and the author have a shared understanding of the APIs they use.

Is this the distinct we're using here? Since we want distinct records, I don't think we need an argument.

Blog posts are another helpful resource to share in code review. There are a handful of blog posts that I always refer back to when I bump into a specific kind of problem, like timezones, character encoding, or form UI. Start building up a library of helpful blog posts, and drop them in code reviews when they’re relevant so that you can develop some common knowledge with authors.

I learned in this awesome blog post that exists? always executes a SQL query. Should we memoize this or consider using present? to avoid making multiple queries?

Teams make all sorts of decisions that aren’t formally documented. To uncover some of those in code review, I share links to old issues, merged pull requests, and existing code. Through discussions, previous code reviews, and commit messages, I can help piece together the story of why we solved a problem in a particular way and if it makes sense to take that approach again.

I really like the user experience for publishing (#105160), which disables the form and includes an explanatory note for users marked as spammy. What do you think about taking a similar approach here?

How to share

Provide context when you share a resource. Dropping a link by itself in a review is cryptic, and it can leave the author guessing what you’re suggesting they do. Authors are more likely to appreciate the resource if you make it clear that your intent is to share something that could be helpful rather than to shame them for not knowing something that you knew already.

VCR has some request matching options that might mean we don't need to get these URLs exactly right to reuse the desired cassettes. I'm wondering if it might be worthwhile to explore that so we can decouple the cassettes from the tests a bit.

Combining a resource with a compliment can be particularly effective. If you appreciate one of the author’s approaches and you’ve seen it executed well somewhere else, share it. It’s a great way to give the author some extra affirmation, and it gives them something to think about the next time they encounter a similar problem.

I love how reusable this new .text-center class is. Have you heard of Tailwind CSS? It’s a whole framework of utility classes like this. Maybe we could consider using it in the future if we like this style.

In code review, a link is worth a thousand words. Save yourself some keystrokes and look for opportunities to share helpful resources.

Cover image by Michael D Beckwith on Flickr.

Hacking Code Review: Give a compliment

Nick Holden — Tue, 23 Apr 2019 15:10:59 +0000

This is part of Hacking Code Review, a series of bite-sized hacks you can start using today to make your code reviews more impactful. Subscribe to be the first to know about new hacks.

It’s easy to think of code review as an opportunity to find all the mistakes in a pull request. When I first look at proposed changes, I can be drawn to the code that’s most surprising or confusing, and it’s natural to begin thinking about what could be handled in a different way.

But if all your code reviews are exclusively critical, you could come off as hostile. Other developers may become frustrated and seek your feedback less often.

In your next code review, give the author a compliment about something you thought they did well.

When to give a compliment

One of the best times to give a compliment in code review is when you notice a novel approach. Authors tend to feel less confident about changes that don’t reuse a well-established pattern in the codebase, so when you see a positive change that looks different from what you’re used to, show your support. By giving a compliment, you send a signal that you’d like to see more changes like it in the future.

I know we usually stub this out, but your approach of calling the actual method in this test is 💯. I feel much more confident that we’ll catch changes to the API in the future. 😍

Another great time to give a compliment is when the author is a new contributor. This can be someone who is making their first pull request to a repository, but it could also be an author who is proposing changes outside their area of expertise. Giving a compliment to new contributors makes authors feel appreciated, and they’ll be more likely to contribute in the future. Having more developers comfortable contributing to more parts of the codebase leads to more resilient teams and software.

Love how you made this its own PR. I can see the temptation to group it with the rest of the changes that are coming to this model, but keeping this PR focused made it easy to follow and a joy to review. ✨

One other opportunity to give a compliment is when most of the rest of your review is critical. Don’t force compliments or try to maintain a certain ratio of positive to negative feedback—authors will notice when you’re not being authentic. Instead, compliment one specific thing about the change that you genuinely appreciate. A thoughtful compliment could help the author begin to think of ways to improve the rest of their proposed changes.

How to give a compliment

An impactful compliment is specific. If the compliment about a particular section of code, explain why you like it. Specific compliments help authors understand what they did well and what they may want to replicate in the future.

Woah, I had no idea that the old version of this scope wouldn't include records where type is nil. Great job thinking through edge cases!

Compliments of the change on the whole can be impactful, too. More meta feedback on things like impact, scope, or timing can show your appreciation for the author’s overall approach.

This refactor is awesome! I’ve been feeling pain working with this class lately, and this feels like the perfect time to make the arguments more straightforward. ❤️

Code reviews aren’t all about being critical, so next time, call out something you like about the author’s work. Everyone will feel great, and your review will be more impactful.

Cover image by Epic Fireworks on Flickr.

How I replaced a Rails app with a few dozen lines of Ruby

Nick Holden — Mon, 25 Feb 2019 16:29:35 +0000

A couple years ago, I broke a dashboard at work.

As part of building a new feature, I changed our database schema. I carefully laid out a plan to add some new columns and migrate existing data. I made sure the changes to the database would work with both new and old application code and the feature could be deployed without any downtime.

I forgot to consider that our application wasn’t the only consumer of our data. Our data team maintained dashboards that the company used to inform product decisions and make financial projections. Those dashboards expected our database schema to look a certain way, and when I made the changes without talking to the data team, one of those dashboards broke.

After we fixed the dashboard, I thought about how I could prevent myself from making the same mistake in the future. I decided needed a reminder each time I made a change to our database schema. To get that reminder, I reached for the tool I was most comfortable with and spun up a new Rails app.

There’s a lot to a Rails app

My goal with the app, DiffAlert, was to send an alert to Slack each time someone made a change to db/structure.sql on the master branch of our company’s application. I saw that GitHub had webhooks and that the push event sent along data about commits, including which files were changed.

In a few hours, I spun up the app, created an endpoint for the GitHub webhook events, and wrote the code to tell whether or not db/structure.sql changed in a given push. DiffAlert’s core logic was complete. Then the real work started.

Next, I had to figure out how to send an alert to Slack. We were already using Slack’s Email app, so I signed up for a new Mailgun account and created an email template with Action Mailer. Then I had to deploy DiffAlert somewhere, so I created a new Heroku application and did some tweaking to get everything properly configured with my workflow.

Besides db/structure.sql, we’d also want to monitor a few other files in our codebase, so I started building a UI to configure alert settings. I’d need authentication, so I designed the data model and created login and sign up forms. Then I needed another view to show all the alerts, and I needed forms to create new alerts and edit existing ones. I needed background jobs so that longer processes like webhook parsing and email sending wouldn’t hold up regular web requests.

DiffAlert chugged along for about a year and a half, reminding my team in Slack when we made changes to our database schema. Each time, we reached out to the data team and didn’t break any more dashboards.

DiffAlert was a side project, so when I left the company, they needed to decide if they would continue sending a former employee their GitHub metadata, maintain their own instance of DiffAlert, or stop receiving alerts. They understandably decided to stop receiving alerts.

GitHub Actions helped me focus on the problem

I work for GitHub, and when I learned about GitHub Actions, I wondered if I could replace DiffAlert with a single Action. A GitHub Action is code, written in any language, that runs in a Docker container when a specified event happens in a repository. I saw that push events could trigger GitHub Action workflows. I also saw that there was a GitHub Action that could post messages to Slack. I started writing Modified File Filter.

First, I needed a Dockerfile. I wanted to write my Action in Ruby, so I used the FROM instruction to create a Docker container from an official Ruby base image. I wrote some LABEL instructions so that my Action would show up correctly in the GitHub Actions visual workflow editor. Finally, I specified which folders the Docker container would need access to and pointed the ENTRYPOINT at an executable Ruby script.

# Dockerfile

FROM ruby:2.6.0

LABEL "com.github.actions.name"="Modified File Filter"
LABEL "com.github.actions.description"="Stops a workflow unless a specified file has been modified."
LABEL "com.github.actions.icon"="filter"
LABEL "com.github.actions.color"="orange"

ADD bin /bin
ADD lib /lib

ENTRYPOINT ["entrypoint"]

The executable Ruby script delegates most of the work to a plain old Ruby class, PushEvent, which parses the event data from GitHub and answers whether a file at a specific path is modified. When a push event modifies the file, the Action exits with a 0 status to trigger the next Action in a workflow. When a push event doesn’t modify the file, the Action exits 1 to halt the workflow.

# bin/entrypoint

require_relative "../lib/push_event"

file_path = ARGV.first
push_event = PushEvent.new(File.read(ENV.fetch("GITHUB_EVENT_PATH")))

if push_event.modified?(file_path)
  puts "#{file_path} was modified"
  exit(0)
else
  puts "#{file_path} was not modified"
  exit(1)
end

I didn’t need to configure emails or figure out how to integrate with Slack since I could lean on the existing GitHub Action for Slack. I didn’t need to design any UI or authentication because that was all handled by GitHub. I didn’t need to configure databases or background jobs. I didn’t need to spin up a Heroku application and set up deployments.

Starting smaller

Rails has a reputation for being a great framework for validating ideas. You can use Rails to build a blog in 15 minutes! Because I love working with Rails, I often reach for it first when I have an idea.

But 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.

Cover image by Iain Farrell on Flickr.

Crawl Vote: Helping groups on the move pick a next spot

Nick Holden — Thu, 24 May 2018 15:37:16 +0000

What I built

Crawl Vote helps groups on the move pick a next spot. Whether they’re looking for poutine in Montreal or tacos in Tijuana, Crawl Vote will return some suggestions for everyone to vote on together.

Demo link

https://crawlvote.com

Link to code

nholden / crawl_vote

Helps groups on the move choose a next spot

Crawl Vote

Helps groups on the move choose a next spot

Installation

git clone git://github.com/nholden/crawl_vote
cd crawl_vote
brew install redis postgresql heroku
bundle install
yarn
cp .env.example .env
bundle exec rake db:reset

Getting started

Sign up for a Pusher Channels app at https://pusher.com/signup and a Yelp API key at https://www.yelp.com/developers/documentation/v3 and update .env.

Start these long-running processes in separate terminal windows:

heroku local
webpack-dev-server

Crawl Vote should be accessible at http://localhost:3345 (or whichever port you specify in .env).

Testing

bundle exec rspec

Contributing

Contributions are welcome from everyone! Feel free to make a pull request or use GitHub issues for help getting started, to report bugs, or to make feature requests.

License

This project was created by Nick Holden and is licensed under the terms of the MIT license.

View on GitHub

How I built it

Crawl Vote uses Ruby on Rails on the back end Vue.js on the front end. I used Webpacker, which comes with a Vue integration, to compile and bundle my JavaScript, CSS, and images. I used Tailwind to quickly prototype my design without writing any CSS.

I used Pusher Channels in a couple ways. When a user first submits where they’re going and what they’re looking for, Crawl Vote creates a new “crawl”, gives it a unique name, and subscribes the user to a Pusher channel with that name. Then, the application kicks off a Sidekiq job to query Yelp’s Fusion API in the background. Once the job has fetched relevant businesses and persisted them to the PostgreSQL database, it triggers an event to the Pusher channel. When the user’s browser receives the event, a Vue component uses the Fetch API to make a request to grab all of the relevant data and display it on the screen.

Once the user has successfully created a crawl and invited some friends, Pusher Channels allow everyone to see the voting in real time without refreshing their browsers. When a user clicks the vote button next to a spot, it makes a request to the application that persists the vote and triggers an event to the Pusher channel. When all the users’ browsers receive the event, the Vue component makes another request to refresh the data on the screen.

I had never used Vue’s List Move Transitions before, but I was really impressed how, with very little CSS, Vue added silky smooth animations as spots moved up and down in the rankings. Magic! ✨

To identify users, Crawl Vote assigns each person a UUID and stores it in the user’s session. When a user first visits a crawl or refreshes the page, the applications identifies the user directly from the session and renders the data server side. When the user’s browser receives a Pusher event letting it know that it’s time to fetch more data, the UUID is sent along as a token in the authorization request header.

Crawl Vote is continuously deployed to Heroku by Travis CI and is served by Cloudflare. I’m using Rollbar for exception tracking and Papertrail for logging. The only thing I paid for was the domain name, which came from Namecheap.

What’s next

I’m happy with how things turned out for this MVP, but I have a whole bunch of things I’d love to try with more time. I’d like to increase test coverage, including at least one or two Rails system tests that click through my Vue components using Headless Chrome.

I’d also like to continue improving the UX/UI, including adding autocomplete to the form fields. The categories that Yelp’s autocomplete endpoint returns look like they could be useful for the “Find” field, and I’ve been happy working with Google’s Place Autocomplete in the past. The design overall could use a little sprucing up, and I think some thoughtful use of color could help the look and feel better reflect the spirit of the app.

Finally, it would be great to do some more tweaking with the parameters Crawl Vote sends along to Yelp’s API. There are a lot of options, and I’m not sure I’d want to expose too many to the user since the complexity could turn people away, but I’d love to do some optimizing to make sure Crawl Vote returns a great selection of spots for every query.

Resist the ‘quick fix’

Nick Holden — Mon, 12 Mar 2018 15:17:10 +0000

I often come across problems that, on the surface, seem like they’d be “quick fixes.” Maybe it’s a bug that could be resolved by tweaking one variable or a new feature that could be added with a change to one branch of a conditional.

When I notice opportunities for quick fixes, I naturally start thinking through the implementation. Popping open my text editor and making the change is tempting. I like coding; it’s a big part of why I’m a developer. Shipping code makes me feel productive. And because I’m almost always working by myself or on a small team with lots of trust and autonomy, nothing’s stopping me from creating a new branch and hacking away.

Most of the time though, resisting the temptation to code the quick fix, and writing a public to-do instead, results in better outcomes.

To-dos take more time upfront but can ultimately lead to less work. A number of times, I’ve shared a to-do and learned that someone else on my team was thinking about a similar problem and addressing both of them at once would be faster and result in a better solution. Other times, I’ve created a to-do about something I think is a problem, but through discussing the to-do, I’ve learned that a change wasn’t necessary after all.

The visibility that creating a to-do brings to a problem extends beyond getting out of extra work. Getting trapped in a cycle of working on quick fixes in a silo can leave me feeling disorganized and others wondering how I’m spending my time. Making a public to-do shows my team where I’m focusing my energy and allows them to contribute when it makes sense.

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.

Often a “quick” fix isn’t. A few times, I’ve started coding a fix, and as time ticked away, I’ve found myself so deep down a thread in the codebase that I forget about the original problem I set out to solve. The exercise of unpacking a problem in English can shake out nuances about the problem that can prevent journeys down rabbit holes.

To-dos lessen cognitive load, too. While working on one problem, it’s easy to find a handful of other problems, and defaulting to quick fixes would force me to keep all of those in my head. Noting those problems in to-dos along the way and moving back to the original one keeps me focused.

All that said, sometimes, issues pop up that seem like clear candidates for quick fixes. Even though I default to to-dos, sometimes I’ll use my discretion and start by poking at some code. In those cases, timeboxing is helpful. If after 20 to 30 minutes I’m not feeling very close to some sort of resolution, I’ll stop and create a to-do, even if I intend to go right back to working on the same solution.

But most of the time, starting with a public to-do instead of a quick fix turns out better for my code and for the people I work with.

Cover image by Trilok Rangan on Flickr.

Continuously deploy custom Heroku error and maintenance pages from your app’s repository

Nick Holden — Mon, 29 Jan 2018 16:44:34 +0000

If you’ve accidentally deployed some bad code to Heroku, you may be familiar with Heroku’s application error page. Or maybe you’ve needed to put your application into maintenance mode and you’ve seen Heroku's maintenance mode page.

Both of these pages are customizable via config vars. All you need are publicly accessible, static HTML pages living somewhere outside of your application. Heroku recommends hosting them 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 way to avoid losing track of custom error and maintenance pages is to have them continuously deployed from your application’s repository. Here’s one way to do that.

Pick a directory to serve the pages from

This could be a new directory in your repository or one that already exists. Be aware that for whichever directory you pick, all of its files will be publicly accessible.

My application, Monday Miles, is a Rails application, which means that the /public directory is already publicly accessible. Serving a mirror of it didn’t seem like a big deal in my case, so I chose to store my error and maintenance pages in /public. Other options include a separate /pages directory or perhaps a directory named after the domain from which you plan to serve these pages.

Add your pages to the directory

The pages should be static HTML pages. While you won’t be able to access assets from elsewhere in your application (like from the Asset Pipeline for Rails), you can upload images and CSS into the same directory and reference them with relative paths.

I already had a /public/500.html page for Monday Miles, so I reused that for my error page. I tweaked the copy to create my /public/maintenance.html page.

Create a new Netlify app

Netlify is an awesome service for hosting static sites. It can do some fancy stuff if you’re using a static site generator like Jekyll or Middleman, but it’s also great for hosting plain old directories of static HTML files. My favorite advantage of Netlify over GitHub Pages is that it provides free, one-click HTTPS for custom domains via Let’s Encrypt.

Once you’re signed up, click “New site from Git.” Choose your Git provider (as of writing, GitHub, GitLab, and Bitbucket are supported), select your repository, and choose the branch to deploy from (probably master). To ensure that you’re only exposing the desired directory, you can either enter that directory in to the “Publish directory” field or add a super simple netlify.toml configuration file to the root of your repository (here's mine for Monday Miles). Since you’re not using a static site generator, you don’t need to set a build command. Click “Deploy site,” and verify that your pages are live at the provided *.netlify.com domain.

Set up your custom domain (optional)

Heroku will serve your error and maintenance pages within an iFrame, so it’s unlikely that your users will notice if the pages are served from *.netlify.com. However, Netlify makes it so easy to get started with a custom domain that I think it’s worth the couple extra minutes.

On the Overview page for your new Netlify app, click “Set up a custom domain” and follow the instructions to add a custom domain (I chose public.mondaymiles.com). If your domain lives with a provider that provides a CDN like Cloudflare, be sure to set the new CNAME record for “DNS only,” since Netlify has its own CDN. Follow the instructions to provision a Let’s Encrypt certificate and enable HTTPS.

If you want any requests for non-existent files at your Netlify domain to redirect users to your main application, you’ll need to add a _redirects file to your Netlify publish directory. Here's what mine looks like.

Configure Heroku

Set the ERROR_PAGE_URL and MAINTENANCE_PAGE_URL config vars to point at your error and maintenance pages on Netlify. You an do this through the Heroku CLI or through your application’s dashboard on the “Settings” page. Remember to do this for all of your applications if you’re using Heroku Pipelines. Follow Heroku’s instructions to test your error and maintenance pages.

And that’s it! Anytime you update those pages in your application’s repository, they’ll be updated on Netlify. Instead of seeing the generic Heroku error and maintenance mode pages, your users will see the custom pages you created (hopefully not too often!).

Try ending today with a failing test for a great start tomorrow

Nick Holden — Mon, 15 Jan 2018 15:45:26 +0000

Tying up loose ends at the end of the day feels nice. Completing a task, committing my work, and shutting my laptop leaves me with a satisfying sense of accomplishment that sticks with me through the evening. And on those days when I grapple with a problem for a while and don’t come to any resolution, I can feel a little defeated.

While it’s nice to watch my test suite pass and call it a day, I’ve found that some of my most productive mornings come when I’ve left myself a failing test the night before.

Mornings are a great time to get caught up and plan. But it can be challenging to transition from organizing and digesting to opening a text editor and getting into a flow state. When I get some momentum working on a tricky problem later in the day, I want to bottle it up for morning. I can get close with one failing test.

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. Maybe I even spent a bit of time the night before thinking about how I might approach it, so the implementation is a quick win.

It doesn’t work all the time. Sometimes, priorities change overnight, and I have to put the test aside and focus on something else. But often, I find that a little time spent writing a failing test at the end of the day lays the foundation for a great morning.