Ask HN: How to deal with 0.1X programmer colleagues? | Hacker News Reader

Ask HN: How to deal with 0.1X programmer colleagues?

51 pointsstartupfreak104 comments

I worked at tech-team-of-one startups for years. Now I'm working at a big organisation.

In the last sprint, I chalked up 41 story points. The rest of the team (3 other devs and a mostly hands-off tech lead) collectively achieved 9 story points. That's 1 medium-sized ticket each over the space of a fortnight. Everyone has a good excuse, but they ALWAYS have a good excuse.

It's driving me nuts. I'm a good coder, but this isn't about me being good, this is about them all being, on paper, completely ineffective. No one inside or outside the team seems to be batting an eyelid about this. I feel resentful and... confused.

It's hard to stay motivated when the bar is so low, but I would feel guilty slacking off all day. What do I do?

View on HN

Questions to maybe consider:

* If you're relatively new, are they giving you starter tasks?

* Are the other team member's tasks harder, less-straightforward, involving less-familiar tech, slowed/blocked by dependencies, less amenable to just crunching through mechanically, etc.?

* Are the other team members doing higher-quality work? (A big corp. might have very different ideas of what software engineering is than you did in a one-person-tech-team startups. Are you a one-person tech debt machine?)

* Do the other team members have more responsibilities separate from this code?

* Is the team in a catch-your-breath period, after a big push to ship something, and people also taking summer vacations, etc.?

* Is there a morale problem going on that you haven't picked up on? Were there layoffs recently? Or do people know something you don't know, like that the project is going to be canceled? Is this a team or company that people want to be in? Is everyone interviewing or practicing Leetcode?

* Why is the tech lead or people manager not on top of this, if it's a problem? (Or maybe they are, but they're handling it discreetly, one-on-one with people, rather than embarrassing people in front of the team?)

These questions also suggest one way to broach the topic with a tech lead or people manager, if you don't yet know whether it's safe to speak more candidly: you could ask how your work is fitting the conventions of the organization, are you blowing through tasks too quickly, is there something you should be doing differently, etc.

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

As a PM, I find it best to put together a straw man project plan before I talk with people, then revise it progressively as I talk with people. Not always, but it's often a good idea, particularly if the project crosses multiple departments or companies. Sometimes I can't get everyone in the room at the same time. Sometimes (often) people will see their own team's area of work as being the main focus, while I have to coordinate with other groups, while trying to minimise the "hurry up and slow down". Sometimes there is a need to get people started on the bits we know about and accept that other bits will need changing. And sometimes you need to get the person responsible to estimate the length of the piece of string, and putting up a wrong estimate is a good way to get an answer.

I'm sure everyone is thinking "agile" now. Yes, I was in to that back when XP was the thing. But it only works for some sorts of project, typically where there is only a single company developing a project, and the customer is internal. If you have a big contract with specific deliverables, a contractual time line, multiple organisations, and perhaps large non-sw parts, you often find that you have to start planning even before the developers are engaged, then accept that some of your assumptions will be wrong.

I hear your point but I wouldn't dismiss the op point, those situations do happen.

In this case the problem could be just miscommunication, it's worth asking some help from the team

Realistically shouldn't those tasks be given story points too if they're done separaterly from the team?

I'm not sure why you're getting downvoted. At least when I was working for a contractor in the automotive industry, these kind of tasks where measured in story-points as well since story points roughly translate into paychecks.

I 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

Are you sure that's all they are doing?

When a new coder joined our team they always got loads done as they were left to completely concentrate on their work on the board. Meanwhile, the rest of the team where dealing with support requests, sales requests, pulling stats from the database for random execs, security audits, fixing the build system (again), CV reviews, design documents, code reviews, customer requests, 20 email or slack chains that they are somehow on, invites & menus for the staff party, …

You’re probably optimizing for the wrong metrics. Look at the people that are promoted quickly and copy what they are doing.

It probably isn’t number of JIRA tickets.

This is the right answer if your goal is make more money (which it probably should be). Other right answer is find a place that rewards based on JIRA tickets if you want to be a highly productive programmer.

This makes a few assumptions while not answering the question or even really understanding what OP has to say.

They don't seem to be bothered about promotion. More that they think they're doing a lot more work than everyone else.

I guess I don't understand the frustration. Why does OP care if they are "working" more than everyone else?

It's quite common for high performers to be annoyed by low performers. Often, they feel like they're having to cover for the low performers and are doing work they would normally not have to do if it wasn't for low performers.

Clearly OP is able to complete 41 points per week. If low performers also did 41 points per week, are you saying OP wouldn't do 41 points per week?

Assuming tasks are unlimited, to OP's perspective, the entire team should be doing 41 points. It isn't that he is doing 'their' work.

I think OP is upset that he delivers more work, but is still paid the same. Companies reward the extra work via promotions and bonuses.

I didn't see this observation in the comments so chiming in. Your 'team-of-one' comment resonated with me. Another way to frame what you're saying is that you're years behind when it comes to professional development working together on a team of engineers.

The phrases 'driving me nuts' and 'them being completely ineffective' are what reinforce this view, to me at least. They may be working far less hard on the code than you are, but it sounds to me like you're working far less hard on being a good teammate and given your history that may take time.

To be completely honest it sort of sounds like you're taking stimulants and they aren't, at least from the way you wrote this up. Get in, get good work done, get out. If you work remotely, all the better. Do some laundry, read a book. Meet and exceeding expectations sounds like about half of what you're getting done and getting worked up about (which I assume is tanking your mood into your evenings).

Focus on the soft skills and be a part of raising your team's morale (yourself included) rather than torpedo-ing it. I suspect the look on your face in some meetings says everything you wrote up here already.

Before you attempt to do anything, first try to assess whether your organization and/or management has a strong “don’t rock the boat” culture. In my experience, an isolated contributor moving super slow might be down to the individual, but a whole team moving slow is usually due to systemic factors.

Attempting to create accountability or meaningful changes to velocity in a “don’t rock the boat” org is usually a one-way ticket to workplace politics hell. If you value building things, small-startup style, you will likely want to avoid this.

Finding a good manager who is willing to give you special-mission style projects to execute on quickly and effectively is often a far better strategy than trying to deal with widespread molasses speed dev culture. Even better, typically, is moving to an organization where the culture and peers match up better with your desired speed and quality of execution.

I'd agree. If the organization is dysfunctional, there's nothing you can do. These problems start at the top.

This is how big orgs ALWAYS work. You have to get used to it or go back to the startup trenches.

The startup pace can be grueling, it can have terrible hours, it can be unrewarding, but at least you're always working. At big orgs with plenty of funding you just sort of marvel at how so many people can accomplish so little. Everyone is always blocked by another team or some arcane bureaucratic process. It never ends and it never gets better.

The good news is you're probably well compensated and have complete job security. The bad news is you're at heightened risk for existential crisis.

The other aspect of it is that with a big company, it's often much more about choosing what is valuable to work on vs. just doing everything you can put your hands on. Large organizations generate large numbers of requests and suggestions, many of which aren't worth anyone's time. You're usually not working on a project where you're needing to add new features or fix bugs ASAP or else the company disappears. The low-hanging fruit of time spent to value created has already been picked years or decades ago.

Ironically, part of the point of having so many people accomplish so little is agility. It's the HR equivalent of owning a gigabit internet line when you're mostly browsing HN and checking your email. Most of the time, it's a waste and no doing anything for you, but when you need it, you don't want to be calling your ISP to try to upgrade. Having tens of "hot spare" engineers who are already used to the product and system who can jump on a big product need on a week's notice can be worth paying them the rest of the time to do very little.

It doesn't mean you're going to feel like you're solving amazing problems every day, but it doesn't mean those other engineers aren't sharp people who can get through a meaningful ticket when it needs to be done. They just know when it doesn't need to be done.

Talk to your manager or find a mentor within the company and ask for advice. Rather than framing it as “my colleges are all slackers” frame it as “what am I missing?” At big tech orgs success can mean a lot more than coding. It’s possible you are not doing things the others are doing… writing specs, documenting, interviewing, planning, etc. the bigger the engineering org the more time spent communicating. It may be they are doing more testing than you as well. It may be that this isn’t for you and you should return to the world of tiny teams where you really can code all day and “feel” much more productive because the communication overhead is so low.

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

Caring about your job is only acceptable if your labor is sufficiently rewarded, you own the company, or if it's some kind of non-profit or public service job that actually benefits society. If you're working for a for-profit organization, the goal is not to work hard, but to be exploited as little as possible.

I made the same "mistake" this person did. Companies didn't reward me. But you know what? I kept improving, they didn't, and I was eventually able to launch my own company while they stay stuck in that job. Obviously companies should reward us for doing better, but, when they don't it still doesn't mean there's no potential benefit from "practicing" doing good work while at work.

That's a great solution to the "mistake" for you. And while it's great to be able to launch and run your own company, not everyone wants the stress that comes with that. I've also "practiced" skills at work to improve myself, though I haven't launched a company.

I've also worked with many colleagues who were great at their jobs, but that's all it was for them - a job. Their passions (which was sometimes just their family) lied elsewhere. They were just working to support that and were perfectly happy with their lives. I wouldn't try to take that from them.

> Caring about your job is only acceptable if…

This suggests that it's unacceptable to care about doing your job well because you enjoy it or simply because your morals compel you to work hard at what you do. I don't think there's anything wrong with someone choosing to work hard for these reasons if that's their choice.

This is a terrible take, if you are passionate about your work then those 8 hours go a whole lot quicker. If you’re not passionate then I would question if the position is a good fit

I used to be passionate about coding at work, that gave me my first job, then my second, then some startups, big cos, and so on. At some point it doesn't really matter to try to keep yourself passionate about your job, you get enough experience, and you've seen how the maturity cycle of almost any tech company goes, in a general sense. At that point my passion for coding as a job disappeared, one just need to perform it well, professionally, and deliver what's expected of you for being paid to do it.

Is it nicer to work in a product/organisation you are passionate about? Of course, it doesn't mean this passion will last, or that it will be rewarded, or that it will even be healthy for you (one of the jobs I burned out from was exactly the one I was the most passionate about).

Building products follows the same patterns, even if the underlying technologies are different, or if you work on a product in a very different market/industry. It becomes all more of the same: store data somewhere, pull data from somewhere, transform some data to some other format, write some business logic, develop an interface, develop an application (web, desktop, mobile, embedded), deploy your systems at some server, monitor your systems (or implement telemetry if working embedded). You don't need to be passionate to work like that, you just need to be professional.

By doing that you also avoid the common pitfall of being exploited because of your passion.

I don't think you necessarily disagree with them. The issue is most people don't have the option to find a position that's a good fit. Or you find out the companies with a mission you're passionate about have a work culture that you're not.

If you're only working places you're passionate about, you're really winnowing the field of possible employers. I say this as someone who's working at a company I generally respect and am passionate about the product of - I think more than most of my friends who work in the field are about their work. If I wanted another job, there's not a huge pool of companies I would even want to apply to.

If I lose my job, or quit, then I'm often going to need to apply and work somewhere that's not a good fit. I can hold out for a bit without a job, but there's no promise that another company I'm also passionate about is hiring for any position I'm qualified for. At the end of the day, I'd generally rather be programming somewhere I don't love than working as a bartender or delivery driver.

People have to eat. Not everyone has a passion in the working realm. My passion would be to make music. I don't think I have the commercial instinct or drive to make a living out of it. Also, that might just destroy my passion.

But you're right though, when I am in flow, those 8 hours go by a lot quicker :)

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

We don't know that. That's one stereotype theory that comes to mind when we hear "big company", but that's not the only plausible explanation.

Also, some people told to do the bare minimum at their jobs will think "Alrighty!" But the same advice could be very counterproductive for people who take pride in their craft or professionalism, or who want to see the mission happen. Those people should be nudged towards improving their situation (either at the current place, or somewhere else), not destroying their strengths.

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.

You confused me for OP.

I spend most of my free time with housework, socializing and hobbies but there just isn't enough meaningful stuff I care to do outside of working hours to overcome the 8 hours a day of meaningless work I do for my employer.

It’s clear other people are able to manage but I have been trying for years and all I ever manage to get out of it is depression.

I just can't do meaningless work for 8 hours a day.

One can care about their job without caring what their peers are doing. Do your work, do it the best you can, and let management deal with everyone else (or not).

Sure, but the point made by the person I replied to was that you shouldn't care about your job. Also, it's normally quite difficult to do a job which requires collaboration when other people don't care about it. Likewise, it becomes difficult to not get burned out if you care about a job and your employer doesn't recognize and reward this.

I think overall my objection is to blanket advice I've heard during my life about how much care I should put into my work. I have never been able to be effective (and as a result have had issues with) doing meaningless work which I didn't care about. I have also had issues with continuing to care about work which people I work with didn't care about.

It's clear that a carefree approach works for some people but in this case it seems like better advice for OP would be to explain how to find jobs where people do care rather than trying to tell him (and other people in that situation) to just deal with it.

Passion can be good, but it must also be measured. I was in a similar situation for several years where I ended up running the show. Was super passionate about the project and doing all the things...

Ended up horribly burnt out, to the point that I'm still struggling with the idea of working 2 years later.

You are asking how to change the culture at a big organization. It is not possible unless you are C-Suite. This is true of most smaller organizations as well, though in smaller organizations the C-Suite may be more accessible.

This is the time to work on yourself. Do not let your team change you or slow you down. Do the work required, improve your skills, and go find a better team.

By the way, it sounds like you are frustrated with how companies work in general. You should read this excellent essay: https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-....

Under this loser/clueless/sociopath framework, the skilled engineers at many organizations (including yours, it seems) simply are highly paid "losers" with cushy benefits (I do not mean this as a personal insult!). Your colleagues may have an experience-driven grasp of this and are acting rationally, in a way.

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

Mature companies can't afford being as fast as startups simply because their different size causes 1) a completely different level of decision inertia, 2) a completely different level of communication issues.

You're not working with 0.1X colleagues, you're working at a 0.1X company. If that's too slow for you but acceptable for your manager, talk with them about it; in the best case, consider yourself free to spend the henceforth-saved time doing something else.

Take more time into learning technologies and stuff you find fun and call it work. It actually is work, but employers don't tend to see that. Make coding fun for yourself.

Everyone works slowly at a big company. What you should do is try to see how you can leverage your contributions to grow faster. People not only work very slowly at big companies, but saying something like that might land you in HR issues. People will work at different pace, and the company has decided that their pace is acceptable too. Just ensure that you get credit for your own work and rise fast.

"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 can sustain that pace without getting burned out or/and (willingly) compromising on their spouses and personal connections outside work.

Looking at the bigger picture you might realize that there are different point of views what progress means. In big corp it's usually about getting rid of/around obstacles, while startups focus on growth, happy VCs and other metrics that mean very little to a big corporate machine that by itself got enough intertia to keep moving even if it doesn't hit those metrics.

Conversely if your current business is running on billable hours. Finishing earlier and providing unrealistic client expectations might activly hurt your employer.

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.

Wish that ever happened. We just add shit to our sprint and yell at devs when they are burned out.

Unfortunately, that does of course that does happen a lot. My point was that I think working sprints doesn't necessarily mean overworking.

A formula 1 race car is _much_ faster than a freight truck. However a freight truck can deliver a lot more goods across the country than an F1 car. Which is your big organization optimizing for?

I'm guessing you enjoy doing the work of writing software, because I think most people who are productive like that do.

So I agree with you that "just do less" is not a good answer, and will not actually lead to satisfaction. The risk is not only guilt, but even worse, the soul-destroying feeling of being a useless person just keeping a seat warm. Although I agree with another commenter that doing things like learning new technologies and reading and commenting on Hacker News is "work" that you can definitely allow yourself to do if you would enjoy or appreciate it. If you start resolving somewhat fewer story points but still way more than anyone else, nobody is going to notice/call you on it.

But meanwhile, you are doing work you enjoy doing, what exactly is the nature of your annoyance? Just that it doesn't seem "fair" that they don't work very hard? I think you have to get over that. It's not your job to discipline them, and who knows how hard they are working (maybe they work very hard, they just aren't very skilled) or what else they have going on in their lives that may be very hard and distracting them.

If you would just appreciate working on a team with other people at your level you can collaborate with, if you would just enjoy that more -- you aren't going to get that on this team. That situation is really not going to change on this team, and there's no point in trying to. You will have to find another team/job/role (maybe at the same organization, possibly not) to find that.

Perhaps there is someone on your team who would like to learn from you and get more productive? You might enjoy mentoring them if so, including even pair programming etc.

If you can't control your disdain for the other team members, you will have to find a new job. Neither you nor they are going to be happy if it becomes clear you think they are incompetent slackers.

I worked at tech-team-of-one startups for years.

I wonder if you picked up any bad habits, like forgetting how to work on a team.

You're working too hard. And you're stupid. You set your own high watermark super high, now you can't back it off without getting questions directed at you.

At no point in your career is holding your peers to account part of the role of a developer. Get that through your skull quickly.

Either find a job where you're under the hammer more and the comp is what you want or learn to live with this. Or work on your own projects on the side. Do anything but what you are doing.

The best employees don't get promoted or celebrated for working super hard. I've never yet met one who was.

Cynical take: being this much more effective than their colleagues won't get OP promoted, but it might get the rest of the team fired.

That would be unlikely. If OP is the exception, not the rule, of their hires, they aren't going to replace the whole team with people like OP. And if they are smart, they aren't going to fire a whole team and rely on one person. Especially one who might be showing signs of frustration being at the company (though, yes, there are many examples in which companies have done this). Perhaps the team is downsized, but "the rest of the team" probably won't be outright fired.

I'm alarmed by anyone describing a fellow human being as "0.1X." That's not normal, right?

Accept that you will never have a perfect job. There is much to be upset about. It could be pay, the interest in the work, the level of autonomy, the career growth prospects, the work-life balance, the people you work with, the people you work for, etc.

In the grand scheme of things, your complaint is minuscule. Trying to adjust the world to sate your ego is the folly of many men. Think carefully about what you actually have control over, and count your blessings that this is all you have to complain about.

This is generally a management problem, and there is probably nothing you can do about it. Enjoy your free time: pick up some new skills, manage your stock portfolio, read a book, etc.

Work at whatever pace you feel like working and don’t pay attention to what others do. Leave to go somewhere where 5x productivity is rewarded. Get recognized for your immense output and get promoted or assigned to work on things that aren’t getting done otherwise.

The members of your team are not reporting to you, so it isn’t your problem, or maybe isn’t a problem at all and the “big” company has enough money and people to get done what needs to get done at whatever pace is normal to them.

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

I also work at a start-up, and I've heard from bigco friends that yes, it _really is that much slower at big companies_. Unfortunately I don't think there's much you can do besides be an ass-kicker and gather up some promotions, maybe?

Maybe some other startup-to-large-company folks will have interesting insights. I feel your pain, though. I'm also used to a fast environment, I can't imagine slowing down like that.

You don't get promoted this way, the reason these people get so little work done is often because they are working on getting promoted instead. Optics win and your ticket points is not it

This. Closing the most Jira tickets will get you from jr. to sr., but beyond that it's not a useful metric for promotion.

As they say, "life ain't fair"!

Do something more ambitious that is bigger and more impactful than closing JIRA tickets.

Everyone here has provided some good advice about looking for what you are missing. In any part of your life, if your conclusion is "everyone here sucks but me": you are probably missing something. Understand that your equation of "more story points faster = better" is a philosophical decision you are making, that your team does not agree with. Your team may not capture all of their work on a jira board or may scale their tasks differently than you. You may value fast completion of tasks, and they may value slow but intentional design and testing. No one's value can be completely captured "on paper".

Also just chill out about perceived relative effort! If deadlines slip, if bad code is being shipped, then you should be concerned about your coworkers effort. If your team is meeting deadlines, then it is managements responsibility to fill the work queue, if you want more work ask for it. Your job isn't to manage your coworkers who all have their own lives and relationships to the work. If you are worried that you are doing more work for less money, do less work or ask for a raise.

You need to consider the possibility that your assessment is wrong as well. From your description, someone who is a cowboy coder that everyone has to clean after him will looks the same.

Did you talk to your manager and the team? How was it like in planning when you take far more points than the other? What is your opinion on the validity of the team's excuse? Was your code done in the sense that it is now running on production?

Do you not talk to your coworkers and understand how they spend their time? This should come first. Maybe they spend half their time socializing. Maybe your code is voluminous but ridden with subtle bugs, and your teammates are spending more time testing and doing good design. Maybe they are splitting their time between other projects or tasks. Maybe you are the only one with job security.

Working for a company, on a team, is different than just being a solo contributor. Teammate relations can be leveraged to create a better product through, well, teamwork. I want people to be happy and effective at their jobs, myself included. I try to work with others, understand what they are doing, and do things that directly or indirectly contribute to their efforts and even unite efforts across individuals and teams. There are usually inefficiencies that come from lack of communication. Talk to your coworkers and manager and adjacent teams and understand better why things work the way they do, stop just running off and racking up story points, it is not a race.

> but I would feel guilty slacking off all day. What do I do?

Raise your quality bar. Work on things that are peripheral to the original issue but makes everyone's lives better. Improve effectiveness of testing, make invalid situations impossible or unlikely to arise. Document what you learn, which is ideally done when information is new to you.

Another thing you can do is pair with some of the other devs. Maybe you can offer some insights that make their work go more smoothly, or maybe you'll get some context as to what complications exist that aren't in the original estimate.

The only good use for points anywhere I've worked was that we could measure 'firefighting hours' per sprint for the whole team relative to the stories that got done. I wish there was a way of connecting slow delivery with tech debt to allow focusing on reducing it.

OTOH I've also worked at a supposed-tech-startup where other team members were literally telling me not to work so hard, it's making everyone look bad.

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

You've gone from little to no processes where you can just steamroll through work to somewhere where there are processes.

If you're new then there will be a bunch of stuff you're probably not doing which others may be doing. Meetings with other teams, code review of other teams work, meetings with clients or other departments, chasing up things that are just lying around that don't really have tickets but yet somehow you need to deal with.

The fact they have a good excuse is really the thing. They have a good reason why. They're telling you all the other stuff they're working on but you're focused on the basic tasks because you're not used to dealing with the other stuff.

You may just not be cut out for working in teams for big companies. You may be someone who should work by themselves on small products. They're two totally different things and people who are good at one aren't always good at the other.

You seem to have a misplaced sense of being part of a team when in reality you are a hired resource and should act accordingly

I had a working theory about this when I used to be like you.

There seems to always be a finite amount of completable work at any workplace. Let's say for purpose of your example it's 72 story points worth of work.

By completing about 30 story points yourself in a 4 member team you might inadvertendly end up taking work that could be comfortably completed by your team mates leaving them with work that is either very challenging or work that they are not motivated to complete.

At the same time they see you overperforming and basically "carrying" the team. Imagine yourself in your next job, after this experience, having a team mate that is able to do 400% of the work you can do.

Would you fight this teammate for the finite amount of completable work or would you sit back letting them do all the work ?

Why do you care ? Do your work and get paid, the rest is none of your problem. If you care just bounce somewhere else, you won't change them.

It's a job, if the execs are happy with the output that's enough, not everyone gets a hard on from typing code all day long.

> Now I'm working at a big organisation.

That's your problem. It's very difficult to keep competency high in a large organization. The system is designed to get predictable output, and be robust to variations in human capital. The low performance of your peers is known and expected by the organization.

The reverse is also true. People who are low competency, or only want to put in minimal effort choose employment at large corporations. It's easier to hide, they have to make less important decisions themselves, less accountability, expectations are lower.

The mismatch here is you. The system you are operating in is not trying to identify or reward hyper-competency, and hyper-compentents are not trying to enter the system.

Zoom out. Excluding the tech stack, do you like and care about the product being built?

If you do, then that should be a sufficient motivator. If not, then prepare your exit.

Other questions to consider: Do you need the paycheck? Is this position beneficial to your long term career growth?

You should ask yourself what you are doing to help them become as good as you. And also, whether their poor performance is your fault.

If nothing else helps and you don't want to be the best guy, go work in another place with better people.

they're not necessarily 0.1x programmers. at big companies risks and their impact are disproportionately higher than at startups, which unfortunately causes most engineers to be overly cautious. every change is almost non-trivial. it also doesn't help that sometimes even long tenured engineers can't inspire confidence that a change could be safely made. of course there are legitimate cases of 'coasters' but my general experience at bigco with a proper bigco culture is one of people avoiding catastrophe at all cost.

My junior colleagues are generally assigned straightforward, easy and well defined 2 or 3 point tickets. They can rack up 20 points quickly. I work on fixing or replacing old fucked up chunks of functionality or poorly defined tickets with unknown outcomes. Those can take weeks trying various approaches and no guarantee of results. Deer in the headlights look when I tell them what I’m working on. Point-based progress optics can be misleading. This may not be your case but that has been my experience.

It's not clear to me how this is your problem. Presumably they were staying afloat somehow before you came on board. Does this level of throughput allow for them to remain profitable somehow? If not this would be a good topic to address in a skip level 1:1.

If it's just the principle of the thing that's bothering you, my advice would be to either go someplace where your peers will be closer to your level, or to just choose to not be bothered by things that don't actually negatively affect you.

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?

Spent a while looking for this comment - doesn't seem like this occurred to many people, but maybe the 0.1x programmer is actually the OP and not the colleagues.

I'd view anyone new in my team racing through tasks very quickly with suspicion - are they documenting their work? Are they writing robust, maintainable code or just trying to tick a box? Are they writing tests? What, in short, are they missing?

The probability that we'd landed a 10x programmer (a mythical beast of which I've only encountered a few) would literally be the last thing to cross my mind.

Unless you're a boss you can't make the kind of changes in the team that I'm guessing you're hoping for, if you point this out in a rude way you might antagonize the situation and curb your potential career growth at the company. I would advise that you raise it in a factual manner with your direct superior and focus on what is expected of you. If you don't see an improvement then look for another team.

I see 2 directions you can go:

If you work remote, get overemployed and collect multiple paychecks and be decent at those jobs instead of a rockstar.

Else, continue crushing it, this job looks WAY too easy for you and you wont grow here without having the right challenges and learnings. Look for roles in other teams in the company where you are not the smartest one in the room. Once you grow there and start crushing it, you will grow naturally.

I'm quite surprised that everyone here is questioning your ability and truthfulness of the situation instead of taking giving advance on the face value of your assertions. If you believe in your assessment of the situation, I would do one of 2 things. Either look for new opportunities or don't feel guilty spending less time at work. Use the time to better yourself.

You are in a good position where YOU get to control the output. No need to slack off. Get your stuff done at a reasonable pace. Set aside some time to learn new technologies or other parts of the organization before grabbing the next ticket. Go home on time, and work on your own stuff or other interests outside of work. Sleep well.

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

How long have you been there? Perhaps not long enough to run out of steam pushing so hard.

You need to work sustainably at a big company. Because there's lots of road blocks to frustrate you. Managing frustration is a skill. Working at 50% capacity is a tactic.

0.1X programmer colleagues ... them all being, on paper, completely ineffective ... the bar is so low

I believe it's all about you thinking that you are too good

Maybe you should start your own company and code the next twitter, facebook or something

>>> No one inside or outside the team seems to be batting an eyelid about this

So, everything looks good from a org stand point. Maybe you are looking at the wrong metric, or maybe you are not a good fit for them.

Maybe you can do similar amount of feature/planned work as them then for the rest do off-the-record speeding up the compile times, or something else that could speed up the rest of the team.

If you work super hard, you run the risk of being irreplaceable.

And if you are irreplaceable in your current role, how do you expect to get promoted into another role?

It sucks. I don't have your experience, nor the answer, but I'd search for a different work environment to avoid degrading.

If you can convince them to sit upside down while they work then you can turn them into a 10x programmer. The inverse of 0.1 = 10!

Hot take: You should be doing more mentoring. Clearly there is something you’re doing that you should share with others.

The fact that you are focusing on story points should tell you that ALL of you are doing garbage work.

Leave them alone. Their boss has no problem with them, so don't ruin a good thing for them

Move to a different environment where you feel like everyone else is more competent than you

maybe just go back to a startup?

You need to find another team. It sounds like the culture you work in is not for you.

How are you sure your points are actually good/valid/roughly correct?

Some people are soldiers, others snipers. Both are important to win the war.

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

Find a few more jobs like this and retire at 40.

Leave. Email me nico@ramp.com

Your reward for shovelling the most shit is a bigger shovel.

Frankly, it sounds like you're the problem here.

Reply on news.ycombinator.com