3 ms·

As a senior person, these are some of my favorite types of projects, because I feel like it's where I'm the most useful, and where I can have the most impact: u

by nomel 3y ago

As a senior person, these are some of my favorite types of projects, because I feel like it's where I'm the most useful, and where I can have the most impact: understand the need, then implement the need rather than the request. When I see people struggling with these, it's usually from a lack of information seeking/gathering, where they first sit down and code rather than spend the first few weeks talking, reviewing understanding, and, most importantly, finding those few A-team people that have meaningful input. Definitely not something someone early in their career should be given, but these types of problems usually benefit from devaluing manager input, since they have a disconnected/warped perception of reality. I take these projects only if the understanding is that I'll be solving a problem, taking input from all involved, rather than implementing a specific solution.

j45 3y ago
Getting the need right, in lockstep with the audiences realization of it is an important soft and hard skill that should be better taught.
- nomel 3y ago
  > in lockstep with the audiences realization Perfect wording! I tell people the hardest problem, in my work, is getting people to see there is a problem. The crazy workarounds that people will come up with, to avoid the root issue, are really incredible.
softfalcon 3y ago
Yeah, these types of projects can turn out to be a real gift. They are essentially a "folks here have an initiative they want to fund but don't know how" and if you direct the conversations well, you can create something incredible out of it. Things being up in the air and vague is often an opportunity to step in a tame a wild forest of ideas into a real application. It definitely takes a certain type of mindset to harness that energy and herd the cats though.
pdonis 3y ago
> I take these projects only if the understanding is that I'll be solving a problem, taking input from all involved, rather than implementing a specific solution. If this is the case, I would say you're not being "set up to fail", which was the explicit description the GP gave. "Set up to fail", to me, implies that whoever is tasking you is not tasking you to actually solve the problem, either because they're too clueless to know that what they're specifically tasking you to do won't work, or because there is some other hidden agenda in play.
gryn 3y ago
that's assuming you have somewhat cooperative people, in which case I don't think it's a setup to fail situation. my reading of it was more like some past experience where I tried to do what you described only to be reprimanded for "overstepping boundaries" and that not being my job function, especially when the manager/PO/etc insist on being an exclusive gateway to information despite repeatedly failing to do that job correctly. I think we all agree on the importance on your last part where you need to suss out whether they want an obedient code monkey or someone to solve the problem. probably through an iterative dialog where the parties involved get to explore and update their understanding of the problem, the technical and non technical constraints and the solution space.
- robocat 3y ago
  > especially when the manager/PO/etc insist on being an exclusive gateway to information A strong signal to leave a sinking ship. I suspect even if you somehow pull a rabbit out of the bag you wouldn't be rewarded for it. I stuck with one project like that when I shouldn't: I finished the work however the useless salesperson was screwing up the communications with the client and didn't get the project across the line to them. One of the most demotivating environments to suffer.
  - whstl 3y ago
    This 100%. This siloing is what causes fear and uncertainty about project, and also what makes developers atrophy their "talk to users" muscle. It is what made me leave jobs in the past and made me fight to change how things work at my current job.
pjerem 3y ago
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.
- whstl 3y ago
  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.
  - lozenge 3y ago
    That is experience! There is a saying - some people have 10 years of experience, some people have 1 year of experience 10 times.
  - helboi4 3y ago
    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.
    - whstl 3y ago
      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.

by nomel 3y ago

j45 3y ago

Getting the need right, in lockstep with the audiences realization of it is an important soft and hard skill that should be better taught.

nomel 3y ago
> in lockstep with the audiences realization Perfect wording! I tell people the hardest problem, in my work, is getting people to see there is a problem. The crazy workarounds that people will come up with, to avoid the root issue, are really incredible.

softfalcon 3y ago

Yeah, these types of projects can turn out to be a real gift. They are essentially a "folks here have an initiative they want to fund but don't know how" and if you direct the conversations well, you can create something incredible out of it. Things being up in the air and vague is often an opportunity to step in a tame a wild forest of ideas into a real application. It definitely takes a certain type of mindset to harness that energy and herd the cats though.

pdonis 3y ago

> I take these projects only if the understanding is that I'll be solving a problem, taking input from all involved, rather than implementing a specific solution. If this is the case, I would say you're not being "set up to fail", which was the explicit description the GP gave. "Set up to fail", to me, implies that whoever is tasking you is not tasking you to actually solve the problem, either because they're too clueless to know that what they're specifically tasking you to do won't work, or because there is some other hidden agenda in play.

gryn 3y ago

that's assuming you have somewhat cooperative people, in which case I don't think it's a setup to fail situation. my reading of it was more like some past experience where I tried to do what you described only to be reprimanded for "overstepping boundaries" and that not being my job function, especially when the manager/PO/etc insist on being an exclusive gateway to information despite repeatedly failing to do that job correctly. I think we all agree on the importance on your last part where you need to suss out whether they want an obedient code monkey or someone to solve the problem. probably through an iterative dialog where the parties involved get to explore and update their understanding of the problem, the technical and non technical constraints and the solution space.

robocat 3y ago
> especially when the manager/PO/etc insist on being an exclusive gateway to information A strong signal to leave a sinking ship. I suspect even if you somehow pull a rabbit out of the bag you wouldn't be rewarded for it. I stuck with one project like that when I shouldn't: I finished the work however the useless salesperson was screwing up the communications with the client and didn't get the project across the line to them. One of the most demotivating environments to suffer.
- whstl 3y ago
  This 100%. This siloing is what causes fear and uncertainty about project, and also what makes developers atrophy their "talk to users" muscle. It is what made me leave jobs in the past and made me fight to change how things work at my current job.

pjerem 3y ago

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.

whstl 3y ago
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.
- lozenge 3y ago
  That is experience! There is a saying - some people have 10 years of experience, some people have 1 year of experience 10 times.
- helboi4 3y ago
  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.
  - whstl 3y ago
    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.