Started new job like a month ago. Finally doing actual dev work and feel like I'm drowning. How did onboarding work for y'all and is drowning normal? This is for a mid level position mind.
psn: PhasenWeeple
0
Options
OrcaAlso known as EspressosaurusWrexRegistered Userregular
Started new job like a month ago. Finally doing actual dev work and feel like I'm drowning. How did onboarding work for y'all and is drowning normal? This is for a mid level position mind.
Drowning is pretty normal for the first 3-6 months in my experience. You don't get really productivity positive until the 6-9 month time frame, and actually effective around a year or thereabouts.
At least, based on my own experiences and observing new people get brought up.
YMMV depending on the complexity of what you're doing and how much what you've done in the past translates over.
+7
Options
gavindelThe reason all your softwareis brokenRegistered Userregular
Started new job like a month ago. Finally doing actual dev work and feel like I'm drowning. How did onboarding work for y'all and is drowning normal? This is for a mid level position mind.
I hate to say it, but structured training and ramp-up is basically nonexistent in tech. Throw you into the pool, check in a year to see if you have a clue.
A year to really understand the system is normal. 18 months if you're a new engineer to take off the training wheels. 2 years is when I start getting worried.
I appreciate the responses. Really feeling like an imposter, even with the lead giving me compliments about my coding style. Adapting to a Sprint style and feeling like I'm really behind due to missing timelines.
gavindelThe reason all your softwareis brokenRegistered Userregular
And the floor isn't "I struggle with some concepts."
The floor is "I so badly can't comprehend coding that I try to get others to do my work, break everything I touch, and intentionally lie about it all to string along the team for literally months."
I appreciate the responses. Really feeling like an imposter, even with the lead giving me compliments about my coding style. Adapting to a Sprint style and feeling like I'm really behind due to missing timelines.
Quick rule - take whatever time estimate you have, double it and say that as the estimate.
Once you start finishing early, drop it to 1.5.
+6
Options
OrcaAlso known as EspressosaurusWrexRegistered Userregular
I appreciate the responses. Really feeling like an imposter, even with the lead giving me compliments about my coding style. Adapting to a Sprint style and feeling like I'm really behind due to missing timelines.
Quick rule - take whatever time estimate you have, double it and say that as the estimate.
Once you start finishing early, drop it to 1.5.
Double it and increase the time increment if it's hardware
I appreciate the responses. Really feeling like an imposter, even with the lead giving me compliments about my coding style. Adapting to a Sprint style and feeling like I'm really behind due to missing timelines.
Quick rule - take whatever time estimate you have, double it and say that as the estimate.
Once you start finishing early, drop it to 1.5.
And remember, it's not writ in stone. Said 5, took 3? Cool beans, adjust it, and now you know. Same with "whoa, we lowballed that, more like a sprint and a half..."; just break it up; adjust points, and now you can do better next time.
Properly (even mostly properly) run, agile/pointing is just a tool to let you and your product team plan on a longer scale and enable communication around the org. The exact numbers don't matter so much as "consistency" and "things get done".
That said, if you ever see management going "team X did 30 points but you only did 28! This is a problem!", run like fuck. That is so not how it works, and is a bad enough indicator that I wouldn't want to wait for any others.
+5
Options
admanbunionize your workplaceSeattle, WARegistered Userregular
Tracking points sprint-to-sprint is valuable but only internal to a team. "We completed 30 points last sprint but only 20 this sprint -- what happened?" Often it'll be something really obvious, but you want to have that conversation before deciding if you're committing to 20 or 30 points for the next sprint.
you know you're deep deep in the networking hell mines when it's 8:40pm and you're ecstatic to get a 403 forbidden instead of just a timeout
life's a game that you're bound to lose / like using a hammer to pound in screws
fuck up once and you break your thumb / if you're happy at all then you're god damn dumb
that's right we're on a fucked up cruise / God is dead but at least we have booze
bad things happen, no one knows why / the sun burns out and everyone dies
Tracking points sprint-to-sprint is valuable but only internal to a team. "We completed 30 points last sprint but only 20 this sprint -- what happened?" Often it'll be something really obvious, but you want to have that conversation before deciding if you're committing to 20 or 30 points for the next sprint.
Yup. The numbers as units are only useful internally. That, plus "the numbers don't mean days" are like, the most difficult things I've seen people run into.
Tracking points sprint-to-sprint is valuable but only internal to a team. "We completed 30 points last sprint but only 20 this sprint -- what happened?" Often it'll be something really obvious, but you want to have that conversation before deciding if you're committing to 20 or 30 points for the next sprint.
Yup. The numbers as units are only useful internally. That, plus "the numbers don't mean days" are like, the most difficult things I've seen people run into.
"3 what?" "Just 3." "But 3 WHAT?"
At EchoCorp (edit: as in my team) we stopped doing estimates completely, nor use any form of points, because even though they're explicitly intended to not be used as time estimates, because that's why people use points in the first place, they always end up somehow being turned into time estimates when people ask "when is X ready?".
Tracking points sprint-to-sprint is valuable but only internal to a team. "We completed 30 points last sprint but only 20 this sprint -- what happened?" Often it'll be something really obvious, but you want to have that conversation before deciding if you're committing to 20 or 30 points for the next sprint.
Yup. The numbers as units are only useful internally. That, plus "the numbers don't mean days" are like, the most difficult things I've seen people run into.
"3 what?" "Just 3." "But 3 WHAT?"
At EchoCorp (edit: as in my team) we stopped doing estimates completely, nor use any form of points, because even though they're explicitly intended to not be used as time estimates, because that's why people use points in the first place, they always end up somehow being turned into time estimates when people ask "when is X ready?".
Weirdly, that's like the one problem we haven't had. Everyone (Like, org-wide) at some point picked up speaking in terms of "sprints" and only sprints when talking to other teams. All it is is sprints, hard dates (that are end of sprints usually) and t-shirt sizes passed around.
In case anyone was wondering, no this does not prevent absolutely spectacular goat rodeos on various scales.
Yep, eventually points go by the wayside once a team matures enough. Also correct in other spaces that points!=time estimates and points/person is meaningless (as 1 point is usually the floor, so if you're creative, you can turn a 3 point story into about 10 points of 1 pointers).
0
Options
JacobyOHHHHH IT’S A SNAKECreature - SnakeRegistered Userregular
edited November 2021
Hey Axure, I appreciate what you're bringing to the table for my HCI course work.
But if I had one tiny suggestion...
When I say a radio button is disabled,
maybe actually make it disabled?
Like make it so you can't select it?
Certainly don't make it enabled in the running prototype for some reason?
Do more than just give it the disabled style?
That would be fucking great...
(I've got it working in a hacky way with Click interactions, but the time and energy I spent on it... :x )
Jacoby on
GameCenter: ROldford
Switch: nin.codes/roldford
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
Tracking points sprint-to-sprint is valuable but only internal to a team. "We completed 30 points last sprint but only 20 this sprint -- what happened?" Often it'll be something really obvious, but you want to have that conversation before deciding if you're committing to 20 or 30 points for the next sprint.
It's also only useful once your team has a lot of experience estimating and has setup good working agreements on how they estimate. Without estimation consistency tracking velocity is pointless. The less cohesive and experienced your team is the less velocity means.
Thankfully I work at a company with a CTO who Gandalf staff's anyone outside of engineering trying to turn points in to time estimates. Once we've scoped a project we'll give the business an estimate on when we think we can realistically deliver. We've gotten pretty good at hitting those delivery points, within a sprint either way generally, so we've earned the trust to work that way.
I appreciate the responses. Really feeling like an imposter, even with the lead giving me compliments about my coding style. Adapting to a Sprint style and feeling like I'm really behind due to missing timelines.
At my last company, both front-end and back-end codebases were all done in the functional style with long chained functions/methods (fluent API) and it took me quite some time to finally get my head around all of it. Not only that, but on the back-end side, it was all on top of a custom system where you would build up "tasks" which would be executed lazily (executed at a later time). I had no clue how to setup a simple if/else structure with the styles they were using. I had never been exposed to or done anything with these styles before, so I was feeling quite stressed, so I hear ya.
Re: points and estimates, the worst is when management is saying "you put X value for this estimate, but it's taking longer". Yeah, that's because it's an ESTIMATE and you course correct next time...yeesh. I guess that's them trying to turn any number into a concrete time estimate.
Re: points and estimates, the worst is when management is saying "you put X value for this estimate, but it's taking longer". Yeah, that's because it's an ESTIMATE and you course correct next time...yeesh. I guess that's them trying to turn any number into a concrete time estimate.
Ditto re: people that don't quite get "iterating".
"You've released New Thing but Feature X isn't in yet! You said you'd do it!"
Yes, but not in the first iteration.
+2
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited November 2021
re: Imposter syndrome. It's absolutely a real thing. Every promotion I've gotten in my career, especially ones with big title steps and more responsibility, have caused me to feel it. I've always attributed it to the fact that my head is full of all of life's memories, and I remember all the times I would have been an imposter for whatever reason. Even though at the time I'm getting the promotion I've earned it via my more recent performance and experience. The people promoting me don't remember when I was green and inexperienced, or when I was still learning how to be an actual professional.
re: Imposter syndrome. It's absolutely a real thing. Every promotion I've gotten in my career, especially ones with big title steps and more responsibility, have caused me to feel it. I've always attributed it to the fact that my head is full of all of life's memories, and I remember all the times I would have been an imposter for whatever reason. Even though at the time I'm getting the promotion I've earned it via my more recent performance and experience. The people promoting me don't remember when I was green and inexperienced, or when I was still learning how to be an actual professional.
I'm stealing that definition, or outlook, or philosophy, or whatever you'd call it.
Started new job like a month ago. Finally doing actual dev work and feel like I'm drowning. How did onboarding work for y'all and is drowning normal? This is for a mid level position mind.
I hate to say it, but structured training and ramp-up is basically nonexistent in tech. Throw you into the pool, check in a year to see if you have a clue.
A year to really understand the system is normal. 18 months if you're a new engineer to take off the training wheels. 2 years is when I start getting worried.
This drives me nuts. I've done some job hopping the last couple of years, and it always surprises me how little actual onboarding and training most places do. I got spoiled by one job I had that had an initial month of training, most places after that it's been nothing. I can't believe I'm the only one to think that actually training new people on your system, infrastructure, internal patterns and traditions, etc., is actually worth anything.
I think some companies just don't realize how much things can vary from place to place, and think that their way is the obvious way, and why would you do it differently??
+1
Options
Monkey Ball WarriorA collection of mediocre hatsSeattle, WARegistered Userregular
edited November 2021
I have to get a new SDE job. I've been unemployed since April, up until very recently by choice. I was burned out. I probably should have took a long break years ago.
There's been a lot of deaths in my family this year (not covid but still) so it has been very good to have no commitments and infinite free time to go to funerals and process things.
But my savings are draining fast, and frankly I'm just getting bored. This has taught me that someday when I retire I should expect to just become self employed. You can only sit around and play video games and read books for so long.
I had actually applied for a single job recently, got through the initial interview process, got to technical interview and proceeded to faceplant because I'm super rusty and I haven't had to think about the entire genre of interview puzzles in over 7 years.
Even though I think the entire thing is ridiculous, it's a hoop I need to jump through, so I just need to sit down and practice this stuff again. Weeee.
Monkey Ball Warrior on
"I resent the entire notion of a body as an ante and then raise you a generalized dissatisfaction with physicality itself" -- Tycho
Going to attempt Advent of Code this year while employed. Made it to Day 17 or 18 while unemployed before stopping. Definitely going to be interesting as I may not have the will power or head space to continue each and every day.
Going to attempt Advent of Code this year while employed. Made it to Day 17 or 18 while unemployed before stopping. Definitely going to be interesting as I may not have the will power or head space to continue each and every day.
I believe I got halfway through... Day one last year, before my brain revolted, and demanded a pickling.
I'd pretend otherwise for this year, but I know me.
This job search I finally started to get pushback on the number of contract positions I've taken, especially the shorter ones. I really want to go FTE and be a real boy with domain knowledge and all that. So I have three offers in hand right now: 135k FTE with good benefits, 140k FTE with almost as good benefits... and 180k contract. By Friday I have to decide if I give up stability for another ~20k/yr. There are much worse problems to have, but I've never actually had multiple offers before and analysis paralysis is for reals.
0
Options
OrcaAlso known as EspressosaurusWrexRegistered Userregular
Disclaimer: I have only ever worked as an FTE.
My personal breakpoint is at 2x FTE pay to account for risk, lack of benefits, time off, etc. 20K take home isn’t nearly enough for my (low) risk tolerance.
What’s your risk tolerance? How much are those benefits worth? How much is that time off worth?
If you are american and this means self-employed contract work, the increased tax burden ( social security corp side ) , having to cover medical, dental, etc makes the FTE offer better
Go FTE.
Ethea on
+5
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited December 2021
I agree with Orca's double pay for a contract rule. That's how important some level of security + benefits is to me. It shouldn't be your only decision point, but all other things being equal I'd take the 135 w/ good bene's. Especially to get yourself setup and in to the FTE world. Once you've got a good solid 2+ year full-time job under your belt you'll be able to be picky and only accept FTE opportunities no problem.
Also do not be afraid to go to the 135 company and ask for 140. No one is going to be offended by that and the worst they say is 'no'. I've never heard of an offer rescinded because someone asked for a little more cheese.
Oh, it's W2 contract - agency work. So tax situation is the same, there's benefits but they're not great, and the gig has an expiration date.
What's the price difference on the benefits? Do the benefit differences matter to you?
Like if the 180k's benefits are missing like "free dental coverage" fuck off you can pay to have all your teeth pulled and upgraded with mammoth ivory at that price difference.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Oh, it's W2 contract - agency work. So tax situation is the same, there's benefits but they're not great, and the gig has an expiration date.
What's the price difference on the benefits? Do the benefit differences matter to you?
Like if the 180k's benefits are missing like "free dental coverage" fuck off you can pay to have all your teeth pulled and upgraded with mammoth ivory at that price difference.
Hard disagree. 180 vs 135 is a hit, but it is absolutely worth 45k/year to not be "the most expendable person in the building", not counting benefits/etc.
Also, short-term high dollar contracts always make me smell "temporary" and "someone is getting screwed", and that person is probably eventually you. Figure how much the agency has to be getting to give you that much... And what's the money on a no-poaching clause in their vendor contract?
Edit: In fairness, I've had some really good experiences as a long term vendor. You're still expendable, and it's still only marginally stable if that, and at this point I don't go for unstable unless it's one absolute hell of a truck of money.
Quick napkin math put the benefits difference at about 20k. I'm currently covering my own medical at about 6k/yr, both only match 401k up to 3%, and the rest of the odds and ends aren't anything wonderful. I think it's going to come down to time off - I haven't had any that wasn't an employment gap for five years now. I wanna go somewhere sunny.
Posts
Drowning is pretty normal for the first 3-6 months in my experience. You don't get really productivity positive until the 6-9 month time frame, and actually effective around a year or thereabouts.
At least, based on my own experiences and observing new people get brought up.
YMMV depending on the complexity of what you're doing and how much what you've done in the past translates over.
I hate to say it, but structured training and ramp-up is basically nonexistent in tech. Throw you into the pool, check in a year to see if you have a clue.
A year to really understand the system is normal. 18 months if you're a new engineer to take off the training wheels. 2 years is when I start getting worried.
The floor is "I so badly can't comprehend coding that I try to get others to do my work, break everything I touch, and intentionally lie about it all to string along the team for literally months."
Quick rule - take whatever time estimate you have, double it and say that as the estimate.
Once you start finishing early, drop it to 1.5.
Double it and increase the time increment if it's hardware
"It'll take a week" -> it'll take two months
I'm joking...or am I?
Nobody can properly time box a 1 year task, and given feature creep a decade is more likely.
And remember, it's not writ in stone. Said 5, took 3? Cool beans, adjust it, and now you know. Same with "whoa, we lowballed that, more like a sprint and a half..."; just break it up; adjust points, and now you can do better next time.
Properly (even mostly properly) run, agile/pointing is just a tool to let you and your product team plan on a longer scale and enable communication around the org. The exact numbers don't matter so much as "consistency" and "things get done".
That said, if you ever see management going "team X did 30 points but you only did 28! This is a problem!", run like fuck. That is so not how it works, and is a bad enough indicator that I wouldn't want to wait for any others.
fuck up once and you break your thumb / if you're happy at all then you're god damn dumb
that's right we're on a fucked up cruise / God is dead but at least we have booze
bad things happen, no one knows why / the sun burns out and everyone dies
Yup. The numbers as units are only useful internally. That, plus "the numbers don't mean days" are like, the most difficult things I've seen people run into.
"3 what?" "Just 3." "But 3 WHAT?"
At EchoCorp (edit: as in my team) we stopped doing estimates completely, nor use any form of points, because even though they're explicitly intended to not be used as time estimates, because that's why people use points in the first place, they always end up somehow being turned into time estimates when people ask "when is X ready?".
Weirdly, that's like the one problem we haven't had. Everyone (Like, org-wide) at some point picked up speaking in terms of "sprints" and only sprints when talking to other teams. All it is is sprints, hard dates (that are end of sprints usually) and t-shirt sizes passed around.
In case anyone was wondering, no this does not prevent absolutely spectacular goat rodeos on various scales.
But if I had one tiny suggestion...
When I say a radio button is disabled,
maybe actually make it disabled?
Like make it so you can't select it?
Certainly don't make it enabled in the running prototype for some reason?
Do more than just give it the disabled style?
That would be fucking great...
(I've got it working in a hacky way with Click interactions, but the time and energy I spent on it... :x )
Switch: nin.codes/roldford
It's also only useful once your team has a lot of experience estimating and has setup good working agreements on how they estimate. Without estimation consistency tracking velocity is pointless. The less cohesive and experienced your team is the less velocity means.
Thankfully I work at a company with a CTO who Gandalf staff's anyone outside of engineering trying to turn points in to time estimates. Once we've scoped a project we'll give the business an estimate on when we think we can realistically deliver. We've gotten pretty good at hitting those delivery points, within a sprint either way generally, so we've earned the trust to work that way.
At my last company, both front-end and back-end codebases were all done in the functional style with long chained functions/methods (fluent API) and it took me quite some time to finally get my head around all of it. Not only that, but on the back-end side, it was all on top of a custom system where you would build up "tasks" which would be executed lazily (executed at a later time). I had no clue how to setup a simple if/else structure with the styles they were using. I had never been exposed to or done anything with these styles before, so I was feeling quite stressed, so I hear ya.
Re: points and estimates, the worst is when management is saying "you put X value for this estimate, but it's taking longer". Yeah, that's because it's an ESTIMATE and you course correct next time...yeesh. I guess that's them trying to turn any number into a concrete time estimate.
Ditto re: people that don't quite get "iterating".
"You've released New Thing but Feature X isn't in yet! You said you'd do it!"
Yes, but not in the first iteration.
I'm stealing that definition, or outlook, or philosophy, or whatever you'd call it.
This drives me nuts. I've done some job hopping the last couple of years, and it always surprises me how little actual onboarding and training most places do. I got spoiled by one job I had that had an initial month of training, most places after that it's been nothing. I can't believe I'm the only one to think that actually training new people on your system, infrastructure, internal patterns and traditions, etc., is actually worth anything.
I think some companies just don't realize how much things can vary from place to place, and think that their way is the obvious way, and why would you do it differently??
There's been a lot of deaths in my family this year (not covid but still) so it has been very good to have no commitments and infinite free time to go to funerals and process things.
But my savings are draining fast, and frankly I'm just getting bored. This has taught me that someday when I retire I should expect to just become self employed. You can only sit around and play video games and read books for so long.
I had actually applied for a single job recently, got through the initial interview process, got to technical interview and proceeded to faceplant because I'm super rusty and I haven't had to think about the entire genre of interview puzzles in over 7 years.
Even though I think the entire thing is ridiculous, it's a hoop I need to jump through, so I just need to sit down and practice this stuff again. Weeee.
I believe I got halfway through... Day one last year, before my brain revolted, and demanded a pickling.
I'd pretend otherwise for this year, but I know me.
Look, I didn't spend last week farming this Paladin glamour for nothing.
My personal breakpoint is at 2x FTE pay to account for risk, lack of benefits, time off, etc. 20K take home isn’t nearly enough for my (low) risk tolerance.
What’s your risk tolerance? How much are those benefits worth? How much is that time off worth?
Go FTE.
Also do not be afraid to go to the 135 company and ask for 140. No one is going to be offended by that and the worst they say is 'no'. I've never heard of an offer rescinded because someone asked for a little more cheese.
What's the price difference on the benefits? Do the benefit differences matter to you?
Like if the 180k's benefits are missing like "free dental coverage" fuck off you can pay to have all your teeth pulled and upgraded with mammoth ivory at that price difference.
Hard disagree. 180 vs 135 is a hit, but it is absolutely worth 45k/year to not be "the most expendable person in the building", not counting benefits/etc.
Also, short-term high dollar contracts always make me smell "temporary" and "someone is getting screwed", and that person is probably eventually you. Figure how much the agency has to be getting to give you that much... And what's the money on a no-poaching clause in their vendor contract?
Edit: In fairness, I've had some really good experiences as a long term vendor. You're still expendable, and it's still only marginally stable if that, and at this point I don't go for unstable unless it's one absolute hell of a truck of money.