Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Framing of the Developer

svese.de

Post reply on HN
Print view View original

21–30 of 67 posts

Re: The Framing of the Developer

#21

Post by qw »

routerl wrote: post #10
narag wrote: post #3

I've never been in a place where it was pretended that there is no person with authority to tell you what to do, whatever that person is called, and that person's ass is the one that's kicked in case things don't work. What this article describes is alien to me: an organization where devs are apparently autonomous, so they're responsible for failures, but still need to go in the direction set by someone else. There a…

an organization where devs are apparently autonomous, so they're responsible for failures, but still need to go in the direction set by someone else. I've just left a place like this, largely for this reason. Someone with impressive credentials was hired by the senior leadership and given project ownership. The problem is that neither this person's education, nor their work experience, had anything to do with softwar…

> Choice example: does a time period "from January 2019 to January 2020" include two Januaries? The answer to this question would change, sometimes twice a week, when asked of the "product owner".

Unfortunately, the only way you can protect yourself is to have a paper trail. If the PO says something, write it down in your tracker (Jira, Trello etc.), or at least an email. If the PO is unclear, write the answer according to how you understand it and ask directly ("Is my understanding correct").

If the PO changes its mind, document that as well.

It shouldn't be necessary, and in many companies it is not, but some environments are toxic.

Re: The Framing of the Developer

#22

Post by cousin_it »

I don't understand why 1) developers are promoted based on impact 2) developers are given tasks by PMs 3) PMs choose tasks based on impact. This makes no sense to me. Either get rid of the PM role and put engineers in control of choosing impactful tasks, or change the promotion criteria.

Re: The Framing of the Developer

#23

Post by andyjohnson0 »

davedx wrote: post #14
gregdoesit wrote: post #7

One of the most well-known companies using what the author calls “impact frame” is Facebook. There, engineers’ promotions and perf used to be heavily dependent on their impact. Developers needed to be aware what the business impact of their work was, thus they needed to measure (using the excellent tooling available). This model worked very well while the company was growing. Lots of features core to Facebook today w…

> My take is the optimum is in-between. Engineers should have an understanding and input on the business impact. But the strategy and prioritisation framework does need to come top-down, aligned with the long-term goals of the business. I used to work for a small-ish Dutch energy company, and they went to a great effort at implementing this kind of framework, I thought it was great. We basically had huge quarterly ro…

Transparent, inclusive, low-ego. Seems like a very Dutch way to organise things. Like you, I also wish with was more common.

Re: The Framing of the Developer

#24

Post by mikekchar »

marcus_holmes wrote: post #20
mikekchar wrote: post #5

I like the diagram in the middle of the article and think it has a lot of value, but I want to comment on the "XP failed" aspect of the article. I've very rarely seen any team actually implement XP. The rare times I've been able to do so, it has worked spectacularly well. However, the constraints are difficult to deal with and XP in its original form only works with small, co-located teams. If you have more than 3-4…

This is the "no true scotsman" thing that plagues SCRUM too. The "you're not doing it right, so obviously it's not working for you" argument. If a team attempts to implement XP, and fail, then XP failed. Any discipline that doesn't work in real situations using real people with real politics and management issues, doesn't work.

I can understand what you are saying, but there are some very subtle and difficult things in the world. The fact that only a very few people in the world can be successful with the things that make a concert pianist successful does not mean that concert pianists have failed. I will absolutely agree that XP is not a discipline for the masses, but it is incredibly effective for those who are able to use it well (to the extent that it covers -- there are lots of areas of software development that XP does not cover at all and where you can fail easily while still using XP). I think one of the problems with XP as a movement was that it actually became more vague over time. I actually think that the original 12 rules are better than the current 12 rules.

I have implemented XP in real situations using real people with real politics and management issues. It has worked incredibly well for me. It does not work in all situations and all political environments with all management issues. You need to be very careful when selecting XP to make sure that the situation you are using it in is appropriate.

Re: The Framing of the Developer

#25

Post by JoshuaDavid »

qw wrote: post #21
routerl wrote: post #10

Earlier quoted context omitted.

an organization where devs are apparently autonomous, so they're responsible for failures, but still need to go in the direction set by someone else. I've just left a place like this, largely for this reason. Someone with impressive credentials was hired by the senior leadership and given project ownership. The problem is that neither this person's education, nor their work experience, had anything to do with softwar…

> Choice example: does a time period "from January 2019 to January 2020" include two Januaries? The answer to this question would change, sometimes twice a week, when asked of the "product owner". Unfortunately, the only way you can protect yourself is to have a paper trail. If the PO says something, write it down in your tracker (Jira, Trello etc.), or at least an email. If the PO is unclear, write the answer accord…

Though even in a non toxic environment you should document any product decisions and why they were made. Your PM now could be the most amazing and helpful person in the world, but in 3 years it may be important to know if there is an important reason a time period from January to January includes both Januaries (and thus something important will stop working if you change it) or whether that was an arbitrary decision because the question had to be answered one way or the other, so they flipped a coin (and thus there is no special reason to believe changing it is dangerous).

Always document product decisions. "Documenting" doesn't have to be a big process, and you don't really need to make polished documentation, but at the very least dump your notes from when decisions are made somewhere permanent and searchable (github comments / jira comments / even slack messages in a non-dm channel count). Your future self will thank you.

Re: The Framing of the Developer

#26

Post by AmericanChopper »

29athrowaway wrote: post #16

That is why you need engineering leadership that can keep the PM in check, and can veto PM decisions if they endanger the product in a way only engineers can understand, or want to understand. And that engineering leadership needs to be independent enough from the PM, so that the PM cannot appoint redundant/agreeable scapegoats with no engineering weight. Maybe you can still allow the PM force their hand on engineeri…

> if they endanger the product in a way only engineers can understand

If you have critical risks that only engineers can understand, then you have extremely poor engineering leadership. I can’t think of any examples critical risks I’ve encountered that couldn’t be communicated concisely to non-technical stakeholders.

Re: The Framing of the Developer

#27

Post by bob1029 »

This seems like such an obvious thing to me. When an issue comes up for prioritization during review, we simply ask "What value does this bring to the business".

Every single meandering bullshit conversational path we happen to find ourselves upon can be immediately curtailed by stating these words. Technical folks may not like hearing it all the time, and it doesn't necessarily have to be the dominating factor 100% of the time (i.e. side-projects, 20% time code activities, etc). But, this is the penultimate tool for ending arguments and separating the bullshit from the reason people are receiving paychecks.

Very scary time-crunch episodes can in many cases be diffused by simply going to the customer and asking them, "Out of these 10 things, if you could have 3 by the end of the month, which would you pick?" I think you would instantly get a picture of how you should prioritize your efforts to drive value for them. I strongly suspect that if you can meet incremental targets in descending order of value (as perceived by the customer), you can keep virtually anyone happy. Hitting customer targets successfully is also very good for morale and can further compound productivity on all ends.

Re: The Framing of the Developer

#29

Post by nobodywillobsrv »

All this discussion gets things wrong. Bring back negative feed back and pain to stake-holders. Creator must take the bullet. IT what happens when executive slaves want the paycheck without the responsibility.

Failure to test organizations is another main problem. Can one person make a small change quickly? No? Then delete. Try again. Burn it down.

Re: The Framing of the Developer

#30

Post by twic »

marcus_holmes wrote: post #20
mikekchar wrote: post #5

I like the diagram in the middle of the article and think it has a lot of value, but I want to comment on the "XP failed" aspect of the article. I've very rarely seen any team actually implement XP. The rare times I've been able to do so, it has worked spectacularly well. However, the constraints are difficult to deal with and XP in its original form only works with small, co-located teams. If you have more than 3-4…

This is the "no true scotsman" thing that plagues SCRUM too. The "you're not doing it right, so obviously it's not working for you" argument. If a team attempts to implement XP, and fail, then XP failed. Any discipline that doesn't work in real situations using real people with real politics and management issues, doesn't work.

Exactly! I just tried to cook some scrambled eggs. One the eggs went on the floor, and the eggs in the pan cooked to quickly and turned into an omelette. Scrambled eggs has failed!
Post reply on HN