Comment by w0m
8 years ago
Depends on the size and life of the project and average term of service. If your project is a decade old and massive, where many on the team have been on the project for 5+ years - Yes, a 'newbie' needs a (non-trivial, 1 year could be too long or too short) amount of time to ramp up on why things are like they are before they can make a nuanced suggestion for improvement.
A smaller project that's in a constant state of flux? Of course suggest giant overarching changes when they appear to make sense. What's proper depends heavily on the context of the group and project.
I work on a system that has 15 year old code in it, lots of it in a bad state (it's being removed, but slowly).
I've seen a lot of people come in (category A) who can spout best practices that we're not following, but can't ever wrap their heads around the way the system works, the amount of effort that implementing an idea will take, and the amount of payoff it will offer. They just cargo cult best practices. With those people, I want to say "please just crank out tickets until you understand more".
However, there have also been a small handful of people (category B) who come in, and quickly find ways to make beneficial changes that are achievable and worthwhile. Those people are incredibly valuable.
Concrete advice: if you take a year for any new hire to understand things enough to make changes, you need to work on the understandability of your system, your onboarding, or stop hiring exclusively from category A.
How is “quickly find ways to make beneficial changes that are achievable and worthwhile” distinct from resolving tickets?
That seems like a perfect description of doing a good job at resolving tickets to me. Because if the change was beneficial, it was presumably not just navel gazing architecture astronauting, it was solving an existing problem, right?
General expectation for Senior engineers in the orgs I've been a part of is that they are great problem finders, as well as problem solvers and implementers. If you have a significant backlog of useful improvements that are relatively straightforward to implement, then it's likely better to bring on a few junior engineers to tackle those rather than Seniors. If you're looking to turn the large backlog into a small backlog thanks to innovative solutions or break into new areas, Seniors tend to handle it better.
The red flag in the ramp up curve is really for Senior engineers. If I didn't have a solid understanding and demonstrated ownership of my problem domain within six months along with meaningful projects getting pushed through - my manager would likely be starting an awkward conversation with me.
5 replies →