22 ms·

It's a race to the bottom. You could pay more for better work that gets done more slowly (fewer hours as people have families, etc,) or you could pay less for w

It's a race to the bottom. You could pay more for better work that gets done more slowly (fewer hours as people have families, etc,) or you could pay less for worse work that gets done more quickly. Well, iOS11 needs to ship on its annual schedule, non-negotiable. And the SVP will really complain if I ask for more money this quarter. So, cheap it is. If a bridge falls down, it's really obvious and people die. If billions of computers become vulnerable to malicious actors and a few hundred or thousand people suffer dramatic personal damages, well that's a nice and quiet problem which will be quickly forgotten in the 24-hour news cycle.

AnimalMuppet 9y ago
I'm one of the greyhairs. I won't work the insane hours, but I'll still get more done. How? By knowing what to write and how to write it, so I don't have to fumble around trying things for nearly as long. By not writing the bugs that the 20-somethings write, which means I don't have to take the time to try to fix them. By not creating the shoddy designs that other create, which then have to be fixed. By having an idea where to look when bugs do show up, so that they get fixed more quickly. And so on. It's about producing working code, not about how many hours my butt is in a seat...
- trevyn 9y ago
  >It's about producing working code I propose that working code is necessary, but not sufficient.
- exelius 9y ago
  I'm not attacking you here (and in fact I agree with you), but from a manager's perspective, I need one guy like you to design it in an architecture modeling tool and 8 young code monkeys to do all the boring work of building and testing it. You can do the code reviews to make sure they don't do stupid shit. The thought is that a team of greyhairs never ships anything, and a team of youngsters ships garbage. But it's better to ship garbage than nothing, hence the bias.
  - oceanghost 9y ago
    Can we just be honest? Us older folks won't build things we know doesn't work against synthetic deadlines, then work overtime to fix what we knew wasn't going to work in the first place, while taking the blame politically. Engineering has in my lifetime become "unwinnable." I'm either not "a team player" or "being negative" for planning for reasonable failure scenarios. Then politically I still take the heat when they happen. This is not a quixotic aspect of engineering, it is a design feature at bad employers. "Heads I win, tails you lose"
    - sidlls 9y ago
      Engineers aren't blameless, here. In fact they're at least as much the problem as "bad employers". Constantly seeking to use the latest shiny tech toy whether it's appropriate or not (e.g. "Big Data" tools to run stuff on a few GB of data) is a thing, especially in the Bay Area. It leads to a bunch of people with a small amount of shallow experience in a large number of soon-to-be-deprecated technologies. Few want to do the hard work of actual engineering. Also, that the product is 10% better/more stable/whatever frequently does not translate into even a 10% increase in sales. So it's not worth it (from the business' perspective) to invest in that quality. Pick some other arbitrary point (e.g. 20% better/20% boost in sales, etc.), right down to some threshold whereby the company simply doesn't even have a product that can be demonstrated.
      - user5994461 9y ago
        >>> Also, that the product is 10% better/more stable/whatever frequently does not translate into even a 10% increase in sales. It's quite common for things to generate or save money. Sadly, most engineers won't bother counting the results related to their work.
      - oceanghost 9y ago
        I agree, but this is essentially a tragedy of the commons problem being exploited by management. Keeping up with new technologies is essentially a proxy question for, "How much free time do you have that I might exploit later?"
- redcalx 9y ago
  Indeed. When you see some of the waste that goes on - whole projects going in the wrong direction and having to be largely reworked. And the people in charge will never admit they made an error in how they set up teams, and that it's the 'greyhairs' getting involved and rescuing projects over and over again.
- javajosh 9y ago
  Indeed! Over time I've become more and more aware (and proud) of the things I left out. As a young programmer, I would be far more proud of the things I included. The shipped project is one branch of an extremely large tree of possibilities which a younger, less experienced programmer would have taken a very long time to explore and discard (which I know for certain because I was that programmer).
  - tracker1 9y ago
    It's weird how that works... I try to avoid unneeded complexity as much as possible for as long as possible... and when I do need complexity, I try to make it as easy to use as possible, so that it's less in your face on reuse. I'm consistently amazed at how much of a pain in the ass things tend to get when people try to build solutions in their early 20's, vs 30's and now in my 40's. Not to mention how much my viewpoint has changed in the past 20+ years in software. I'm pretty happy when I can remove a bunch of dead/unused code trees, commented out swaths of crap, and refactor portions of a codebase into 1/5 the size.
    - megaman22 9y ago
      I rewrote a 900 line class today by writing one generic function that encapsulated a pile of common logic that the monstrosity had copied and pasted with slight changes over, and over, and over, and over, ad nauseum, and wound up with less than 100 lines of code. What a glorious day.
- lovich 9y ago
  What you won't do however, is work insane hours to get something done because management changed scope or requirements at the last second but kept the deadline. The flavor of agile development that most shops seem to devolve to is one where management gets the part that they can update requirements based on new information, but deadlines are the same and costs need to constantly be cut. My personal belief is that our industry tends towards less experienced workers because they put up with shit managers more and can be used to cover for their issues. It's anecodtal only, but I have never heard management decide that their deadlines we're improbable if not impossible when bugs get through. It's always just explained away with platitudes about code quality that suddenly dont matter when that requires more money or more time
  - doktrin 9y ago
    As an overworking tryhard chronic cover-upper, this hits dishearteningly close to home.
  - emodendroket 9y ago
    Call me cynical, but I am always surprised when people sincerely appeal to "agile/scrum values" of team autonomy or whatever to contest management diktats because, like... isn't it totally predictable that that part will be ignored whenever it is inconvenient?
    - dreamfactored 9y ago
      Agile is like dieting, simple but hard and requiring a lot of discipline. Very very few companies are any good at it but done well, it's a complete transformation.
      - emodendroket 9y ago
        I think it's more like a cult, where it's supposed to solve all your problems and any problem you identify with it just proves you aren't doing it right.
        9y ago
- rglullis 9y ago
  I totally agree that measuring productivity by the amount of working hours is ridiculous. However, it is important to realize that you are not competing with the 20-somethings or the ones that are fresh out of college. You are competing with the ones that have already a good amount of experience (let's say 7-10 years) but are still in the beginning of their careers. If they are minimally talented, they will probably produce code just as good as yours, yet they will probably (a) work for less money and (b) still be single and (c) more dedicated to work and (d) more tolerant of bullshit asks from the employer. Those are the ones that eventually fill positions as "Sr. Engineer" and crowd out the older ones.
  - lurr 9y ago
    which means you're competing for principal and architect level jobs, which are much more restricted.
  - notyourday 9y ago
    > I totally agree that measuring productivity by the amount of working hours is ridiculous. The alternative is P&L and boy grey beards don't want P&L based measurements
    - notyourday 9y ago
      There are only two things that are measurable: 1. Time 2. P&L P&L measurement would destroy majority of the old timers unless the old timers work the same little money fresh out of college people do.
- lurr 9y ago
  maybe they discriminate because you call the designs of other people shoddy. I'm only being half snarky. Large chunks of these threads end up as people bashing young people for being idiots for various reasons. I do believe that discrimination is an issue, but you also just don't need that many seniors. If you have a couple to make sure designs are reasonable, catch mistakes, and mentor the junior people then that seems pretty sufficient. If you have 5 seniors and a junior you get stuff done, but the junior person quits because they don't see any point in sticking around on a team where they aren't being challenged because someone more senior always gets to do it. Someone else will give them the challenge they want. I'm moving on right now exactly because of this.
  - AnimalMuppet 9y ago
    > maybe they discriminate because you call the designs of other people shoddy. I'm primarily calling my designs shoddy when I had only a few years of experience.
- shados 9y ago
  If we assume this is all 100% true...there's still no way to be sure during an interview. There's plenty of shitty older devs. And if they're old enough they're a protected class which will make things very awkward if you hit a shitty one. And with the newer generations, there are plenty of 18 years old that will run circle against more experience devs, nevermind mid 20 ones. There's of course plenty of crappy ones too. So all things equal, but with a different salary, which one do you pick if you're a naive hiring manager? Fortunately I now work for a company where this is a non-issue. While we definitely hire a ton of new grads, we'll never say no to older/more senior candidates (and sure could use more). Which is good, because I'm getting dangerously close to my 40s.
QAPereo 9y ago
Mind you, people are still happy to let bridges fall, and infrastructure in general, crumble. “That’s for the next guy to fix” seems to be the order of the day.
ryanmarsh 9y ago
If billions of computers become vulnerable to malicious actors and a few hundred or thousand people suffer dramatic personal damages, well that's a nice and quiet problem which will be quickly forgotten in the 24-hour news cycle. This. I do development coaching and training. I’m totally burned out because my job doesn’t matter. These companies don’t care. They hire me to “increase code quality” but that ends up being a lie. They just use me to get their teams to crank out shit faster, and I do mean “shit”. They don’t care if the systems blow up a few times a year or once a week. Banks, oil companies, airlines, all of them. They loose millions because of it too, still it doesn’t matter. No one (in leadership) gives a fuck. “Just make this quarter’s goal” is all that matters. Fucking equifax for crying out loud, NO CONSEQUENCES. If this isn’t ironic enough do some googling on why Equifax is named such. tl;dr This isn’t their first rodeo. They once fucked up so big they had to change their name. Sucking at software only has consequences in a few industries, usually ones where the product is software, the product is discretionary, and the customer is fickle. Even then it usually sucks. These same companies are audit conscious (about money), they’re crazy about regulatory compliance, and workplace harassment. Why? These things have real consequences. The sooner some company gets fined one year’s profit or an exec goes to jail the sooner this shit will actually matter to them.
- hackits 9y ago
  I think you've nailed it on the head but haven't realized why you've nailed it on the head. `Why? These things have real consequences.` To a business they see software/engineers as a expense. The whole focus as a business is to provide a service that people are will to pay more than it costs to provide said service. Everything else doesn't matter, what does matter for a business is $$$$$ and making sure business doesn't get sued because bill touched jill with his #####. For what my words are worth, I do think you need to take a step back and view it from a Business person perspective and attempt to align your goals with theirs. Get out of your cube and go and meet CEO's and CIO and talk to them about their problems and what their goals are. Then see if you two can work together to achieve their goals and bring value to the table. Even writing this I've could think of 10 or 20 different business discussions you could have.
  - 9y ago
banku_brougham 9y ago
You have it. Terse and to the point, i’m just providing more recognition here than my upvote.
itronitron 9y ago
In my experience, worse work typically gets done a lot more slowly than good work.
- omilu 9y ago
  This is my experience as well, I've never seen slow result in good.
- bdcravens 9y ago
  I don't think they mean slow development. Rather, overall rate - all other things equal, someone who insists on no more than a 40 hour week will accomplish less than someone willing to work 60-80 based on whatever metric you use (KLOC, story points, etc)
  - k3liutZu 9y ago
    I think his argument still applies to an "overall" metric.
    - bdcravens 9y ago
      Are you saying the 40 hour developer has a lower code quality than the 80 hour developer?
  - lemmings19 9y ago
    I've only ever heard one person ever mention KLOC's, and they were in their 60's nearly a decade ago. They were explaining how people were using it as a measurement of work done in the 80's, and what a terrible idea it was to measure throughput that way. You're the second person. When was the last time you encountered anyone using KLOC's (per 1k lines of code) as a measurement of work done? Are they working on mainframe codebases?
    - dorgo 9y ago
      I like to use LOCs to see at a glance the size of a project. A more complex business logic usually takes more LOCs to write it down. And I bet there is a strong correlation between LOCs and hours worked on a project which would make LOCs a good approximation of work done. Actually I should research it. Should be not too hard to find all the tickets for projects and compare the time logged to LOCs.
Bahamut 9y ago
To be fair, Apple already pays better than most companies.
asmosoinio 9y ago
> It's a race to the bottom. You could pay more for better work that gets done more slowly (fewer hours as people have families, etc,) or you could pay less for worse work that gets done more quickly. But in my experience, this is not true AT ALL. More experienced people might work less hours, but will produce the actual end results much quicker - both in hours and in calendar time. Especially when considering that less experienced devs will (on the average) cause more bugs and worse code structure - in the long run this causes a ton of extra work. In my opinion that is the main difference that easily makes someone a "10x" or a "100x" developer.
- Cthulhu_ 9y ago
  But that part - bugs, structure - quickly becomes invisible to higher management, as they start to rake in millions the software issues become only minor hitches in comparison. When a company does well, software problems are easily forgiven - Twitter had huge scaling problems but still grew to one of the largest platforms; Coinbase is having regular problems now and is a multi-billion platform. Code quality doesn't matter if the business goes well. We purists like to think that high-quality software sells itself, but I'm more and more starting to think that you can't start off with that. Of course, on the other hand over-engineering at an early phase of a project is very much a thing too - starting with microservices, using the latest framework or language, etc.
  - majjam 9y ago
    Please can you explain why using microservoces is over engineering? Is it because it’s a relatively new approach? Im getting involved in a new project that is using microservices and a new framework...
    - beaconstudios 9y ago
      not OP, but microservices can cause you to have to spend a disproportionate amount of time writing glue code between services. Starting with microservices is often a case of implementing separation of concern at the network rather than the functional layer, which is IMO too high in the stack. Microservices should be extracted for performance reasons, not build from the start because they are trendy.
EvilGrin 9y ago
This is just a facet of the good old fashioned project management 'iron' triangle. https://en.wikipedia.org/wiki/Project_management_triangle https://en.wikipedia.org/wiki/Project_management_triangle Crudely put, for project X you have three the following constraints. Cheap, On time, and good quality. You get to pick two of these three. It would seem to me most companies are opting for cheap, on time delivery and thus the quality is simply absent.
walshemj 9y ago
so apply timeboxing
otakucode 9y ago
If a bridge falls down and people die, the suits go to prison for criminal negligence for not hiring experienced people and giving them the power in the organization to set the schedules. If a system that involves software fails and people die, the courts throw up their hands and say 'nobody knows how computers work, and there are no standards we could claim they violated or ignored' and the company usually doesn't even take much of a PR hit. It should be obvious to everyone that this situation will not stand forever and it will be very bad when it stops... but everyone has motivations to resist the establishment of standards so they'll continue to bicker about it and do nothing until legislators force the issue in the most hamfisted and horrendous way possible.
TsomArp 9y ago
I am not sure it is cheaper in the end. You might pay a lower hourly rate, but because of bad work, rework, miscommunication, delay on communications you will pay more in the end. That has been my experience with, for example Chinese and Indian development teams abroad. There is a reason why agile prefers collocated teams.
- godelski 9y ago
  While I agree with you, that it isn't cheaper in the end, people think short term. Lots of companies are trying to pinch pennies at every corner. A great example: Why does extra sauce cost more money? It pisses most people off and a lot of people turn it down. But they still probably see slightly higher margins at the end of the year.
- notyourday 9y ago
  It is not about cost. It is about cashflow. Revenue is not a king. Profit is not a king. Cashflow is a king.
  - marcosdumay 9y ago
    Nope, hiring fewer more experienced programmers is also better for cashflow. My bet is that it's about easy and hard to measure costs, and how our modern big government world insulates large companies from competition.
    - notyourday 9y ago
      Nope. I can hire out of school programmers for $70k/year. I can hire grey beards for $200k/year. Not a single grey beard is worth 3 of those out of school programmers. This is also why grey beards suck for P&L so they better want to work long hours.

AnimalMuppet 9y ago

I'm one of the greyhairs. I won't work the insane hours, but I'll still get more done. How? By knowing what to write and how to write it, so I don't have to fumble around trying things for nearly as long. By not writing the bugs that the 20-somethings write, which means I don't have to take the time to try to fix them. By not creating the shoddy designs that other create, which then have to be fixed. By having an idea where to look when bugs do show up, so that they get fixed more quickly. And so on. It's about producing working code, not about how many hours my butt is in a seat...

trevyn 9y ago
>It's about producing working code I propose that working code is necessary, but not sufficient.
exelius 9y ago
I'm not attacking you here (and in fact I agree with you), but from a manager's perspective, I need one guy like you to design it in an architecture modeling tool and 8 young code monkeys to do all the boring work of building and testing it. You can do the code reviews to make sure they don't do stupid shit. The thought is that a team of greyhairs never ships anything, and a team of youngsters ships garbage. But it's better to ship garbage than nothing, hence the bias.
- oceanghost 9y ago
  Can we just be honest? Us older folks won't build things we know doesn't work against synthetic deadlines, then work overtime to fix what we knew wasn't going to work in the first place, while taking the blame politically. Engineering has in my lifetime become "unwinnable." I'm either not "a team player" or "being negative" for planning for reasonable failure scenarios. Then politically I still take the heat when they happen. This is not a quixotic aspect of engineering, it is a design feature at bad employers. "Heads I win, tails you lose"
  - sidlls 9y ago
    Engineers aren't blameless, here. In fact they're at least as much the problem as "bad employers". Constantly seeking to use the latest shiny tech toy whether it's appropriate or not (e.g. "Big Data" tools to run stuff on a few GB of data) is a thing, especially in the Bay Area. It leads to a bunch of people with a small amount of shallow experience in a large number of soon-to-be-deprecated technologies. Few want to do the hard work of actual engineering. Also, that the product is 10% better/more stable/whatever frequently does not translate into even a 10% increase in sales. So it's not worth it (from the business' perspective) to invest in that quality. Pick some other arbitrary point (e.g. 20% better/20% boost in sales, etc.), right down to some threshold whereby the company simply doesn't even have a product that can be demonstrated.
    - user5994461 9y ago
      >>> Also, that the product is 10% better/more stable/whatever frequently does not translate into even a 10% increase in sales. It's quite common for things to generate or save money. Sadly, most engineers won't bother counting the results related to their work.
    - oceanghost 9y ago
      I agree, but this is essentially a tragedy of the commons problem being exploited by management. Keeping up with new technologies is essentially a proxy question for, "How much free time do you have that I might exploit later?"
redcalx 9y ago
Indeed. When you see some of the waste that goes on - whole projects going in the wrong direction and having to be largely reworked. And the people in charge will never admit they made an error in how they set up teams, and that it's the 'greyhairs' getting involved and rescuing projects over and over again.
javajosh 9y ago
Indeed! Over time I've become more and more aware (and proud) of the things I left out. As a young programmer, I would be far more proud of the things I included. The shipped project is one branch of an extremely large tree of possibilities which a younger, less experienced programmer would have taken a very long time to explore and discard (which I know for certain because I was that programmer).
- tracker1 9y ago
  It's weird how that works... I try to avoid unneeded complexity as much as possible for as long as possible... and when I do need complexity, I try to make it as easy to use as possible, so that it's less in your face on reuse. I'm consistently amazed at how much of a pain in the ass things tend to get when people try to build solutions in their early 20's, vs 30's and now in my 40's. Not to mention how much my viewpoint has changed in the past 20+ years in software. I'm pretty happy when I can remove a bunch of dead/unused code trees, commented out swaths of crap, and refactor portions of a codebase into 1/5 the size.
  - megaman22 9y ago
    I rewrote a 900 line class today by writing one generic function that encapsulated a pile of common logic that the monstrosity had copied and pasted with slight changes over, and over, and over, and over, ad nauseum, and wound up with less than 100 lines of code. What a glorious day.
lovich 9y ago
What you won't do however, is work insane hours to get something done because management changed scope or requirements at the last second but kept the deadline. The flavor of agile development that most shops seem to devolve to is one where management gets the part that they can update requirements based on new information, but deadlines are the same and costs need to constantly be cut. My personal belief is that our industry tends towards less experienced workers because they put up with shit managers more and can be used to cover for their issues. It's anecodtal only, but I have never heard management decide that their deadlines we're improbable if not impossible when bugs get through. It's always just explained away with platitudes about code quality that suddenly dont matter when that requires more money or more time
- doktrin 9y ago
  As an overworking tryhard chronic cover-upper, this hits dishearteningly close to home.
- emodendroket 9y ago
  Call me cynical, but I am always surprised when people sincerely appeal to "agile/scrum values" of team autonomy or whatever to contest management diktats because, like... isn't it totally predictable that that part will be ignored whenever it is inconvenient?
  - dreamfactored 9y ago
    Agile is like dieting, simple but hard and requiring a lot of discipline. Very very few companies are any good at it but done well, it's a complete transformation.
    - emodendroket 9y ago
      I think it's more like a cult, where it's supposed to solve all your problems and any problem you identify with it just proves you aren't doing it right.
      - 9y ago
rglullis 9y ago
I totally agree that measuring productivity by the amount of working hours is ridiculous. However, it is important to realize that you are not competing with the 20-somethings or the ones that are fresh out of college. You are competing with the ones that have already a good amount of experience (let's say 7-10 years) but are still in the beginning of their careers. If they are minimally talented, they will probably produce code just as good as yours, yet they will probably (a) work for less money and (b) still be single and (c) more dedicated to work and (d) more tolerant of bullshit asks from the employer. Those are the ones that eventually fill positions as "Sr. Engineer" and crowd out the older ones.
- lurr 9y ago
  which means you're competing for principal and architect level jobs, which are much more restricted.
- notyourday 9y ago
  > I totally agree that measuring productivity by the amount of working hours is ridiculous. The alternative is P&L and boy grey beards don't want P&L based measurements
  - notyourday 9y ago
    There are only two things that are measurable: 1. Time 2. P&L P&L measurement would destroy majority of the old timers unless the old timers work the same little money fresh out of college people do.
lurr 9y ago
maybe they discriminate because you call the designs of other people shoddy. I'm only being half snarky. Large chunks of these threads end up as people bashing young people for being idiots for various reasons. I do believe that discrimination is an issue, but you also just don't need that many seniors. If you have a couple to make sure designs are reasonable, catch mistakes, and mentor the junior people then that seems pretty sufficient. If you have 5 seniors and a junior you get stuff done, but the junior person quits because they don't see any point in sticking around on a team where they aren't being challenged because someone more senior always gets to do it. Someone else will give them the challenge they want. I'm moving on right now exactly because of this.
- AnimalMuppet 9y ago
  > maybe they discriminate because you call the designs of other people shoddy. I'm primarily calling my designs shoddy when I had only a few years of experience.
shados 9y ago
If we assume this is all 100% true...there's still no way to be sure during an interview. There's plenty of shitty older devs. And if they're old enough they're a protected class which will make things very awkward if you hit a shitty one. And with the newer generations, there are plenty of 18 years old that will run circle against more experience devs, nevermind mid 20 ones. There's of course plenty of crappy ones too. So all things equal, but with a different salary, which one do you pick if you're a naive hiring manager? Fortunately I now work for a company where this is a non-issue. While we definitely hire a ton of new grads, we'll never say no to older/more senior candidates (and sure could use more). Which is good, because I'm getting dangerously close to my 40s.

QAPereo 9y ago

Mind you, people are still happy to let bridges fall, and infrastructure in general, crumble. “That’s for the next guy to fix” seems to be the order of the day.

ryanmarsh 9y ago

If billions of computers become vulnerable to malicious actors and a few hundred or thousand people suffer dramatic personal damages, well that's a nice and quiet problem which will be quickly forgotten in the 24-hour news cycle. This. I do development coaching and training. I’m totally burned out because my job doesn’t matter. These companies don’t care. They hire me to “increase code quality” but that ends up being a lie. They just use me to get their teams to crank out shit faster, and I do mean “shit”. They don’t care if the systems blow up a few times a year or once a week. Banks, oil companies, airlines, all of them. They loose millions because of it too, still it doesn’t matter. No one (in leadership) gives a fuck. “Just make this quarter’s goal” is all that matters. Fucking equifax for crying out loud, NO CONSEQUENCES. If this isn’t ironic enough do some googling on why Equifax is named such. tl;dr This isn’t their first rodeo. They once fucked up so big they had to change their name. Sucking at software only has consequences in a few industries, usually ones where the product is software, the product is discretionary, and the customer is fickle. Even then it usually sucks. These same companies are audit conscious (about money), they’re crazy about regulatory compliance, and workplace harassment. Why? These things have real consequences. The sooner some company gets fined one year’s profit or an exec goes to jail the sooner this shit will actually matter to them.

hackits 9y ago
I think you've nailed it on the head but haven't realized why you've nailed it on the head. `Why? These things have real consequences.` To a business they see software/engineers as a expense. The whole focus as a business is to provide a service that people are will to pay more than it costs to provide said service. Everything else doesn't matter, what does matter for a business is $$$$$ and making sure business doesn't get sued because bill touched jill with his #####. For what my words are worth, I do think you need to take a step back and view it from a Business person perspective and attempt to align your goals with theirs. Get out of your cube and go and meet CEO's and CIO and talk to them about their problems and what their goals are. Then see if you two can work together to achieve their goals and bring value to the table. Even writing this I've could think of 10 or 20 different business discussions you could have.
- 9y ago

banku_brougham 9y ago

You have it. Terse and to the point, i’m just providing more recognition here than my upvote.

itronitron 9y ago

In my experience, worse work typically gets done a lot more slowly than good work.

omilu 9y ago
This is my experience as well, I've never seen slow result in good.
bdcravens 9y ago
I don't think they mean slow development. Rather, overall rate - all other things equal, someone who insists on no more than a 40 hour week will accomplish less than someone willing to work 60-80 based on whatever metric you use (KLOC, story points, etc)
- k3liutZu 9y ago
  I think his argument still applies to an "overall" metric.
  - bdcravens 9y ago
    Are you saying the 40 hour developer has a lower code quality than the 80 hour developer?
- lemmings19 9y ago
  I've only ever heard one person ever mention KLOC's, and they were in their 60's nearly a decade ago. They were explaining how people were using it as a measurement of work done in the 80's, and what a terrible idea it was to measure throughput that way. You're the second person. When was the last time you encountered anyone using KLOC's (per 1k lines of code) as a measurement of work done? Are they working on mainframe codebases?
  - dorgo 9y ago
    I like to use LOCs to see at a glance the size of a project. A more complex business logic usually takes more LOCs to write it down. And I bet there is a strong correlation between LOCs and hours worked on a project which would make LOCs a good approximation of work done. Actually I should research it. Should be not too hard to find all the tickets for projects and compare the time logged to LOCs.

Bahamut 9y ago

To be fair, Apple already pays better than most companies.

asmosoinio 9y ago

> It's a race to the bottom. You could pay more for better work that gets done more slowly (fewer hours as people have families, etc,) or you could pay less for worse work that gets done more quickly. But in my experience, this is not true AT ALL. More experienced people might work less hours, but will produce the actual end results much quicker - both in hours and in calendar time. Especially when considering that less experienced devs will (on the average) cause more bugs and worse code structure - in the long run this causes a ton of extra work. In my opinion that is the main difference that easily makes someone a "10x" or a "100x" developer.

Cthulhu_ 9y ago
But that part - bugs, structure - quickly becomes invisible to higher management, as they start to rake in millions the software issues become only minor hitches in comparison. When a company does well, software problems are easily forgiven - Twitter had huge scaling problems but still grew to one of the largest platforms; Coinbase is having regular problems now and is a multi-billion platform. Code quality doesn't matter if the business goes well. We purists like to think that high-quality software sells itself, but I'm more and more starting to think that you can't start off with that. Of course, on the other hand over-engineering at an early phase of a project is very much a thing too - starting with microservices, using the latest framework or language, etc.
- majjam 9y ago
  Please can you explain why using microservoces is over engineering? Is it because it’s a relatively new approach? Im getting involved in a new project that is using microservices and a new framework...
  - beaconstudios 9y ago
    not OP, but microservices can cause you to have to spend a disproportionate amount of time writing glue code between services. Starting with microservices is often a case of implementing separation of concern at the network rather than the functional layer, which is IMO too high in the stack. Microservices should be extracted for performance reasons, not build from the start because they are trendy.

EvilGrin 9y ago

This is just a facet of the good old fashioned project management 'iron' triangle. https://en.wikipedia.org/wiki/Project_management_triangle https://en.wikipedia.org/wiki/Project_management_triangle Crudely put, for project X you have three the following constraints. Cheap, On time, and good quality. You get to pick two of these three. It would seem to me most companies are opting for cheap, on time delivery and thus the quality is simply absent.

walshemj 9y ago

so apply timeboxing

otakucode 9y ago

If a bridge falls down and people die, the suits go to prison for criminal negligence for not hiring experienced people and giving them the power in the organization to set the schedules. If a system that involves software fails and people die, the courts throw up their hands and say 'nobody knows how computers work, and there are no standards we could claim they violated or ignored' and the company usually doesn't even take much of a PR hit. It should be obvious to everyone that this situation will not stand forever and it will be very bad when it stops... but everyone has motivations to resist the establishment of standards so they'll continue to bicker about it and do nothing until legislators force the issue in the most hamfisted and horrendous way possible.

TsomArp 9y ago

I am not sure it is cheaper in the end. You might pay a lower hourly rate, but because of bad work, rework, miscommunication, delay on communications you will pay more in the end. That has been my experience with, for example Chinese and Indian development teams abroad. There is a reason why agile prefers collocated teams.

godelski 9y ago
While I agree with you, that it isn't cheaper in the end, people think short term. Lots of companies are trying to pinch pennies at every corner. A great example: Why does extra sauce cost more money? It pisses most people off and a lot of people turn it down. But they still probably see slightly higher margins at the end of the year.
notyourday 9y ago
It is not about cost. It is about cashflow. Revenue is not a king. Profit is not a king. Cashflow is a king.
- marcosdumay 9y ago
  Nope, hiring fewer more experienced programmers is also better for cashflow. My bet is that it's about easy and hard to measure costs, and how our modern big government world insulates large companies from competition.
  - notyourday 9y ago
    Nope. I can hire out of school programmers for $70k/year. I can hire grey beards for $200k/year. Not a single grey beard is worth 3 of those out of school programmers. This is also why grey beards suck for P&L so they better want to work long hours.