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

The worst programmer I know

dannorth.net

Post reply on HN
Print view View original

441–450 of 668 posts

Re: The worst programmer I know

#441

Post by jackblemming »

rightbyte wrote: post #296
lcuff wrote: post #111

Earlier quoted context omitted.

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

> 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.

Re: The worst programmer I know

#442

Post by no_wizard »

astrange wrote: post #390
manicennui wrote: post #324

Earlier quoted context omitted.

Nonsense. Most people write pretty useless unit tests. Gotta get that test "coverage" high though!

Unit tests are useful if you write them alongside new code, but then become not useful since if you never change the code, they never break, and so are wasteful. It's better to have tests more sensitive to failure, like integration or regression tests.

They’re still valid even if you aren’t changing code.

The key there is caching your results. Don’t run unit tests for code that hasn’t changed.

They still serve the important purpose of checking validity of the code under test though, so if they do get modified downstream at some point and they fail you then know the changes aren’t conforming to expectations of the system.

This of course assumes people aren’t writing highly coupled tests and that is more rare than I wish it to be

Re: The worst programmer I know

#443

Post by erik_seaberg »

psunavy03 wrote: post #146
hardwaregeek wrote: post #86

It’s like Draymond Green. Individually his statistics suck. He’s jokingly called Mr Triple Single (a triple double is a major achievement, a triple single not so much). But he’s such a fantastic defensive coordinator and playmaker that his impact metrics on the team are massive. Like practically comparable to Steph, his more lauded teammate, in some stretches. A common refrain in basketball is that people forget it’s…

And similarly to sports, there are devs who understand this, and devs who actively refuse to do things like pair, mob, or collaborate and just want to be handed work pellets so they can pick up their headphones and go to la-la land.

I don’t expect predigested tasks, and I’m fine with participating in broad strokes planning. But I need peace and quiet when I’m trying to concentrate on writing the code.

Re: The worst programmer I know

#444

Post by tialaramex »

tchaffee wrote: post #393
twic wrote: post #376

Earlier quoted context omitted.

HR are not going to reject an incredibly experienced senior guy with a CV as long as your arm because of the title of a blog post. Your quote doesn't even suggest they would, and I'm not going to cite any evidence because it's honestly just a patently absurd proposition.

HR will definitely reject someone because of the title of a blog post. When you have a pile of a hundred CVs and two openings, you disqualify quickly. I'm basing this on real world experience.

If you're letting HR who have no idea what they're doing, go from "a hundred CVs" to "two openings" you are bad at your job.

HR's job, like legal, or many other departments, is to facilitate what you actually do which in this case means work like chasing references and ensuring the candidates have somebody who can answer stupid logistics questions without bothering the interviewer, not figuring out who is the best fit for any particular job, that's the job of the people making the hiring decision.

Maybe if you're hiring fifty people to stand outside in the rain holding signs you can let HR pick who gets a job. Picking software engineers, especially if you actually care whether they're any good, is not the purpose of an HR department.

Re: The worst programmer I know

#445

Post by lmm »

thelastgallon wrote: post #426

I've never seen these kind of people (Tim). Almost always, it is someone who knows absolutely nothing, meanders from desk to desk, wasting productive people's time, picking their brains. They are usually never given any work, because someone else has to undo the damage and do the work! Then then socialize with managers outside of the team, bragging about how much 'value' they're adding and they can talk as if they he…

Yep. Even in the unlikely event that he's really that good, he's doing only the fun part of the job and shirking the other 90% where you turn your brilliant code into something that actually does something useful for an end user. A better manager would take action.

Re: The worst programmer I know

#446

Post by paint »

>Measure productivity by all means—I’m all for accountability—ideally as tangible business impact expressed in dollars saved, generated, or protected.

That's a disgusting way to think about productivity, the result of otherwise smart people growing up in a capitalist exploitative system.

Re: The worst programmer I know

#447

Post by gcheong »

whirlwin wrote: post #431
Stratoscope wrote: post #304

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…

What an odd practice. Not sure who conducted the review, but managers especially should be familiar with the concept of coaching, and recognize that you were doing a great deal of it. I am a technical manager myself and spend a lot of time on coaching team members too.

20 years ago when I started there wasn’t anything I experienced that could be called coaching, mentoring, or leveling up. Sure, I could get some time from a more experienced developer to get another set of eyes on a particularly hard problem if I wasn’t able to come up with a solution but for the most part I was just expected to work with minimal explanation or direction. Very little in the way of code reviews as well. I certainly hope this has changed and to whatever extent I’ve been able to I’ve always tried to make myself available to others because sink or swim really sucks.

Re: The worst programmer I know

#448

Post by _boffin_ »

gardenhedge wrote: post #362
_boffin_ wrote: post #75

Earlier quoted context omitted.

Maybe Tim could have also added his name to the tickets as he was pairing and helping the others complete them...

Certain tools (Ahem MS) don't allow more than one person to be added to a ticket

What tools are you talking about?

Re: The worst programmer I know

#449

Post by nine_zeros »

jareklupinski wrote: post #183
nine_zeros wrote: post #105

Earlier quoted context omitted.

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

that's great for covering your a, but the project will still fail and no one will get value / praise for all that time spent if time is the only actual concern for the project's success, a good approach is to explicitly re-scope the feature list and start asking managers things like: "do we really need feature X to release? can feature Y wait until after beta? did the request for feature Z come from a user or a stake…

> that's great for covering your a, but the project will still fail and no one will get value / praise for all that time spent

Yes the project will fail. But if my manager only cares about speed, why should I care about anything more? Why should an engineer be responsible for a manager's poor decisions?

Re: The worst programmer I know

#450

Post by charamis »

throwaway92837 wrote: post #67
jongjong wrote: post #64

Earlier quoted context omitted.

My problem in my last role when I read large Pull Requests is that they tended to be way more complicated than they should have been but because they worked and I couldn't single out a small number of specific problems, I had no choice but to approve. Still, I knew it would slow us down in the medium and long term but this bloat is completely invisible to management. It has become taboo to say things like "This code…

Right. This is where you would think the AI assistance could play an important role: Warning: it looks like you’re trying to pack too much crap into a single PR and your peers are unlikely to understand what they are accepting.

The person who would ignore the reviewer’s recommendation in this case, would probably also ignore the AI’s as well.
Post reply on HN