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…
For me that's very much been an experience thing. It's often not just motivation, but also that handling errors properly can be genuinely difficult compared to writing the happy paths of code. It's probably a good thing to do a training/knowledge sharing on in an org (seniors show juniors different ways to handle errors).
The worst kind of programmer
41–50 of 137 posts
Re: The worst kind of programmer
#42So you’re no meant to use generators/discriminators/whatever because they’re too fancy or something?
IMO any language feature, any technology feature that is there and documented in the API is fair game to be used.
The author seems to be suggesting there is some “standard” way of programming ….. not too advanced mind you …. and that anyone who uses more than some baseline set of features is setting up some crazy complex house of cards.
Codswallop.
What exactly is this line below which you’re a good normal sane programmer and above which you’re a narcissistic primadonna who makes write only software.
Don’t write your software for a baseline of barely competent programmer …. write the best software you can according to the project priorities defined by management.
And use every advanced technique you think is right for the job.
As long as you strive for simplicity then whatever you need to get there is the right technique.
The alternative is done stupid set of rules that go through the programming APIs and cross a whole bunch of stuff out, forbidden for being “too advanced”. Silly. You’re a professional software developer, do your job.
Re: The worst kind of programmer
#43They 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.
Testing is all you need to produce bug-free software.
Re: The worst kind of programmer
#44He's someone who has almost 2 years of work experience before he got his degree, meaning he worked and studied simultaneously. Because he works remotely he doesn't stop at 8 hours, I caught him working on an issue at 11 p.m. on a Wednesday night, with a Friday deadline (I know because he told me). When I told him to stop doing that cause he will drive himself to burnout he promptly ignored me, claiming that ThePrimeagen and all talented influencers endorse such behavior because it's fine to invest in your career early on.
He's only chasing big firms, and wants to hit senior status before 25. He writes internal company tools in Rust, again because the internet influencers say Rust is cool, and not because there are people in the company who know Rust and can maintain it once he leaves the company (which will happen soon because again, he told me so). He thinks that people should get on his level, and that he shouldn't adapt his work to others, and jokingly threw a "people think I'm hard to work with" remark. He had a job interview where he explicitly asked if they reward high performers who work outside of working hours.
His social media profile is pristine. He keeps a blog that writes for his small side-projects or because he discovered how StringBuilder works and has to analyze it. It doesn't matter if a developer would read it, what matters is the recruiters seeing him grinding.
Before you think "this doesn't affect you in any way" let me clarify: Next time someone asks if you have plans to get married or have a kid, this is the person they actually look for. This is why ageism is a thing. It's not because you're old it's because being young you can afford to not work-life balance. I know that because I'm 40 years old and while I'm not in a life situation where I care about work-life balance I'm implicitly placed in the "this guy gets married soon and has a life" bucket by everyone, even if I explicitly tell them I'm a career-focused guy.
It's the stereotyping based on assumptions which are in turn based on societal expectations that really gets me mad. I'm not experienced enough to make claims like OP does "people like him are detrimental to the team", however since this is capitalism and it rewards what managers think should be rewarded then it's clear which behaviors one must adapt in order to bring food to their plate. Worst or best? It is what it is.
Re: The worst kind of programmer
#45Yeah. 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…
I have no love for Haskell or functional programming, but the problem here isn't FP per se, it's that they tried to jam it into Java.
Don't fight the language or framework. If you are using Java, write idiomatic OOP code. If you want to write FP on the JVM, then start writing Clojure or Scala. If the business won't let you write Clojure or Scala, then do it on your own time and/or change jobs.
Re: The worst kind of programmer
#46> 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…
Re: The worst kind of programmer
#47This 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“?
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.
Re: The worst kind of programmer
#48> 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
#49> 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 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.
Re: The worst kind of programmer
#50> 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.
Both languages are becoming far more mainstream, but they are still in the realms of people wanting to play with 'new' languages.
The correct answer is to choose a language that is maintainable by most engineers you have, and if you need something else for technical reasons, hire the new engineers first - never impose a new language on engineers without very good reason, and definitely not because "It's simple".
It's often not the language that's the problem, but all of the 'clever' ways the 'clever' devs use it.