Live data from Hacker News

The worst kind of programmer

mikhailian.mova.org

21–30 of 137 posts

Re: The worst kind of programmer

#21
> Golang teams strive, Rust teams… rust, because the language encourages concentration on itself, not on the outcomes of engineering projects.

Why call out Rust specifically here? CloudFlare achieved the world's first widespread deployment of HTTP/3 thanks to Rust, and they called out plenty of Rust-specific benefits that sped up the development process and provided peace of mind.

Sure, if you're using Rust just because it's Rust, you'll lose sight of the big picture. This can happen in any language.

Re: The worst kind of programmer

#22
post #7

This is a brilliant way to put how I view "10X developer" mindset.

You’re not a 10x if you can’t share your knowledge by mentoring others, writing good docs and writing code that’s easy to read and change by others. By this standard, they were not 10x. 10x is not about number of lines of code produced.

Re: The worst kind of programmer

#23
post #2

It's a good discussion to have! I've been in both sides of these roles over the years. I think the problems in the article really seem to be lack of technical design or leadership though, rather than problems with individual programmers or personality types. You can't have one guy leave, another guy come in, have the same issues then blame the people. The process is broken! At any kind of head count beyond 5+ people,…

It happens when companies are managed by people with non-technical backgrounds. They think they can employ “autistic wizards” to solve the lowly technical problems. One such wizard initially receives all the praise and then gets so out of touch with reality that they either implement a custom TCP/IP stack or they get frenzy with the modern buzzword tools.

Re: The worst kind of programmer

#24
Developing software as a team is a completely different sport than developing software alone. Developing software alone even happens when people think they work as a team. They just split up the tasks so that each individual contributor owns their part of the codebase.

Developing software as a team really means much more time is spent on discussion, writing documentation, reviewing code and explaining concepts than actually writing code. The benefit of this is: Everyone in the team has a good understanding of the code base and can contribute. The disadvantage: Not everyone likes this style of work and is comfortable with so many non conding tasks.

Re: The worst kind of programmer

#25
post #7

This is a brilliant way to put how I view "10X developer" mindset.

You’re not a 10x if you can’t share your knowledge by mentoring others, writing good docs and writing code that’s easy to read and change by others. By this standard, they were not 10x. 10x is not about number of lines of code produced.

I agree, but by the looks of many social media posts it's basically a nerdy extension of the "sigma grindset" movement, rather than what you mentioned about good software engineering practices.

Re: The worst kind of programmer

#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)

Re: The worst kind of programmer

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

For me that's very much been an experience thing. It's often not just motivation, but also that handling errors properly can be genuinely difficult compared to writing the happy paths of code.

It's probably a good thing to do a training/knowledge sharing on in an org (seniors show juniors different ways to handle errors).

Re: The worst kind of programmer

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

Person two sounds great to work with, would love to be like them

Re: The worst kind of programmer

#30
"Intermediate dev" strikes again!

Junior dev works in fear and tends not to make a mess

Senior dev knows less code is better than more

Intermediate dev knows about every tool in the toolbox but doesn't know when is the right time and place to put them to use

It's an extra insult to have to follow through on their bad decisions once they leave

Post reply on HN