Redefining—and making a case for—resumé-driven development
May 22, 2021
Every once in a while I hear a pejorative term in the tech world that I think could be reframed to be constructive. One such term is Resumé-Driven Development (RDD).
According to rdd.io, the values of RDD are:
- Specific technologies over working solutions
- Hiring buzzwords over proven track records
- Creative job titles over technical experience
- Reacting to trends over more pragmatic options
Don’t get me wrong—these things are pretty universally bad. But these points also represent the most cynical reasons people make decisions that look good on a resumé.
Who, exactly, is reviewing this resumé?
The aforementioned list of values on rdd.io is only impressive to the wrong kinds of people. In other words, if you join a company that’s only impressed by the shiniest, newest tech, you’re going to have a bad time.
My argument for reframing RDD is that the things that look good on a resumé to the kinds of people you should want to impress are generally good for both you and your company/product.
What if we reframed RDD to mean something like:
“What kind of tech choices represent industry best practice, benefit the product, and would attract high quality resumés when we’re hiring?”
All of a sudden, you’re making tech choices that look good on a resumé to the right kind of people, you’re likely directly improving the quality of your product by using best practices, and you’re indirectly improving the quality of your product by improving the quality of your engineering team.
Furthermore, when you interview with quality teams and managers, you’ll be able to explain why you made the choices you did: you improved performance, or quality, or developer experience.
So—go forth and make your resumé look great in the eyes of teams and managers you respect and with whom you would someday like to work.
If you'd like to support this blog by buying me a coffee I'd really appreciate it!
Nick Scialli is a senior UI engineer at the Microsoft.