The source content for blog.juliobiason.me
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

34 lines
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 = ["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.
<!-- more -->
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") }}