If everyone else is wrong, and only you are right, what does that tell you?
Maybe you are the outlier that moves fast and breaks things, while the rest prefer sustainable progress over the long periods?
Ask HN: How to deal with 0.1X programmer colleagues?
61–70 of 108 posts
Re: Ask HN: How to deal with 0.1X programmer colleagues?
#62Your mistake is caring. Are you being rewarded for working much harder than your colleagues? Are they being punished for working hardly at all? Why are you working hard for the benefit of the company's bottom line? It's a big company, why do you care about its bottom line? Your colleagues have the right attitude. They are doing the absolute bare minimum to collect a paycheck and go home. I suggest you do the same. Ca…
I need a job I can care about or else I struggle to do the work.
Right now this is unbearable for you but getting angry with your colleagues is just going to make it unbearable for everyone.
Spending your passion on your own projects or OSS will yield you better returns 9 times out of 10.
Re: Ask HN: How to deal with 0.1X programmer colleagues?
#63How can you be so sure all your colleagues are useless? Are they doing any important but non-flashy work (planning, documentation, cleanup, etc) that isn't captured by the "story point" metric, which is a pretty bad tool to gauge productivity anyway?
Keep in mind all of that important but non-flashy work can also be used as a cover for not doing anything of consequence. Yes, sometimes it is important, but 70% of the time when I see someone has been "planning" they've done absolutely jack... (Recent example: How can a PM plan a software engineering project without talking to the people actually doing the work? Then they wonder why the "plan" makes no sense...)
Re: Ask HN: How to deal with 0.1X programmer colleagues?
#64Hey but what if your colleagues are busy putting out fires your “productivity” is causing? Thought about that, huh?
In teams bound by certain process, whatever reason they may have, and that process may well be stupid, but it is there and agreed upon, the velocity is usually adjusted within a few sprints such that it’s mostly even. Outliers this big are a smell, and whoever is the outlier is suspect.
Maybe your definition of what a story point is off the mark. Maybe their stories require lots of yak shaving. Maybe it’s what I said in the beginning. But in general I won’t for a second buy that the whole thing keeps ticking because of your valiant effort and they all are lazy asses. This is easily provable by your going on an extended leave. Either you come back and it’s all unmoved or ruined and they are indeed bumbling lazy asses, or your effort don’t move the needle as much as you think they do, or they all deliver more because you’re not there.
Re: Ask HN: How to deal with 0.1X programmer colleagues?
#65Stop defining yourself by your work, unless you actually reap the benefits of all of your work. Stop judging your colleagues for not having the passion you do, unless you hired them yourself.
Don't feel guilty slacking off, unless it's your business.
Re: Ask HN: How to deal with 0.1X programmer colleagues?
#66In addition to what everyone else is saying, it's possible that your way of working just may not be compatible with this company. And that's perfectly fine. When you move to a new place, try to find a way to screen better for this during the interview process.
Re: Ask HN: How to deal with 0.1X programmer colleagues?
#67I used to manage a developer whose claim to fame was how many "story points" they crushed. There was no rhyme or reason to their work, they would never say no to anything, and it didn't matter if their changes caused performance regressions or added broken windows to the code base: closed was closed and nothing else mattered. Working with them was difficult: they saw themselves as this productivity machine but the rest of the team was dealing with all of the extra work their productivity brought: more outages and incidents, code complexity, etc.
I can't tell if that's what you're doing but it was a good lesson for them to think more strategically and be focused on what matters to the team and to them. Being able to deliver and make progress at a reasonable pace is a good thing but, in our case, delivering lines per hour was not the metric we were measuring.
Maybe what you need to do is have an honest conversation with your team or team lead. What does the team value? What are the expectations?
Update: fixed spelling/grammar
Re: Ask HN: How to deal with 0.1X programmer colleagues?
#68"It's a marathon, not a sprint". I've only ever heared this phrase working for a big corp during my first large incident response engagement. Having worked both at startups and large organizations, I can tell that there are two extremes and neither are healthy. It seems like you got used to the constant crunch time that startups use to burn faster through their usually young human resources. From my experience, noone…
Then they proceed to call the samn things “sprints” and except us to do them back to back to no end
A "sprint" when managed well, doesn't need to mean working tirelessly the entire period. One of the features of sprints is a way to avoid scope creep by imposing a deadline. I would argue that generally the more appropriate response to not meeting a sprint deadline is more often to cut scope than to insist than to insist devs put in extra hours.
Re: Ask HN: How to deal with 0.1X programmer colleagues?
#69I work at a small'ish company of few FTE (~10 members and handful of interns/ residents). I am basically the most senior non-C level member within a relatively flat management hierarchy (by design).
I handle a small corner of product development i.e. B2B 3D asset development from multimedia. Every weekly meeting my progress report is modest. You might bin me into that 0.1x engineering member.
Yet, I could tell you I remain quite busy. 33% of my time goes into product development. The other 67% are into quasi-employee management tasks (quarterly performance checks, their salary/bonus/increments, merging their code branches, keeping tabs on infrastructure), Capital generation (meeting investors, putting engineering-sensible business plans, correspondence etc) & PR (showing up at conferences, keeping updated with latest tech by reading papers, building professional networks to access talent/ investors/ experts on corp's behalf.)
If looking at purely my LOC, I probably add half or a third of the average guy right now. I know it could be better - and I keep trying to improve my IC role. But the message I want to let know is: A lot of things are going on without others being plastered with updates. And that happens with gradual seniority in org chart.
Do I miss my TopCoder days? Yes absolutely. Will I start doing that now? Probably not. Someone has to help run the engineering team. All that coding might is useless if we run out of workplace cohesion and investor money. And I am uniquely positioned to do that. I would like to see the team run rumbling along rather than few Usain Bolts sprinting in their chosen directions.
Re: Ask HN: How to deal with 0.1X programmer colleagues?
#70You sound like a very competitive person. You might want to consider that a lot of software development is actually the navigation of socio-technical systems. Heavy emphasis on the socio. Your competitive drive isn't bad, but it might lead you to local optima in your career in the long-run.
How do you get things done in a larger organization? At AWS it's solved by having APIs and documentation for everything. This leads to a janky UI, a lot of redundancy in their systems, and a pretty bad work environment from what I hear.
In a lot of technical organizations, this problem is solved instead informally through relationships between members of the organization. You want to get something done outside of your constrained contexts? You'll probably need some relationships. Getting a lot of cards done is great, but if you're pushing too hard all the time you're going to sour those relationships.
What I'm saying boils down to this: being a developer in a large organization is about 1-3 parts coding to 7-9 parts communication and relationships. Further, if you spend time communicating you can often realize that the feature you're implementing was already implemented two years ago and there's just a regression that's caused the line of code to no longer be executed.
You can say fuck it to the communications with your peers if you'd like. However, keep in mind that most of your jobs as you become senior are going to come from referrals from former colleagues. Your boss right now isn't going to help you get your next job–the people sitting around you might.
Consider reading [non-violent communication](https://www.amazon.com/Nonviolent-Communication-Language-Lif...).