> When people don't deliver what you expected, it's because you did a shitty job of communicating it to them.
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.
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.
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.
Requirements covers a VAST range of different garbage that can be provided to someone under the guise of letting them get on with it.
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.
Which is... also the responsibility of the manager. Q.E.D.
I was trying to say that it's not always the responsibility/fault of the manager's communication skills specifically.
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.
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.
And who does that person report to? Who made the decision to hire them in the first place?
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.
if people generally understand you and one person does not its them. if most people don’t understand you its you.
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.
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 :).
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!
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.
> 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...
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.
I don't have good memories from the whole thing.
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.
> 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.
A female software engineer who does not strive for beauty in code, is she less feminine? A male software engineer who strives for code beauty more feminine than the female one?
It is a useless argument to get into, when the actual way to describe the type of code would be a choice of "beautiful, sorted, structured, consistent" instead.
Gender, as such, has nothing to do with it.
Even in the conclusion quoted here, the author says "I think it's quite a compliment". As if when you first hear the term "girl code", you're supposed to think "ew", and the author is there to convince you otherwise.
Why not just call it neat or organised instead? Using a gendered term does nothing but appeal to stereotypes and solidify them.
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.
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.
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)
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.
Personally, if I'm sick, the last think I want to do is communicate with my manager - it means you have to be careful, you never know if they're digging, or 'professional but not exactly sincere empathy' etc..
'Adult Professionals' shouldn't need to be coddled. If you're sick you're sick and that's that.
If you have something that's a 'big deal' then you have that in a conversation in which the managers emotional response one would expect is empathy but beyond that it's a matter of 'how to work around it'.
'Trust' is a multifaceted thing, I generally do not trust that people will do their jobs well at the outset, until I've seen evidence of that, but as far as those kinds of workplace issues I definitely 'trust by default'. People get sick and that's that.
And then have a lot of tolerance because we are all a little odd in our own ways and it's just easier not to get caught up in stuff.
If I didn't have such a relation with my manager I'd be looking for a job. If he doesn't look out for me when I'm sick he will probably not look out for me professionally either.
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.
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.
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.
Is your advice to pretend you trust them? Some kind of "fake it til you make it" approach?
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.
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.
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.