7 ms·

My first reaction to this... the document says "We are owners of each and every feature we build", but who is "we"? If I write a feature, am I expected to own i

My first reaction to this... the document says "We are owners of each and every feature we build", but who is "we"? If I write a feature, am I expected to own it throughout the lifecycle? It's easy to hide behind "We", and easy to say "we isn't me". I might suggest something like "I own everything I build and everything my teammates build". That eliminates a whole class of avoidance and excuses for bad code. Overall it's a nice distillation of general corporate engineering teamspeak but I didn't grasp anything new or enlightening. This document would be pretty easy to ignore if I were in that group.

free2rhyme214 11y ago
I completely agree with you. Also to me accountability goes to whomever is currently working on the code and whomever manages that individual. I think what they meant was that when you code something, you have to treat your work like you completely own it so you do a good job but to me that's self explanatory and is only repeated to enforce rules that are obvious.
edawerd 11y ago
What we meant by "we" is that the individual engineer who wrote the code is ultimaetly responsible for it. From building/modifying the backend APIs, frontend code, testing, QA, and ongoing maintenance/bug fixes. I guess "we" really means "you"
- pkaye 11y ago
  What about sales, marketing, management, QA and other staff? What is their responsibility?
  - chralieboy 11y ago
    Probably outside of the scope of this document. Can you imagine if a Sales team came up with a set of values and part of that document specified how engineers should do their jobs? There would be revolt!
- codeonfire 11y ago
  That will never work because economic returns to a piece of code will not go to the engineer. Both management and company owners will want most of the returns of the code, leaving no profit motive for the engineer to be ultimately responsible for it. The engineer will move on and the owners and management are stuck with rotting code. Or management gets rid of all the engineers because they want to keep all the revenue and discount both cost of maintenance and need for engineers to profit.
  - hliyan 11y ago
    I believe you described Marx's theory of alienation[1] as applied to software engineering. [1]:https://en.wikipedia.org/wiki/Marx's_theory_of_alienation https://en.wikipedia.org/wiki/Marx's_theory_of_alienation
    - codeonfire 11y ago
      Yeah, which is why companies should stop going on about 'owning' things. If I'm going to own its creation and operation, I'm going to own all the revenue it produces. All of it. I have all the means of production (no 19th century power looms needed to create software) and all I really have to do is survive while it is being produced.
      - omouse 11y ago
        This is actually what Philip Greenspun did at ArsDigita. Each project had its manager/lead own the profit-and-loss: From Founders At Work: "I'm organizing this company like McDonald's. Each restaurant is going to be managed by a few people, and they're going to have profit-and-loss responsibility. If they make a profit, they get to pocket half of it. If they make a loss, we're going to know who's responsible, and we're going to go there and fix it, and there are going to be consequences for those people." People have all the right incentives to make their customer happy, to do the thing on time, to take the customer's money, deposit in the bank, and then move on to the next one and get their bonus at the end of the year. And apparently at one time Accenture had this philosophy too: At the time Anderson Consulting (now Accenture) didn't have any salespeople. They always had the people who were executing the project sell it. "You eat what you kill" was the phrase at Accenture. You don't have a salesperson go out and tell the customer, "We can do this", making promises and then handing it off to a programmer"
mmatants 11y ago
> I didn't grasp anything new or enlightening Repeating the "obvious" is very important. There is a constant fight against entropy, miscommunication and attrition of experience in any team, and things like these add up in a huge way. The more years I spend in the field, the more I realize the need to "over-compensate" affirming and syncing up on stuff like this. And aggregating stuff like this into a list is tougher than it seems. This is one of the most balanced values summaries I've seen (for my subjective taste!) - not being too vague, but also not "hard-coding" specific methodologies or buzzwords.

free2rhyme214 11y ago

I completely agree with you. Also to me accountability goes to whomever is currently working on the code and whomever manages that individual. I think what they meant was that when you code something, you have to treat your work like you completely own it so you do a good job but to me that's self explanatory and is only repeated to enforce rules that are obvious.

edawerd 11y ago

What we meant by "we" is that the individual engineer who wrote the code is ultimaetly responsible for it. From building/modifying the backend APIs, frontend code, testing, QA, and ongoing maintenance/bug fixes. I guess "we" really means "you"

pkaye 11y ago
What about sales, marketing, management, QA and other staff? What is their responsibility?
- chralieboy 11y ago
  Probably outside of the scope of this document. Can you imagine if a Sales team came up with a set of values and part of that document specified how engineers should do their jobs? There would be revolt!
codeonfire 11y ago
That will never work because economic returns to a piece of code will not go to the engineer. Both management and company owners will want most of the returns of the code, leaving no profit motive for the engineer to be ultimately responsible for it. The engineer will move on and the owners and management are stuck with rotting code. Or management gets rid of all the engineers because they want to keep all the revenue and discount both cost of maintenance and need for engineers to profit.
- hliyan 11y ago
  I believe you described Marx's theory of alienation[1] as applied to software engineering. [1]:https://en.wikipedia.org/wiki/Marx's_theory_of_alienation https://en.wikipedia.org/wiki/Marx's_theory_of_alienation
  - codeonfire 11y ago
    Yeah, which is why companies should stop going on about 'owning' things. If I'm going to own its creation and operation, I'm going to own all the revenue it produces. All of it. I have all the means of production (no 19th century power looms needed to create software) and all I really have to do is survive while it is being produced.
    - omouse 11y ago
      This is actually what Philip Greenspun did at ArsDigita. Each project had its manager/lead own the profit-and-loss: From Founders At Work: "I'm organizing this company like McDonald's. Each restaurant is going to be managed by a few people, and they're going to have profit-and-loss responsibility. If they make a profit, they get to pocket half of it. If they make a loss, we're going to know who's responsible, and we're going to go there and fix it, and there are going to be consequences for those people." People have all the right incentives to make their customer happy, to do the thing on time, to take the customer's money, deposit in the bank, and then move on to the next one and get their bonus at the end of the year. And apparently at one time Accenture had this philosophy too: At the time Anderson Consulting (now Accenture) didn't have any salespeople. They always had the people who were executing the project sell it. "You eat what you kill" was the phrase at Accenture. You don't have a salesperson go out and tell the customer, "We can do this", making promises and then handing it off to a programmer"

mmatants 11y ago

> I didn't grasp anything new or enlightening Repeating the "obvious" is very important. There is a constant fight against entropy, miscommunication and attrition of experience in any team, and things like these add up in a huge way. The more years I spend in the field, the more I realize the need to "over-compensate" affirming and syncing up on stuff like this. And aggregating stuff like this into a list is tougher than it seems. This is one of the most balanced values summaries I've seen (for my subjective taste!) - not being too vague, but also not "hard-coding" specific methodologies or buzzwords.