Hacker News Reader

Comment by noduerme | Hacker News Reader

I've worked for a lot of unsympathetic people who didn't put themselves in my shoes, or who had their own personal issues that caused them to tonelessly say degrading things to me as a young coder. But I was lucky enough - or sympathetic enough - to get through to them as their employee with questions that made them see me as someone they could help and improve. This wasn't even their choice; it was mine, to tease those explanations out of them. I sure wish most employers and corporate structures had this sort of kindness in mind, but on an individual level it really comes down to forming a co-sympathetic relationship (as an employee). Now as a boss, I find myself extremely sympathetic to anyone who asks intelligent questions, but very short on the fuse with people who don't take the time to look things up for themselves. Is that me becoming more of an asshole with age? Or is it that I put myself through the process and I expect others to as well?

View on HN

> ...it really comes down to forming a co-sympathetic relationship...

Trust?

Young me was told that trust was crucial to effective management, high performance teams. Ok. How to do that? What does that look or feel like?

I've had exactly one trustful peer relationship. People used to joke that we acted like a married couple. We have no idea why we just clicked. We accomplished so much, worked so hard, had so much fun. Sadly, once you experience authentic trust, any thing short of that just feels like a waste of time.

I've trusted maybe 2 of my many bosses.

You'd have to ask my direct reports if any of them trusted me. I hope some would say "yes".

Older me reflecting back on all this stuff...

I had hoped life would be more win-win, a la Robert Wright's book Nonzero. But it was mostly transactional relationships, power dynamics, zero sum games (win-lose), so much energy wasted on guarding my boundaries, and then getting exploited whenever I didn't.

Basically, it all sucks.

My experience is the same. As a young engineer I got things to work on time and with minimal issues. My reward for being good at my job is to be loaded up with work from my boss and by my peers and even by those who were outside of my team. When I refused because I said I have my priorities. I was called out for not being a team player. I once even had a come to Jesus meeting by someone who was not my boss for refusing to work on his emergency ticket. This tech lead who was on another team was later forced to apologize to me.

Essentially there are two classes of people. Those who want to master their craft and develop their skills. And those who think their job is boss around others and that other people exist to make their life easier. I have noticed this sense of entitlement is especially common among younger engineers who think I owe it to them to mentor them. Hmm. I don’t owe you anything.

Could you say more about that trustful relationship? How did it start, did you have similar backgrounds, was it work-focused or get into personal stuff? Signs to look for/ aim towards for people who aspire to meaningful, trusting relationships.

Not the parent.

I have noticed there are two kinds of trust relationships. The first is pure office politics. You have long term creditability, therefore everyone knows not to try their manipulative tactics on you, engage with you professionally, and therefore you have a trust relationship. This is akin to being a made man.

The second kind of trust relationship I have encountered are with very religious devout people who believe they are doing God’s will to help others and with people who have sense of humor that builds people up not take them down. They don’t take themselves too seriously and just want do a good job and get along with everyone.

I'll try to be brief.

Mid-90s. Mid-sized company. Very engineering driven. Founder President was unteachable, largely absent, prone to drive-by management (disruption). VP of Sales was a complete dink ("All I want is free, perfect, done yesterday. Is that too much to ask?"). "Visionary" VP of Engineering with goal of being Director or better at Microsoft, most of his time building a fiefdom, protected his power by encouraging infighting. Tech Support was very powerful and in open rebellion.

I got things done. Mostly by being a bulldozer. Not popular. Eventually promoted to Engineering Manager over a suite of products. I was very interested in empowerment, process, execution, shipping products customers wanted. Major influences were Luke Hohmann, Deming, Eli Goldratt, and so on.

I had a crazy notion: instead of engineering dominance, model team after quality circles (a la Ford Motors) and the US Constitution's balance of powers. So initially, Marketing role would own scope and price, Engineering would own cost and schedule, Quality Assurance would own releases. Eventually expanded to include Sales, Tech Support, Docs & I18N.

Through pure luck I got paired with a skilled Marketing person, who also had domain expertise, first time doing software. She wanted to learn "software" and I wanted to learn "marketing". So we taught each other, mostly by example and answering questions.

Empowering QA assurance was a lot more troubled. Wonderful person, we got along very well. But she struggled to balance my way of doing things with how her peers (and their teams) were doing SQA. In a nutshell, I wanted her to be in charge, whereas her peers were stuck in Kem Kaner's mentality of victimhood and self-disempowerment. For example, I insisted we have our own test lab, she balked when her peers insisted on a shared lab run by the test group. In other words, I wanted a product & team focused org chart, and the rest of the company wanted to keep functional silos.

[Per the E-Myth's advice, I served the role until I could hire someone. So I did my own thing. Think "The Joel Test" and Code Complete, back when that stuff was controversial. The lightest weight ticket tracking system. Automated builds and testing. Front loading as much work as possible (eg always have a shippable product instead of Big Bang integration at the end). I say to show I took SQA very seriously and walked the talk.]

So the way that it played out, my Marketing Manager and I were on the same page. Meaning she could speak on behalf of both of us. She could make decisions without my input. She was savvy enough to know when I'd want to be in the loop. And vice-versa. In turn I went to trade shows, met with dealers and customers, and interacted with Marketing and Sales (in her absence) as her ambassador. We prepped each other, took notes, then debriefed.

I didn't have that relationship with my QA Manager, much as we tried. And we tried. Despite a great personal relationship, work wise we just ground gears.

When I switched to another team, to bring another troubled product back from the dead, my team was eager for my replacement, who was "nice" and very well liked.

New guy promptly disempowered everyone, threw away all of the team's processes (eg speed triage), became the sole gatekeeper (aka control freak), morale tanked, releases stalled.

About 3 months later my former SQA manager took me to lunch, told me she finally grokked what I was trying to do, and that she'd rather work her ass off shipping product with an asshole like me than be a drone working for a nice guy.

Bittersweet.

As for the people who worked for me, my job was to protect them, do whatever it takes to help them succeed. Most did great. Some excelled. Others were total time sinks, causing endless heart ache. Like I said previously, you'd have to ask them if any of them trusted me.

The managers I trusted treated me the same way. Just tell me what needs to be done, remove any blockers, help me stay on track. That's happened only 2 or 3 times. Everyone else needed constant upward managing, or worse.

Thank you!

Most of the time when someone ask a question answering it isn't very easy. You have to look things up, go through the code, maybe run some test to figure out what the solution is. That is how you work with the code and that is what they need to do to work in the code.

The problem here is that they expect that answering would be easy for you, but it is not, so you tell them to go figure out themselves since you don't have the time to do all that work for them every time they get "stuck". Since in fact, you yourself are "stuck" like that every day, being "stuck" is a major part of being a software engineer, it never ever goes away and junior engineers often thinks that being "stuck" is bad. It really isn't, that is what your life will be from now on, you just got to learn how to handle being stuck and nobody can really teach you that.

Anyway, when you dragged the answer out of those other people you did the work to unstuck yourself. Those people couldn't just have told you the answer from the start since they didn't know until after the long discussion with you, that discussion was the work. Now that you are on the other side you get a lot of "unintelligent" questions, ie questions you can't easily answer, and therefore feel frustrated with these new engineers. It has nothing to do with kindness, its just that the junior engineers needs to understand that finding the answers to these questions is their job and not something that just juniors have to deal with.

Example with overly simple question:

Junior: How do I center a div in html?

Senior: Just look it up on Google.

Junior: Why can't you just tell me?

Senior: I just told you how to do it, that is what I do every time I need to center a div!

I agree and want to add a few thoughts.

I've found the best way out of these kinds of questions, where the asker hasn't put in even the lowest level of effort is to say, "I don't know, but here's what I would do first to figure it out." Most people will be glad to find out there is a path forward and take it themselves. If they're not willing to pick it up there and do the thing you've suggested then you are dealing with someone who doesn't value your time and setting a boundary is the right thing to do. The kind way to respond at that point is simply, "I'm sorry I don't have time to figure this out right now. You can try [the thing I suggested] and come back if you still have questions."

The crux here is there is no kind way to just make people go away. If your role is mentoring, and any of us with experience should be in that role at least a little, then some of your time is going to be spent on this interaction. The most valuable thing you can do for yourself, the other person and the company is lead them toward finding the answer themselves. That's going to require a balance of helping and honestly and kindly saying no to doing their work for them. Not easy.

"I put myself through the process and I expect others to as well". Resonates with me. I expect people to at least process things to a degree on their own so that we can have an intelligible conversation.

> Or is it that I put myself through the process and I expect others to as well?

I have no answer for sure but I've seen this pattern in just about every aspect of life. Older people who did X are very very angry if younger guys refrain to do X

I think it's fine as long as both sides are aware of the expectations. But managing those expectations might be better suited to a manager position, rather than the senior/junior developers actually involved in it. The job of a manager is to enable people to do their job.

The job of any person whose output other people depend on is to enable those people to do their jobs.

A junior software developer's job is to enable customers to do their jobs (as customers). An architect's job is to enable developers, sysadmins, etc to do their jobs. We are all part of a team, and we all depend on each other.

"do their job as customers" yeah that totally doesn't sound like bullshit :D

> Is that me becoming more of an asshole with age?

Sort of, but I don't mean that in a bad way!

Many of us experience rough times coming to terms with how to function in an organization and how to develop professionally. In my opinion, after that experience becomes internalized we end up behaving in various different ways when the tables are turned and we become "part of the landscape" for newcomers.

Some people believe that others must face the same challenges they had, that suffering is not only inevitable but required as part of the path to mastery. It's very much like a Calvinistic way of thinking where people must prove themselves worthy before they are given consideration in the eyes of god (or in the case of a workplace, senior practitioners). I think of this as "the stackoverflow" approach. It helps people out because it forces the student to formulate valid questions and uses reward or punishment as incentives.

Others, seem to model their behavior in an opposite way. They remember the confusion they experienced and strive to help out the newcomer. They try to provide some measure of "guard rails" so the newcomer doesn't have to crash and burn as much as they did. These people tend to take the "answering" of questions more seriously, and often end up asking questions to the student instead of just answering, evaluating their responses, and then asking more questions. This is like a Socratic approach and it challenges the student to come up with their own answers. It ALSO works.

Which of these is correct? Neither (or both). They're just ways of responding and everyone has encountered both modes and probably behaves in either way depending on the situation. Some of us have personalities that naturally tend towards one or the other.

I think that whatever approach is taken, it is super important to not dismiss the student. People do need encouragement, not necessarily with every interaction, but they need to know it's OK to "not know" and that their suffering is something we all experience. This helps to create a sense of psychological safety.

It's an indicator of a lack of empathy, which can come from many places. You need to find empathy for those people who don't take the time, and barring that, compassionately help them reach an empathy for you and others they might be frustrating.

I have a short fuse any time I think people aren't helping their coworkers or don't put in the work so others can do their jobs, and it's making other people quite frustrated. For me it comes from a couple places (perfectionism, ego, self-criticism, differing priorities). I'm still struggling with it, and I'm very lucky my boss is very understanding.

I don’t agree. People are hired to do a job. If they can’t do a job because they don’t have the skills and must depend on someone else to help them, they should not have been hired in the first place. This has nothing to do with empathy. This is common sense. If you can’t do the job, why are you here?

> If you can’t do the job, why are you here?

Because you're the best the company could find and afford to get into the position to maybe fix the problem. Lamenting an unskilled workforce or not having the perfect developer for a given task is just professional entitlement.

Your job is to work with the team and the resources you have. Why are you daydreaming about things you don't?

There's often an issue where people do not make any progress towards becoming useful, and do not show any promise of being capable of becoming a net contributor.

At this point, you can fire them, silo them off the critical path, move them into other work, or just keep jamming a square peg in a round hole. But it wears on the people who have to take up the slack and do, or re-do, that person's work.

I get things done with the team I hired. I don’t hire people who can’t do their jobs and question those who hired them.

Common sense suggests that > 95% of companies don’t have access to the highest grade of engineers. If we work for companies like that, our job is to work within the system and get shit done. That often means being kind and mentoring.

Reply on news.ycombinator.com