Comment by OnionBlender
1 month ago
I had a director that was obsessed with github enterprise stats. He forbid people from squashing commits and told people to commit every day, even if you're in the middle of something. This was so that he could see who was writing the most code.
One of our interns was close to the end of his term and this director wanted to hire him. He thought the intern was amazing based on the amount of code he wrote. The problem was that this intern was bad, so we had him write unit tests. However, he was also bad at writing unit tests. He would run the code and then write tests that enforced the current results, instead of considering that the current behaviour might be incorrect. Thankfully we didn't hire him after myself and others explained why the intern had so many commits and lines of code written.
Reminds me of an old joke about a policeman who pulls over a poor driver. The driver complain "But I haven't been in a single accident", the reply from the policeman, "Yes, but you've caused dozens".
Some people are just oblivious to the trail of destruction left in their wake.
“Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future. Typically, other engineers must clean up the messes left behind by the tactical tornado, which makes it appear that those engineers (who are the real heroes) are making slower progress than the tactical tornado.” ― John Ousterhout, A Philosophy of Software Design
Have had multiple roles running behind these guys cleaning up their messes. If I’m now ever in a position to just let them flail around (not always possible as these guys are often leads) I try to do so, if they are abusive about it, I’ll just quit. this is a major cause of burnout.
In other words, the "10x programmer".
4 replies →
Reminds me of a manager and a QA I once knew. QA was a nice guy, but a terrible QA. Would fail stories on the most arbitrary guidelines. Story is about changing the font size on the home page? He'd fail it because he wasn't able to log in (he tested while the auth service was undergoing planned maintenance).
Manager loved this guy, and pushed him through several promotions. Eventually other employees got tired of being skipped for promotions and left the company, creating a minor staffing crisis
We kinda have this, but… At least we have a dedicated QA team. That spends their whole day literally just confirming that the shit we write is up to spec. We spend a lot of time resolving discrepancies between implementation, spec and test, but when things roll out the other end, they work.
yeah a good qa team is peace of mind.
I think just about everybody has had to deal with one or several of these guys.
> Story is about changing the font size on the home page? He'd fail it because he wasn't able to log in (he tested while the auth service was undergoing planned maintenance).
Average offshore QA team.
1 reply →
Much as cancer arises and grows from natural cellular processes gone awry, this seems to be an organizational cancer, present in any company of a large enough size.
Then the other employees found that this is how the world works: don't promote people that deliver results or you may have to replace them.
Well, I seen a fair share of "blind" programmers who just did their (very limited) scope, perhaps they did it well... yet the whole tool just didnt work and nobody cared.
I imagine that if the guy pointed out things like this - he wasnt popular with the developmemt team, but popular with management and users.
people get promoted based upon their ability to conform to management culture, and their ability to deliver outcomes; in most places the former is far more important than the latter but not always
the former is often easier to measure than the latter, and the latter is often only measurable when superficial.
> who was writing the most code
There's yer problem right there. Code quantity is not correlated with value. In fact, it can be negatively correlated with value if it's buggy and laden with technical debt. Measuring productivity by lines of code produced actively discourages writing clean, maintainable, bug-free code.
I’m getting a similar sense from many of the AI “success” stories we’ve been hearing. There’s amazement about how many lines of code the AI produces in a short amount of time.
But not so much about maintaining and debugging all those lines of code once they’re created.
But the code runs great, over a hundred transactions per minute! All on just a $750 a day AWS instance! Saved so much money on those expensive developers! /s
Math left as an exercise for the reader.
1 reply →
Turning a 100+ lines function of 5+ intertwined control flow mess into a single expression using a combination of method chaining of just a few lines is always a delighting experience to my mind.
Until a coworker needs to debug a specific edge case that was too specific for the single expression, and it all has to be rewritten back to long form. Dense code is not always better and sometimes makes a code base incomprehensable.
6 replies →
> Code quantity is not correlated with value. In fact, it can be negatively correlated with value if it's buggy and laden with technical debt.
** "No Code" or Nihilist Software Engineering **
No code runs faster than no code.
No code has fewer bugs than no code.
No code uses less memory than no code.
No code is easier to understand than no code.
No code is the best way to have secure and reliable applications. Write nothing; deploy nowhere.
One of my most productive days was throwing away 1,000 lines of code. -- Ken Thompson
The cheapest, fastest, and most reliable components are those that aren’t there. -- Gordon Bell
Deleted code is debugged code. -- Jeff Sickel
Measuring programming progress by lines of code is like measuring aircraft building progress by weight. -- Bill Gates
* Master Foo and the Ten Thousand Lines *
Master Foo once said to a visiting programmer: “There is more Unix-nature in one line of shell script than there is in ten thousand lines of C.”
The programmer, who was very proud of his mastery of C, said: “How can this be? C is the language in which the very kernel of Unix is implemented!”
Master Foo replied: “That is so. Nevertheless, there is more Unix-nature in one line of shell script than there is in ten thousand lines of C.”
The programmer grew distressed. “But through the C language we experience the enlightenment of the Patriarch Ritchie! We become as one with the operating system and the machine, reaping matchless performance!”
Master Foo replied: “All that you say is true. But there is still more Unix-nature in one line of shell script than there is in ten thousand lines of C.”
The programmer scoffed at Master Foo and rose to depart. But Master Foo nodded to his student Nubi, who wrote a line of shell script on a nearby whiteboard, and said: “Master programmer, consider this pipeline. Implemented in pure C, would it not span ten thousand lines?”
The programmer muttered through his beard, contemplating what Nubi had written. Finally he agreed that it was so.
“And how many hours would you require to implement and debug that C program?” asked Nubi.
“Many,” admitted the visiting programmer. “But only a fool would spend the time to do that when so many more worthy tasks await him.”
“And who better understands the Unix-nature?” Master Foo asked. “Is it he who writes the ten thousand lines, or he who, perceiving the emptiness of the task, gains merit by not coding?”
Upon hearing this, the programmer was enlightened.
Source: http://www.catb.org/~esr/writings/unix-koans/ten-thousand.ht...
The author of the shell script was probably Doug McIlroy. See www.leancrew.com/all-this/2011/12/more-shell-less-egg/ for more.
Unix-nature loves malicious argument and code injection vulnerabilities, while C brings its own set of issues such as buffer overflows.
2 replies →
This is an amazing collection. Thanks for it.
It's is exactly what I was needing for this slide deck on I'm writing how to improve our code.
1 reply →
code is liability for both the business and the thinker at the end of the day. It's worth it to spend as much time as possible figuring out how to avoid writing it and keep it minimalized.
https://yosefk.com/blog/engineers-vs-managers-economics-vs-b...
> ...It's a common story and an interesting angle, but the "best vs good enough" formulation misses something. It sounds as if there's a road towards "the best" – towards the 100%. Engineers want to keep going until they actually reach 100%. And managers force them to quit at 70%:
> > There comes a time in the life of every project where the right thing to do is shoot the engineers and ship the fucker.
> However, frequently the road towards "the best" looks completely different from the road to "the good enough" from the very beginning. The different goals of engineers and managers make their thinking work in different directions. A simple example will illustrate this difference.
> Suppose there's a bunch of computers where people can run stuff. Some system is needed to decide who runs what, when and where. What to do?
> * An engineer will want to keep as many computers occupied at every moment as possible – otherwise they're wasted.
> * A manager will want to give each team as few computers as absolutely necessary – otherwise they're wasted.
> These directions aren't just opposite – "as many as possible" vs "as few as necessary". They focus on different things. The engineer imagines idle machines longing for work, and he wants to feed them with tasks. The manager thinks of irate users longing for machines, and he wants to feed them with enough machines to be quiet. Their definitions of "success" are barely related, as are their definitions of "waste".
> The "good enough" is not 70% of "the best" – it's not even in the same direction. In fact, it's more like -20%: once the "good enough" solution is deployed, the road towards "the best" gets harder. You restrict access to machines, and you get people used to the ssh session interface, which "the best" solution will not provide.
Probably not the point but committing every day is one methodology for TBD and it’s great for generating productivity. Not so much useful for measuring productivity though.
I can’t imagine how miserable it would be to try to measure dev productivity by quantifying commits on a daily basis. What a waste.
TBD = trunk-based development
This story tracks pretty closely with the Dilbert cartoon in the article. Except unintentionally.
> The problem was that this intern was bad, so we had him write unit tests.
Please tell me you assigned this person a "increase code coverage" task and not "I wrote a new feature, write the unit tests for it" task
Yes, it was an "increase code coverage" task. The same director wanted 100% code coverage so I had the intern write tests for existing code that didn't have many tests.