Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Paolomania
Apr 26, 2006

In what way are they struggling? Ramp up speed? Self-sufficiency? Initiative?

Adbot
ADBOT LOVES YOU

Paolomania
Apr 26, 2006

StumblyWumbly posted:

The core one is probably an inability to admit they don't understand or clarify their issues, so I run into things like (vastly simplified example) "The instructions were unclear but I figured it out" "The instructions were 'Push button twice', I had to ask him to work with another engineer to understand it.

I tried to teach him about binary representation of numbers, he said he understood, I asked him a question, he got it wrong, I'm still not sure he understands.

He's a young guy and a hard worker, but the results and the ability are not there. I've tried giving him free thinking projects and extremely direct projects. He could have a place but design engineer is a tough fit.

Yeah some baseline level of critical analysis and self reflection is necessary to progress in just about any profession. I'd avoid handholding during initial implementation and get much more involved in guiding them through evaluating their own work in an almost socratic way. "what happens if it does this? try this parameter. write a unit test for X case ... did it do what you expected?" etc. Let them make the discoveries and come to the conclusions. If they can't handle that then I don't see how they could mature past entry level.

Paolomania
Apr 26, 2006

Vulture Culture posted:

Gentle nitpick:

Thank you for the effort post and good insight. To keep the conversation going: I interpret this particular case as an entry level engineer that is exhibiting overconfidence in their sloppy execution. They have also been unresponsive to direct feedback. IMO I would rather this engineer be humbled by guiding them to discover through their code's shortcomings than by causing a production outage with real impact to the business. Pedagogy is not the only concern here.

Paolomania
Apr 26, 2006

Vulture Culture posted:

Sidebar: your chances of humbling someone who's unreceptive to feedback are pretty slim. They already know that regardless of what you say to them, their work is obviously good enough to keep them employed. Sometimes people won't be disabused of that notion until they meet the Ghost of Christmas Future.
Point taken on the production outage example as I was just using that as a shorthand for some form of consequence as we don't know the full development workflow and release process that StumblyWumbly's team is operating under and I didnt mean to interrogate that and rather focus on coaching approaches (although of course review process and testing infra can provide some of the feedback here).

Don't you think its bit fatalistic to look at an overconfident entry level developer and say "this person's attitudes probably cannot be changed"? Early career is exactly the time you will have someone who has perhaps aced their academic and personal projects and does not yet have an appreciation for the complexities and scope of production systems as well as the level of collaboration needed to work on large projects. Of course everyone reacts differently and some will go imposter syndrome and some will go Dunning Kreuger and there is no one size fits all coaching approach, but I do think most at early career can mature to a healthy balance of confidence and self-skepticism regardless of their starting point.

Paolomania
Apr 26, 2006

leper khan posted:

If they're not utilized properly they cost an org 10x their rate for their output. I'd rather not have any, especially without strong review guidelines.

The true definition of a 10x coder.

Adbot
ADBOT LOVES YOU

Paolomania
Apr 26, 2006

Bojack Srcmain posted:

What's a solid number of engineers to have under you as a TL whose focus is primarily writing tech designs, reviewing product docs, planning rollouts, and doing code reviews? At 5 I'm feeling a little bit spread thin as there's a near constant barrage of incoming support tickets and questions as well.

I think this depends entirely on how much outside product- and project- management, release, operational, test and front-line customer support your team has. If you are purely engineers banging out bug fixes and features then yeah the number can be more than a handful, maybe 6-9 depending on how many junior level people you have, and still leave you on a technical track, but it sounds like you have a pretty high customer support load which is going to knock that down a bit.

My team on the other hand had our product and project management support taken away and our operational and test support abstracted up into a broader org, so I've pretty much given up on doing any significant technical work at 6 reports as I'm doing all of the team's product-, project- and people- management as well as participating in our various oncall and toil rotations.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply