> Using the :clap: emoji in a pull request comment to highlight a clever bit of my code.
> Sending a direct message of thanks upon realizing they were actively benefiting from a refactor I’d made to a previously gnarly bit of code.
> Posting a note to our #gratitude channel on Slack recognizing how helpful some documentation I’d written had been to them, and encouraging others to use it.
I remember reading a study about how for a romantic relationship to succeed, the ratio of positive to negative interactions has to be 5 to 1. 
Work relationships might only need a ratio of 1:1, but especially as an engineer, where the default's to critique and only pick out the bad parts in code reviews, these really help! Even at Stripe, I remember how far a "Nice! I've been meaning to do this for a while" as a part of a code review would go in just making all the other suggestions go down better. Definitely kudos to CircleCI for making this a part of the culture.
I'm on mobile so I can't pull a source, but research for work relationships generally agrees on a ratio of around 6:1 positive to negative ratio for negative feedback to be taken in a positive way.
You're correct that engineering culture falls FAR short of this, and leads to some really bad outcomes as a result.
That's 100% true, but being a good software engineer isn't about clever inventions. It's about reliably doing the right thing, and that in and of itself is praise-worthy.
When someone writes tests I will always call those tests out. Because I know that writing tests isn't always the funnest work and as such I'm really grateful that they took the time to do it!
Or what about when someone writes a really good code review? They took the time to review your work and that's another time to say "hey thanks for doing that!".
If you really look for it there are dozens of things a day that your teammates do for you that are real chances just to say "hey it's really cool that you did that". When you really start to look you'll find that you can have a really positive impact on your team by calling out all of the good things you see going on around you. It really does make a huge difference.
This sentiment, of applauding people for good work , works both ways. It makes the applaud-ee feel good, it does believe me, even if its simply because someone noticed it and cared enough to say it. It also makes the applaud-ee tad bit more respectful towards the applaud-er and try to return the favor. Add more people in this and its a recipe for a healthier work environment.
Phrasing is important. "Here's 3 things you fucked up, fix it" is negative. "Here's 3 minor nitpicks. Otherwise, LGTM, thanks for tackling this! :thumsup:" is overall positive. Both could be describing the same code review. "While you're in there, could you add unit tests for X and Y?" is asking for a favor you can then thank them for doing, "X is missing unit tests, why?" is demanding answers for a mistake.
You can still help set the tone on the receiving end of code reviews as well. "Good catch!" when people spot significant bugs in my code, reacting with thumbs up emojis when people voice their concerns. Elicit feedback, suggestions for improvements - instead of "what is everything this code does wrong", it's "okay, here's a first draft - how can we make it better?".
The goal is not to deliver perfect code. That's impossible - we're human. Trying to do so anyways is counterproductive - static analysis, and a second set of fresh set of eyes will find some bugs faster. Seperating onself from one's work like that can be difficult - but between setting an example yourself, and showing geniue appreciation for the person's work even as you're finding issues in the code can help.
> The goal is not to deliver perfect code. That's impossible - we're human. Trying to do so anyways is counterproductive.
If it's not important why are you saying anything?
If it's code style, well if it's code style I'm going to ignore you. And if pressed I'm going to tell you to fix the linters because I ain't got time for this shit.
If I can take the 5 seconds to type up something I've seen, you can take the 5 seconds to fix it. We're not trying to ship perfect code, but we are trying to ship good code - so we might as well take advantage of any easy wins like fixing spotted issues.
Sometimes my "nitpicks" turn out to fix/catch serious bugs that I didn't realize were bugs. Sometimes they're unimportant and ignored. I don't always know which way it's turning out ahead of time.
Sometimes they're important, ignored, and then things break when it's checked in. Whoops. Easily fixed though.
> If it's code style, well if it's code style I'm going to ignore you. And if pressed I'm going to tell you to fix the linters because I ain't got time for this shit.
If it's exact whitespace rules, sure, I probably don't care either. I might mention it in passing so you can fix your autoformatter rules so the people who do care get off your back.
If you're making me spend my time adding CI steps/rules, and build server time executing them, because you can't be bothered to match basic function casing rules? I'm going to be annoyed. Especially for more important code style issues that are hard to teach the linter about, like "dnt abbrv evrythg its unrdble", and "don't name your indicies ijIl in the same scope."
You need to have it automated with commit hooks. Anything else is a solution that results in aggregating nitpick reviews that ignore glaring structural problems.
Only the low hanging fruit. Yes, they'll reduce tabs vs spaces debates. No, I haven't found a linter that can suggest good function naming, and if I did it probably wouldn't work across all of the 10+ languages I get to use at a typical gamedev job. Most stylers and linters don't even catch basic spelling mistakes.
Sure, use tools to help, and push to adjust your coding standards to conform to the limits of those tools where practical and sensible - but even that's no panacea, it won't solve everything.
> If you're relying on individual developers to setup their Dev Env to do this you're doing it wrong. You need to have it automated with commit hooks.
Considering you commit locally in git I'm confused how you're supposed to avoid having any dev env setup. Maybe you'd suggest imaging your dev machines, but that's a massive waste of time for smaller shops where your install requirements change more frequently than your image gets installed, and tend to be user specific. You want a living document/checklist that you can update before setting up a new box, and default settings files, not constantly rebroken over-automation. Nor is the average FOSS contributor going to download gigs of images just to format a bugfix patch when trying to contribute back upstream.
> Anything else is a solution that results in aggregating nitpick reviews that ignore glaring structural problems.
You can't technology your way out of a social problem. I have seen low-automation environments without this problem, and I have seen high-automation environments with this problem.
You're not going to convince your coworkers to spend more time/brainpower into spotting glaring structural problems by ignoring half their feedback. They'll rightfully assume you'll likely ignore half their suggestions for structural fixes too, wasting their effort. Especially if your claim is that you "ain't got time for that" - don't got time for a quick and easy code style fix? How the heck am I supposed to convince you to spend the time to do more serious refactoring to fix structural problems, or add unit test coverage to catch what my reviews will miss, then?
I'm not saying you should manually fix up every style issue in your code, but if code formatting/style/linting is truly such a solved problem, then it's going to be way more constructive to setup the configs/rules/hooks to fix it for everyone once and for all, than to simply ignore it.
Because nothing ever ships without issues. When talking about end products, we're often - if not usually - talking straight up known bugs, not mere nitpicks. Hell, I'm willing to OK known bugs in changelists under some circumstances - like being less buggy than what's currently checked in!
Serious bugs can be a good reason to hold off on something. But nitpicks - say, a minor quibble about function naming is a subjective personal preference that should never devolve into a lengthy debate holding up an important improvement that otherwise checkin. We both have bigger, more important dragons we could use our time to slay. It's worth discussing briefly - maybe we can achieve consensus and find a better option - but if you want to check in your code as is, right now, for pretty much any reason whatsoever? Go for it. We can always make a followup changelist. Hell, please do - those are easier to diff! Even if we're working in "commit straight to shared master branch in perforce" style. If you're using git, but are worried other people about to start refactoring and want to merge into the main work branch ASAP? Go for it. Naming debates can wait. Typos can wait. There's always the next changelist. Just have a general dread of having lots of files checked out? Go for it. Make your commit. The issues are nitpicks, not blockers.
I've seen plenty of good work - changelists that are objectively improvements - die in analysis paralysis and never get checked in because of quibbles over less important details. It sucks. Minor naming quibbles should not be a cause of this. Significant design problems - maybe - but not minor easily fixed after the fact naming quibbles.
"LGTM otherwise!" is also a good finisher to signal "Okay, I've gone through everything, I think I won't find anything else." In more relaxed review environments, it's a signal that I don't feel the need to re-review your change - maybe with minor fixes for outright bugs - before you commit. It is carte blanche to move forwards.
I think there's a lot to be found in some of the business practices we've cast off, like firm handshakes and business cards - they matter as simple acknowledgements. Literally, just serving the same purpose as a TCP ack. "I'm still receiving you, go on".
Distributed systems rely on a lot of tradeoffs about how often you reconcile state and how much you expect the other parties to have successfully executed on what they say they have. Human relationships are a vastly more complicated distributed system than we've otherwise imagined.
Gene Wilder's "compliment sandwich" is often used an example of how to both praise and criticize, without risking undue offense.
So now when I do code reviews, I also verbalize all the things I like and agree with, like sharing my inner dialog, just like subjects are asked to do during usability tests. This helps me convey my respect and appreciation for my coworker(s) and their effort(s). I especially call out when I learned something from them.
Further, we recently got a puppy. I'm struggling to practice positive reinforcement training. The trainers make it look easy. But when I finally connect with my dog, successfully training a new behavior, it's like magic. At first, it feels (and looks) weird constantly praising, but after a while it becomes the new normal.
I just wish I knew all this stuff much earlier in life.
And it references Gottman's research also.
> *Authors’ Note: The journal that published this study has since expressed concern about the data. We first became aware of this research in Kim Cameron’s book, Positive Leadership. Like many others, we were distressed to learn of the incorrect data in the Heaphy and Losada research and we immediately ceased our citations upon learning that the study wasn’t correct. But we do believe the basic assumption and premise that leaders should provide more positive than negative feedback is correct.
But I hate it when people (often in management) are fake positive and give a ton of praise that ultimately doesn't mean anything.
Some people actively desire appreciation for small things, and miss it when it's absent. Other people find appreciation for small accomplishments distasteful.
One small job for good managers is to figure out who their people are (on this, and a thousand other axes). But be careful not to assume everyone feels the way you do about compliments from management.
Effort on the other hand (iirc) is quite good to compliment.
> After looking at over a hundred groups for more than a year, Project Aristotle researchers concluded that understanding and influencing group norms were the keys to improving Google’s teams.
> First, on the good teams, members spoke in roughly the same proportion, a phenomenon the researchers referred to as ‘‘equality in distribution of conversational turn-taking.’’ On some teams, everyone spoke during each task; on others, leadership shifted among teammates from assignment to assignment. But in each case, by the end of the day, everyone had spoken roughly the same amount.
> Second, the good teams all had high ‘‘average social sensitivity’’ — a fancy way of saying they were skilled at intuiting how others felt based on their tone of voice, their expressions and other nonverbal cues. They seemed to know when someone was feeling upset or left out. People on the ineffective teams, in contrast, scored below average. They seemed, as a group, to have less sensitivity toward their colleagues.
> Within psychology, researchers sometimes colloquially refer to traits like ‘‘conversational turn-taking’’ and ‘‘average social sensitivity’’ as aspects of what’s known as psychological safety — a group culture that the Harvard Business School professor Amy Edmondson defines as a ‘‘shared belief held by members of a team that the team is safe for interpersonal risk-taking.’’ Psychological safety is ‘‘a sense of confidence that the team will not embarrass, reject or punish someone for speaking up,’’
> Google’s intense data collection and number crunching have led it to the same conclusions that good managers have always known. In the best teams, members listen to one another and show sensitivity to feelings and needs.
> Google in its race to build the perfect team, has perhaps unintentionally demonstrated the usefulness of imperfection and done what Silicon Valley does best: figure out how to create psychological safety faster, better and in more productive ways.
Praise from a functionary can backfire. Praise from an actual coach (not these traveling inspirational speakers who call themselves coaches) can be rewarding.
I, similarly to the author, was hired into a position without necessarily having a huge amount of skills. The reason I was hired was due to me showing an aptitude for being able to be dropped into a new situation and find my own way out of it. My hiring experience was baptism by fire. There was no onboarding, just JIRA tickets and some architecture diagrams.
My team races at a million miles per hour, and frankly doesn't have the time to hand-hold a juniour as they learn the ropes. I was put on pagerduty and started putting out production fires within 3 weeks of being hired. With no prior experience.
That is not to say that my team didn't help _at all_. However, I distinctly recall trying to limit my questioning to daily stand-up, and only asking further questions if I was very stuck on some proprietary technology (because Google searches can't help you with in-house tech.) My manager during performance reviews would heap praise on me for being so green and yet so low-maintenance.
Now at this point I'm programming, doing "infrastructure as code" in the cloud, and working on baremetal hardware. Coming from basically nothing. Allow me to brag a little bit. I'm proud of myself.
It is stressful, there are long hours involved, but the experience hardens one for sure.
Maybe I'm just experiencing a sort of Stockholm syndrome. Maybe I was put into a terrible situation and just accepted it as normal, even good. Experience is subjective like that.
Honestly I can't think of as valid reason why there would be something breaking in production that a junior with 3 weeks of experience on a team could fix. Where are the dev ops people? Why is the production code so fragile? If the "fire" is easy enough for a junior with 3 weeks experience on the codebase to put out, why is it even a problem in the first place? Many questions here.
Also, when you're a green software engineer it can be hard to know when to ask questions. You definitely don't want to ask too many questions which are trivial and easily googleable. But you also don't want to spend 4 hours figuring something out that a teammate could explain in 10 minutes, unless their time really is 16x more valuable than yours.
You deserved better, and I really hope as you moved further into your career that you found it. Finding great mentors and coaches is truly transformative.
If one wants to learn in the best environment, one usually needs to go to university and _pay_ for the education. To go into a highly competitive industry, get _paid_ (usually quite well) and complain that someone didn't teach you the way you'd like to be taught is some kind of astronomical entitlement that I can't even begin to comprehend.
Beyond that, I disagree with your basic assertion. It's a sign of team maturity to encourage mentor/mentee relationships.
But, if you end up at an org that has their stuff together - if you're coming from nothing maybe you show a high aptitude for programming - it is something that should be an aspect of the experience.
I don't expect to be mentored, but I won't give an employer the time of day if I don't see myself growing in the job, so it's the same effect. Personal/professional growth is table stakes.
You can pick however you want to frame it. It's the same end effect: if I work for you and not as a founder/C suite, mentorship on the job is a baseline requirement when we negotiate the terms.
This poster is someone who took the initiative to get better and therefore showed qualities worthy of reward. They absolutely deserve better than they got.
How can you be so sure? You don't know what the compensation of the GP was, you don't know that they weren't / won't be written a stellar letter of recommendation (or better yet introductions) that will land them directly into coveted senior dev land, you don't know that the experience forged won't make the GP an effective startup founder, etc, etc etc.
In your experience you were thrown out into the rough seas and survived just fine-- I don't think it would be right to deride someone for drowning by saying that in their situation you would swim just fine.
There are many inputs to the system/society that outputs an article like this one, and this is perhaps what you are pushing back against-- and reasonable people would.
It's good for learning to be put into a situation where you have to perform outside your comfort zone "on your own", but in the context of a support system that will back you up if you fail. It's called "emotional safety" and it's an important factor in good teams.
Something is wrong if this is the case. Training new hires is part of the job. If they literally do not have the capacity to do that, then you are badly understaffed.
It can be an absolutely Herculean task to further convince them that, not only is the new person not going to increase velocity right off the bat, they're actually going to slow down the rest of the team to some extent.
One can always try to pull themselves out of a bad situation, but that doesn't hide the fact that efficiency was lost, and from what I've seen, rather than creating lots of excellent engineers via such a trial by fire, you rather get a lot of missed old knowledge and reinventing the wheel combined with people getting high egos and thus getting very defensive over whatever it is they got attached to during their trial by fire.
Yes, the work gets done, but how well, and do we care? As an industry, we seem to do a poor job of gathering and reinforcing good practices. I still encounter completely opposing silos that often have no clue the other exists. And everyone seems very strangely certain in the correctness of their choices.
> My team races at a million miles per hour
I must ask, though, what is this magical company?
> My manager during performance reviews would heap praise on me for being so green and yet so low-maintenance.
And I'm very curious how much you're paid.
I fully agree that I, by necessity of my lack of experience, have made mistakes and lost efficiency. I have engineered things suboptimally. I have cut corners to get some feature out the door. But I also recognize that the business I work for cares about earning money, not about making nice software. My managers like me because "I get shit done."
> I must ask, though, what is this magical company?
In terms of my company. I work for a company with ~250-300 devs. The total employee count is in the high 400's. It is not a unicorn. The yearly revenue is something like 50 million USD, and we operate at a break-even in terms of profitability.
I work on a team of 4 overworked sysadmins. I would say the team's "product" is managing the production application + all dependencies (way too many dependencies...), an ETL pipeline, and VDI. At least this company has an IT team to deal with stuff like printer/WiFi/laptop issues.
> And I'm very curious how much you're paid.
My salary is 82.5k CAD with ~1.5 years of experience.
And as a reply to most other people commenting on the parent. Yeah, mentorship is probably the best way to develop a career. I think it really is a luxury, though, and probably very few companies do it right. I wish I could have gotten some guidance, but I didn't. I'll just make do with what I've got. It's worked so far.
I'd only caution to appreciate that the team dynamic is not healthy; if you are ever in a leadership position, please don't mimic it. A little assistance can go a long way, and while I don't like the terminology used in this article little bits of appreciation regularly given do really help team cohesion.
This does that.
Your experience should go by the way side and tap into the productive capacity of people that shouldnt be distracted by pressure.
Eventually, we all find ourselves in a situation where there is no one to turn to, and you either sink or swim on your own skillset.
My onboarding experience at CircleCI was quite similar to yours (minus Pagerduty). One of the reasons my documentation gets shout-outs (as I mentioned in this post) is because there are sections of our codebases that didn't have any until I wrote them.
Succeeding in spite of difficult challenges is worth being proud of. Many of the moments I highlight in this piece are moments where coworkers helped me to see that I'd made it through a particular fire and had emerged alive and still-breathing on the other side.
I commend you for making it to where you are today, keep up the good work :)
(More thoughts, approximately 2 seconds after posting)
And, as many commentators have blessedly noted below, coming through the fires with the support of a team is a generally much more positive, and often more constructive, experience.
I have worked at places far less supportive than CircleCI and would choose not to go through several of the same experiences again having experienced how much _better_ this is.
There's a healthy balance to be struck.
...surely we can all agree that this is highly sub-optimal right?
> My team races at a million miles per hour, and frankly doesn't have the time to hand-hold a juniour as they learn the ropes. I was put on pagerduty and started putting out production fires within 3 weeks of being hired. With no prior experience.
I'm not saying this applies to you, but by experience has been that very well performing teams are so productive that they can be measured and calm. Overtime isn't needed, emergencies are rare, and "fires in production" don't happen, because the team is so far ahead of the curve. Whereas once a team starts to cut corners on documentation and processes, then more and more emergencies start to crop up, and all of a sudden it's crunch mode 24/7.
Okay. I recently had a conversation with my manager about two recent hires. One asked a lot of questions, has become productive incredibly quickly, and is extremely well liked by the team. The second has been very low maintenance, has been very reluctant to ask questions, has been very slow to become productive. My conversation with my manager basically centred on how great the fist dev is, and how we can make sure future hires are more like the first dev, and less like the second dev.
Low maintenance is not really a trait I would want to optimise on.
> Coming from basically nothing. Allow me to brag a little bit. I'm proud of myself.
As you should be. But I would suggest that the average new hire, in your shoes, would certainly have come even further if they'd been given a healthy environment. You might as well.
> It is stressful, there are long hours involved, but the experience hardens one for sure.
Yeah, I'm just going to say it: That sort of stress is not good, and long hours simply aren't something we as an industry should expect or condone.
I would interpret the linked article as "good environments are better that stink ones", which is true. I would interpret your comment as "skilled and/or lucky devs can survive stink environments", which is also true. But just because you can doesn't mean it isn't better to not have to!
If you are doing anything scrum-like, the daily standup is the worst time for a junior to ask questions, except if it's "I'm stuck with X, who can I ask after the standup about it?" (but that type of question is better done in a team chat, if you ask me).
The standup is meant to identify impediments and blocked issues, not time for technical questions. The standing up part is to make everybody uncomfortable if it's dragging on to long.
Now, I don't expect a junior developer to know this, but a scrum master (or in its absence, a team lead or more senior developer) should really have told you about it, and gave you instruction for a better time to ask such questions.
I changed careers to web development. Was hired on a 3 man team. My boss was overwhelmed by work and after I was hired an unbelievable series of family health issues.
I just sat down and decided I was going to work my way though the code until I figured it out.
My coworker was a good guy, CS degree, better coder than I am. More knowledgeable for sure.
Coworker guy moved on, he needed more structure, nothing wrong with that. I managed to just dig my way though and learned a lot.
Different experiences for sure, works for some, not so much for other.
I like the concept but the homophone makes it confusing. (Giving positive feedback in public regularly and in front of peers and management seems to be a good thing.)
Not GP, but I agree, and would further like to stop hearing this one too...
How about just calling it casual encouragement?
Micro-aggressions are just made up offenses in the mind of the receiver.
WRT "guys"; I know of at least two companies (and I work at one) which try to encourage the use of other pronouns in place to "guys" in order to be more inclusive.
Also, companies promoting switching pro-nouns is an ineffective way to get people to be more inclusive. It's a band-aid. You be inclusive by actually being inclusive.
Not every company need change, but if a pretty minor change can have a big impact on someone’s happiness and feeling of belonging, I’m willing to change.
This article has nothing to do with "promotions" from an HR perspective (although arguably being promoted to "Team Lead" ought to have resulted in a pay rise - whether it did or not isn't mentioned in the article). It's about a healthy team and its leaders treating someone fairly, honestly, and respectfully.
But yeah, I agree, avoid the toxic baggage.
It's a though the author is conflation two issues (that are of course related). One, a more generic 'nice nudges' culture, and another oriented specifically towards 'minorities in tech'.
In a lot of the discussions around gender, I end up thinking. "OK, I care. Now what should I do?" This post actually has some answers.
Also, even though I've got basically all of the privilege merit badges, I can empathize with her about what it feels like to be intimidated and how a little caring support goes a very long way in that time.
I found there are two difficult aspects to this: clearly defining the relationship from feelings -> needs (many examples in the book of this, and how people twist words when asked to describe what other people do that they don’t like), and avoiding specific language mannerisms I’ve grown used to but recognize as following negative patterns.
I found the approach helpful when I tried using it during some emotionally tense situations.
What a way to start an article that will presumably be read by your current peers, subordinates, and superiors.
> For the last decade, I have worked in male-dominated environments. While during this time I’ve encountered many nitwits and detractors, I’ve also been fortunate to encounter many proponents and advocates.
That doesn't seem like a blanket denunciation of their peers, subordinates, and superiors.
But this is in an article that is 90-95% positive, so I disagree.
That said, this person graduated a coding bootcamp + joined their first team less than 3 years ago. I'm not sold that they have much to teach about managing an engineering team (not that I do either).
When I was lacking experience, I actually really just wanted negative feedback. The absence of feedback, to me, was synonymous with "your work is correct." But no one would ever tell me what I was doing wrong. Even now, half a decade later, I have yet to get that negative feedback. I hope that means I'm just a good coder, but I always have this nagging feeling that it's because no one has actually reviewed my code before.
That said, imposter syndrome is a very real thing, and it’s felt disproportionately by women and minorities in tech — I think we should be cognizant that a lot of our colleagues have been told throughout their lives, implicitly or explicitly, that their work isn’t good enough, and so that positive affirmation can do a huge amount of good.
Ultimately this about measuring and rewarding value generated which I prefer be evenly applied, objective as possible, transparent, and continuous. I prefer a culture of professionalism - a premise that we're all good at what we do and we all have agreed on some process to determine what is valuable to work on so we don't need continual praise - if the work wasn't valuable we wouldn't be working on it.
Part of me interpreted it as they don't trust me and tried to defend from my stupid mistakes. But I told myself to be patient and shook off the negative thoughts.
Recently I updated my view. Since I became a component lead, I wanted to be a bit more open-minded and let a junior dev to help edit a document. He messed up a few times (fat finger typos, pasted letters without accents, unsorted columns, etc.)
I researched together with him into why he inadvertently made those mistakes and it turned out he's very new to the IDE and not familiar with some editing tricks. He was a bit ashamed about that and tried to learn. But mistakes still happened sometimes.
One day, faced with deadlines and no time for re-doing edits, I turned off junior dev's write permissions.
I knew that this would cause negative emotions and explained to him. He understood it too. Things went smoothly for that deadline.
What I wanted to say is, some micro-act of taking away permissions is good for team efficiency, but may also show distrust, especially for sensitive team members.
My current take is: Trust by default. If breached more than twice, build it into the process and explain carefully.
What do you think?
I'm not saying its not warranted but I've seen people working at Google for several years and not get the Senior title.
At startups, 2yrs experience is usually when "senior" begins. Employers can pay in $ or in titles.
* Senior SWE
* Staff SWE
* Principle SWE
I think it depends a lot on the company and what terminology they use. Even at my current company, "senior" is not the highest level.
Time to time, I see review like: "This is confused to me" and the person who write that code explains a lot but refuse to make chances...I think those don't assume good intention in code review.
We aren't in school anymore. We are all get paid to work on something and to help the companies success, or the next engineer to success. When people spend time review your code, read your code, being thankful for these free advice.
I learned so much and thank deeply to people who review my code literally line by line.
The extra emoji, tactic, micro-promotions etc add no value to my learning experience.
The flip side to the coin is that "This is confusing to me" is not particularly useful feedback. It reminds me of my days in academia, where professors told students they can't help them if they come to them and merely say "I don't understand this." You have to give more details.
If you want to help your employees, give them title changes. If you want to help and retain your employees, give them title changes and pay raises.
Oh gosh no, voice calls are bad enough already. I'm sure we'll see something like a soundboard in slack or discord at some point specifically for this though. :|
> He also uses Emacs, which is terrible, but nobody’s perfect.
This is triggering me hard. I guess I know it's a joke, but most legendary programmers use emacs and for good reasons, it's a huge productivity booster. There's a high learning curve, but if you're going to tackle one of the more intelligently sophisticated industries with a semi-high learning curve let's not shy away from tools that that are also hard to learn.
Sorry for the rant: you all have a nice weekend. Maybe practice how to use emacs for a couple hours!
If you work a major bank or something, there is nothing stopping your managers from covering their asses ( all along the hierachy) an simply transferring the blame onto the lowest level employees.
My impression is that many ways to win in business don't involve working smart and hard, but instead involve reducing competition, influencing regulation, restricting consumer access to accurate product information, etc.
In other words, you can win the market by being the best, or you can just change the market itself. Your bank example is a good one — look at what a financial successful strategy it has been for banks to capitalize on their gains and then distribute their losses onto us by getting bailed out.
I am not sure then how low level employees can protect themselves from becoming a scapegoat for failures and theft of success . Its hard to asses management before you join a team and harder to change teams.
It may very well have policies that are in fact illegal in terms of their application.
I would never work at a company that promoted these specific ideals in an official manner, not because I don't believe in the general impetus of the notion that 'we should be helpful to those who are minorities in tech' (of course we should), rather, that one would be subjected to wicked well-intentioned-but-ultimately-maligned discriminatory policies.
+ For example, boycotting / refusing to attend 'speaking engagements that require 50/50 female/male representation in micro cultures that are in fact heavily skewed in one direction - this is in fact discriminatory. I'm not going to boycott a conference because it's mostly dudes, or women, or whatever group may constitute the majority of speakers/attendees.
+ "Discipline or fire employees who abuse privilege". This is definitely a dealbreaker, as in, 'run away from this company as fast as you can'. Consider for a moment who is defining privilege, on what basis, and what might constitute 'abuse' of such privilege?
Besides the fact that this is probably illegal, and surely immoral - it means that you will be subject to disciplining and firing on the basis of your perceived status as defined by race, gender, background, nationality, immigration status? What else?
And who is making such assertions? By what standards? Are they clear? I'd dare the author to articulate one instance of admonishing someone for 'abuse of privilege' which is not in fact illegal.
This policy essentially promotes cult-like authoritarian behaviour on the part of senior management, whereby they'll be empowered to promote, fire, denigrate or support individuals on some arbitrary social basis that basically has nothing to do with one's level of general professionalism, or work ethic.
A much simpler, more pragmatic, less ideological framework would actually help the framers of this policy achieve basic goals.
And again, some 'micro cultural' issues in the article I think have merit, outside the context of the aforementioned document.
Finally, I will say, that a lot of this 'decent management' is normalized in other professions. I think perhaps what we might be talking a lot about companies which are really just 'a bunch of guys who just finished school' - who may not even have had a lot of mentorship or professional experience themselves. Combined with the longer hours, stress ... maybe it makes for a more toxic work environment wherein 'high five' behaviours are not common?
It's linked from "micro-promotions" because it's relevant. That's all. If you have no clue what the term is about, and you go to the link, you can now say "oh, promotion as in encouragement or countering bias. Ok, at first I thought it was small meaningless title changes or badges or something."
I enjoyed the article and mentally filed it into my "things to keep in mind" category. I'll probably think of it when I do my next code review. Not "oh, I have to say something nice! Uh... your indentation is absolutely perfect!" I'm not into meaningless positive comments; they devalue legitimate praise or gratitude. But I already face the choice of whether to do a basic "lgtm" vs something like "cool, this is a lot easier to follow now" or "thanks, that's been bothering me for some time." And this is a reminder of valid reasons to say something more. Even though most of the time I'll still be sticking with "lgtm".
Uh, I'd say this predates current practices by a good 50 years. Companies have always done this.
But to codify one's arbitrary ideological assumptions, which are probably illegal, is beyond pale.
They are asking for a major lawsuit.
But it's illegal to define abuse in terms of gender or race, though, i.e. the policy is to fire people who are abusing their 'privilege'. An HR busybody could feasibly interpret this to mean "a white person yelled at a black person, which is an abuse of racial privilege, ergo, we're condemning/firing them" - or something along those lines.
My point is that the definition of 'privilege' is going to be arbitrary, probably based on race, gender etc. and therefore illegal.
And it's certainly not illegal to decline an invitation to a conf., but it might be discriminatory to decline an invitation to some conference because they didn't adhere to some kind of ideological version of equality, i.e. 'we're not going to the gaming conf. because most of the speakers are men'.
These are important issues, we need nuance, I think that the chart I referred to lacks such nuance and is to intersectionally heavy handed.
We all want people to get along, but that doesn't mean any policy with that intent will have a positive effect.
Small gripe. Its funny how software developers think they have a career. Once you leave a job you are basically an entry level programmer again. What I mean is if you stay somewhere 5 years using one set of technologies, you'll find that you are not qualified for the vast amount of open positions that use other new (just came about in the last 5 years) technologies. You basically have to start all over again or somehow find a team that is using the same set of technologies (which is rare). You know (React now) wait until 5 years from now when you try for a new job, there will be something else and your experience won't count only your knowledge of the hot new thing.
At the new job, the culture will be white make dominated, if not age < 32 white male dominated. So a career in software == a job in software that gets reset every time you change jobs, and there is no escaping white male domination because software is based is often blind trust and the ones with the highest probability of getting that are white males (It may be hard to swallow but it is true).
As for mentor ship, the culture of most places dictate that the most experienced mentor who that like. Females are usually excluded from this group and made to handle the bug list and given minor tasks. After 15 years they may be put in a position of leadership so that the company can save face (if the female employee sticks around for that long).
> Once you leave a job you are basically an entry level programmer again. What I mean is if you stay somewhere 5 years using on set of technologies, you'll find that you are not qualified for the vast amount of open positions that use other technologies.
I doubt this is true for your average Java/Python/C# developer or even a powershell person.
> At the new job, the culture will be white make dominated, if not age < 32 white male dominated.
What does this have to do with anything related to the first point?
> As for mentor ship, the culture of most places dictate that the most experienced mentor who that like. Females are usually excluded from this group and made to handle the bug list and given minor tasks.
This is still true at some companies, but I think it is changing far and wide in the US. I've met some amazingly gifted female developers, some terrible. I've met amazing male devs and terrible ones too. When we become blind to that bias and we have a good diversity on a team, I find teams become pretty cool to be apart of, especially when we have a mindset of mentoring.
No offense taken. If I didn't get burned (I guessed "burned" means to have observed this first hand countless times over 15 years in the industry), then how would I know it to be true?
> I doubt this is true for your average Java/Python/C# developer or even a powershell person.
You can know Java, but if the team is using mongo and you don't know mongo, then there is a problem - if you know java and mongo - but there is a react front-end, then there is a problem... get my drift. The industry is going with a "experience doesn't count - you have to know what I know or be good at faking it" kind of theme. It very prevalent.
> What does this have to do with anything related to the first point?
I has to do with the article. Did you read it?
> This is still true at some companies, but I think it is changing...
"Changing" isn't good enough. Think about something horrible , anything, would you want it to be "changing", or would you want it changed?
- I've been in several companies whose teams were not white male dominated, including leadership.
- The situation with women in engineering teams is a problem, but I have witnessed at least one place myself that was doing very well (big tech co)
- I work in AI, which beyond the applied math and science parts, is basically just backend, data, and infrastructure engineering. My experience is that the particular technologies aren't super important, and experience does transfer. I've also used nothing but Python for the last 7 years and this has been perfectly fine. I've had to learn several different database technologies, though at some point I expect to not have to do this much more. Architectures are obviously different, but that will always be true. And it doesn't mean that you can't apply prior knowledge to have important insights. All of my more senior colleagues and managers understood this, sometimes explicitly saying so in our interviews. Certainly this is a discussion point when I've hired people.
I'd like to know a little more about why you've come up with what you have here. I do think something in your experience is a little off, because it really doesn't match mine.