Farmers, Pioneers and Software Engineers
I’ve worked with a lot of software engineers and met hundreds while speaking at conferences and running a local meetup. Broadly speaking, software engineers come in two types: Pioneers and Farmers.
The Pioneer
In the 1840s President James Polk (ignoring the fact that Native Americans already settled the land, but that’s another blog post) opened up the Oregon Territory to American settlers.
In theory, anyone could pack up their wagon and move to the Oregon territories and claim free land. In practice, only 100 people were willing to risk the journey in 1842 because the 2,000-mile trek was incredibly dangerous and difficult. Pioneers faced disease (dysentery anyone?), wild animals, harsh terrain, unpredictable weather, and uncertain fortunes when they arrived.
This Pioneering spirit has always been lauded in the American mythos, and you can still find remnants of it in fields like software engineering. Pioneers are creative, innovative, and continuously on the move. They seek fortune and fame by taking on risks that most of us would deem unnecessary.
You will find lots of Pioneers at early-stage startups and working as freelance software engineers.
Strengths
Pioneers love attacking new problems, trying new languages, and starting greenfield projects. They were the first to implement a blockchain, the first to use AI to generate deep fakes, and the first to adopt and then dump microservices.
If they’re also process-driven, they can help establish best practices like CI/CD and automated testing. If they’re good communicators, they can help kickstart your documentation, teach the rest of your team, and be the face of your engineering organization.
Pioneers tend to take a lot of the glory in software engineering, but this comes with some caveats.
Weaknesses
These same characteristics that make Pioneers so exciting to have on your team become their biggest weaknesses when left unchecked.
For example, a Pioneer will always solve the problems you give them. They may hack their own company’s servers to do it, but they’ll find a way.
Pioneers also tend to get carried away when they find exciting new technology. They may rewrite your data abstraction layer in a weekend just so they can play with GraphQL, but is that really the best thing for your company?
Tips for Pioneers
If you are a Pioneer, find roles that offer you increasing challenges. When left unchallenged, Pioneers will create hurdles for themselves, which means they’ll make simple problems more complex than they need to be.
Your role as a Pioneer is to set things up and then train others to maintain them. The most effective Pioneers move around their organization (or to other organizations) frequently, set up awesome new products and systems, teach the rest of the team to maintain them, and then move on.
Some managers won’t understand you (they’re likely farmers), and you’ll be a terrible fit at buttoned-up, slow-moving organizations, but that’s okay. Your ability to learn things quickly and live on the cutting edge will make it easy for you to stay employed.
Tips for Managers of Pioneers
Pioneers need to feel autonomous and challenged. That means you cannot micromanage a Pioneer or tell them exactly how to solve a problem. For Pioneers, the fun is in figuring things out.
At the same time, you should not let Pioneers run rogue. Your job as a manager is to direct them to the most productive, high-value targets in your organization that excite them. If you fail to do that, you’ll lose the Pioneer pretty quickly.
The Farmer
During the Western migration, the number of Pioneers grew, and eventually, they blazed a reliable, relatively safe trail. Farmers settled all the land between Illinois and Oregon to produce a wide variety of crops (now it’s all corn, but that’s also another blog post). Farming wouldn’t have been possible without the early Pioneers - someone had to conquer the unknown - but Pioneers wouldn’t (or couldn’t) survive by farming the same old land they always had.
Farmers realize that not everything that Pioneers do is good, and are often miffed that Pioneers get so much of the credit.
You’ll find Farmers quietly writing Cobol apps at Fortune 100 companies, maintaining our power grid, and running high-availability data centers. They’ll be implementing incremental improvements that create millions of dollars in value for large organizations; they’ll be shaving milliseconds of TCP requests; they’ll be attending programming competitions in their free time to sharpen their skills.
Things that most Pioneers would abhor are delightful to Farmers.
Strengths
Great Farmers don’t just maintain codebases; they optimize the shit out of them.
Farming rewards patience: Farmers have to wait months just to get their first crop! They know that their work will take time, so they painstakingly work to get it right and continually improve it.
Farmers probably know 1 or 2 languages better than anyone else in the organization (maybe the world), and they’ll ace any technical coding challenge because they’ve actually used the Sieve of Eratosthenes in production before.
Farmers typically know one part of the codebase really well, and they can debug anything in it. If they’re good communicators, Farmers can pass their knowledge to others on the team and easily quadruple their value. If they like processes, they might shave 15 minutes off your test suite over the weekend just to see if they can.
Weaknesses
Again, strengths become weaknesses when left unchecked.
Farmers can spend way too much time solving inconsequential problems, obsessing over unit test coverage, or failing to ship because it isn’t good enough. They will struggle to set up a new application - they need some constraints to be most effective - and will get annoyed when a Pioneer comes into their world and starts fiddling with things.
Because Farmers like to take ownership of their code for the long-term, Farmers who don’t communicate well can decrease your team’s bus factor. They can also be resistant to change, pivots, or new business requirements.
Tips for Farmers
Find a role with a well-established company that rewards patience and optimization.
You don’t want to become one-dimensional, so make some space in your schedule to learn something new every quarter. While money may not be your #1 motivator, don’t forget that loyalty is rarely rewarded in our field, so go use those algorithm skills and get a new job every few years to work up the pay ladder.
Don’t get too annoyed with the pesky Pioneers you run across. Just remember that they’re different from you, and things that you find blissful are annoying to them.
Tips for Managers of Farmers
Deploy your farmers to maintain and improve existing codebases, but set clear expectations around the quality level they need to achieve.
When a Farmer gets obsessed with a problem, help them understand the big-picture goal and think about whether it’s worth another week of their time. Farmers tend to fall into the sunk cost fallacy pretty easily, so try to help them out of it.
Farmers are precious in large, mostly stable codebases, but they’re rarely paid as much as they’re worth. Go to bat for your Farmers when it comes to pay raises and make sure you keep them as long as you can.
Finally, find ways to push your Farmers to learn and teach others. They can be fantastic force multipliers when they can train junior engineers.
Why These Archetypes Matter
Most of the Pioneers who took to the Oregon Trail in the mid 19th century settled down, raised a family, and built a homestead on their land. They became Farmers over time, and future generations of Pioneers and Farmers both came from their efforts.
Over your career, your role as a Pioneer or Farmer may change: you may oscillate between these two ends of the spectrum every few years, or you may find a happy place and stick with it.
The field of software engineering is huge. We need both Farmers and Pioneers. The trouble crops up when a Farmer is hired to do a Pioneer’s job or vice versa.
As companies and codebases transition from startup to mid-stage to stable, they need different types of engineers at various leadership levels within the company. An early-stage startup may want a Pioneer to deliver their MVP, but no company is going to cowboy code their way to an IPO. This is why you rarely see the first engineer at a startup taking the company public.
It’s just as rare for Farmers to excel in early-stage startups. The risks and unknowns are just too high, and there’s no way they will be able to deliver software at the quality they need to while the company stays nimble enough to survive.
Labels like this aren’t perfect. People almost always land somewhere on the spectrum between Pioneer and Farmer, but I’ve found these two dichotomies help me make better management and career decisions.
What do you think? Find me on Twitter to continue the conversation.