I've started to do this on a regular, almost daily basis.
If I come across something that sparks joy or interest - usually something I find here, on HN - I reach out to the author and let them know with a personal email.
I also sometimes offer a free-forever-no-strings-attached rsync.net account on the off chance that they would find that useful.
In reality, the Venn diagram of "people who write things that spark joy to the founder of rsync.net" and "people who aren't already self-hosting their own solution " is small.
But once in a while it really makes someones day ...
I have the displeasure of working with a team member who does the exact opposite: at every chance he gets, he expressed his displeasure regarding other team members to management. Once I confronted him about that behavior and he stated that those who fix problems get promoted while those who create them get passed over, and he believed that by pointing other people's flaws he would improve his chances of moving upward.
I firmly believe that's the main reason most people don't praise anyone else. If they do, they are calling out their competitor's positive contributions, while no one reciprocates in kind.
I delegated some areas during a big event and I took one of those persons asside because he was too rude.
He said that he pointed out mistakes ( which was correct, but they were new) and that they would remember it better if he was this direct. I just mentioned that he should not be this rude and just explain them what they did wrong and he adjusted. It was literally his mindset ( he adjusted that evening, not his mindset)
Pointing that something is wrong won't fix it, and if in the meantime you manage to ruin relationships within your team you have actively made things worse just to pretend being a good leader, but just proving you are an awful person to work with (and at this point you might still be wrong about your claim on what's wrong).
But continuing these existing good behaviors is really important too. If you tell people what not to change, then they won't accidentally change the good stuff in their efforts to fix orthogonal things.
I always try to praise a person. But I also want to "reserve all rights" to say that a codebase is crap or a choice made in the past was evidently a bad choice.
Finding the balance to critique work that a person contributed to, without criticising that person itself, is hard. A true challenge, I found.
It becomes even harder if a project is Open Source and you truly feel you have to "warn" people against using a solution in certain cases. It then becomes really hard not to sound like a grumpy old neckbeard or someone with a grudge. I lately decided it is best to just shut up, and let people find out themselves; to let them fail, fall or possibly succeed and prove me wrong instead. I do see the arrogance of that too, though.
How did you go about doing that? (How did you warn others about an oss project, ... Maybe one/some project at GitHub?)
Maybe when someone somewhere asks why I don't want to include X-lib or Y-dependency, I'll explain why for this case its not a good choice.
Generally, I keep this to the consultancy-reports and on-premise discussions though.
I would have appreciated working with you/people who gave some critical thoughts to third party dependencies.
I hope that each time you go to a new employer, you try again and see if they're happy with getting such warnings
Criticizing the code itself (with useful feedback), and not the person who wrote it, gives them a chance to own up to it if they're comfortable with doing that. And if not, you're still able to improve the codebase without directly calling them out.
If they get pissy about it, that's on them.
A critical skill for a senior engineer in a team is to define and establish such standards for the team. Rather than reacting to each design/code review, taking the time to setup these process mechanisms is a lot more productive and healthy for everyone involved.
This requires strategic thinking (a skill that comes with practice) towards how you choose to spend your time at work to accomplish anything.
A lot of projects lack that "objective standards". I've been helping to solve exactly this. But code can be messy without having a clear defined "clean code" standard. And a project can perform horrible, without having minimum response times docutented.
Often my job was to define all those. And often those definitions already hit a nerve. When suddenly your code is marked as "far too tightly coupled" or "too complex: AB above 34" when you thought it was neat and smart code, that is confronting and, I've seen, is often felt as personal critique.
My basic point is this, even those with the wrong mindset can be swayed with the right mindset, as long as it is sincere.
The pro-social way out of the prisoner's dilemma's shitty equilibrium requires deliberate effort to foster the sort of personal trust and collaboration-by-default attitude that makes the 8+ work hours of every weekday of most of our lives not suck.
And it makes people feel good, which is personally enough for me (while recognizing the privilege that lets me say I have enough).
I’d hate to work with such an individual; I’d avoid them like the plague.
To me “good culture” is the de-emphasis of these kinds of mindsets (and emphasis of the opposite). To the point where it’s justification for hire/fire.
I realized that I am biased toward communicating things like feedback or suggestions.
Yet I do have many positive thoughts about others that I keep to myself. I don't know why I do this.
If you're highly self confident without any feedback from other people, chances are you're mistaken. Not guaranteed, but highly likely.
1. Always publicly thank contributors for each unit of work I encountered, no matter how mundane, and especially when I recognized the value where it wouldn’t necessarily be visible/“hot” otherwise.
2. To make regular time for specific recognition of work that stood out to me, both public and direct, again especially highlighting important work that wouldn’t otherwise get a lot of light. (By now it should be obvious that I tend to work in libraries/infrastructure where good work tends to be mostly invisible.)
3. To try to continuously add visibility where work tended to be more foundational/less visible, so others would be encouraged to add to that recognition.
4. To make sure positive feedback was included wherever general or even critical feedback was warranted.
I’m not perfect and never perfected execution on those goals, but it was always an underlying part of how I interacted with my team. It improved my relationship with every team member who I most butted heads with (save one who was reflexively adversarial and invented conflict for even the tiniest work items; some people are just jerks!). And it also made a lot of people just generally more comfortable with their own contributions and better able to see their own value.
That may be good for team building and make some people feel better but, personally, I would find that situation very uncomfortable.
The idea is good: share the love, highlight good work. But it probably better just to let people know more naturally.
(The votes were publicly announced -- and also who had voted?)
I suppose it can feel that way, but on the other hand forcing oneself to find and appreciate others efforts and good qualities—even if there are perceptibly few of them—can be a good exercise, especially for those of us who are naturally quite critical. While I'd argue that it's a good virtue and intrinsically valuable, the habit is also practically beneficial: people perform better when they're appreciated and recognized; one's ability to form and work with teams is noticeably easier; it's easier to adjust performance and expectations; et c.
People often put the cart before the horse when talking about stuff like this. Manufacturing gratitude is doesn't make it less genuine or fundamentally less good.
Really, it’s about noticing and acknowledging good work or behaviour.
I wonder if this is a culture or generational difference. I've found my employer's incentives / gestures a bit lackluster compared to simple gratitude. I like working on a team where the members are publicly thankful for their teammates' efforts. Shrute Bucks stink.
I've been publicly recognized and appreciated it, I've also received quiet thank you notes. I know I like the latter more.
To me it’s embarrassing to be recognized publicly for literally doing what I am being paid to do. Instead, perhaps recognize each week the people that didn’t meet the standard:
“Wanted to recognize Bob this week for being a bit of a douche as well as letting all of us down when he messed up the build system and delayed our build delivery to QA and the Loc team thus having the rest of us having to scramble over the weekend to clean up the mess. Thanks Bob!”
I don’t want claps from my peers. I’ve already figured out if they like my work or not from day-to-day interaction.
If you want to recognize my contribution, give me money - that’s why I’m here. This is a business relationship. I work, you pay. Pay up.
You think complimenting people is horrible, people should be publicly shamed, insulted and blamed for the failure of the team, and fancy yourself for a leadership role? Grief.
Instead, perhaps take the "if you're on time, you're late, being early is the minimum" self-satisfied chip off your shoulder and realise that blaming Bob for you being a doormat and working on the weekend is you being "a bit of a douche".
My goodness. This is horrifying.
I'm cringing just thinking of a team doing that.
It’s appropriate for a manager or team lead to do this. It’s not appropriate to make it the norm (even if it’s “optional”) for the whole team.
Much better for a leader to model the desired behavior, and, create space for those on the team, of their own volition and without peer pressure, follow suit.
It will also be much more authentic, real, and meaningful.
Also, I had a manager who would move everyone I praised off the team. He was paranoid about cliques.
That sounds awful