What are some clever ways for a non-technical person to work with devs?

What kind of a thing is this?

Is there a reason you couldn't simply act as the user and test it out? Most QAs I have worked with have not been technical either.

Define your requirements as best as you can, based on examples you've seen in other websites/apps. Ask for the source code every so often.

Ask ChatGPT how it would go about making something with similar requirements, step by step, and then feed it back the source code you get from the dev and ask it if it's a reasonable way to approach that problem. It's probably going to do better than hiring another rando dev who you don't already know to be trustworthy. Tell it you're not technical and to explain what the code should do in a best practice situation and compare it with the source code you actually provided, explaining differences in layman's terms.

The best way is probably to ask them to show you that it’s working and explain how they know that’s the intended or correct behavior.

Another way would be to learn some technical details so you understand what they’re saying and doing instead of writing yourself off as non-technical.

A worse but doable way is to have someone with expertise check their work. That only makes sense if you don’t trust your developers which is a pretty bad situation.

Your question is weird because it’s sort of like asking “How do you know if a contractor is building a house properly when you don’t know anything about building houses?”

How do you make sure that a plumber or a construction worker or even a surgeon is going to do the right thing?

It usually helps if you look at the problem from a different perspective.

In a non-technical role, the definition of something being “done correctly” ends when the output/result matches the requirements. Whether that be a user experience, reporting, or whatever the requirements are. As long as those are clearly defined, and you can test the application against those definitions, the trust lies in the development team that it was programmed properly.

Any kind of testing should be defined at a high level. What is being tested and what is the expected result? What should trigger an alert?

Does it work as expected? Then they did it correctly. Did they do it fast enough to meet the business needs? Then they did it quickly enough. Do they keep delivering things that work, that are done fast enough for the business, and you don't they keep working? Then the quality is high enough.

Trust your people. If you spend all your energy trying to second-guess whether they are competent, they won't stick with you. And if they did not deserve that trust, it will show in their results quickly enough anyway.

I my experience, its something that starts with trust, a lot of times you would have trust what a dev is saying, but still asking questions, asking why an estimate on a task is what is being proposed, why would it take more effort, what are the alternative ways of doing it etc. Too much agreement on everything and complete lack of agreement are both signs of something not right. Healthy debates are good

If the quality of work isn't verifiable by performance indications you'd be best off having another developer review the code.

> What are some clever strategies or methodologies you've employed to verify a developer's honesty

Same as anybody else, just see if they can deliver on what they say.

More developers is better though, as you’ll be able to compare multiple perspectives, which can reveal dishonesty