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

[highwayman47]

What are some clever strategies or methodologies you've employed to verify a developer's honesty and quality of work when you lack deep technical understanding?

For example, if you have a developer doing something technical - how can you ensure it's done correctly?

I suppose you could have them do the work and then have a separate dev check the work (if resources allow)?

Interested in potential ideas - treat this more as a brainstorming activity where all responses don't need to be entirely practical.

[MattGaiser]

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.

[highwayman47]

What if it's sensitive data, and just want to make sure it's secure - not necessarily saying the dev is malicious, but maybe need a 2nd pair of eyes on security, etc.

[solardev]

Then you shouldn't trust the dev or a random second pair of eyes either, but probably get an independent security audit from a professional cybersec auditor, and even then, have insurance and a plan in mind for when leaks/hacks occur (they will, once you're big enough scale).

Security is something that even professional devs get wrong all the time and why the industry has vulnerability disclosure processes (https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability...), listings (https://cve.mitre.org/), and entire groups that try to find them before the blackhats do (https://googleprojectzero.blogspot.com/)

If you just want "good enough" security for a side project or whatever, then using standard libs & algorithms (NOT inventing your own) is usually a good bet. As a layperson you probably can't evaluate the security knowledge of a developer. Most developers can't even evaluate that of other devs. Security is a specific specialty that most devs only know the very basics of (if even that).

[solardev]

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.

[exaldb]

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?”

[tucaz]

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.

[interbased]

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?

[codingdave]

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.

[EchoStar27]

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

[noashavit]

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

[gitgud]

> 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