Ask HN: Are my expectations on code quality and professionalism too high?

One of the very most frustrating things for an exec is downtime. The next worst is inaccurate time estimates for IT work. If you don't have at least some experienced architects/developers, it's normal to find yourself in the position where nobody knows what they don't know, and that's a bad look for everyone involved. It's also why a lot of bigco's have been outsourcing internal appdev to MSPs over the last 10+ years. It de-risks projects, eliminates skilled labor shortages, and ensures reasonable QoS... in theory. It doesn't always work out that way, but that's the objective.

This is the normal. I think I have never be in a project with the "proper" stuff from the start.

I have applied what I can, not even asking (because the answer will be "no?"), so the fact that:

> All agree to do these things..

You are set! that is the key!. Now, how do this successfully?

Pick only 1 thing to solve (like I say, almost daily, to Stakeholder of the projects "One problem(or miracle!) at time").

The first is "use source control" OR "use a task manager/bug tracker".

For a project with more non-developers, the second will be MORE useful.

The key is use the most simple thing you can get. I use pivotal, ignore it for all the SCRUM stuff, and only use it to list the task to be done, task doing and done, and train everyone with this ONLY rule "Put what is more important from top to bottom".

That is literary, the only process that I use with others. With non-developers, I not even try to expect them to label correctly bugs vs features, and most of time I rewrite the task myself (for clarity).

But man, people, specially non devs, love to see the progress of the project! This relieve so much presure is insane.

So the key:

* Pick only 1 thing to improve at time

* Use the more simple tool/process possible

For example, use git, only 2 branches (master, dev)

* Accept some imperfect inputs from people that are not skilled in the trade

"My users will never reporte correctly a bug, so I rewrite the reports after talk to them"

And for others "the devs never put a good message in commit", then

* Pick only 1 thing to improve at time

if are in the phase of "at least using git!" not sweat it. Maybe gently remming them

And probably:

* Have a mega list of good things to do in the task manager, and cross milestones with the team. Celebrate when done!

Your standards and expectations are reasonable, but sometimes push comes to shove. You're describing a lot of intentionality of the seniors and management. Ask. Communicate. Share your concerns. Accepting the vast distance between the ideal and the reality is part of engineering. Bridging the gap is the other part.

I sympathize with your frustration, but no ideal place exists. My old team tried their hardest to get to the state you're describing for two years and got there. It was beautiful.

If it's a real small startup (If it's bigger than that, then you've got a problem and you should start looking elsewhere or attempt to change the company from within (hard to do unless you're in leadership).

Otherwise, here's my personal rules for "running scrappy":

- Pushing to master & prod w/o review is fine if it's truly an emergency or something super tiny, i.e. a whitespace change. Otherwise, it's good to get in the habit of putting up a PR, even for posterity.

- Connecting to prod dbs - never do this unless it's something you have to fix right now. Otherwise, just grab a copy, a backup, or connect to an idle follower instance if you need prod data (v ez to setup).

- Bad code is fine. You have to pick & choose your battles. Ideally care about stuff that's around building a mental model of your application rather than quibbling around refactoring some small function

- Similar note about testing... you can get away without it in a bunch of cases, especially if the app is easy to QA locally

- Deployments.... just use Heroku :-)

- It's good to spend at least a little time architecting/designing, but seriously time-box it and run with what you've got

- Staging environment.... you won't have a good one for a long time :-)