2 ms·
I sympathize with this, but taking two days to add two lines of code is unproductive. Sorry, that's just not a lot of output. Two-day bugs happen, but they shou
by bananaface 6y ago
I sympathize with this, but taking two days to add two lines of code is unproductive. Sorry, that's just not a lot of output. Two-day bugs happen, but they should be rare. The real question is: is this rare, or is it typical for this developer?
IMO the real problem is trying to evaluate an employee's productivity on the scale of two days. There isn't enough context to understand the situation.
- Cthulhu_ 6y agoYou CANNOT make any statements about whether or not a code change is productive / unproductive if you do not know the context. It doesn't work like that. Take any random commit on https://github.com/torvalds/linux/commits/master; https://github.com/torvalds/linux/commits/master; most change just a handful of lines but I can guarantee that each of them represents a significant time investment in analyzing, documenting, discussing and testing the code change in question. I mean I get where you're coming from, if your job is basic data wrangling (webapp -> rest API -> back-end -> database and vice-versa) then you don't need to put too much thought into it and just need the output. But that's only one part of software development.
- bananaface 6y agoI don't think we disagree. One line per day can be a reasonable rate of change. But usually it isn't. Usually that's too slow, and it's indicative of an unproductive developer. Everyone in the thread is defending the OP because the issue is relatable. "He's productive, his manager doesn't understand!" Ok, maybe. But also maybe his productivity is way below what he's being paid for. We don't know, we don't have enough context to judge.