In development, we all can agree that the user is most important. And what do users love? Features.

It’s reasonable to assume that each of your users will want a new and unique feature at least a few times per year. Product owners guessing at what these features could be can cause backlogs to fill up, and it seems as if no matter how many developers you add to a project, the work just never ends. Any product owner can empathize about paying overtime to get the work done. So to keep each user happy and keep the budget in check, every effort should be spent on making developer time productive to get those features out the door as soon as possible. On this we all can agree.

So my modest proposal is to maximize development time on features. Every day spent on work other than feature development is a day wasted. Refactoring code, writing unit tests, and mucking about with a Git branching strategy are distractions. Think about it: Will the user ever know if you used Gitflow or trunk-based development? No.

Who hasn’t seen the mindless droves of code monkeys milling about the coffee machine talking about the difference between continuous delivery and continuous deployment? These are precious moments where code is not being written, features not being developed, and new buttons on a web page for users to click not showing up on their screens. What a waste. This time is much better spent with hands-on-keyboard work. Communication with other team members should be curtailed, if not eliminated. Code reviews, meetings, team lunches, and arthritis appointments could better spent making the site’s logo just a little bit bigger, as per the CEO’s request.

An ideal developer’s day looks like this: they show up to the office, walk immediately to their desk, sit down, and start typing code at 150 wpm. At noon, they go into a pitch black room to relieve their eye strain and to scarf down a wholesome Soylent Drink (now available in Strawberry), and then go back to work immediately after. After writing code for eight intensely focused hours, they grab their backpack and scooter out the door. And if you managed to hire a 10x developer, they will stay late because that’s how more features are created!

If you hire 10x developers, expect 10x output in code. That’s basic math.

Simplifying development is one way to help make that happen. Starting with a strict rule of “no frameworks” is a good start. Tell any web developer “There’s a new JavaScript framework I want you to use,” and I guarantee they’ll roll their eyes. They get it! JavaScript frameworks are a waste of time. If the developers use anything but HTML, CSS, and vanilla JavaScript to create a web app, it becomes overwhelmingly confusing. Time spent learning and understanding some silly new here-today gone-tomorrow framework could be time spent on building a font kerning customizer for the customer, for example.

And when it comes to the process, if it ain’t broke don’t fix it. While DevOps is primarily about tools, it is also about culture and process. Some ideas around DevOps are really encouraging, like maintaining a backlog that puts highly-requested features above bugs. However, other ideas are less ideal. For example, some DevOps proponents suggest forcing software developers and operations to work dangerously close to one another. Distance between these groups is healthy, because of the separation of concerns: one group writes code, another downloads RAM onto servers.

Another idea put out by some radical DevOpsists is centered around monitoring. The energy creating, maintaining, and understanding a monitoring tool could be spent on features. One thing proponents often forget is that if a user calls to report an issue they are running into, it’s a perfect opportunity for them to ask if they liked the last feature that was deployed and if they can think of any new features they might want.

This is why I love Minimum Viable Products. The idea is to create a fully-featured product that keeps monitoring, continuous integration, automated tests, code reviews, discussions about security and new technology, and coffee breaks to a minimum. The Minimum amount of time spent on those things while creating a Viable Product is how success happens. Users don’t pay for security, they pay for features. Once users see all the features when they are delivered all at once in a new product, that’s when they start faxing those fat checks.

Overall, don’t let the needy developers get to you. They aren’t the users. They aren’t in sales and they definitely didn’t get an MBA or have to endure that corporate retreat, so they might not have an idea about the types of pressures you are facing. Don’t focus on improving the process, don’t focus on learning or education, or getting new laptops. They’ve been using the ones they already have for years, so clearly they work well. Let them do their thing, you do your thing, and most of all: keep making those features.