alt Hacker News> Your job is to deliver code you have proven to work.
Strong disagree here, your job is to deliver solutions that help the business solve a problem. In _most_ cases that means delivering code that you should be able to confidently prove satisfies the requirements like the OP mentioned, but I think this is an important nitpick distinction I didn't understand until later on in my career.
Replies
> In _most_ cases that means delivering code that you should be able to confidently prove satisfies the requirements like the OP mentioned
That is an insane distinction that you are trying to do there. In which cases delivering code that doesn't satisfy the requirements would solve a business problem?
It's more than just solving a problem though, you should be solving the given problem without creating new problems. This is where the working/secure code aspect comes in.
Maybe I'm not late enough in my career to understand what you're saying, but what kind of problems are you helping the business solve with code that hasn't been proven to work?
> Strong disagree here, your job is to deliver solutions that help the business solve a problem.
Sure. That is every job though. It is interesting to muse on. Hard for us to solve a problem without a computer (or removing one!)
Man we better hope the solution to that problem is working code. Otherwise we better start working the fryers or something.
Didn’t know your code could satisfy requirements without working. /s
My priorities are as follows: 1) code works 2) code satisfies requirements
Not sure how anyone can prove their code satisfies requirements when it doesn’t run.
There's no distinction there, proving the work is correct is within the scope of helping the business solve a problem; not without and not beside it. So your point is hot air, making a distinction where none exists.