How do Rails pros convey that they don’t just know their way around Ruby and Rails projects, but they can also be of value when it comes to solving expensive business problems with software?

How do professional software developers jump ahead from their current position WITHOUT being “language agnostic” and learning half-dozen other programming languages, just in case a potential client (or full-time employer) needed it?

For those of you who don’t know, allow me to summarize what I learned from Patrick McKenzie, Godfather of the Internet (Currently @ Atlas by Stripe).

Ruby and Rails developers who’re able to create a remarkable career in software development focus on JUST THREE THINGS, the same three things that drive most hiring and promotion decisions at business of all sizes, including startups and F500 companies.

Ruby / Rails developer who’re able to stand out from their peers focus on…

  1. Helping businesses satisfy a need for their customers
  2. Solve an expensive, internal business problems
  3. And capitalize on an in emerging business opportunity

Let’s look at three examples of how this plays out in the real-world.

1 – Satisfying a need for their customer / marketplace

Did you know that the average Staff Software Engineer at Walmart, the lowest ranked developers, earns $151, 283 per year? Walmart spends a fortune on these developers NOT because they’re better than other developers out there. Instead, their main responsibilities, which includes optimizing their ecommerce web app so that it becomes a machine that turns casual browsers into buyers is very important to both Walmart and the people who buy from them.

Even though the “business folks” at Walmart are experts in the brick-and-mortar business, their customers appreciate an ecommerce site that works 24/7/367. Hence, Walmart hires these developers and spends a fortune on them to satisfy that need.

It doesn’t make sense from the outside looking in, but I’m sure they’ve done the math and know that they can provide a lot more variety of products to their customers through their ecommerce site, and at more profitable margins, just like Amazon.

Regardless of what product or service a business sells, they’d hire a developer to build a website to peddle their wares because their customers and marketplace prefer to purchase products online.

An expert Rails developer understands this and makes that crystal clear to their potential client (or full-time employer), instead of selling themselves based on only the tech stack they’re familiar with.

2 – Solve expensive, internal business problems

Fortune 500 companies subscribe to Salesforce and spend, on average, $114,000 per year on Salesforce Consultants to customize the software because they want to find more customers, close more deals faster and keep customers happy.

Unhappy customers and slow sales-cycles are expensives problem for almost every B2B company, including Fortune 500 companies. A spreadsheet could do the same job as a CRM, right?

But a spreadsheet simply can’t solve the problem of keeping customers happy. That’s why Salesforce exits. And thousands of Salesforce Consultants focus exclusively on adding new features to system to help sales teams meet their quota, and improve the overall bottom line of the business.

You can also build a remarkable career as Ruby / Rails developer, if you focus on building software that helps businesses solve problems like keeping customers happy, consistently meeting sales quotas, and improving the overall bottom line.

3 – Capitalize on an emerging, profitable business opportunity

Basecamp, Shopify and GitHub created software to capitalize on business opportunities. Entrepreneurs and startups build software products because they want to capitalize on an opportunity before another person does.

It happens that most startups today use Ruby and Rails because if it’s good enough for Basecamp, Shopify and GitHub, it must be good enough for them too. There’s no point in reinventing the wheel or betting their livelihood and future on an unproven JS framework.

Rails is popular among entrepreneurs/startups because they can build MVPs quickly and bring their products and services to market faster to capitalize on an emerging opportunity before a competitor does. That’s why the average Ruby and Rails developer in NYC, who works at an early stage startups takes home $78,614 per year.

You could build software for a Fortune 500, a non-profit organization, or a small startup in the middle of nowhere. It doesn’t matter where, or for whom.

You’ll be doing it for one or more of these reasons:

  1. Satisfying a need for their customers / marketplace
  2. Solving an expensive, internal business problem
  3. Capitalizing on an emerging, profitable opportunity

It took me more than TWO YEARS to internalize this, so don’t blame yourself if other Ruby / Rails educators haven’t taught you this. Perhaps, they don’t know.

Had I known this sooner, I would have spent more time to learn how to turn business problems, needs and opportunities into working software.

Had I known sooner that businesses hire software developers to build Ruby / Rails applications to satisfy a need, solve a problem, or capitalize on an opportunity…

…I would have learned how to build robust, and secure software, that’s easily maintainable and uber-profitable sooner, not just working software.

I wouldn’t have wasted time trying to understand how Rails internals work (I still don’t), how to implement authentication from scratch in Rails or the 7 different ways you can deploy and backup a Rails application.

I wouldn’t have worried about which Ruby gem I should learn to use next so that I’m employable. And I wouldn’t have worried about memorizing Sandi Metz’s rules for developers.

That’s because I would’ve taught myself almost everything I ever needed to know about building software with Ruby and Rails, in the process of building valuable and working software.

And I did, as soon as I stopped focusing on the tools of the trade – HTML/CSS, Ruby and Rails, JavaScript/CoffeeScript, and PostgreSQL – and started putting on a “business analyst hat” when deciding what topics I should learn next.

I’m not telling you this to brag, but to impress upon you that understanding the business of software development helps you focus on the right things when approaching potential clients (or full-time employer) for work and figuring out how to demonstrate the value you provide.

You can also build a remarkable career in software development and jump ahead from your current position…

WITHOUT worrying about when you’ll be good enough WITHOUT learning through career-killing trial-and-error WITHOUT become “language agnostic” for a rainy day.

That’s why I’m going to show you how to MODEL the way you create software after some of the great minds in this profession, including Ryan Bigg, DHH and Fabio Akita.

I’e already shown you the ONLY THREE THINGS you should focus on as a Ruby / Rails developer who wants to show the value you can provide so that you can also create a remarkable career in software development.

In case you’ve forgotten (or skipped that section) it’s the same three things that drives hiring and promotion decisions at almost every business, including F500 companies and growth-stage startups.

It doesn’t matter if you’re a solo-consultant or looking for your next full-time position, you’ll be hired or promoted based on whether you can build software that helps the client (or full-time employer) achieve these business objectives:

  1. Satisfy a need for their customers / marketplace
  2. Solve an expensive, internal business problem
  3. Capitalize on an emerging, profitable opportunity

Once you determine the WHY behind a particular software you’re working on, the next step is to capture the requirements for the solution you plan to implement.

Here’s how to structure your software delivery process. This is the exact process used by Ruby and Rails developers you admire, including DHH, Peter Cooper and Fabio Akita, to ship uber-profitable software products.


Need/Problem/Opportunity → User Stories → Requirement Specification → Technical Specification → Implementation

Before you write a single line of code, you must wear your “business analyst hat” and create a requirement specification for the software solution you intend to implement.

Your requirement specifications should always be clear and testable, so one of the best ways to make sure you always build valuable, and easily maintainable software is to write your requirement specifications as user stories.

Let’s take the most common web app functionality, and write a clear and testable requirement specification as user stories.

Instead of writing: Sign In Functionality Required

Professional Rails developers write: As a customer, I want to sign in using my username and password, so that I can check my order history.

The benefit of using user stories to write clear and testable requirement specifications is that you always fit your requirements into a format everyone involved in the project can understand, including non-technical “business people.”

As a [STAKEHOLDER], I want to [GOAL], so that [MOTIVATION]

The [STAKEHOLDER] describes whom you’re implementing a feature for.

The [GOAL] describes what the stakeholder does with a feature.

The [MOTIVATION] describes why the stakeholder wants that feature.

Here’s the previous example again, with each component of the user story identified.

As a customer [STAKEHOLDER], I want to sign in using my username and password [GOAL], so that a can review my order history [MOTIVATION].

When you write requirement specifications as user stories, you focus on the people who will use the software you build, instead of the exact solutions and the technology stack that you’ll use.

It also makes you think more logically and strategically about the complex problem you’ve been tasked to solve, so that you can build valuable and working software for your clients (or full-time employer).

Now that you know professional Rails developers use stories to ship secure and robust software that’s valuable and uber-profitable, how can you take this knowledge and make it a core part of your own software development process?

If you’re drawing blanks right now, don’t fret because I’ve got your back. Just use the user stories and test cases written in RSPEC below…

And ship TWO Ruby apps tonight: Download my RSpec test cases.

There’s nothing more to read here.

Download the test cases above and start modeling the pros tonight. You’ll be glad you did.