Ask HN: What is the ideal developer experience in 2020?

* Node.js on backend, using a thin db layer (not an orm) like sequelize. My newer projects also use TypeScript on back end and share models with front end with a lerna setup

* React.js with TypeScript (default create-react-app setup) on frontend; multiple smaller apps for each business unit/functional area; some limited sharing of UI components between these apps (turns out not that much needs to be shared really)

* Everything in a mono repo and edited in VS.Code

* Deploy by building apps, gzipping backend and frontend into one tarball, then either:

- Ask my "release person" to copy it into the Windows server drive for test or production

- Run my own "release script" that scp's it to my Digital Ocean droplet and tells pm2 to restart the production application

My projects email me when something crashes in the back end and I run sentry.io to see what's gone wrong in the front end.

Why I find this to be a great developer experience:

* Simplicity. One language, easy to share things like e.g. validation between FE and BE, minimal cognitive burden when context switching; small apps = simple code; simple release system means I can get new features or bug fixes to users extremely fast with minimal fuss

* No CI pipelines or DevOps time sinks: this is effective because I'm a single developer; I also work on projects where a solid CI pipeline and infra as code adds value, but these things can also slow you down too

=====

In other words, what I feel makes me effective is using a modern language and ecosystem, but deploy it with methods from 10-15 years ago. :)

- The project should start up with one click or one command. It's fine if I need to configure credentials or something similar, but beyond that, your project should be so easy to start that your mom could do it. If the project requires me to locally install a database, configure ports, or anything of the like, that's a shining red flag that things are very wrong.

- The underlying architecture and rationale should be documented and this document should be reasonably up to date. Whoever is the lead developer on the project should be responsible for this. Not all details need to be covered, but the main principles and the driving business requirements behind it need to be clearly stated and up to date. If there's no broad documentation, I consider the project to already be off the rails, not just heading that way.

- There should be a concept of testing. You don't need to have tests yet, especially if you're still prototyping, but you need to have a very clear idea of what you will test, how, and how you'll get there.

- Formatting isn't a discussion point. Whatever stylistic preferences there are are covered by linting and automatic formatting. If I clone the project, it should be reasonably hard for me to do things the wrong way and fairly easy to do them the right way.

- Branch management, code review, etc. All of this falls in the same pot for me, no one should have the ability to push directly to master, all changes need to go through review, pass lint, tests, etc before they can be merged. Doesn't matter if you're the lead dev or a summer intern.

You'll notice that all of the above are procedural issues, not code specific issues. I firmly believe that by nailing the underlying process first, you make it easy to build good software and hard to build bad software.