Live data from Hacker News

The worst programmer I know

dannorth.net

171–180 of 668 posts

Re: The worst programmer I know

#171

Earlier quoted context omitted.

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

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.

Re: The worst programmer I know

#172

Earlier quoted context omitted.

unions don't measure productivity. They group people based on credentials + experience, and treat everyone as interchangeable within those buckets.

That's not generally how it works in professional sports with player unions. Nor does it work that way in the film and television industries where there are unions representing writers, directors, actors, etc... The shape of the union is whatever the membership wants it to have.

Both of those examples have weaker unions that play less of a role. Also the poster above suggested that the union as opposed to the management could measure performance. That doesn't happen in sports or TV.

Re: The worst programmer I know

#173
Tim was the worst programmer. I'd be so bold as to say he wasn't a programmer at all. He was a mentor and a leader and should have been promoted rather than sacked to replace whatever taskmaster your team had at the time.

Re: The worst programmer I know

#174

Earlier quoted context omitted.

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

Talking about flow state and estimates? The red flag just gets bigger. You are asking me to show you that Santa is not real. A "very senior dev" will not be handing out "1 hour" estimates to a product team. An hour of what? Billable hours? Wall-clock time? It's just not the right framing. You will notice a good senior dev will be incredibly cautious about any commitment and not hand out "ego estimates" like one hour.…

That sounds nightmarish.

If I say 1 hour, I mean that I know exactly which knob needs to be twiddled, perhaps because I wrote it in the first place, and that there'll be a pull request ready for review an hour from now.

That's clearly not always possible. Sometimes it is. If I say that it is, then I can deliver it.

Re: The worst programmer I know

#175

Earlier quoted context omitted.

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.

It's not about incompatibility it's about safety. You drive with air bags or you don't, those two concepts are NOT about incompatibility. It doesn't even make sense.

If there are situations where you have no choice but to drive without airbags, those are holes in safety.

Essentially if you have to have runtime checks to prevent the program from full on crashing those are holes. Not everything is checkable with static checks but the way to go is to move as much of your code away from runtime checks as much as possible.

Re: The worst programmer I know

#177
post #123

Earlier quoted context omitted.

> You'll implement it, get on with your day, and not at all think about why the answer is what it is. this is an incorrect assumption. some people (like me) have an analytical mind. if I am given an answer, I will usually reverse it back to the question, so that I understand how it came about. or I will ask follow up questions until I have that understanding. all this method is doing is forcing multiple people to go…

Just because you're a special snowflake (you aren't, but keep believing it if it works for you) doesn't mean that the discovery process isn't the best approach for teaching most people things. Hearing or reading something is the lowest form of learning and generally results in the lowest retention. > thats just a huge waste of time. Instilling knowledge and discovery rather than rote completion of work based on other…

> Just because you're a special snowflake (you aren't, but keep believing it if it works for you)

Someone who makes a comment like this, isn't arguing in good faith, or even intelligently. So I will give this comment the respect it deserves: none.

Re: The worst programmer I know

#178
post #107

Earlier quoted context omitted.

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.

I guess maybe in 10 years I'll be working with 30 year olds who understand and value of that approach as I do today. My current reality is that I'm a 33 year old working with 20 year olds who think they're geniuses who are going to take over the world in 5 years; from that viewpoint, I'm essentially a failed engineer because I didn't build a Facebook, Uber or AirBnB even though I had 10 years to do it.

From seeing your posts, I think you have a psychologica lock that under mines your self-confidence.

Re: The worst programmer I know

#179

Earlier quoted context omitted.

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.

why? most code is not some complex algorithm where 100 lines of code can take years of genius work to figure out. Unit tests, for example, have near linear proportionality between LOC and utility. Same for comments, same for standard business logic.

I can whip out 100 lines of bullshit in a few seconds. I can just paste in whatever Copilot gives me and as long as it builds call it a day.

It will take me far longer to come up with the correct 100 lines that is both maintainable and can be worked on by others down the line.

I can pad my lines of code in seconds if I wanted to before pushing the changes. That padding provides no business value and might even introduce bugs.

And how do you handle refactoring? If I come in and refactor everyone else's shitty padding by combining helpers and optimizing code, I'll have negative lines of code. Am I an unproductive worker?

Sure, most code is not some complex algorithm but lines of code is a stupid metric that is not representative of the work done and can be gamed by anyone knowing what they're doing.

Re: The worst programmer I know

#180
post #38
post #25

Earlier quoted context omitted.

It might be from the great book The Idea Factory by Jon Gertner (p 135). 'In the midst of Shannon’s career, some lawyers in the patent department at Bell Labs decided to study whether there was an organizing principle that could explain why certain individuals at the Labs were more productive than others. They discerned only one common thread: Workers with the most patents often shared lunch or breakfast with a Bell…

The most impressive thing about this story is that they figured out the answer . They did the research, and nailed down that it was Nyquist who was was the productivity booster. It’s the exact opposite of the OP’s story, where management tried to fire the Nyquist-equivalent.

Honestly, I'm kind of skeptical of the answer. I'm not saying that talking with Nyquist wouldn't be useful, probably it was, but what's stopping a dozen other things at least that useful from being part of the answer?
Post reply on HN