Hacker News Reader

Comment by tomc1985 | Hacker News Reader

tomc1985

It is weird to me to see people talking like this. Throughout my 10+ year career as an SE, all the way from junior level to senior-plus, customer- and product-mindset thinking has been seemingly mandatory. Like how would I even write the software if I didn't understand what they wanted? What would I even do/what should I even write?

We need to remember at all levels that it is people that use this stuff. Coincidentally, we are also people. So we should all be able to think as them.

It is weird to me to be separated from my stakeholders. I can't say I really like having a PM in between me and them, other than having them sit in meetings instead of me.

View on HN

> Like how would I even write the software if I didn't understand what they wanted? What would I even do/what should I even write?

Whatever the ticket says. I have done plenty of work that I couldn't tell you where it fit into the product or what button one would click to make it run as we otherwise had unit tests to verify it.

It sounds incredibly demotivating. Is it?

I save that passion for personal projects. After all, the work is buying someone else a nice house and the new electric Delorian.

Well, unless your product makes a real positive impact on people's quality of life or the environment. :) Maybe I'm just fortunate to have such an employer. (Of course my CEO also gets rich in the process, but that's not the only "mission".)

Why should it be demotivating trying do something perfectly as requested?

Many of us, including me, come from freelancing, and perhaps that trained many to answer most customer requests with "ok but what you really want is...", but in a company where there are people doing that as their job... Why bother?

Actually I would even go further and argue that too many passionate developers talking product management in every refinement meeting is a big inefficiency, and depending on the company size, sometimes even one is one too many.

lol because developing products that users want/work well for users is 100x more important than writing code.

Protecting the environment and sustainability is also 100x more important than that. Do we ever draw a line where our responsibilities end or as developers do we have to gather knowledge and make the best decisions until we reach singularity or the heat death of the universe?

Delegating is okay, or you burn yourself out.

Not at all. There are plenty of technical challenges that must be resolved within that. I can be fascinated by the plumbing without really understanding what the data is for.

A lot of it is also personality. I am odd. Very odd. At times Sheldon Cooper odd. Know the exact seat I want on a 787 vs an A220 odd. That makes my empathy for users awful. I will spend tons of money on pain points in my life that make everyone else think I am nuts. I will completely ignore areas of life that are top priorities for most people. I obsess when making decisions and willingly read reems of documents to figure out all the rules.

There are so many things that I do that normal people do not do. Because of that, I cannot create mass market products.I do not think anything like a typical user. I know my limits there.

That's fair! Thank you for the insight.

Empathy/sympathy are important factors here. As a fellow weirdo I do not see my weirdness as an excuse for being unable to 'walk a mile in their shoes'. There are lots of people around us constantly transmitting their emotional status, I see no reason to not pay attention to that.

I have consistently found myself unable to do it well, so I outsource it. People may transmit, but I do not receive it with any meaningful accuracy.

just because you're odd doesn't mean you can't empathize with others. that's a huge cop out.

Fundamentally any feature request is just an engineering problem. Sometimes they're interesting, sometimes they're not. If you trust whoever makes these issues on your board (or whatever it is you use), why would it be demotivating? You know you're building stuff folks want, because making sure that's the case is what the person making those issues is trying to do.

If you can't trust your coworkers, every workplace is demotivating.

This is a fair argument. Thanks for engaging.

That sounds disastrous. "Whatever the ticket says" is often ambiguous, poorly-written, or just plain wrong (in terms that the request is documented incorrectly and the requestor is not actually asking for what they want). Sometimes someone with technical inclinations gets too smart and thinks the solution is X when it is really Y.

In my personal experience, it is much easier to clear this up going to the requestor itself, rather than asking a PM to clear it up. I ask them high-level questions like, "so, what is it that you really want here?" to try and suss out what the actual deliverable is.

But I agree that if you have too many projects on your plate this is untenable. But then devs having too many projects on their plate is a pretty poor situation and is indicative of bad management.

It is only disastrous if the PM screws up. It is certainly more brittle though as there is a single point of failure. You also need devs willing to persist in a social endeavour in the face of uncertainty until they get something solid and many are not.

nope it's always disastrous. PMs don't know how to code.

Because we are supporting too many products as it is and they are always asking for more?

I get snippets from users, but I support so many different types of users and roles, it would take probably 6 months of only training to have a rudimentary understanding of all of those roles and the products we support that they use.

And we implement SAFE "agile" and most of the time it seems like we are insulated from actual users. I got in hot water because I had the audacity to talk to a user because the client kept changing the flow after the inception meeting that ended up being the client solutionizing the project.

Reply on news.ycombinator.com