Live data from Hacker News

The worst kind of programmer

mikhailian.mova.org

51–60 of 137 posts

Re: The worst kind of programmer

#51
post #26

All this for me has nothing to do with programming or programmers and much less to skill level. All that is superficial. What's lacking there is deep alignment before jumping into coding and too much concentrated dependencies in specific individuals instead of team. Call it process problem if you want. It's a people and culture of that team problem that downstream to a process that didn't care enough about teammates…

Yep, this sentence from the article is good summary of the problem they had: > The rest of the team observed them in admiration. They should have been included in building base, they also should spend time learning what state of the art is (since, as article says, they had time before requirements started flowing)

As far as I know, appearances win every time, so the appearance of you being (to put it in video game terms) "the carry" is much better than you being the one who teaches others.

Then we have the replaceability factor. It's not rare for someone to try to secure their spot by making themselves irreplaceable, and one way of doing this is by being the only person working on a project or the vast majority of the codebase. I'm currently onboarded in a (previously) 1-man project and I find myself learning why they designed things like that instead of learning the framework and best practices.

Re: The worst kind of programmer

#52
post #9

I worked with a guy who did 12 hour days, closed tons of tickets but his code was full of bugs. We were writing trading software and he would handle errors by silently failing. I worked with someone else who didn’t have a computer at home. Their coding style was “write code that I don’t have to support, I don’t want to get emails while I’m sleeping”. They wrote mega defensive and very boring code. Their code never ha…

> closer tons of tickets but his code was full of bugs

Yeah, total closed ticket count is a terrible metric. If closing one ticket in a rush opens two bug tickets, that’s one ticket opened overall. Much harder to track though!

Re: The worst kind of programmer

#53
post #26

All this for me has nothing to do with programming or programmers and much less to skill level. All that is superficial. What's lacking there is deep alignment before jumping into coding and too much concentrated dependencies in specific individuals instead of team. Call it process problem if you want. It's a people and culture of that team problem that downstream to a process that didn't care enough about teammates…

Yep, this sentence from the article is good summary of the problem they had: > The rest of the team observed them in admiration. They should have been included in building base, they also should spend time learning what state of the art is (since, as article says, they had time before requirements started flowing)

I agree for an ideal world but the problem is often the wall of the reality i.e. TIME. Levelling the playing field takes time and it's not doable when you have to deliver now, not in a month. So playing at a level sustainable by everyone on the long run is certainly a better and more robust approach.

Re: The worst kind of programmer

#54
post #9

I worked with a guy who did 12 hour days, closed tons of tickets but his code was full of bugs. We were writing trading software and he would handle errors by silently failing. I worked with someone else who didn’t have a computer at home. Their coding style was “write code that I don’t have to support, I don’t want to get emails while I’m sleeping”. They wrote mega defensive and very boring code. Their code never ha…

Isn't this highly dependent on management too? Person 2 would get fired in a startup because he/she didn't create features fast enough.

Re: The worst kind of programmer

#55
I suspect that these types of programmers are not challenged enough at work. And this is when some devs try to entertain themselves at customers' expense. My advice to such people would be to work with the team where they are no longer the most experienced. Another option is to start a side project that can be safely used as a proving ground for all the exciting ideas.

Re: The worst kind of programmer

#56
I’ve fallen into this trap as well and try to be more mindful and pick boring, easy technologies and frameworks. Each and every time I built some (in my opinion) clever abstraction or library some other devs would struggle to use it. And they were right I guess, as I don’t want to grok other peoples homegrown libraries either. In the end software is a team game and you need a common language, and you need to realize that most programmers (maybe not the ones here) just want to solve the issue at hand in a straightforward way.

That said even frameworks can be problematic, e.g. in the JS world the technology churn rate is so high that I had developers rewrite perfectly fine though a bit outdated React code bases in the latest fad framework. Those developers are dangerous too, they don’t invent their own stuff but they want to always stay on the bleeding edge, which is a recipe for disaster in most organizations.

Re: The worst kind of programmer

#57
post #9

I worked with a guy who did 12 hour days, closed tons of tickets but his code was full of bugs. We were writing trading software and he would handle errors by silently failing. I worked with someone else who didn’t have a computer at home. Their coding style was “write code that I don’t have to support, I don’t want to get emails while I’m sleeping”. They wrote mega defensive and very boring code. Their code never ha…

Isn't this highly dependent on management too? Person 2 would get fired in a startup because he/she didn't create features fast enough.

Afaik person 2 would get fired from any company that touts its internal competitiveness and technical challenges as a benefit.

Re: The worst kind of programmer

#58

What a pile of garbage. So you’re no meant to use generators/discriminators/whatever because they’re too fancy or something? IMO any language feature, any technology feature that is there and documented in the API is fair game to be used. The author seems to be suggesting there is some “standard” way of programming ….. not too advanced mind you …. and that anyone who uses more than some baseline set of features is se…

> What exactly is this line below which you’re a good normal sane programmer and above which you’re a narcissistic primadonna who makes write only software.

Look at the rest of your team, all the other developers that have to work on the product. Write for the average capability of those, bearing in mind that employee churn will mean new people have to be on-boarded.

Realise that code that is 'simple' to you, often may not be to others - you will see it thought your own. The code has to be readable and maintainable by others.

> You’re a professional software developer, do your job.

Exactly. That's not just about churning out clever code and moving on. It's about creating a product that can be maintained by everyone on the team.

Anyone who's had to maintain a 'legacy' codebase knows exactly what this means, as they curse the names of those who came before and the stupid decisions they made... and spend far too long trying to figure out the obscure code ideas they used.

Re: The worst kind of programmer

#59
> Appealing to management does not work. After all, the management in business environments is usually non-technical, and the worst kind are the best performers. Who should the management listen to if not to the best performers?

> One largely unappreciated aspect of Scrum is the interchangeable nature of team members.

I'm not trying to argue that encouraging this kind of programmer will result in better software, but if a programmer goes from "difficult to replace" to "easy to replace" by following these best practices, then maybe the problem runs much deeper than these kinds of individual programmers. Apparently following best practices is bad for job security.

Re: The worst kind of programmer

#60
post #9

I worked with a guy who did 12 hour days, closed tons of tickets but his code was full of bugs. We were writing trading software and he would handle errors by silently failing. I worked with someone else who didn’t have a computer at home. Their coding style was “write code that I don’t have to support, I don’t want to get emails while I’m sleeping”. They wrote mega defensive and very boring code. Their code never ha…

> They wrote mega defensive and very boring code How I love boring code, and I am getting more defensive. Good-sleep-oriented-programming. For much of my career I took technical debt on myself because I felt uncomfortable giving generous time estimations with ample buffers. I am ashamed. But now I learn to push the breaks, ask for help and escalate unexpected problems as early as possible in the project. I don't need the trendiest tech on my resume as long as the team is happy and sleep well.
Post reply on HN