Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Worst Programmer I Know (2023)

dannorth.net

Post reply on HN
Print view View original

361–370 of 385 posts

Re: The Worst Programmer I Know (2023)

#361

Post by psychoslave »

LandR wrote: post #292
lodovic wrote: post #282

Earlier quoted context omitted.

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.

I've experienced this watching a coworker debugging that sort of code, he had initially written it all as a long chained statements, then had to undo it all to allow him to debug. Once it was extracted it could be debugged and step through it, great! Once he was done debugging it he put it all back to how it was originally... The mind boggles.

Looks like a limited debugger unable to let inspect what's happening in each chained function. Or is that something else?

I mean, it looks like the same level as adding explicit temporary variable because the debugger won't give provide values of the different part of an expression assigned to a third variable. That's a way to circumvent the tool limitation, just as you can add a tap or map in a middle of a chain if the debugger is too rudimentary to provide more conveniency.

Re: The Worst Programmer I Know (2023)

#362

Post by psychoslave »

rightbyte wrote: post #288
lodovic wrote: post #282

Earlier quoted context omitted.

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.

Single use long functions are great for debuggability and following the code path. Injection or whatever fancy term used for passing function pointers around is ofent write only.

If the function is long, accumulate variable along the way, and open intertwined control flow every three lines, no a single function is not at all a scalable way to expose a construction involving many transformations and sources and debugging will be as hard as the control follow depth times number of stacked variable so far as it's stepped through.

With method chaining at each step you have only the complexity of the current method inputs to deal with: that's a far better noise/signal ratio.

Re: The Worst Programmer I Know (2023)

#363

Post by milesrout »

saagarjha wrote: post #298
milesrout wrote: post #297

Earlier quoted context omitted.

You mean what if Alice is intolerant? Bob would have to be pretty egregious to make it so Alice cannot work effectively, and that is when HR gets involved. But if Bob is just not the easiest to work with, then it is up to Alice and Bob to work together. You can't expect everyone else to always adjust to what you want.

No, I don't mean that. You assume that this is a logical conclusion but the problem is that "Bob would have to be pretty egregious to make it so Alice cannot work effectively" is not actually true. Bob, being the slightly better coder, could make Alice's life miserable without, like, doing a harassment that HR would be interested in. Constantly changing APIs that Alice relies on ("they're better now, why are you comp…

And if Bob doesn't get to do that he will leave. If Bob has to put up with low quality code because Alice can't get the basics right but he also isn't allowed to point out basic mistakes in code review, he will leave.

There is no such thing as being "overly nitpicky in reviews". This sentiment reminds me of an old coworker of mine that would basically throw a tantrum when I asked him not to add new lines to a file, which was indented consistently with tabs, with spaces. He needed to be reminded of this every commit. This is the sort of crap that distracts from the substantive code review, yes. But the solution is not to do what Alice wants and ignore minor details. It is for Alice to get the basics right the first time so that Bob can focus on more substantive things.

This isn't just true in software development either. In law, the first thing a new graduate joining the profession is told is that whatever you do, the work you produce should be spelt correctly and your grammar should be right. The formatting should be consistent too. Why? Because inconsistency and error in those aspects is distracting to someone reviewing the substance of the work, and the basics are so easy to get right.

To put it concisely: if you got the basics right the first time, which you should, then you wouldn't get nitpicky comments.

There are obviously many ways that people might be less productive in combination than the sum of their individual productivities, but in my experience some unfortunate people make no effort to adjust the way they work so that they combine well with others, and some people blend in very naturally with others' working styles. Some people are worth having even if they're difficult. Some people are only worth having if they play nicely. Either be a star or play nicely. Mediocre performers that are also difficult to work with don't ever last very long.

Re: The Worst Programmer I Know (2023)

#364

Post by saagarjha »

milesrout wrote: post #363
saagarjha wrote: post #298

Earlier quoted context omitted.

No, I don't mean that. You assume that this is a logical conclusion but the problem is that "Bob would have to be pretty egregious to make it so Alice cannot work effectively" is not actually true. Bob, being the slightly better coder, could make Alice's life miserable without, like, doing a harassment that HR would be interested in. Constantly changing APIs that Alice relies on ("they're better now, why are you comp…

And if Bob doesn't get to do that he will leave. If Bob has to put up with low quality code because Alice can't get the basics right but he also isn't allowed to point out basic mistakes in code review, he will leave. There is no such thing as being "overly nitpicky in reviews". This sentiment reminds me of an old coworker of mine that would basically throw a tantrum when I asked him not to add new lines to a file, w…

> And if Bob doesn't get to do that he will leave.

Maybe he should.

> If Bob has to put up with low quality code because Alice can't get the basics right but he also isn't allowed to point out basic mistakes in code review, he will leave.

There's a difference between nitpicks and "gets basic things wrong" or "doesn't format their code". Remember that Alice is 0.9 of Bob: she's not there fighting with him on formatting (everyone has CI do this anyway, lol) or getting basic things wrong. She's getting comments like "hmm, this API you use could be a bit better, could you also refactor that while you're at it?" or "can you make this more general to support this use case that we don't actually need right now, but could potentially need later?" I guarantee you, regardless of how smart you are, there are a multitude of ways I could tie up your review for a long time. And this happens all the time in projects with very smart people working on it.

Re: The Worst Programmer I Know (2023)

#365

Post by saagarjha »

WalterBright wrote: post #349
saagarjha wrote: post #295

Earlier quoted context omitted.

> At work, I am not really interested in how smart they are or how easy to work with they are, or how nice a person they are. At work I'm interested in results. I've had workers come to me and complain about "Bob" who has annoying habits and an abrasive personality. I defend the ones that produce results. And what if "Bob" makes it so that "Alice" who is almost as smart as him can't work effectively?

That's why being a manager is not a trivial job. Amusing story: one day, I got a call from "Bob" who complained that our receptionist "Alice" refused to forward his phone messages to him. Apparently, this was because "Alice" didn't like "Bob". What was this, high school? So "Alice" was informed that she was taking messages for the company, and "Bob" needed those messages to perform his job. She got the message.

Sounds like Alice was the one who was difficult to work with in this case?

Re: The Worst Programmer I Know (2023)

#366

Post by Grimblewald »

morsecodist wrote: post #94

The idea of measuring individual developer productivity is kind of absurd to me. I'm not saying that what we do is magic, there are just so many variables. Measuring story points or lines of code is kind of the opposite of productivity. This encourages developers to do as much meaningless work as possible. I'd want a developer to make a task simpler or use an existing tool which means less time writing code. The valu…

but also, the reason we come together to work as groups is so that we can achieve more than we would as the sum of the parts. The same is true for horses, two horses that work well together put out more power than two individual horses. So the problem becomes when you identify one of your horses has 1.5x the output of the other, and think firing the weaker horse will lead to minimal productivity gains, you end up with egg on your face when you realise you are not left with a horse that works 1.5x, but rather a horse now working at 0.5x what what it was in a team. The exact same thing is true for team work, team sports, etc. There is no one person 'holding it all together' if there is, then that person needs way better support and realistically, should get the entire departments pay when the remaining department is let go.

Re: The Worst Programmer I Know (2023)

#367

Post by musicale »

gowld wrote: post #358
musicale wrote: post #178

Earlier quoted context omitted.

Unix-nature loves malicious argument and code injection vulnerabilities, while C brings its own set of issues such as buffer overflows.

Are you referring to bash when you say Unix-nature? Bash and C are both old and flawed early implementations that brought great ideas. Bash can be replaced by a much safer language that retains its shell nature (easily able to weave together many Unix programs).

I was replying to GP.

You could certainly replace bash and traditional Unix shells with something else. My favorite attempt is scsh (though mainly for the "acknowledgements" section of its reference manual.)

But I'm in favor of a Unix/Linux command shell and scripting language that has type and taint checking for command arguments, and which differentiates between code and data. Typed data pipes could be nice as well.

However, Unix/Linux isn't (yet) designed for those features. For example exec() doesn't type check command arguments.

Re: The Worst Programmer I Know (2023)

#368

Post by vraylle »

WalterBright wrote: post #225
morsecodist wrote: post #94

The idea of measuring individual developer productivity is kind of absurd to me. I'm not saying that what we do is magic, there are just so many variables. Measuring story points or lines of code is kind of the opposite of productivity. This encourages developers to do as much meaningless work as possible. I'd want a developer to make a task simpler or use an existing tool which means less time writing code. The valu…

Everyone on a programming team knows who the good and not-so-good programmers are.

This is the key. Ask all the developers for a ranked top-3 list of who they would most prefer to go to for help with a programming problem. Put that data together and you know who your best are.

Before the inevitable protest: I believe the ability and willingness to communicate with other developers is a vital skill in this business.

Re: The Worst Programmer I Know (2023)

#369

Post by milesrout »

rpmisms wrote: post #339
milesrout wrote: post #296

Earlier quoted context omitted.

That isn't dangerous, just ignorant.

It's not ignorant, it's a different perspective on priorities that is outside your orthodoxy.

It is ignorant of history, law, politics and logic. Companies do not exist for that purpose. It isn't why they arose as a concept. It isn't why they are created today. It isn't why the law of companies exists today. It just has nothing to do with reality.

If you said that businesses should exist for the benefit of their staff as much as for the benefit of their proprietors it might make some sense as an opinion. But you said that companies (a specific type of legal structure) do in fact exist for the benefit of their employees (a specific class of contractual relationship), which is simply false.

If you want to make statements about how you think the world ought to be, then be my guest. If you want to lie about the state that the world is actually in, then you should be relieved when someone interprets your lie as mere ignorance.

Re: The Worst Programmer I Know (2023)

#370

Post by sour-taste »

neverokay wrote: post #330
hadlock wrote: post #287

Earlier quoted context omitted.

What are you asking

I’m not asking you if you read carefully. This is not to be mean, I asked the GP specifically because they demonstrated that they understand the spirit of what I am talking about. Your own confusion is stemming from something else, not my question (you don’t even recognize my question, as evidenced). For example, who raised you? See, that’s a question you might not understand but it’s the spirit of my original questi…

I still have absolutely no idea
Post reply on HN