8 ms·

For the first month or so I take a very humble listening position, even if I immediately see things I want to fix. More often then not, there is a background an

For the first month or so I take a very humble listening position, even if I immediately see things I want to fix. More often then not, there is a background and a history to things that could lead to a) my “fix” being unnecessary and/or ill-informed and b) friction with the rest of the team because here comes a whippersnapper upending all our stuff. Process and code fixes are _much_ easier once you have good rapport with the team.

makmanalp 8y ago
This honestly took me a while to learn - it's so easy to jump in and be a smartass (and I've been guilty of this before) about how bad things are, but a) suggesting small, incremental changes that demonstrate a nuanced understanding of where things went wrong and b) volunteering to work on making things better goes a long way. Most of the team will already often know and agree on what is bad - but just won't be empowered to fix it somehow.
- minor3rd 8y ago
  > This honestly took me a while to learn Yeah same here. I think I pissed off my manager pretty quickly at my current job by trying to change how they did certain things before getting an understanding of why they did them that way, but I realized my mistake and went into more of an observer-mindset for awhile. Over time I built up a reputation with reducing friction in smaller ways on specific features I worked on, and then applied that same thinking to larger scale issues I saw. They were much more receptive once they knew I could make valuable contributions, and now I'm one of the main people establishing patterns and architecture decisions at my company. Learning to establish myself for awhile before making process changes was a great learning experience that I plan to take with me to all future roles.
  - krenel 8y ago
    Your comment resonates with me. I work hard to improve things; most of it was worth it, some of it didn't went well but it was a constant fight with my boss. If I failed, he would bring it back for months. What worked for me was to step back and get into super pasive mode. Give all the responsability to my manager. I didn't question any of his design decisions, gave support to all ideas even if seem plain wrong unless he wanted honest feedback (usually, he didn't because I would change the original idea). Never say or even insinuate "I told you this was not gonna work"; I just acted surprised and asking to him "ok, what do we do now?". It just took a few months for my manager to start reliying on me, more and more. Now I have even more space for improving things, with the full support of my manager because "he wants me to do it" not "because I push my ideas to him". At the end of the day, it's not dumb if it works.
oreganoz 8y ago
Yeah, I have to say I'm a bit surprised to see people so eager to change things that are working, so fast.
- geezerjay 8y ago
  Sometimes those things that are working imposed a hefty load of technical debt, which newcomers are tasked to pay up with compound interest due to the unfamiliarity with the codebase. Therefore rewriting some components may actually pay off in productivity in the short run.
mason55 8y ago
See also Chesterton’s fence. You don’t want to change something until you understand why it’s there in the first place. https://abovethelaw.com/2014/01/the-fallacy-of-chestertons-fence/ https://abovethelaw.com/2014/01/the-fallacy-of-chestertons-f...
- gota 8y ago
  This reminds me of the Joel Spolsky's post on why you should never re-write your code from scratch [1]. The reasoning goes most 'ugliness' comes from bug-fixes that people encountered along the way, and by re-writing that 'two page function' you lose all that accumulated knowledge. In short, the hacks that make us want to rewrite code are there for a reason [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
  - james_morton 8y ago
    More likely the hacks are there because requirements changed and the software wasn't initially built to be flexible enough to support change. A rewrite will solve it in the short term - until requirements change again. However, I would much rather apply the new 'hacks' onto the rewritten 10 line function than figure out the original 200 line behemoth.
    - swsieber 8y ago
      Each hack individually, yes, is likely to be there because of requirements changing. But collectively, it's likely that one of those hacks is there to account for some edge case that's not intuitive and will be missed on the rewrite.
    - organsnyder 8y ago
      In my experience, it's extremely difficult to know which particular lines of code are obsolete. This becomes even more difficult as a codebase ages and is worked on by more contributors. Add on another exponent for every business stakeholder that has a hand in defining the business rules—especially if you have requirements coming from multiple sources that may not be aware of each other.
JustSomeNobody 8y ago
> Process and code fixes are _much_ easier once you have good rapport with the team. And one doesn't get that by walking into a place expecting to make sweeping changes. What's worse is job hoppers were asked so this means people are going into a shop, making these changes, and leaving shortly after. The hell?
- awinder 8y ago
  More realistically they’re going into a shop proposing changes immediately, getting slapped down, becoming disillusioned, leaving, and then trying again somewhere else. Even when people do make changes like this, it’s unlikely they stand the test of time, I’ve definitely seen people’s “pet changes” get rolled back within microseconds of them exiting.
  - carlmr 8y ago
    You're absolutely right. "job hoppers" are often the very motivated people that are worth their weight in gold, but don't find a company that is on their level. However as a manager you should probably not institute sweeping changes a "newbie" (he could actually be more of an expert than your own team, but you don't know this yet) suggests, but finding out why the newbie suggests them should be in your best interest. Often fresh eyes are the only ones that can see what is wrong. Dan Luu put this really well: https://danluu.com/wat/ https://danluu.com/wat/. A lot of catastrophe's could have been avoided (especially stuff that's morally questionable) if people listened more to the newbie who still isn't conforming enough to your team that he still sees what's wrong. So my advice (to the managers): listen to the suggestions, and put your managerial clout and preexisting rapport with your team (which the newbie lacks) to implement the good ones, if there are good ones. If they aren't you can still explain why.
cncrnd 8y ago
Agreed. I have a theory that the reason contractors want to change everything when they arrive is so that they have infinite work. I also always see contractors wanting to start self-initiated projects from scratch rather than working in the codebase, which is of course easier to produce a visible result in.
- Techinica 8y ago
  As a person working in this scenario I find the biggest issue coming into work on an established code-base is the lack of documentation and a lack of interest from the company's own people to divulge any information about the code base. This unfortunately leads more often than not to the situation you describe, re-written code or projects perhaps unnecessarily separated.
  - cncrnd 8y ago
    Very true as well, and if that were plainly stated the problem could be addressed. The issue is that some of these people are smooth talkers able to convince managers that these big shifts are necessary right away...and inevitably end up abandoning big projects they push for. Others are able to poke around the codebase and ask questions till they can contribute in a meaningful way, but these are rare in my experience.
    - klibertp 8y ago
      > Very true as well, and if that were plainly stated the problem could be addressed. That's not, at all, how this works, especially for newcomers. If the new programmer on your team doesn't want to work on a larger code base, it's your responsibility to notice this early, initiate a talk with them about the reasons and actively try to fix the problems they have. Reading code is hard enough, but reading it under pressure of being the new guy makes it even worse. Don't expect many people to be able to cope with this without serious effort on your part. If you can't be bothered to effectively support them in understanding your code, they are not likely to care about that code sufficiently to productively work on it.
    - 8y ago
mattlondon 8y ago
+1 for this. Unless you've been hired specifically to help them change their dev practices, I'd go along with what they have until you've got some understanding and reputational-clout to start suggesting such huge changes to how everyone works. Rocking up and on day one start asking people to change their development practices (particularly around branching policy which is something very contentious and/or strict everywhere I've been) because "It makes my work easier" is a sure-fire way to get people's backs up and dislike you. And where do you stop? First it "It makes my work easier" to change the dev practices, but why not start demanding that everything is rewritten in Go/Vue.js/Haskell? It'll make your work easier. How about we change the product from a Desktop App to a web app? It'll make your work easier. Why dont we just sub-contract the whole thing out to off-shore teams? It'll make your work easier. There might be a case for any of those, but I'd personally wait (and I would prefer any hires I bring in also wait!) until the right time before advocating for massive sweeping changes right away. tl;dr - Arrogance & know-it-alls can be disruptive (in a bad way). It takes a village and flexibility is key to working with any team.
- dboreham 8y ago
  The fact that process is off in the first place indicates a deeper problem.
  - deleted 8y ago
    [deleted]
  - mseebach 8y ago
    In which case the correct answer is to sit tight for a bit until you understand the deeper problem. And then you fix the deeper problem, and then you fix the process.
  - zrobotics 8y ago
    If the process is 'off' around branching policy, there may actually not be a problem. It's certainly possible the new dev prefers a different branching policy simply because that fits with what they are used to. There may be reasons, and good ones, for what may at first appear like poor git practice. Or it may be a problem, but a new dev should at least give it enough time to determine there is no reason things are this way before advocating change.
pjmorris 8y ago
'Everything got the way it is one logical step at a time' - paraphrase of some of Gerald Weinberg's advice in 'The Secrets of Consulting'
bbarn 8y ago
I was going to say "Happy Hour" but this is really what I meant. I focus first on understanding how the team works, their motivations, their past pain points, and honestly become one of them before I suggest changing what is then _our_ process.
- kevinmchugh 8y ago
  I wouldn't, on the first day, try to take up more of my coworkers time. I would wait until I learned the norms about after-work outings and what sort of obligations they have outside of work.
tvanantwerp 8y ago
This is one I learned the hard way. I made a number of much-needed fixes at a job where they'd never really had a dedicated technical person before. People freaked out. I hadn't communicated what I was doing and why it was necessary, and it took a while to earn goodwill after that. Lesson learned: don't implement a solution until you've convinced everyone they have a problem and this will fix it.
Antoninus 8y ago
I whole-heartedly agree. I've worked with too many Senior Engineers who immediately want to change processes in their first two weeks of starting at a new company. It only alienates the other developers.
deleted 8y ago
[deleted]
jSully24 8y ago
I was asked in an interview "What is the first thing you will change?" (I was interviewing for a Manager position, but I think this applies no matter the position you are being interviewed for.) My response was - "I don't know. I need to spend time getting to know the team, understand our product, and better understand priorities." I try to use this question in interviews with senior people, be they Developers or Managers. It can expose someone who will quickly blow your team up should they join. I like working with people who have great passion and will stand up for their ideas, but understanding the problem first is alway wise! Getting to know people, products, and customers, (not that customers aren't people) with listening and questions makes everyone better.
- maerF0x0 8y ago
  > "What is the first thing you will change?" My response: "My mind" ... As i seek to _first_ understand and then to act...
  - bayological 8y ago
    10 Points
gravis7777 8y ago
Dead on right. Love this approach. Hate when someone comes into a corp and on day 2 starts pushing changes when they weren't hired to specifically fix a broken process, just replace an employee who is moved on. After 60 days, you will know plenty about what is broken and by then will have earned at least some trust to begin implementing fixes.
cgb223 8y ago
We've got a new member on our team (from a different team within the company) who within his first week is already trying to shake things up with "fixes" Its driving me a little crazy. He is more senior than us, but doesn't have any of the context of why we do things the way we do He'll explain things to us we already know, and propose solutions to us we tried months ago that didn't/don't work After getting a little frustrated, I pulled him aside at the end of the workday and sat him down to give him some context on a lot of things on our team, but he's determined to "shake things up" and believes he's "right" so "why should it matter"? The one good thing about this is it's taught me just how patient and restrained I can be, which is a lot more than I thought, but please, please tell me that this eventually changes?
- Hirak 8y ago
  Guys, should we tell him?
  - cgb223 8y ago
    Oh, no What am I missing?
    - noir_lord 8y ago
      It won't get better, he's more senior, he'll probably get promoted before you guys (and he has a head start) so he'll be your bosses boss and mandate all this stuff. You'll leave because surely everywhere can't be this dysfunctional only to find that everywhere is then you'll reach a grudging acceptance (people will call you cynical) and you will live for your hobbies. 40 years from now a vein blows out and you shuffle of the mortal coil. Alternatively it'll get better, he'll realise that his ideas while well intentioned are upsetting the team and he'll tone it down a bit. Flip a coin. (I wish I was joking about the binary options but well...it'll be one of those two).
- xorcist 8y ago
  Everything changes. But it's likely to be the whippersnapper moving on (again), while the rest you you gets to mend all the semi-implemented best practices to resemble some sort of coherent whole again. Or not. Nah, you're probably ok.
bytematic 8y ago
Adam Grant talks about this in "Originals".

makmanalp 8y ago

This honestly took me a while to learn - it's so easy to jump in and be a smartass (and I've been guilty of this before) about how bad things are, but a) suggesting small, incremental changes that demonstrate a nuanced understanding of where things went wrong and b) volunteering to work on making things better goes a long way. Most of the team will already often know and agree on what is bad - but just won't be empowered to fix it somehow.

minor3rd 8y ago
> This honestly took me a while to learn Yeah same here. I think I pissed off my manager pretty quickly at my current job by trying to change how they did certain things before getting an understanding of why they did them that way, but I realized my mistake and went into more of an observer-mindset for awhile. Over time I built up a reputation with reducing friction in smaller ways on specific features I worked on, and then applied that same thinking to larger scale issues I saw. They were much more receptive once they knew I could make valuable contributions, and now I'm one of the main people establishing patterns and architecture decisions at my company. Learning to establish myself for awhile before making process changes was a great learning experience that I plan to take with me to all future roles.
- krenel 8y ago
  Your comment resonates with me. I work hard to improve things; most of it was worth it, some of it didn't went well but it was a constant fight with my boss. If I failed, he would bring it back for months. What worked for me was to step back and get into super pasive mode. Give all the responsability to my manager. I didn't question any of his design decisions, gave support to all ideas even if seem plain wrong unless he wanted honest feedback (usually, he didn't because I would change the original idea). Never say or even insinuate "I told you this was not gonna work"; I just acted surprised and asking to him "ok, what do we do now?". It just took a few months for my manager to start reliying on me, more and more. Now I have even more space for improving things, with the full support of my manager because "he wants me to do it" not "because I push my ideas to him". At the end of the day, it's not dumb if it works.

oreganoz 8y ago

Yeah, I have to say I'm a bit surprised to see people so eager to change things that are working, so fast.

geezerjay 8y ago
Sometimes those things that are working imposed a hefty load of technical debt, which newcomers are tasked to pay up with compound interest due to the unfamiliarity with the codebase. Therefore rewriting some components may actually pay off in productivity in the short run.

mason55 8y ago

See also Chesterton’s fence. You don’t want to change something until you understand why it’s there in the first place. https://abovethelaw.com/2014/01/the-fallacy-of-chestertons-fence/ https://abovethelaw.com/2014/01/the-fallacy-of-chestertons-f...

gota 8y ago
This reminds me of the Joel Spolsky's post on why you should never re-write your code from scratch [1]. The reasoning goes most 'ugliness' comes from bug-fixes that people encountered along the way, and by re-writing that 'two page function' you lose all that accumulated knowledge. In short, the hacks that make us want to rewrite code are there for a reason [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- james_morton 8y ago
  More likely the hacks are there because requirements changed and the software wasn't initially built to be flexible enough to support change. A rewrite will solve it in the short term - until requirements change again. However, I would much rather apply the new 'hacks' onto the rewritten 10 line function than figure out the original 200 line behemoth.
  - swsieber 8y ago
    Each hack individually, yes, is likely to be there because of requirements changing. But collectively, it's likely that one of those hacks is there to account for some edge case that's not intuitive and will be missed on the rewrite.
  - organsnyder 8y ago
    In my experience, it's extremely difficult to know which particular lines of code are obsolete. This becomes even more difficult as a codebase ages and is worked on by more contributors. Add on another exponent for every business stakeholder that has a hand in defining the business rules—especially if you have requirements coming from multiple sources that may not be aware of each other.

JustSomeNobody 8y ago

> Process and code fixes are _much_ easier once you have good rapport with the team. And one doesn't get that by walking into a place expecting to make sweeping changes. What's worse is job hoppers were asked so this means people are going into a shop, making these changes, and leaving shortly after. The hell?

awinder 8y ago
More realistically they’re going into a shop proposing changes immediately, getting slapped down, becoming disillusioned, leaving, and then trying again somewhere else. Even when people do make changes like this, it’s unlikely they stand the test of time, I’ve definitely seen people’s “pet changes” get rolled back within microseconds of them exiting.
- carlmr 8y ago
  You're absolutely right. "job hoppers" are often the very motivated people that are worth their weight in gold, but don't find a company that is on their level. However as a manager you should probably not institute sweeping changes a "newbie" (he could actually be more of an expert than your own team, but you don't know this yet) suggests, but finding out why the newbie suggests them should be in your best interest. Often fresh eyes are the only ones that can see what is wrong. Dan Luu put this really well: https://danluu.com/wat/ https://danluu.com/wat/. A lot of catastrophe's could have been avoided (especially stuff that's morally questionable) if people listened more to the newbie who still isn't conforming enough to your team that he still sees what's wrong. So my advice (to the managers): listen to the suggestions, and put your managerial clout and preexisting rapport with your team (which the newbie lacks) to implement the good ones, if there are good ones. If they aren't you can still explain why.

cncrnd 8y ago

Agreed. I have a theory that the reason contractors want to change everything when they arrive is so that they have infinite work. I also always see contractors wanting to start self-initiated projects from scratch rather than working in the codebase, which is of course easier to produce a visible result in.

Techinica 8y ago
As a person working in this scenario I find the biggest issue coming into work on an established code-base is the lack of documentation and a lack of interest from the company's own people to divulge any information about the code base. This unfortunately leads more often than not to the situation you describe, re-written code or projects perhaps unnecessarily separated.
- cncrnd 8y ago
  Very true as well, and if that were plainly stated the problem could be addressed. The issue is that some of these people are smooth talkers able to convince managers that these big shifts are necessary right away...and inevitably end up abandoning big projects they push for. Others are able to poke around the codebase and ask questions till they can contribute in a meaningful way, but these are rare in my experience.
  - klibertp 8y ago
    > Very true as well, and if that were plainly stated the problem could be addressed. That's not, at all, how this works, especially for newcomers. If the new programmer on your team doesn't want to work on a larger code base, it's your responsibility to notice this early, initiate a talk with them about the reasons and actively try to fix the problems they have. Reading code is hard enough, but reading it under pressure of being the new guy makes it even worse. Don't expect many people to be able to cope with this without serious effort on your part. If you can't be bothered to effectively support them in understanding your code, they are not likely to care about that code sufficiently to productively work on it.
  - 8y ago

mattlondon 8y ago

+1 for this. Unless you've been hired specifically to help them change their dev practices, I'd go along with what they have until you've got some understanding and reputational-clout to start suggesting such huge changes to how everyone works. Rocking up and on day one start asking people to change their development practices (particularly around branching policy which is something very contentious and/or strict everywhere I've been) because "It makes my work easier" is a sure-fire way to get people's backs up and dislike you. And where do you stop? First it "It makes my work easier" to change the dev practices, but why not start demanding that everything is rewritten in Go/Vue.js/Haskell? It'll make your work easier. How about we change the product from a Desktop App to a web app? It'll make your work easier. Why dont we just sub-contract the whole thing out to off-shore teams? It'll make your work easier. There might be a case for any of those, but I'd personally wait (and I would prefer any hires I bring in also wait!) until the right time before advocating for massive sweeping changes right away. tl;dr - Arrogance & know-it-alls can be disruptive (in a bad way). It takes a village and flexibility is key to working with any team.

dboreham 8y ago
The fact that process is off in the first place indicates a deeper problem.
- deleted 8y ago
  [deleted]
- mseebach 8y ago
  In which case the correct answer is to sit tight for a bit until you understand the deeper problem. And then you fix the deeper problem, and then you fix the process.
- zrobotics 8y ago
  If the process is 'off' around branching policy, there may actually not be a problem. It's certainly possible the new dev prefers a different branching policy simply because that fits with what they are used to. There may be reasons, and good ones, for what may at first appear like poor git practice. Or it may be a problem, but a new dev should at least give it enough time to determine there is no reason things are this way before advocating change.

pjmorris 8y ago

'Everything got the way it is one logical step at a time' - paraphrase of some of Gerald Weinberg's advice in 'The Secrets of Consulting'

bbarn 8y ago

I was going to say "Happy Hour" but this is really what I meant. I focus first on understanding how the team works, their motivations, their past pain points, and honestly become one of them before I suggest changing what is then _our_ process.

kevinmchugh 8y ago
I wouldn't, on the first day, try to take up more of my coworkers time. I would wait until I learned the norms about after-work outings and what sort of obligations they have outside of work.

tvanantwerp 8y ago

This is one I learned the hard way. I made a number of much-needed fixes at a job where they'd never really had a dedicated technical person before. People freaked out. I hadn't communicated what I was doing and why it was necessary, and it took a while to earn goodwill after that. Lesson learned: don't implement a solution until you've convinced everyone they have a problem and this will fix it.

Antoninus 8y ago

I whole-heartedly agree. I've worked with too many Senior Engineers who immediately want to change processes in their first two weeks of starting at a new company. It only alienates the other developers.

deleted 8y ago

[deleted]

jSully24 8y ago

I was asked in an interview "What is the first thing you will change?" (I was interviewing for a Manager position, but I think this applies no matter the position you are being interviewed for.) My response was - "I don't know. I need to spend time getting to know the team, understand our product, and better understand priorities." I try to use this question in interviews with senior people, be they Developers or Managers. It can expose someone who will quickly blow your team up should they join. I like working with people who have great passion and will stand up for their ideas, but understanding the problem first is alway wise! Getting to know people, products, and customers, (not that customers aren't people) with listening and questions makes everyone better.

maerF0x0 8y ago
> "What is the first thing you will change?" My response: "My mind" ... As i seek to _first_ understand and then to act...
- bayological 8y ago
  10 Points

gravis7777 8y ago

Dead on right. Love this approach. Hate when someone comes into a corp and on day 2 starts pushing changes when they weren't hired to specifically fix a broken process, just replace an employee who is moved on. After 60 days, you will know plenty about what is broken and by then will have earned at least some trust to begin implementing fixes.

cgb223 8y ago

We've got a new member on our team (from a different team within the company) who within his first week is already trying to shake things up with "fixes" Its driving me a little crazy. He is more senior than us, but doesn't have any of the context of why we do things the way we do He'll explain things to us we already know, and propose solutions to us we tried months ago that didn't/don't work After getting a little frustrated, I pulled him aside at the end of the workday and sat him down to give him some context on a lot of things on our team, but he's determined to "shake things up" and believes he's "right" so "why should it matter"? The one good thing about this is it's taught me just how patient and restrained I can be, which is a lot more than I thought, but please, please tell me that this eventually changes?

Hirak 8y ago
Guys, should we tell him?
- cgb223 8y ago
  Oh, no What am I missing?
  - noir_lord 8y ago
    It won't get better, he's more senior, he'll probably get promoted before you guys (and he has a head start) so he'll be your bosses boss and mandate all this stuff. You'll leave because surely everywhere can't be this dysfunctional only to find that everywhere is then you'll reach a grudging acceptance (people will call you cynical) and you will live for your hobbies. 40 years from now a vein blows out and you shuffle of the mortal coil. Alternatively it'll get better, he'll realise that his ideas while well intentioned are upsetting the team and he'll tone it down a bit. Flip a coin. (I wish I was joking about the binary options but well...it'll be one of those two).
xorcist 8y ago
Everything changes. But it's likely to be the whippersnapper moving on (again), while the rest you you gets to mend all the semi-implemented best practices to resemble some sort of coherent whole again. Or not. Nah, you're probably ok.

bytematic 8y ago

Adam Grant talks about this in "Originals".