Ask Lemmy

As an engineer, I hate having to repeat the same thing again and again so take notes and make sure you understand them.

Secondly know the product or project intimately relative to your level. For example if I work on the project and I know it from the code and infrastructure and everything else in addition to how it works for the end user then the least I expect is that the person asking the questions has used the software with a demo account on UAT or something so that my answers will not go over their heads. Knowing the product will also allow you to talk to clients better and you will know what it can and can't do.

I'm ok with someone if I see they are willing to make the effort regardless of their level, if someone is coming to me to do their work for them , then I lose my patience fast and will very soon be less helpful and prioritize my actual work over their bs.

Finally as I said we are often overworked and not looking to have more things to do. We are the ones that have to stay late to fix someone's mess or get called to patch an emergency zero day in some software used by the company on a weekend. In addition we support everyone else as without us there is no product and no jobs for the rest of you. We are at the bottom of the pyramid holding the rest up with the CEO being the prick at the top.

Finally dont just engage when you need something, get to know them and see if you can help them with something. Maybe a heads up about a project or client to avoid or some thing.

It is good that you want to bridge the gap and I wish more in your position would do so.

The deeper I get into a subject involving engineering, the less I can relate what I know effectively. If I've done the thing many times, I can talk about it more freely.

It boils down to, "I don't know what I don't know." The only thing I can do is explain the long path of stuff I've figured out in order to get where I am at in my understanding. I don't have a clear overview scope. I'm aware I have likely made mistakes even within what I know.

If you are asking me for official statements that can come back to me, I'm going to be extremely cautious in what I tell you and only speak about things I am absolutely sure of and have triple checked. Most of what I'm sure of is going to be unhelpful surface level information. Professionally, telling you anything that could be wrong is career suicide. Reputation is the currency of an engineering career.

The engineers have their own tasks and deadlines to deal with, why are you talking to them directly to get the information you want? You need to talk to their project manager to either give you access to the database in question, write a tool that generates the report you need or write a one time query to get this information. All of these things take time and need to be planned and resourced. I hope you're not just walking up to people and asking for random lists of customers that ordered more than once in the last year or whatever?

Have you asked them why they are reluctant to turn over the deets?

I’ve certainly withheld info because explaining DMARC is a lot more time consuming then just saying it’s a special type of spam filter.

please give an example interaction that was difficult?

As an engineer with almost thirty years of experience, I don't want to be on the hook for telling someone the wrong thing. Also, if you want an estimate there are lots of engineers who won't want to give an estimate of 2 months when you're expecting 2 days. Then we have to explain that the entire app is a fucking unmaintainable shit show because we've been doing two months worth of work in two days by cutting corners and writing shit code and we know it.

Also they could just be shy introverts. But it's probably a reluctance to commit themselves.

I say all this like a universal truth, but just by reading all the responses here you can tell it varies from person to person. You have to assess your team and figure out each individual. My experience is it's a trust/comfort thing, but that may not be your case.