Comment by wccrawford
8 years ago
I don't think I agree with this.
We had a programmer that tried from the start to impress us. They were constantly suggesting new tools, or changes to the system, or trying to abstract some code.
What they weren't doing was what we asked them to do. They'd put a token effort into that, do it wrong, and then call it done.
On the other hand, all my best newbie programmers came in, buried themselves in their tickets until they understood them, fixed them, and went on to the next ticket. There was very little attempt to change the system in their first year.
I'm much happier with people who focus on doing their job instead of focusing on trying to impress people.
The article is about how to make a positive impact as soon as possible, impressing people is only a side effect of that.
It sounds like you're looking for ticket monkeys; the article is about how to become more than that for the people that aspire to that.
The fact that you call your new hires "newbies" and don't expect them to make suggestions for a year is a huge red flag for me. Either you didn't understand that the article is targeted towards experienced professionals switching jobs (first sentence), or you think that a professional will take an entire year to understand your org and be more productive than work on tickets.
Most devs that I know worth their salt are comfortable switching jobs every 2 years or so (whether they choose to or not). The contrast between that and not even being expected to think for a year is massive.
It sometimes seems like we software developers travel in really distinct worlds.
People who have an established pattern of changing jobs every 2 years won’t even get an interview in my org, and they definitely need at least a year before they understand the problem space well enough for their offers of major architecture changes to be welcome.
The idea is that coming in and working on the problems you’re assigned is good because you can more deeply understand the problem space AND make things better.
I expect this, better and faster and with more humility and wisdom, from senior engineers. That doesn’t make anyone a ticket monkey in my book, it makes them effective at their very highly paid job.
As an aside, I highly recommend the article’s strategy for appearing (and hopefully actually being) wise and humble, as long as you’re getting your assigned, bare minimum work done.
Anyway, it sounds like maybe we mutually wouldn’t want to work with one another, which is why it seems like we live in different worlds to me.
> they definitely need at least a year before they understand the problem space well enough for their offers of major architecture changes to be welcome.
I think there's a role for humility on both sides. In my current role, I was an experienced hire. After a month on the job my manager and his manager pulled me aside and said "What are we doing wrong?"
The interesting thing was that when I told them that I thought their module system was seemed backwards, the response was "Yeah, we know. It's a quirk of history that it ended up that way, and we've got a plan to fix it. Anything else?"
They very much valued a fresh set of eyes to ensure that they weren't missing something they had become house-blind to. At the same time, as a set of fresh eyes your attitude should be one of questioning, "Why are we doing it that way?" rather than "We're doing it wrong" or "This way is better".
3 replies →
There's another facet to this story that's not getting discussed: that of path dependence.
The OP is Silicon Valley royalty. This matters. His site is pretty humble, but this guy was like, employee #10 at facebook and is probably worth high 8/low 9 figures. He is respected in a way most people aren't.
Boz can come in and start making these changes. Most people can't. We need to talk about this more. We labor under this bizarre illusion of non-hierarchical workplaces in Silicon Valley, when the reality is and always has been, some people have more influence than others.
I find it helpful to keep in mind the circumstances about the advice-giver as much as the advice itself. I'm not saying there aren't good nuggets of advice to glean. But who you are and your track record really matter in Silicon Valley and we should acknowledge that. It's not as much of a pure idea meritocracy as people think/pretend.
2 replies →
The flip side of this is demonstrating humility and being a ticket monkey for a year, only to slowly realize you've been taken advantage of, and as you approach year #2 realizing that neither you nor anyone on the "ticket monkey" team ever has or ever will move to the new development group. I once had the experience of being duped by a company that (accidentally, or maliciously) advertised two Developer positions when in actuality they wanted one Junior Developer and one mid-level Developer. Our resumes ranked similarly so they arbitrarily put one of us on the ticket-monkey team and the other on the new development team. I should have either raised hell or gone elsewhere when I found out the level I received was not the one in my offer letter (the pay, while the same, was already below-market anyway), but like a chump I took it as a character building opportunity and thought I would work my way up. What I learned was that that strategy works in a dysfunctional company about as well as it works in a dysfunctional relationship.
> they definitely need at least a year before they understand the problem space well enough for their offers of major architecture changes to be welcome.
No offense intended, because I don't know your situation, but as someone who has worked in several industries, every time I've heard that kind of phrase it's boiled down to some combination of unnecessary complexity (of architecture and/or process) and undocumented tribal knowledge.
I can't imagine any problem space that would take a senior developer a full year to become competent.
7 replies →
> at least a year before they understand the problem space well enough
I'm curious what domain you're in? I get the sense that different real-world topics account for much of the difference between developer 'worlds'.
I remember talking to a few rocketry companies in college (not SpaceX), and they were overt about wanting someone who would start out doing rote work and already had substantial expertise in their C package of choice. I certainly cant blame them; their risk profile is fundamentally different than almost any other software domain. (The exceptions, like military and aviation use, also tend to be pretty hard-nosed.)
"Not doing assigned work" is obviously a terrible trait basically anywhere, but the other divide here is really interesting to me. There are a lot of very successful companies which hire 2-year-turnover staff and assume they'll get the same, and then there are companies like yours with 'dark matter developers' who would never cross paths with that.
> People who have an established pattern of changing jobs every 2 years won’t even get an interview in my org
2 years? Most of the companies and projects I joined were long gone and dead 2 years down the road. Different industries indeed.
5 replies →
>they definitely need at least a year before they understand the problem space well enough for their offers of major architecture changes to be welcome.
IME, hubris usually correlates with architectural problems and higher than normal technical debt.
I can't see any good reason to analyze ideas about architectural overhauls on anything other than their technical merits. If there's a reason relating to the problem space for rejecting one particular idea that's fine, but unless your architecture is completely fucked that should be very rare.
It's perfectly normal to tear out the badly written guts of a software system and build up a better version, and a deep understanding of requirements should not really be required to do that in most cases.
4 replies →
Unless your system is much bigger than 1M LOC I seriously doubt that an experienced good programmer will need more than one year to understand it. It never took me more than one month to understand a system, even when I was junior and when the system was > 1M LOC.
2 replies →
> don't expect them to make suggestions for a year
That's not the problem.
The problem is that some newbies want all of the code to be their design pattern of choice; or just want to refactor things until they understand it. Some will just refuse to follow established design patterns and do things like bypass our dependency injector.
For me, it's a red flag whenever someone comes on a team and immediately wants to refactor to use their favorite design patterns, frameworks or style. It's not that their preferred design patterns are better or worse than what we're using; it's that you just don't refactor code on a say-so.
I feel like the article is not about this at all though. If you behaved according to the algorithm as a newbie, you would only refactor and change the design pattern if people told you that that should be done. Which your newbies weren't told according to what you're saying.
1 reply →
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.
7 replies →
I don't know about a year, but usually understanding how things work take time. Understanding why they work this way and not another also takes time. If somebody doesn't take time to learn the background of decisions taken, they are liable to repeat the same mistakes and stumble at the same bumps as have been already passed before and encoded in organization's common lore.
There is something called Chesterton fence principle: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence - before proposing to change something, give it an earnest try to figure out why it was like this before, and what changed. Sometimes there's no good reason, or the reason once existing is long gone, and a fresh eye is useful to shake out those cases. In other cases, there are complex and unobvious reasons that cost a significant effort to figure out, and may be not apparent to the fresh eye. So it's better to keep an open and humble mind and at least at first, approach new system with the attitude "please help me learn why it's like this" instead of "this looks wrong, let's throw it away and re-do it from scratch". I'm not sure about a year, but at least a month or two would probably be appropriate. And my experience showed dealing with bugs can actually be very instructive about how things work and why they work this way and not the other.
Why the bias against solving problems that are ticketed? Problems that haven't been discovered yet are seldom more important than the ones that have already been discovered. Unless we're optimizing for your ego, or the existing team truly are idiots whose entire list of known problems deserves to be blown off. (Or more gently, they've made some glaring oversight of a worthwhile value-adding solution.)
Anyway, the article is more about humbly learning how the team works, not about rewriting their codebase just yet, i.e. the opposite of your point about "ticket monkeys."
The article is clearly targeted at managers and leaders, not your average individual contributor.
Often new leaders & managers start in an established team and want to change something to "make their mark" or have an impact as soon as possible, often with disastrous results (because they don't yet have the context to make informed decisions).
The advice is to spend time with your team to learn the ropes, figure out the internal politics, hear the common pain points and _then_ start addressing things, hopefully with some quick wins (like canceling a wasteful meeting or appropriating a larger conference room) that due to organizational inertia, went unaddressed.
Yes. And I think the article is also good advice for coaches / consultants.
When I come to a new team, I always try to find out a lot of things during the coffee breaks. But the approach from the article is more structured.
So, I guess I will try a mix of the two approaches next time ;)
I agree that the OP seemed to miss who the article is targeted at (managers, leaders). However I think this is still very good advice for an IC, even someone straight out of school.
Does it mean they start taking on projects that don't align with their role? Probably not.[0] What it does do is enable them to get a fresh perspective on the org, team and work and perhaps contribute ideas in group settings/meetings/social situations that others may not have considered, by virtue of not having executed the algorithm in the article.
If nothing else it gives one a structured way to gain valuable information about the org and the work, regardless of where you sit in the 'food chain'. It's also a great way to build a network.
[0]Often companies allow for 'stretch' time where ICs can take on side projects. Running this algorithm could be a great way to surface ideas for those kinds of projects.
That isn’t clear to me at all, but then I don’t know the author.
This seems like excellent advice for individual contributors, of whatever seniority, if you can already kick ass at the work you’re assigned, maybe after the first month or two. Provided you have the diplomatic skills to broach process change ideas in a way that doesn’t leave you looking like an entitled asshole, of course. But then, maybe that’s what you meant by “leader”!
It could have been emphasized better, but the third sentence of the article does say that it's talking about "incoming leaders".
How does what you say contradict the OP in any way, shape or form?
He says ask to meet people to understand how everything works. It's not about impressing them, even if it shows proper respect as a side effect (and showing respect by listening is quite the opposing of suggesting new things nilly willy).
I think the original article was written for someone who's going to _manage_ a new team, although it doesn't say that as explicitly as it should. But that's what I'm reading between the lines.
I think the "listening tour" is a pretty good idea even if you aren't a manager. But what to _do_ with it, needs somewhat different advice.
I also suspect the programmer in the comment I'm replying to did _not_ in fact do the "listening tour" that is the main recommendation of the original article. It's not advocating for suggesting changes based on your personal opinion, but only after learning what the team thinks and based on what they think. So the programmer in the comment I'm replying to didn't follow the advice at all.
I think implicit in the author's text is the implication that you have a high standard for ownership, so that you can handle your responsibilitites well.
I agree though that this should not be advice for novice programmers, as in this moment of the career you are not sure of the most common pitfalls a team/project gets into and should be mostly concerned about learning the technical knowledge. Trying to do anything else will be a distraction from your current goals.
Very helpful advice for consultants or team members who really care about the project and your career.
But again, as said by a sibling comment, you should always pay attention to disfunctional environments and avoid getting too much attention from sociopathic managers/technical leads. Get some advice from the peers at the same hierarchical level first to know if things are handled smoothly, before iterating.
I am dealing with this at the moment. We have a new contractor and he always wants to make big changes whenever he does something. Sometimes he may be right but I am getting tired explaining that maybe there is a reason why we are doing things a certain way and that the changes he is proposing often are just changes but don't really improve anything.
To quote the seven habits of effective people:
"Seek first to understand, then to be understood"
This is one of the most valuable lessons of contracting: only try to help people who want to be helped. Sometimes you can influence them to want help with something (e.g. an architectural change that will make things better), but if they don't believe there's anything wrong, it's just going to be a pointless battle.
It gets more awkward when you're brought in by one person, but quickly realize that the people you're working with don't want you to do what you were brought in to do. Or when people tangential to the project see it as a threat to the status quo and actively try to prevent you from doing what you're trying to do.
"but if they don't believe there's anything wrong, it's just going to be a pointless battle."
Also consider that the people there aren't dummies but know what they are doing. One of the biggest career improvements I have made is to assume people are competent until I get clear evidence of the opposite. This makes relationships much more pleasant.
1 reply →
You're probably correct in your analysis, but in general I'm very wary of people who use self-help readings or techniques to analyze what everyone around them should be doing differently. I often run into people who seem to use these kinds of things as excuses to blame others and not take reasonable action on their own.
I don't walk around quoting self help all the time. My point is that before you give advice first take some time to understand the situation.
Of course, for a contractor, there's good money in making the problem bigger...
> I don't think I agree with this.
> We had a programmer that tried from the start to impress us. They were constantly suggesting new tools, or changes to the system, or trying to abstract some code.
If you had people like that, and you weren't able to utilize their talent, then your workplace sucks.
The right way to go when someone says "We should do $X!" and you don't believe it is to say "Prove it!"
Depends on how disruptive their proving it is going to be. If it's not going to be worth the code turmoil, even if they're right, then no, that's not "the right way to go".
Improvements aren't free. They cost, usually more than just the opportunity cost of the implementer's time. There are lots of ideas for improvement that will cost more than they deliver. If I have someone consistently suggesting them, no, I have no place for utilizing their "talent", and no, it's not because my workplace sucks.
And I'd have no use for people merely following commands and doing the minimum work necessary -- like most employees. We cherish ambition and are not afraid to be proven wrong. We prefer to give people the benefit of doubt, rather than assuming ignorance.
> What they weren't doing was what we asked them to do. They'd put a token effort into that, do it wrong, and then call it done.
I'm not sure I would call that "talent", and based on that performance, I certainly wouldn't want their "improvements" on our systems.
The best way become more familiar with an unknown team and code base is to work in the code daily. Spending your entire day in 30-minute one-on-ones with people will not help either of those. The exception of course is when you're brought in as a senior-level person in order to change something. But then you need to ask yourself why the senior folks on that team aren't in charge of that.
Spending your entire day in 30-minute one-on-ones with people will not help either of those
I assumed it would be around 5-10 meetings over a few weeks. Half of which can probably be done on lunch breaks. So it shouldn't take too much time away from real work. Obviously you should be working in the code base daily, but in the beginning working 8 hours a day is probably less efficient than working 7.5 hours and spending 30 minutes actually asking someone to explain parts of the code base to you.
Please don’t ask me to explain parts of the code base during my lunch break. It’s my lunch break, not meeting time.
3 replies →
> Spending your entire day in 30-minute one-on-ones with people will not help either of those.
How many of these meetings do you think the author is suggesting?? Even one day of that is 16 meetings, roughly the number of people I worked with on a regular basis at Microsoft.
Clearly the author is suggesting to mix them with regular work. One hour of effective meetings per day, plus seven hours in the code, is going to be vastly more effective than just wallowing through code for the entire day.
This confuses me. Coding is more of a tactical operation, and with it you're still going to want a grand strategic vision of what to implement. I think it's foolish to think that you can see the big picture just by trying to make a lot of commits.
A common one is that they are bogged down in work. Then, figure out why that has been allowed to happen and tread carefully.
I think you missed the point - it's not being over eager. It's a methodical approach to quickly learning about your new organization.
I read it as the more neutral impress, as in draw attention or make a lasting mark, versus "make yourself look good".
You are rather elaborately saying that you want people who do what they're told and don't make waves. Got it--every manager wants that 100 percent. No kidding.
Style tip: When talking about a particular person, don't refer to him or her as "they".
> Style tip: When talking about a particular person, don't refer to him or her as "they".
Can you explain why, please?
Grammar and style are both ultimately dictated by usage, so if someone insists on plugging in XYZ as a new ultra-PC pronoun I can't really prove that it is incorrect, no matter how ridiculous.
So, that said: The whole point of using "they" is when you don't know the gender of a person and don't want to presume by saying "he" or "she" or muddying up the text by saying "he or she". When you know the gender of a person, using the correct pronoun is better--it's both succinct and corresponds more closely with reality.
It's a touchy subject [I mean, some idiot flagged my comment--come on!] but people tend to over-correct in grammar quite a bit, and over-correcting with "they" happens like this.
2 replies →