As was foretold, we've added advertisements to the forums! If you have questions, or if you encounter any bugs, please visit this thread: https://forums.penny-arcade.com/discussion/240191/forum-advertisement-faq-and-reports-thread/

[Programming] Page overflow to new thread

1727374757678»

Posts

  • dporowskidporowski Registered User regular
    If you have an iPad/Apple stuff, the Playgrounds app is pretty good, too.

  • LD50LD50 Registered User regular
    Thanks a bunch!

  • PhasenPhasen Hell WorldRegistered User regular
    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
  • OrcaOrca Registered User regular
    Phasen wrote: »
    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.

    EtheaCampyadmanbgavindeldurandal4532GnomeTankkime
  • gavindelgavindel The reason all your software is brokenRegistered User regular
    Phasen wrote: »
    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've got a book! Angels, innovations, and the hubris of tiny things: Seraphim
    SageinaRage
  • PhasenPhasen Hell WorldRegistered User regular
    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.

    psn: PhasenWeeple
  • PhyphorPhyphor Building Planet Busters Tasting FruitRegistered User regular
    That's our secret, we're all imposters

    thatassemblyguygavindelPhasenOrcaEtheaNaphtaliIzzimachSporkAndrewzagdrobiTunesIsEvildurandal4532InfidelGnomeTankironsizidesyndalisMonkey Ball Warriorkime
  • gavindelgavindel The reason all your software is brokenRegistered User regular
    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've got a book! Angels, innovations, and the hubris of tiny things: Seraphim
    FremthatassemblyguyLD50zagdrobiTunesIsEvilInfidel
  • schussschuss Registered User regular
    Phasen wrote: »
    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.

    SpoitNaphtalidporowskiFremzagdrobGnomeTank
  • OrcaOrca Registered User regular
    schuss wrote: »
    Phasen wrote: »
    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

    "It'll take a week" -> it'll take two months



    I'm joking...or am I?

  • EtheaEthea Registered User regular
    Once your estimates are measured in months or years. Double and increment is super true.

    Nobody can properly time box a 1 year task, and given feature creep a decade is more likely.

    schuss
  • dporowskidporowski Registered User regular
    schuss wrote: »
    Phasen wrote: »
    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.

    FremschussInfidelGnomeTankMvrck
  • admanbadmanb unionize your workplace Seattle, WARegistered User regular
    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.

    dporowskiGnomeTank
  • AiouaAioua Ora Occidens Ora OptimaRegistered User regular
    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
    admanbgavindel
  • dporowskidporowski Registered User regular
    edited November 23
    admanb wrote: »
    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?"

    dporowski on
    admanbthatassemblyguy
  • EchoEcho ski-bap ba-dapModerator mod
    edited November 23
    dporowski wrote: »
    admanb wrote: »
    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?".

    Echo on
    thatassemblyguy
  • dporowskidporowski Registered User regular
    Echo wrote: »
    dporowski wrote: »
    admanb wrote: »
    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.

    schuss
  • schussschuss Registered User regular
    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).

  • JacobyJacoby Registered User regular
    edited November 23
    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
  • GnomeTankGnomeTank Registered User regular
    edited November 24
    admanb wrote: »
    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.

    GnomeTank on
    Sagroth wrote: »
    Oh c'mon FyreWulff, no one's gonna pay to visit Uranus.
    Steam: Brainling, XBL / PSN: GnomeTank, NintendoID: Brainling, FF14: Zillius Rosh SFV: Brainling
    admanbEar3nd1l
  • TelMarineTelMarine Registered User regular
    Phasen wrote: »
    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.

    3ds: 4983-4935-4575
    Echothatassemblyguy
  • EchoEcho ski-bap ba-dapModerator mod
    TelMarine wrote: »
    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.

    thatassemblyguyGnomeTank
  • GnomeTankGnomeTank Registered User regular
    edited November 27
    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.

    GnomeTank on
    Sagroth wrote: »
    Oh c'mon FyreWulff, no one's gonna pay to visit Uranus.
    Steam: Brainling, XBL / PSN: GnomeTank, NintendoID: Brainling, FF14: Zillius Rosh SFV: Brainling
    Echo
  • EchoEcho ski-bap ba-dapModerator mod
    GnomeTank wrote: »
    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.

  • SageinaRageSageinaRage Registered User regular
    gavindel wrote: »
    Phasen wrote: »
    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??

    sig.gif
    Naphtali
  • Monkey Ball WarriorMonkey Ball Warrior A collection of mediocre hats Seattle, WARegistered User regular
    edited 1:32AM
    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 at
    "I resent the entire notion of a body as an ante and then raise you a generalized dissatisfaction with physicality itself" -- Tycho
    admanbOrcaEar3nd1l
Sign In or Register to comment.