Live data from Hacker News

The worst programmer I know

dannorth.net

101–110 of 668 posts

Re: The worst programmer I know

#101

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 ass…

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.

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.

Re: The worst programmer I know

#102
So basically he just had the wrong title? Sounds like a great engineering manager or lead (in a company where that involves less code writing) or something. But his title is an IC role. But if he's spending all day pairing and not writing code then yeah - that manager seems to be correct, that's not his job? Why isn't he taking on any stories?

Re: The worst programmer I know

#103
post #92

Earlier quoted context omitted.

The saddest thing is that some bosses want throwaway code. I had a short stint once in a company where the owner wanted the web service rewritten from scratch every 6 months so they could use the newest web framework and follow the current fashion. He would hire a 5000 LoC per week hero on the spot.

Tangential but I was doing a web app for a client and gave a time estimate, which accounted for doing things properly (i.e. learning a frontend framework first). He asked "can you do it faster" and I agreed, thinking I'll make a throwaway version first and fix it later. Needless to say the project was a disaster, rapidly became unmaintainable. That's how I learned my job isn't to do what the client asks, it's to make…

[deleted]

Re: The worst programmer I know

#104
I worked at a company for a couple years where you had to produce 10 points a week or you got pipped. Didn't matter if you were a jr or sr. I worked on a few teams there and you could immediately tell how the teams measured points by the stress level of the developers.

Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week.

Teams that gamed the system and understood the impossible task they were assigned always gave the highest points total to a ticket they could or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers.

In an environment like that playing by the rules is a suckers game.

When I eventually quit, every sr engineer at the company; 7 total, followed me within 4 months.

Re: The worst programmer I know

#105
post #92

Earlier quoted context omitted.

The saddest thing is that some bosses want throwaway code. I had a short stint once in a company where the owner wanted the web service rewritten from scratch every 6 months so they could use the newest web framework and follow the current fashion. He would hire a 5000 LoC per week hero on the spot.

Tangential but I was doing a web app for a client and gave a time estimate, which accounted for doing things properly (i.e. learning a frontend framework first). He asked "can you do it faster" and I agreed, thinking I'll make a throwaway version first and fix it later. Needless to say the project was a disaster, rapidly became unmaintainable. That's how I learned my job isn't to do what the client asks, it's to make…

> That's how I learned my job isn't to do what the client asks, it's to make sure their project succeeds even if it means making them (temporarily) unhappy.

And I learned that doing it my way will get me fired because the manager has asked to do faster.

The way I have learned to get around this is by making the manager publicly document the request to go faster. If they don't document, I don't see or act on it. Once they document it, I happily go faster and let it all crash and burn. Then when they inevitably try to blame me, I point at the public documentation of the request to go faster and let the blame fall on the person responsible.

Re: The worst programmer I know

#106

Earlier quoted context omitted.

Because it's a bogus argument. The productive person doesn't need a paper weight at lunch to act as a shower thought generator. Management can get it wrong sometimes, but in broad strokes, they're right.

Define "productive". Because lins of code churned out is not and has never been a good measure of productivity. That "shower thought generator" might very well be more productive than the person they're sitting next to churning out tens of thousands of lines of unmaintainable code if their shower thoughts are causing people to find better ways to solve a problem. Which is basically the entire point of the article.

It's more about measuring outcomes. We have a goal, did we meet the goal. There are many paths to the goal, so measuring things like lines of code is incorrect. But so is measuring Bob's ability to ask Alice a good question. Management can't, at scale, consider such factors. We don't have the counterfactual where Bob didn't ask the questions, and Alice did great anyways. Performance reviews would become even more subjective if we had to place a value on the impact of asking questions. All forms of measurement are flawed, so I stick with outcomes.

Re: The worst programmer I know

#107
post #68

Earlier quoted context omitted.

I sometimes use my job title as a higher level senior or lead to say vulnerable things like: "This change is hard for me to read and understand" or "This is a large PR, and it may be difficult for me to schedule time to review it. Can it be split up into a series?" I also configure linters and code quality tools to automatically flag some of the more egregious problems.

I can relate though I wish I could get into a position that I could say such things and not get fired. In some circles "This change is hard to me to read and understand" would be interpreted as "I'm an aging dinosaur who doesn't understand this new tech; you youngsters are too clever for me." (though I realize how completely wrong it is). I'm 33 but I feel like I already have to make an effort to avoid the dinosaur l…

I’m 10 years older, my experience has been that getting to ask stupid questions is one of the joys of age/seniority/security. Very often everyone else in the room has the same stupid question but you get to look like a stone cold genius because you were willing to risk looking silly.

Re: The worst programmer I know

#108
post #61

> He would not crowd them or railroad them, but let them take the time to learn whilst carefully crafting moments of insight and learning, often as Socratic questions, what ifs, how elses. I do not like people who do this. just tell me the answer. this is such a gigantic waste of everyone's time. you figured something out months/years ago, great for you. give it to me NOW, so I can get on with my day. if we BOTH run…

Quite simply, no.

You're not going to learn from being handed an answer on a silver platter.

You'll implement it, get on with your day, and not at all think about why the answer is what it is.

Re: The worst programmer I know

#109

Earlier quoted context omitted.

> Very senior dev: ... that should take about an hour. Red flag!

Why do you say red flag? It is an exaggeration, of course, nothing is purely 1 hour. Rather it is 1 hour work in flow state, which is about 2 pomodoros, which is about 6 bulletpoints, which is about 1/4 of a day’s programming effort. Just about right for a 1 point card by a senior who only sit down to code when they kinda exactly know what to write

[dead]

Re: The worst programmer I know

#110
post #13

[flagged]

"Didn't happen to me anecdotally so must be fake news" is not a compelling argument.

Also to say it couldn't happen at tech companies is pretty bold. There's nothing special about tech companies. They can hire incompetent managers just as well as other companies.

Post reply on HN