51–60 of 222 posts
> they stopped asking Bill to fill out the form which is only possible because he's so important. imagine doing this as a stack-ranked IC in an org like AWS. The old days of a software as an artisanal craft is long over imho.
Protection from retaliation and group negotiation on working conditions are brilliant for people who aren't as "important" as Bill.
Microsoft and IBM Lines of code clash >In the PBS TV series based on Bob Cringely's Accidental Empires, there is a sequence where Steve Ballmer describes the experience of co-developing OS/2 with IBM, how the whole thing became a fantastic clash of corporate culture, with Microsoft having the small-company attitude of getting things done, and IBM being focused on internal measures primarily KLoCs, that is thousands o…
For a bit of context, the TV series this refers to is called „Triumph of the Nerds” and it’s a great watch, even today (maybe ever more so?).
> they stopped asking Bill to fill out the form which is only possible because he's so important. imagine doing this as a stack-ranked IC in an org like AWS. The old days of a software as an artisanal craft is long over imho.
Earlier quoted context omitted.
Exactly! I've myself spent days investigating an issue only happening on a specific Android device (but used by an important client) only to find that the solution was something along the lines of using "opacity: 0.1" instead of 0. That bug was left unfixed for months but now it's solved. Should I have received a talk because of that? (Of course the commit would have had at least 10 LOC more, explaining the reasons a…
> Should I have received a talk because of that? Of course not. But, if your commit history for last 6 months is just one or two of those one-line changes a month, that might hint that there’s a problem.
Earlier quoted context omitted.
Sorry but your argument makes no sense. The 10LOC/day guy is not to be singled out from the 1000LOC/day people because 1000 LOC could be just as trivial; 1LOC could have taken hours to discover.
Right. One data point among many. And managers should be looking at everyone’s code, not just the low LOC ones. But there are people (I’ve seen this frequently) who constantly represent their work as having been “much more difficult than expected” but then you discover that they actually are struggling with what should be easy tasks, and looking at code (complexity and volume) is a data point. For me, more often than…
Cartoonish anecdotes like this take away from that actual value that LOC can provide to management, when employed judiciously as one data point among many. It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the c…
Every what?
Earlier quoted context omitted.
Exactly! I've myself spent days investigating an issue only happening on a specific Android device (but used by an important client) only to find that the solution was something along the lines of using "opacity: 0.1" instead of 0. That bug was left unfixed for months but now it's solved. Should I have received a talk because of that? (Of course the commit would have had at least 10 LOC more, explaining the reasons a…
> Should I have received a talk because of that? Of course not. But, if your commit history for last 6 months is just one or two of those one-line changes a month, that might hint that there’s a problem.
Gave myself RSI deleting On the plus side I replaced an O(n²) algorithm with a faster one in the very next commit. Needed to get rid of the ninety copies of the same bad idiom first.
Cartoonish anecdotes like this take away from that actual value that LOC can provide to management, when employed judiciously as one data point among many. It is very informative for managers to take a periodic look at the number/frequency of commits from each engineer and their size, and from there dive into each commit and explore the denseness of the code, the cyclomatic complexity, and the overall nature of the c…
There was a bug in an embedded system I worked on that several engineers, software as well as hardware, spent months troubleshooting. I eventually got called in and fixed it with a while loop and one function call inside of that loop. 4 lines in total, counting the brackets. A very trivial change if you didn’t know why it was there, what impact it had on the system or how much it would have continued to cost in engin…