Ask HN: What to do if I'm a bad fit for dev team?
I have 5 years of experience writing ML software and working with distributed systems for large-scale data processing (10s-100s of TBs).
I have some hard-won experience, but I am by no means done learning. I try to be open-minded, and I've accepted that there's no way I'll ever truly be an expert in every aspect of SW engineering.
Four months ago, I joined a new team at a new company (my previous tech was purchased, and I wanted to move on to other projects). Writing code with this team has been a really difficult experience. Every change that I make I get pep8'd and abused on style. With each PR that I make, a long thread (>50 back-n-forths) ensues with comments like "let's put the calls in this file instead of that file", "let's actually put the code here in this file", "your code should be under 80 characters long", etc. What's annoying is that this codebase is a mess, and these comments appear to me as hazing as they are not uniformly applied to others: lots of inconsistent styles; really complicated class hierarchies; major violations of YAGNI; major violations of pep8. The codebase size is <3K LOC, and I've worked on codebases with 100Ks of lines; so it's really frustrating to deal with the nitpicking on something that seemingly wastes everybody's time, and doesn't provide opportunities for growth or learning.
So being a good new employee, I've asked for a style guide and was handed this link: https://www.python.org/dev/peps/pep-0008/. I've been programming in python for 10 years, and I just found this to be insulting. I've worked on projects that are orders of magnitude more complex than the current one; and yet none of my experience matters, and I feel that I'm being viewed as a junior since I've been given smaller and smaller "projects" (if they could be called that) to work on.
I believe that my teammates see me as a bad apple. I want to do something constructive here, but I'm feeling pretty bruised and confused.
Thanks for any advice. You should probably examine really closely why they do this. My hypotheses are: 1. They are doing it to purposely be unproductive. It's like in school where kids would ask the smartest kids in the class to bring down the grading curve by telling them to relax or hang out more. <3k LOC supports this theory, which is absurdly small for a team that's been around for a while. 2. They see you as a threat. This could be for the above reason, it could be because of your background. The hazing and insulting comments support this. This might also go into a lot of things that you haven't mentioned. Like some people saw me as a threat when I was the only developer who didn't have to work at the office. It might also be that you're staying in later or coming in earlier, skip lunch, aren't going out on drinks with them, aren't engaging in some workplace ritual. Hypotheses should be tested, then you can work on solving the problem. I would recommend the Benjamin Franklin approach. Ben was ambitious, but he was bad at reading people early in life. He was screwed multiple times for standing his ground or proving that he was right. He eventually learned to roll with the punches, to fit in even though he thought it was wrong and unproductive. You probably want to quit later, but it might be a good exercise to find out what you're doing wrong so you don't face the same issue in the future. I would add, as I have lived that in other teams : Don't expect that people do what is mentioned above consciously. It might be a layer below the surface, and they probably do not feel like they are doing this on purpose. Thanks! Do you have any suggestions for Ben Franklin biographies/books? I got it off Robert Greene's Mastery, the chapter on people being an obstacle to mastery. Try his autobiography. Adding to some great suggestions ... Sometimes there is no reason to waste time fighting or/and adjusting. Move on and find another team that would appreciate what you have to offer. If you have so much experience you may have a few people to reach out to for connections. Slowdown and listen. Do you hear this loud sucking sound? It's the demand for software developers. There is a ton of examples in competitive athletics and other areas of human endeavors when someone was unappreciated in one situation and super successful in another. Still, before you leave, learn as much as you can about the situation, so, if for no other reason, you could recognize it before joining. 1. Don't fight over unimportant things. Setup flake8 with all the plugins, maybe use yapf, try to make the coding style issues just go away. 2. Try to figure out why this is happening. There's usually a reason. Most likely it's managerial incompetence, but maybe not, and even if you can't figure out a solution being able to identify the problem is a useful skill (and might help you minimize conflict). 3. Try to switch teams. If that doesn't work, start thinking about switching jobs. This is a tough situation to be in.
In my opinion, there are two ways of dealing with it
1) Escalate to reliable competent authority - Tell them whats the problem
2) If (1) does not work, its just a caustic place to work, get a project change or change companies. These situations deteriorate fast, and its difficult to get out of them. I had a similar experience about 2 years ago. I joined a team and my first pull request had more comments than my commit had LOC. There was a comment each for two libs I pulled in asking what the licenses were. Opinionated but forceful suggestions that were matters of taste. No actual issues with functionality or performance. I just emailed the manager and said based on the first interaction with this particular team member it wasn't going to be a good fit for me and left on day 2. Some people just don't like to collaborate and they want your hands out of their sandcastle. Sometimes, teams just suck. You can waste your time trying to fix it or you can move on. If you have no skin in the game, I say you should move on. For instance, I've been shopping around for a new job and had a CTO of a decent sized ~30 person engineering team told me during the interview that their standards for testing is "get it working" and "test on staging." If basic unit tests are a luxury around here, how do you expect to grow and become better devs over time? I would argue with them to the usefulness of their practice. Like, use Pareto principle. Some coding style is useful and should be agreed upon. Some code review is useful. But beyond that (whatever is beyond for the particular team) is useless.
If they are stubborn and you don`t like it there, move on. You may be able to refute their recommendations with this video where Raymond Hettinger sympathizes. https://www.youtube.com/watch?v=wf-BqAjZb8M funny, I started to post this as a response in one of those epic PR threads, but then deleted it because I didn't want to be inflammatory. Being new to the team and in this unfortunate position, I think it may be wiser to just roll over than fight. I'm in this unfortunate mode of minimizing the interaction if I can. Maybe you've chosen the wrong job? You claim to have oodles of experience. Both technically (as a 'coder') but based on some of your other comments, also an architect and even a people manager. What does your manager/iteration manager think? Are they feeding you the same feedback? It's only a matter of time until it bubbles up to them so figuring out a plan might be appropriate. When I first joined, I was working on a decent-sized project that required interfacing with other teams. My mode of development has always been to ask lots of questions, even if they're "dumb". I like "dumb" questions because it gets everyone on the same page, and it narrows the conversation. It's worked out really well in the past; I really believe in communicating early and often. During my first week, I started down this path. I made comments in our chat, and was quickly told by my manager to take it offline. I was told that I shouldn't be "opening cans of worms" with other teams. So I had to be more discrete about understanding my new role, and figuring out Where the Bodies Were Buried in more round-a-bout ways. That's the only direct feedback I've gotten from above; this is dysfunctional right? From your description it does look like some sort of hazing ritual - you aren’t junior in technical competence but your are junior in political and social experience in this company and they are “teaching” you what is socially acceptable in this company. Either you are or want to be a similar kind of person and appreciate their efforts or you aren’t or don’t want to be and plan your exit. Before you think about whether you are technically appropriate for the job you must think whether you are socially appropriate for the company. Your life is way too short to spend a third of it pretending to be someone else, so be at a company where you feel like you’re chilling when you’re talking with colleagues. Sounds like you've joined somewhere that has already long drawn-out political battle lines. It would probably take years to figure out what the history is behind this. I suspect the difficult time you are having is likely because you are either boy who notices the emperor isn't wearing clothes, or it's because you've landed on one side of a political landscape. I've been here before, and you also have to be careful of who you get support from as well. To be fair, most workplaces have history to some degree or another. If you are able to keep your head low and excel at the tasks you've been given without showing others up, you'll do well and might even be able to make a clean escape! Yeah this sucks - opposite to my current role I used to DM people on slack and the tech lead told me to keep it in the appropriate dev channel because all questions are important to everyone and everyone should be able to chime in. I'd look for an exit plan - good luck! Yeah it's bad news bears. Save yourself. Leave as soon as possible. You won't regret it. Adhere to the style guide and make sure you remind others when they violate it. These debates are why golang and it's gofmt are so great :)