3 ms·

Discipline for its own sake is certainly wasteful. What grieves me is lack of inquisitive ness and communitcation. If we're not deepening our understanding of

Discipline for its own sake is certainly wasteful. What grieves me is lack of inquisitive ness and communitcation. If we're not deepening our understanding of how things work, and working together, then things get wobbly. True story: delimited text data ingest file. Guy wrote a C language file to hack the upper byte off the characters, and then write them back to disk. At a glance we think "C! This was a performance thing." Except laboriously writing each character after hacking it in twain and discarding the upper byte isn't a performance hack. It's a "didn't RTFM on the python open() command and try the encoding argument, so we did a C hack" move. Encoding="utf-16" worked great. I'd take a victory lap, except for every time I'm clever, there are two where I look an ass. Discipline may not scale, but teamwork and inquisitiveness paper over a multitude of shortcomings.

scottlamb 6y ago
I think it's also important to remember that these things we sometimes consider character traits can be quite situational: In the absence of deadlines or other external pressure, I sometimes write beautiful, uselessly incomplete code. With mild deadline pressure, I do all right. In a toxic, death march environment, I can see how teamwork and inquisitiveness might drain away and someone would write the terrible code you just described. (See also: fundamental attribution error. I wrote the bad code because of the death march. He wrote the bad code because he's intellectually lazy.)
- wccrawford 6y ago
  I've seen quite a few junior developers that either lack the "inquisitiveness" or that it's too weak to overcome even a self-imposed deadline. They get things "working" but don't take time to understand the system first. As senior developer, I have to go in and stop them repeatedly and make them rework it. Up until now, I've told them why it's wrong and that basically does all their thinking for them. Now I'm wondering if I need to drag that step out and make them come up with the solution instead. The problem I've been debating lately is how to instill that inquisitiveness in my junior and mid-level devs when they lack it. (I'd been saying they don't think holistically, but I think inquisitiveness is a good work for a trait that will lead to that.) I'm thinking maybe I change my code reviews to have some video chat time where I lead them through the problem instead of telling them.

scottlamb 6y ago

I think it's also important to remember that these things we sometimes consider character traits can be quite situational: In the absence of deadlines or other external pressure, I sometimes write beautiful, uselessly incomplete code. With mild deadline pressure, I do all right. In a toxic, death march environment, I can see how teamwork and inquisitiveness might drain away and someone would write the terrible code you just described. (See also: fundamental attribution error. I wrote the bad code because of the death march. He wrote the bad code because he's intellectually lazy.)

wccrawford 6y ago
I've seen quite a few junior developers that either lack the "inquisitiveness" or that it's too weak to overcome even a self-imposed deadline. They get things "working" but don't take time to understand the system first. As senior developer, I have to go in and stop them repeatedly and make them rework it. Up until now, I've told them why it's wrong and that basically does all their thinking for them. Now I'm wondering if I need to drag that step out and make them come up with the solution instead. The problem I've been debating lately is how to instill that inquisitiveness in my junior and mid-level devs when they lack it. (I'd been saying they don't think holistically, but I think inquisitiveness is a good work for a trait that will lead to that.) I'm thinking maybe I change my code reviews to have some video chat time where I lead them through the problem instead of telling them.