[-] lysdexic@programming.dev 12 points 1 week ago

Is it really unethical if it benefits the organization? Even if that’s not really the goal.

The blogger acknowledge that the use of the word "unethical" as a hyperbole ton drive engagement.

The real-world issue is that we need to get stakeholders on board with the idea of having to do extra work that is not required to deliver a feature. If you tell a manager that you need to spend a month rewriting a system that was just launched, they will laugh at you.

[-] lysdexic@programming.dev 12 points 2 years ago

In the 2010s, the mindset at tech giants seemed to be that they had to hire the best developers and do everything they could to keep them.

Not really. The mindset was actually to hire skilled developers just to dry up the market, so that their competitors would not have skilled labour to develop their own competing products and services.

Then the economy started to take a turn for the worse, and these same companies noted that not only they could not afford blocking their competitors from hiring people but also neither did their competitors. Twice the reasons to shed headcount.

It was not a coincidence that we saw all FANGs shed people at around the same time.

[-] lysdexic@programming.dev 12 points 2 years ago

Imagine running Guido out of his own fucking project

Imagine running Guido out of Python and still have the gall to argue they are acting on Python's best interests.

What a bunch of self-serving fools.

[-] lysdexic@programming.dev 11 points 2 years ago

I don't think it makes any sense to mention source hut because none of the features you mentioned are killer features (or relevant. Why should I care about implementation details of feature tracking?) and it completely fails to address GitLab's main value proposition: it's CICD system.

Anyone can put up any ticketing system. They are a dime a dozen. Some version control systems even ship with their own. CICD is a whole different ballgame. It's very hard to put together a CICD system that's easy to manage and has a great developer experience. Not even GitHub managed to pull that off. GitLab is perhaps the only one who pulled this off. A yams file with a dozen or so lines is all it takes to get a pipeline that builds, tests, and delivers packages, and it's easy to read and understand what happens. On top of that, it's trivial to add your own task runners hosted anywhere in the world, in any way you'd like. GitLab basically solved this problem. That's why people use it.

11
1
10
8
10
12
1
Well, it's just an AWS Account ID! (mail.cloudsecurity.club)
22
8
std::try_cast and (const&&)=delete (quuxplusone.github.io)
15
1
6
[-] lysdexic@programming.dev 12 points 2 years ago

It’s a way of saying “these are wrong and should be deprecated.”

They aren't wrong. No one in their right mind just throws away years of work delivering a stable production project just because a random clueless person in the internet said something. It's lunacy.

[-] lysdexic@programming.dev 11 points 2 years ago

You don’t need any of it, relevant experience is worth in the region of 5x-10x for every hiring manager I’ve known, and for myself.

The only time I had to brush up on data structures and algorithms is when I apply to job ads, and recruiters put up bullshit ladder-pulling trivia questions to pass to the next stage of a recruiting process. It's astonishing how the usefulness of a whole body of knowledge is to feed gatekeepers with trivia questions.

[-] lysdexic@programming.dev 12 points 2 years ago* (last edited 2 years ago)

no. I’m sick of cicd pollution in my project dir.

This is about configuring the version control system you use to track your software. It has absolutely no relation with CICD systems.

All that shit needs to go under hidden folders.

On unix-like platforms, dot files are interpreted as hidden files. By design, .gitattributes is already hidden.

[-] lysdexic@programming.dev 12 points 2 years ago

Also worth mentioning, Ubuntu 23.10 already ships with .NET 8.

https://packages.ubuntu.com/mantic/dotnet8

[-] lysdexic@programming.dev 11 points 2 years ago

This article seems to be well-meaning but contrasts with the de-facto standard way of storing dotfiles. The Linux Filesystem Hierarchy Standard is quite unambiguous in how it specifies that the purpose of $HOME is to store dotfiles.

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s08.html

FHS also specifies that applications can store their dotfiles in subdirectories, and this is leveraged by other standards like the Freedesktop's xdg-user-dirs spec to default to ~/.config

https://www.freedesktop.org/wiki/Software/xdg-user-dirs/

I'm not sure what's the point of arguing against the standard way of storing dotfiles while basing the remarks on no standard or reference.

[-] lysdexic@programming.dev 12 points 2 years ago* (last edited 2 years ago)

Whew, here I was thinking it might be cool to try to contribute to some project, maybe even Linux! This thread shall serve as my reminder to never do that because that’s for god-tier emotionless techbros only.

I've stumbled upon this blog post first in HackerNews, and the comments there make it quite clear that, even though it wouldn't hurt to give more credit than merely reporting a bug, the author's submission was flawed and subpar, and the rewrite that went in was undoubtedly better in every way.

I don't think all this drama is waranted or justifiable. Also, if the first whiff of adversity bothers you and any feedback in a PR other than enthusiastic praise leaves you with a sour taste then collaborative work might not be for you, both as a participant and as someoje that everyone else has to endure.

[-] lysdexic@programming.dev 12 points 2 years ago* (last edited 2 years ago)

My workplace has the opposite problem.

I don't see that as a problem. The job description of an engineer includes dealing with new problems and onboarding onto new things. So you never wrote a parser and now you have to. That's ok, just go ahead and start from the ground up.

What I perceive as a major problem is the utter disconnect between what companies test for, and what companies actually do.

It makes no sense at all to evaluate candidates on obscure trivia questions no one will ever care about or use, let alone reject an applicant because they mixed up O(nlogn) with O(logn). It matters more if you know a good, healthy answer to tabs vs spaces.

I once was a part of an hiring loop where we assessed a candidate, and one other fellow assesser wanted outright to reject the candidate because he failed to answer one of his questions on data structures. Everyone in the meeting voted in favour of that hire, except that one guy. When we asked to reconsider his position, he threw a tantrum because he felt that it was a matter of principle that we had to not hire a candidate that didn't knew trivia. The hiring manager asked if that info was important, and in case he felt it was whether it could be looked up online in a matter of minutes, but the assesser tried to argue that it was besides the point.

Data structures and algorithms trivia feels like ladder pulling.

[-] lysdexic@programming.dev 12 points 3 years ago

(proceeds to cry and click on "subscribe")

view more: ‹ prev next ›

lysdexic

0 post score
0 comment score
joined 3 years ago
MODERATOR OF