11 ms·

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 sys

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.

badosu 9y ago
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.
pc86 9y ago
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.
- jacobush 9y ago
  A common one is that they are bogged down in work. Then, figure out why that has been allowed to happen and tread carefully.
- dagw 9y ago
  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.
  - maccard 9y ago
    Please don’t ask me to explain parts of the code base during my lunch break. It’s my lunch break, not meeting time.
    - dagw 9y ago
      Sure, just say "no" when I ask if you want to go to lunch and talk shop.
      - 52-6F-62 9y ago
        That gets tricky. You can quickly become a poor "culture fit" at some workplaces when you turn down such requests as a principle.
      - brazzledazzle 9y ago
        If you’re in my management chain that’s easier said than done.
- arcticfox 9y ago
  > 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.
- xkjkls 9y ago
  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.
kevinconaway 9y ago
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.
- struppi 9y ago
  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 ;)
  - maroonblazer 9y ago
    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.
- mercutio2 9y ago
  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”!
mynameishere 9y ago
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".
- gil 9y ago
  > Style tip: When talking about a particular person, don't refer to him or her as "they". Can you explain why, please?
  - mynameishere 9y ago
    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.
    - gil 9y ago
      Got it, thanks. Perhaps the parent was trying to conceal the identity of the person in question and gender would be too much of a giveaway.
    - sctb 9y ago
      It's less of a touchy subject than a predictable and boring digression. Users often flag off-topic comments.
norswap 9y ago
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).
arcticfox 9y ago
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.
- w0m 9y 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.
  - hyperpape 9y ago
    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.
maxxxxx 9y ago
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"
- tonyarkles 9y ago
  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.
  - maxxxxx 9y ago
    "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.
    - tonyarkles 9y ago
      That's very true. The middle ground of that is that smart people, making a series of reasonable decisions, can still lead to a terrible destination. I've done it myself, and I've had teams describe multi-year developments where I can't point out a specific place they went wrong. People get caught up in that though, and they're often blind to it until a fresh set of eyes get on it. [I've spent a lot of time this morning trying to articulate further, and I'm too distracted by the work I'm trying to do. Sorry.]
jrochkind1 9y ago
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.
privacypoller 9y ago
I read it as the more neutral impress, as in draw attention or make a lasting mark, versus "make yourself look good".
deleted 9y ago
[deleted]
edraferi 9y ago
I think you missed the point - it's not being over eager. It's a methodical approach to quickly learning about your new organization.
bjourne 9y 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. 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!"
- AnimalMuppet 9y ago
  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.
  - bjourne 9y ago
    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.
- loco5niner 9y ago
  > 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.

badosu 9y ago

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.

pc86 9y ago

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.

jacobush 9y ago
A common one is that they are bogged down in work. Then, figure out why that has been allowed to happen and tread carefully.
dagw 9y ago
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.
- maccard 9y ago
  Please don’t ask me to explain parts of the code base during my lunch break. It’s my lunch break, not meeting time.
  - dagw 9y ago
    Sure, just say "no" when I ask if you want to go to lunch and talk shop.
    - 52-6F-62 9y ago
      That gets tricky. You can quickly become a poor "culture fit" at some workplaces when you turn down such requests as a principle.
    - brazzledazzle 9y ago
      If you’re in my management chain that’s easier said than done.
arcticfox 9y ago
> 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.
xkjkls 9y ago
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.

kevinconaway 9y ago

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.

struppi 9y ago
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 ;)
- maroonblazer 9y ago
  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.
mercutio2 9y ago
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”!

mynameishere 9y ago

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".

gil 9y ago
> Style tip: When talking about a particular person, don't refer to him or her as "they". Can you explain why, please?
- mynameishere 9y ago
  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.
  - gil 9y ago
    Got it, thanks. Perhaps the parent was trying to conceal the identity of the person in question and gender would be too much of a giveaway.
  - sctb 9y ago
    It's less of a touchy subject than a predictable and boring digression. Users often flag off-topic comments.

norswap 9y ago

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).

arcticfox 9y ago

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.

w0m 9y 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.
- hyperpape 9y ago
  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.

maxxxxx 9y ago

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"

tonyarkles 9y ago
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.
- maxxxxx 9y ago
  "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.
  - tonyarkles 9y ago
    That's very true. The middle ground of that is that smart people, making a series of reasonable decisions, can still lead to a terrible destination. I've done it myself, and I've had teams describe multi-year developments where I can't point out a specific place they went wrong. People get caught up in that though, and they're often blind to it until a fresh set of eyes get on it. [I've spent a lot of time this morning trying to articulate further, and I'm too distracted by the work I'm trying to do. Sorry.]

jrochkind1 9y ago

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.

privacypoller 9y ago

I read it as the more neutral impress, as in draw attention or make a lasting mark, versus "make yourself look good".

deleted 9y ago

[deleted]

edraferi 9y ago

I think you missed the point - it's not being over eager. It's a methodical approach to quickly learning about your new organization.

bjourne 9y 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. 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!"

AnimalMuppet 9y ago
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.
- bjourne 9y ago
  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.
loco5niner 9y ago
> 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.