TL;DR – this is not nearly good enough in most cases and it’s only small fraction of what you are paid for.
I want this post to be the canonical place to refer people to who say “but it works” because people who explain why this is not OK are tired of repeating the same arguments, me included.
You are paid for …
Following is not an exhaustive list but it should give you some perspective which is opposite from the narrow-minded “but it works”.
Typically, your Software Engineering $Job pays you for:
- Of course the thing must work. But also..
- It should continue working
- Gives deprecation warnings? Probably not good.
- Only runs on Node.js v10 LTS which is end of life in less than a year (as of writing)? Think again.
- Got away with invalid XML? Can you be sure that the next version of parser won’t be stricter?
- It should be maintainable (aka you and other people should find it easy to operate and modify, now and years later)
- Code quality
- Tests (if you don’t have tests, even your basic claim that something “works” is under suspicion)
- How to use your sh*t?
- How to set up the development environment?
- Non-obvious code parts
- It should be production ready, not abstract “works” or even worse “works on my machine”
- Tested in dev/qa/whatever-you-call it environment
- Reproducible – tomorrow they make a new environment, “qa42”, in a different AWS account in a different region. Could somebody else deploy your sh*t there without talking to you?
- Update 2020-09-13 (from Guy Egozy) – Scalable enough to be used in production.
If you claim that you are “done” because “it works”, congratulations, you have a (probably) working prototype. That’s typically small part of a project.
Related term – “Tactical Tornado”, look this up.
Update 2020-09-13: Reddit discussion