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

121–130 of 137 posts

Re: The worst kind of programmer

#121

Post by 4pkjai »

globular-toast wrote: post #93
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.

Agreed!

Re: The worst kind of programmer

#122

Post by LoganDark »

pkolaczk wrote: post #115
LoganDark wrote: post #111

Earlier quoted context omitted.

If you know anything of the work that was required to ship those features, you know that "relaxing limitations" was not the difficult part. I know they did ship in multiple stages, and some of those were relaxing limitations (once edge cases were accounted for), but a lot of the work was refactoring large portions of the trait solver and related machinery in order to be able to express completely new concepts (const…

I’m not saying it was trivial to implement internally. But from the perspective of developers this is not a new feature, but a new ability to compose existing features. Also, their existence does not change how you write idiomatic code. Existing code still compiles and doesn’t need changes. Those features are pretty niche.

> Existing code still compiles and doesn’t need changes.

This will be true forever, because of Rust's stability guarantees. By this logic, Rust will never have any new features.

Re: The worst kind of programmer

#123

Post by from-nibly »

gardenhedge wrote: post #10

I agree they were bad devs but I don't see how scrum fixes this at all. Even if every team member got a say, they would defer to the most experienced.

As someone in this situation a lot. They always do. People generally don't want to fight the smartest guy in the room. And everyone is happy to leave responsibility with someone else.

Re: The worst kind of programmer

#124

Post by sam_lowry_ »

Tainnor wrote: post #113

The kind of anti-intellectualism that is espoused by this blog post is what sometimes makes me want to leave this profession. Certainly, there are many people who overcomplicate solutions - for a myriad of reasons. The idea that therefore it is suspicious to be passionate about software engineering or that one should work as an interchangeable DevOps cog is deeply saddening however.

I always suspected that the famous 20% side project time in early Google was a trick to divert intellectuals from shitting into production code.

Re: The worst kind of programmer

#125

Post by cobertos »

MrBuddyCasino wrote: post #110
cobertos wrote: post #47

Earlier quoted context omitted.

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

But English is not fixed, at the domain-specific level. Domain-specific words are created, used, and forgotten all the time. This is to the benefit of communication/problem-solving and detriment to outsiders, juniors, longevity etc. (if the concept doesn't "stick")

Mathematics, finance, material science, etc. all have concepts and words in that conceptual space to define ways to solve and talk about problems. To pick one up and build upon it but have it be forgotten/not-understood has the same risk/reward as potentially choosing a short-lived technology. Sometimes choosing something complex is worth the risk, sometimes it's not.

Re: The worst kind of programmer

#126

Post by t8sr »

pydry wrote: post #100
Ferret7446 wrote: post #89

Earlier quoted context omitted.

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

I’ve seen it replace Python and Java. In both cases, Go was a massive win from a readability and operational predictability POV. Of course I’m not talking about data science Python, which is hard to displace, but “microservices Python”, which I still have nightmares about.

I’ve not seen it replace C++ so much - that’s Rust’s job. But a SWE with 2 years of on the job experience shouldn’t be writing C++ or Rust, they should be writing Go or something equally hard to mess up. (Rust might be safe, but it gives you enough power to write truly unreadable code, just like C++ does.)

The two languages are in different niches, and I am curious why they get compared so much. I write Rust and Go, and for the stuff I work on, they almost never overlap.

Re: The worst kind of programmer

#127

Post by revskill »

icedchai wrote: post #107
revskill wrote: post #43

Earlier quoted context omitted.

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?

Those things are not rocket science, isn't it ?

Re: The worst kind of programmer

#128

Post by diarrhea »

bilinguliar wrote: post #46
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…

With feature-rich languages, teams often end up with their own DSL. I see it as a downside. Especially at 3 AM.

Rust specifically isn’t feature-rich. It’s mainly just different.

Re: The worst kind of programmer

#129

Post by icedchai »

revskill wrote: post #127
icedchai wrote: post #107

Earlier quoted context omitted.

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?

Those things are not rocket science, isn't it ?

No, but I've found many developers are uncomfortable touching anything outside of their local environment.

Re: The worst kind of programmer

#130

Post by GoToRO »

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.

That's not what I was referring to. F.e. management brought on the project some senior dev. He did a minor framework update, reeplace one library with another even if nobody was complaining about anything and he was gone. None of the problems or technical debt the client was actually complaining was addressed. Oh, and he did some implementation that blocked the other devs, and we needed to work arround it.
Post reply on HN