3 ms·

I work for a non tech fortune 500 company and was committing code by day 2. It's really about being willing to figure out what the blocker's to access are and m

by jrott 6y ago

I work for a non tech fortune 500 company and was committing code by day 2. It's really about being willing to figure out what the blocker's to access are and making sure they are taken care of before hand.

phist_mcgee 6y ago
I've heard this a few time about submitting your first PR within one or two days at a company. It's cool and all for you to get code out there, and if you've got good CD it probably won't screw anything up, but I know my stack at work. I know there are nuances, and deliberate details, and designs, and prioritize and a million other things. How can a person be expected to write a bug fix and truly understand what is happening, when they may not even yet full understand the product yet?
- lmm 6y ago
  If you're working at these big companies then working in a codebase you don't fully understand will just be a fact of life. I worked at a Fortune 500 company for 4 years, but of course I didn't understand even half of the million-line Scala codebase I was working on by the time I left. The way you make people productive in that environment is you have, and enforce, good coding and design standards so that code will do what you expect and you can rely on parts of the codebase that you don't necessarily understand the internals of. Frankly, having to consider "nuances, and deliberate details, and designs, and prioritize and a million other things" is not a good use of people's mental capacity, and you should aim not to have a codebase where people have to do that. Write your codebase like a tower of libraries/DSLs, where each layer presents a solid abstraction to the layer above it, and the topmost layer is just the business logic written in the language of the domain; then it's easy to make a simple change to that business logic because you just have to make the same simple change to your code.
- MarkSweep 6y ago
  At my old job I maintained a list of “up for grabs” tickets. They were all very narrowly scoped, so little judgement would be needed. Things like “the text on this button is misspelled” or “add an extra button to the GUI to expose this existing functionality”. These sort of bugs are good “first week” bugs since most of what you learning is setting up the development environment and interacting with engineering systems (bug tracker, code repo, CI/CD).
sudeepj 6y ago
Good for you! (not being sarcastic) Culture plays a huge role as well. I have seen the environments where existing folks are un-willing to help out new guy. This could be due to lack of time, getting territorial, just-being-jerk, lots of attrition, etc. The best way to get started is to start writing tests for the team and work your way up. I find this useful for all levels of hire.
- jrott 6y ago
  Absolutely. It's totally a cultural thing I've been in the opposite situation as well. The culture really has to be that getting someone new onboarded is the most important thing and not somebodies side project.

by jrott 6y ago

phist_mcgee 6y ago

I've heard this a few time about submitting your first PR within one or two days at a company. It's cool and all for you to get code out there, and if you've got good CD it probably won't screw anything up, but I know my stack at work. I know there are nuances, and deliberate details, and designs, and prioritize and a million other things. How can a person be expected to write a bug fix and truly understand what is happening, when they may not even yet full understand the product yet?

lmm 6y ago
If you're working at these big companies then working in a codebase you don't fully understand will just be a fact of life. I worked at a Fortune 500 company for 4 years, but of course I didn't understand even half of the million-line Scala codebase I was working on by the time I left. The way you make people productive in that environment is you have, and enforce, good coding and design standards so that code will do what you expect and you can rely on parts of the codebase that you don't necessarily understand the internals of. Frankly, having to consider "nuances, and deliberate details, and designs, and prioritize and a million other things" is not a good use of people's mental capacity, and you should aim not to have a codebase where people have to do that. Write your codebase like a tower of libraries/DSLs, where each layer presents a solid abstraction to the layer above it, and the topmost layer is just the business logic written in the language of the domain; then it's easy to make a simple change to that business logic because you just have to make the same simple change to your code.
MarkSweep 6y ago
At my old job I maintained a list of “up for grabs” tickets. They were all very narrowly scoped, so little judgement would be needed. Things like “the text on this button is misspelled” or “add an extra button to the GUI to expose this existing functionality”. These sort of bugs are good “first week” bugs since most of what you learning is setting up the development environment and interacting with engineering systems (bug tracker, code repo, CI/CD).

sudeepj 6y ago

Good for you! (not being sarcastic) Culture plays a huge role as well. I have seen the environments where existing folks are un-willing to help out new guy. This could be due to lack of time, getting territorial, just-being-jerk, lots of attrition, etc. The best way to get started is to start writing tests for the team and work your way up. I find this useful for all levels of hire.

jrott 6y ago
Absolutely. It's totally a cultural thing I've been in the opposite situation as well. The culture really has to be that getting someone new onboarded is the most important thing and not somebodies side project.