5 ms·

In the future your boss will assign work by auctioning JIRA tickets off to the team with a price ceiling set by freelancers on the LinkedIn marketplace. Payment

by DC1350 6y ago

In the future your boss will assign work by auctioning JIRA tickets off to the team with a price ceiling set by freelancers on the LinkedIn marketplace. Payment will be through a bounty system. Salary is such an outdated payment structure

biohax2015 6y ago
That sounds awful.
- loceng 6y ago
  Why?
  - codewithcheese 6y ago
    https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law
the_snooze 6y ago
That's a great incentive structure to build unmaintainable systems.
rank0 6y ago
I can't tell if this is a joke or not. Sounds like an easy way to develop horrible documentation-free, semi-functional systems. The future is gonna be filled with disinterested one time contractors and employers who fraudulently refuse bounty payout.
vincentmarle 6y ago
You may be joking, but this is already how my team has been operating for the past 6 months. Theoretically it sounds great, because you can scale up or down your engineering needs just like you scale anything on the cloud. Have 100 Github issues to fix this week? Scale up to 20 freelance devs for a week and get it done. Practically, it doesn't work. We're going to go back to hiring full-time engineers again.
- thebiglebrewski 6y ago
  Why doesn't it work? Genuinely curious!
  - marcinzm 6y ago
    I'd guess because: * It takes months for an engineer to be properly ramped up on a new codebase and even longer for business domain expertise. Until then they might actually be negatively productive due to onboarding questions other devs must answer. * Enforcing any coding standards is difficult so you get a lot of technical debt over time. edit: Also, a good engineer on a well functioning team will push back on bad or inefficient feature requirements. If you're just getting paid by feature and feel no ownership of the product then you have little incentive to do that.
    - bitbuilder 6y ago
      I'd add to that, team dynamics can't be discounted. Feeling part of a team is good for morale, and in turn productivity. People tend to produce better work, on a faster timeline, when the respect of their teammates is on the line. Also, with any given team and codebase, team members will tend to carve out unofficial roles that best fit their abilities. This of course increases the net productivity of the team.
  - easton 6y ago
    You'd run into Brooks's law pretty quickly, that is, "adding manpower to a late software project makes it later", since you have to spend a bunch of the current engineers' time to get the new people up to speed. Especially for one issue, which maybe doesn't require a lot of domain knowledge, but being neck deep you sometimes can't estimate that properly. https://en.wikipedia.org/wiki/Brooks%27s_law https://en.wikipedia.org/wiki/Brooks%27s_law
adolph 6y ago
I've been thinking about this, only using Etherium contracts.
z0xz0xz0x 6y ago
Oh god. I really hope this is not the case or I would stop working in this profession

by DC1350 6y ago

biohax2015 6y ago

That sounds awful.

loceng 6y ago
Why?
- codewithcheese 6y ago
  https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law

the_snooze 6y ago

That's a great incentive structure to build unmaintainable systems.

rank0 6y ago

I can't tell if this is a joke or not. Sounds like an easy way to develop horrible documentation-free, semi-functional systems. The future is gonna be filled with disinterested one time contractors and employers who fraudulently refuse bounty payout.

vincentmarle 6y ago

You may be joking, but this is already how my team has been operating for the past 6 months. Theoretically it sounds great, because you can scale up or down your engineering needs just like you scale anything on the cloud. Have 100 Github issues to fix this week? Scale up to 20 freelance devs for a week and get it done. Practically, it doesn't work. We're going to go back to hiring full-time engineers again.

thebiglebrewski 6y ago
Why doesn't it work? Genuinely curious!
- marcinzm 6y ago
  I'd guess because: * It takes months for an engineer to be properly ramped up on a new codebase and even longer for business domain expertise. Until then they might actually be negatively productive due to onboarding questions other devs must answer. * Enforcing any coding standards is difficult so you get a lot of technical debt over time. edit: Also, a good engineer on a well functioning team will push back on bad or inefficient feature requirements. If you're just getting paid by feature and feel no ownership of the product then you have little incentive to do that.
  - bitbuilder 6y ago
    I'd add to that, team dynamics can't be discounted. Feeling part of a team is good for morale, and in turn productivity. People tend to produce better work, on a faster timeline, when the respect of their teammates is on the line. Also, with any given team and codebase, team members will tend to carve out unofficial roles that best fit their abilities. This of course increases the net productivity of the team.
- easton 6y ago
  You'd run into Brooks's law pretty quickly, that is, "adding manpower to a late software project makes it later", since you have to spend a bunch of the current engineers' time to get the new people up to speed. Especially for one issue, which maybe doesn't require a lot of domain knowledge, but being neck deep you sometimes can't estimate that properly. https://en.wikipedia.org/wiki/Brooks%27s_law https://en.wikipedia.org/wiki/Brooks%27s_law

adolph 6y ago

I've been thinking about this, only using Etherium contracts.

z0xz0xz0x 6y ago

Oh god. I really hope this is not the case or I would stop working in this profession