Hacker News Reader

Comment by pjerem | Hacker News Reader

I agree with you but there are two prerequisites for this to work :

- as you said, this can’t be too soon in your career : gathering requirements and knowledge is something that you can’t do without experience

- you need to be 100% confident that you are working in an environment where you will be rewarded accordingly. Working hard on those projects just to see your manager be promoted will be an absolute emotional disaster.

If one of those requirements aren’t met, you are good for burning out.

View on HN

I agree, and I also find that it's mostly developers with experience that are able to do it... but it's not because of seniority: it's because people with 10+ years of experience simply had to learn it in the past.

In the past there was no choice: developers would talk to users and stakeholders and collect information.

Today there are few opportunities for a junior developer to do this.

That is experience! There is a saying - some people have 10 years of experience, some people have 1 year of experience 10 times.

That would be really cool to do. One of the reasons I became a dev is cos I used to work for customer service in a games company and I was frustrated with the fact that there were ongoing bugs that I could've fixed if I was in the dev position. In reality, as a dev I am now on the other end where we never really hear feedback from users and there always seems to be some agile race to the bottom where we try to fix as little as possible as simply as possible.

I had several instances of product people asking stakeholders, users and support people not to talk with developers. Prioritisation had to go exclusively trough them.

There was constant complaining from both sides: from product that "tickets opened to us are horrible, support/customers are ignorant" and from customers that "nothing ever gets done here".

In the end nothing of that was true. Nobody was ignorant and a lot was getting done.

Was it a good system, then, even if people didn't realize it?

> always seems to be some agile race to the bottom where we try to fix as little as possible as simply as possible.

Yeah, that's not agile. The entire point of agile is that you close the loop and the reason you break your work into smaller chunks is so you can deliver them faster in order to gauge the feedback of that chunk and better understand what should be delivered in the next chunk.

If you're not closing the loop, you're not doing agile, you're just doing waterfall with more bureaucracy.

Reply on news.ycombinator.com