1.6 KiB
+++ title = "Things I Learnt The Hard Way - Don't Tell It's Done When It's Not" date = 2019-07-18
[taxonomies] tags = ["en-au", "books", "things i learnt", "personal", "responsibility"] +++
You are tired of running the same thing over and over again. You kinda remember that something weird may happen, but because you're tired, you tell everyone that "It's finished". Don't.
I must admit that I've done this. Yes, there is that corner case that I didn't test. Yes, there is that piece of code that, although it works, it's weird. Yes, I left a technical debt behind. But we get tired of looking at the same thing over and over. And we get pushed by higher ups to deliver stuff. And that's when we say "It's done", when it's not.
Although we just dodged one, we end up leaving our colleagues -- people that really depend on our work -- down. They expect to connect to whatever we are doing to keep going. The expect to see the results of their work crystallized by ours. And they can't. 'Cause we said "It's done" when it wasn't.
And you can be sure, as soon as that happens, they will be the first to point, in minutes, that it is not done.
On the other hand, if you say "Almost, but there is this thing that bothers me and I think it may give us a headache in the future", they will understand. So be clear and transparent about your work.
{{ chapters(prev_chapter_link="/books/things-i-learnt/responsible-code", prev_chapter_title="Take Responsibility For The Use Of Your Code", next_chapter_link="/books/things-i-learnt/people-care", next_chapter_title="People Get Upset About Code And Architecture Quality 'Cause They Care") }}