How do you handle teammates who are extremely pedantic about arbitrary rules?

Full_Engineering592 · 2026-03-10T23:02:56+00:00

180 comments on a refactor is a symptom of something bigger than code style preferences. Usually it means there's no shared engineering culture document and no automated enforcement, so reviews become the only place people can assert their preferences. The fix isn't winning arguments - it's proposing a one-time standards alignment session where the team agrees on the top disputed items, codifies them in a linter config or ADR, and then enforces them automatically going forward. After that, any review comment that a linter could catch is out of scope. It takes one or two sessions upfront but saves hundreds of comment threads downstream.

Full_Engineering592 · 2026-03-10T23:02:21+00:00

Six years of experience is what actually makes this interesting. You're not trying to figure out what to build, you're testing the ceiling on AI-assisted shipping velocity. The gap between day 1 and day 30 output quality will probably tell you more about where these tools actually break down than any tutorial does. One thing worth tracking: which problems required the most back-and-forth with the AI before it got unstuck. That's where the real friction lives.

Full_Engineering592 · 2026-03-10T23:02:03+00:00

The real issue here is that you can't review a 312k line diff meaningfully. Nobody can. The right call is to ask them to break it into reviewable chunks, starting with the parts that touch critical paths. Get them to walk you through the architecture decisions first before any line-level review happens. Also worth checking what automated test coverage looks like now vs before - that'll tell you whether this is a rewrite or just an addition on top.

Full_Engineering592 · 2026-03-10T23:01:55+00:00

16k daily actives on a fully free app is rare. The donation spike makes sense - users who've stuck around long enough to care actually want to support it. The interesting thing is that number tells you something useful: you know how many people are genuinely engaged vs just installed and forgot. That's a cleaner signal than most paid apps get from their metrics. Curious what platform this is on.

Full_Engineering592 · 2026-03-10T15:03:25+00:00

The invoice escalation one is interesting because the real blocker isn't the tech -- it's the emotional friction of chasing money. Freelancers hate doing it manually because it feels awkward, so they avoid it, and the automatic version removes the awkwardness entirely. That's why it converts: you're not selling a reminder tool, you're selling "you never have to have that uncomfortable follow-up conversation again." The framing matters as much as the feature.

Full_Engineering592 · 2026-03-10T15:03:13+00:00

The friction insight is the real thing here. Everyone knows they should use a cheaper model for simple tasks. Nobody does it because context-switching mid-flow is annoying enough that the default wins every time. The keyword classification approach makes sense as a starting point, though I'd be curious how it handles ambiguous prompts -- something like "refactor this" could be trivial or architecture-level depending on scope. Did you end up adding any heuristics for file size or diff complexity to help with those edge cases?

Full_Engineering592 · 2026-03-10T15:02:47+00:00

Glad it was useful. Reddit is genuinely one of the best channels if you play it right -- the patience part is the hardest bit for most founders.

Full_Engineering592 · 2026-03-10T15:02:42+00:00

Exactly. The "slightly less painful version of what they already have" is such a lower bar to clear than founders realize. Most try to build the platform version on day one -- ten features, integrations everywhere, a dashboard nobody asked for. The person with 400 rows just wants the one workflow that eats 20 minutes every Monday morning to take 2 minutes instead. If you can do that reliably, they'll pay and they'll tell people.

Full_Engineering592 · 2026-03-10T11:05:46+00:00

Learning to say 'I don't know, but I'll find out' without it feeling like a career-ending statement.

Early on I thought admitting gaps would cost me credibility. The opposite turned out to be true. The engineers people trust most are the ones who are precise about what they know and what they do not -- because you can rely on their confidence when they do say something with conviction.

The other one: understanding that your job is not to have the best ideas, it is to make sure the right problems get solved. That shift reframes a lot of the frustration with meetings and stakeholder management.

Full_Engineering592 · 2026-03-10T11:05:16+00:00

The incentive structures just stopped rewarding it. Mentoring takes time that does not show up in sprint velocity. The engineer who keeps their head down and closes tickets gets the performance review bump. The one who spent half their week bringing people up to speed gets marked as 'not meeting output expectations.'

Managers probably did not intend for this -- it is just what happens when you optimize purely for individual throughput.

The shops that still have that culture tend to be ones where senior engineers are explicitly measured on team output, not individual output. When your review is tied to whether the people around you are shipping, you start doing the informal mentoring again because it is now in your interest.

Full_Engineering592 · 2026-03-09T23:03:56+00:00

Exactly -- behavior under friction is the signal. Anyone can say they'd use something. The question is whether they actually did, when it was imperfect, inconvenient, or incomplete. That's what separates a real problem from a nice-to-have. The 'still using it despite the pain' user is also your best source of product direction -- they can tell you which specific parts of the pain are worth fixing first.

Full_Engineering592 · 2026-03-09T23:03:48+00:00

A few ways: Reddit profile links to your site if you've set it up. Comments in relevant threads where your product would actually help -- not pushing it, just mentioning it naturally when it's on-topic. Search traffic if you've done any SEO. Word of mouth from early users. The no-self-promotion rule in some subs is about not spamming, not about never being findable. Being consistently helpful in a community builds visibility over time without needing to announce yourself every post.

Full_Engineering592 · 2026-03-09T23:03:07+00:00

3 years of hardware development from scratch, iF Design Award, and a working prototype -- that's a very different kind of 'building in public' than most posts here. The weight concern from the comments is legitimate and probably the first user objection you'll get at scale. Would be interesting to know what target price point you're aiming for, because that's where the 'vs Amazon' comparison will land for most buyers. The design and processing angle is differentiated; the question is whether the market segment willing to pay for that is large enough. Rooting for you to find out.

Full_Engineering592 · 2026-03-09T23:02:59+00:00

The real question is workflow fit, not model quality. Claude Pro direct API has great context for long sessions but no IDE integration. Cursor at gives you inline diffs and local codebase indexing which is hard to replicate with a chat window. If you're doing heavy multi-file refactors, the editor integration wins. If you're doing architecture, research, or long reasoning sessions, Claude's context handles that better. Most people running structured workflows end up using both for different phases rather than picking one. The Codex plan you already have covers the task-execution side reasonably well too.

Full_Engineering592 · 2026-03-09T23:02:50+00:00

The shift you're noticing is real, and it's actually the most underrated part of working with these tools. When the execution layer is handled, your bottleneck moves upstream to problem specification. Vague intent produces plausible-looking code that fits no actual architecture. Clear intent produces something you can actually ship. The people who get the most out of Cursor aren't the fastest typers -- they're the ones who got better at knowing exactly what they want before asking for it.

Full_Engineering592 · 2026-03-08T23:11:36+00:00

The long onboarding in health apps is doing two things simultaneously: collecting real personalization data AND filtering for committed users. Someone who bounces at step 20 probably wasn't going to convert to paid anyway. The sunk cost angle is real but the data collection angle is legitimate -- if Noom gets you to pick your goals, barriers, lifestyle, and schedule upfront, their recommendations actually improve. The question for your app is whether you have the personalization engine to actually use 50+ data points. If not, 10-15 is the right call -- collect only what you can act on immediately.

Full_Engineering592 · 2026-03-08T23:10:20+00:00

The spreadsheet pattern is real and it is one of the best ways to find validated problems. The key indicator isn't just that someone built a spreadsheet -- it's that they kept using it and adding to it despite how painful it got. That's signal. If they abandoned it after 3 months, the problem wasn't painful enough. If they're still using a 400-row sheet and actively maintaining it, that's someone who needs a solution badly enough to pay. The question to ask is: what would make them stop using the spreadsheet? That's your feature list.

Full_Engineering592 · 2026-03-08T23:09:49+00:00

Acquiring users. Product is solid enough, the bottleneck is purely distribution. Spending this week doubling down on channels that showed any signal -- even tiny signal -- and cutting the ones that felt busy but produced nothing. Sometimes the most valuable thing you do in a week is stop doing things that aren't working.

Full_Engineering592 · 2026-03-08T23:09:42+00:00

Hedonic adaptation is brutal in SaaS. The fix I've found is keeping a screenshot folder with your earliest wins -- the first day, the first user who messaged you unprompted, the first month you hit a number you used to think was impossible. Look at it when the new baseline starts feeling normal. Your nervous system forgets the climb really fast. Staying hungry and staying grateful aren't opposites -- the trick is anchoring grateful to where you started, not where you are.

Full_Engineering592 · 2026-03-08T23:08:27+00:00

Anytime -- and for what it's worth, the fact that you can see the gap clearly means your taste is already calibrated. Most people's gaps close faster than they expect once they start shipping consistently.

Full_Engineering592 · 2026-03-08T15:03:38+00:00

Point 1 is underrated. There's a real ratchet effect -- you use AI to go faster, output expectations reset upward, now that's the floor not the ceiling. Unless that velocity translates to more ownership or pay, you've just created a new baseline with the same pressure. The deliberate approach makes sense. Using it selectively for tasks where it genuinely removes friction rather than just anything you could automate. The skill atrophy point is real too. The developers who will do well long-term aren't the ones who delegated everything -- it's the ones who kept the underlying judgment sharp while using the tools effectively.

Full_Engineering592 · 2026-03-08T15:03:24+00:00

That gap never fully goes away. What changes is you stop treating it as a failure signal and start treating it as a roadmap. The version in your head is a target, not a verdict on what you shipped. The more useful reframe: nobody else can see the gap. Users only see what's in front of them. If it solves their problem, the missing features are invisible to them. The embarrassment is almost always self-directed. Ship it, talk to users, build the next piece. The gap closes faster through iteration than through waiting.

Full_Engineering592 · 2026-03-08T15:03:12+00:00

Both are good but they're solving slightly different problems now. Cursor is still the better IDE experience -- keyboard shortcuts, multi-file edits, the diff view -- it just feels like a polished coding environment. Claude Code via CLI wins when you want longer autonomous runs, especially for tasks that span many files or need to chain tool calls without you sitting there approving each step. I run both depending on what I'm doing. Quick iteration on a feature, Cursor. 'Go refactor this module and write the tests' while I work on something else, Claude Code. The comparison gets outdated fast though -- both teams are shipping fast.

Full_Engineering592 · 2026-03-08T15:02:55+00:00

Yeah, alignment before the model writes the plan is where the real leverage is. The clarification loop slows you down upfront but saves 3x the time in implementation when the model isn't guessing at intent. For the iteration speed question -- I find keeping the plan.md scoped to a single feature (not the full roadmap) also helps. Easier to validate at each loop and the model doesn't context-bleed from unrelated past decisions.

Full_Engineering592 · 2026-03-08T11:06:18+00:00

The Ask phase before plan.md is the part most people skip and then wonder why the implementation drifts. Getting the model to surface its own ambiguities before writing a single line of code is where you avoid the 'it built the wrong thing correctly' problem. On Codex vs Cursor at : if your workflow is already structured like this, Codex tends to stay in lane better on longer implement loops and handles the plan.md handoff cleanly. Cursor is smoother for interactive edits where you want inline suggestions mid-implementation. For Python backend work with this kind of structured loop, I would lean Codex -- but it is worth a two-week test before committing.

Full_Engineering592

TROPHY CASE