If there is one thing I have learned about the world of software development and standardization of methods, patterns and even languages, it’s that if you come to the developer, you win.

What does that mean, exactly? For software development tool makers and standards bodies, it means that you have to treat your users like consumers. This means ease of use, comprehension and support are the most important things when dealing with developers.

Obviously, developers love many things. They love beer and pizza. They love extremely powerful tools like the one-two punch of C and GCC. Developers love familiarity and appreciate anything that can save them time.

Over the past decade, the idea of what makes a developer a developer has solidified, and the world has grown to include millions of them. But there have been times when the developer was not the focus of a development tool effort.

The days of WS-* and SOA were such a time. Certainly, everyone would say they were thinking very closely about developers and were trying to provide them with powerful solutions to problems that would potentially arise from a service-based world.

But in the end, the entire shebang was replaced by REST as a method of communication between services. Why? Because it was dirt simple. When given the choice between an option that requires only a single-sentence description, and a book-sized standard, the sane developer will always choose the simpler of the two.

That’s not to say extremely complex solutions and standards aren’t necessary, but only to say that getting your API, your SDK, or your new language adopted by developers in the millions requires such thinking.

And this is the world in which many enterprises will soon be living. Developers are the most precious resource in our business economy right now. Every type of entrepreneurial endeavor can be made more efficient, more profitable, more defensible given the proper use of software. It’s the modern-day equivalent of high seas sailing ships for 16th-century European nations: The bigger your fleet, the more of the world you can control.

And the bigger your fleet of software, the more markets you can enter, the more competitors you can match, and the fewer human bodies you actually need to reach the bottom line. For every 10 developers your company hires, you should be able to eliminate at least that many physical laborers within either your organization or your users’ organization.

As Marc Andreessen says, software is eating the world. It puts good, honest, hard-working people out of business, and yet also gives the hopeless and adrift a lifeline to keep themselves afloat.

Observe the way that Lyft is putting taxi drivers out of work, while also giving a whole way of providing livery to those that take the jump using their own car to become, in fact, a taxi.

This has occurred because there is tremendous need for innovation in industries that, typically, don’t even have R&D budgets. From taxi services to car washes to home food delivery, these are all the things we earnestly thought we’d be changing back in 2000, when the original dot com revolution held the Valley’s eyelids open and pointed its head directly at the sun.

But now, it’s finally happening. Software is eating the world. And if your company isn’t ready to lay a golden path (strewn with valets and washroom attendants) to the world’s software developers, you’ll be left behind.

And the metaphorical secret to developers (when speaking in aggregate, mind you) is that developers are just as lazy as your average human. Make your APIs dirt simple. Make your documentation short and easy to grok, backed up by those longer bits in an easily searchable storage format. And whatever you do, listen to the developers who speak to you, even if they say something glib or cruel.

The path to success in software tooling leads toward those millions of developers. The best and brightest might be easy to win over with math and PowerPoint presentations, but there are a lot more out there that could be reached with a one-line RESTful API call example at the top of your “How To” page, followed by a few more examples in clear, bold text.