[rubyn00bie]

Learning to let my go of my ego and trust...

Understanding that delegating tasks, instead of doing them myself, was of the utmost importance the more people I managed... especially, greenfield work. Literally: do not steal the fun. This also means inherently trusting people, and if you can't do that you shouldn't be working with them. two important notes about that:

1. If you just thought of someone you can't trust instead of thinking about how you can give more trust to people, you just had your ego stand in the way of mutual success. You are a shitty manager, and today is hopefully the first day of you recognizing that and learning to trust.

2. When people don't deliver what you expected, it's because you did a shitty job of communicating it to them. What seems obvious to you after 45 minutes in a meeting with three other people already prepared for the topic will most of the time seem obvious to no one else. If it does, I can almost promise, their vision of it is totally different than yours. Learning to work through the defining the problem (that includes asking "does this problem exist?") and then guiding solutions (we have x days, engineering hours, etc available) to ensure they meet the needs of the business. If no one but you delivers things correctly, you're a shitty manager, and today's hopefully the first day of you recognizing you need to learn to communicate and trust.

Not many people are lucky enough to be told so plainly it's their ego, but it's your ego that causes your team to fail. Maybe it's your boss's ego that's causing you to fail... I was told plainly to my face to not let my ego get in the way of the goal... and yeah it punched me in the gut too, so if you're hurting, or in denial know it's okay. We all have to grow, it's worth it.

[fighterpilot]

  > When people don't deliver what you expected, it's because you did a shitty job of communicating it to them.

Why is this necessarily the fault of the manager's communication skills?

Sometimes the person sucks beyond repair and needs to be fired.

If you have a competent person who didn't deliver what you expected, then yes, it's probably the fault of the manager's communication. Not so for the lower-end of that competence spectrum.

It might still be the manager's fault for hiring that person in the first place, but that's separate to it being their fault at not communicating properly.

The shitty job here is not firing that type of person quickly enough, and misdirecting the blame towards your communication skills.

EDIT - edited the first sentence for clarity.

[takeda]

If requirements were provided and person didn't fulfill them, they did a bad job. If requirements were fulfilled, but you aren't happy with the result, then you did a bad job.

[fighterpilot]

> If requirements were fulfilled, but you aren't happy with the result, then your requirements were wrong.

Isn't it possible for a dev to fulfill requirements but still deliver a bad result as measured by subjective (but important) things such as code smells, bloat, crappy algorithmic logic, and so on? Or do you think managers need to spec things out in such strenuous detail that surprises (but also, to an extent, autonomy and ad hoc decision making) aren't possible?

There's also the case of R&D roles where it's hard to spec things out exactly in advance, and you're partly relying on the employee's ingenuity.

[takeda]

You're talking about completely different thing than what OP was talking about. It's about developer having a different vision than you.

You either need to accept that someone sees the problem differently than you and accept their solution, or if it is something important to you, you need to get better at explaining your vision.

Anyway, back to your requirements, as you pointed those requirements are subjective. If those are important things you should still outline what's expected. You don't have to do it for every project, and can be when person is being on-boarded.

[fighterpilot]

Right, in that case I'm in agreement, if the employee didn't deliver what was expected because they didn't understand (or weren't convinced with) the manager's vision, then that's most likely the fault of the manager's communication.

[Aeolun]

> If requirements were provided and person didn't fulfill them, they did a bad job.

Requirements covers a VAST range of different garbage that can be provided to someone under the guise of letting them get on with it.

[irrational]

This happened to me this past week. I built exactly what the spec said. They came back and said it all looks good, except we expected this to be that. Um, nothing about that was in the spec, nor was it ever mentioned verbally in a meeting. Making the change from this to that will require everything to be redone since it requires fundamental changes. I would have built it differently had it been communicated to me from the beginning. Apparently it didn’t occur to them to mention it. But they really want it. So I’ve started rebuilding it. Sigh.

[brazzy]

A key skill of a senior developer is a sixth sense for this kind of unspoken requirements, and asking questions to flush them out. Not always possible, of course.

[tstrimple]

This is why it’s important for devs to understand the problem being solved with their code, not just blindly executing to a spec that everyone knows doesn’t spell out every last detail the customer is interested in. Stop treating devs as fungible spec builders and more as partners of the business so they can shift from building against specs to solving real problems. The devs who have this “sixth sense” are finding a mismatch between the spec and the underlying business problem problem they know they are trying to solve.

[nine_zeros]

> A key skill of a senior developer is a sixth sense for this kind of unspoken requirements, and asking questions to flush them out. Not always possible, of course.

While true, a key requirement for even senior developers to function well is good management or a good team lead.

If effective management doesn't exist, the senior engineer should be made manager/team lead since he's doing that work anyway.

On the other hand, if management is micromanaging, then the responsibility of clarification is on the micromanagers.

Management of knowledge workers is a hard job. Most managers are incapable of understanding their reports and understanding their OWN standing among their reports.

[darkerside]

It's always shades of gray when it comes to management. You need to sort the grays into blacks and whites, but don't forget that they are gray.

[erikpukinskis]

> Sometimes the person sucks beyond repair and needs to be fired.

Which is... also the responsibility of the manager. Q.E.D.

[fighterpilot]

I edited my first sentence in my post to make what I'm trying to say clear, I realize it was worded in a confusing way.

I was trying to say that it's not always the responsibility/fault of the manager's communication skills specifically.

[goto11]

In management you can't really deflect responsibility downwards.

[fighterpilot]

I'm not trying to suggest that. I'm suggesting an accurate diagnosis of the mistake that was made by management.

In the case of my example above, it was a failure of management to hire a sufficiently competent person, or a failure to fire the person when their lack of competence became apparent. It wasn't (in my example) a failure to communicate requirements properly.

[goto11]

OK I get what you are saying, but if a manager is not able to communicate clearly enough that employee understands the directions given, then it is the fault of the manager.

If the employee understand the task given but does not have the skill to carry it out satisfactory, then it may be a question of the competency of the employee.

[Buttons840]

It doesn't matter who's fault it is. Communication failed. You can fix it by changing yourself or the other person, but only one of those solutions is within your power.

[yowlingcat]

> Sometimes the person sucks beyond repair and needs to be fired.

And who does that person report to? Who made the decision to hire them in the first place?

[fighterpilot]

That's why I said "It might still be the manager's fault for hiring that person in the first place"

[yowlingcat]

First of all, nobody "sucks beyond repair" -- everyone can grow and evolve although some people may start at a point where the company doesn't have adequate enough resources to make an ROI off of its investment.

The problem is, some people have a fixed mindset rather than a growth mindset because they've never seen anything different so they think it's impossible. When you say "Sometimes the person sucks beyond repair and needs to be fired" it ends up functioning as a red herring to deflect away from poor people leadership. It's a naive excuse made to hide a lack of understanding regarding how something really works.

To figure that out, let's ask this: how do you think the manager hired that "wrong" person in the first place, and how do you think that person ended up in a place to end up failing?

My point is not to be socratically pedantic here, but to point out that communication is /hard/ and often times an inadequate deployment of it is at the root cause of these kinds of failures. What kinds of communications could have gone wrong here?

1) Failure to adequately communicate with higher ups about headcount, business goals and necessity/capability to deploy extra headcount

2) Failure to adequately communicate requirements for the job before hiring

3) Failure to adequately communicate during the interview so as to properly assess candidates

4) Failure to adequately communicate expectations, progress, onboarding and plans after a candidate onboards

Guess what happens if anything about this chain of processes is broken internally? The candidate will fail, and due to circumstances out of their control. And then they will move to a more functional organization, and wonder why they ever wasted their time with this one.

Now, whose responsibility is it to make the right judgment call about that? Whose responsibility is it to have the right internal /communications/ to make sure the decision is well thought out and solid, to make sure it is brought through to fruition successfully? Who reaps the ultimate rewards, and who ultimately shoulders the greatest burden for mis-execution?

Not the IC. It is leadership. This isn't rocket science.

[iamhamm]

Could be the current manager or could be a past one.

[throwaway98797]

you are not as bad as the last person who miss understood you.

if people generally understand you and one person does not its them. if most people don’t understand you its you.

[takeda]

Eh, that describes exactly my last job (which wasn't bad, I liked my coworkers, but my last manager made it a horrible experience), worst job I had so far.

He wasn't bad as an engineer, but he had this crazy OCD to a point that even keys in YAML file should be ordered alphabetically.

He had his vision how things should be, and how he would implement them.

First, he was not happy that my solutions were done differently than what he would do.

Then, when I learned about that he wasn't happy and tried to do it the way he wanted by asking him question about it he told me that I required hand holding and as a senior should not need that. Yes I'm senior, but not a mind reader.

I would think that someone who majored in psychology would be better at something like that, but I guess the only thing he learned in psychology class was Socratic method, which he constantly overused when talking to others.

He though he was being clever but only made me think (because I couldn't say it to his face): "just fucking tell me what the fuck you want me to do"

Ugh, I'm so glad I don't have to deal anymore with this BS.

[johnchristopher]

> He wasn't bad as an engineer, but he had this crazy OCD to a point that even keys in YAML file should be ordered alphabetically.

Eh, I am guilty of that (for myself, I don't run around other people's code).

I don't know if it's OCD but I clearly remember the moment I decided to order keys (in yaml, json, etc.): after a debugging session where I lost time because I was scanning whole lists with my eyes, looking for a particular key and thought "it'd be easier if it was ordered according to alphabet and not domains of concern".

Wasn't there a debate/online conversation about `girly code` a decade ago ? About tabs, alignment, etc ? Thank you prettier :).

[kubami]

IMHO having this as a rule that keys in dictionaries are sorted alphabetically can be a valid rule. But this should be enforced in tooling, not "rules", and not through micromanagement. Much like using opinionated code formatters - like `prettier` you mention. It makes lives of everyone easier down the line.

Sometimes this comes from years of experience (mostly pain ;)). Some leaders, while coming from a good place - I want to help you, and others, avoid pain in the future - communicate it very badly - do it like that... because I say so!

[goodpoint]

> having this as a rule that keys in dictionaries are sorted alphabetically can be a valid rule

Ordering keys to prevent randomness is very helpful to spot changes when using "git diff", doing code reviews, comparing files side by side.

Often it helped me spotting bugs due to a missing or unwanted element.

I wish code linters had enabled by default with the ability to disable it with some simple syntax.

[johnchristopher]

I had a look at prettier's github issues in the mean time and

> No, prettier tries not to change the semantics (specifically, the AST) of the program, and sorting imports/keys could break that guarantee. See here for more details and context, as well as links to similar/duplicate issues: #1684 (comment)

it makes sense not to make it a default.

https://github.com/prettier/prettier/issues/2460 https://github.com/prettier/prettier/issues/1684#issuecommen...

[Buttons840]

I think another option is to just let it go and you can "fix" it later if you want and have the chance. Just put it in a "cleanup" commit or something. Don't be passive agressive about it, make it a team practice. Sometimes people will change the style of your code, that's ok, it's not a slight against you.

However, if you get in a situation where people are changing styles back and forth then you need to talk it out. E.g. Alice inserts a blank line, Bob removes the blank line, Alice inserts the blank line again - time to talk about blank lines and code style.

In this case, if Alice sorts the dictionary keys and Bob couldn't care less, it seems both can have what they want by simply letting Alice sort the keys. And if it becomes a common thing instead of a one-off, maybe talk about it.

[darkerside]

That makes it way easier for one person to find (who actually knows the names they chose for the keys) but just about impossible for everybody else.

[sunir]

Girly?

[johnchristopher]

Yes, see https://headrush.typepad.com/creating_passionate_users/2006/... and https://signalvnoise.com/archives2/beautiful_code_testfirst....

I don't have good memories from the whole thing.

[sunir]

Thanks for posting the context for such a bizarre description. I can assure you that it's not worth continuing that train of thought.

However, if you want a positive, constructive frame the goal is self-documenting code. In that vein, here is a set of ideas I made a major contribution to amongst many other serious-minded software engineers.

http://wiki.c2.com/?SelfDocumentingCode

[jrh206]

Haven’t read the articles, but wow, this idea needs a new name

[animal_spirits]

Why? Does something being "girly" strike some kind of negative emotion? I don't think it is bad to associate organized and elegant code as feminine. You probably should read the article

> And there you have it. I think "girl code" is quite a compliment. Because caring about things like beauty makes us better programmers and engineers. We make better things. Things that aren't just functional, but easy to read, elegantly maintainable, easier--and more joyful--to use, and sometimes flat-out sexy.

[nine_zeros]

F. This is my current manager.

I feel like this is more common among insecure managers than with secure managers. The insecurity shows up in micromanagement. Micromanagement takes many forms, all the way from verbal status updates to toxic code reviews to lack of coherence in project plans or career plans.

Until this recent manager, I never truly understood what micromanagement and insecure management meant. Maybe I was lucky to have good experienced managers in the past. Insecure micromanagement truly crushes my motivation to work.

[darkerside]

As someone who suffers from the same neuroses, I would push back on some of this a bit.

If you haven't built trust with every person on your team, that doesn't make you a shitty manager. The more people you can work with and trust, the more effective you may be as a manager, but don't let a counterexample serve as proof positive that you suck. Trust is a two way street.

Sometimes people underperform for other reasons that have nothing to do with you. They may have a different perspective, or they may just be having a bad day. Or they may have family or health problems affecting them. Or, they may actually just no longer care or not be good at their job.

[ISL]

For the first point -- I believe that OP wants the manager to extend trust as a mechanism and path toward both a trusting relationship and short-term performance.

For the second -- it is on the manager to know enough about the reasons affecting their report's performance to be able to adapt before the team underperforms. (and it is on the report to surface that information quickly so that the team isn't compromised)

[Chozenlaruso]

How can this be accomplished? I take great pains not to get involved in my employees' personal lives. When they call out sick, I never ask why. While I do ask if "they need anything", they never have to tell me what they are sick with, or if they are even not sick and just need a day. I assume they are adults who are competent to manage their own time.

I once worked with a manager who would always ask for details like "oh you have a headache? Do you have a fever?" While I think his intentions were good, and that he just wanted to show concern and even offer support or advice, I always found the questions incredibly invasive and a violation of my privacy.

My team knows that I will always listen if an employee wants to share details of their personal lives (upto anything that crosses the line of appropriatness for work), but I would never pry.

So, in this example, I would never know an employee is struggling with a personal issue, unless they broached the subject with me.

[darkerside]

I don't think it's prying to care about your employees and want to make sure they are ok. Asking for at least first level details should be done IMO.

[xxxtentachyon]

What do you consider first-level details? It’d be super put off if my boss asked me if I had a fever when I emailed in sick.

[Bootvis]

“Nothing to serious I hope? Can I be of any help?” works for me as an employee.

[darkerside]

I understand the first point, but I disagree that is always going to be possible or the correct path. If you blindly trust every employee, you will eventually end up hurting the company, the employee, and yourself.

Second point, sure. That's the ideal. But it's not always going to happen, and you need to be able to deal with that situation to be a well rounded manager and leader. IMO.

[psds2]

I didn't see any discussion of blind trust. The first point was about focusing on looking at the trust and figuring out how it could be built up.

[darkerside]

And I'm saying there are points where it doesn't make sense too do that. I believe that's the most effective path 90% of the time, but you are not a complete manager if you can't deal with the 10% edge cases effectively.

[philosopher1234]

Thank you for being a voice of reason. Puritanism is so popular on HN.

[arendtio]

> Sometimes people underperform for other reasons that have nothing to do with you.

You can still try to find out what causes their behavior (by showing interests into their perspective) and may be able to help them and therefore the team.

- If they have a different perspective, it should be helpful to listen to their perspective.

- If they have a bad day, it will go away.

- If they have family or health problems, you might not want know the details, but simply knowing that a person is going through a difficult time might give you enough information to know how to improve the situation.

Even if you are not the cause of the situation, you might still be able to improve it as a manager.

[darkerside]

I agree. If you just assume it's your own bad communication that's at fault, you deny your report the opportunity to ask for help they may need..

[hummerbliss]

"Learning to let my go of my ego and trust…”

This is the quality I learnt to look for in a leader (I am not a leader but worked under few good ones).

I also noticed how good leaders never take things personally. They quickly move on and not hold grudge. I am amazed how good leaders are able to do that and in doing so inspire me to do the same.

[globular-toast]

I don't think trust is something you can just decide to do. It's like loving someone or believing something. You either trust them or you don't.

Is your advice to pretend you trust them? Some kind of "fake it til you make it" approach?

[jrh206]

You can work on it. Trust people with small things (or at least bite your tongue while they do it their way). Observe that nothing goes wrong. Trust more.

[anonymouse008]

So, you must have really good hiring methods... do you mind expanding on those too?

[peterlk]

"Hire slow and fire fast". I've never seen a company that had not made several bad hires. The difference was the speed at which they were willing and able to identify them and remove them. You shouldn't trust someone the moment you bring them on, but I do believe that should be able to imagine yourself trusting them.

A general rule for me is that you should know within the first 2-4 weeks whether you've made a bad hire. This is a bold statement, but my experience is that this time frame will give you enough time to get a gut check (super vague, but there are too many different patterns for me to articulate here). If your gut says no, that will stick with you, and your gut will likely become a self-fulfilling prophecy anyways.

[jariel]

This is good advice for many but it's not nearly as universal as it's implied.

There are people who don't live up to the mark in terms of quality and that's that, and in those scenarios it would have little to do with trust.