Fidelity is up and obedience is down!

Naval Officer Disobedience

Fidelity is up and obedience is down on my bayonet buckle, Sir/Ma’am.

When asked "What's Up?", this is the required answer that a Plebe must memorize (among many others) on day 1 of their training at the United States Naval Academy. The lesson associated with this quote is that true loyalty and faithfulness (fidelity) come before blind compliance (obedience). The Naval Academy ironically, ingrained well meant disobedience into the military discipline associated with following orders and executing them. Officers are required to reject unethical orders and cannot use "I was just following orders" as a shield. As a developer, this is a critical skill that you must also onboard, but in a slightly different context.

Engineering Disobedience

A quote that is very similar to the belt buckle quote comes from Elon Musk.

First, make your requirements less dumb. Your requirements are definitely dumb… It's particularly dangerous if a smart person gave you the requirements because you might not question them enough. (link)

The man who built one of the most successful engineering companies in the history of the world follows a very similar principle. Do not blindly accept what is put in front of you. Elon believes that you should question things often.

The Price of Obedience

A user story aka ticket is kind of like a military order. You can either orchestrate the work as stated and close the ticket, or you can go outside the box, understand it deeply, and be willing to disobey if you have the guts to do what seems like the more correct thing to do.

Closing a ticket exactly as written, acceptance criteria met and nothing more, adds little value. You won't understand the problems as much, you strip your agency away, and ultimately, you become a commodity. It puts you, who is 100 million more intelligent, into direct competition with an LLM. Instead of obedience, think about fidelity.

Your team needs you to think about your software's end users, understand their pain, and question the "orders" assigned to you when it is appropriate. Fidelity is asking what the ticket was actually for, and then building that. You should never offer blind compliance to an instruction handed to you. Sometimes doing your job means you have to question things and know that the people writing instructions make mistakes. Your team and leadership need you to question it.

Do you think a submarine captain gets mad if an ensign defies a standing order to make sure the sub doesn't collide with another vessel?

The Developer Fidelity Flow

As a developer, this is a simple flow to make sure you can be disobedient when you it counts. You can apply this for user interface work or backend work alike. Modify this flow as it makes sense.

1. Ensure It’s Not Dumb
Look outward before you build. Go use three products that solve a similar problem. Click through the example products, not just their screenshots. What do all three do the same way? See if there is a convention that could be followed to save extra effort down the road. What did they leave off the first screen? It's just going to have long to have long-term negative complications?

Nobody will put this step in the ticket and don't rely on the LLM to give you "best practices".

2. Self-Roast
Critique it yourself hard.
Does it make sense? Where do your eyes go first, and is that where they should go? Is the one main action obvious in two seconds? Read every label out loud. If a label needs a sentence underneath to explain it, the label is wrong.

Most important: Does this look like an LLM made it? Are you shipping the generic, default patterns the robot would give you? People can tell.

3. Robot Roast
Hand it to an LLM and be blunt. Say: “Here is a product on the market. Its UI is terrible. If I were to make my own version, what are three things that could make it better?”

Then force it to review from three different perspectives. For example:

• View this as a regular user, manager, sysadmin (or worker, admin, power user, whatever fits the product)

The harsh framing plus multiple personas gets sharper, more useful feedback than a generic “how can I improve this.” Give it real context or you’ll just get advice about contrast ratios.

4. New Robot, New Roast
Take it to a different LLM. After iterating with one LLM, you’ve usually converged on a shared idea of the screen, which means you now share its blind spots. A second model was never in that room. It will be able to give you unbiased advice with without any of the prior knowledge. This is a very rare case were a lack of context could be good.

Why This Matters To You

Getting software to work used to be the achievement. AI ended that. When you can go from an empty folder to a working product in an afternoon, working is the floor, and nobody congratulates you for the floor. What replaced it is harder: it has to feel remarkable. Almost nobody can tell you in advance what that means. Users will not open a ticket that says "this feels cheap." They will just quietly think less of the thing you built.

AI will not close that gap for you. It produces work that functions and is unremarkable or worse, gives users a poor experience. If you don't pick up and find those problems on your own, your team and customers will. They'll notice ai slop or generic user interfaces and they might think to themselves "This isn't good," but they won't say it. And eventually, over time, that will erode the product and the entire team. Many companies are ruined because of this. Developers who don't disobey, add little value to their organization or worse, burn capital producing mediocre results.

Summary

Your future in development is not in producing working code. It is in building remarkable experiences. To do that, you must keep your fidelity up and your obedience down.

Written by Periscoped. We build software that people actually like using.