Micro-promotions and mentorship: impact of small actions in engineering culture

https://circleci.com/blog/micro-promotions-and-mentorship-the-big-impact-of-small-actions-in-an-engineering-culture/

by Bary0n1cMatt3r • 7 years ago

339 160 7 years ago

circleci.com

ralusek• 7 years ago

This is the first time I've heard the term "micro-promotion," and I would very much like to never hear it again.

TheOperator2• 7 years ago

Getting micro-promoted is a micro-aggression.

TimTheTinker3• 7 years ago

Comment needs more intersectionality :)

NullPrefix• 7 years ago

I would think that it's micro-aggression not to micro-promote, when there's a reason for.

TimTheTinker3• 7 years ago

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.

ebiester• 7 years ago

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.)

josteink2• 7 years ago

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.

How about just calling it casual encouragement?

OJFord• 7 years ago

micro-aggressions

Not GP, but I agree, and would further like to stop hearing this one too...

Darkphibre• 7 years ago

My take is that it's many small, public acts of appreciation. That would go a long way for me, at least!

sonnyblarney4• 7 years ago

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'.

[1] https://maleallies.com/wp-content/uploads/2015/01/Male-Allie...

teddyh• 7 years ago

I think an older term is “an attaboy”:

https://www.urbandictionary.com/define.php?term=attaboy#2432...

https://dilbert.com/search_results?sort=date_asc&terms=attab...

hopler3• 7 years ago

"Attaboy" is obsolete for obvious reasons.

alexandercrohde2• 7 years ago

I agree. It just brings up so many messy associations (because "micro-aggressions") that I would stick to a term like "applause" or "appreciation."

josteink2• 7 years ago

Or “encouragement”.

But yeah, I agree, avoid the toxic baggage.

humbleMouse2• 7 years ago

Here's your title bump to "Technical Lead" with your 2% raise, have fun taking way more responsibility with pretty much the same pay...

ww520• 7 years ago

In another word, say nice appreciative things to people.

JMTQp8lwXL3• 7 years ago

You may not like the term, but it's valuable to have a word that describes something like a micro-promotion.

mturmon• 7 years ago

It's a dorky word, but it corresponds to an actual thing that is appreciated and noticed by technical employees. If used correctly, it has value.

purplezooey• 7 years ago

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.

phsource• 7 years ago

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.

[1] https://www.gottman.com/blog/the-magic-relationship-ratio-ac...

nugator• 7 years ago

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.

whatshisface2• 7 years ago

Only if your peers are deciding your compensation.

hinkley• 7 years ago

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.

enjo5• 7 years ago

"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.

whatshisface2• 7 years ago

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.

jhwhite• 7 years ago

This maybe? https://hbr.org/2013/03/the-ideal-praise-to-criticism

And it references Gottman's research also.

maxxxxx• 7 years ago

I think honest praise is definitely great and as engineers we are often way too negative with each other.

But I hate it when people (often in management) are fake positive and give a ton of praise that ultimately doesn't mean anything.

AcerbicZero2• 7 years ago

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.

RootReducer• 7 years ago

Agreed. It's well-studied that heaping praise on mediocre accomplishments diminishes the effectiveness of future compliments.

dh5• 7 years ago

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:

www.physics.nyu.edu/sokal/BrownSokalFriedmanAPonlinefirst.pdf

ignoramous• 7 years ago

Google's study also revealed similar common reasons why certain teams excelled at work: https://news.ycombinator.com/item?id=11174399

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.

Waterluvian2• 7 years ago

I made a habit of pointing out every new thing I learn from someone's PR.

strogonoff• 7 years ago

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.

swiley• 7 years ago

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. :|

HendersGame5• 7 years ago

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.

jabloczko2• 7 years ago

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.

caprese• 7 years ago

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.

wrs• 7 years ago

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.

ranie93• 7 years ago

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.

brandall103• 7 years ago

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.

enjo5• 7 years ago

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.

dsabanin2• 7 years ago

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.

Traster• 7 years ago

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.

duxup• 7 years ago

I've had a similar experience.

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.

alexandercrohde2• 7 years ago

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.

noego• 7 years ago

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.

projektir2• 7 years ago

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.

And I'm very curious how much you're paid.

jabloczko2• 7 years ago

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.

humbleMouse2• 7 years ago

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.

walshemj2• 7 years ago

Not to put the original poster down but I was hired into a similar role but that was with 8 years experience plus several years sysadmin experience.

opportune2• 7 years ago

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.

diNgUrAndI2• 7 years ago

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.

singron• 7 years ago

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).

jniedrauer3• 7 years ago

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.

wool_gather2• 7 years ago

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.

natalyarostova• 7 years ago

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.

AcerbicZero2• 7 years ago

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.

dnautics3• 7 years ago

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.

silveroriole• 7 years ago

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!

Jernik• 7 years ago

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.

HendersGame5• 7 years ago

I don't find this comment to be abrasive ;P

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.

Waterluvian2• 7 years ago

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.

Lazare• 7 years ago

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!

perlgeek• 7 years ago

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.

jpmoyn• 7 years ago

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).

jniedrauer3• 7 years ago

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.

wool_gather2• 7 years ago

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.

ketzo2• 7 years ago

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.

HendersGame5• 7 years ago

I'm guessing that you really wanted _constructive_ feedback, correct? I have received lots of that.

HendersGame5• 7 years ago

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...

daenz2• 7 years ago

For the last decade, I have worked in male-dominated environments. While during this time I’ve encountered many nitwits and detractors...

What a way to start an article that will presumably be read by your current peers, subordinates, and superiors.

xsmasher2• 7 years ago

That's only part of the sentence.

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.

daenz2• 7 years ago

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.

tom_• 7 years ago

If the shoe doesn’t fit, don’t wear it.

dbachelder• 7 years ago

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.

sonnyblarney4• 7 years ago

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?

[1] https://maleallies.com/wp-content/uploads/2015/01/Male-Allie...

kristianc• 7 years ago

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.

sonnyblarney4• 7 years ago

Yes, having worked in 'cult like companies' I'm inclined to agree, though maybe not so much 50 years, but 'since the dawn of time'.

But to codify one's arbitrary ideological assumptions, which are probably illegal, is beyond pale.

They are asking for a major lawsuit.

hopler3• 7 years ago

Punishing abusive employees is not illegal, and neither is declining an invitation to speak at a conference.

sonnyblarney4• 7 years ago

"Punishing abusive employees is not illegal"

Certainly not.

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.

sfink• 7 years ago

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".

esturk• 7 years ago

I'm more curious how she went from no experience SWE to Senior SWE and a team lead in 2 years.

I'm not saying its not warranted but I've seen people working at Google for several years and not get the Senior title.

projektir2• 7 years ago

Google and other FAANGs don't really seem to promote well or quickly...

marcinzm• 7 years ago

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).

hopler3• 7 years ago

When the team size doubles or quadruples in 2 years, someone becomes a lead.

At startups, 2yrs experience is usually when "senior" begins. Employers can pay in $ or in titles.

opportune2• 7 years ago

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.

chewbacha3• 7 years ago

In some places, "Senior" is the second tier with other titles coming after. I once worked some place that was:

* SWE

* Senior SWE

* Staff SWE

* Principle SWE

I think it depends a lot on the company and what terminology they use. Even at my current company, "senior" is not the highest level.

Zaheer• 7 years ago

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.

dominotw2• 7 years ago

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.

munificent2• 7 years ago

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.

dominotw2• 7 years ago

Yea that makes sense.

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.

munificent2• 7 years ago

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.

alexeldeib• 7 years ago

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.

HendersGame5• 7 years ago

Thank you! I'm so glad to hear you found it actionable, I was really hoping folks it would be :D

JustSomeNobody• 7 years ago

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?

kureikain• 7 years ago

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.

BeetleB• 7 years ago

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.

skizm• 7 years ago

As a low level individual contributor, unless the micro-promotion comes with a pay raise, the title changes are just patronizing IMO.

lkbm• 7 years ago

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.

sorinn• 7 years ago

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/

sinsterizme• 7 years ago

Ah yes, people must be working at all hours of the day. How dare they spend time doing other things!

externalreality2• 7 years ago

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).

aiisjustanif3• 7 years ago

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.

externalreality2• 7 years ago

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?

hadsed• 7 years ago

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.

anbop• 7 years ago

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.

diNgUrAndI2• 7 years ago

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.

What do you think?

ravenstine• 7 years ago

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.

siliconc0w• 7 years ago

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.

omot• 7 years ago

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!

noddingham• 7 years ago

But vim is better?

sigillum• 7 years ago

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?

Micro-promotions and mentorship: impact of small actions in engineering culture

Related Stories