[HN Gopher] Ask HN: Suggestions for working effectively with jun...
___________________________________________________________________
Ask HN: Suggestions for working effectively with junior devs?
I'm a senior dev at one of the FAANGs with more than 15 years of
experience, but the rest of my team consists of devs with an
average of 2 years of experience. At first when I joined, I thought
this was an aberration, but there are many teams around me that are
structured similarly. Is this how FAANGs try to scale teams? The
devs on my team are smart but mostly naive about getting stuff done
in the real world. I'm sure they'll figure it out over time. But in
the meantime, my days are quite frustrating because I'm in teaching
mode most of the time instead of building stuff.
Author : tinglytoes
Score : 132 points
Date : 2023-02-02 16:33 UTC (6 hours ago)
| jawns wrote:
| In organizations that have separate management and IC tracks,
| there tend to be two ways that the IC track is interpreted as you
| become more senior:
|
| 1) You spend just as much time as you did before in development,
| only working on harder stuff.
|
| 2) You become more like an architect or an attending physician,
| where you're spending some time in development and some time
| teaching or consulting more junior devs.
|
| I think most senior ICs would prefer #1, but in reality #2 is
| more common.
| fdgsdfogijq wrote:
| Shocking when you realize places like Amazon will be one L6 and
| ten inexperienced devs. The L6 will just absolutely micromanage
| the low yoe devs. So come up with a design for the whole team,
| break it into pieces, and then grill them on their small designs.
| The CRs go under the microscope. Sprint planning with some
| absurdly short estimate. This is how modern software development
| is done. And its unfortunate that for non critical services, you
| actually dont need that many experienced engineers.
|
| This is why ageism is rampant, some 35 year old would never agree
| to this setup.
|
| Either do it, or move to a critical service team where theres
| actual adults
| firstSpeaker wrote:
| Is this first hand experience? And if this is the case in most
| org/teams or just AWS?
| pyb wrote:
| That's also what you see at underfunded startups.
| cody_coconuts wrote:
| Matches my experience on both counts
| fdgsdfogijq wrote:
| Yes, this is the model, even though people generally wont
| speak it out loud within the company.
| anavette wrote:
| This (experienced manager, many very-junior analysts) is also
| the model in consulting.
| stcroixx wrote:
| If they're hiring people who have no more than 2 years of
| experience they must understand that it will also take a senior
| like you to be an almost full time mentor to make them productive
| instead of you building stuff yourself. Are they expecting you to
| continue building stuff at the same rate you were without doing
| constant training? That would be a mistake. If not and you're
| just missing what you used to do, I think you'd have to move to a
| new team where you're not the one mentoring multiple juniors.
| black_13 wrote:
| [dead]
| heleninboodler wrote:
| My approach: 1) spot ways in which they are slower than you and
| _demonstrate_ how to do it faster. A lot of people have a hard
| time doing this without being a condescending dick about it, but
| if you can pull off "can I show you a really good trick for
| doing that?" you will force-multiply by showing a bunch of noobs
| how to get closer to your speed. 2) Give advice on designs and
| approaches to problems, and try to explain _why_ you 're taking
| that approach. Articulate what principles led to your decision.
| Enable them to try it themselves, not just learn by pattern
| recognition. 3) Give away your ideas for free. Nothing pays off
| better than telling a junior dev "hey, I think you should do
| [very detailed plan]" and then when they do it, praise them to
| high heaven for the work they did, taking zero credit other than
| saying you helped them develop the idea. Everyone knows you
| deserve the credit, the junior dev thinks you're brilliant and
| generous (and wants to repeat the experience because they're
| getting a reputational boost), and you get your great idea
| implemented without lifting a finger (and can honestly mention
| your contribution/mentoring on your self-review).
| bachmeier wrote:
| > my days are quite frustrating because I'm in teaching mode most
| of the time instead of building stuff
|
| I have no experience at all with these companies, but isn't this
| one of the main reasons they hire someone like you?
| KaiserPro wrote:
| I too am at a FAANG, and I have 18 years experience(only hte last
| 4 years at a FAANG).
|
| The "ramp up" barrier is less about how things are done in the
| real world, but down to a total lack of documentation. Stuff in
| FAANGs is never really world changingly hard in terms of
| technical, it mostly a case of playing murder mystery to find out
| what the "proper" way of doing things are.
|
| There are a couple of ways to help and free up your time:
|
| 1) write good instructions for the feature they are supposed to
| be building. Point them to the systems they need to be using,
| along with some of the examples you've learnt from, give them
| introductions to the people they'll need talk to
|
| 2) use them as a resource for testing documentation. When they
| get stuck, help them reach out to the right team to get it fixed.
| If its your stuff, fix it.
|
| 3) have empathy, you are bringing up the next generation. Its
| your responsibility to make them happy, well rounded individuals,
| who will train the next generation so you don't have to.
|
| You're not there to fix their shit, you will need to delegate
| tasks to them, in the full knowledge that they might fuck it up.
| Your job is to give them moral support so they can fix it
| themselves.
| mter wrote:
| From the new hire side, the way I explain it is that they should
| ask the people with 2-3 yoe first since they're the ones closest
| to the code + have onboarded most recently. It's not that they
| can't even ask our senior devs questions, but we want to minimize
| random questions that anyone else on the team can answer. We also
| try to utilize slack/updated runbooks to make sure everyone
| learns the answer to questions vs answering the same questions
| over and over in dms.
|
| Are you trying to be hands on and involved in everything to meet
| your standards? You have to trust the rest of the team and
| delegate things, and only step in when shit is completely
| unacceptable or you'll never get any work done. You should
| definitely talk with your manager about how much time you're
| spending on this and make sure that they are aligned with you on
| your priorities.
|
| Lastly... are you still a new hire? Generally it's better to
| listen and learn as opposed to telling people to do it your way.
| tracerbulletx wrote:
| You're a journeyman or a master with apprentices, embrace it and
| schedule your time accordingly.
| kixxauth wrote:
| To really become valuable in your role you need to leverage your
| experience and skills to become a force multiplier (as mentioned
| several other places in this thread).
|
| There is some good advice in here to help junior devs level up.
| But I would start by boiling it down to one that is easier to
| remember as you become a manager / coach:
|
| Try to remember what worked well for you when you were learning,
| and then do that for your team.
|
| I have gone back to that well over and over as I've moved between
| senior, principal, and management roles.
| greenie_beans wrote:
| what was it like when you were a new dev? were you frustrated by
| the lack of mentorship from experienced devs? or did you have
| some guidance?
|
| could you reframe the situation and see it as, "this is cool, i
| have all of this experience to share with new developers."?
| unless you don't want to be a mentor, which idk, good luck.
| kissgyorgy wrote:
| The definition of "Senior developer" is a little bit different
| everywhere, but I think what's common is that YOUR JOB is now
| COACHING JUNIORS. Your role is just different, you have to accept
| that.
| heleninboodler wrote:
| At my job, there are three levels above "senior" and senior is
| the lowest we typically hire. So the ridiculous irony is that
| "senior" here means noob. :D
| harshalizee wrote:
| Nope, this is just how it is in Amazon. Other FAANGs tend to have
| a better spread of engineering experience. Root cause has always
| been the high turnover. Once you have enough experience and the
| AMZN name under your belt, most devs chose to jump ship to
| somewhere saner.
| pyb wrote:
| From personal experience, I got the impression that Amazon was
| not even that interested in hiring experienced developers. I
| think they decided that churning through early-career engineers
| was ultimately more effective for them.
| horsawlarway wrote:
| A: Welcome to management, it's a sneaky thing sometimes
|
| B: My advice is pretty simple - whenever possible, don't fix
| their mistakes for them or tackle the cleanup on something
| they've made a mess of. It's tempting - you'll spot the issues
| coming way before they do and you'll have a better fix in mind
| fast, but they need to be able to touch the fire and feel the
| burn... It builds confidence for them when they do fix it, it
| shows you have made them responsible and they own something, and
| in the long term it builds team trust (use your 15 years of
| judgement here about what can be allowed to fail for a bit
| without breaking the bank).
|
| C: There are some junior devs (not always labeled junior) who
| manage to keep their jobs by routinely going through their
| contacts and getting them to "teach them the code" which really
| translates into "doing their work". Politely stop doing this - a
| 5 minute conversation (or less) and a link to some relevant code
| is enough before you pat them on the back and tell them to go
| work on it themselves again.
| jobs_throwaway wrote:
| > a 5 minute conversation (or less) and a link to some relevant
| code is enough before you pat them on the back and tell them to
| go work on it themselves again.
|
| so, you never work with issues with colleagues for > 5 minutes
| at a time? Is that normal? I understand you shouldn't do their
| work for them, but surely there's times when a longer coworking
| session is appropriate
| horsawlarway wrote:
| That's a fair ways off what I actually said.
|
| Pairing is fine, long sessions (1 to 3 hours) can be
| genuinely helpful and good experiences.
|
| They are less helpful if your colleague requires that session
| to get anything done. If their answer to the question "Show
| me what you've got so far?" is "ummmmm" or otherwise blank...
| time for the link and a pat on the back.
|
| If it's "I tried this and it didn't work" or "I have this
| thing on this branch but I'm stuck" or "This is close but I
| can't figure out this error" - sure, dig in.
| faangiq wrote:
| Sounds like you work at Amazon. They had to attempt this method
| because their reputation/pay is so bad in the industry they're
| not able to hire experienced devs.
| Nuzzerino wrote:
| Nobody at that scale is able to sustain hiring standards as
| high as you're insinuating.
| jomkr wrote:
| Asking questions is helpful.
|
| Knowing when it's fine to let them go with a 80% perfect plan
| geocrasher wrote:
| I don't work in a FAANG. I do have 24 years experience in my
| field however, and most of the people that work for me have 2-3
| years.
|
| Stop looking at the differences. Start looking at the
| capabilities. Trust them with things and see how they do instead
| of hand holding them. They don't need it or want it. Treat them
| like coworkers, not subjects.
| bobthepanda wrote:
| In general, the role of senior dev is to break down projects into
| pieces understandable and achievable by juniors.
|
| It helps get them experience and it helps you from having to do
| literally everything, because it isn't particularly easy to hire
| more senior devs.
| taylorhughes wrote:
| This plus do not get overly distracted by the ones who can't
| figure it out on their own after some basic guidance. Identify
| the juniors who do well, and leverage them to help drive your /
| the org's goals. They will get promoted and you will hit your
| goals faster. It's a balance though because you have to carve
| out your own time too.
| spike021 wrote:
| After having worked at a FAANG and having friends who still do,
| the way I've seen it is that with your YOE to work basically
| solely as an IC with less mentorship responsibilities you have to
| be in a highly specialized, challenging area (AI, ML, etc.). If
| you're in a more common area like web dev, backend engineering,
| data ingestion, etc etc. then you're more likely going to have
| those mentorship responsibilities.
| throwawaygo wrote:
| At a company with "flat team" aspirations it's like this but the
| loudest juniors call the shots. Come in with 10 years exp in a
| language and get constant pushback on my suggestions because I'm
| new and unproven. After 2 years most of the loud ones that made
| all the decisions are gone and we're stuck with something that
| doesn't scale and needs to be rewritten because before end of
| quarter. Amazing how much tech debt is possible in this model.
| kissgyorgy wrote:
| Sorry it's hard to hear this, but you are definitely lacking
| some skillset of persuasion or communication. There are always
| "fights" in the beginning I guess, but if you are confident,
| know your shit, it should be very easy to convince less
| experienced people.
|
| One thing you might not be aware of is "social capital",
| "setting expectations", "assertive communication" and things
| like that.
|
| Sure, in an ideal world, wisdom should always win over
| loudness, but until that happens (never), you have to learn
| these soft skills to be the reasonable voice in a team.
|
| I always found my voice in every team very early on, due to my
| knowledge, my high quality of work and being confident (in my
| abilities and my work.)
| lazyasciiart wrote:
| > if you are confident, know your shit, it should be very
| easy to convince less experienced people.
|
| No, it isn't. I am fully aware that I am lacking some kind of
| ability to champion projects, explain things that seem
| obvious to me, and convince others, but I am also the
| absolute subject matter expert, know every piece of this shit
| and am completely confident in what I'm telling them. That's
| why it's infuriating to watch blatantly stupid projects with
| no basis in reality kick off then crash and explode in
| exactly the way I predicted. It is 100% a communications
| failure on my part. The confident salesman idiot will win
| every time.
| tclancy wrote:
| Why think this by default? I am in a similar situation as OP,
| 20 years of experience as dev, team lead and engineering
| manager, yet because I didn't know the intricacies of our
| custom framework the second I walked in the door, many of my
| suggestions were dismissed upfront and, a year in, I feel
| it's an uphill battle to get my ideas treated with anything
| other than suspicion.
| jokethrowaway wrote:
| That suspicion is healthy. You don't know the technology
| being used, per your own admission.
|
| Ah, if only I had a dollar for every project turned into a
| mess because some engineering manager (who probably coded
| in COBOL last) thought they knew what they were talking
| about and pushed down some crappy choice
| boredtofears wrote:
| In my experience coming in as the new guy with X many more
| years of experience doesn't automatically mean you're going
| to be listened to no matter how "assertive" you are.
| Communicating assertively can easily cause others (especially
| newer devs) to be on the defensive. If a whole team has
| decided on a trajectory you're not likely to change things
| very quickly by just exuding confidence. You don't have much
| "social capital" on a brand new team until you've
| demonstrated your skillset.
|
| Also I find the habit of passing judgment of a person on an
| internet forum extremely distasteful and pretty disingenuous
| - you don't know enough about this person from a two sentence
| forum comment to judge their communication/persuasion
| skillset. It does nothing to support your argument or do
| anything other than make you feel superior to that person.
| outside1234 wrote:
| This is what it feels like to get more senior. Your role is to
| coach others increasingly versus delivery.
| Cwizard wrote:
| Depends on the organisation, at my last job you could become a
| senior IC (which does not have any management or mentoring
| requirements) or you could become a 'lead' which is expected to
| coach the others in the team.
| bobleeswagger wrote:
| Wait till you learn their salaries.
| jsjsof wrote:
| Probably higher than his salary.
| Insanity wrote:
| I think that was the assumption here, but ignore stock
| changes over 10 years. People hired 2-3 years ago were hired
| on a "high" and their total compensation this year likely is
| not as great.
|
| (For some definition of Great, it's still way beyond the
| average for $population)
| Buttons840 wrote:
| You have to build the right thing through them. Then, they can
| maintain it themselves. If you build it all yourself, you will
| have to maintain it all yourself.
|
| Source: me, a former team lead who built it all himself.
| giantg2 wrote:
| "because I'm in teaching mode most of the time instead of
| building stuff."
|
| Based on the structure you detailed, it sounds like that's by
| design. I guess embrace being a teacher, or leave?
| [deleted]
| [deleted]
| fatnoah wrote:
| > I'm a senior dev at one of the FAANGs with more than 15 years
| of experience, but the rest of my team consists of devs with an
| average of 2 years of experience.
|
| I'm going to guess that it varies widely. I managed a team of 13
| at a FAANG, with 1 new grad, 3 in the 1-5 YOE range, and the rest
| in the 5-10 YOE range. I was the only one with > 10 (over 20
| range, actually).
|
| Of that group, that company was the only company they've worked
| at. Success in getting stuff done was mostly about personality
| than background or experience. Those who had a need to push on
| things to get them done succeeded, and those that didn't had a
| harder time.
|
| The main differentiator, IMHO, was that the FAANG-only folks had
| little to no concept of System Design or operational elements
| (i.e. what happens after software has been shipped). There was
| essentially no opportunity for the former, and no reason to dig
| into the latter. All the systems they needed to do work were in
| place, including high level architectures, data pipelines, metric
| capture, etc.
| Sevii wrote:
| When I was at Amazon I saw a maximum of around half the team
| being L4. Usually it was people with 5+ years experience at other
| companies getting down leveled to L4/L5. I don't think we ever
| had more than 1-2 legit new grads/juniors on a team.
| quadcore wrote:
| _my team consists of devs with an average of 2 years of
| experience._
|
| What I'd do. Dont let them write apps from scratch. Or you'll get
| tech debt and a team with low morale and skills. Have seniors do
| prototypes and refactors. Reward seniors who it well. Dont reward
| seniors who dont beat deadlines and keep on doing meetings.
| PaulHoule wrote:
| It's not just FAANG, it is how many larger organizations work. I
| would point to the Indian consulting shops like Infosys who
| typically grow rapidly, hire a lot of "freshers", have a lot of
| opportunities for promotion, and try pretty hard for the senior
| people to transfer their experience to the juniors. On a good day
| those organizations succeed at this pretty well.
| sumtechguy wrote:
| A lot of large companies do this. I think in the past 2 weeks I
| have had maybe 3-5 hours to work on my stuff. The rest is
| meetings and showing others how to do something.
| symfoniq wrote:
| Do you find that this creates a degree of background
| stress/anxiety? After many years of being a highly effective
| IC/consultant, I'm still trying to adapt to being primarily a
| manager with a software engineer title, and not sure how well
| that's going. It can feel unsettling.
| sumtechguy wrote:
| For me going from being 'the guy who does tons of stuff' to
| the 'guy who knows stuff' has had some upsides but some
| downsides. Upside is I get to share with others and get
| more people going and doing good stuff faster. As a group
| we are better off. But narrowly on me, however, that has
| come at a cost of my productivity is lower. I also have to
| manage expectations of what I can do now with managers. It
| does make me feel like I am not getting anything done too.
| But if I can unstick 4 other people I guess it is a win...?
| PaulHoule wrote:
| I think many people find it hard to make the transition.
|
| Logically if you can double the productivity of 10 freshers
| you can contribute more value than you can as a highly
| productive IC who is 10 times more productive than a
| fresher. Your instincts as an IC can have you feeling you
| are not productive at all though.
| bbor wrote:
| I'd say that this is less "how fangs work" and more "what gangs
| are like in 2023". If you look at the devs hired per Q stats for
| your company I'm willing to bet that seeing mostly people with
| 2yoe will suddenly start to make more sense.
|
| My personal theory is that the MBAs discount how much this messes
| with quality engineering culture, and have no idea what they're
| doing by running teams with one experienced manager, one senior,
| and a bunch of excited juniors.
| rqtwteye wrote:
| It's like this in a lot of companies. At FAANG you are probably
| more lucky because at least most juniors are smart. In general I
| don't know how to navigate this well. You don't want to be the
| old guy that constantly dictates things to be done in old ways.
| But you also can't let them go completely wild with their ideas
| and have disaster strike later. Onboarding one or two new guys
| into a team is fine but teams with a majority of newbies are just
| difficult.
|
| A major problem I have seen in the last years is that the young
| guys seem to have a preference for super complex systems.
| Everything needs a http API, Kubernetes, Microservices, multiple
| repos and complex build pipelines even when a simple server with
| a database would be just fine.
| refulgentis wrote:
| Been at FAANG 6-7 years and was equally surprised as you coming
| in.
|
| I had a peer more used to it coming in, the best thing he did was
| build a relationship, subtly establish this wasn't going to be a
| great place to bring my full self, and be kind day to day minute
| to minute as questions came up.
|
| More directly, what you described is how it goes and it's sad.
| The worst part is watching them either find a way to be a part of
| the grinding machine, get chewed up by it, or give up and be sad.
| Best thing you can do technically is what you're doing, if you
| build a personal relationship, you should help them pace and
| signal the lack of incentives
| sgwizdak wrote:
| Clear out what your obligations are with your management.
|
| I've been in positions as a senior software engineer where it's
| my job to carve up projects and have make sure juniors can get
| things done. That means checking in with them, make sure they
| understand stuff, make sure quality is high, and ensure they're
| not getting blocked. Your management looks to you get the project
| done. You are not measured by your IC but by your ability to
| force-multiply to knock out projects.
|
| In these situations, your individual IC contributions go down,
| but you effectively get to claim delivery of the project under
| your belt based on ensuring delivery success. (It may be critical
| in these situations to track how you made that happen.)
| syndacks wrote:
| Talk to your manager and find alignment on what the team needs
| and how you might fit that. If your manager sees/acknowledges
| what you do and is in favor of you mentoring more -- and you want
| that -- figure it out, put it in writing, etc. If you don't want
| that, find alignment with your manager. If they are a good
| manager they'll allow you to focus on coding. You might be in a
| position to give a little and get a lot back both in the eyes of
| management and your own career satisfaction (teaching over coding
| as much) so I encourage you to try to zoom out, communicate, and
| get on the same page as the teams manager.
| throw_away1525 wrote:
| With 15 years of experience and a bunch of new engineers on your
| team, your job is no longer to build shit. It's to help everyone
| else on your team build shit. If that's a problem, you might need
| to find a new team. I hear that Netflix only hires senior
| engineers.
| filoleg wrote:
| That was true of Netflix until about 2021, back when they still
| had a flat structure. Since then, they started hiring for
| levels below senior as well.
|
| Sadly, there are no engineering postings on their jobs page
| right now, so all I have at the moment is secondary sources[0]
| and personal accounts.
|
| 0. https://blog.pragmaticengineer.com/netflix-levels/
| mabbo wrote:
| > I'm sure they'll figure it out over time. But in the meantime,
| my days are quite frustrating because I'm in teaching mode most
| of the time instead of building stuff.
|
| This is what they hired you to do: to help them figure it out.
| Not over time, but right now. Your job is to power level them.
|
| You aren't there to build stuff anymore. You're there to make
| everyone else build the right stuff, the right way, and learn how
| to do it without needing your help anymore.
|
| For the company, you doing that job is more valuable than having
| you build everything yourself quickly.
| bitwise101 wrote:
| > I'm in teaching mode most of the time
|
| You have 13 years of experience in the industry more than your
| buddies. That's expected. And it's not wasted time.
| bigmattystyles wrote:
| You're lucky! You basically have an opportunity to multiply the
| way you work; every day, strive to make yourself redundant. Hand
| off as much as you can and support along the way; if you do this
| well, new, more challenging projects will find you. Second, don't
| treat them like children, but like peers. That being said, when
| the corporate bs comes for you or them, don't throw them under
| the bus. In fact, protect them. Laud publicly, be critical
| privately.
| jefftk wrote:
| It's not great that they didn't prepare you for this before
| coming on, but yes: as someone with 15 years of experience your
| job is not to get stuff done directly but to help your junior
| devs grow and compensate for their naivete.
|
| If you want to be building this directly you might want to
| consider startups or consulting, places where they need someone
| who both has real world experience and can build things? At a
| FAANG the reason they're willing to pay you so much is your
| leadership, mentorship, and teaching capacity: you plus a group
| of junior devs should be much more effective than the junior devs
| would have been without you.
| id00 wrote:
| > But in the meantime, my days are quite frustrating because I'm
| in teaching mode most of the time instead of building stuff.
|
| Look at this as a huge opportunity for you to grow and increase
| your impact, to become a staff+ eng. Uplevel, teach, "use" them
| as a lever to do at the end much more than you would be able to
| do alone
| taylorhughes wrote:
| Also it sounds like there is a need to be more aggressive with
| managing your calendar. At some point you have to organize your
| time into blocks where you can actually do work and manage when
| you are in "teaching mode".
| genderwhy wrote:
| Welcome to being a senior dev. Your job _is_ teaching, coaching,
| and developing others. Because the better and faster you do so,
| the better and faster the team will be at achieving your visions.
| You have the opportunity to set the direction for many engineers
| and build things bigger than you yourself can build alone, AND
| the people who will one day be able to help you do that.
|
| Teaching is an investment (and is, imo, super rewarding). Think
| about where your team will be in one year if you spend the time
| now to level up everyone.
| throwaway5959 wrote:
| As a senior dev, teaching should be a good chunk of the job. As a
| principal I spend a third of my time mentoring, a third of my
| time in arch/meetings, and a third of my time building (usually
| with other engineers doing some of the work). The lower you go
| down the ladder in terms of experience the more you should be
| coding.
| blindhippo wrote:
| As a senior dev theoretically on track for principal, I'm
| finding coding occupies maybe 10% of my time over a full year.
| The rest is largely in "leadership" meetings where we argue
| over details about goal language and trying to figure out how
| to blame project failures on "dependencies".
|
| Not really what I went into this field for. I miss my halcyon
| days being a low rank engineer churning out project tasks, but
| I do get the need for technical people to be providing the
| right guidance to help herd the cats in management.
| bradly wrote:
| Not at during my time at Apple, but I did experience this at
| Intuit. It seemed like the best way for a manager to be promoted
| was by their headcount.
|
| It's important when hiring to make sure you have the resources
| needed to bring someone on. For hiring a junior dev I would be
| asking myself if the team can dedicate 10-20 hours a week for
| pairing for six months.
|
| Also I find it helps both people if there is an expectation
| around when someone should feel comfortable. Again, no less than
| six months until I would expect them to feel comfortable.
| leetrout wrote:
| That's a very reasonable estimate for the drag a new person,
| not even just a junior, can put on a team! I like it!
| oconnore wrote:
| I think you need to consciously and continuously figure out where
| your time is best spent. There is a spectrum between situations
| where you can afford to let them make mistakes while figuring
| things out vs. situations where you need the team to execute to
| your own standards. You can evaluate this in multiple dimensions:
| productivity, system robustness, code quality, etc.
|
| Think in terms of interfaces, assertions, and consistency checks.
| How can you be more hands off in the areas where the bar can be
| lower? What does your involvement need to be when you need the
| bar to be higher? Is the bar high enough that they will tend to
| improve over time?
|
| If you are a perfectionist, you will simply end up doing more
| work than if you had done everything yourself. If you can create
| a structure that allows you to relax in some areas while helping
| the team grow their skills, then you will be more productive.
| barefeg wrote:
| Do you have some examples of situations where it's ok for them
| to make mistakes while figuring things out?
| goldeneye13_ wrote:
| In my experience this really depends on the type of the team. If
| it is a product team it is likely to have a lot of junior
| developers and not too many senior ones. If it is some deep
| Infra/backend team you can have a team that is mainly >L5. I was
| surprised when picking a team in FAANG the choices were you
| either join as a tl of a very large team of junior ish devs or
| you join as TL of a small team with mainly senior devs.
| turdprincess wrote:
| Unfortunately you will either need to change your attitude or
| change teams. In your position, the expectation is that you are
| mostly a working through others and acting as a force multiplier
| of their work. So doing stuff like:
|
| * figuring out what motivate your juniors and trying to align
| that with what needs done
|
| * giving them work which stretches their abilities but doesn't
| overwhelm them
|
| * giving them some space to fail but not too much
|
| * grooming your juniors to be leaders themselves so they can do
| some of this mentorship
|
| And in general, there are two ways to go. The first is to accept
| the fact that many senior engineering and most staff engineering
| gigs are more about this kind of mentorship approach than
| actually doing work. And basically accept that the prime "getting
| shit done" years of your career are done and you will mostly be
| working in this new way now.
|
| The second is to change jobs where you are back in the driver
| seat. As a senior engineer, these positions DO exist even at
| FAANG (over on my team, I am the most junior with 12 years of
| experience). However, the more senior you get, the harder it is
| to find a role like this, especially in big tech - its the rare
| exception. Startups and consulting gigs probably better align
| with wanting to be hands on keyboard, but at the price of a
| paycut.
| ChrisMarshallNY wrote:
| That seems like a fairly good example.
|
| For better, or worse, many tech companies, these days, seem to
| be obsessed with hiring large armies of inexperienced
| developers.
|
| I have always assumed that they rely on embedded process, to
| get these developers to work towards release-ready products,
| but they may also be relying on mentorship and training from
| senior developers (I like that, better).
|
| In my previous position, we did some fairly advanced and unique
| stuff (image processing pipeline stuff, in C++). It was almost
| impossible to hire engineers that already knew it. We had to
| look for people that "had potential," and hope to train them
| into a workflow.
|
| It also meant that each employee was a big investment in time,
| and encouraged us to keep them on board for many years.
|
| Training (I've done a lot) is a big fat pain, and not for
| everyone; but I feel that it is well worth it, to learn to do
| it.
|
| It makes you a "go to" person for problem-solving (which not
| everyone likes, but problem-solvers are _extremely_ valuable).
| It also engenders trust, deference, and respect.
|
| TL;DR, it's good for your own personal career, to become a good
| mentor.
| Silhouette wrote:
| _For better, or worse, many tech companies, these days, seem
| to be obsessed with hiring large armies of inexperienced
| developers._
|
| I suspect that has been true in many tech companies over the
| past few years but will be much less true in those same
| companies over the next few years.
|
| A culture where everyone with <10 YOE is job hopping every 18
| months for a big compensation boost does not encourage either
| investment in training up those people by a company or
| development of deeper skills and experience by an individual.
|
| If the recent trends in the tech employment market carry on
| this year I expect we'll see a lot more incentives for good
| people to stay with good employers for longer and a lot less
| willingness by employers to pay silly money for those with
| little experience and limited skills. Just like previous
| market swings we'll probably see less emphasis on hiring and
| more on stability and longevity of good working
| relationships.
| PragmaticPulp wrote:
| > * figuring out what motivate your juniors and trying to align
| that with what needs done
|
| This is true, but be careful about taking this too far.
|
| Young people arrive at the workforce with a wide range of
| expectations and motivations. Some of those are going to be
| unrealistic. You should always try to work with them to
| understand what drives them and help them find their fit.
|
| The most frequent misaligned expectation I've seen in juniors
| is the desire to lead greenfield projects in year 1 of their
| career. It can be very disappointing to arrive at your dream
| job and learn that you have to work on someone else's code, and
| that you have to build a reputation before they'll hand you the
| fun greenfield work.
| unsui wrote:
| Literally just had this situation come up in a recent 1:1
| with one of our junior devs.
|
| He asked about being able to work on greenfield projects
| focusing on AWS technologies.
|
| I had to go into a historical context data dump on the value
| of addressing technical debt (the project she is being
| assigned to), and how that frees us up to work on the cool
| and shiny projects.
|
| I think it landed, but I could see some of the fire slightly
| snuffed out of him.
| BurningFrog wrote:
| I wish there was more focus on working with existing code in
| education, since it is by far most of the work in real
| projects, and also the hardest.
| jeffwask wrote:
| >And in general, there are two ways to go. The first is to
| accept the fact that many senior engineering and most staff
| engineering gigs are more about this kind of mentorship
| approach than actually doing work. And basically accept that
| the prime "getting shit done" years of your career are done and
| you will mostly be working in this new way now.
|
| 100% and this is far from being a FAANG thing (never mind that
| FAANG doesn't even exist anymore). My experience is mostly in
| startup and PE based companies and it's like that there as
| well. The majority of my managers have been non-technical,
| corporate continues to shrink the management layer to "save
| money" (line managers with 20+ engineers), support roles like
| project managers in many places have been eliminated, and
| managers seem to spend the majority of their day dealing with
| comms so organizing and managing the doing aspects of doing
| work have fallen to me as a Principal, Staff, Lead engineer. My
| role these days seems to be to come in and bring organization
| to chaos, mentor / teach engineering (not how to code but how
| to be a professional engineer), be a tie breaker on big
| technical decisions, and set the vision and direction for my
| teams. Most folks I know who wanted to stay doers topped out a
| Senior or Engineer II and chose to stay there.
|
| This is also likely to just increase or accelerate as the baby
| boomer generation (the largest working generation ever) who
| occupies a lot of leadership roles these days start to retire
| and leave a huge gap in qualified and ready candidates to fill
| the void. There just aren't enough of us so I expect we will
| see more and more folks press ganged into leadership that never
| really wanted that.
| mixmastamyk wrote:
| Boomers already retired a while back, with few exceptions
| after covid.
| sidlls wrote:
| Those bullet points are spot on. Once you reach a certain level
| of experience, by years and/or breadth of experience, you are
| far more effective and valuable as a source of advice and
| education than as a code slinger.
| azangru wrote:
| > In your position, the expectation is that you are mostly a
| working through others and acting as a force multiplier of
| their work.
|
| OP said that his role is senior developer. Developer. Not a
| manager. Not a team lead. But someone who wants to write code,
| preferably together with other experienced developers, and by
| doing so, enjoy the process of learning and understanding
| technology at a deeper level. Why, then, would one expect his
| responsibility to be motivating juniors, giving them work, or
| raising them to be leaders?
|
| Also, if someone wants to write code, teamed up with other
| senior developers, where should one go?
| ctvo wrote:
| > OP said that his role is senior developer. Developer. Not a
| manager. Not a team lead. But someone who wants to write
| code, preferably together with other experienced developers,
| and by doing so, enjoy the process of learning and
| understanding technology at a deeper level. Why, then, would
| one expect his responsibility to be motivating juniors,
| giving them work, or raising them to be leaders?
|
| It sounds like you and the OP want to be "just" an engineer
| (mid level ), which is a terminal level at these companies.
| You can stay there your entire career, make the maximum
| salary for that band, and continue to focus mostly on writing
| code.
|
| Wanting the higher pay and title, but none of the
| responsibility isn't realistic. _You_ have misunderstood what
| the senior / staff role is, not the company. The expectation
| is you lead, mentor, and do less coding.
|
| Alternatively, become very, very deep at a niche field, like
| high performance computing, and go work for a trading firm if
| your goal is the same salary while focusing on writing code.
| Few others will pay you 500k+ to solve common distributed
| system problems and producing CRUD apps.
| jeffwask wrote:
| This is the most honest answer and something I have seen a
| lot folks who want the higher pay of the higher roles but
| none of the responsibility.
| azangru wrote:
| > lot folks who want the higher pay of the higher roles
| but none of the responsibility
|
| Isn't building a high-quality product with a sound
| architecture, while making correct technical decisions,
| and writing well-tested and properly documented code, all
| the while identifying and integrating the best practices
| that your field has developed so far responsibility
| enough?
| jeffwask wrote:
| Not really, no. The value of your contribution over the
| person next to you is marginal at best after a certain
| point. Even if you are say 50% more efficient than the
| next engineer. You will still be less valuable than
| someone who operates as a force multiplier improving the
| efficiency of 8 engineers by 15%.
|
| Now, don't get me wrong I love having doers on my team
| but when the rubber meets the road I'll reward the folks
| who lift all boats first.
|
| Especially with the rate of turnover these days, having
| someone who can rapidly onboard and get engineers up and
| running can make huge difference and if you are working
| on basic B2B SAAS stuff on standard languages, there are
| tons of good mid-levels out there.
|
| If you shift into niche languages or are doing something
| complex the equation is likely to change.
| celim307 wrote:
| This is what the role looks like in the vast majority of
| bigger tech companies, for good reason. Tech companies
| biggest hurdle is steering the boat. To launch anything you
| need to coordinate, align, and get consensus, beyond just
| your own team. Can engineerings develop in a vacuum? Can they
| take even well defined tickets, and build an optimal solution
| without knowing the product direction and vision?
|
| The manager is a people manager, not a product builder.
| Marketing, product, other engineering teams, all need to be
| aligned. As the most senior you're probably setting the high
| level architecture, so you're going to be the "API" or point
| of contact on which the other architects on other teams will
| need to communicate.
|
| Selling that architecture to juniors involves all those
| things mentioned, and as the architect you're responsible and
| the best person suited to judging their work as aligning with
| the vision/architecture. Senior role is usually defined and
| evaluated in performance reviews for the impact that goes
| beyond the code.
|
| I'm not explaining it super well, but its something you
| realize is a natural part of the role as an engineering
| leader. And that what a senior+ engineer is, a leader. Mid
| level engineer is a terminal role in a lot of companies for
| those who don't want the added responsibility.
|
| To your other point, there do exists teams where its all
| seniors who mostly do IC work. These are usually high-value,
| high-risk, core product engineering R&D. Or some kind of DX
| (Developer Experience) team where you are building tooling
| for other engineers, but even these teams too often has
| juniors, as at the end of the day, they are just another type
| of platform team
| BurningFrog wrote:
| > _Also, if someone wants to write code, teamed up with other
| senior developers, where should one go?_
|
| Many startups are like this.
|
| They're typically picky about letting new people in.
| thatguymike wrote:
| ...Because OP is getting paid a big salary to do what the
| business requires, not what they wish their responsibility
| could be?
|
| > Also, if someone wants to write code, in a team with other
| senior developers, where should one go?
|
| > Startups and consulting gigs probably better align with
| wanting to be hands on keyboard, but at the price of a
| paycut.
| azangru wrote:
| > ...Because OP is getting paid a big salary to do what the
| business requires, not what they wish their responsibility
| could be?
|
| Is this what the business truly requires though? As a
| person grows his skill in software development domain, does
| the business really require him to transition from being an
| expert programmer to being an unskilled manager? Being a
| competent software developer doesn't qualify one for a big
| salary?
|
| Isn't it what the Peter Principle was all about?
| Tyrek wrote:
| What the business truly requires is an abstract question.
| What the business expects of him, however, has been
| answered in this thread. The purpose of a system is what
| it does, etc.
| ChuckMcM wrote:
| Yes, and now his role is _developing_ the technical talents
| of others so that they too can be senior developers. If you
| 're in a large company that is 90% of what is expected out of
| senior technical people.
| slg wrote:
| I never worked at a FAANG. Do these teams not have managers?
| Most of those responsibilities seem like the job of a manager.
| In my career, this approach of one senior person on a team of
| juniors means the senior is responsible for a lot of the system
| design and other high level technical decisions, but they
| wouldn't be counted on for things like motivating other
| employees.
| [deleted]
| britch wrote:
| On my team at least there's a grey area between managers
| responsibilities and Tech lead responsibilities.
|
| Managers are ultimately responsible for getting tasks that
| stretch employees abilities, but also in my experience don't
| have hands on the code. They're usually dealing with politics
| around team priorities, goals, keeping people motivated, etc.
|
| Managers rely on tech leads to identify work that needs to
| get done and would be a good fit for the newbie. Tech leads
| also have to teach newbies best practices, offer advice on
| designs, etc.
|
| Managers are often technical (e.g. used to be programming
| daily), but are not actively writing code anymore.
|
| I feel this is a bad situation for tech leads since they have
| to sort of manage, and do design work, and write code. Kind
| of a thankless job
| scotty79 wrote:
| In my last corporate job we didn't have a manager. Tech
| lead was filling that role.
| giantg2 wrote:
| "Do these teams not have managers? Most of those
| responsibilities seem like the job of a manager."
|
| I wish! I do not work at FAANG, but I don't think I've had
| any managers that were that involved in our work. It's mostly
| a push-it-down-to-the-dev so everything is on the dev's plate
| at the end of the day. Which is funny, because I always
| thought the point if the manager was to remove overhead and
| coordinate the work so the devs can get more done.
| throw1234651234 wrote:
| You forgot the part where they:
|
| 1. Take credit for your work.
|
| 2. Promise to research something and tell you that you can
| get more work done because they are "handling it" and then
| provide no information, so you are saddled with MORE work
| in addition to what you already had to do.
|
| 3. Give direction without understanding anything to feel
| important.
|
| As you can see, there is some recent trauma here.
| refulgentis wrote:
| Same. Cosign, I've been prepped for it for 2 years and
| it's still a surprise and bad because I gave every
| opportunity, and then some, to prove it wasn't this silly
| and lazy. It is.
|
| They will tell you as little as possible, at the very
| last minute, when they get bored of you asking for help.
|
| You can literally change a field and if you expect your
| manager to do anything to help along the way, they won't.
| When you ask, they won't. When you ask again and
| highlight real bad behavior, they won't. When the
| bullying occurs right in front of them, they'll blame you
| and the other manager and tell you they didn't
| understand. Do. Not. Stress. Yourself. For. These.
| Places, dear Reader
| turdprincess wrote:
| I think in the end, it's hard to separate technical
| leadership from human leadership. After you do your system
| design, you need to divy it up amongst the juniors to get it
| implemented. When deciding who gets what piece you have to
| consider what motivates them, what their strengths and
| weaknesses are, etc... But for sure your manager is helpful
| in figuring these things out.
|
| At this level, your manager basically becomes your partner,
| with the same goal of getting the work done most effectively.
| Your domain is the technical, their's is the human, but there
| is ton of overlap in the middle
| iosguyryan wrote:
| It's rare a good architect is also a good (and willing)
| people manager. Organizations and teams profit most when
| separating those roles, unless you happen upon an
| individual who does both well. Separating mentorship and
| design from management has a huge cultural advantage:
| people who want to make more money don't have to always
| seek more political power, they can focus on technical
| skillsets that will make the organization wealthier and
| more fun to work at.
| throw1234651234 wrote:
| The architect ALWAYS ends up doing this. The other manager
| needs to be very active and engaged to actually deliver any
| value to the team and take some of this work off of the
| architect.
| harel wrote:
| Small correction: Consulting gigs are not a paycut. They are a
| pay multiplier.
| pyb wrote:
| OP never said he was their manager. In fact, OP's manager
| probably doesn't want him to be mentoring all day long.
| ceejayoz wrote:
| OP might consider _asking_ their manager rather than
| guessing.
|
| "Hey, there seem to be a lot of juniors. How do you want me
| to approach this?"
| eropple wrote:
| That's very frequently exactly what a staff engineer is
| expected to do at large orgs, though.
| mattpallissard wrote:
| I'd say this tracks my non faang experience.
|
| I used to find it frustrating to have a team full of greenhorns
| but changed my tune quickly. 1. They were
| eager as hell. It's refreshing to be surrounded by people like
| that. 2. You can get more done with them by training
| and helping mop up the occasional mistake than you can without
| them.
|
| In the end it was great but an entirely different role than
| what it said on the tin.
|
| > Startups and consulting gigs probably better align with
| wanting to be hands on
|
| Also tracks.
| nkingsy wrote:
| Echoing others, embrace it or move.
|
| I'm about a year and a half into working with 4 juniors at big
| tech, and I'm just amazed by how capable they are now. The first
| 3-6 months were slow, but now I am struggling to find things to
| do!
| hd95489 wrote:
| It's important to understand your metrics and position roles. If
| your role is to guide and teach do that. If your org requires you
| to commit more lines of code then tech the ones you like and let
| the rest drown.
|
| The success of the project is rarely your responsibility but if
| it is then obviously manage some sort of in between where you
| prevent damage, improve others work and do some of the core stuff
| yourself. This is the worse case scenario because you have to
| play both lead and manager
___________________________________________________________________
(page generated 2023-02-02 23:02 UTC)