When you think of a developer what comes to mind? A brogrammer living in San Francisco working 23 hours a day on the next Facebook? If so, you wouldn't be alone. Like so many industries, software development is rife with stereotypes. And one that is particularly pervasive is the idea that all developers, if given the chance, would opt for a complete rewrite of an application.
While it's true that there are many software developers who do enjoy starting with a clean slate, there is also a group who loves working on making existing applications better. Rather than starting from scratch and building an 80% solution, these developers are ideal for taking over a project once it's become stable, and nurturing it for a long time. Neither developer is better. Both are needed in the software world. You just need to understand when to use each one.
Makers Enjoy Initial Development & MVPs
To demonstrate how these developers are different, let's look at the typical product lifecycle. When a project begins, there is a burst of development that must occur for a project to get off the ground. For developers that identify as "makers", this is an ideal state. They love a blank canvas. So much so, that these types of projects, are often referred to as Greenfield projects. For developers who enjoy testing the viability of an idea, working on projects like these can feel like a little slice of heaven. Anything seems possible. The sky is blue, dotted with white puffy clouds, and the grass, in their mind, is always greener.
Once the project has the desired feature set, it's time to introduce it to market. Often this is done as a Minimum Viable Product (MVP). The app is still small, and the mental model is generally not too complex. At this point, the market will decide what happens next. Either the app will gain traction, and grow its user base, or it will fade into obscurity.
Menders Prefer Working on Apps that Are Stable and Growing
At this point, the tasks for the developer shift. Instead of thinking big and implementing architecture, they'll need to focus on things like security, scalability, performance, bug fixes, and feature enhancements. The work becomes more detailed than it was at the beginning of a project and to the frustration of many a product owner, the developer's interest begins to wane. To makers, the fine details and craftsmanship required at this phase aren't as fun.
But there is a group of developers whose talents and interests are well suited for these types of tasks. They haven't had a name until now, but we like to call them "menders". Menders love refactoring, or editing code to enhance clarity. Bug fixes genuinely excite them and they get a little giddy about testing. These are all qualities that may not be as useful at the beginning of a project, but as your app grows and becomes more complex, these are definitely traits that you'll want on your team.
Makers : New Construction :: Menders : Remodeling
Another way to think of the maker mender difference is to think about the difference between new construction and remodeling. With new construction, you're often starting with a cleared piece of land, similar to that blank text editor that makers like so much. Mending, on the other hand, is more like the show "This Old House". There's often a very good reason that the existing structure should stay, but to update it requires digging in, knocking down walls, and sometimes dealing with the unexpected things you find.
Motivation Tactics for Makers and Menders
Like with any mix of personalities, diversity is typically a good thing. Most likely, you'll want to have a mix of makers and menders on your team. The key is knowing how to motivate them so you'll get the best performance. Makers are like rabbits –Â they burst with speed for a short period of time. Menders are more like the tortoise. In their world, slow and steady improvements wins the race.
Let Makers Experiment and Give Them a Deadline
Nothing bores a maker more than repetition. So keep your makers engaged by tasking them with experiments. Allow them freedom to look into the future and employ design thinking. Need a prototype to prove a concept? Call on a maker. They'll enjoy standing something up quickly. Makers are also likely to thrive at hackathons where there's high energy for a short period of time. And if you're in a crunch and on a deadline, makers will step up to the challenge as they are often motivated by time pressure. Crossing over a big deadline gives them a sense of accomplishment, so sprints are a good project management tool for these folks. Just don't expect them to stay put on one project for too long. Makers love exploring new ideas and will get bored easily if their project is too tedious.
Give Menders a Series of Small Wins Throughout the Day
The blue-sky thinking and deadline driven project management that motivates a maker is often stress inducing for a mender. What they may lack in excitability, they make up for in consistency. A mender is an ideal person to tackle technical debt, fix bugs, fine tune features, create a style guide, and monitor support tickets. Unlike their maker friends, menders do best when their work is steady and relatively predictable. Have a problem that no one has been able to solve yet? Share it with a mender. They'll enjoy the challenge of digging in really deep and figuring out what's going on. Just be careful not to micromanage your menders, as that will annoy them to no end. Instead, develop a long backlog of tasks and give your menders autonomy as to what gets done and when. If there is a priority or deadline, communicate it well in advance to allow for unkown unknowns to surface.
So how about you? Are you a maker? Mender? Something in between? What motivates you to develop your best software?
Oldest comments (44)
I am definitely more of a maker, but I could see myself evolving over time to be more of a mender. I think it can depend on the exposure you get to different challenges.
I'm kind of right in the middle, similar to where I am on the introvert/extrovert scale. Too much time on either side and I start craving the other. I love diving into the details but I also enjoy creating new things and exploring.
I feel that I'm in the same position as you Andrea. I love spinning up new projects and having complete control on all the exciting technology choices, but it certainly is nice to be working on a tried platform that is stable.
I think having that balance between the two is very important though. There are characteristics of both mindsets that are great to have when starting a new project as well as maintaining a legacy project.
I'm more of a maker but I also enjoy fixing bugs, specially if they are challenging. Also, I think no one should ever be micromanaged.
I hate micromanagement, too. That's why I think it's important to identify people's strengths and learn what they enjoy working on. When someone finds pleasure in their work, it's amazing how much more productive they are.
Amazing article! I'm a maker, 100% sure. I love to start a new project, choose what language, patterns and libs to use. It's a exciting moment, only makers can understand.
You are right about hackathons and be motivated by pressure too. Makers wish to be challenged to push their limits and learn new things.
I prefer to work in x-functional teams with a lived you-build-it-you-run-it philosophy of ownership. Their, every Maker needs to become a Mender and vice versa: Menders are part of the rapid-prototyping phase!
Hope that those, who calls themselfe "Makers" do not ignore security and scalability topics per se ;)
Cheers
I remember meeting with you during my senior year of college at the recommendation of one of my professors (Tyler Darden). One thing I still remember from that meetup is the discussion of makers/menders and how, at the time, I was solely a maker. Now almost 3 years later, not only would I say I've grown an appreciation for mending, but I truly enjoy both making and mending.
This bit of wisdom was truly helpful, and I'm glad to see it shared with the development community at large!
Nice to see you on here Joel! It's such a small world. :)
Seems like there's potentially a room for a 3rd camp. Surely someone out there revels in A/B testing, but I don't think it's the Makers or Menders.
Hmmmm... maybe "measurerers"? :)
I tend to think of A/B testing as a form of continuous improvement and I think it varies by project. If you have something that's bold and exploratory, that's likely to excite a maker, but if you've nailed down the concept and now you're in the refining phase of testing, a mender might enjoy that more. It's really subjective and depends a lot on context.
Nice article.
I use similar division. product vs technology orientation. Product is what you would call maker, and technology is more similar to mender.
It is the type of task that gives the specific dev the opportunity to display her or his skills. Some tasks like 'build a new tool in only 2 days' will probably take out the product guy out, and leave the technology guy in.
While the task 'stabilize the system' will take the technology guy out, and leave the product guy hidden.
As many devs are in the spectrum, we need both. Only a few devs would be happy to fix defects in the same area for 2 years. I would also think that writing projects that are never used can't be good for a dev.
I try to combine between the two. Yes, there are defects to fix, but you can also write a new feature (especially in a new area).
I'm definitely a Mender, 100%. I often find it frustrating and difficult to convey the value of my work to others, particularly in interview situations, as so many of them seem to be focussed on your ability to come up with new ideas and build personal projects from scratch. It can be difficult to demonstrate (without breaking corporate confidentiality) how you have refactored and improved upon existing products.
If you haven't listened to this Freakonomics podcast yet, I have a hunch that you'll love it. :) freakonomics.com/podcast/in-praise...
Me too! I would much rather refactor and tweak something until it's working really well than having a blank page and a deadline.
I don't know how to add this kind of work to a portfolio either so am using my posts here to convey my experience.
Nice article! I think I fall into the makers half, never thought of a programmer from this perspective!
Mender, myself. Doesn't feel like it at times when refactoring affects foundational components of the application.
It's great to add words to help de-find oneself. By de-find i mean identify with categories you feel close to. I'm a maker who enjoys when making is done and it's about time i become a mender :) I believe staying in either category is not a good idea...
For me it depends what I'm doing. When it comes to UI work, I'm far more of a mender. I prefer to take something existing and modify it to suit what is needed. That includes creating whole new sections of it.
I love creating things from scratch when it comes to just hacking around with node stuff though, be it backend stuff or even completely decoupled from websites. I have a habit of coming up with way too many projects!
That was such a nice read. 100% maker here.
I think I am more of a mender, but I'm unsure. Maybe 60% mender 40% maker?
I love refactoring old code and making it beautiful and performant. I definitely enjoy the challenge of figuring out reasons for weird bugs no one understands, and I would definitely say that I'm the tortoise with bursts of speed.
But, on the other end, I like toying with new stuff, learning new languages and approaches. I bore quite easily, so I don't like to be stuck with the same project and technology for a very long time.
What I really suck at is getting to an MVP, I'm unable to rapidly go from zero to a working application because I lose a lot of time trying to find the best technology/configuration/approach. That's why I see myself more as a mender.
About micromanagement: it happened to me once to have someone give me single tasks without giving me the whole picture. I spent more time waiting for the next task than actually doing work, and not being in control of the quality of the overall project was quite frustrating!
This is such a great distinction. I'm a maker, hands down. Fixing broken things drives me insane, I'd rather make something new. Excellent article!