Comment by Fr0styMatt8 | Hacker News Reader

Comment by Fr0styMatt8 | Hacker News Reader

Parent Full thread

Here's what I want as a software engineer. I want to be respected for my opinion.

If I say that a customer change is a complicated task, I think it's great if my manager engages me and takes me to task on why I think that is -- as long as this is done from a position of respect and not from a position of disbelief.

When I say "We are likely going to have to implement X, because the customer won't give us an answer on it and just like the last feature, they said it was fine not to have right up until the last minute when it suddenly wasn't", I DON'T want the response to be "So, if we don't have to do X, it should only take a few days, right?".

In case it's not obvious, what I'm dealing with right now in my job is management that expects me to be up front with them but can never seem to believe what I say when I am. It's like they take the most blindly optimistic interpretation of what you say, even though that's not what you said, then hold you accountable for what you didn't say when the shit hits the fan.

If I went to my doctor and he said "You need to take this medication or it's 90% likely you'll get sick", most people would think I was an idiot if I decided to decline the doctor's advice, then complained that the doctor didn't know what he was talking about because I got sick.

So yeah, as a software engineer I want to be respected as an expert in my domain in the same way that people generally don't think it's okay to second-guess their lawyers/doctors/basically any other profession it seems than software engineering.

/Vent is now over :)

I guess it's time to stop calling engineering estimates an "opinion!"

But yeah, I see the same thing all the time. We say "this isn't going to work unless we do X,Y,Z," which of course aren't done, and then of course things don't work out, and it's our fault. I blame it on a lack of intuitive understanding (and pressure to cut costs, resulting in a RDF).

Most people would understand that a bridge won't hold if you left out all the rebar from the structure, even if it wasn't visible from the outside. With software, though, people's eyes just go blank at some point, and they simply ignore everything and piece together what they want to hear. "X dollars in Y days, got it."

You phrased that way better than I did. That's exactly the kind of thing I was talking about.

You are reversing authority. It is the executive whose system you are computerizing who needs to state how things should work - and your job to make it work. If it takes longer than the executive thinks it realistically take, if you can't explain it to him in a way that makes him a master of the situation: you are not doing your job.

So even arguing from the perspective of "my opinion must be respected" is, to me, an indicator of your own failings as an engineer. Its always the engineers job to make sure the system they are building, works for their users. Your boss is a user too.

If you have to have an opinion be respected, you haven't been writing your docs. Opinions don't build working software systems - written materials do. So making sure they're read and understood is actually your job, and complaining about others not having respect for this fact, means you're not doing a very good job.

Just my opinion. Respect it or don't.

That's a fair criticism and I do find communicating WHY something is difficult, especially to a manager who doesn't code, to be a challenge at times. It is something I'm conscious of and I'm working on. I agree that respect has to be earned.

For what it's worth, I'm not talking about dictating what the customer's requirements should be (as in "That's a stupid idea, I think this is what you should do instead"). I'm talking about "This will take three weeks even though it looks like a simple change because there are still plenty of unknowns" ... "But we have already promised the customer that this will be done in a few days (without consulting engineering), can't you just do it quick and then we'll fix it up later? (but later never comes)" type stuff. Or never being given the time to implement a test framework or refactor and then being criticized because customers find bugs. That kind of thing I find difficult and frustrating.

I understand you. But I still really believe that if you're in this situation, you've lost control of your customer - and this is your job, no matter what. Sure, users are stupid. We know that. But making them smarter - whether its through a smart application, or a smart process, or smart documentation, or smart other-enlightenment processes .. this is the job of good engineers. Strive to be better at educating the user and you will become a better engineer - its just a truism I've noted.

(Not to say it isn't necessary sometimes to get the gripes off ones chest.. just that it should be seen as an indicator of a failure, somewhere, to engineer solutions for the user.)

So... what happens when the client says "I want a database that's C, A, and P" or somesuch, and then just doesn't believe you/ignores you/etc. when you explain what's wrong with their request? Presume "working in another company" isn't an option, because, in your experience, every other company will do the same thing to you.

I understand informed consent—a doctor can't shrug off the responsibility to get the patient informed enough to say yes to what they're doing with a "just trust me." But sometimes what the user is paying you for is, exactly and precisely, to not have to learn X in order to do X.

Reply on news.ycombinator.com