Hacker News Reader

> it does mean that it's quite hard to fire an underperforming dev, because how the hell do you prove they're underperforming? What metric do you use?

I think your criticism of 'at-will' employment is unfounded in this scenario. Having lower guardrails on employment means it's not as pressing to figure out performance metrics. If the company narrative is that an employee is helpful to the mission, then there isn't much cause to fret for a more perfect metric. And at-will means you can test more employees before committing to a few for longer than a couple years.

I didn't express any direct or detailed criticism of at-will in my comment, just my gladness that we don't have it.

Why, despite the difficulties it causes me when dealing with poor performing devs, am I happy we don't have at-will?

Because at-will dramatically distorts the employer - employee social contract in favour of the employer. And employers already have a disparately large amount of power over their employees as it is. So there you go, that's my criticism of at-will employment. It puts the well being of the employer ahead of the well being of the employee.

You can have a trial period without "at-will".

Gladness you don't have it is criticism you're trying to hide behind semantics.

You and I seem to have different ideas of an employment social contract (or non-existence of one). Unless you're interested to dig into that difference, I don't think we have anywhere else to go with this thread.

Gladness: "I'm glad i don't have a million dollars to manage in my bank account, just getting the best from my small savings is stressing me out!"

Thankfully: "My bank account (thankfully) lacks a Bill Gates' sized stash of greenbacks, it does mean that it's impossible to buy a mansion though"

I'm not criticising the concept of a million dollars in either of these statements. Thankfully, as used in the original context means something quite different to the meaning you've derived.

I might still actually have a bone fide criticism of a million dollars, but that's neither here nor there in the context of either statement.

I think wrapping it up's a fair shout though so no hard feelings and all the best.

At will doesn't mean you can test out more employees. It means you don't have to pay anyone any pay when you let them go.

It has side-effects. A worker will bolt at the first better opportunity or when your company looks like they are in trouble because they have to. It also raises wages as people changes jobs more often.

> I think your criticism of 'at-will' employment

There was no criticism of at-will employment in the parent post.

That's a hair trigger you've got yourself there fella.

> In my country, which (thankfully) lacks America's "at-will" employment contract

I'm sorry, is that not obviously criticism? My parser must be busted again.

Looks like it is criticism of America's "at-will" labor laws to me too.

No, it's not. Which is why I made my post.

Ah, noted. Thanks for the education.

I don't think my concern with the issue at end is much more related to automation and wages than it is related to the "engineering" side of things.

Most of what the "literature" recommends is based on individual lessons learned and ideas, that are indeed backed less by data than they are by anecdote.

Having that is better than nothing. But if you compare software "engineering" when talking about software architecture, to construction, electrical or such, it's puzzling indeed to see how much more craft and less actual science is involved.

There are metrics that seem to apply though. Lines of codes and bugs aren't good indeed. Cyclomatic complexity is more related to algorithmic than architecture (which if going that direction is very much a science).

Measuring architecture effectiveness is measuring how much the architecture achieves its goals. These are contextual, most commonly in business they will be related to things like quality (as in, the software does what it is supposed to), total cost, time of execution. Some goals you can derive from that are adaptability to change, ability to modify and extend, which you might derive in turn into qualities such as decouple-ness, non redundancy of code, readability, etc. Some metrics for these exist, such as the instability (fan-in / fan-out ratio) or the abstractness measure of packages.

I don't know of architecture books that present patterns or practices with this sort of justification though. There's a chapter on that in Clean Architecture, but most of the rest is only strongly worded opinion.

Of course it can be quantified otherwise hiring based on skill level for a software role would be impossible. You can look a examples of code and know someone's level and then deduce their performance based on output and quality of code. The problem is NON-technical people are the ones who want to quantify your performance! Which has been my problem for years in the software industry. If you haven't written code in years, you will be lost as to whether I'm writing good software or not, yet these are the people who rise to the top to manage the technical people and then do a horrible job because they have no idea what to optimize for.

The standard practice is to quiz based on algorithms and data structures. How is that quantifying anybody’s performance? I knew a smart young algorithms guy once who could solve anything, but he still liked storing all his data in the global scope until he was told to stop it.

Yeah now that I think more about it, those quick tests say nothing about a candidate. It's definitely harder than it seems.