Live data from Hacker News

The worst programmer I know

dannorth.net

501–510 of 668 posts

Re: The worst programmer I know

#501

The worst programmer I knew never had any productivity problem; if anything he produced too much code, outpacing the others' ability to maintain certain levels of quality. He ended up promoted; in many organizations, people that hack the code rather than properly design and build sustainable solutions are highly valued.

Yeah, that must have been my collegue. Usually he was in charge of implementing all the new stuff, because he was able to deliver fast. And then I had to refactor, or usually just rewrite and redesign the whole thing, because it was immediatelly unmaintenable. I didn't mind, since at the end of the day, he was really good and doing these prototypes and selling them to management. I was good at making the application last and stable, so it kinda worked out.

Re: The worst programmer I know

#502
Whenever I’m forced to do a periodic performance/peer review, I just think about how I’m doing my manager’s job for them.

I’ve already spent the last quarter either complaining about coworkers or praising them, now you write the damn report! And as for the self evaluation, again, you write the damn report… unless you have no clue as to how I’m doing, to which I say, your performance really sucks as a manager.

Re: The worst programmer I know

#503

Earlier quoted context omitted.

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?

>Why should an engineer be responsible for a manager's poor decisions?

Because the corporate hierarchy demands it. Front-line workers are expendable, much like front-line soldiers. Corporations are not democracies, and neither are militaries.

If your job is to write and commit code, you are the corporate equivalent of infantry. In short: a grunt.

Re: The worst programmer I know

#504

Earlier quoted context omitted.

"fully-owned and operated by the government" - This is the most important reason. For better or worse, gov't jobs are basically not allowed to meaningfully reward exceptional performance. There's just no mechanism for it. Not to say things like this don't happen in private industry too - it certainly does. But at least you've got a chance. In most companies there is room to meaningfully bonus or promote or otherwise…

This doesn't happen at FAANG either, absolutely nothing to do with gov't

Sure they do, you just haven't demonstrated that exceptional performance.

Re: The worst programmer I know

#505

Earlier quoted context omitted.

Absolutely! But after a while he knew why there was no kind of reward whether in the form of a financial compensation, a promotion or even additional days of vacation. Simply because the law of work does not have a section for exceptional performance/achievement.

"fully-owned and operated by the government" - This is the most important reason. For better or worse, gov't jobs are basically not allowed to meaningfully reward exceptional performance. There's just no mechanism for it. Not to say things like this don't happen in private industry too - it certainly does. But at least you've got a chance. In most companies there is room to meaningfully bonus or promote or otherwise…

>For better or worse, gov't jobs are basically not allowed to meaningfully reward exceptional performance.

Neither do private companies. The measurement becomes the goal. And that measurement often has nothing to do with legitimate performance.

Re: The worst programmer I know

#506

Earlier quoted context omitted.

I hope that feedback didn't discourage you from continuing with your approach to software development and teamwork.

I am the same way with my coworkers. I spend a lot of time helping juniors with their code and doing code review. My boss talked to me and told me to stop helping out so much and focus on my own tickets.

That’s good feedback I think.

There’s an article that was going around again about ‘glue work’ ([1]) that has a story where an engineer gets caught up doing all this kind of mentoring, coordination and other work like that and then is passed over for promotions because they don’t have technical achievements (though they claim to have become instrumental in enabling everyone else’s technical achievements).

The article never gets to quite the right conclusion - it’s actually massive management failure - what I was thinking the whole way through was “why hasn’t somebody sat them down and told them to do their actual job??”

Mentoring and code review are both super important, but if the organisation wants you to focus on getting tickets done then you basically just have to, unless you can convince them to actually add the additional work to your actual role description or get enough seniority to add it yourself.

But it’s good to have feedback on what kind of work you’re actually going to be measured on in performance reviews, promotions etc.

1. https://noidea.dog/glue

Re: The worst programmer I know

#507

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…

It’s important to find/figure out what a company values and optimise for that. Once a reputation has been established, it’s then possible to go about changing things, but not before.

I’ve seen too many stories of people optimising for the “team”, but losing their job or being looked over for promotion due to negative perception from those higher up.

The opposite is also true, sometimes unfortunately. Once a good reputation has been established (whatever is currently valued in the company), any amount of misbehaviour will be tolerated for a long time.

It shouldn’t be this way, but that’s been my experience.

Re: The worst programmer I know

#508
post #463

Earlier quoted context omitted.

In the modern company good engineers are not valued. Engineering excellence is not a prerequisite to business success. Managers know this. Why else many things any one of us could list from the computing business.

I agree with you 100%. Management does not have an eye for software that is easy to maintain and continue to make money on 5 or 10 years down the line. Most management is thinking short term, how do I get money in MY pocket right NOW. Who cares how the business does in the long term, they'll jump ship and move on. It is the engineering that often makes a difference for long lived companies, it's just that usually the…

> ... 5 or 10 years down the line. Most management is thinking short term,

Woe is us. Five or ten years is not considered short term

> . I try to give more to the clients that pay more, or at least create something that I can reuse in the future, while making sure what I deliver is stable and not a big ball of spaghetti to make the next developer/engineer cry at night.

I am not sure about the "...who pay more". As I am currently woefully underpaid I am more sympathetic to that view than once I was, but, I still view myself as a professional, and I act with professional ethics.

Partly that means speaking up when I see a project going near the rocks. I do not make too much fuss, but I do say it out loud.

That has cost me plenty. Our industry is full of people who are very good at one thing or another, but do not know their limits.

Part of my "being professional" is knowing my own limits.

Re: The worst programmer I know

#509
I know a dozen programmers like this. It's true that it's not easy to get fired if you're a constant benefit to the team's productivity, but it's very hard to get promoted under most organizations' promo guidelines, which usually involve design documents and end-to-end projects.

Re: The worst programmer I know

#510

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…

> ...or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers. But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns. I'm not saying this was a good workplace, it doesn't sound like it at all. But to me, it sounds li…

What Scrum "intends" to do, and what it actually does, are radically different.
Post reply on HN