12 ms·

A common illusion that developers tend to have is the "I'm right, why can't they just see it" syndrome. Without knowing the full story, who knows what actually

by volgo 8y ago

A common illusion that developers tend to have is the "I'm right, why can't they just see it" syndrome. Without knowing the full story, who knows what actually happened there. When you're working on a team, it's completely different from working alone because productivity at scale is totally different from churning out code by yourself One of the best advices I've heard about starting a new job is that, shut up for 6 months and just do whatever you're told. Don't make any decisions, don't make any improvements to the company process, and don't argue with people. Be relentlessly curious and ask lots of questions and follow the herd. Learn everythig you can about the process - the pitfalls, who are the strongest and weakest teamates, who are the difficult ones, who are the influential ones, how do they resolve issues. Once you learn the team's in and out, you have more leg to stand on when influencing decisions. That's when you start suggesting improvements, drawing on the solid experience and trust you've built over the past 6 months From your story, it's clear you wanted to "do it my way" from the get-go and had no patience or respect for other people's way of doing things. It has nothing to do with like-ability or being right and certainly shows lack of professional experience and judgement. I would certainly not want someone like that on my team, no matter how technically gifted they are because an asshole player like that would derail any software team

0xcde4c3db 8y ago
No kidding. As someone who has a good bit of difficulty with social interaction (no diagnosis, but it overlaps with issues that ASD and ADHD people often report), I've failed a likability check or two in my time. I've had conversations where someone seems to be offended or otherwise put off and I have no idea why. But even having those problems, I don't discount other people's opinions and priorities so much that I'd just go in and refactor an existing system without first being pretty clear on who's responsible for it, what problems I'd be solving and risks I'd be creating for them, and that they're okay with it.
maxxxxx 8y ago
"shut up for 6 months and just do whatever you're told. " I like this one. I see a lot of contractors come in and write code that doesn't fit with the rest of the code base. They don't make any attempt to understand why we are doing things a certain way. I know there is plenty room for improvement but first make an effort to understand the current situation and only then make suggestions for improvement.
- JoeAltmaier 8y ago
  Sometimes a contractor, who has been on lots of jobs and seen everything, can tell immediately that things are not going well. They can see a way out. And 6 months is a long time to watch the walls fall in around you. I'm in such a situation now. A large rambling app that shouldn't be an app, written in a spaghetti style. Ever more features compounded by a boundless bug list, growing daily. All addressed by too small a team, clutching at 'agile' to make some measurable headway. But its a forced march into a gale, and losing ground all the time. Contractors were supposed to come onboard to help retool and redesign. But got roped into bug lists and creeping features and daily standup meetings that take 45 minutes. Work is evaluated solely by 'momentum' and tickets closed and other futile things. So we all turn, turn, turn the crank, because crank-turning resembles work and we're getting paid. Six months are just about up! So what should I do next? Say something now? To whom? These guys are all marching in formation off the cliff, and have no bandwidth to entertain philosophical discussions about the nature of gravity and the sharpness of the rocks at the bottom.
  - maxxxxx 8y ago
    My advice is to first show ability within the current framework. Fix a few bugs quickly, show a good understanding of things. This gives you credibility and trust. Then make your suggestions. A lot of people come in and immediately say "this is all shit" but never prove that they actually have ability. If you are good you can make improvements in the worst code base without having to change everything first.
    - zimpenfish 8y ago
      > This gives you credibility and trust. Then make your suggestions. Many years of experience has taught me that this is 99% of the time useless. If management were listening to suggestions, they'd have been listening to the suggestions of the people already there. But they're not.
      - maxxxxx 8y ago
        I guess I was writing from the viewpoint of a tech lead. In general I don't let management make any technical decisions so if a new idea comes up it can get implemented if the rest of the team agrees. But if someone is new he first needs to show ability first. Too many people come in, want to change to their favorite stack and just trade the current set of problems with a different set of problems.
Cthulhu_ 8y ago
6 months is VERY long though, in software development; if you have a six month trial period (which is also pretty long, although OTOH the more common 1 month here is pretty short), you also kinda have to prove yourself, to show to both your peers and the boss you're an asset. So yes, do start focusing on the actual business and such first, get a feel for the culture. If there's other people that e.g. submit cleanups / refactorings, then point out an issue and ask if you can take a bit of time to clean that up - for example, and assuming you don't have anything more important to work on at that time, etc.
khalilravanna 8y ago
Absolutely agree. I will make the one addition that "6 months" as a time period for that "nascent" stage is actually a variable based on how quickly you can connect to the rest of the team. Size of the team is also a factor on this variable. For example, if you're on a team with 3 other people and you're a generally sociable, like-able, persuasive individual, that time period to ramp up and start affecting change on the team might only be a month. If you're a grouch, you might be looking at closer to 6 months for that same time because it's harder for you to win the team's trust. Nobody wants advice from a mean stranger but they will probably listen to their mean friend. Size of the team is important as well. The example I gave was 3 other people on the team. Building a relationship with 3 people doesn't take a huge amount of time. But how about an engineering organization of 4 teams and 20 people? Well, now that's going to take quite a bit longer. It's also going to be more difficult and complicated as navigating multiple teams, initiatives, interests is obviously an order of magnitude more complexity than one team and 3 people.
toomanybeersies 8y ago
> Don't make any decisions, don't make any improvements to the company process, and don't argue with people I disagree. Do these things, just do them in a subtle manner. Nobody likes someone who comes to a new job and can't stop saying "at my old job we did XYZ in such a way". It's annoying and condescending. Nothing wrong with hinting at improvements though. Trivial example: rather than "we should all be using rubocop", you could mention in passing that rubocop really helps you write clean code.
iajrz 8y ago
There's a risk to this approach. I tried it twice (with ~3 year gap in between), and twice I lost myself and had to re-train to be my usual self. Bad habits are contagious, momentum gets lost. Conformity is a strong force. I've been lucky to have great leadership to learn from and model, and who've taken time to guide me through why things couldn't be fixed at a certain point in time - or plain asked for patience and scheduled time to devote to my concerns. Given good developers are pretty much in demand, I think we can afford to stay true to ourselves most of the time and just shop around for leadership that suits our style.
falcolas 8y ago
> shut up for 6 months and just do whatever you're told I've found it better if I don't shut up, I tend to ask a lot of questions. I still do what I'm told (that's what I'm getting paid for, ultimately), but the chance to ask questions is one that shouldn't be passed up. The trick is that you can't just ask questions as a way to enforce your own will, "Why aren't we using Vault again?", but to genuinely try and understand what's going on. "What's our configuration management strategy?" "What lead to us using X?" And, ultimately, every company is kind of fucked up. Each company is fucked up in a slightly different way. Accept this as your starting point, try and figure out why it's fucked up (your first 6 months), and then try and fix it by working with your co-workers (who, despite working at a kind of fucked up company are probably at or above the median for human intelligence).
- sosborn 8y ago
  Asking questions is an effective strategy - it comes off as wanting to learn rather than wanting to teach.
- SketchySeaBeast 8y ago
  > The trick is that you can't just ask questions as a way to enforce your own will, "Why aren't we using Vault again?", but to genuinely try and understand what's going on. "What's our configuration management strategy?" "What lead to us using X?" Absolutely. Ask questions, all the questions. Just be smart about it. There will be time later to discuss these things, and the company will have reasons. If the reasons are ones you can't live with, get out, but you're not in a position to affect real change at this point. But for me when a junior dev is asking questions, it tells me they are actually invested.
trisimix 8y ago
Lol go king kong on their shit
MattyRad 8y ago
RubyConf 2017: Keynote - You're Insufficiently Persuasive by Sandi Metz - https://www.youtube.com/watch?v=VzWLGMtXflg https://www.youtube.com/watch?v=VzWLGMtXflg
papito 8y ago
As a new person, you may see things that are blatantly obvious to you, sort of this stranger effect, and half of the time you will be right. The other half of the time: * You are just wrong. * The issue is already known to everyone but it has been deemed low priority. * Things may seem wrong but they are that way for a reason. So, pay attention, make a mental note of issues, but don't bring anything up in the first few weeks, as you may look at best silly, at worst, like a whiner.
majormajor 8y ago
Expanding on something I mentioned in a different comment: I wish more managers were up front with the pain points. If I can explain our refactoring/internal improvements road map, and give brief backstory about why the current state is the current state, and save someone weeks or months of "ugh is this code really the best thing we could be doing here?!" context-less fumbling, that's a great tradeoff. I suppose it could backfire, if [new hire] immediately disagrees with my reasoning and comes to the conclusion that I'm just an idiot who's bad at that stuff, but is that really going to be worse to hash out some on day 3 instead of day 40? If [new hire] turns out to be an asshole who isn't open to other people's opinions, let me find that out ASAP.
factsaresacred 8y ago
> Without knowing the full story, who knows what actually happened there Without knowing the full story, who knows what actually happened there. Chesterton's fence: In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it." https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
- deleted 8y ago
  [deleted]
brandmeyer 8y ago
The flip side, is that this is how deviance is normalized. https://danluu.com/wat/ https://danluu.com/wat/
jamaicahest 8y ago
>While I know I made many mistakes, I believe I was not the only one who did... but I was the one on probation... so... so long and thanks for all the fish. Author seems somewhat arrogant, one of the worst personality traits in my opinion. Hard to be liked if you're arrogant.

by volgo 8y ago

0xcde4c3db 8y ago

No kidding. As someone who has a good bit of difficulty with social interaction (no diagnosis, but it overlaps with issues that ASD and ADHD people often report), I've failed a likability check or two in my time. I've had conversations where someone seems to be offended or otherwise put off and I have no idea why. But even having those problems, I don't discount other people's opinions and priorities so much that I'd just go in and refactor an existing system without first being pretty clear on who's responsible for it, what problems I'd be solving and risks I'd be creating for them, and that they're okay with it.

maxxxxx 8y ago

"shut up for 6 months and just do whatever you're told. " I like this one. I see a lot of contractors come in and write code that doesn't fit with the rest of the code base. They don't make any attempt to understand why we are doing things a certain way. I know there is plenty room for improvement but first make an effort to understand the current situation and only then make suggestions for improvement.

JoeAltmaier 8y ago
Sometimes a contractor, who has been on lots of jobs and seen everything, can tell immediately that things are not going well. They can see a way out. And 6 months is a long time to watch the walls fall in around you. I'm in such a situation now. A large rambling app that shouldn't be an app, written in a spaghetti style. Ever more features compounded by a boundless bug list, growing daily. All addressed by too small a team, clutching at 'agile' to make some measurable headway. But its a forced march into a gale, and losing ground all the time. Contractors were supposed to come onboard to help retool and redesign. But got roped into bug lists and creeping features and daily standup meetings that take 45 minutes. Work is evaluated solely by 'momentum' and tickets closed and other futile things. So we all turn, turn, turn the crank, because crank-turning resembles work and we're getting paid. Six months are just about up! So what should I do next? Say something now? To whom? These guys are all marching in formation off the cliff, and have no bandwidth to entertain philosophical discussions about the nature of gravity and the sharpness of the rocks at the bottom.
- maxxxxx 8y ago
  My advice is to first show ability within the current framework. Fix a few bugs quickly, show a good understanding of things. This gives you credibility and trust. Then make your suggestions. A lot of people come in and immediately say "this is all shit" but never prove that they actually have ability. If you are good you can make improvements in the worst code base without having to change everything first.
  - zimpenfish 8y ago
    > This gives you credibility and trust. Then make your suggestions. Many years of experience has taught me that this is 99% of the time useless. If management were listening to suggestions, they'd have been listening to the suggestions of the people already there. But they're not.
    - maxxxxx 8y ago
      I guess I was writing from the viewpoint of a tech lead. In general I don't let management make any technical decisions so if a new idea comes up it can get implemented if the rest of the team agrees. But if someone is new he first needs to show ability first. Too many people come in, want to change to their favorite stack and just trade the current set of problems with a different set of problems.

Cthulhu_ 8y ago

6 months is VERY long though, in software development; if you have a six month trial period (which is also pretty long, although OTOH the more common 1 month here is pretty short), you also kinda have to prove yourself, to show to both your peers and the boss you're an asset. So yes, do start focusing on the actual business and such first, get a feel for the culture. If there's other people that e.g. submit cleanups / refactorings, then point out an issue and ask if you can take a bit of time to clean that up - for example, and assuming you don't have anything more important to work on at that time, etc.

khalilravanna 8y ago

Absolutely agree. I will make the one addition that "6 months" as a time period for that "nascent" stage is actually a variable based on how quickly you can connect to the rest of the team. Size of the team is also a factor on this variable. For example, if you're on a team with 3 other people and you're a generally sociable, like-able, persuasive individual, that time period to ramp up and start affecting change on the team might only be a month. If you're a grouch, you might be looking at closer to 6 months for that same time because it's harder for you to win the team's trust. Nobody wants advice from a mean stranger but they will probably listen to their mean friend. Size of the team is important as well. The example I gave was 3 other people on the team. Building a relationship with 3 people doesn't take a huge amount of time. But how about an engineering organization of 4 teams and 20 people? Well, now that's going to take quite a bit longer. It's also going to be more difficult and complicated as navigating multiple teams, initiatives, interests is obviously an order of magnitude more complexity than one team and 3 people.

toomanybeersies 8y ago

> Don't make any decisions, don't make any improvements to the company process, and don't argue with people I disagree. Do these things, just do them in a subtle manner. Nobody likes someone who comes to a new job and can't stop saying "at my old job we did XYZ in such a way". It's annoying and condescending. Nothing wrong with hinting at improvements though. Trivial example: rather than "we should all be using rubocop", you could mention in passing that rubocop really helps you write clean code.

iajrz 8y ago

There's a risk to this approach. I tried it twice (with ~3 year gap in between), and twice I lost myself and had to re-train to be my usual self. Bad habits are contagious, momentum gets lost. Conformity is a strong force. I've been lucky to have great leadership to learn from and model, and who've taken time to guide me through why things couldn't be fixed at a certain point in time - or plain asked for patience and scheduled time to devote to my concerns. Given good developers are pretty much in demand, I think we can afford to stay true to ourselves most of the time and just shop around for leadership that suits our style.

falcolas 8y ago

> shut up for 6 months and just do whatever you're told I've found it better if I don't shut up, I tend to ask a lot of questions. I still do what I'm told (that's what I'm getting paid for, ultimately), but the chance to ask questions is one that shouldn't be passed up. The trick is that you can't just ask questions as a way to enforce your own will, "Why aren't we using Vault again?", but to genuinely try and understand what's going on. "What's our configuration management strategy?" "What lead to us using X?" And, ultimately, every company is kind of fucked up. Each company is fucked up in a slightly different way. Accept this as your starting point, try and figure out why it's fucked up (your first 6 months), and then try and fix it by working with your co-workers (who, despite working at a kind of fucked up company are probably at or above the median for human intelligence).

sosborn 8y ago
Asking questions is an effective strategy - it comes off as wanting to learn rather than wanting to teach.
SketchySeaBeast 8y ago
> The trick is that you can't just ask questions as a way to enforce your own will, "Why aren't we using Vault again?", but to genuinely try and understand what's going on. "What's our configuration management strategy?" "What lead to us using X?" Absolutely. Ask questions, all the questions. Just be smart about it. There will be time later to discuss these things, and the company will have reasons. If the reasons are ones you can't live with, get out, but you're not in a position to affect real change at this point. But for me when a junior dev is asking questions, it tells me they are actually invested.

trisimix 8y ago

Lol go king kong on their shit

MattyRad 8y ago

RubyConf 2017: Keynote - You're Insufficiently Persuasive by Sandi Metz - https://www.youtube.com/watch?v=VzWLGMtXflg https://www.youtube.com/watch?v=VzWLGMtXflg

papito 8y ago

As a new person, you may see things that are blatantly obvious to you, sort of this stranger effect, and half of the time you will be right. The other half of the time: * You are just wrong. * The issue is already known to everyone but it has been deemed low priority. * Things may seem wrong but they are that way for a reason. So, pay attention, make a mental note of issues, but don't bring anything up in the first few weeks, as you may look at best silly, at worst, like a whiner.

majormajor 8y ago

Expanding on something I mentioned in a different comment: I wish more managers were up front with the pain points. If I can explain our refactoring/internal improvements road map, and give brief backstory about why the current state is the current state, and save someone weeks or months of "ugh is this code really the best thing we could be doing here?!" context-less fumbling, that's a great tradeoff. I suppose it could backfire, if [new hire] immediately disagrees with my reasoning and comes to the conclusion that I'm just an idiot who's bad at that stuff, but is that really going to be worse to hash out some on day 3 instead of day 40? If [new hire] turns out to be an asshole who isn't open to other people's opinions, let me find that out ASAP.

factsaresacred 8y ago

> Without knowing the full story, who knows what actually happened there Without knowing the full story, who knows what actually happened there. Chesterton's fence: In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it." https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

deleted 8y ago
[deleted]

brandmeyer 8y ago

The flip side, is that this is how deviance is normalized. https://danluu.com/wat/ https://danluu.com/wat/

jamaicahest 8y ago

>While I know I made many mistakes, I believe I was not the only one who did... but I was the one on probation... so... so long and thanks for all the fish. Author seems somewhat arrogant, one of the worst personality traits in my opinion. Hard to be liked if you're arrogant.