Live data from Hacker News

The worst programmer I know

dannorth.net

571–580 of 668 posts

Re: The worst programmer I know

#571
post #98

One really good developer I worked with wrote excellent code and also terrible code that had to be replaced immediately — and both made him great to work with. The value of writing good code is self explanatory. You probably use some of his code today. But he was also great in a firefight: customer is dead in the water and it might be our fault. He’d show up cold and “jam his fingers in the holes in the dam”: quickly…

I'm one of these firefighter type, and it's causing some frictions with others developpers, because my code is not great and not future proof. But I get the job done quickly, and lots of my quirky code have saved the day, either by solving an emergency or winning a tender. It's difficult to communicate with "perfect minded" developpers, because for them if code is not thought-out, then it's not worth anything, even if they understand the need for speed. Of course they think the reverse about me^^

We're set up a weekly meeting to alleviate the issue and it's working OK. The hardest is finding out which "type" is the right one, when it's not an emergency but there's a tight schedule/unclear specifications... At least we make a common decision

Re: The worst programmer I know

#572

Earlier quoted context omitted.

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.

If anything many seem super green with 1-2 years tech experience.

Re: The worst programmer I know

#573

Earlier quoted context omitted.

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.

In my team, points and tickets are useful for knowing we’ve scheduled a solid - not overwhelming or underwhelming - amount of work.

Re: The worst programmer I know

#574

Earlier quoted context omitted.

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

Oh my! You buried the lede:

"In an effort to avoid naming everything after Euler, some discoveries and theorems are attributed to the first person to have proved them _after_ Euler."

Re: The worst programmer I know

#575

Earlier quoted context omitted.

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

In my team, points and tickets are useful for knowing we’ve scheduled a solid - not overwhelming or underwhelming - amount of work.

Get rid of the scheduling too if you're doing it too often. Two times a year is good enough.

Re: The worst programmer I know

#576

Earlier quoted context omitted.

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…

If you're a senior engineer, mentoring junior engineers IS your actual job, in addition to the coding work. It's arguably the more important part of your job description because junior engineers write most of the code, so you get far more done via mentoring than you do typing on a keyboard

Re: The worst programmer I know

#577
post #221

Earlier quoted context omitted.

(I am from Europe, so I have a fairly good idea of what Unions can do, also thanks to having lived and worked in two different countries). I am not against Unionizing "per se" but the role of Unions has never been "tell the management how to run their business". There has been some cases of (smallish) company being "acquired" by their own workforce, and the Unions might have helped with formalizing the deal, but this…

A union would provide the sort of employment protections much of Europe alreadys enjoys.

I know how Unions work. The OP stated: ...it's time for you to toss that leadership out. You can do that by leaving, or talking to management about this, or unionizing.

A Union can organize and sustain a strike. But they cannot "toss leadership out". Not the CEO, the Board or any manager at any level.

They could theorethically "blackmail" a company saying "strike will not end until X is fired" where X is a PM or manager or whatever but I never really heard of anyone trying this tactic, not to say actually succeed...

Re: The worst programmer I know

#578
If you're Tim here, here's a career protip

Don't spend all your "empowerment" energy at one company. Companies WILL undervalue "glue" developers (and also "glue" teams). Eventually being so focused internally can hurt you.

Instead, if you're good at helping others, do it publicly. Speak, blog, participate in open source. Turn your "helping others" energy into one of helping the broader development community. Pay it forward there and it will reap more dividends.

Re: The worst programmer I know

#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 naively think.

In this particular case, I can think of a few reasons why the original scenario that this team was in would still be considered "bad". For example, maybe Tim received tasks to do and he didn't do them, now the company is behind on things. Maybe the other people are not as good as their job as they should be, but because of Tim's interference that's being hidden. Maybe the expectation is that the other people are as good as Tim, so why are they not helping each other out as much as Tim is? Should Tim get a promotion, or are the other people performing badly compared to their position and salary? Maybe the tasks that Tim was supposed to do are more important than the ones he's helping others with. Maybe the company didn't budget this much investment (2 people) for a specific thing that needs doing, and as there's just so much engineering time going around, what other tasks are now receiving less time than budgetted?

There's so many ways where this story may fall apart in a real context. Obviously, something has to change (expectations, budgetting, salaries, job levels, etc...) to align reality with the direction that the company wants to go into, and that change is not necessarily (limited to) "keep Tim around and have him help everyone out and everyone will be OK and this is the optimal scenario and management bad".

The implication also being that "evaluating people on story points is bad", but that completely disregards the fact that doing this has surfaced an issue in the department that needs resolving (and before I get pitchforks thrown at me - that issue may very well be that Tim needs a change of job title and a promotion) - but obviously expectations and reality didn't align beforehand, and the story point metric surfaced it and allows for resolving it. In that sense, the story point thing yielded benefits that otherwise wouldn't have been had.

Re: The worst programmer I know

#580

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

> It’s important to find/figure out what a company values and optimise for that.

One important ingredient for this is to know many companies will actively lie about their values. Typical case is, everyone tells you they value quality and feedback, while in reality everything is rushed and actual suggestions are at best thrown away in the "later" bin.

> Once a reputation has been established, it’s then possible to go about changing things, but not before.

I've noticed 2 patterns in my various gigs in the past: The virtuous cycle where I'm trusted to build something with significant autonomy from the start, I end up being happy, motivated, productive; and the vicious cycle when I'm just a new untrusted cog in their machine, my motivation & productivity plummet.

As far as I can tell I have no control over the initial condition, and the only way I could break the cycle was to start fresh in a new assignment. Some would suggest I suck it up and work my way up, but to be honest I no longer have the energy to pay my dues over and over again.

Post reply on HN