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

101–110 of 137 posts

Re: The worst kind of programmer

#101

Post by sebastianconcpt »

Arisaka1 wrote: post #51
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)

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 despise seeing appearances win over substance. I feel like every time illusion trumps over reality, whoever is involved in that is making humanity be pushed one little bit closer to asking to be fooled in a massive illusory lie ala Plato's Cave (or The Matrix 1999 if you prefer).

Re: The worst kind of programmer

#102

Post by LoganDark »

drogus wrote: post #84
sam_lowry_ wrote: post #31

Earlier quoted context omitted.

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.

What big language features did Rust get in the last few years? What big changes have you seen that changed codebases directly? Cause I code in Rust and my Rust code these days looks very similar to what I was writing a few years ago. The biggest change to the language was async/await, which was introduced almost 5 years ago. What if you compare it to Go that fairly recently got a massive new feature that can change h…

> What big language features did Rust get in the last few years?

const generics, generic associated types

Re: The worst kind of programmer

#103

Post by pkolaczk »

sam_lowry_ wrote: post #31
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…

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.

Scala has a lot of complexity due to OOP and Java interoperability. Rust does not.

Re: The worst kind of programmer

#104

Post by pkolaczk »

LoganDark wrote: post #102
drogus wrote: post #84

Earlier quoted context omitted.

What big language features did Rust get in the last few years? What big changes have you seen that changed codebases directly? Cause I code in Rust and my Rust code these days looks very similar to what I was writing a few years ago. The biggest change to the language was async/await, which was introduced almost 5 years ago. What if you compare it to Go that fairly recently got a massive new feature that can change h…

> What big language features did Rust get in the last few years? const generics, generic associated types

Those are not new features. Those are relaxing limitations on existing features and making things more orthogonal. Rust already has had generics, now you can use them in more places consistently. Similar thing with `impl Trait` in traits.

Re: The worst kind of programmer

#105

Post by icedchai »

bambax wrote: post #37
davedx wrote: 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-busin…

I love when a “timeline” is determined without even discussing the work with the people who actually do it. It’s beyond laughable.

Re: The worst kind of programmer

#106

Post by antupis »

mnsc wrote: post #62
antupis wrote: post #39

Earlier quoted context omitted.

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.

I'm sure there are circumstances where there's good reason to firehose thousands of lines of complex unmaintainable code. But how common is such "throwaway" projects?

Usually when you are starting an actual new project that kinda throwaway is a very good way to understand business needs and problem domain.

Re: The worst kind of programmer

#107

Post by icedchai »

revskill wrote: post #43
GoToRO wrote: post #6

They are the best in management eyes: look, they are doing so many things. All those things are unnecessary and will need to be supported/removed in the future. The truly best are the ones that do very little indeed. We produce software, not objects. You get to save money when you use a good piece of software not when you write it. But they are seen as lazy.

Seriously, what's the "only nessessary" for most software project ? Not CI/CD, not deployment pipelines, not complicated YAML bullshits. Testing is all you need to produce bug-free software.

Without that other stuff, (CI/CD, deployment pipelines, etc.), you’ll waste so much time manually deploying. It is very error prone, especially for those who lack knowledge of the whole system. Why not automate it?

Re: The worst kind of programmer

#108

Post by a_random_user »

While I have seen this pattern occur in many software projects I have worked on, I find your implied solution cannot possibly work; bringing everyone to the lowest common denominator can not possibly yield extraordinary results.

The example you put forth, namely rust vs golang is great; rust is an extraordinary tool.. in the right hands. So no, it is not for the average programmer. You need years of experience to see why rust is a great language and framework. To understand the why. Instead of ditching the Jedi and the light saber with it would be a better approach to understand how to leverage the extraordinary individual without alienating the entire base team. Define boxes where they can contribute as individuals who own key components.. alone. Team work is not for everyone ;-)

Re: The worst kind of programmer

#109

Post by ChrisMarshallNY »

Hmm... If you remove that last line (well, truth be told, a few folks probably earned that, too), it pretty much describes the membership of every team I've worked with, for over 35 years, and I've worked with some big, interdisciplinary, high-functioning, geographically-distributed teams.

Different strokes, for different folks, I guess.

Re: The worst kind of programmer

#110

Post by MrBuddyCasino »

cobertos wrote: post #47
MrBuddyCasino wrote: post #33

Earlier quoted context omitted.

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

The ability to be more expressive, niche, and precise. As an analogy, it would be like removing the "big words" from the English language because they are not well understood, but then losing the specificity and expressiveness of having them in the first place.

In software there is no fixed common language (like english) that, with varying competence, is spoken among all participants, but the opposite: many languages, frameworks and technologies, some of which will not see the next decade.

In such an environment, it seems prudent to avoid sunk costs of short-lived technologies, and instead try to reduce complexity as much as possible. I understand that this is not always satisfying, and that one wishes it was different. There is joy in elaborate expressions of language.

Post reply on HN