5 ms·

I've always felt that in the various jobs I've held the degree to which I could "get under the hood" was determined by people higher up the chain of command tha

I've always felt that in the various jobs I've held the degree to which I could "get under the hood" was determined by people higher up the chain of command than me. Run into a complex bug in library X? Well, we don't want you spending a week to debug it, write a patch and try to upstream it. Work around it for now instead. Or we'll defer that feature since we don't want you to spend that much time on "non-company" projects. Etc. I think this is usually all the more true when your employer expects you to be a generalist of some kind and I've become a bit jealous of people whose employers let them really dig into things and even deviate to ecosystem projects instead of focusing on keeping the internal hamster wheel spinning. On another tangent, one thing I found very frustrating early in my career and which I still feel is problematic in our field is that there's kind of a double standard when it comes to approaching things "under the hood." At my first job I'd always ask my supervisor when when things lead there and then get told not to go there (despite wanting to) while a coworker of similar experience hired at around the same time would constantly get everything done behind schedule because he just did the things under the hood I made the mistake of asking about, but he'd get applauded for it continually. (Perhaps I learned from this, but it was pretty frustrating and disheartening at the time.)

strickjb9 11y ago
I can relate to your last paragraph. I used to (and still) source dive to find good workarounds to library issues. But I never asked for permission, I just did it. I also delivered on time. Nowadays, I'm a team lead and I am guilty of telling people "not to go there" (about half the time). It's funny because it actually conflicts with my opinion that I want people to dig in! The choice to "dig in" is a personal risk/reward. It's a risk that an engineer must take while practicing good time management. Asking your manager is akin to making them take that risk for you (the risk of wasted time, passing deadlines, etc). My crappy advice is... ask for forgiveness, not for permission. If you're a good engineer, you'll come out on top!
- Glyptodon 11y ago
  I don't disagree with you, but I also think there are situations where (particularly if you aren't privy to the big picture) it's a good idea to have some kind of sounding board to run things off of before diving/jumping in, though that may be a bit tangential to the point at hand. Maybe more to the point, I don't think my behavior at the time was an attempt at pushing the risk up the chain as much as it was a manifestation of fear/anxiety that I'd somehow be outside of company expectations/norms or would end up spending a bunch of time working around/fixing something that had already been solved in a way that I, as a newer employee, just didn't know about.

strickjb9 11y ago

I can relate to your last paragraph. I used to (and still) source dive to find good workarounds to library issues. But I never asked for permission, I just did it. I also delivered on time. Nowadays, I'm a team lead and I am guilty of telling people "not to go there" (about half the time). It's funny because it actually conflicts with my opinion that I want people to dig in! The choice to "dig in" is a personal risk/reward. It's a risk that an engineer must take while practicing good time management. Asking your manager is akin to making them take that risk for you (the risk of wasted time, passing deadlines, etc). My crappy advice is... ask for forgiveness, not for permission. If you're a good engineer, you'll come out on top!

Glyptodon 11y ago
I don't disagree with you, but I also think there are situations where (particularly if you aren't privy to the big picture) it's a good idea to have some kind of sounding board to run things off of before diving/jumping in, though that may be a bit tangential to the point at hand. Maybe more to the point, I don't think my behavior at the time was an attempt at pushing the risk up the chain as much as it was a manifestation of fear/anxiety that I'd somehow be outside of company expectations/norms or would end up spending a bunch of time working around/fixing something that had already been solved in a way that I, as a newer employee, just didn't know about.