← back to list

After 4 years and 6 developers, here's how I finally learned to spot the bad ones ( not promoting )

★★ signal-medium   r/entrepreneur  ·  ↑ 119  ·  💬 35  ·  2026-01-14  ·  kw: too much time  ·  open on reddit ↗
your rating:
Tool
GitHub
Issue
Non-technical founders cannot assess developer quality until months of cash burn occurs; bad developers hide behind jargon, batch commits weekly, claim 'almost done' indefinitely, and say yes to every request without pushback, causing 4-year hiring cycle to burn through 4 of 6 developers before identifying performance patterns.
Cost
unstated
Recommendation
Weekly working demos; require commit frequency monitoring; demand specific status updates instead of 'almost done'; hire developers who push back on requirements; assess communication clarity in interviews; none of these are tool-based recommendations
extracted with
anthropic/claude-haiku-4.5 · 2026-05-08

Body

I've hired 6 devs over the past 4 years. Two were great while the others cost me a lot of money before i figured out they weren't working out. The problem? I couldn't tell who was good until months of cash had already burned. here is what i wish i knew earlier: **Too much jargon is a red flag.** Good developers explain their work simply. "I added the password reset button. Now users get an email when they click it." While bad developers hide behind complexity. "I refactored the auth middleware to handle session state." If your dev leaves you more confused at the end of the conversation, that's not because you're dumb. It's because they're either hiding something or they don't truly understand what they built **Commit frequency matters even if you can't read code.** Go to your repo on GitHub. You don't need to understand the code. Just look at the patterns. If you see multiple commits per week with clear messages like "feat: added user profile page" then that's good, while one giant commit every 10 days labeled "updates" or "fixes" is bad . Keep this as a rule of thumb: Small frequent commits = good habits. One giant weekly commit = poor planning or last-minute cramming. **"Almost done" is almost always a lie.** If your dev always answers to your queries about what happened with : "almost done". they're either stuck and won't admit it, or they're actually not working. Good devs give specifics: "password reset is done. email templates will be done in Thursday. Then I'll use two days to test." **The best developers push back on your ideas.** This always keep surprising me. The devs who keep saying yes to every request are actually the worst. They weren't thinking, just billing The best developer I ever hired regularly told me my ideas were wrong. "That feature would take 6 weeks. What if we did this simpler version instead?" That's what you want. You don't want a mindless machine, but someone that will help you and correct you if you're wrong. **Weekly demos reveal everything.** Stop accepting status updates. Ask your dev every Friday for a working demo of what he is working on. Even if it is still unfinished. Good developers love showing their work, but the bad ones always have an excuse for why they can't demo yet. By the time your gut tells you something is wrong. You've already lost months. What i found the most helpful is getting visibility earlier not until it's obvious What signals do you look for when evaluating developers? Curious what's worked for others here.

Top comments (7)

[score=1] AutoModerator
Welcome to /r/Entrepreneur and thank you for the post, /u/MedAgui! Please make sure you read our [community rules](https://www.reddit.com/r/Entrepreneur/about/rules/) before participating here. As a quick refresher: * Promotion of products and services is not allowed here. This includes dropping URLs, asking users to DM you, check your profile, job-seeking, and investor-seeking. *Unsanctioned promotion of any kind will lead to a permanent ban for all of your accounts.* * AI and GPT-generated posts and comments are unprofessional, and will be treated as spam, including a permanent ban for that account. * If you have free offerings, please comment in our weekly Thursday stickied thread. * If you need feedback, please comment in our weekly Friday stickied thread. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/Entrepreneur) if you have any questions or concerns.*
[score=32] Azaptive
Having a team that push back on you is SO underrated. Heavy agree dude.
[score=34] mpanase
software engineer with decades of experience here sound advice non-technical people: print OP's post, frame it and hang it on your office
[score=5] innate_pointer
This is solid advice, especially the part about pushback. My best devs have been the ones who tell me "that's gonna be a nightmare to maintain" or suggest simpler alternatives that I didn't think of The commit frequency thing is huge too - learned that one the hard way with a contractor who would disappear for weeks then dump a massive "finished everything" commit that barely worked
[score=9] Starlyns
Nice catch but Most owners just want yes people. Give your input or a better idea? Now they personally dont like you
[score=6] Select-Young-5992
\>Good developers explain their work simply. "I added the password reset button. Now users get an email when they click it." While bad developers hide behind complexity. "I refactored the auth middleware to handle session state." This one really depends on who you're talking to...A PM? 100% agree. But if I was a dev working on the same codebase, "I refactored the auth middleware to handle session state...so users can get email when click it" is way better.
[score=3] [deleted]
**Too much jargon is a red flag.** This is highly contextual. It could be a red flag. It could also be a developer being micromanaged by someone without basic technical skills. **Commit frequency matters even if you can't read code.** This is a good sign for a new hire in an already healthy company, but plenty of work exists outside of git for many broken companies. Infrastructure and databases can be an auditable blackhole unless you're already mature with infrastructure-as-code and automated db migrations. **"Almost done" is almost always a lie.** Juniors suck at estimating and seniors are often forced into estimates they don't agree with. If I estimate 5 weeks but I'm given 3 weeks then I push back until I give up and that turns into "almost done." Getting honest and calibrated estimates as a team is very difficult even if you remove the pressures. **The best developers push back on your ideas.** Yes. **Weekly demos reveal everything.** This is highly contextual and audience dependent. If you're building a new form, then sure.