Live data from Hacker News

The worst kind of programmer

mikhailian.mova.org

31–40 of 137 posts

Re: The worst kind of programmer

#31

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

Rust, like Scala, is a complex ever evolving language that attracts curious minds. Look at the human side of the story. Yes, teams can build great software in Rust. But Rust also attracts many people interested in playing with fancy language features.

If I had a choice, I would have taken Go over Rust just because I need a different kind of people in my team.

Re: The worst kind of programmer

#32
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,…

I love the cats analogy. It reminds me of the book even tougher than herding cats (about tech management) https://www.amusingmulcahy.com/my-first-book-even-tougher-th... No mention of autistic cats there as far as i remember!

Added to my reading list. Thanks

Re: The worst kind of programmer

#33

This is a deeply nihilistic article. The pinnacle of software development is definitely not simple languages and boring technologies. Have we given up?

Can you elaborate what exactly we‘re giving up when choosing „simple languages and boring technologies“?

Re: The worst kind of programmer

#34
post #4

Yeah. Functional programming happened to be trending again and our lead service bus developers decided to write Java like it’s Haskell. Now their garbage keeps crashing with stack overflows, and they complain when files are bigger than a few hundred lines. We accidentally pushed a 10,000 line file once and it brought the entire bus to a crawl for an hour. TEN THOUSAND LINES. One day, these twerps pushing this stupidi…

Yeah that's not the fault of a functional approach, that's just bad code.

And perhaps the code was bad just by using a functional approach which nobody master. QED

Re: The worst kind of programmer

#35

This is a deeply nihilistic article. The pinnacle of software development is definitely not simple languages and boring technologies. Have we given up?

It depends on the requirements. Does CRUD software require the pinnacle of software development?

Energy/"talent" would be better spent elsewhere.

(don't mean "talent" as derogatory but everyone has its own definition so it's a bit unclear)

Re: The worst kind of programmer

#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??!?!?!?

Re: The worst kind of programmer

#37
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,…

Well yes; the problem described in the post is often found in real life: how many Angular projects are simple CRUD apps that would work just as well in PHP or ASP? But I don't think the cause is clever programmers.

I think the main cause (as you say) is this:

> After all, the management in business environments is usually non-technical

Management in business environments is not only non-technical, it's also non-business. It specializes in managing people and timelines, without a profound understanding of either the business requirements or the technical solutions available to address them.

I don't know how one promotes a culture where management is technical but that should be an important topic to focus on in many (most?) organizations.

Re: The worst kind of programmer

#38

I feel confused. Even though I’ve been doing C++ embedded systems and drivers, C++ network protocols, C++ graphics engines (OpenGL and Vulkan), C++ video codecs etc, on many OS’s, all this for over 25 years professionally, I must admit I have no clue about the articles technology stack, programming techniques, languages, or architecture. Am I completely out of touch with this industry?

You may be out of touch with web development in the "enterprise" (Java) style. Personally I much prefer working in the embedded/video/graphics area so if I never have to work with Angular/Spring that's ok with me.

Re: The worst kind of programmer

#39

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

Also, it is much slower than just shipping the code. I prefer working with a pair or a team but sometimes you need to ship often and fast.

Re: The worst kind of programmer

#40
post #15

The point of the article is buried under the bait that is the list of qualities to watch out for. The main problem was that these people overengineer things and work without any collaboration or business context. Out of the four listed qualities: Ability to find satisfaction in solving abstract problems Ability to put up many hours of work Passion in software engineering Narcissism and self-confidence Only the last o…

I find that the first three are correlated with both the best and the worst engineers I know. The last one is usually the decider. Sadly lots of hiring processes select heavily for the first three and are poor at identifying the last one.
Post reply on HN