Some context: I'm a newly hired developer (1.5 years) at a software testing company. For a while things were going great. I was able to dive in relatively quickly, but there have been some speed bumps.

In particular, I wrestle a lot with our codebase. It's particularly hairy (being written in C++, Ada and Python) and it's 20 years old at this point. Most frustratingly, there is very little to no established code ownership in a tool that spans over 1.5 million LOC. There is sort of an ad hoc understanding -- the tool can be separated into various modes, and same people tend to work on the same modes, but it's not always the case.

Recently, I've been asked to change, in a fundamental way, a part of the tool that is used in every single mode. I've designed and implemented changes to features before, but nothing this complicated. My boss seems very confident in my ability to do it, but it took me over a month to understand exactly how it would affect "my" part of the tool, and implement the change there.

Now, despite multiple attempts to ask my boss for help implementing the work in other parts of the tool, he insists that I must learn them and do it myself. I voiced concerns about code ownership, and maybe asking the people who work in that area to do some of it, but the response was that "they are busy and this is your task." It was made clear that I can ask questions, but as far as my main task, I'm on my own.

He's aware of how big this change is. He even says it himself, and tells me not to be hard on myself if it's taking a while. But despite his sympathies, the project just isn't getting done. There's just so much code, I can't even comprehend it all. Sometimes I will spend an entire day trying to map out a completely different part of the tool, trying to understand how my change will affect it, and I'll go home having accomplished almost nothing. Sometimes I'll make a design mistake, realize it, and have to completely start over. I walk in the next day, sit down, look at my notes and sigh. Hopefully I'll write some code.

On the rare occasion I get assigned a different task, I always knock it out quickly because it just feels like a breath of fresh air, but when I even think about my main task, it's so demoralizing that it makes me to want to find a new job.

How can I manage the stress of feeling like I'm not accomplishing anything, and more importantly, deal with a project which I feel is too large for me to take on?

ETA: my boss used to be the technical lead for 16 years. I don't think his lack of technical know-how is the issue here.

  • He used to be one of the lead developers for the tool, for over 16 years. He knows the codebase sucks, but I think he's been removed from the problem for too long now (the past 4 years)
    – Tyg13
    May 22, 2019 at 14:44
  • 1
    in that case, trust his judgement. Dwizums answer is probably the best advice here. Don't measure achievement by the amount of code you've written - I've lost count of the number of times I've spent days working on a single line of code solution. May 22, 2019 at 14:47
  • 5
    The question right now lacks specific thing you want help with. What do you want to happen? It sounds more like a rant right now with all due sympathy to your issue May 22, 2019 at 17:18
  • @aaaaaa Ideally, I'd like to be taken off this project. It's a lot of drudge work to get something that should have been in the tool in the first place. We've built onto a structure for years that now needs to be almost completely reworked. I don't think that's a change that a developer with a single year's experience with a massive codebase should be making. But I fear for the worst if I were to say this to my boss, verbatim
    – Tyg13
    May 22, 2019 at 18:13
  • 1
    Forget the idea of "owning" the code. The code belongs to the company, not any particular employee. Developers should never think that they own a particular bit of the codebase.
    – Simon B
    May 22, 2019 at 21:32

5 Answers 5


You said,

Hopefully I'll write some code.

One of my mentors had a plaque on their desk: Resist the Urge to Code. Yes, software may be your work product, but that doesn't mean your work is only writing code. You need to understand what you're doing, and that takes time. The point of the plaque was to get developers to think carefully about their tasks and make sure they consider the approach they're taking, rather than immediately sitting at a keyboard and writing code based on an incomplete or half-baked notion.

Further, to tie in to your choice of wording in your title, when his developers would complain about spaghetti code, he'd tell them to "pick up a fork and spoon and start twirling." The point being, yes- sometimes we're served a mess and we can't just dive in and eat, we have to organize the mess first.

So - when you have a day like,

Sometimes I will spend an entire day trying to map out a completely different part of the tool, trying to understand how my change will affect it, and I'll go home having accomplished almost nothing.

you shouldn't think of this as accomplishing nothing, since you're learning about the task you have to do. That's an accomplishment. Even if you think "I've tried to map this out and I got it wrong" well then, you've at least ruled something out.

To get at the heart of your concern, yes - it is nice when we have work in easily-identifiable parcels that we can wrap our hands around and accomplish in discrete chunks. But sometimes that's not the case. Since you're feeling so overwhelmed, you may want to seek help (either via your manager, senior developers, the web, whatever) on process mapping or other meta-tools and methods for developers, so you can get better at learning how to tackle large problems, instead of just solving the problem in front of you or simply feeling overwhelmed.

It's also worth pointing out that you made several very encouraging comments about your boss, indicating that he understands the difficulty of the task and he's willing to give you the leeway to accomplish it. it's a compliment that he thinks so highly of you. He's indicated that you're able to ask the other code-owners questions, which is a good starting place when you're really stuck.

Ultimately, you need to decide if this is acceptable work that you are happy to do, versus something that's going to make you quit your job. Just take it to heart: when your boundaries are being pushed, it's either an opportunity to learn and grow, or an opportunity to run from the problem. We all do both, at different points in our lives. The choice is really yours.

  • 5
    This. Don't start coding until you understand what it will do and don't panic if the understanding part takes a lot of time in cases such as these. Every day one learns something more about the system that will later allow changes to be made is an accomplishment. Success cannot be measured in lines of code. Lambdas/LINQ would not have been introduced if that were the case.
    – Jonast92
    May 22, 2019 at 16:14
  • 6
    +1 for "pick up a fork and spoon and start twirling."
    – Eric
    May 22, 2019 at 18:50
  • 11
    My best days are the days where I delete code. May 23, 2019 at 0:15
  • 1
    To this point, I have gone as far printing out entire spaghetti modules to parse through the control flow like reading a "choose your own adventure" book by sticking my fingers or post it notes to mark spots to return to and reading it like a novel. Nowadays I try to throw maximally verbose Doxygen at undocumented codebase to at least get the call graphs before diving in.
    – crasic
    May 23, 2019 at 1:32
  • 3
    Sometimes when I don't understand the codebase I have to work on, I try to refactor it first. It doesn't have to be a complete refactor, even simple things such as changing variable names can help you understand it. It also helps you feel like you're "doing" something - which helps take away the anxiety and allows your brain to focus on learning.
    – Ian Parry
    May 23, 2019 at 2:29

One day mapping out the code is nothing, in the grand scheme of things. If it's a large code-base it may take weeks of long and tedious slogging. It's not fun, especially not on your own.

Try to work out which bits you need to know about. Try to determine which modules will be affected by your changes, and which won't. Document what you find - diagrams, notes on the inter-dependencies and interfaces between code modules, anything that may be useful to you in the future. Even warnings not to make certain changes because they will break something else.

To start with, measure progress in what you have managed to document, not how much code you have written.

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

Bill Gates


The way you make it sound makes it sound like your code is written in "modules", except that a bunch of modules are spaghetti-strung in amongst other, unrelated modules. What would happen if you factored out that shared part that you are responsible for and figuring out how to make a one-size-fits-all solution to what you're being asked to do, rather than re-implementing each piece individually?

Failing that, it doesn't sound like you're being asked to re-implement a "module", because a "module" is supposed to work the same way in every case. It sounds like you might be being asked to take over a very large swath of the application by yourself, which sounds unreasonable to me. You should carefully figure out which of these cases is correct.

Also, if your boss understands how big of an undertaking this is, but also won't allocate people to help you, it sounds to me like he's trying to throw you under the bus. I've had a similar situation before, and it ended in me being fired from the job for not doing the required work in a reasonable time, despite my boss's repeated "I understand how much work this is and I don't expect it to be done quickly". If this is the same thing that happened to me, your boss is not being friendly and understanding, he's setting you up to fail and smiling at you while stabbing you in the back. Get out.

  • Related to your last paragraph. We tend to think of our shop as being split into two halves: one headed by my boss, and another by a co-boss. Both have equal authority, but also their own subordinates. On the subject of the implementation of this feature, my co-boss disagrees heavily with my boss and I, and thinks this could have been done much easier a different way. Recently, another developer began working on a parallel implementation of this feature from an entirely different angle. I didn't even know about this until the developer came to me himself.
    – Tyg13
    May 22, 2019 at 16:20
  • @Tyg13 My recommendation in light of that is twofold: Firstly, if your co-boss is an engineer as well, ask him for some suggestions. Explain to him that you're stuck, and you'd like some insight into this huge codebase. See what he says. If he takes the "I know the answer but I'm not telling you haha!" tactic, then run away AS FAST AS YOU CAN. This would be not only unprofessional (as in your co-boss would not be working in the best interest of the company), but would also make it clear that you are being set up.
    – Ertai87
    May 22, 2019 at 16:22
  • As for the second piece of advice, the fact that you are being given duplicate work and the other person was told not to collaborate with you explicitly (this is my take based on information provided) means that you're probably being put in competition with him. Determine which of you is in the better position from a work-politics standpoint, and that person is probably soon to be on the chopping block. Since he was the one notified about the work being duplicated and not you, the one to be chopped is probably you. Get out.
    – Ertai87
    May 22, 2019 at 16:24
  • Unfortunately, given from what I've seen of the structure of this company, it's more likely that no one told this developer I was working on the project. We don't have meetings other than the weekly one-on-one with the manager. No one knows what anyone else is doing unless we ask one another, or our manager tells us.
    – Tyg13
    May 22, 2019 at 19:16

Well, you have difficulty delivering and also someone else is working on the same task.

Try joining the other guy: he can delegate onto you tasks that you can deliver, he takes responsibility if his solution doesn't work out, you are relieved of this task you don't really want to do.


The question here is: what is the deadline - how much time were you given for this? If there is enough time, then do it, do it slowly and carefully, do it well.

If there isn't enough time, and the company is asking for impossible, start looking for a new job.

Also, is your experience on the level with the complexity of the code? Reworking something in a 1.5 M lines of already messed-up spaghetti code is a job for a very senior developer with lots of experience. Is your 1.5 years of experience just with them - and you have a lot more in total - or is it more or less your total professional experience? Because if it's like that, they're setting you up to fail. See the previous case... as in, start looking for a new job.

The next question here is, if the company is considering seriously reworking that code so that it's not a spaghetti mess, or are they just doing a fix atop a patch atop a change and so on? In that case, also, start looking for a new job.

If your manager has 16 years of experience as a tech lead, and is doing things as described above, it's intentional, it's a conscious decision to either get more work out of you than is normally possible, or to set you up to fail, and whichever case it is, he won't change his mind no matter what you say.

Based on answers to these questions, you will see if this is a hard but expected part of your job, or a messed-up project and team - and that will tell you all you need to know.

You must log in to answer this question.

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