> Significantly, they also acknowledged the contributions I made. Acknowledgment doesn’t require a parade. These are small gestures that folks made that were meaningful to me:
> 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. [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.
"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!"
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.
I'm not exactly a software engineer, but I have a really hard time imagining how 6 in 1 statements about anything could be complements. In my area, most work is average (by definition) and the main reason you show your work to people sitting in the chair next to you is so that they can catch your trivial mistakes. (Kind of like code review.) I do know that in the average program there are far more bugs than clever inventions.
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.
> 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!
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.
Also, it is how you build a culture around behavior. For instance, if you’re constantly applauding tests, then that makes a norm, and reinforces the behavior more than a curt “write tests”.
In between those trivial mistakes is a lot of functional code I didn't have to write myself. Very often, that's code that I personally no longer have to write (if I'm reviewing it, there's a good chance it would've ended up on my place if they didn't take care of it for me), or that I get to leverage in my own code. That's stuff I can thank them for.
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.
Mostly agree. Might want to rethink the nitpick thing.
> 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 it's not important why are you saying anything?
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."
Code formatting, code style, and linting is a solved problem. 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. Anything else is a solution that results in aggregating nitpick reviews that ignore glaring structural problems.
> Code formatting, code style, and linting is a solved problem.
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.
You can say "good job!" in response to mediocre work. You can say thanks for simple interactions that are just people acting as expected. You can build a culture where trust is both expected and repeatedly acknowledged.
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.
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.
I read this with great interest before noticing the retraction. Has there been any other research like this without the caveat?
> *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.
I think your spot on here. Constructive criticism and genuine praise from fellow engineers is great, but having management jumping in to celebrate comically minor things just highlights how out of touch they are, and how worthless their praise truly is.
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.
> 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.
Yes, I agree. I work at a Swedish automotive startup with about 12 backenders. We praise each other a lot in our PR reviews and I really feel I don't need anything more than that. Getting positive feedback from a superior is not needed since I'd rather get it from people who understand exactly what I've accomplished and see the true value in it.
I think that might depend on how much leadership you're seeing.
Praise from a functionary can backfire. Praise from an actual coach (not these traveling inspirational speakers who call themselves coaches) can be rewarding.
That sounds very similar to the throroughly debunked "critical positivity ratio" by Losada. The paper by Brown, Sokal, Friedman criticizing it is a great and very accessible read btw:
I am struggling to phrase this comment in a non-abrasive way. Please read on charitably.
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.
If your organization has a junior putting out "fires" in production after 3 weeks, a few major things are wrong. First of all, code shouldn't be "on fire" frequently in production. Especially a domain of functionality that is simple enough for a 3 week old junior.
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.
Yeah, this. It's great that the poster leveraged it as a learning opportunity and could handle things, but it speaks to the poor quality of the organization/team that this would be an issue to begin with. But of course we have limited details.
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.
I was in a similar situation. In my case, i was on the ops team for a big chunk of the company, so it had an unusual amount of fires in production. I was rushed into oncall basically only because the existing rotation was only 2 people and they were very miserable. Later the company made more structural changes to relieve the situation (e.g. dev ops).
Sounds like the team lead is very desperate for external help. I worked in a startup where I contributed to production code two weeks after. I was at intermediate level at that time. But the team was short of people and needed extra hand at any level.
You can be proud of yourself, but you should also be mad as hell! You may have come a long ways, but you'd be so much further with good mentorship and coaching. It's not that your team was moving "a million miles an hour", it's that your team suffered from bad leadership. Leadership incapable of providing the right support for the people on the team.
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.
I don't think this is the right way of thinking about this. People react to things in very different ways - and this might have worked for this person. The reason we put in place mentorship and different structures to help people is so that there are as many avenues for success as possible. It might be this guy kicked ass in the one way he was given. That doesn't mean his team is doing the right thing, but it's not fair to assume that he actually missed out. There's a difference between doing things because they need to be done to raise success rate, and doing things because they're essential.
No one deserves anything, you get what you can get.
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.
I agree that you can't expect anything. The job is the job, you're there to give value, not take it.
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.
This expectation vs. entitlement discussion is just quibbling over semantics.
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.
No one 'deserves' anything, but it's worth noting that it's not impossible to create fast-moving and nurturing environments, and maybe trying to learn how to do that for your peers.
"Deserve" means to show qualities that are worthy of either reward or punishment.
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.
Learning on the job is mutually beneficial. The employee learns useful skills, and the employer gets a more useful employee. Tossing people into the deep end and letting them figure it out is short-sighted. We should expect more, even if just for the employer to do what’s best for them.
Maybe think of it as the article describing life-jackets and basic swimming strategies to help those that may be drowning.
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.
I work at one of these “everything is on fire, nobody has time, going a million miles an hour, hiring inexperienced people” places. They are not good. They may make you feel like you’re really learning loads and taking on lots of responsibility. You’re actually mostly learning hacks that work in an emergency and learning to be taken advantage of and do multiple people’s jobs. Why do you think they hire inexperienced people and put them straight on production fixes? It’s because inexperienced people are cheap and won’t say no to anything. Management there are likely very dysfunctional. Get out!
It's not a dichotomy — you learned a lot in your situation, but you might have learned as much or more from a different situation. It's normal to assume your own life experience is normal.
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.
> 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.
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 a struggle to convince management that the team is understaffed for the expected work and needs to hire.
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.
I think this kind of thing really comes down to the situation. You have not provided much detail here. There are cases where something like this can work very well (low scope project, low amount of proprietary information) and cases where it may end up in disaster (very large scope, misleading information, footguns). Particularly, fixing fires is one thing. Writing high quality code that follows good patterns is another, and leaving a junior to just "figure it out" doesn't actually make much sense. Often things like "accessibility" are just forgotten completely.
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.
I'll reply to your comment because it's the most aggressive. Glad to see another grumpy-wumpy internet commenter.
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.
You should be proud of yourself, you have an ability to deal with what would be a very stressful situation for most.
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.
I would say there is a push to expand productivity of the population instead of simply stroking the ego of the most disciplined and adapt at sink or swim situations.
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.
I think I understand where you're coming from with this commment. I too, went through a series of jobs being thrown into the deep end, and while the amount of help I recieved from my co-workers varied, I can't think of a single time they actually left me hanging totally by myself. Instead they encouraged me to learn on my own as much as possible, and minimize asking questions that I should be able to find the answer for myself.
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.
I've been on both sides of it. I think it's good to have a trial by fire or two to build up self-sufficiency and drive, but I think if that's all you have then it just makes scars.
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 :)
Update:
(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.
On the flip side, I hired a couple of juniors, and am hand-holding them WHILE going a million miles an hour, deploying "infrastructure as code" and "deploying to baremetal hardware", so while i would love to have a junior like you were, it's totally the onus of developer managment to figure out how to handhold juniors, if they need it.
Organizations function best when they help their employees be maximally productive. It takes a special kind of person to discover and derive Newton's laws of motion... and that too can take years. There are vastly more people who can understand it quickly once it's explained to them, and start applying it to solve real-world problems.
I mean, it's great that you thrived and didn't cause any huge issues as you got up to speed but uh...
...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.
> My manager during performance reviews would heap praise on me for being so green and yet so low-maintenance.
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!
> I distinctly recall trying to limit my questioning to daily stand-up
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 was the same way, and eventually realized my biggest skill is self teaching and managing uncertainty, but I'm not a shining star of design or algorithms, for example. So I try not to hold everyone who joins our team to my greatest strength.
I've heard from multiple engineers that have been put in a similar situation and hated it. It directly negatively impacted their self-esteem as developers and some of them quit at the soonest possible point.
As someone who went through pretty much the same thing and fought very hard to earn where he is today, I'm glad you're bragging and I'm glad you're proud of yourself.
I think it is in terms of promoting in terms of publicity rather than advancement. I'd like a better word, but it seems to be in contrast to micro-aggressions.
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.)
Given that micro-aggression are arguably mostly created by the mentality of the receiver, and not the acts of the sender, I don’t think the comparison is entirely right.
The person above you was correct and they are real things that are called microaggressions. A micro aggression is defined as "A statement, action, or incident regarded as an instance of indirect, subtle, or unintentional discrimination against members of a marginalized group such as a racial or ethnic minority."
I think because it's unrelated to the original comment. "Guys" was not in question, "attaboy" was. Using "guys" as an argument would be a strawman regardless if the rationale is correct.
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.
The point was, attaboy could be used in the same way that "guys" is. I don't see how that's a straw man fallacy.
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.
Seems to me that respecting someone’s feelings of “exclusion” by using pronouns that make them feel included is “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.
That term could be used or taken pejoratively, as if people are being stiffed and only given "micro-promotions" when they're worth more than that.
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.
The 'micro-promotions' link in the article leads here: [1], to an arguably fairly ideological intersectional view of how people ought to behave in a company, and it mostly has nothing to do with 'nice little high fives' or 'micro praise' or anything like that.
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'.
I really like this article. It's very concrete in terms of what the author experienced, how it felt, and the actions the people around her took to make her experience go well.
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 recently started reading about non violent communication, and this is a big tenet from what I gather. Affirmatively communicate your feelings and your needs.
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.
> 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.
I expect more from someone in a team leadership position (Engineering Team Lead) than to have public, petty and negative opinions about a vague "many" number of their coworkers. This is a red flag when it comes to leadership, and if they're serious about attracting and keeping experienced software developers, they'll keep those kinds of opinions out of the workplace's acceptable discourse.
Personally, I value honesty and a critical eye in my leaders. If those two things happen to reveal something negative about a workforce or a talent pool, is that a negative?
If it said "[everyone/most everyone] I worked with is difficult" or "[all/most of] My bosses seem to be idiots" I would agree with you about negativity and red flags.
But this is in an article that is 90-95% positive, so I disagree.
I've worked in that same environment (as a man (and have been one of those nitwits (hopefully not a detractor!!!))) for 2 decades and echo those thoughts. The author is being genuine and accurate. Anyone offended by it should take a look in the mirror.
It feels good, and is a good motivator, when your code is received positively. Especially early on when you aren't necessarily confident that you are a "coder" yet. I think that is a great nugget of truth for anyone working on an engineering team.
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).
> Especially early on when you aren't necessarily confident that you are a "coder" yet.
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.
I’m actually in your position, and I agree, sometimes what you really want is to know what you did wrong.
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.
Same; I wish I got more feedback on my patches. I tend to just get 'LGTM'. But I know there's always something that could be better, even if just a little bit. I'll see it in a month, maybe, when I come back to something I wrote/changed, but I wish my teammates would tell me now.
In a past life, long ago before I was but a wee bootcamp graduate, I was successful in other roles. If you'd be curious to get a glimpse into those experiences I wrote a bit about them here: https://medium.com/@HendersGame/is-coding-bootcamp-right-for...
The problem with adhoc public praise is that it invariably gets unevenly applied which makes people feel unvalued if they work on a less visible or more esoteric part of a system. It may actually result in them being undervalued because some manager who has twenty reports, never sees Bob get any :claps: and so begins to assume bob isn't generating value.
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.
I found it tricky when working with junior devs. I remember when I was junior several years ago, I wasn't given the permission to update some shared google docs, not even correcting some obvious typos. Only senior engineers who "own" them have the write permissions. When I raised the question in the team meeting, the management simply said that's an established process and showed no willingness to change that.
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.
You are right because, while I tend to be easy going, if I were that junior dev I would see having my write permissions taken away as a big F-U. I'd be polite about it, and begin looking for a new position elsewhere.
Yes these titles vary widely at different companies. In fact, that's exactly why we build https://www.levels.fyi - We don't have CircleCI on there yet but hope it helps.
Some companies promote quickly. Generally companies I wouldn't want to work at since to me it indicates that they hire a lot of junior people, and have trouble retaining or hiring experienced talent (so they throw promotions at people as a stop gap).
I know a couple people who are tech leads at large, well known companies (Facebook, Amazon) with 2-3 years of experience. But the one that I know better than the others is a workaholic obsessed with things like perceived "prestige". My guess is that they both were put in charge of some project that was a homerun and thus got allocated more head count, so they were logically chosen to keep leading the project they helped create.
The actions in here are excellent. At most workplaces you have to ignore everything that does not please management and only do the things that do. Even if it means ignoring a lot of little things that customers will view as quality.
One of the thing about code review I found sad is that many engineers have big ego.
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.
>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.
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.
Title changes can be very valuable. The thing is, they're only valuable because they help you get a better job elsewhere. "Here's something that is only useful if you leave". Cool, I appreciate it, but do you expect me not to use it?
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.
Along these lines, I think some people need to do some introspection and ask themselves why isn't it their default to give praise. If someone does a good job, say it. I mean seriously, how freaking hard is that?
Sometimes remote calls with multiple participants feel awkward, and there’s this mild detachment and lowered engagement (not sure about the cause and effect relationship there). Laugh track, used sparingly with good timing, sounds like a golden idea or at least something hilarious to try.
>Laugh track, used sparingly with good timing, sounds like a golden idea or at least something hilarious to try.
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. :|
Turns out it was deeply creepy, so we stopped using it quite quickly. There was talk of setting it as a Pagerduty ringtone, as it was juuuust disturbing enough to get your attention.
Abstracting from the poetry, what could be the factor when the time spent by senior developers coaching bootcamp's product and not working on actual company's product could cause recent circle ci production issues?
First of all, this is an important article that reminds that cultivating an inclusive environment means culmination of small and subtle gestures as opposed to simply declaring that diversity is important. It's a great article but... I just couldn't forgive this line:
> 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!
I love reading blog posts like that. But wouldn't it be better to spend that time on ... you know ... keeping the service functional to paying customers? https://status.circleci.com/
I have a theory that if you want to be promoted for your skills, work ethic ect you have to work at company that's facing the pressures of capitalism. Wants to succeed.
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.
That theory assumes that skills and work ethic directly translate to capitalistic success.
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.
The only way is networking. You have to find good people and stick with those people. Only work somewhere if you know someone good who works on that team and likes it.
This is a great example of how to foster an inclusive culture that isn’t at all limited to women and minorities. The things described here will make everyone feel good about the work they do and the people they do it with.
These are some fine ideas, but I'd argue they should be separated from the very ideological elements in the reference 'micro promotions' document here: [1]
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?
Uh, that's not how I read this at all. The linked document is not a policy document. It isn't defining micro-promotions either. It is a response to the general question "how can I help?", in the form of a practical list of example actions that someone could take if they wanted to do something to improve the situation. There is no implication that you have to do all of them. In fact, just the opposite -- it is presented as a Bingo card, directly suggesting that a given person is only likely to do some random subset of everything listed.
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".
> 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.
Uh, I'd say this predates current practices by a good 50 years. Companies have always done this.
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.
> Although no company is perfect, at CircleCI I’ve had opportunities to grow my career in an environment I enjoy.
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).
No offense but you sound like someone who got burned.
> 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 but you sound like someone who got burned.
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 think you're making a reasonable point that's coming in too strong.
- 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.
> 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. [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.
[1] https://www.gottman.com/blog/the-magic-relationship-ratio-ac...