Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The worst kind of programmer

mikhailian.mova.org

Post reply on HN
Print view View original

91–100 of 137 posts

Re: The worst kind of programmer

#91

Post by globular-toast »

If one of these "worst kind" developers is messing up the team then it's not a good team. You wouldn't want a team composed entirely of this type of programmer but, equally, you wouldn't want one composed entirely of the 9-5 bish-bosh-bash type programmer either.

This kind of analysis makes it seem like not only a binary system but a one-dimensional one too. People are multi-faceted and each individual fits somewhere on a multi-dimensional space. Some people like to talk to users, others prefer to talk to technical peers. Some like to break down problems into their essence, others like to do literally what they are told to do. Some like to work on honing their tools and techniques, others prefer to learn something once and keep using it forever.

Ultimately you bring out the best in someone if you can get them doing what they like doing. The "best" people in any field are those that are there because they like doing what they are doing. The ones that struggle are those that are doing it simply as a job that pays. A good team will bring out the best in everyone.

Re: The worst kind of programmer

#92

Post by Arisaka1 »

axegon_ wrote: post #36

> There is broad consensus that Golang is simple to the point of being symplistic. It is in a way opposed to Rust as the means to an end and not a subject of much discussion. Golang teams strive, Rust teams… rust, because the language encourages concentration on itself, not on the outcomes of engineering projects. I'm sorry, what??!?!?!?

I also saw the same on Reddit, that in terms of language design Go is trying to stay simplistic and the example people tend to give is using a single for loop with variations instead of many specialized loop structures.

Re: The worst kind of programmer

#93

Post by globular-toast »

4pkjai wrote: 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…

Sounds like you and the other guy were in the wrong job then. Don't blame the rockstar. Go and find the place where you're the rockstar.

Re: The worst kind of programmer

#94

Post by drogus »

t8sr wrote: post #79
pydry wrote: post #49

Earlier quoted context omitted.

It sounds like he's overfitting to one or two programmers he knows. It seems ironic to me because rust is clearly designed much more pragmatically than golang. The whole article is also ironic because a hallmark of bad programmers is overgeneralizing their bad experiences.

> It seems ironic to me because rust is clearly designed much more pragmatically than golang. That’s a big “citation needed”. Why is it clear and what do _you_ mean when you say pragmatic?

I disagree that it's more pragmatic (and I love Rust), but in my opinion it's designed more thoughtfully. There are many articles pointing out various inconsistencies in Go, like: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...

Frankly I find things like that all the time, the most recent one I remember is my small frustration regarding rational numbers and duration manipulation: https://x.com/drogus/status/1728407593771471226?s=20

Re: The worst kind of programmer

#95

Post by drogus »

_v7gu wrote: post #81
sk11001 wrote: post #48

Earlier quoted context omitted.

I don't know if I would the generalize as much as the author about how different teams operate but there is a valid point in there - with some languages you can focus on getting things done while with Rust you spend a disproportionately large percentage of your time thinking about programming language concepts.

I think Go creates a false sense of “getting things done” by allowing too little abstraction and increasing LOC. The writing/thinking ratio is great, but most of it is having to write 4 lines of repetitive code for every reduce that should have been one line instead

I implore anyone that says "Go is simple therefore Go codebases are simple" to look at big Go projects like Kubernetes

Re: The worst kind of programmer

#96

Post by timeon »

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

> Why call out Rust specifically here?

Author just wants to push narrative. Examples in article were about something else but he needed to slip it there anyway.

Re: The worst kind of programmer

#97

Post by moffkalast »

axegon_ wrote: post #36

> There is broad consensus that Golang is simple to the point of being symplistic. It is in a way opposed to Rust as the means to an end and not a subject of much discussion. Golang teams strive, Rust teams… rust, because the language encourages concentration on itself, not on the outcomes of engineering projects. I'm sorry, what??!?!?!?

A peek into the very strange mind of the average Golang enjoyer I guess.

Re: The worst kind of programmer

#98

Post by moffkalast »

CipherThrowaway wrote: post #83

The author was on a mismanaged project and his takeaway is to blame his fellow devs rather than hold management accountable. In fact, he does not even seem to recognize the existence of a managerial issue. This whole article reeks of imposter syndrome. Of course, it must be the case that all the devs who are more productive and impactful than the author are actually secretly very bad, and that the author's inability…

The main management issue with this project sounds like the lack of prototyping while requirements are unknown. Until they are rock solid every piece of code written should be considered expendable.

I bet the guy suddenly quit once it became obvious that they'd have to maintain a poorly fit monstrosity and management wouldn't support a full rewrite that was badly required now that they knew what they actually needed. And because they probably got a better paid offer from some other place where they could build something from scratch again. Or maybe I'm just projecting, lmao.

Re: The worst kind of programmer

#99

Post by sebastianconcpt »

Instantix wrote: post #53
gwnywg wrote: post #26

Earlier quoted context omitted.

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.

Right but managers have the responsibility to validate everyone has not only the right level of urgency but that has it in the right thing. The natural thing to happen is small deviations escalating to misalignment and later lack of trust. Managers should check on the small deviations and gently (social skill) help teammates stream their energy and efforts to take the mission to success. And whatever the major constraint is for a given team, every business needs to de-risk their engineering investments and nothing does that better than a great team culture and great vibes among teammates. If managers aren't the protectors of that I see them as either incompetent, failures or frauds.

Re: The worst kind of programmer

#100

Post by pydry »

Ferret7446 wrote: post #89
pydry wrote: post #49

Earlier quoted context omitted.

It sounds like he's overfitting to one or two programmers he knows. It seems ironic to me because rust is clearly designed much more pragmatically than golang. The whole article is also ironic because a hallmark of bad programmers is overgeneralizing their bad experiences.

I would be interested in reading about the pragmatism behind Rust's design. Go was designed to specifically address many pragmatic issues at Google, such as slow compile times, engineer ramp up time, language complexity causing hard to understand code, ease of writing automated tooling, and more. https://go.dev/talks/2012/splash.article

Rust was dogfooded essentially as a replacement for C++ with better thread, memory and type safety and was designed to swap out C++ in firefox with a view to eliminating whole classes of bugs.

Golang may be the perfect language internally at google for all i know but where it substitutes for python Id rather use python and where it substitutes for rust Id rather use rust.

Ive been serially unimpressed with some of the design decisions, including the initial reluctance to do package management properly, the lack of exceptions and how long it took to get generics. After trying to write golang i always seem to write equivalent code with 30% more SLOC as a result of some decisions that seem more idealistic than pragmatic.

(im also a pretty firm believer that SLOC correlates to bugs, so i view 30% longer code, all other things being equal = 30% more bugs)

Post reply on HN