5 ms·

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 to

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?"
  - watwut 9y ago
    Ok, but his specific complaint was that planning for reasonable failure scenarios makes you labeled not "a team player" or "being negative". And I have seen this happen, it is true problem. Someone else refactoring badly does not cancel that systemic problem out.
  - TeMPOraL 9y ago
    > 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. Here is the core of the problem, and it's more of an incompatibility of goals than errors of one of the parties. Businesses want to make money. They usually don't give a flying fuck about what their product is or does beyond the point it gets sold. Does it waste users' time and piss them off? They paid us, which means they value it, so everything is ok. Engineers, on the other hand, tend to care about what value the product actually provides to their users. So they would rather invest effort in making the product better for the users, instead of making it better for sales team to sell. I don't really see the way out of this conflict. The engineers are right, but the businesses are right too - it's the business that pays and suffers (some of) the consequences, so it's the business that gets to tell engineers what to do, and not the other way around. If CEO is making a stupid decision, that's on CEO. The way I see actually useful software gets done, it's outside or on the side of a business, not within it.
    - brlewis 9y ago
      The value the product actually provides to users is the viral coefficient. Lots of companies value growth. Find one.
      - TeMPOraL 9y ago
        Growth has been completely gamed already. Just look at most startups.
    - fshaun 9y ago
      Good point about incompatible goals. One way out is to align the value as perceived by users with the value as perceived by engineers. If users aren't willing to pay for reliability/security/etc. then it's rational for management to devalue those properties. I'm not optimistic that this will happen. Anecdotally, I expound to acquaintances the risks of unprotected PII or questionably-secured home security apps, but convenience seems to outweigh such concerns. Regulation is one approach to solve asymmetric information transactions. I don't see how that could be applied in general to software quality, but it could target the cases that have severe or widespread effects.
ryanmarsh 9y ago
I seem to recall an episode of the A16Z podcast where Adrian Cockcroft of Netflix explained they were top heavy on senior engineers when they began moving to microservices. Didn’t seem to slow them down but I could be misremembering.
- lurr 9y ago
  They only hire senior engineers. I don't know what that really means though. People who are smart, hard working, and get the right jobs can get a senior title in 5-6 years at the big companies.
  - lpr22 9y ago
    I know someone hired at Netflix who is belligerent, inexperienced, and lazy. He is a senior engineer there. Titles don’t really matter much at the end of the day.
btilly 9y ago
I STRONGLY disagree. My experience is that programmers who become "architects" and are only responsible for design and code review tend to go downhill in their skills. It SEEMS like an efficient way to use experienced people, but it is actually an anti-pattern. Their tendency is to develop ideas that sound good but don't work well in practice, and there is no direct way to correct the mistake. (Any time it doesn't work, the tendency is to blame the implementer. And there is usually enough to blame that their own contribution to the problem gets missed. You're less likely to miss the problem when YOU are trying to make the implementation work.) In fact the problem is sufficiently bad that in interviews it is important to have people actually write code to show that they still can. When you get an "architect" who takes offense at the exercise, that's a non-hire. They might have been good 10 years ago, but they aren't worth hiring now. This was something I'd sort of noticed, but didn't become conscious of until I worked at Google. There they were very conscious of the phenomena. Every programmer from the most junior to the most senior (for the record that would be Jeff Dean) writes code. If you're not willing to write code, you're not a hire. That said, the exercise goes both ways. If I interview with an employer and I discover that they design things up front as UML diagrams, odds are that this won't be a workplace that I want much to do with. If I'm working in a job and they force me into an abstract architecture role like you describe, I'm going to quit and find a better job.
- thomasrognon 9y ago
  My title is "architect". I use scare quotes because I agree with what you wrote and I dislike being associated with the type of people and the jobs that make it true. I, also, only work at places where the interview is sufficiently technical and there are no separate design-only roles. It's been surprising to me how much I've had to fight people on this issue in the past.
- notyourday 9y ago
  <three letter hat on> 1. All of you are overhead. 2. Customer is the profit. 3. Now how do I get (2) to be higher than (1) before we run out of money? </three letter hat off>
- exelius 9y ago
ryandrake 9y ago
> But it's better to ship garbage than nothing Yup, this is the software industry boiled down to the basics.
- doug1001 9y ago
  well i think this is certainly the problem--ie, now "garbage" looks justified but those aren't really the two alternatives, are they--ie, crap code or nothing? it might be in the very short terim (ie, by this friday) but over any other span of time, the choice is more like: ship crap code in 30 day, followed by 50% of the team's resources spent bug fixing (which can often be cleverly disguised as new features) for the next 90 days OR ship high quality code in 45 days
  - megaman22 9y ago
    Sadly, it's hard to convince people that doing things right is better than doing them wrong, but quicker. That customer needs this code on the 1st, that is a hard and fast deadline! So shit is churned out, and handed over on the 1st. Then, three or four 1sts later, the customer finally gets their shit together and deploys it, and, voila, it is shit. And the cycle continues, as the scramble ensues to patch the shit by the 15th with yet more shit. And you end up like the little Dutch boy at the dike, except instead of fingers you're using hotfixes made of excrement.
tlear 9y ago
You hire wrong grey hairs, most new people never shipped anything. Person with 10-20 years experience probably shipped a TON of stuff. This is the key thing to look when hiring, people who shipped things and like to ship things. On other hand there tons of grey hairs who never shipped anything and are useless as new grads are.
watwut 9y ago
> You can do the code reviews to make sure they don't do stupid shit. This does not work. Your code monkeys will get demotivated fast and wont be able to learn anyway. The one architect guy will because increasingly out of touch and his code review will become pointless red tape fast. > 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. Why would greyhairs never ships anything? I dont get it. My experience was that young people need more supervision to not get demotivated and to actually finish it. (on average)

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?"
- watwut 9y ago
  Ok, but his specific complaint was that planning for reasonable failure scenarios makes you labeled not "a team player" or "being negative". And I have seen this happen, it is true problem. Someone else refactoring badly does not cancel that systemic problem out.
- TeMPOraL 9y ago
  > 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. Here is the core of the problem, and it's more of an incompatibility of goals than errors of one of the parties. Businesses want to make money. They usually don't give a flying fuck about what their product is or does beyond the point it gets sold. Does it waste users' time and piss them off? They paid us, which means they value it, so everything is ok. Engineers, on the other hand, tend to care about what value the product actually provides to their users. So they would rather invest effort in making the product better for the users, instead of making it better for sales team to sell. I don't really see the way out of this conflict. The engineers are right, but the businesses are right too - it's the business that pays and suffers (some of) the consequences, so it's the business that gets to tell engineers what to do, and not the other way around. If CEO is making a stupid decision, that's on CEO. The way I see actually useful software gets done, it's outside or on the side of a business, not within it.
  - brlewis 9y ago
    The value the product actually provides to users is the viral coefficient. Lots of companies value growth. Find one.
    - TeMPOraL 9y ago
      Growth has been completely gamed already. Just look at most startups.
  - fshaun 9y ago
    Good point about incompatible goals. One way out is to align the value as perceived by users with the value as perceived by engineers. If users aren't willing to pay for reliability/security/etc. then it's rational for management to devalue those properties. I'm not optimistic that this will happen. Anecdotally, I expound to acquaintances the risks of unprotected PII or questionably-secured home security apps, but convenience seems to outweigh such concerns. Regulation is one approach to solve asymmetric information transactions. I don't see how that could be applied in general to software quality, but it could target the cases that have severe or widespread effects.

ryanmarsh 9y ago

I seem to recall an episode of the A16Z podcast where Adrian Cockcroft of Netflix explained they were top heavy on senior engineers when they began moving to microservices. Didn’t seem to slow them down but I could be misremembering.

lurr 9y ago
They only hire senior engineers. I don't know what that really means though. People who are smart, hard working, and get the right jobs can get a senior title in 5-6 years at the big companies.
- lpr22 9y ago
  I know someone hired at Netflix who is belligerent, inexperienced, and lazy. He is a senior engineer there. Titles don’t really matter much at the end of the day.

btilly 9y ago

I STRONGLY disagree. My experience is that programmers who become "architects" and are only responsible for design and code review tend to go downhill in their skills. It SEEMS like an efficient way to use experienced people, but it is actually an anti-pattern. Their tendency is to develop ideas that sound good but don't work well in practice, and there is no direct way to correct the mistake. (Any time it doesn't work, the tendency is to blame the implementer. And there is usually enough to blame that their own contribution to the problem gets missed. You're less likely to miss the problem when YOU are trying to make the implementation work.) In fact the problem is sufficiently bad that in interviews it is important to have people actually write code to show that they still can. When you get an "architect" who takes offense at the exercise, that's a non-hire. They might have been good 10 years ago, but they aren't worth hiring now. This was something I'd sort of noticed, but didn't become conscious of until I worked at Google. There they were very conscious of the phenomena. Every programmer from the most junior to the most senior (for the record that would be Jeff Dean) writes code. If you're not willing to write code, you're not a hire. That said, the exercise goes both ways. If I interview with an employer and I discover that they design things up front as UML diagrams, odds are that this won't be a workplace that I want much to do with. If I'm working in a job and they force me into an abstract architecture role like you describe, I'm going to quit and find a better job.

thomasrognon 9y ago
My title is "architect". I use scare quotes because I agree with what you wrote and I dislike being associated with the type of people and the jobs that make it true. I, also, only work at places where the interview is sufficiently technical and there are no separate design-only roles. It's been surprising to me how much I've had to fight people on this issue in the past.
notyourday 9y ago
<three letter hat on> 1. All of you are overhead. 2. Customer is the profit. 3. Now how do I get (2) to be higher than (1) before we run out of money? </three letter hat off>
exelius 9y ago

ryandrake 9y ago

> But it's better to ship garbage than nothing Yup, this is the software industry boiled down to the basics.

doug1001 9y ago
well i think this is certainly the problem--ie, now "garbage" looks justified but those aren't really the two alternatives, are they--ie, crap code or nothing? it might be in the very short terim (ie, by this friday) but over any other span of time, the choice is more like: ship crap code in 30 day, followed by 50% of the team's resources spent bug fixing (which can often be cleverly disguised as new features) for the next 90 days OR ship high quality code in 45 days
- megaman22 9y ago
  Sadly, it's hard to convince people that doing things right is better than doing them wrong, but quicker. That customer needs this code on the 1st, that is a hard and fast deadline! So shit is churned out, and handed over on the 1st. Then, three or four 1sts later, the customer finally gets their shit together and deploys it, and, voila, it is shit. And the cycle continues, as the scramble ensues to patch the shit by the 15th with yet more shit. And you end up like the little Dutch boy at the dike, except instead of fingers you're using hotfixes made of excrement.

tlear 9y ago

You hire wrong grey hairs, most new people never shipped anything. Person with 10-20 years experience probably shipped a TON of stuff. This is the key thing to look when hiring, people who shipped things and like to ship things. On other hand there tons of grey hairs who never shipped anything and are useless as new grads are.

watwut 9y ago

> You can do the code reviews to make sure they don't do stupid shit. This does not work. Your code monkeys will get demotivated fast and wont be able to learn anyway. The one architect guy will because increasingly out of touch and his code review will become pointless red tape fast. > 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. Why would greyhairs never ships anything? I dont get it. My experience was that young people need more supervision to not get demotivated and to actually finish it. (on average)