7 ms·

This seems like good advice, but is presented poorly. You're meeting expectations, which is great, but don't stop there. You recognize that you (and your teamm

This seems like good advice, but is presented poorly. You're meeting expectations, which is great, but don't stop there. You recognize that you (and your teammates) could be doing more, so make it happen. You're entirely capable and empowered to do so: - Fix that technical debt. - Identify better tooling and demonstrate it's value to your teammates. - Proactively find things your software could do better and write about them. Don't be discouraged if people don't bite on the first few, you'll find one eventually that's too good to not pursue. Sure, you could accept the status quo and coast like some of your teammates, but you'll be unhappy (and bored). Do what makes you happy -- identify, evangelize, prototype and build. All of this doesn't mean you're lazy for having posted this -- just that you need encouragement to make the things happen that'll make you happier and more fulfilled at the end of the day.

skrtskrt 6y ago
This is good... only IF he can actually get to work on this stuff without being stomped on and blocked from every corner of the organization.
- mkoubaa 6y ago
  None of the FAANGs block personal projects from staff who are productive enough in their primary responsibility
  - skrtskrt 6y ago
    What if the "personal" project is like "introduce this new tooling to the team, get it integrated into our CI pipeline"? Anything that introduces new technology or has the potential to require some time from other teams (Devops, SRE) I can see running into organizational roadblocks in the final stages of the project, even if the individual is free to start the experimentation and justification steps them on their own.
    - nuclear_eclipse 6y ago
      If they're willing to do the integration and support work on their own, then it shouldn't be a roadblock, and they should be able to prove the impact that it offers to other engineers and be rewarded if they did all of the work.
    - codeviking 6y ago
      I think you're referring to "gatekeeping." If the employee, for instance, proactively fixes a bug or resolves some technical debt, it's possible another team member might try to prevent it from being merged. Their reasons might seem non-objective and rooted more in the fact that they weren't involved in the change, or involved in the decision to make the change. I've ran into this. It's easy to be discouraged and, in the event this occurs, stop trying. That said I think this is the wrong thing to do. Instead I view this type of scenario as a chance to convince my teammate of the value I'm adding and the rationale behind the change being made without being explicitly planned. It's hard work, and sometimes involves some long, strained conversations with your team mates. That said at the end of the day you just might encourage that individual to proactively solve these types of problems. This will probably make that person happier as well, and unlock additional productivity for your team. The hardest part of software is the people part :)
walshemj 6y ago
The OP is of course the new guy/gal so your not going to being doing major things from day 1.
- codeviking 6y ago
  Being new doesn't mean you can't try to do things. If the OP takes that perspective then they're just limiting their own potential. Code is code, and can be changed. There's this weird inhibition in our industry to just trying things. Senior or not, there's no harm in opening a PR. If there's a clear reason for not applying a change it's just a learning exercise. The PR can be closed without any negative impact. Who knows, maybe discussing the PR will be teach the senior contributor something. I can't tell you how many times I've realized a prior constraint is no longer valid via a discussion o'er a PR. I end up informed, the new contributor ends up empowered and the code base lands in a better state -- win, win and win! IMO these types of changes and the resulting discussions are healthy and absolutely crucial to the longevity of a successful piece of software.
  - walshemj 6y ago
    Just opening a PR ? some time you have to step a way from a laser focus on JIRA and GitHub. As a newbie at a FANG its going to take at least 9 months to a year to get that familiar with such a large code base. And most of being a developer is not KLOC's or its modern eqvielent Fuature Points

skrtskrt 6y ago

This is good... only IF he can actually get to work on this stuff without being stomped on and blocked from every corner of the organization.

mkoubaa 6y ago
None of the FAANGs block personal projects from staff who are productive enough in their primary responsibility
- skrtskrt 6y ago
  What if the "personal" project is like "introduce this new tooling to the team, get it integrated into our CI pipeline"? Anything that introduces new technology or has the potential to require some time from other teams (Devops, SRE) I can see running into organizational roadblocks in the final stages of the project, even if the individual is free to start the experimentation and justification steps them on their own.
  - nuclear_eclipse 6y ago
    If they're willing to do the integration and support work on their own, then it shouldn't be a roadblock, and they should be able to prove the impact that it offers to other engineers and be rewarded if they did all of the work.
  - codeviking 6y ago
    I think you're referring to "gatekeeping." If the employee, for instance, proactively fixes a bug or resolves some technical debt, it's possible another team member might try to prevent it from being merged. Their reasons might seem non-objective and rooted more in the fact that they weren't involved in the change, or involved in the decision to make the change. I've ran into this. It's easy to be discouraged and, in the event this occurs, stop trying. That said I think this is the wrong thing to do. Instead I view this type of scenario as a chance to convince my teammate of the value I'm adding and the rationale behind the change being made without being explicitly planned. It's hard work, and sometimes involves some long, strained conversations with your team mates. That said at the end of the day you just might encourage that individual to proactively solve these types of problems. This will probably make that person happier as well, and unlock additional productivity for your team. The hardest part of software is the people part :)

walshemj 6y ago

The OP is of course the new guy/gal so your not going to being doing major things from day 1.

codeviking 6y ago
Being new doesn't mean you can't try to do things. If the OP takes that perspective then they're just limiting their own potential. Code is code, and can be changed. There's this weird inhibition in our industry to just trying things. Senior or not, there's no harm in opening a PR. If there's a clear reason for not applying a change it's just a learning exercise. The PR can be closed without any negative impact. Who knows, maybe discussing the PR will be teach the senior contributor something. I can't tell you how many times I've realized a prior constraint is no longer valid via a discussion o'er a PR. I end up informed, the new contributor ends up empowered and the code base lands in a better state -- win, win and win! IMO these types of changes and the resulting discussions are healthy and absolutely crucial to the longevity of a successful piece of software.
- walshemj 6y ago
  Just opening a PR ? some time you have to step a way from a laser focus on JIRA and GitHub. As a newbie at a FANG its going to take at least 9 months to a year to get that familiar with such a large code base. And most of being a developer is not KLOC's or its modern eqvielent Fuature Points