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

581–590 of 668 posts

Re: The worst programmer I know

#581

Post by sovietmudkipz »

derangedHorse wrote: post #556
redbell wrote: post #339

Evaluating someone’s performance, especially, software engineers by non-tech people might produce dramatic results. Let me tell you a story about a friend of mine, codenamed tommy . Tommy was an IT guy with incredible skills in networking. He moved to an energy company, fully-owned and operated by the government. Just a few weeks from his arrival, they had to rebuild the entire network from scratch with new, modern,…

He should’ve had a friend make a company and bid for the job. Then, later on, Tommy could be brought on as a contractor for extra pay

Serious question: isn’t this illegal? Technically the $job was paying $Tommy for his expertise in networking. If $Tommy withheld that expertise and instead entered into a conspiracy with $friend to launder his expertise for more profit from the company, it seems like double dipping.

The only way (I think) $Tommy could have done it cleanly would be to quit and instead start the enterprise with $friend before approaching $job.

Re: The worst programmer I know

#582

Post by zerbinxx »

mattmanser wrote: post #560
zerbinxx wrote: post #478

Earlier quoted context omitted.

Agreed, I will almost always take someone with 5 years of experience at a couple of good shops rather than 20 years of experience broken up across 10 different ones.

Really? I have a lot of 2 year stints, as well as some clients I worked with for 5+ years that always invariably turned into occasional month here and there. Often the long-term guys I met are the shit guys who are coasting, still writing code as if it were 2005. Worse still is when their language knowledge has coalesced around an old language version and they're not using any of the new stuff, as I've seen code base…

Well there you said it, you work some places for 5+ years, therefore I would strongly consider you. The main reason is that longer stints give you an opportunity to become a master with at least one set of tools. If you interview and are apparently not masterful with your own toolset, then I’ve caught a coaster. I’ve found that it’s much harder to acquire this signal vs. noise thing with exclusively 2 year stint people because they spend half of their life on boarding or unemployed.

Also, I get what you’re saying, but DI was around in 2005 and some good engineers (older than I) were using it back then. It seems lot of good ideas skipped a generation!

Re: The worst programmer I know

#583

Post by sbergot »

wonderwonder wrote: post #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…

Measuring story points across the company is such a weird thing. The meaning of points depends on the team. Like you can decide to multiply all the feature costs by 10 from one sprint to another if you want to.

The only usage of points is to improve the predictability of the output of a team. It cannot be used to measure performance in an absolute way.

If performance metrics are built on points, it just ruins the meaning of points. There is no reason to be honest anymore.

Re: The worst programmer I know

#584

Post by Gerardo1 »

relix wrote: post #579

As a manager in technology I'm starting to really detest stories like this, because they are often bandied around by IC's with a very narrow view or opinion of why it's bad to do new change X or Y "because here is a story", which on the surface may be similar to what happened here but is in fact a good idea. In reality things are always so much more nuanced, or require much more context to judge, than what people nai…

This seems a lot like trying to invent a problem to justify your metrics rather than acknowledging that your metrics don't align with the actual performance of the team.

There's no indication in the article that the team was struggling or under-performing, and there's no reason to promote someone out of a position they're thriving in just because the way they deliver value doesn't neatly align with how you're measuring value, especially if you can plainly see the value.

Here's what I've seen in the past: exactly the scenario you described, the "Tim" is promoted to team lead or architect or something similar, and now their calendar is booked up and they no longer have time to do the thing that brings value (and that they enjoy). No one on the team is happy, everyone is stressed, and in a year or so you'll start bleeding members. Tim either hangs around and is a mediocre whatever position he is, or he leaves to be a whatever position somewhere else where he can start with a new context and without loaded expectations.

Re: The worst programmer I know

#585

Post by sbergot »

bluecheese452 wrote: post #488
bratbag wrote: post #427

Earlier quoted context omitted.

Points are a relative value. If its 10 points a week then you estimate based on the assumption that 2 pts is a days worth of work. That, coincidentaly, is what ours roughly shakes out to be. Sounds like the stressed teams were lacking in common sense.

What happens if you underestimate one time? You get a pip. Better to overestimate.

What you need to do is to multiply all costs by ten. That way even if you underestimate one week you are not threatened by this insane metric.

Re: The worst programmer I know

#586

Post by WalterBright »

jacquesm wrote: post #525
WalterBright wrote: post #516

Earlier quoted context omitted.

> a few months later > Which was exactly what I thought they had hired me for! It's good to regularly update your manager with what you're doing and accomplishing, as they may not realize it at all.

Then you have to wonder why they're there in the first place. Managers that do not manage and do not know what the people they are supposed to be managing are up to can be missed.

I always viewed my manager(s) as people with the authority to get what I needed to do my job, not as people who needed to constantly monitor my work.

Re: The worst programmer I know

#587

Post by jrowen »

relix wrote: post #579

As a manager in technology I'm starting to really detest stories like this, because they are often bandied around by IC's with a very narrow view or opinion of why it's bad to do new change X or Y "because here is a story", which on the surface may be similar to what happened here but is in fact a good idea. In reality things are always so much more nuanced, or require much more context to judge, than what people nai…

At the end of the day, it's all emotional and biased human beings subjectively evaluating/judging other human beings. This guy that worked with Tim believed that he added great value to the team. A manager came to a different conclusion. It's impossible for them to determine who is "correct," let alone us. Of course we can come up with all sorts of potential scenarios but it seems pointless and unfounded without first-hand knowledge of the situation. The skill of being a manager is deeply understanding the specific and individual nature of their team rather than trying to apply a more generalized "playbook."

Edit: By that I mean that I am highly skeptical of metrics used to evaluate people. It's a lazy way to make the job easy and avoid doing the hard work of getting in the trenches, gaining unquantifiable insight into what's going on, and effectively communicating that up the chain.

Re: The worst programmer I know

#588

Post by zdragnar »

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…

I had a similar experience to yours. Back when I was the equivalent to what is now staff engineer, my team got a new boss. On paper, I didn't look amazing, but I was constantly helping people.

My new boss admitted at our first review that he had written up a performance plan, but threw it out not long before. What happened was we just transitioned to an open office, and he got to see the line of people who would come to me for help, and how I wouldn't turn anyone away.

I was a little salty about losing my cubicle, but that experience definitely made me appreciate being in an open office.

Of course, I haven't worked in an office of any kind for years and will never take a job that isnt WFH again, so take that last bit with a grain of salt ;)

Re: The worst programmer I know

#589

Post by sarchertech »

riffraff wrote: post #540
vegetablepotpie wrote: post #513

Earlier quoted context omitted.

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…

If your team is doing mostly similar work and the team has the same composition for a long period, points can have some meaning.

When a team shifts projects, and changes members, there are too many variables and not enough data points, so points become useless.

Since most teams change both of those thing fairly frequently, in the close to 20 years I’ve been doing this, points are generally not helpful.

Re: The worst programmer I know

#590

Post by lizard »

riffraff wrote: post #538
lizard wrote: post #267

Earlier quoted context omitted.

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.

You know, after I wrote this I got to thinking, "Why don't I have have more social Zoom calls?"

The answer is that I never was good at social things like inviting people to coffee.

But it doesn't help that we're taught to "protect" our time and avoid unnecessary calls and meetings. Presumably so we can write more lines of code, close more tickets, or earn more points like the story and other anecdotes here.

I think I may try something new in my calendar. Worst case I'll end up sitting in front of my computer alone with a block for the next hour and nothing to do but work on all those things I need to do anyways.

Post reply on HN