Comment by 3pt14159
2 years ago
Well, I like the story here, but it's kinda against a bit of a strawman. Don't get me wrong, I'm not losing the overall point of the piece, a point I agree with, but that said a metrics focussed manager could have simply added an "adjunct" label to the stories and had this "worst programmer" add themselves to stories as the non-lead developer.
Ultimately the best way of measuring programmer productivity is by the assessments of the programmers on the team. This isn't as easy as it seems. For example, I once worked on a team where the best Heroku guy just had the absolute wrong idea about "easily understandable python code" since he would prefer to raise and catch an exception instead of rely on a built-in to test attribute existence or type compatibility. But nobody could get around large scale Heroku deployments like this guy. The juniors understand this nuance less well than seniors do, but even so, it does sorta come out in the wash. Your team does know its best people and they're usually happy to say it in a private one on one.
<Ultimately the best way of measuring programmer productivity is by the assessments of the programmers on the team. >
Maybe ... Productivity itself is difficult to define. Different people will value aspects of the work differently
At one Internet Advertising company I worked for, the founder had written most of the original code. Written in the late 1990s, it was Perl, JavaScript, HTML, and SQL jumbled together. Completely ignoring the notion of 'separation of concerns'. Huge amount of code duplication. Source code control? Phhht! Nary a test in sight. Ran programs as root to work around permission problems. Self modifying code ... you betcha. He worked right on the production servers. He could and would push out a feature the same day a customer asked for it. VERY quick to make the customers happy. The company was being bought out at the time I came on board. Pocketed his millions, headed down the road, yay for him.
My own take is that the company would never have 'made it', if a software team had been hired to 'do it properly'.
After his departure, as we rewrote our code base to 'professional' standards, much time was spent refactoring that produced few or no new features. How productive was that? A very complex question.
As a digression, I sometimes found his original code easier to maintain that the stuff done 'the right way' because there WAS no 'separation of concerns'. I didn't have to hunt in a different part of the source tree for where something was done. It was all 'right there'. YMMV.
In the end, 'productivity' is way more subjective that we'd like.
> I didn't have to hunt in a different part of the source tree for where something was done. It was all 'right there'. YMMV.
This is my take too as I have gained experience. The way I did code from the get go, was the overall best way. Long function that did the stuff one thing at a time. Like no functions called from different parts of the call tree. I breeze to debug and understand or modify.
Until it’s not. Nobody wants to read your 100,000 line file called main that only has one function. As with everything, moderation.
1 reply →
I believe that’s the conventional approach in Python, though? It is a duck-typing language, try-except is a legitimate way of seen if an operator works on an object, and objects should do sensible things with operators.
The funny example is that the hasattr built-in just tries to getattr, and then catches the exception to tell if it has the attribute.
I agree. In Python terms "Easier to Ask for Forgiveness than Permission" (EAFP) is preferred over "Look Before You Leap" (LBYL).
https://docs.python.org/3/glossary.html#term-EAFP comments:
> Easier to ask for forgiveness than permission. This common Python coding style assumes the existence of valid keys or attributes and catches exceptions if the assumption proves false. This clean and fast style is characterized by the presence of many try and except statements. The technique contrasts with the LBYL style common to many other languages such as C.
and there are any number of essays on the topic, like (random DDG search) https://programmingduck.com/articles/lbyl-eafp .
Exceptions are for exceptional circumstances. An object being a certain type is not an exceptional circumstance, not even in a dynamic language. You should never be surprised by the type of an object unless your program has serious design flaws.
The fact that the language doesn't have your back means you need to be more careful about types, not less. The type of the arguments is a function precondition. It's the callee's responsibility to document preconditions and ideally recover cleanly from a violation, but the caller's responsibility to ensure preconditions are met. Illegal states should be caught early, not allowed to percolate until an exception is thrown.
I don't much care if what I just wrote is "Pythonic" or not. I don't think too much careful design up front is responsible for every Python codebase I've ever seen reading like Finnegan's Wake.
You aren’t required to like the conventional way they do things in Python.
I dunno. I don’t love Python for big projects either. If we want to go around and tell all the people using this very popular language to stop shipping their successful products because they look messy to us, I’ll happily take the second shift (after you), haha.
If you are calling something immediately, a try-except is ok. If you are calling with a try-except just to simulate hasattr or getattr then why do we have the built-ins in the first place?
“Just try and then handle the exception” is a pretty weird paradigm for this sort of thing, to those of us who come from more typical languages. So I suspect they just included hasattr to make us more comfortable.
Conventions are changing. Modern python is shifting to type checking with external type checkers.
The two are not incompatible. I'll type all class properties and functions, but still use try/except on dict access or function calls.
3 replies →
So I used to kind of think like you, but I think that's just not a practical approach. Yes, you could alter the system in this 1 exact situation if you know exactly what to change, but there will be dozens of other failure modes too (engineer releases code that breaks in 2 months, engineer deliberately mis-estimates story points, engineer doesn't comment their code so that nobody else on team can do certain work, etc)
So if you have a manager who is a dialed-in coder who's going to keep updating the jira-point formula based on spending more than 1 hour a day reading code, and keep tuning it around the ever-more creative loopholes engineers employ, then yes, you may end up with a workable system. But never yet in my long career have I seen that.
No, no, you misunderstand. I agree with the point. I just think it was made against a strawman and could have been made even stronger. I'm not for metrics on stories to award productivity points. I'm for one-on-ones and success-as-a-team evaluations.
> a metrics focussed manager could have simply added an "adjunct" label to the stories and had this "worst programmer" add themselves to stories as the non-lead developer.
The story includes a part where they dropped the crappy metric and changed to a better one.