I'm relatively junior in a small team, in my first job. I got valuable skills in the last few years. I can't complain about my salary.

I almost burnt out in the last few years, in an effort to improve the team's output despite senior coworkers' indifference. Management told me they appreciated my efforts, saw the results, and they went beyond their usual rules about raises to keep me a few months ago. Most of the team consider me a good programmer. The lead sometimes asks me for advice.

Through multiple reasons (mostly disorganization, lack of a strong technical lead, no consequences or pushback against low-quality contributions), the main product is being built on very bad code. A colleague whom I respect who works on it directly agrees with this. I've pushed as hard as I could about this and going any further would cause too much conflict (the people responsible basically say I'm imagining problems).

My morale is low because my efforts feel wasted when the face of our projects to most customers is of low quality. I worry that working too long in a team with that culture will make me stagnate and prevent me from getting experience working on robust systems. That new product is also failing to attract customers, even its manager told me privately that they have doubts about its business model.

Is it reasonable to care about the whole team's output even when it's not my responsibility? Should I focus on my own tasks and stop caring about anything else when I think that the whole team is moving in the wrong direction? I'm considering quitting, but would like to know if my thinking makes sense before making a decision.

  • What does those responsible for the "very bad code" think about your thoughts? Also "very bad code" may have qualities you are too junior to appreciate... Feb 3 at 14:32
  • They think I'm imagining problems. I can't share code to prove it, but I can promise you this isn't a case of "senior sees the whole picture, junior doesn't have the experience to evaluate". I'm talking about functions could easily be made linear and robust, but get written with unnecessary nesting and tons of edge cases, unnecessary coupling, variables that get assigned the same value 3 times for no reason, globals that make parallel testing impossible, full screens of logging with no meaning, etc. This has caused problems that should not have happened. Feb 3 at 14:54
  • 1
    To give a single example, one of these persons saw a function that didn't do exactly what they wanted, copied and pasted it with the same name (causing a name collision that shadows the first version; it was in Python), changed the copy's API to fit their specific case in a way that breaks the original feature, all to make a pretty disorganized function in their own project work. Writing the latter function correctly would take 2 minutes. Even the workaround could have been done without breaking quite easily. Feb 3 at 14:58
  • Do not underestimate the value of code battletested in production for years. And frankly "Not being able to test in parallel" is really not seing the whole picture. If I were you I would focus on the things actually causing problems and suggest how to fix those (and ONLY those) and listen very carefully to the feedback you get. You might learn a thing or two. Feb 3 at 15:00
  • 1
    That code was not battle-tested for years. It has created problems. The people working on it who aren't the main dev also tell me that it's causing problems for them. The parallel testing example is admittedly a bad example, except that testing performance is a problem we're currently struggling with and this will set the devops team back. I don't understand why you assume so many things about my situation, or that I didn't already gave suggestions, or that I didn't listen to the answers. I'm talking about code that breaks distinctively more than the team's other, more complex, older projects. Feb 3 at 15:05

5 Answers 5


I'm relatively junior in a small team, in my first job....

This is the key. OP showcases all signs of "cares too much about their first job" syndrome. (In fact, I was speed-scanning the question, thought, "Hmmm, I wonder if this is their first job? Sounds like it probably is", then went back and noticed this first line.)

You don't own this project or codebase. You won't be in this job forever, nor will the company be in existence forever (or even likely more than a few years). You've got one or more "cowboy coders" who trample all over the codebase to add features. The owners accept, are familiar with, and even lionize these founding coders for their ability to do this. Even while it environmentally enshittens everything for other coders.

There's simply nothing you can do in this situation. You're not going to be able to take ownership from all of the company shareholders, executives, and senior coders who think differently from you. It's time to take the knowledge you've developed in your first job and take it to a new job in a more senior role.

... I got valuable skills in the last few years.

Completely separately, I'd also recommend that you move on from your first job after about 2 years (about how long it takes to absorb the main lessons from a first job), and it sounds like you're past that point.

So all signs are strongly pointing to moving on to your second job. In my experience, this is extremely challenging at the start of a career. You've poured blood, sweat, and tears into this company, and you've got a lot of your social and personal identity tied up in this position. But jobs come and go, and high performers advance their careers by moving fairly frequently.

Find the next job and wave goodbye. This is your next major lesson.

(And compare to these prior answers on the same theme: one, two.)


You should care about it, absolutely. However, there are many companies around, that I have worked for and partly owned, where the sales people have an undue influence on deliverables. All that matters is that they can announce new features, code quality has no bearing on it.

One day, this is going to catch up. You are obviously working for such a company. There is no way, you can convince the management that it is worth spending more time to write better code and to test it properly. They just can't see it. If you persist they will see you as a trouble maker.

My philosophy has been to do the best I can and leave the code in a better state than I found it. Eventually, if you stick around, you may be in a position where you can dictate some terms.

If you can't wait for the long goal, then look for a better company. But there is no guarantee that the next one is going to be much better. Don't resign until you have found a new position.

  • Thanks! I can’t upvote but you’re probably right. Feb 3 at 15:48

Is it reasonable to care about the whole team's output even when it's not my responsibility?


Should I focus on my own tasks and stop caring about anything else when I think that the whole team is moving in the wrong direction?

Unless you are responsible for the team, yes.

To elaborate:

It is good to try to envision the big picture, it is appreciated when you suggest about possible improvements, however unless you are responsible for the entire team, or given the task to manage the team, pushing it any further is not in your scope. You have proposed ideas, given hints about the possibility to make it better, now leave it to the people who are calling the shots.

Software industry is not always about cutting edge technology, improvements, efficiency - sometimes (well, most of the times), it follows the idea "If it ain't broken, don't fix it". Don't be hard on yourself, let it go.

  • Is the solution to stay in a place where my work feels pointless though? I understand why I shouldn't try to go beyond my position, but it feels like I'm building foundations for a house that won't last two years. Feb 3 at 13:48
  • As I said, learn to let it go. Do not get too attached to the product / organization. Do your job, and let those people worry about other things who are getting paid for that. If you feel you're not valued, find another job, but not based on emotional grounds. Feb 3 at 13:50
  • I'm also asking on career grounds. Basically, isn't this environment bad for my skills and career growth. But I take your point about not getting emotionally invested. Feb 3 at 13:53
  • 1
    As a junior dev, the product or project you worked on will not decide your career, rather the knowledge you gained while working will do. When you see you are not learning something new yourself, you know it's time to move on. Feb 3 at 13:56
  • Makes sense, thanks for your advice! Feb 3 at 13:59

Unfortunately, most real world software projects are built under time and budget pressures. That means that often, when a solution works, it is accepted so the next part of the problem can be worked on, even if it isn't the cleanest code possible.

Also, most real world code is "whittled" rather than designed. There is a lot of truth in the old adage which says that programming is the art of debugging a blank sheet of paper. Code tends to develop by addressing the simple case, then adding exceptions for the more complicated cases, and so on; the results is often not as clean as it could be if you knew the entire architecture from the beginning and wrote it all at once.

Additionally, once people start actually using the code a premium is placed on not breaking what already works, even if it isn't pretty.

So over time, like many workspaces, code tends to get messy. And until it develops a bug, or performance becomes an issue, it's hard to find time to stop work long enough to clean it up.

The solution, such as it is, is to try to improve each piece of it every time you are working on it for some other purpose, even if only slightly. You can't go back and fix the whole thing at once, but if you can add comments, or reorganize a loop so it makes more sense and runs faster, or replace one function with a better solution, eventually that starts to add up. Evolutionary changes are a lot easier to get approved than revolutionary ones, unless the revolution is actually necessary. They're easier to review. They have less risk of introducing new bugs. And they're easier to find time for.

Yes, it can be frustrating. Working with legacy code requires some degree of patience, and focus on what matters right now. And sometimes you have to type with one hand while holding your nose with the other.

If you have a task control or "ticketing" system, which records all the things that need to be done, or should be done, and lets the group organize and prioritize and track those, that can be both a stress reliever and a huge help. Rather than interrupting your work to fix something else immediately, you can log it as "technical debt". That way the improvement idea doesn't get lost, and remains as something to be gotten back to when time does permit, by you or by someone else.

Also, since I mentioned performance: always remember that infinite speed-up of something which accounts for 1% of the runtime takes infinite effort but only improves performance by 1%. Part of being a developer is learning to focus on the changes that will matter most, and will make the most Improvement per hour of work. With improvements in processor speed and memory size over the years, efficiency has become less critical.

By all means, write good code. But save your greatest efforts for the places where it will make the most difference per hour invested in it. That usually means focusing on algorithms rather than individual lines of code, except in the most frequently run inner loops.

This is software engineering, not computer science. Craft, rather than art. Make it work, make it good, make it great - in that order. Often, good enough really is good enough for now.

Eventually, you may get the opportunity to re-architect major portions of it, or the whole thing. Usually that happens when what you have really cannot be made to meet the new requirements. It's challenging, and it's fun, but it's rare. Until then, learn to make the most improvement you can with the least risk you can. It does add up over time. And the contribution does get noticed.

And periodically you will get the opportunity to build something entirely from scratch. At which point you will really learn just how hard it is to keep a larger piece of code clean while continuing to maintain, debug, and enhance it.

It's a different kind of programming puzzle than the ones we solve as students. There are constraints that most class assignments simply don't have. However, learning how to work within and around those constraints can be its own kind of game, and can be enjoyable at the same time that it is driving you crazy. The trick is going the right kind of crazy.

So to answer your question, you should certainly care, but focus on the parts that you have direct control over, focus on improving one piece at a time, focus on the changes that are most important to the customers (and thus to the company), and remember that your code, too, will be old and crufty someday. Do what you can with the resources you have, and defer the rest until more resources become available. Focus on doing your own tasks superlatively, and on offering clear, directly actionable suggestions when reviewing other's code.

You don't need to boil the ocean to make a good cup of tea. Even if it could benefit from boiling. Take it one cup at a time, and then one teapot at a time. And know that you are making a real difference by doing so, and doing it well.

  • All this is right, but my situation is that some projects are "legacy" code as soon as they are released due to bad coding practices. The kind of complexity you should get after years of time-constrained maintenance is there from the start. I've created and maintained big projects (relative to the team size) and there is a clear disparity between old, well-maintained ones and the ones I'm worried about. Feb 3 at 14:47
  • The question is, is addressing that the best use of "your" time? If not, log it as technical debt with a specific suggestion in how to improve it, and let it go until someone has cycles to deal with it. If you are involved in review of that code you can try to help guide it, remembering the priorities and that complaining without contributing solutions may result in your being stuck with the task and not achieving your other goals. If you aren't a reviewer and aren't going to fix it yourself, pushing too hard is annoying rather than useful. What you've actually been assigned is your priority.
    – keshlam
    Feb 3 at 15:04
  • Ood is good, but we need you on lute right now
    – keshlam
    Feb 3 at 15:06
  • Basically, try not to become this guy: workplace.stackexchange.com/questions/195319/…
    – keshlam
    Feb 3 at 15:08
  • It was a good use of my time when I could make progress, now it isn't because it clashes with other team members. But I still see the result and it's pretty clearly going the same way as existing projects, from the same people, created before I got hired, that have needed complete rewrites because nothing worked at the time. This is not only my own opinion, it's what I heard internal users and management say after I arrived. So I have pretty strong data points that suggest this isn't just an abstract problem, even ignoring the problems it's already caused. Feb 3 at 15:13

Is it reasonable to care about the whole team's output even when it's not my responsibility?

To a point: You should care specifically about how this affects your future in the company which includes the future of the company itself. You can't really affect the outcome but you need to understand what that outcome means for your future career. Remember

 Stress = -----------------

That's why you are burned out: too much responsibility but no authority.

Should I focus on my own tasks and stop caring about anything else when I think that the whole team is moving in the wrong direction?

From the sound of it, you have already done what you can reasonably do and are hitting a wall right now. Repeated slamming your head against that wall will only increase your pain but is unlikely to make a dent.

I'm considering quitting, but would like to know if my thinking makes sense before making a decision.

Rephrase that as "looking for a job with a better cultural fit". Yes, that includes quitting, but that's just a means to an end AFTER you have found a better job.

That's probably a reasonable course of action here. The company's culture is what it is and it's unlikely to change anytime soon. Many people are fine with doing only mediocre work and that's ok as long as the business is viable. However that's probably not a place where you can thrive in the long run, and there are plenty of companies that highly value excellence, passion and diligence. They will happily take you in.

  • Thank you! I don’t know why you were downvoted. Your point about burnout is exactly the situation my own manager complains about being in. Feb 3 at 15:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .