5 ms·

> All I see is yet another reasonably sounding yet unsupported piece of folklore. Another artefact of the fact that software developers are still craftspeople

> All I see is yet another reasonably sounding yet unsupported piece of folklore. Another artefact of the fact that software developers are still craftspeople - as in "someone skilled at making things by hand". Software development output is something that no-one has yet successfully quantified. There's no easy metric to assess a non-productive software developer from a productive one. We can all tell the difference, but good luck measuring it. In my country, which (thankfully) lacks America's "at-will" employment contracts, 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? Bug rate is a bad one, because very smart people working in a new problem domain may register an significant uptick in bugs - doesn't mean that they're incompetent, it's just the result of doing new stuff in an unfamiliar domain in a highly complex environment. Lines of code? The less said about that metric and how gameable it is, the better. Us still being craftspeople is also why we can command such high wages relative to the rest of the economy - what we do is not yet automated, so we can still draw a premium.

noobiemcfoob 7y ago
> 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.
- CraigJPerry 7y ago
  > 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.
  - noobiemcfoob 7y ago
    > 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.
    - CraigJPerry 7y ago
      No, it's not. Which is why I made my post.
      - noobiemcfoob 7y ago
        Ah, noted. Thanks for the education.
    - geekone 7y ago
      Looks like it is criticism of America's "at-will" labor laws to me too.
- EdwardDiego 7y ago
  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".
  - noobiemcfoob 7y ago
    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.
    - CraigJPerry 7y ago
      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.
- wolco 7y ago
  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.
charles_f 7y ago
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.
proc0 7y ago
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.
- jammygit 7y ago
  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.
  - proc0 7y ago
    Yeah now that I think more about it, those quick tests say nothing about a candidate. It's definitely harder than it seems.

noobiemcfoob 7y ago

> 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.

CraigJPerry 7y ago
> 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.
- noobiemcfoob 7y ago
  > 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.
  - CraigJPerry 7y ago
    No, it's not. Which is why I made my post.
    - noobiemcfoob 7y ago
      Ah, noted. Thanks for the education.
  - geekone 7y ago
    Looks like it is criticism of America's "at-will" labor laws to me too.
EdwardDiego 7y ago
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".
- noobiemcfoob 7y ago
  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.
  - CraigJPerry 7y ago
    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.
wolco 7y ago
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.

charles_f 7y ago

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.

proc0 7y ago

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.

jammygit 7y ago
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.
- proc0 7y ago
  Yeah now that I think more about it, those quick tests say nothing about a candidate. It's definitely harder than it seems.