|
Does anyone have any resources or advice on developing engineers? I'm interested in this from the lead and engineer perspective. I'm good at teaching myself and over the past 20 years I've never worked at a big company. I'm realizing that my tactic of "here's a problem you might like, go figure it out" may not be well suited to everyone, but I also have trouble judging effective ways of teaching and knowing how much time teaching is too much.
|
#
?
Nov 22, 2023 14:17
|
|
|
|
| # ? May 23, 2024 19:26 |
|
|
StumblyWumbly posted:Does anyone have any resources or advice on developing engineers? I'm interested in this from the lead and engineer perspective. Your goal is to keep someone in their proximal zone of development. And to work with them directly to align interests with assignment.
|
|
#
?
Nov 22, 2023 14:41
|
|
|
StumblyWumbly posted:Does anyone have any resources or advice on developing engineers? I'm interested in this from the lead and engineer perspective. I was a tech lead who spent a ton of time mentoring and I still do a lot of mentoring in my new role. Heres some of what I found helpful. I offer weekly one-on-ones with developers. Every meeting I start by asking them if theres anything they want to discuss or if they have any questions. Most days they dont, which is fine; but now they know theyre allowed to ask and occasionally they will. Unless the engineer has something obvious they need help with (one needed help with the type system, another struggled with English so I taught them to comment everything as a tool to get them to understand existing code before making changes, etc) by going over the coding standards with them and using that as an opportunity for story time both yo explain the reasoning behind the standards and also dive into code examples. Code examples will often diverge into discussions of code base or language peculiarities. Most days it is fun for me and since 80% of the team still comes they must be getting something out of it. The other thing I do with everyone is give them advice on how to manage up and direct their career trajectory. When annual/quarterly reviews rolls around, I remind them that they get out what they put in and that a good manager wants them to succeed, so they should sincerely discuss their areas of interest or ask for help developing skills they want to improve in. Sometimes this means they have basically the same discussion with me before and after the formal meeting with their manager. The feedback I have gotten is that these sorts of prep sessions are very helpful, but dont try to force them, just make sure they know its an option. During Benefits selection Ill ask if they want to cancel the meeting and use the time to review their benefits instead. Some do, some dont. Some want to ask questions about benefits, all but the most trivial I show them how to ask HR/our manager instead. Occasionally Ill teach someone how to make a budget. Its shocking that the US school system doesnt do this. Its not directly work related but someone needs to do it and a reduction in stress at home often leads to positive improvements in work performance. After that I move onto one of: Asking what they want to focus on next, most of the time they dont know what they dont know and thats fine. Thats our job, but if they do, thats great. Pair-reviewing where we review or re-review a recent or current PR together. Working through Cracking the Coding Interview together (People with BS degrees often have no or very little understanding of algorithms). You can work through your favorite development book together too. This is mostly a springboard for more discussion anyways and a little bit of coding practice. Refactoring code that bugs me with them (again, this should be a springboard for discussion about why the old code was bad and the new code is good). Polishing up the UI is especially good for this as so much of UI is a judgement call, it really takes a lot of examples to start seeing improvement. Anything else that can serve as a springboard for discussion. The other thing I have seen that works really well is lunch and learns where everyone watches a presentation and then discusses it. One of my previous coworkers loves watching developer conference presentations and ran a monthly meeting where he showed his favorites. It was great! When he moved on I took over running it and found picking out good videos to be a miserable slog. So dont try and force it. But if you already like watching those or know someone who does it can be a great tool, and fun besides. This is already lot of words so Ill wrap this up with one last way I mentor. Every code review is an opportunity to help a developer improve. I try to make the time to explain the reasoning behind every change request and often will call/visit for a chat about requested changes. Over time this can really help someone improve. Like all learning, it takes a lot of repetition so try not to get frustrated or discouraged when you see someone making the same mistake over and over and over again. Also, Im not perfect and dont always have time to give the best explanation, or sometimes any explanation. Theres always another review to do, though, and thus another opportunity for growth. Oh, and I strongly recommend finding a peer mentor. I found having one both helpful and a great stress reduction. Even effort posts like this can only ever be a fraction of the time investment a mentor at the same company can offer you. LLSix fucked around with this message at 15:12 on Nov 22, 2023 |
|
#
?
Nov 22, 2023 15:03
|
|
|
StumblyWumbly posted:Does anyone have any resources or advice on developing engineers? I'm interested in this from the lead and engineer perspective. In my opinion, the hardest part of mentorship is keeping an eye on the long view. It's a little bit like raising kids: if you see them every day, and you aren't putting marks on the door frame, you'll never notice them growing. Either make marks or keep enough distance that you notice how much they've grown when you see them. Part of growing is making mistakes. It's the reason teenagers and mid-level engineers make so many bad decisions. You need to create a safe environment for mistakes, you need to let the mistakes happen. If you're invested in the outcomes, you have to let the person figure out when they're in over their head and give them the opportunity to ask for help. If they don't recognize or have trouble asking for help, you have to correct that. This builds the framework for the rest of your mentorship. Be involved, but not so involved that you can't see them growing, and not so involved that you're averting mistakes before they happen. (Let the normal work processes avert mistakes where they're designed to avert mistakes; help your mentee understand them and don't turn a blind eye to them.) My preferred mentorship style is a little bit like The Doctor (Doctor Who) dragging companions on an adventure. My style is deeply immersive and is very much not for everyone. I am also very, very good at it. I'm not vain, but I also know when I'm not the right person for a job, and more reserved and cautious people are almost always better with a different mentor. Don't be afraid to turn people down, or to help them find the right mentor for their learning style. It isn't on you to be that person for everyone, though it might be on you to help connect someone to the right resources to help them grow. Tactically: encourage people to copy and paste code instead of building a new abstraction the first time they spot duplication. You wouldn't believe how far this will get you. Vulture Culture fucked around with this message at 15:30 on Nov 22, 2023 |
|
#
?
Nov 22, 2023 15:27
|
|
|
Vulture Culture posted:Management isn't just a manager's job, and there is a component of "it takes a village" when you're working with a healthy team. The main difference between management and coaching or mentorship is that a coach or mentor is invested in outcomes for a person's sake, and a manager is invested in outcomes for the business's sake. You need to figure out how much this plays into your situation as you decide on an approach. This is one of the reasons I prefer being a staff engineer to a manager. My approach is very much mentorship. I make sure to point out which standards are industry wide and which are specific to our company, and which most companies have some version of, but don't all agree on the specific details for (e.g. spacing around parentheses). My goal is to help them be the best version of themselves. If the company benefits, that's a bonus. And the company does benefit, but it's not the goal. When the needs of a person conflict with a company, I'll pick the person every time. Because they're a person and a company is this made up thing. I even advised one engineer who really wanted two raises in back-to-back years that he needed to job hop if he wanted a raise again. I've never seen someone get two raises in a row. Surprisingly he's still here which is good because he's a good engineer and I would have been sad to see him go, but he deserved honest advice from me. My teaching style is the same as my learning style. 1) I like to watch someone do a thing once, and explain what they're doing as they do it. I take lots of notes during this process. 2) I like to try it myself with them there to correct me when I make a mistake; updating my notes as I go. 3) I like to try it on my own; using only my notes as a guide, and ask them to review it 4) I can now do it on my own and have a documented process I can send other people if they need it; or follow when teaching for anything complicated. Your teaching style sounds a lot more fun than mine. Vulture Culture posted:Tactically: encourage people to copy and paste code instead of building a new abstraction the first time they spot duplication. You wouldn't believe how far this will get you. Also, thanks for the book recommendations. I'm going to be reading one of them this holiday weekend. LLSix fucked around with this message at 18:28 on Nov 22, 2023 |
|
#
?
Nov 22, 2023 18:07
|
|
|
LLSix posted:Whyyyyy? This seems opposite the usual advice. Yesterday, I helped an engineer fix a bug (the second time) caused because some code that got copy and pasted not 5 lines apart and it still only got fixed in one of the two places. Ive seen more atrocities committed in the relentless pursuit of DRY than the bugs that pop up from some missed copy paste.
|
|
#
?
Nov 22, 2023 18:15
|
|
|
Guinness posted:I’ve seen more atrocities committed in the relentless pursuit of DRY than the bugs that pop up from some missed copy paste. Ironically, I've seen more useless repetition in hardline DRY than in copy/paste. Building abstractions before you've detailed the problem is always a mistake.
|
|
#
?
Nov 22, 2023 18:18
|
|
|
leper khan posted:Building abstractions before you've detailed the problem is always a mistake. Yeah this exactly. n = 2 use cases is often not enough to generalize and then when the third or fourth use case eventually come along it gets shoehorned in to a bad abstraction Especially when someone is wading into unfamiliar territory and doesnt understand the full scope and impact of business logic Guinness fucked around with this message at 18:33 on Nov 22, 2023 |
|
#
?
Nov 22, 2023 18:30
|
|
|
Thanks for this, this is mainly in line with what I've been doing, but it drives home how much time it requires (more than I have), and its good to hear confirmation. There's one entry level engineer in particular who is having trouble growing. I think they need a very different style from what we can provide, but at the end of the day it is what it is and maybe we just aren't the right place for him.
|
|
#
?
Nov 22, 2023 18:32
|
|
|
In what way are they struggling? Ramp up speed? Self-sufficiency? Initiative?
|
|
#
?
Nov 22, 2023 19:02
|
|
|
Guinness posted:Yeah this exactly. n = 2 use cases is often not enough to generalize and then when the third or fourth use case eventually come along it gets shoehorned in to a bad abstraction I call it "dying on the hill of DRY." I've also continuously run into generalizations that were solely there for future proofing. You know, "we might need to account for this case in the future." My most successful (by my standards) team to date became really disciplined about only solving the problem in front of us, and it led to better code, deployed faster. The vast majority of the time the future case never happened. When it did, and we decided that it justified a refactor towards a generic implementation, we had those specific cases already deployed and debugged and surrounded with unit tests. Made it safer in my opinion.
|
|
#
?
Nov 22, 2023 19:35
|
|
|
Paolomania posted:In what way are they struggling? Ramp up speed? Self-sufficiency? Initiative? 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.
|
|
#
?
Nov 22, 2023 19:37
|
|
|
Che Delilas posted:I call it "dying on the hill of DRY." DRY and YAGNI. Like peanut butter and jelly
|
|
#
?
Nov 22, 2023 19:46
|
|
|
Che Delilas posted:I call it "dying on the hill of DRY."
|
|
#
?
Nov 22, 2023 20:17
|
|
|
Oh yeah. That makes sense. I work in c so people using too much abstraction isnt my usual problem.
|
|
#
?
Nov 22, 2023 20:24
|
|
|
Vulture Culture posted:What's really neat about this is that the tests on your first pass almost certainly documented the most specific cases that were necessary in production. The generic implementation probably didn't do this half as well or as obviously Exactly. You get your first and arguably most important behaviors, blueprint them with tests, and later you can refactor with confidence.
|
|
#
?
Nov 22, 2023 23:08
|
|
|
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. 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.
|
|
#
?
Nov 23, 2023 01:49
|
|
|
I got scheduled for the third year in a row for on call shift over 12/24-12/31 and had to, for the third time and also 3rd major holiday this year, request a change in Slack multiple times before any acknowledgement. Not much to ask, just venting but I wish my team lead or manager had any semblance of leadership about them. Our schedule is autofilled on a rotational basis like A -> B -> C -> A -> B by some random guy on my team who never accounts for PTO or holidays and our lead and manager never intervene so I have to be like "hey I'm scheduled for a holiday yet again" which seems unfair.
|
|
#
?
Nov 26, 2023 18:55
|
|
|
Good Will Hrunting posted:I got scheduled for the third year in a row for on call shift over 12/24-12/31 and had to, for the third time and also 3rd major holiday this year, request a change in Slack multiple times before any acknowledgement. FWIW I think the conversation you're mentioning is a good topic for a team meeting/etc rather than hashing it out over slack if you're not getting a response. If I need coverage and it's not urgent, I'll toss it out on slack but also just remember to bring it up at the next team meeting. A broader term topic is I would recommend you try and discuss this scheduling stuff with your team anyway; it sounds like basically the year is evenly divisible and you're getting stuck with the oncall stuff. I had this issue on a previous team (that I did the scheduling on) so eventually I just showed up and went 'hey I've had to work 50% of all the holidays so far this year, and I'm scheduled for 25% more. Let's fix this.' Most people are going to be fine with something equitable to all parties, so I wouldn't feel bad about saying 'hey I'd like to have the oncall split more equally'. I actually wrote a blog post recently that covers how I think teams should approach oncall in general, so if quoting a random website helps you, feel free to use it: https://blog.crabbo.dev/oncall-101-oncall-is-work/. Re-reading it I realize it doesn't include anything about equitable treatment, so I'll probably slap out another post about that.
|
|
#
?
Nov 27, 2023 06:45
|
|
|
Paolomania posted: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. The Socratic method involves open-ended, thought-provoking questions that are designed to elicit well-reasoned responses. It's supposed to teach ontological reasoning by exposing hidden assumptions and biases. It isn't designed to transfer skills or methods. Learners need to explore new areas in both breadth and depth. The main attribute of the Socratic method, done well, is that it allows the student, not the teacher, to drive the conversation in a productive direction by demonstrating if more breadth or more depth is needed, and giving them the latitude to ask questions on the right vector. Those really specific questions have a place: when someone believes they know something but you absolutely need to prove to them that they don't. A lot of the worst online debates go this way. It only works when everyone involved enjoys playing this game, or all the other options have been exhausted. It's better to ask the hard questions early. What do you think are the main concerns that we have to consider when we're looking at this problem? Okay, so what problems or edge cases does that suggest the implementation might run into? What assumptions are underlying that thinking? Does breaking down this general case into multiple more specific cases improve or degrade the user experience here? What if you changed some of the details, does the same line of thinking still apply? Where do you think this approach breaks down? You might notice that these are also the kind of questions that get asked in good design meetings. Coaching someone through their approach at the beginning is often the better place to do it. At the end, it's better to check in and see what they learned and what they might try differently or change the next time they see a similar problem. Laid out this way, these patterns all start to sound really familiar.
|
|
#
?
Nov 27, 2023 19:37
|
|
|
Thanks to whoever recommended An elegant puzzle a while ago. I'm slowly making my way through it and I appreciate the hell out of it. Very jumpy, very much "Here are some well thought out things that worked for me". But it is helping me get some perspective on my own work.Rocko Bonaparte posted:Does anybody have anything for improve how to technical writing that "aims upwards?" I'm talking less about documentation and manual stuff and more about proposals and arguments. I'm having to do that a lot more and hoped there was a book or two that go that way.
|
|
#
?
Nov 28, 2023 04:47
|
|
|
Vulture Culture posted:Gentle nitpick: these kinds of questions aren't the Socratic method. Done wrong, they can create a scenario where one person is perceived to already know the answers and enjoys watching another person continuously make predictable, avoidable mistakes. I often see it done, often by the most empathetic, well-intentioned, and socially intuitive engineers in an entire organization, in a way that wastes time and degrades trust. The questions are great for someone who's stuck, but also, if you've already distilled a problem-solving approach down to a flowchart, just write it down and share it. No point being a bad linter that exits immediately on the first warning it sees. I think this is really good advice, because I've struggled with this specific problem and hadn't been able to wrap my mind around the problem until you articulated it.
|
|
#
?
Nov 28, 2023 06:47
|
|
|
Yeah, thanks a lot. I think I'm guilty of this specific thing and am going to have to pay attention to it.
|
|
#
?
Nov 28, 2023 11:54
|
|
|
Vulture Culture posted:Gentle nitpick: these kinds of questions aren't the Socratic method. Done wrong, they can create a scenario where one person is perceived to already know the answers and enjoys watching another person continuously make predictable, avoidable mistakes. I often see it done, often by the most empathetic, well-intentioned, and socially intuitive engineers in an entire organization, in a way that wastes time and degrades trust. The questions are great for someone who's stuck, but also, if you've already distilled a problem-solving approach down to a flowchart, just write it down and share it. No point being a bad linter that exits immediately on the first warning it sees. Wow, Fantastic!
|
|
#
?
Nov 28, 2023 18:24
|
|
|
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.
|
|
#
?
Nov 28, 2023 18:37
|
|
|
Paolomania posted: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. I ask because in a well-designed workflow, work that visibly misses a quality bar doesn't take down production, it just doesn't ship until it hits the bar. If this is the case, is it possible people are taking heroic measures to help another engineer hit deadlines? Deadlines that they would otherwise be obviously missing, generating significant management interest in that person's work? On the other hand, if you have rules that only apply to some people some of the time, you've actually given an escape hatch to anyone who's bad at their job who wants to claim that they're being treated unfairly. 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. Vulture Culture fucked around with this message at 21:30 on Nov 28, 2023 |
|
#
?
Nov 28, 2023 21:20
|
|
|
Vulture Culture posted:Done wrong, they can create a scenario where one person is perceived to already know the answers and enjoys watching another person continuously make predictable, avoidable mistakes. I often see it done, often by the most empathetic, well-intentioned, and socially intuitive engineers in an entire organization, in a way that wastes time and degrades trust. Your whole post is excellent, and helps think about some things. I'd like to ramble about the quoted portion for a bit. I personally struggle with this topic a lot. Being an effective leader is really challenging on its own - add into the mix "up or out" 9 box people, expert beginners, and more and it gets soul-crushingly challenging. It only takes more than one on a team to be a constant battle. The line between helpful direction and condescending control freak feels super thin and nebulous. Managers have the carrot and the stick, tech leads have neither. I'm starting to dislike what I do for a career, because it seems like my happiness is directly tied to the luck of the draw and which people I end up on a team with. quote: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. One of the truest things ever.
|
|
#
?
Nov 29, 2023 01:03
|
|
|
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. 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.
|
|
#
?
Nov 29, 2023 15:22
|
|
|
Paolomania posted: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. You're dead-on with how you describe that archetype. There's a chance that they'll figure it out on their own, and in my world, that's fine as long as I see enough improvement to make confident guesses about their trajectory. Without that, the most charitable thing I can call them is a low performer. Given the opportunity to put in the effort to 2x the impact of a high performer or a low performer, I will always pick the high performer. Over-investing in the low performer is a mistake that's unfair to the company, the team, and the high performer. I'm empathetic to someone needing a lot of patience and space and room to grow into a new role. This is also the tech industry, and I'm not generally assuming that someone with a hotshot attitude is planning on sticking around the company for four or five years. (This is a heuristic, I've been wrong on it before, and some people have really surprised me.) And yeah, "unreceptive to feedback" is a broad spectrum. You have people who have real poo poo attitudes, and you have people who are really receptive to feedback but manage to not really internalize or act on any of that feedback. On the other end, you have managers and colleagues who over-massage and poo poo-sandwich their feedback to the point where the message is completely lost or couched in opinion. My default is to deliver the feedback three times in different ways, and then find someone else to deliver the feedback. If conversationally trying to improve someone's performance isn't moving them to hit the bar, they get to hear the feedback in perf-oriented language. luchadornado posted:I personally struggle with this topic a lot. Being an effective leader is really challenging on its own - add into the mix "up or out" 9 box people, expert beginners, and more and it gets soul-crushingly challenging. It only takes more than one on a team to be a constant battle. The line between helpful direction and condescending control freak feels super thin and nebulous. The line feels really thin and nebulous if you let the line be thin and nebulous. If you hold the line, and you do it consistently, people will eventually know exactly where the line is, and once you can both show you're aligned on where it is, it's your opening to let them move it. This is sometimes hard for them to grasp in a field where management is often such an absentee, negligent affair that people are prone to confuse any management at all with micromanagement. You have to be confident where this is a you problem and where it's a them problem. Vulture Culture fucked around with this message at 16:39 on Nov 29, 2023 |
|
#
?
Nov 29, 2023 16:24
|
|
|
I forgot I was involved in this conversation because the person I brought up is actually a hardware engineer, so some things are very different. A great example: He ordered prototypes of a production sized (ie very small) board, which I think will be hard to assemble and test. He's confident he can solder things together and get everything working. If he's right, we save 2 weeks calendar time, I'm pretty sure he's wrong we will waste 2 weeks calendar time. A few things make this very much a "try and see" experience. I think the core difference between my situation and what Vulture Culture describes is that there is a lot of space between a "good" design and a "obviously flawed" design. This can happen in software as well, but there are usually style guides to guide you because at most places a small SW team is still 3x the size of the hardware team. A recent situation involved looking at a chip he had selected and saying thing like "This isn't how the chip is generally used" "I don't interpret the specs the same way", but the guy is confident the chip will work and we end up wasting a bunch of time because I'd rather not say "I have no faith in your idea, use mine". The situation isn't helped by me being overworked in general. I'm moving towards divesting some of the teaching and encouragement to a nice senior engineer, and I'll hang on to performance reviews and brutal honesty. Aiming to not just be a wire mother, but we'll see how it goes. Vulture Culture posted:The line feels really thin and nebulous if you let the line be thin and nebulous. If you hold the line, and you do it consistently, people will eventually know exactly where the line is, and once you can both show you're aligned on where it is, it's your opening to let them move it. This is sometimes hard for them to grasp in a field where management is often such an absentee, negligent affair that people are prone to confuse any management at all with micromanagement. You have to be confident where this is a you problem and where it's a them problem. Focusing on project issues and facts, and just communicating enough so any slights are lost, has gotten me through some very sticky situations. Engineers naturally have their/our ego tied in with their work, and it is tough not to take statements about the work personally.
|
|
#
?
Nov 30, 2023 02:36
|
|
|
StumblyWumbly posted:I'd rather not say "I have no faith in your idea, use mine".
|
|
#
?
Nov 30, 2023 15:14
|
|
|
I've generally found it best to separate "I have no faith in your idea" and "Use mine". I've found that frequently when I've been smart enough to identify a flaw in someone's approach that has given me over confidence that I also know the right way to do it. "I don't think this is the right approach, can we spend some time seeing if there's a better way?" is a much better starting point, for myself at least.
|
|
#
?
Nov 30, 2023 15:46
|
|
|
Vulture Culture posted:One of my cocktail napkin measures of team health and psychological safety is what would happen if someone said exactly this to another team member I've worked with a surprising number of developers who would be happy if someone did this because if the idea didn't work out, they could blame the idea giver.
|
|
#
?
Nov 30, 2023 17:05
|
|
|
StumblyWumbly posted:I'd rather not say "I have no faith in your idea, use mine". Intel had a Corporate Value about this, "Disagree and Commit" You said your piece, the team decided otherwise, but we need your technical expertise so... get to work. I'm pretty sure it was printed on the calendar they'd give out to have on your badge lanyard.
|
|
#
?
Nov 30, 2023 18:22
|
|
|
I've recently gone with "I suspect this option won't pan out because xyz -- but I'm not the one doing the work and I'm always happy to be proven wrong"
|
|
#
?
Nov 30, 2023 18:51
|
|
|
I normally go with this line https://youtu.be/QriZJ-X3wbU?si=F2hV8wIplyJftxJ1
|
|
#
?
Nov 30, 2023 19:26
|
|
|
JawnV6 posted:Intel had a Corporate Value about this, "Disagree and Commit" You said your piece, the team decided otherwise, but we need your technical expertise so... get to work. I'm pretty sure it was printed on the calendar they'd give out to have on your badge lanyard. That's an Amazon Leadership Principal as well, and IMO it's a really good idea and maybe one of the smartest things they do there. Any job is going to ultimately end up with you having to do things you don't agree with; that's how a job works. Sometimes people interpret that as 'oh, I shouldn't bother speaking up at all, since it won't matter' and that's a surefire way to breed resentment, because suddenly the people making the bad decisions don't even have to think about the negative parts, and people who are reasonable and just sometimes make a bad call won't ever realize that there was a problem. The trick is to realize that you're just going to not always get what you want, and learn to not invest your whole personality and self-esteem out of it. It's how I've approached my job for a long time, and it's always worked really well. I've always been really straightforward with my boss about my opinion, but as long as I felt I got heard, I was also happy to just make the best out of a situation I disagreed with. Notably the 'things I disagreed with' were never like 'go drown a man in cold blood', but more like 'This is risky and will result in extra work, etc'.
|
|
#
?
Dec 1, 2023 09:52
|
|
|
Falcon2001 posted:That's an Amazon Leadership Principal as well, and IMO it's a really good idea and maybe one of the smartest things they do there. Any job is going to ultimately end up with you having to do things you don't agree with; that's how a job works. Sometimes people interpret that as 'oh, I shouldn't bother speaking up at all, since it won't matter' and that's a surefire way to breed resentment, because suddenly the people making the bad decisions don't even have to think about the negative parts, and people who are reasonable and just sometimes make a bad call won't ever realize that there was a problem. The trick is to realize that you're just going to not always get what you want, and learn to not invest your whole personality and self-esteem out of it. You can either not always get what you want, or never get what you want. I'll take not always.
|
|
#
?
Dec 1, 2023 14:57
|
|
|
Bruegels Fuckbooks posted:I've worked with a surprising number of developers who would be happy if someone did this because if the idea didn't work out, they could blame the idea giver.
|
|
#
?
Dec 1, 2023 16:24
|
|
|
|
| # ? May 23, 2024 19:26 |
|
|
Yeah. The best teams I experienced were always very vocal, but people were also ready to listen. Strong opinions loosely held, to proverbialize it.
|
|
#
?
Dec 1, 2023 16:34
|
|
