A few years ago I was in a hiring loop where four interviewers grilled me on a number of subjects, including algorithms and data structures. They asked me all sorts of trivia questions on assimptotic complexity of this and that algorithm, how to implement this and that, how to traverse stuff, etc. As luck would have it, I was hired. I spent a few years working for that company and not a single time did I ever implemented a data structure at all or wrote any sort of iterator. Not once.

I did spend months writing stuff in an internal wiki.

I can't help but feel that those bullshit leetcode data structures computational complexity trivia are just a convoluted form of ladder-pulling.

From the article:

"To spell it out why this conference generated fake women speakers," Orosz alleges, it was "because the organizer wants big names and it probably seemed like an easy way to address their diversity concerns. Incredibly lazy."

How hard is it for these organizers to actually reach out to women developers and extend an invite to talk about any topic they are interested in? In the very least, there are tons of high-profile bloggers who are vocal about things and stuff. Even though women are severely outnumbered, you almost need to go way out of your way to avoid actually extending an invite to a woman in the field.

Eduards Sizovs, the DevTernity organizer accused of making up fake female speakers, felt it was the right PR move to post this message on Twitter:

https://twitter.com/eduardsi/status/1728447955122921745

So I've been called out (and canceled?) by listing a person on my conference's website (who never actually made it to the final program). JUST A RANDOM PERSON ON THE CONFERENCE WEBSITE canceled all the good work I've been doing for 15+ years. All focus on that.

I said it was a mistake, a bug that turned out to be a feature. I even fixed that on my website! We're cool? Nooooo, we want blood! Let's cancel this SINNER!

The amount of hate and lynching I keep receiving is as if I would have scammed or killed someone. But I won't defend myself because I don't feel guilty. I did nothing terrible that I need to apologize for. The conference has always delivered on its promise. It's an awesome, inclusive, event. And yes, I like Uncle Bob's talks. They're damn good.

When the mob comes for you, you're alone. So, let it be. I'll keep doing a great conference. With all speakers, half the speakers, or I'll be speaking alone on all tracks and lose my voice. But the event will be a blast. Like always. I'll die while doing great work. But the mob won't kill me.

I don't think that tone-deaf is the right word for this.

Elon Musk buying it.

Holy hell, you went for the jugular.

Java gets a bad reputation from proponents of FOMO/fad-driven development, but the whole Java ecosystem was built for the web. Anyone is hard-pressed to find a better tech stack than Java-based frameworks without resorting to hand waving and passing personal opinions as facts.

I love C# and the whole .NET Core ecosystem, but even I have to admit it's very hard to argue against java.

but I don’t understand why they don’t self-host

Why would anyone self-host a FLOSS project? Trade secrets is not a concern, nor is it barring access to the source code repository. Why would anyone waste their resources managing a service that adds no value beyond a third-party service like GitHub?

Also, double can and does in fact represent integers exactly.

But in my humble opinion, those projects shouldn’t really exist.

What's the point of your opinion if not only do these projects exist but they are also pervasive?

You cannot wish things away and pretend reality is something different.

I think my interview/offer ratio is somewhere below 1%.

Keep your spirits up, and be mindful that there are tons of job adverts out there that don't actually have a real job position to fill, and are only used by recruiters and consulting companies to harvest CVs and meet their internal quotas. 1% sounds about right

I've been working with Agile for years and I worked with people who burned out, but there was not even a single case where Agile contributed to burning out, directly or indirectly. In fact, Agile contributed to unload pressure off developers and prevent people from overworking and burning out.

The main factors in burning out we're always time ranges from the enforcement of unrealistic schedules and poor managerial/team culture. It's not Agile's fault that your manager wants a feature out in half the time while looming dismissals over your head.

It's not Agile's fault that stack ranking developers results in hostile team environments where team members don't help out people and even go as far as putting roadblocks elsewhere so that they aren't the ones in the critical path. Agile explicitly provides the tools to make each one of these burnout-inducing scenarios as non-issues.

The biggest news to me is that GitHub allows users to search code. Every single time I tried to search something in GitHub, search results were next to completely useless, and always a sure-fire waste of time and effort.

There's hope, I guess.

your 2 decades of experience mean much more than memorizing algorithms, you know how to produce real value

That's all fine and dandy but the HR recruiter that can't tell apart git from grunt needs to cross boxes in the skills assessment section, and if you don't ace coding challenges you are as good as dead to them.

Why do so many programs use rational databases instead of loading the data during startup and keeping it in memory?

I presume you're referring to relational databases instead of rational.

The responsibility of a RDBMS is to implement a set of performance-focused data structures that help clients reliably get the data that they need in the fastest possible way, without having to reinvent the wheel.

More often than not, this data does not fit in the heap.

Also, in many usecases there is more than a single client.

Hope this helps.

Python is only good for short programs

Was Python designed with enterprise applications in mind?

It sounds like some developers have a Python hammer and they can only envision using that hammer to drive any kind of nail, no matter how poorly.

HTML is bad. The language itself feels unintuitive and is clunky compared to modern markdown languages, and let’s be honest, your webpage just consists of nested <div> tags.

My websites do not consist of nested divs. Your webpages might just consist of nested divs, but only if you are clueless about what you're doing and are oblivious to basic stuff like accessibility support.

CSS is bad. Who knew styling can be so unintuitive and unmanageable? Maybe it made sense 25 years ago, but now it’s just terrible. It’s very clunkily integrated with HTML too in my opinion.

Being unmanageable is the output of the developer team, not the languages they use. Decoupling Presentation from the data and semantics never ceases to make sense. CSS has many issues but the way its integrated with HTML is certainly not one of them.

Frankly, you sound like you blame your tools a lot.</div>

A less confusing title would be “Mozilla drops support for Mercurial (...)

It's not even about GitHub at all. Taken straight out of the announcement:

“For a long time Firefox Desktop development has supported both Mercurial and Git users. This dual SCM requirement places a significant burden on teams which are already stretched thin in parts. We have made the decision to move Firefox development to Git.”

Was this thing generated by a poorly trained LLM?

These small proof of concept projects just go to show how fundamentally important are projects such as GCC and LLVM, which considerably lowered the barrier to entry of monumental tasks such as developing a programming language that targets basically all platforms under the sun.

Kudos GCC and LLVM.

Objective-C and Objective-C++ are an abomination. Extending languages with other language constructs is ok, I guess, but I find Apple's extremely poor documentation to worsen a situation that's already quite bad.

If GitHub changes terms of use to pay for basic stuff, or starts breaking compatibility or adding egregious bugs, I would start looking for alternatives.

A while ago I had all my personal projects on GitLab. I was a GitLab fanboy and advocated it everywhere to the point I convinced the project manager of a previous job to migrate the team's projects to it and pay for GitLab ultimate. Without going into details, that goodwill ended the moment I stumbled upon a regression introduced by GitLab which affected my personal projects, and their customer support essentially said the issue was won't fix but it was fixed in premium customers. I simply unblocked myself by moving all projects to GitHub, disabled GitLab CICD and shut down my GitLab runners, and onboarded onto a mix of GitHub Actions and CircleCI. I could still stick with GitLab, but why bother?

I would do the same to GitHub if I experienced anything remotely similar.

Duplicate code can be a code smell, but it's far better to have the same function definition or code block appear twice in the code than extracting a function that tightly couples two components that should not be coupled at all.

See Write Everything Twice (WET) principle.

Because Microsoft will eat your ass in your sleep

So Microsoft has access to Firefox's source code. So what? Isn't the point of a FLOSS project that your source code should be made available to everyone?

I get it that the project isn't getting work done on features, but it bothers me how the author tried to criticize basic code quality improvements such as fixing typos. I don't know if the author is an active contributor to the project, but I think he shouldn't really be criticizing the ones that actually contribute, wether their contributions are big or small.

On all the agile projects I’ve worked on, the teams have been very reluctant to make a specification in place before starting development.

I don't think this is an Agile thing, at all. I mean, look at what Agile's main trait: multiple iterations with acceptance testing and product&design reviews. At each iteration there is planning. At each planning session you review/create tickets tracking goals and tasks. This makes it abundantly clear that Agile is based in your ability to plan for the long term but break/adapt progress into multiple short-term plans.

I think there's context missing from that story. Diagrams do not trigger disgust. At best, making superfluous and time-wasting demands in the context of trivial tasks that add nothing of value and achieve nothing but wasting time and adding overhead can often lead managers to frown upon them.

${CORPORATION} has profited off of Redis without giving much back (...)

I don't understand this blend of comment.

If you purposely release your work as something anyone in the world is free to use and change to adapt to their own personal needs without any expectation of retribution or compensation, why are you complaining that people are using your work without any retribution or compensation?

More to the point, why are you singling out specific adopters while leaving out the bulk of your community?

It makes absolutely no sense at all.

Ok.

Having fun when programming should be much more important than having correct or fast code (...)

That's only remotely reasonable if you're a weekend warrior that messes with coding as a pastime. Even so, I'm not sure what fun you can extract from dealing with slow, broken code.

The optimization I'm the most proud about was when I worked on a legacy project whose end-to-end builds took around 1 hour. After spending some time working on its architecture, project layout and build system, I managed to get the full end-to-end builds to take 10 minutes, and incremental builds to be almost instant.

What makes me the most proud about this project is that the technical debt plaguing the legacy project was directly and indirectly the reason why half a dozen of my team members burned out and quit the company. After that point my remaining team members started to be far less stressed and team velocity skyrocketed, just for the fact that the thought of iterating over a bugfix and posting a pull request didn't cost at least one hour, and sometimes two or three.

I would think you would try to perfect what you have instead of making new ones all the time.

Perfecting what you have often leads to a completely different language. See C vs C with classes which ended up being C++.

There is absolutely no problem with creating new languages. These are often designed with specific features in mind, and the success cases often offer features that are in high demand. Take for instance node.js, and how its event loop makes it a near ideal language for network-heavy applications that run on a single thread.

There would be no other incentive for companies to buy it.

A company might want to extend it's service offering with a build pipeline/CICD system, and buying GitLab would get them the best-in-class service.

Microsoft bought GitHub for much of the same reasons, and GitHub didn't went to hell after the acquisition.

but if it’s not readable it’s garbage.

Readability is often in the eye of the beholder, but knowing that a component implements a design pattern is all you need to know how it's used without even having to peek at the code.

I think the most vocal critics of design patterns are those who are clueless about design patterns, and they are criticising their use just because they are scared of stuff they don't know.

If anything, I thing Stack Overflow replaced Usenet as the source of informal technical advise.

Never heard of Experts Exchange beyond the jokes.

We have a client which is MAD cause the project is riddled with bugs, but the solution somehow is paying more attention. Except that it clearly isn’t feasible to pay more attention when you have to check, recheck and check again the same thing over and over…

By definition, automated testing means paying more attention, and doing it so well that the process is automated.

They say it’s a waste cause you can’t catch UI (...)

Show them a working test that's catching UI bugs. It's hard to argue against facts.

but they somehow think they are smarter than google or any other small or big company that do write test

Don't sell a solution because others are doing it. Sell a solution because it's a solution to the problem they are experiencing, and it's in their best interests to solve it. Appeals to authority don't work on everyone.

I don’t think it’s a stupid thing to want to have code in the kernel, especially after spending all my time debugging this issue.

The way that you jumped straight onto broadcasting drama when your very first Linux kernel patch stumbled on the code review stage is a major red flag.

I would hate to work with you because I would feel that I would be risking being subjected to a very public character attack each time I had to review one of your patches.

From the article:

(...) but recently, another type of criticism seems to be on the rise.

The code that I suggest is too verbose. It involves too much typing.

This reads like a one-sentence strawman. Describing code as "too verbose" is really not about the risk of carpal tunnel syndrome. It's about readability and cognitive load.

The blogger seems to almost get the point when he writes the following:

In short, the purpose of source code is to communicate the workings of a piece of software to the next programmer who comes along. This could easily include your future self.

The purpose of source code is to communicate (...) to the next programmer who comes along.

If you make the mistake of going the "enterprise quality java code" meme approach, you're making the next programmer's life needlessly harder.

The blogger then tries to make his case with verbose code, and makes the following statement:

Which alternative is better? The short version is eight lines of code, including the curly brackets. The longer version is 78 lines of code. That's ten times as much.

I prefer the longer version. While it takes longer to type, it comes with several benefits. (...)

This is yet another strawman. The longer version is awful code, not because it's longer but because it's needlessly jam-packed of boilerplate code. Ignorign basic things like interfaces and contracts, It's been proven already that bugs in code are directly proportional to the number of lines of code, and thus the code the author prefers is likely to pack ten times more bugs.

The shorter code in this case would not be the 78-loc mess that the author picked as the thing he prefers. The shorter code in this case would be something like onboarding the project onto Project Lombok to handle all-args constructors, property methods, and even throw a builder in for free. This requires onboarding Lombok to the project, and add two annotations to the short example. Two lines of code, done.

After the blogger fails to make his case, he doubles down on the typing non-sequitur:

Perhaps you're now convinced that typing speed may not be the bottleneck (...)

This is a blog post that fails to justify a click. It's in the territory of "not even wrong".

(proceeds to cry and click on "subscribe")

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.

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.

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.