This is about thew new starter cost.

When a developer joins a team, they will not be as productive as they have to learn the code, frameworks, libraries, the project purpose, the tooling, etc… Often this impacts other members of the team lowering the entire teams productivity.

When you use productivity tracking (e.g. things like capacity planning) you will see the teams performance drop and it will take time for it to exceed the previous measured performance. This is the cost of adding a new starter.

So if it takes 6 weeks for a new starter to increase overall team producitivty then planning someone on a project for 4 weeks is pointless since the team will have a higher delivery rate without the extra person. This is typically why an organsation loses its ability to migrate staff between projects.

Code formating affects the layout of the code and our brains do all sorts of tricks around pattern recognition, so if your code formatting rules are too different a someone migrating between projects has to spend time looking for code and retraining their brain.

Its an additional barrier and a one within an organisations skills to remove (by forcing a common code standard).

The last part is why you use an IDE.

Several of them will ingest prettier files to build code formatting rules

• https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode
• https://www.jetbrains.com/help/webstorm/prettier.html
• https://marketplace.eclipse.org/content/prettier-formatter

IDE support is normally a good way to work out what the wider community is using.

Python is unique in formatting forms part of the syntax, every language has linters but its far more common for orgs to tweak the default rules .

For example Java has Checkstyle. The default rules ‘sun checks’ give a line length of 80, tabs are 4 spaces and everything is placed on a new line.

Junior devs inevitably want to trash the line length (honestly on 1080p monitors, 120 makes sense,).

There is always a new line/same line discussion (everyone perfers same line but there is always one die hard new line person).

The tab width discussion always has one junior dev complain that “tabs are better”, as someone who started development on Visual Studio 6 where half the team double spaced, the other half used tabs. Those people get a lecture from me on how we can convert tabs to spaces but not the inverse so it will always be spaces if I am near.

With Checkstyle you upload the rule file as an artifact into your M2 repository. Then you can pull it down as a dependency when the checkstyle plugin runs.

I avoid any company that requires a software test before the interview.

I worked for a company that introduced them after I joined, I collected evidence all of the companies top performers wouldn’t have joined since we all had multiple offers and having to do the test would put people off applying. The scores from it didn’t correlate with interview results so it was being ignored by everyone. Still took 2 years to get rid of it.

The best place used STAR (Situation Task Action Result) based interviews. The goal was to ask questions until you got 2 stars.

I thought these were great because it was more varied and conversational but there was a comparable consistency accross interviewers.

You would inevitably get references to past work and you switch to asking a few questions about that. Since it was around a situation you would get more complete technical explanations (e.g. on that project I wrote an X and Y was really challenging because of Z).

I loved asking “Tell me about something your really proud off”. Even a nervous junior would start opening up after that question.

After an hour interview you would end up with enough information you could compare them against the company gradings (junior, senior, etc…).

This was important because it changed the attitude of the interview. It wasn’t a case of if the candidate would be a good senior dev for project X, but an assessment of the candidate. If they came out as a lead and we had a lead role, lets offer them that.

Nvidia drivers don’t tend to be as performant under linux.

With AMD instead of using the AMD VLK driver, you would use the RADV (developed largely by valve). Which petforms better.

Every AMD card under linux supports OpenCL (the driver is more based on graphics card architecture) and you install it very easily. Googling it with windows found pages of errors and missing support.

Blender supports OpenCL. I bet the 2x improvement is Blender being able to ofload rendering to the AMD graphics card.

Also this represents the biggest headache in Linux, lots of gamers insist they can only use Nvidia cards. Nvidia treats linux as an afterthought as best or deliberately sabotages things at worse.

AMD embraced open source and so Linux land is much nicer on AMD (and to a less extent Intel).

The results here will probably be a DxVK quirk, lots of “Nvidia optimised” games have game engines doing weird things and the Nvidia driver compensates. DxVK has been identifying that to produce “good” vulkan calls.

If its for work I would suggest picking a “stable” distribution like Debian, Kubuntu or OpenSuse.

A lot of people recommend Arch or Fedora but the focus of those is getting the very latest releases, which increases your chance of stuff breaking.

A lot of people will suggest niche distributions, those can be great for specific needs but generally you will always find Debian/Ubuntu/RHEL support for commercial apps.

I would also suggest looking at the KDE Desktop, many distributions default to Gnome but it is unique in how it works, KDE (or XFCE) will provide a desktop similar to Windows 11.

Lastly I would suggest looking at Crossover Linux by Codeweavers.

Linux has something called WINE, its an attempt to implement the Windows 95 - 11 API’s so windows applications can run on linux.

WINE is how the Steam Deck/Linux is able to play Windows games. Valve embedded it into Steam and called it “Proton”.

WINE is primarily developed by Codeweavers and they provide the Crossover application that makes setting up and running a Windows application really easy.

People will mention Lutris but that has a far higher learning curve.

There is an application database so you can see in advance if your applications would work: https://appdb.winehq.org/

Natural scrolling is the first thing I disable when forced to use a Mac, windows, gnome, kde, xfce, etc… all scroll in one direction.

Macos has a unique keyboard and a lot of unique non obvious and non discoverable behaviour. For example I use a lot of windows laptops, left and right click involve pushing the trackpad downon the left or right. Someone had to show me right click on a Macbook was a two finger touch. These deliberate non standard behaviours make switching devices really annoying.

I would argue KDE defaults should follow the most common behaviour across multiple platforms, with the option to implement specific quirks.

The move to default double click brings the KDE default into alignment with other platforms (single click isn’t the default anywhere else).

I would suggest a bigsur global theme that implements macos keyboard shortcuts, mouse actions, etc… would be a better compromise.

@ergoplato I didn’t suggest that.

Personally I don’t think its ego. I think you have two issues.

The first is people go through stages learning DevOps. Stage 1 has people deploy a CI because its cool, they build a few basic pipelines and then 90% of people get bored. The 2nd stage is people start extending those pipelines, it results in really complex pipelines requiring lots of unique changes based on the opinion of the writer. You move to the 3rd stage when your asked to recreate/extend for a new project and realise how specific your solutions are.

Learning how to make minor tweaks and hook in a few key points to get what you want takes years. Without that most packagers will want to make big changes upstream which won’t go down well.

The second issue, I have met quite a few developers who become highly stressed when the build system is doing something they haven’t needed to do or understand.

A really simple example I have a Jenkins function which I tend to slip into release pipelines, it captures the release version and creates a version in Jira.

I normally deploy it first as a test before a few other functions to automate various service management requirements.

Its surprising how many devs will suddenly decide every problem (test failed, code failed review, sharepoint breaks, bad os update, etc…) is due to that function.

For me this little function is a test, if the team don’t care I will work to integrate various bits. If they freak out, I’ll revert decide if it is worth walking them through the process or walk away.

One of the reasons for the #DevOps movement is developers see building and packaging as #notmyjob.

The task would historically fall on the most junior member of the team, who would make a pigs ear out of it due to complete lack of experience.

This is compounded by the issue that most C/C++ build systems don’t really include dependency management.

Linux distributions have all tried to work out those dependency trees but they came up with slightly different solutions. This is why there are a few “root” distributions everything branches from.

That means developers have to learn about a few root distributions to design a deb/rpm/aur package systems to base their release around.

That is a considerable amount of learning in a subject most aren’t interested in.

The real question is why don’t package maintainers upstream a packaging solution?

You’ve just moved the packaging problem from distributions to app developers.

The reason you have issues is historically app developers weren’t interested in packaging their application so distributions would figure it out.

If app developers want to package deb, rpm, etc… packages it would also solve the problem.