Live data from Hacker News

The worst programmer I know

dannorth.net

531–540 of 668 posts

Re: The worst programmer I know

#531

> I explained all this to the manager and invited him to come by and observe us working from time to time. Whenever he popped by, he would see Tim sitting with someone different, working on “their” thing, and you could be sure that the quality of that thing would be significantly better, and the time to value significantly lower—yes, you can have better and faster and cheaper, it just takes discipline—than when Tim w…

Extensive pair programming can also be massively draining and burnout inducing for certain types of people. I hate it when companies mandate pairing. Some people's brains just don't work effectively in that type of environment.

Mandating it is stupid, it obviously depends on the team, task and person.

But you can't deny that it's an amazing tool to open silos in terms of knowledge. I wish people would be more open to it, because I've never been able to get someone up to speed faster with a tool or codebase, than with pair programming. And vice versa too. If you're the person that knows less about the topic, pair programming with a senior is like a one on one tutoring session with a really skilled instructor. It's worth the time in gold imo.

Re: The worst programmer I know

#532
"measuring developer productivity is that you can quickly identify the bad programmers"

The author has obviously never tried to build anything non-derivative in a team. This metric only identifies the noisiest inexperienced programmers, that go through other peoples work... like a monkey on crack throws its poo. These folks are often successful in business, because anyone that actually grasps real workmanship is already busy. The main problem is meritocracy eventually fails, as someone biased must choose what constitutes "good" work. Thus, a pseudo-Technocrat just follows foolish idealism with extra steps... and becomes a Marketer in time.

The truth is "all software is terrible, but some of it is useful..." depending on the end use-case.

Happy computing, =)

Re: The worst programmer I know

#533
post #526

Some 20 years ago, I worked at a moderately large software company that sold a desktop application for Mac and Windows. The team had mostly Mac experience and they were just getting their feet wet with Windows. So naturally the Windows version had some problems. At the time, I was known as a "Windows expert", so they hired me to help improve that version and help the team get more familiar with Windows programming. I…

PSA... check out this guy's LinkedIn profile. It's a great read.

Thank you! You gave me an excuse to look at my own LinkedIn profile, which I've ignored for a few years.

I have a distinct memory from not that long ago when I was unemployed and asking people for advice on what to put on LinkedIn and on my resume.

One consistent piece of advice was "Don't list anything more than five years ago. People will think you're old!"

I thought, "Screw that, everyone already knows I'm old."

So I decided to just tell my story, all the way back to the beginning in the days of punch cards and Teletypes.

I am grateful that you appreciated that.

Re: The worst programmer I know

#534

Earlier quoted context omitted.

It's, what, two clicks to duplicate a ticket, and another to assign one to other person? Sure a "this person paired" button would be easier, but sometimes you just gotta do jira chores.

Then the status has to be tracked in two places. It’s certainly not impossible, but as a programmer I’m allergic to unnecessary busywork.

Then get rid of the "points" and maybe the "tickets" too.

Re: The worst programmer I know

#535

Earlier quoted context omitted.

He doesn’t have his own achievements? I have heard of the Nyquist frequency, the nyquist limit, the nyquist sampling rate and the Shannon nyquist theorem. As far as I know no other individual has had this many “things” named after him.

https://en.wikipedia.org/wiki/List_of_things_named_after_Joh... Note that the "Known for" section on his main page has 119 elements. But they're not all named after him.

Also

https://en.wikipedia.org/wiki/List_of_things_named_after_Leo...

Re: The worst programmer I know

#536

Reminds me of an anecdote about Bell Labs. Someone calculated who the most productive employees were (based on things like patents received), and found that many of them would eat lunch with the same person. That person wasn't individually very productive, but he would always ask thoughtful, compelling questions that in turn made his coworkers measurably more productive.

For all a lot of people dump on Scrum Masters and Agile Coaches . . . this is part of who the good ones are supposed to be.

Oh No!

Good people amplifiers are domain/technical experts; Scrum Masters/Agile Coaches are neither.

Re: The worst programmer I know

#537
post #261

Earlier quoted context omitted.

Harry Nyquist isn't exactly an unknown engineer who doesn't have his own achievements, though - not sure why people are saying he would be fired in a modern company!

He doesn’t have his own achievements? I have heard of the Nyquist frequency, the nyquist limit, the nyquist sampling rate and the Shannon nyquist theorem. As far as I know no other individual has had this many “things” named after him.

Did you skip over the word "isn't"?

Re: The worst programmer I know

#538
post #267

Earlier quoted context omitted.

Do people honestly think this kind of thing replicates with formally scheduled Zoom 1:1s? I don’t.

I don't know about you, but I don't tend to have breakfast and lunch over Zoom. While I did go out to lunch with coworkers more often while working in the office it was almost exclusively with direct teammates, and other groups I occasionally saw where also on the same team. Now that I'm fully remote, I will typically do a few "hacking sessions" over Zoom every week. Its much easier and more comfortable than standing…

FWIW, I schedule coffee with colleagues over zoom.

It's not the same as having lunch together but it is enjoyable and useful.

Re: The worst programmer I know

#539

Earlier quoted context omitted.

The point of scrum is to provide employment for consultants and non-engineers. I left engineering for an engineering job in finance. No scrums, no POs, just trader driven development and I haven’t looked back once. Glorious.

"The point of scrum is to provide employment for consultants and non-engineers" I'm actually starting to believe this. I work for a very large company that switched to agile. We have agile / scrum coaches in pretty much every big meeting and I have yet to hear one say anything. I don't mean anything useful, I mean anything at all. They just sit there blinking. I have no idea what they do.

When someone doesn’t have anything to say, I very much prefer that they say nothing at all. Especially in meetings.

Re: The worst programmer I know

#540

Earlier quoted context omitted.

“Story points” help you predict your work in the future. Knowing what and when you deliver can be valuable! Say you’re developing software for the next Super Bowl broadcast - it’s useful to know whether you’ll deliver what you said you would. If it’s looking like you can’t, you can start to make educated decisions about what work to cut and get a better idea of what you actually will deliver.

The criticism of the GP is that teams at his company would estimate story points differently depending on how much stress they wanted to take on and not based on the complexity of the work. This had the impact of the low stress teams not taking on ambitious work. Whereas teams that would take on ambitious work and attaching points to that work were working at unsustainable levels to meet targets. In your Super Bowl e…

The predicting value is only per-team. If your team does 10 points per sprint, it won't deliver 20. If it does 100, it will.

But it's an important tenet of scrum that velocity is only meaningful in a single team[0], the root management failure in OP's case is comparing different teams.

[0] and teams cheat themselves too. I recall one advice early in my career that a velocity increase with no underlying process change was likely to mean.. that the team started to overestimate complexity, and one should understand what went wrong.

Post reply on HN