> 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.
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.
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.
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.
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.
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.)
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.
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.
> 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'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).
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.
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.
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.
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.
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.
[+] [-] phsource|7 years ago|reply
> 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...
[+] [-] jabloczko|7 years ago|reply
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.
[+] [-] humbleMouse|7 years ago|reply
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.
[+] [-] enjo|7 years ago|reply
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.
[+] [-] ranie93|7 years ago|reply
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.
[+] [-] silveroriole|7 years ago|reply
[+] [-] wrs|7 years ago|reply
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.
[+] [-] jniedrauer|7 years ago|reply
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.
[+] [-] projektir|7 years ago|reply
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.
[+] [-] brandall10|7 years ago|reply
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.
[+] [-] caprese|7 years ago|reply
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.
[+] [-] AcerbicZero|7 years ago|reply
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.
[+] [-] alexandercrohde|7 years ago|reply
[+] [-] HendersGame|7 years ago|reply
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.
There's a healthy balance to be struck.
[+] [-] dnautics|7 years ago|reply
[+] [-] noego|7 years ago|reply
[+] [-] Lazare|7 years ago|reply
...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!
[+] [-] perlgeek|7 years ago|reply
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.
[+] [-] duxup|7 years ago|reply
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.
[+] [-] natalyarostova|7 years ago|reply
[+] [-] Jernik|7 years ago|reply
[+] [-] Waterluvian|7 years ago|reply
[+] [-] ralusek|7 years ago|reply
[+] [-] ebiester|7 years ago|reply
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.)
[+] [-] teddyh|7 years ago|reply
https://www.urbandictionary.com/define.php?term=attaboy#2432...
https://dilbert.com/search_results?sort=date_asc&terms=attab...
[+] [-] TimTheTinker|7 years ago|reply
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.
[+] [-] alexandercrohde|7 years ago|reply
[+] [-] Darkphibre|7 years ago|reply
[+] [-] mturmon|7 years ago|reply
[+] [-] munificent|7 years ago|reply
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.
[+] [-] daenz|7 years ago|reply
What a way to start an article that will presumably be read by your current peers, subordinates, and superiors.
[+] [-] xsmasher|7 years ago|reply
> 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.
[+] [-] dbachelder|7 years ago|reply
[+] [-] tom_|7 years ago|reply
[+] [-] jpmoyn|7 years ago|reply
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).
[+] [-] siliconc0w|7 years ago|reply
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.
[+] [-] diNgUrAndI|7 years ago|reply
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?
[+] [-] ravenstine|7 years ago|reply
[+] [-] esturk|7 years ago|reply
I'm not saying its not warranted but I've seen people working at Google for several years and not get the Senior title.
[+] [-] purplezooey|7 years ago|reply
[+] [-] kureikain|7 years ago|reply
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.
[+] [-] skizm|7 years ago|reply
[+] [-] JustSomeNobody|7 years ago|reply
[+] [-] strogonoff|7 years ago|reply
[+] [-] sigillum|7 years ago|reply
[+] [-] omot|7 years ago|reply
> 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!
[+] [-] sorinn|7 years ago|reply
[+] [-] dominotw|7 years ago|reply
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.
[+] [-] anbop|7 years ago|reply
[+] [-] said|7 years ago|reply
[deleted]