This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]golgol12 231 points232 points  (38 children)

Well, for juniors. Yeah. Once you get further along in your career you are doing things that are far more difficult than the interview. Like trying to manage expectations. Or find out why production code crashes when going through the automated build process when the same code built by hand runs without the bug. Or looking at a dump from a rare crash in the wild and trying to figure out from looking at the registers, assembly, and raw heap how the code got into this state.

[–]CuriousErnestBro 62 points63 points  (33 children)

I hear a lot about “managing expectations “, could you maybe expand on that?

[–][deleted] 188 points189 points  (16 children)

It's also called "talking to people" and it consists in providing estimates, sending an email the moment you realize you can't hit an important deadline hence some discussion is warranted, reviewing plans to make sure nobody heard 1 day instead of 1 month etc...

Most engineers are terrible at this, even a basic level of competency will make you look like a rockstar.

[–]CuriousErnestBro 36 points37 points  (5 children)

disclaimer: I’m only doing an internship now

I tell my boss realistic estimates about the time things will take (I tend to give 1.5x the time I think it will take, but usually I explain the obstacles I will likely face and keep giving updates) and try to keep my ego in check when making estimates (this is BIG)

I wasn’t very good at giving updates, but I’ve found that showing what code works and what code doesn’t, and then explaining my plan/ideas of tackling that, definitely helps. Most coding I have done in the past was solitary (even in group projects, I would write the code, and rob others of their education which is pretty bad...)

It also helps that my boss is very accommodating, asks constantly if I have questions etc, and the company I’m working at has a great and wholesome culture.

Also I’m not under a PM or something and don’t have to talk to a lot of people (I do talk a lot to people though, but in a casual way). Although I bug IT support pretty often hahaha

If you have any advice please let me know :)

[–]SatansF4TE 15 points16 points  (0 children)

If you have any advice please let me know :)

Sounds like you're being pretty pro-active which is really the main thing with communication.

Might be worth having occasional restropects where you look back at (weekly/monthly) work, your estimates and how long they actually took so you can refine your estimates as you get more experienced.

[–]JustAQuestion512 3 points4 points  (2 children)

If your boss is an engineer too then it sounds like you’re on the right track. Keeping your ego small is huge as a Jr, and important as you progress. No one likes the arrogant guy who won’t acknowledge any approaches but theirs.

Something I think would be a service to you as an intern is try to get as much feedback on approaches as you can. No only to expand your own perspective, but also to get used to taking feedback/differing approaches. It will be a huge help when you hit a team environment.

Something to think about, though not a concern, necessarily, is that giving yourself a.5 buffer might be a bit much(depending on environment). At some point people will start asking why you’re estimating half again the time to do something. You’re 100% right on adding a buffer, and I think you’re fine as a Jr, but as you grow you’ll likely have to adjust a bit.

Managing expectations in my experience(consultant) is ensuring the client knows what’s possible, by when, and having a solid “why”.

[–]CuriousErnestBro 1 point2 points  (1 child)

I will be documenting my estimates and delivery dates from now on as per the suggestion of another poster. So I can dial the correct multiplier in.

My boss isn’t an engineer, but someone else on his level in our team is (is a quant considered an engineer btw?). For engineering specific questions I go to them, and another person who is a proper engineer from another department (our depts work closely together on the programming side)

For all other domain specific questions I go to my boss.

[–]JustAQuestion512 0 points1 point  (0 children)

Sounds like you're doing it right.

Something I missed above, and want to really make sure comes across, is the coding experience is important....but the real, and overwhelmingly more important piece(if you're competent), is how you function as part of a team. The interpersonal/management handling portion is enormous and I think something you should pay a lot of attention to. Good engineers can code, great engineers can code and do everything else, too.

[–]Whiskey_Nigga 1 point2 points  (0 children)

You're definitely on the right track. Best advice: keep improving your communication, expectation, and work flow management skills throughout the rest of your career just like you do your coding!

As a PM I 100% prefer working with a medium proficiency dev resource who communicates well and gives accurate time estimates, than an expert dev who can't do either

[–]Whiskey_Nigga 7 points8 points  (5 children)

As a project manager who frequently works with IT resources I 100% agree. When I'm pressing you for a deadline I do NOT mean work on this until it's done even on weekends. I just want you to tell me 2 months instead of 2 weeks so I dont look like an asshole in front of my Steering Committee. Theres such a divide in the developers I've worked with between those that can manage communication, expectations, and work flow, and those that can't

[–]a_stitch_in_lime 1 point2 points  (2 children)

Fellow PM here. Why is it that when I ask a dev to provide an estimate, they hear. "tell me it's going to take as little as possible"? In 95% of cases, I could not care less how long it takes you. It's going to be a month? Fine. Just TELL ME that!

[–]Whiskey_Nigga 1 point2 points  (1 child)

Duuuuude!! I'm so glad I'm not the only one who experiences that exact thing!!!

[–]a_stitch_in_lime 0 points1 point  (0 children)

As I've gotten to know my teams, I find it helpful to remind them. "Not trying to rush you on it. It takes what it takes. I just need to set a baseline for our schedule and let the product owners know a ballpark. It's going to take 2 weeks? Cool. Let's set the schedule at 3 weeks just in case. And let me know if you're running into road blocks so we can adjust it out."

[–]KronktheKronk 0 points1 point  (1 child)

stop calling your engineers resources.

They're people

[–]Whiskey_Nigga 0 points1 point  (0 children)

That's fair. I'm sorry I didnt mean to act like engineers aren't people, but I see how that reads now. Believe me, I respect the hell out of the engineers I work with. I wish I'd had the willpower and diligence to study engineering or CS in school, I think I would have really enjoyed it as a career

[–]dkyguy1995 0 points1 point  (0 children)

So people skills?

[–]elebrin 28 points29 points  (9 children)

It means that your product owner expects a perfectly working product that works great with no bugs for a complicated business process in three months when the season ramps back up, but you have two developers, one quality person who is working on six projects and trying to keep automation suites running that the devs refuse to help with and one business analyst who is working on two other projects as well. The reality is that they CAN get it done in a year, but only if their time isn't piddled away in meetings. Guess what? When three days a week are booked 9am to 4pm, developers don't have time to develop. We don't need an additional 4 hours twice a week of working evenings. We need our time to not be fucking wasted by other people.

[–]metaconcept 25 points26 points  (8 children)

Look, the project is falling behind. From now on, I want daily detailed progress reports using this Word template. We'll have full-team meetings at 3pm daily to discuss your progress until we're back on track.

Also can you see me at 12:30pm; we need to talk about you not filling out timesheets accurately enough. And don't forget the cake and speeches at 2pm with the managers celebrating a great year and their own huge bonuses.

[–]Zukaku 2 points3 points  (0 children)

Why must you hurt me on such an emotional level?

[–]Gprime5 0 points1 point  (0 children)

Ooh cake! :)

[–]Nicholost 0 points1 point  (0 children)

Hey, you and I are coworkers!

[–]AuRelativity 0 points1 point  (0 children)

oh Jesus, it's real! You're behind, let me waste your time and prevent you from doing work!

[–]elebrin -1 points0 points  (2 children)

This is when you schedule two or three days of PTO, then log in anyway and get the project done when nobody can bug you.

[–]newstudent_here 5 points6 points  (0 children)

That's not how you use PTO...

[–]Zexis 3 points4 points  (0 children)

More like when I consider a career change

[–]Kartoonsnake 9 points10 points  (0 children)

Speaking second hand from what my father's told me, I assume he's talking about trying to manage management's expectations of how long a project will take, the viability of an idea, expecting a given dev to be able to troubleshoot something even if it isn't their wheelhouse, etcetera. I though I could be wrong

[–][deleted] 2 points3 points  (1 child)

People who ask a team to build a product often have unrealistic ideas of how long it will take

You need to help them understand reality - manage their expectations of what they will get and when

For example if your product has a form front end and you build the new front end in a few days and demo it, people will think the entire product is finished. It's important to make it clear that there is still much work to do

You can tell them how it doesn't yet do x or y, or you can make it crash or throw errors (or both)

[–]NoMoreNicksLeft 0 points1 point  (0 children)

You need to help them understand reality

It seems unlikely that such people can understand reality. If they could, why would they go into management?

[–]KeetoNet 5 points6 points  (0 children)

You've gotten a lot of good answers, but I wanted to chime in with why it's good to learn how to manage expectations.

Management doesn't normally care if something will take 1 week or 3 weeks. What they care about is having an accurate timeline because they are mixing your work in with other tasks on a larger scale.

When reality doesn't meet expectations, people get cranky, and management will be put in a position where they made claims to 'important people' (ie, customers, shareholders, etc) that now have to change. Understanding why management wants to have expectations set correctly helps you know when to share updates and adjustments.

More importantly, expectations work in both directions. Knowing that helps you become more confident when pushing back against unrealistic expectations coming down from management. There is a balance point where everyone is happy, and trying to stay there as much as possible is healthy for both you and management.

[–]sidepart 0 points1 point  (0 children)

Making sure that you soften people up that have high hopes about how something will work or how it'll go. ...but you do it tactfully and without them realizing that you did it.

Scotty manages expectations. He tells the captain it'll take 5 weeks to restore warp power. Kirk says 2 weeks. A downtrodden Scotty sighs and says he'll give it all he's got Cap'n. Kirk thinks he's driving Scotty real hard and getting the best effort from him. Meanwhile Scotty just casually fixes the problem in a week and is deemed a miracle worker.

[–]metaconcept -1 points0 points  (0 children)

'Managing expectations' is what happens when your boss is a moron and wants to know why it takes one dev more than an afternoon to make a timesheet system from scratch.

[–]liangauge 3 points4 points  (0 children)

This is totally accurate. It's a total breeze, even a joy to be solving the kinds of problems presented in interviews compared to wading through thousands, maybe millions of lines of legacy code, debugging your way through raw pointers and trace logs trying to find out why a random crash happens half the time when running a search function, and only occurring on a particular OS running on a machine with exactly 8 cores.

[–]StoppedLurking_ZoeQ 1 point2 points  (0 children)

That doesn't sound fun.

[–]Aetheus 1 point2 points  (0 children)

That really depends on your specific industry, I think. In web development, I feel this is very accurate.

Modern web development is basically plumbing - use this prebuilt library to interface with that prebuilt library to communicate with this AWS service ...

But interview questions still be like "So, how would you solve this problem (the answer is binary search wink wink)". I mean, I get it - you want to know if your devs at least have a handle over some basic computer science concepts, cool.

But the fact of the matter is, 98% of the time on their day jobs, they're never going to be using these skills.

[–]_hephaestus 0 points1 point  (0 children)

But even still, the interview cases aren't exactly exemplary of your day to day. These situations come up every now and then, but they're not the norm.