Live data from Hacker News

The worst kind of programmer

mikhailian.mova.org

71–80 of 137 posts

Re: The worst kind of programmer

#71
After the anecdote, the vibe I got of the article was anti-intellectualism applied to the programming field.

I'm all for simpler, communicable code and APIs. But at the same time not everything can be solved with a junior-level technique. That doesn't mean throw a new framework at it, but it does mean explore the problem spaces, communicate possible solutions with the team, choose one, document it, move forward.

Yeah, it is fun to skip some of the steps above, but usually at a big-picture detriment. You need a balance!

Re: The worst kind of programmer

#72
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.

> implement a custom TCP/IP stack

This but over HTTP of course, I heard it prevents issues with firewalls.

Have I seen a company-made HTTP over an internal RabbitMQ instance that had to de queue messages and call registered web hooks on our multiple apps ? Yes. And when I asked the CTO why we had to do like this, because we were losing all the rabbitmq purpose, the answer was that HTTP didn’t need firewall configuration so that we could spread our architecture everywhere over the internet.

Re: The worst kind of programmer

#73

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.

Removing the big words from English is encouraged in most business communication. I think both losses are a shame, but they are conscious decisions made by people optimizing for certain outcomes.

Another choice quote from the fine article:

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

Re: The worst kind of programmer

#74
I happen to disagree with this guy. The way I see it, we are paid to deal with sh*t. And I'm not saying this just of developers, but also of management and scrum masters. That's it.

In my current job, I was the most versatile DevOps they hired. The guy that got assigned to bringing me up to speed wanted to use shell script to automate infrastructure creation in AWS. The lead engineer wanted to use Java , because the org ships Java code. Both of them had been working at the org. for twenty years. Then a second lead architect wanted to use Cloudformation for AWS, not CDK (which, for a project this complex, would have made sense). We had to negotiate, and ended up writing Python scripts to generate Cloudformation because let's face it, nobody wanted to edit a single .yml file with a hundred thousand lines of infrastructure code and shell-script nested in it. Six months later, the lead architect who forbade us from using CDK (a consultant) came back and said, "we should use CDK, it's so much better than cloudformation and your home-made scripts." I still want to punch him on the face. But! I don't think that any of us is on the wrong when we say "X". We just do it from our best experience. We are paid to listen to the "Y" the others have to contribute, to do "Z" at the end, and to deal with the consequences, all of it as best we can.

Re: The worst kind of programmer

#75
If you're ever criticising other devs for being narcissistic and thinking they know best, while simultaneously looking down on them, you need to take a long look in the mirror.

Doubly-so if you start invoking terms like 'Dunning-Kruger'. As if they're so wrong and you're so right - there must be a psychological explanation for why they don't see things your way.

Re: The worst kind of programmer

#76

The examples given in the article do not match the final conclusion. This is all non sequitur argument. They chose a commonly known, boring tech stack (Spring boot and Angular) and then used them incorrectly and the project failed. And the authors conclude that choosing the tech stack was the problem. I argue the real problem was in management - two guys working alone and the rest of the team not participating and no…

[deleted]

Re: The worst kind of programmer

#77
post #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…

> sleep-oriented-programming

nice. ;-)

Re: The worst kind of programmer

#78
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 mean Rust code can become really opaque very fast, as there are macros and a ton of meta programming features that can make it very hard to know what a given piece of code is doing exactly (in my opinion). Golang is very straightforward in that sense, reading and understanding code seems much easier. It’s of course possible to write simple, straightforward Rust code.

I worked both with Go and Rust in a professional setting and imho if someone doesn't care about readability, the code won't be readable in either of the languages. Yes, in Rust you tend to build more abstractions, but if they're built correctly, you usually don't have to dive into the details, just use the abstractions (also isolation of level of abstractions helps). Also, yes, code in Go is simple, but as a project gets bigger you may end up with tons of copied code that may differ slightly in some variations with a lot of concepts that make it harder to read the code (like a god context object that is passed everywhere, where people just start adding stuff, cause it's easy to do and suddenly you have no control flow).

The article mentions a Java project, btw, so I'm not sure where is he getting his "it's because of the language" bit.

Re: The worst kind of programmer

#79
post #49
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??!?!?!?

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?

Re: The worst kind of programmer

#80

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“?

It's a non-starter because people disagree on "simple".
Post reply on HN