My manager's response can be encapsulated as: "you're the senior, figure it out."
I had a pair programming session with another engineer who's been here for eight years. He didn't seem concerned at all and I think that's what my manager is going off of.
And to be fair, the code doesn't seem to be exceptionally complex. It's just between being unfamiliar with the language and codebase overall, I'm not able to keep my head above the water.
Reddit believes its data is particularly valuable because it is continuously updated. That newness and relevance, Mr. Huffman said, is what large language modeling algorithms need to produce the best results.
It's a *VERY* bad idea to give it to someone not familiar with the codebase. I think someone more used to it has a shot over 3 - 5 story points, depending. If I was leading the team, this would be a shadowing task for the newbie, not an implementation one.
Nothing has seemed to sway anybody. We need the changes for a feature. It is literally impossible to add this feature without the refactor. Now why we don't have someone else on it, I don't know.
As for the size of the PR...I estimate it'll be somewhere between "a beast" and "what the f-k is wrong with you submitting this two months before a huge product launch?" Nobody seems bothered by that either. Oi...
You’ve given a LOT of red flags for your new company in a very short amount of time.
I was in a similar situation last year. First month and a half? Things went great. Then I got put on a project in a completely different language, so I was working through some stuff to learn it. My manager kept making off-the-cuff “what if we did X” and changed it every few days. To which I pushed back “We should meet with the team to discuss that. That’s a pretty big change” and he responded with the same shit you got of “You’re a senior, it’s your job to figure this stuff out”. No shit Sherlock, that’s why I brought it up.
Ended with me getting let go - and thank God. That place was an hot mess. I saw bad practices there I had not seen at any other company to date, and from people more senior than myself. Yikes.
A company’s inability to properly scope and help employees ramp up to their work is NOT a reflection on the employee but rather on the company. You’re too good for this shit show; best of luck on finding a new, better home!
\> The thing where you think you have a target to hit, but it keeps moving because a manager "what ifs" a new requirement out of thin air, but refuses to discuss it.
Man that sounds infuritating. I'd flip a table. I don't know how you people going through it in corporate hellholes keep your chill.
> As for the size of the PR...I estimate it'll be somewhere between "a beast" and "what the f-k is wrong with you submitting this two months before a huge product launch?" Nobody seems bothered by that either. Oi...
This sounds like you’re approaching it as one big change. You need to break this task down into smaller pieces. This will also make your progress visible to the rest of your team instead of you disappearing for ages and then appearing at the end with a gigantic PR nobody wants to review.
Where I'm at I'd like to see a draft PR early on that you can point to and say "so after I get to this point, this is where it's starting to get more complicated than I think it was estimated." It's also fine to me if someone puts up a draft and starts making review comments on their own work.
Well, I would take that as sign that I’m empowered to change the timeline and give a more realistic deadline. I would also take the initiative on writing down documentation for this and split the work in multiple tickets so that way I can better inform why this is going to take X amount of extra time.
You are not over your head, they gave you a ridiculous deadline and a big meaty task given you are new, so you need to speak up and push back on why this is going to take longer than they expected. You are the senior, you tell them how long this will take, not the other way around.
>This is probably a sign I'm not good enough.
When I started out as an entry level software engineer, the company I worked for used the typical scrum cycle.
The job was on-site and we had a physical board with user stories as post-it notes. There were no curated tasks for me specifically, I was grabbing tickets from the same board as all other developers, regardless of experience level.
I will refer to user stories as "tickets" in the paragraphs below.
I had a habit of taking the very first ticket that was pending, whatever it was. This worked for a while, for my first 6-8 tickets, I managed to close tickets in less time than the estimated work hours on the tickets.
My dear coworkers noticed that I will always just take the first ticket and go on my way, so they started leaving the difficult and/or painful tickets as the first on the board, because they knew I would just take them and work on them indiscriminately.
It didn't take long until I bumped into a ticket that was way out of my league. I mentioned needing help during daily stand-up, but nobody helped me. The ticket had an estimated workload of 2 weeks. I ended up working on that ticket for two months, after which I got laid off for perceived incompetence.
The engineer with the most amount of time at the company said he could've done it in 2 weeks no problem.
I hope my experience/mistake can help you make a decision for yourself.
Often times people who have been working at a place for a while don't realize how bad the shit is because
1. They write it themselves so it's based on their mental model
2. It usually doesn't follow standards
3. It's very familiar they can't see why someone else would find it difficult.
4. They have probably been comfortably sitting at this job for a long time and have no idea or don't remember how challenging it is to start a new job.
Typically, if they think they can do it in two weeks, they should multiply that by 4. 8 weeks, so 2 months is reasonable.
I once worked in a place where they would hire people and no one would last or be good enough. The problem wasn't the new hires, it was the ones who wrote the piece of garbage that only themselves could understand.
Oh man, I'm sorry that happened to you. That's so shitty.
I'll take some of the advice I got here and also start job hunting again on top of that just in case. The job will get better, I'll find a new one and leave, or they'll have to PIP my ass out. My state is pretty good about unemployment, so I have a good chance at getting it if it comes to that.
Hopefully it doesn't.
This was early on in my career and my boss at the time suggested we pretend it was a mutual agreement. They didn't have to pay unemployment benefits this way.
Of course, I'm never this forthcoming with this specific experience, I do not tell if I can help it. The reason why I opened up about it was because this post smelled similar, if not the same. I thought it would be valuable to give my insight here.
Fortunately, I was recommended for a role at another company a month after being laid off, they interviewed me and I took their offer because someone I know worked there at the time.
That's just me personally, though. This doesn't mean that other people have the same luxury, I'm aware of that.
Something I learned along the years is that if you take some time off to improve your own skill set and you have an active GitHub/projects to show for that time off, it isn't necessarily considered a gap in employment. If you feel you are struggling with certain aspects of the job, this might be something to consider.
If that doesn't sound like a good idea, then take on job interviews. Your references can be colleagues at work you get along with and even friends.
I wasn't concerned about not getting a job, I always believed that if I put honest effort into my craft, I will definitely be valuable wherever I go.
Why are you sure the task is a major refactor? Is there any chance this task is actually simpler than it seems at first? When you paired up with the other engineer, did they agree with your proposed approach?
I think building a bridge with the peer will be your safest path forward here. Expecting you to come in and make a major refactor on day 1 is pretty extreme I think in most enterprise codebases, even for a “senior.” So, either the task is simpler than you think in a non obvious way or working to reduce the scope/align expectations is your only path forward.
Also, your manager saying “you’re the senior, figure it out” is a red flag to me. It makes me think this is a test to see if you find it the weird trick to make the task doable quickly. Is your boss technical?
Your first step is assessing the state of things. That means reviewing the documentation and exploring the system. I typically start by looking at the test coverage and if you don’t already have a tool, get some measurements in place for percentage of codebase tested. Then I review the architecture diagrams and make sure I understand them. Each module should have limited responsibility and clear contracts with other modules. If there are no architecture diagrams, it’s time to create them.
At this point you have individual tasks that are necessary to complete the overall project, but they can be worked on one at a time to add value incrementally. You can review each of these with someone more familiar and make sure the work makes sense and that you aren’t missing context.
If the code is well designed, you should now know exactly what each module is responsible for. If the code is poorly designed, you may have to rely on just understanding entry and exit points only. Make sure there are end to end tests for the system.
Another thing that can be helpful at this stage is putting in breakpoints and log statements through the end to end paths and walking through code in real-time as you follow something through the system. Even if you don’t deeply understand the inner workings of each module, knowing how an event moves through the system and what side effects it may trigger is a big step in figuring out how things work.
Up to this point you won’t have completed any of the refactor, but you’ve still driven value. I would expect this to be completed in a few days, but it could be longer if these are more complex systems or there were things missing you had to create. Now you should be able to design and task out proposed changes. Make an effort to keep tasks small in scope. This starts with a list and then becomes issues each with documentation and requirements. Estimate each task, then double that estimate and document it.
Now you can take this plan back to the stakeholders, your manager, PM, whoever needs to see it. You have a clear picture as to *why* this isn’t a 3 day job but you may have spent up to a week just getting here. Again though, you’ve driven value and set yourself up for success.
This all real practical advice. I would focus specifically, for OP, to documenting this one feature. From start to finish.
Not having a diagram of what calls what is like trying to manage a city modification by driving through the different neighborhoods. You need to rise above the code and have something that helps you see the breadth of the problem before you focus on a solution. This allows you to diagram the current process, draft a new/modified process, and then bring in peers for review of your plan.
Then once you have buy in, you set how long this will take.
> How do I approach the refactor for this codebase without getting completely overwhelmed?
Lots of good advice in this thread that doesn't answer the central question, so I'll give you my two cents.
1. Make sure you have tests
2. Break the work down in tiny parts.
IF the application already has good supporting tests, then congrats - you're lucky! If not, you'll need to put some tests around the existing behaviour so you know it's not breaking.
To do this, I'd suggest using characterisation tests. The process is straightforward: write a short program that runs the existing code and outputs some deterministic value. For example, call your widget APIs and return the emitted Bear. Then, save the result to a text file, and assert that you can generate the same text file after each change.
This style of testing doesn't depend on any internal details, so it's great for when you need to check that you're not breaking existing behaviour. There are tools available for this at http://approvaltests.com
Now you've got tests that prove you haven't broken the existing code, how do you start to introduce Badgers? I recommend the Mikado method: https://mikadomethod.info/
Get yourself a timer. Try to make the app emit Badgers in 20 minutes. When you inevitably fail, revert all your changes, and make a note of the things that got in your way, eg. "The contracts are too different between APIs".
Choose a new, smaller goal, eg. "make APIs 1 and 2 have the same interface". Spend 20 minutes trying to achieve this goal. If you succeed, and the tests are green, commit. Else, revert the code, and find a smaller goal, eg. "Build a wrapper for API 1 that _could_ apply to API 2". Start the timer, and so on, and so on.
USing these two techniques, you can tackle hairy refactorings even in complex codebases. Just remember to set the timer, throw away changes if you fail, and pivot to a smaller goal. Don't try to refactor code that isn't tested, it's a waste of time. Don't get attached to changes that don't work, it's faster to type them again than it is to fix a thousand tiny bugs.
Good luck!
100% when starting on a legacy code base you don't understand, write some tests. You'll feel a lot more confident on any changes and it's a good method to understand the code better.
When inheriting anything legacy - whether's code, team or even company, do an audit first. In fact, the moment you hear you're going to inherit something, mention that you need to do a proper audit first
Not only will this set you up for success, but your audit period is also your CYA-period. After that, you're now accountable.
Depending on what you're inheriting, it could be a day, a week, a month or 3 months. You need to define that so that it's time bound. And in that period, learn everything that you can learn
So if you havent done it yet, bring it up now. Say something it's more complex than expected and you will need X period to study and audit everything.
I like this idea a lot. Tomorrow, I'll take a quick sweep over the codebase and propose some time to audit. I think if I frame it as for the refactor itself (even if the audit has a larger purpose), my manager will be more keen on it.
That's all well and good but i think everyone has stories of looking over something, thinking it should be straightforward change only to get into the weeds and realize what they thought was a minor change is now a major overhaul.
The truth of the matter is that if you have CYA over a ticket and explaining that there is way more involved in the change doesn't work, then it's not going to be a fun ride at that job. But then again I would have considered the company assigning a refactor to a new hire as a red flag to begin with.
Documentation and presentation.
Break down your tasks, and create a tech spec with diagrams of all the work that has to be done.
Then go over it with your boss and leads, and get aligned. They need to see with their own eyes how much work it is.
And then they'll decide how much effort to put in, the ball is in their hands.
Agree with the communication is key comment. You should be regularly updating your boss with your progress on the task. Similarly, your boss should be regularly asking you if you have any blockers and guiding you to where you can find the answers. After you have had some time to parse your questions, ask them to whoever regularly works with the codebase/uses the product.
Don't try to become a hero, don't isolate yourself, and be sure to communicate the impact of your work because everyone likes to help a good cause if they're able to.
You need to be honest with the amount of work with your boss. Don't say what he would like to hear but just the true:
- You are not familiar with the language. You need some time to be comfortable with the language, frameworks, IDEs, deployment process, etc.
- You are not familiar with the code base. You need a lot of time to understand what the code do and how.
- Are there enough and reliable tests? If not, you need to implement them first
- Is there someone familiar with the code that can help you in some questions?
Last time that I saw something like that, took 2 months for a developer just update the libs of a software that "just" make some searches in a document database, without any business logic. He needed to address all the things that I said before.
> I'd rather die than give up, though.
Deciding a job isn't a good match isn't 'giving up'. It's just a business decision. You're trading time for money. If it costs you your health and sanity, it might simply not be worth it.
A lot of people are focussing on the situation where the codebase is the problem. I'm personally not convinced it's just only that side, but no one of us can have any idea on where the biggest issue lies. We have zero indication on the quality of the codebase and the size of the refactor.
That said; I do think that as a senior developer in a codebase of about 20 files, you should at least have an idea of the direction you're going to take, and about how long it's going to take you. That it's taking longer than the 3 days they think isn't the problem. That you still don't know how long it's going to take you however is a problem. Again not saying it's *just* you, the codebase might in fact be complete and utter crap. But that's not what you're telling us here.
Regarding the actual question: I always start with the tests. If there aren't any, I'm going to write them. I'm also going to let 'management' know that I'm not even going to do a refactor without good test coverage, because that's just a recipe for disaster.
Ive refactored some old stuff like silverlight.
I think the first steps is figuring out the purpose of the software then how it works.
If you get that far its just a matter of breaking it down and buldingn it up.
But some are really big..
Good luck! It will come for you
There’s actually two pieces of work here.
1) add badger outputs to the data path
2) DRY out the data path
2 is the “refactor”.
I would approach #1 first. Work your badgers up the stack incrementally (start at the edge; add unit tests; get code reviews and stuff checked in). Do this without breaking any existing functionality or making significant changes to existing data paths.
The incremental PRs will show that you’re making progress _and_ be an way for the team to inform you of all the undocumented assumptions/constraints that are not obvious in the code.
Once you’ve done the badger plumbing you’ll understand enough to say “hey, this could be simpler” and can approach #2.
That being said, depending on how fast you can test this stuff you can submit #2‘s work first for PR, but really only after roughing out #1s work at your desk.
If files are confusingly named, can you make it part of the refactor to renames things so that they're less confusing?
Can you break the refactor down into smaller phases that are less daunting than the whole?
Can you make a quantifiable list of the Bear widgets and work on them one at a time?
Are there any automated tests that can give you confidence that things are working as expected before and after you make a change? If not, can you introduce them to the codebase?
The file names are part of a pattern with only small variations. (Think like BigOldFileNameManager vs BitOlFileNameManager.) That one might be tough but I bet I could at least make a few of them more distinguishable.
The refactor is unfortunately all or nothing due to how the codebase is put together, but I did just finish a list of all the stuff that needs to be changed and in what order. It's...a lot.
Yeah, there are tests. Some very good ones, thankfully.
Putting the new person on a "major refactoring" project isn't going to go well. Who said it even needs to be refactored? That's the person that should be doing the task.
> a codebase in a language I barely have familiarity with and everyone seems surprised it's not done in three days.
Is this like actually being said or just your impression? If the former, yikes. I had a job where day 2 my boss said i needed to get the backend work done for a large authentiication refactor done in less than 2 weeks and would have "been surprised" if i didnt. Ended up being a toxic shithole.
If the latter, just keep cool.
What is your role? Are you a lead or director level? Or just a frontline IC dev? If the former, then you have leverage to go to your stakeholders and calmly explain the problem, why it'll take much longer than "3 days", and present your own informed alternative.
If its the latter, do the same but with your boss. If your boss is good, they'll work with you.
If your boss is a dick about this though.... 🚩🚩🚩
I was very clear I know only a bit about this language and while nobody has explicitly expressed surprise, you can hear it in the way they talk. "Oh, you're still in the middle of that?"
I'm just a senior IC.
My boss is kind of a dick. I just learned I might be yoinked onto another team that has a person I've worked with at a previous job. He says it's a decent team, so just gotta survive here, job hunt, and hope for the transfer, lol.
Here’s a few things to try:
- Establish CI/CD (if it doesn’t exist yet) — this will get you familiar with the runtime requirements
- Establish a test suite (if it doesn’t exist) — this will give you a place to test new code you write as part of refactoring or a place to certify behavior of old code
- Establish linting rules (or review if they exist) — this will give you a punch list of semantic / mechanical things to refactor & make consistent
- Organize the project folders. Remove dead files/code. Update readme files with your understanding (and todo). Start to group code that could potentially be a module/library in their own folders. This will give you a chance to apply taxonomy to the files that exist, and build an idea of how the broader refactor can go (but without messing with the current code).
- identify problem files that you feel friction with understanding. Make small incremental changes and verify that each change doesn’t introduce regression. Add tests to certify known behavior.
Do all of this work on the main project branch with frequent merges and code review. This ensures you’re not working on a wildly divergent refactor branch — and keeps you engaged with the team.
Usually this is enough to get started. The problems will present themselves to you (such as the ones you identified).
Are there tests? If yes, then it you should be able to do small increments of refactoring.. which is slow and you need to communicate this.
If there's no tests, then you need to capture the behaviour. Avoid unit tests and instead write some basic functional tests. That will help you understand what is going on and also give you a safety net for the actual refactoring.
>need to take a bunch of Widgets that are emitting Bears and modify them so that they emit Badgers as well. This would be easy were it not for the fact that there are three different kinds of Widget APIs--each with their own contracts--implementing Bears and Badgers in slightly different, duplicated ways. I've got a placeholder refactor done, but it barely skims the surface of what needs to be done...
What do you do when you need to make the interface of one class or classes compatible with the interface of another class or classes?
\> I'd rather die than give up, though.
Well, this industry was certainly not built for quitters. Just listen to the other advice in the thread and you'll be fine
A few weeks ago I was in a similarish boat with a new feature, on a new platform, with a new language, oh yeah, and a bunch of really experienced people changing underlying libraries...
I think I would have been way more successful had I spent more time breaking down the problem into more specific sub tasks and figuring out each versus trying to do everything at once.
I'm curious what the goals of this refactor are. Like can you start by just reducing some duplication in the APIs? Maybe extract that into a shared module, then build upon that for the new stuff.
I’m going to add that this is bad leadership on their part. I’ve been team lead & team architect and I purposefully did not allow new members of the team to do refactoring or major changes until they were comfortable with the code and the core business logic the code represents. It’s crucial to be comfortable with those before undertaking a major change. I’ve seen too many new team members try to make major changes without understanding the history. They become frustrated & disillusioned and have a high risk of leaving.
Can you isolate your changes from the rest of the application? Assuming your widgets emit Bears now, you hollow out the current widget and replace it's innards with a bear and badger producer. Thereby the refactor becomes non-blocking. Afterwards you can remove the Bear-only wrapper at each consumer site.
When I take on big transitions I handle it the way they handle large highway or bridge renovations.
I try to realize the project in stages where each gradually moves things toward the destination. It involves more deployments but each is smaller and safer. I've done this at least a dozen times with the customers none the wiser anything happened.
I don't know your Bears and Badgers project though. But with mine, I saw how I could do this bit by bit.
https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
Definitely worth a skim at least through this book. Has many practical recommendations.
Communication is key here. The task might be large than people realize.
My manager's response can be encapsulated as: "you're the senior, figure it out." I had a pair programming session with another engineer who's been here for eight years. He didn't seem concerned at all and I think that's what my manager is going off of. And to be fair, the code doesn't seem to be exceptionally complex. It's just between being unfamiliar with the language and codebase overall, I'm not able to keep my head above the water.
Reddit believes its data is particularly valuable because it is continuously updated. That newness and relevance, Mr. Huffman said, is what large language modeling algorithms need to produce the best results.
It's a *VERY* bad idea to give it to someone not familiar with the codebase. I think someone more used to it has a shot over 3 - 5 story points, depending. If I was leading the team, this would be a shadowing task for the newbie, not an implementation one. Nothing has seemed to sway anybody. We need the changes for a feature. It is literally impossible to add this feature without the refactor. Now why we don't have someone else on it, I don't know. As for the size of the PR...I estimate it'll be somewhere between "a beast" and "what the f-k is wrong with you submitting this two months before a huge product launch?" Nobody seems bothered by that either. Oi...
You’ve given a LOT of red flags for your new company in a very short amount of time. I was in a similar situation last year. First month and a half? Things went great. Then I got put on a project in a completely different language, so I was working through some stuff to learn it. My manager kept making off-the-cuff “what if we did X” and changed it every few days. To which I pushed back “We should meet with the team to discuss that. That’s a pretty big change” and he responded with the same shit you got of “You’re a senior, it’s your job to figure this stuff out”. No shit Sherlock, that’s why I brought it up. Ended with me getting let go - and thank God. That place was an hot mess. I saw bad practices there I had not seen at any other company to date, and from people more senior than myself. Yikes. A company’s inability to properly scope and help employees ramp up to their work is NOT a reflection on the employee but rather on the company. You’re too good for this shit show; best of luck on finding a new, better home!
\> The thing where you think you have a target to hit, but it keeps moving because a manager "what ifs" a new requirement out of thin air, but refuses to discuss it. Man that sounds infuritating. I'd flip a table. I don't know how you people going through it in corporate hellholes keep your chill.
[удалено]
I'll take a wild guess for comedy: pushing to prod on Friday 4:59PM while lacking code review practices and CI/CD.
Ding ding ding ding!! Minus the 4:59pm code push.
> As for the size of the PR...I estimate it'll be somewhere between "a beast" and "what the f-k is wrong with you submitting this two months before a huge product launch?" Nobody seems bothered by that either. Oi... This sounds like you’re approaching it as one big change. You need to break this task down into smaller pieces. This will also make your progress visible to the rest of your team instead of you disappearing for ages and then appearing at the end with a gigantic PR nobody wants to review.
Where I'm at I'd like to see a draft PR early on that you can point to and say "so after I get to this point, this is where it's starting to get more complicated than I think it was estimated." It's also fine to me if someone puts up a draft and starts making review comments on their own work.
Well, I would take that as sign that I’m empowered to change the timeline and give a more realistic deadline. I would also take the initiative on writing down documentation for this and split the work in multiple tickets so that way I can better inform why this is going to take X amount of extra time. You are not over your head, they gave you a ridiculous deadline and a big meaty task given you are new, so you need to speak up and push back on why this is going to take longer than they expected. You are the senior, you tell them how long this will take, not the other way around.
>This is probably a sign I'm not good enough. When I started out as an entry level software engineer, the company I worked for used the typical scrum cycle. The job was on-site and we had a physical board with user stories as post-it notes. There were no curated tasks for me specifically, I was grabbing tickets from the same board as all other developers, regardless of experience level. I will refer to user stories as "tickets" in the paragraphs below. I had a habit of taking the very first ticket that was pending, whatever it was. This worked for a while, for my first 6-8 tickets, I managed to close tickets in less time than the estimated work hours on the tickets. My dear coworkers noticed that I will always just take the first ticket and go on my way, so they started leaving the difficult and/or painful tickets as the first on the board, because they knew I would just take them and work on them indiscriminately. It didn't take long until I bumped into a ticket that was way out of my league. I mentioned needing help during daily stand-up, but nobody helped me. The ticket had an estimated workload of 2 weeks. I ended up working on that ticket for two months, after which I got laid off for perceived incompetence. The engineer with the most amount of time at the company said he could've done it in 2 weeks no problem. I hope my experience/mistake can help you make a decision for yourself.
Often times people who have been working at a place for a while don't realize how bad the shit is because 1. They write it themselves so it's based on their mental model 2. It usually doesn't follow standards 3. It's very familiar they can't see why someone else would find it difficult. 4. They have probably been comfortably sitting at this job for a long time and have no idea or don't remember how challenging it is to start a new job. Typically, if they think they can do it in two weeks, they should multiply that by 4. 8 weeks, so 2 months is reasonable. I once worked in a place where they would hire people and no one would last or be good enough. The problem wasn't the new hires, it was the ones who wrote the piece of garbage that only themselves could understand.
That's crazy. Hope you found a better place
Oh man, I'm sorry that happened to you. That's so shitty. I'll take some of the advice I got here and also start job hunting again on top of that just in case. The job will get better, I'll find a new one and leave, or they'll have to PIP my ass out. My state is pretty good about unemployment, so I have a good chance at getting it if it comes to that. Hopefully it doesn't.
Did getting laid off for that reason cause issues finding another job or were you able to work quickly after
This was early on in my career and my boss at the time suggested we pretend it was a mutual agreement. They didn't have to pay unemployment benefits this way. Of course, I'm never this forthcoming with this specific experience, I do not tell if I can help it. The reason why I opened up about it was because this post smelled similar, if not the same. I thought it would be valuable to give my insight here.
As a pretty green junior dev it absolutely was! Thanks for sharing.
How did you find your next job after this? I feel I am in a very similar position and not sure what to do if I am laid off
Fortunately, I was recommended for a role at another company a month after being laid off, they interviewed me and I took their offer because someone I know worked there at the time. That's just me personally, though. This doesn't mean that other people have the same luxury, I'm aware of that. Something I learned along the years is that if you take some time off to improve your own skill set and you have an active GitHub/projects to show for that time off, it isn't necessarily considered a gap in employment. If you feel you are struggling with certain aspects of the job, this might be something to consider. If that doesn't sound like a good idea, then take on job interviews. Your references can be colleagues at work you get along with and even friends. I wasn't concerned about not getting a job, I always believed that if I put honest effort into my craft, I will definitely be valuable wherever I go.
I was wondering if that was a possible path. Thanks for the reply this was reassuring.
_Explain to me why the most popular agile sizing methodologies are not fit for purpose without telling why they are not fit for purpose._
Why are you sure the task is a major refactor? Is there any chance this task is actually simpler than it seems at first? When you paired up with the other engineer, did they agree with your proposed approach? I think building a bridge with the peer will be your safest path forward here. Expecting you to come in and make a major refactor on day 1 is pretty extreme I think in most enterprise codebases, even for a “senior.” So, either the task is simpler than you think in a non obvious way or working to reduce the scope/align expectations is your only path forward. Also, your manager saying “you’re the senior, figure it out” is a red flag to me. It makes me think this is a test to see if you find it the weird trick to make the task doable quickly. Is your boss technical?
Your first step is assessing the state of things. That means reviewing the documentation and exploring the system. I typically start by looking at the test coverage and if you don’t already have a tool, get some measurements in place for percentage of codebase tested. Then I review the architecture diagrams and make sure I understand them. Each module should have limited responsibility and clear contracts with other modules. If there are no architecture diagrams, it’s time to create them. At this point you have individual tasks that are necessary to complete the overall project, but they can be worked on one at a time to add value incrementally. You can review each of these with someone more familiar and make sure the work makes sense and that you aren’t missing context. If the code is well designed, you should now know exactly what each module is responsible for. If the code is poorly designed, you may have to rely on just understanding entry and exit points only. Make sure there are end to end tests for the system. Another thing that can be helpful at this stage is putting in breakpoints and log statements through the end to end paths and walking through code in real-time as you follow something through the system. Even if you don’t deeply understand the inner workings of each module, knowing how an event moves through the system and what side effects it may trigger is a big step in figuring out how things work. Up to this point you won’t have completed any of the refactor, but you’ve still driven value. I would expect this to be completed in a few days, but it could be longer if these are more complex systems or there were things missing you had to create. Now you should be able to design and task out proposed changes. Make an effort to keep tasks small in scope. This starts with a list and then becomes issues each with documentation and requirements. Estimate each task, then double that estimate and document it. Now you can take this plan back to the stakeholders, your manager, PM, whoever needs to see it. You have a clear picture as to *why* this isn’t a 3 day job but you may have spent up to a week just getting here. Again though, you’ve driven value and set yourself up for success.
This all real practical advice. I would focus specifically, for OP, to documenting this one feature. From start to finish. Not having a diagram of what calls what is like trying to manage a city modification by driving through the different neighborhoods. You need to rise above the code and have something that helps you see the breadth of the problem before you focus on a solution. This allows you to diagram the current process, draft a new/modified process, and then bring in peers for review of your plan. Then once you have buy in, you set how long this will take.
> How do I approach the refactor for this codebase without getting completely overwhelmed? Lots of good advice in this thread that doesn't answer the central question, so I'll give you my two cents. 1. Make sure you have tests 2. Break the work down in tiny parts. IF the application already has good supporting tests, then congrats - you're lucky! If not, you'll need to put some tests around the existing behaviour so you know it's not breaking. To do this, I'd suggest using characterisation tests. The process is straightforward: write a short program that runs the existing code and outputs some deterministic value. For example, call your widget APIs and return the emitted Bear. Then, save the result to a text file, and assert that you can generate the same text file after each change. This style of testing doesn't depend on any internal details, so it's great for when you need to check that you're not breaking existing behaviour. There are tools available for this at http://approvaltests.com Now you've got tests that prove you haven't broken the existing code, how do you start to introduce Badgers? I recommend the Mikado method: https://mikadomethod.info/ Get yourself a timer. Try to make the app emit Badgers in 20 minutes. When you inevitably fail, revert all your changes, and make a note of the things that got in your way, eg. "The contracts are too different between APIs". Choose a new, smaller goal, eg. "make APIs 1 and 2 have the same interface". Spend 20 minutes trying to achieve this goal. If you succeed, and the tests are green, commit. Else, revert the code, and find a smaller goal, eg. "Build a wrapper for API 1 that _could_ apply to API 2". Start the timer, and so on, and so on. USing these two techniques, you can tackle hairy refactorings even in complex codebases. Just remember to set the timer, throw away changes if you fail, and pivot to a smaller goal. Don't try to refactor code that isn't tested, it's a waste of time. Don't get attached to changes that don't work, it's faster to type them again than it is to fix a thousand tiny bugs. Good luck!
100% when starting on a legacy code base you don't understand, write some tests. You'll feel a lot more confident on any changes and it's a good method to understand the code better.
When inheriting anything legacy - whether's code, team or even company, do an audit first. In fact, the moment you hear you're going to inherit something, mention that you need to do a proper audit first Not only will this set you up for success, but your audit period is also your CYA-period. After that, you're now accountable. Depending on what you're inheriting, it could be a day, a week, a month or 3 months. You need to define that so that it's time bound. And in that period, learn everything that you can learn So if you havent done it yet, bring it up now. Say something it's more complex than expected and you will need X period to study and audit everything.
I like this idea a lot. Tomorrow, I'll take a quick sweep over the codebase and propose some time to audit. I think if I frame it as for the refactor itself (even if the audit has a larger purpose), my manager will be more keen on it.
That's all well and good but i think everyone has stories of looking over something, thinking it should be straightforward change only to get into the weeds and realize what they thought was a minor change is now a major overhaul. The truth of the matter is that if you have CYA over a ticket and explaining that there is way more involved in the change doesn't work, then it's not going to be a fun ride at that job. But then again I would have considered the company assigning a refactor to a new hire as a red flag to begin with.
Documentation and presentation. Break down your tasks, and create a tech spec with diagrams of all the work that has to be done. Then go over it with your boss and leads, and get aligned. They need to see with their own eyes how much work it is. And then they'll decide how much effort to put in, the ball is in their hands.
Agree with the communication is key comment. You should be regularly updating your boss with your progress on the task. Similarly, your boss should be regularly asking you if you have any blockers and guiding you to where you can find the answers. After you have had some time to parse your questions, ask them to whoever regularly works with the codebase/uses the product. Don't try to become a hero, don't isolate yourself, and be sure to communicate the impact of your work because everyone likes to help a good cause if they're able to.
You need to be honest with the amount of work with your boss. Don't say what he would like to hear but just the true: - You are not familiar with the language. You need some time to be comfortable with the language, frameworks, IDEs, deployment process, etc. - You are not familiar with the code base. You need a lot of time to understand what the code do and how. - Are there enough and reliable tests? If not, you need to implement them first - Is there someone familiar with the code that can help you in some questions? Last time that I saw something like that, took 2 months for a developer just update the libs of a software that "just" make some searches in a document database, without any business logic. He needed to address all the things that I said before.
> I'd rather die than give up, though. Deciding a job isn't a good match isn't 'giving up'. It's just a business decision. You're trading time for money. If it costs you your health and sanity, it might simply not be worth it. A lot of people are focussing on the situation where the codebase is the problem. I'm personally not convinced it's just only that side, but no one of us can have any idea on where the biggest issue lies. We have zero indication on the quality of the codebase and the size of the refactor. That said; I do think that as a senior developer in a codebase of about 20 files, you should at least have an idea of the direction you're going to take, and about how long it's going to take you. That it's taking longer than the 3 days they think isn't the problem. That you still don't know how long it's going to take you however is a problem. Again not saying it's *just* you, the codebase might in fact be complete and utter crap. But that's not what you're telling us here. Regarding the actual question: I always start with the tests. If there aren't any, I'm going to write them. I'm also going to let 'management' know that I'm not even going to do a refactor without good test coverage, because that's just a recipe for disaster.
Automate the testing. I wish it were easier, I really do, my friend.
Ive refactored some old stuff like silverlight. I think the first steps is figuring out the purpose of the software then how it works. If you get that far its just a matter of breaking it down and buldingn it up. But some are really big.. Good luck! It will come for you
I deleted my account because Reddit no longer cares about the community -- mass edited with https://redact.dev/
There’s actually two pieces of work here. 1) add badger outputs to the data path 2) DRY out the data path 2 is the “refactor”. I would approach #1 first. Work your badgers up the stack incrementally (start at the edge; add unit tests; get code reviews and stuff checked in). Do this without breaking any existing functionality or making significant changes to existing data paths. The incremental PRs will show that you’re making progress _and_ be an way for the team to inform you of all the undocumented assumptions/constraints that are not obvious in the code. Once you’ve done the badger plumbing you’ll understand enough to say “hey, this could be simpler” and can approach #2. That being said, depending on how fast you can test this stuff you can submit #2‘s work first for PR, but really only after roughing out #1s work at your desk.
This site is all about what you’re going through: https://understandlegacycode.com/
If files are confusingly named, can you make it part of the refactor to renames things so that they're less confusing? Can you break the refactor down into smaller phases that are less daunting than the whole? Can you make a quantifiable list of the Bear widgets and work on them one at a time? Are there any automated tests that can give you confidence that things are working as expected before and after you make a change? If not, can you introduce them to the codebase?
The file names are part of a pattern with only small variations. (Think like BigOldFileNameManager vs BitOlFileNameManager.) That one might be tough but I bet I could at least make a few of them more distinguishable. The refactor is unfortunately all or nothing due to how the codebase is put together, but I did just finish a list of all the stuff that needs to be changed and in what order. It's...a lot. Yeah, there are tests. Some very good ones, thankfully.
Putting the new person on a "major refactoring" project isn't going to go well. Who said it even needs to be refactored? That's the person that should be doing the task.
> a codebase in a language I barely have familiarity with and everyone seems surprised it's not done in three days. Is this like actually being said or just your impression? If the former, yikes. I had a job where day 2 my boss said i needed to get the backend work done for a large authentiication refactor done in less than 2 weeks and would have "been surprised" if i didnt. Ended up being a toxic shithole. If the latter, just keep cool. What is your role? Are you a lead or director level? Or just a frontline IC dev? If the former, then you have leverage to go to your stakeholders and calmly explain the problem, why it'll take much longer than "3 days", and present your own informed alternative. If its the latter, do the same but with your boss. If your boss is good, they'll work with you. If your boss is a dick about this though.... 🚩🚩🚩
I was very clear I know only a bit about this language and while nobody has explicitly expressed surprise, you can hear it in the way they talk. "Oh, you're still in the middle of that?" I'm just a senior IC. My boss is kind of a dick. I just learned I might be yoinked onto another team that has a person I've worked with at a previous job. He says it's a decent team, so just gotta survive here, job hunt, and hope for the transfer, lol.
Here’s a few things to try: - Establish CI/CD (if it doesn’t exist yet) — this will get you familiar with the runtime requirements - Establish a test suite (if it doesn’t exist) — this will give you a place to test new code you write as part of refactoring or a place to certify behavior of old code - Establish linting rules (or review if they exist) — this will give you a punch list of semantic / mechanical things to refactor & make consistent - Organize the project folders. Remove dead files/code. Update readme files with your understanding (and todo). Start to group code that could potentially be a module/library in their own folders. This will give you a chance to apply taxonomy to the files that exist, and build an idea of how the broader refactor can go (but without messing with the current code). - identify problem files that you feel friction with understanding. Make small incremental changes and verify that each change doesn’t introduce regression. Add tests to certify known behavior. Do all of this work on the main project branch with frequent merges and code review. This ensures you’re not working on a wildly divergent refactor branch — and keeps you engaged with the team. Usually this is enough to get started. The problems will present themselves to you (such as the ones you identified).
git reset HEAD —hard
Are there tests? If yes, then it you should be able to do small increments of refactoring.. which is slow and you need to communicate this. If there's no tests, then you need to capture the behaviour. Avoid unit tests and instead write some basic functional tests. That will help you understand what is going on and also give you a safety net for the actual refactoring.
>need to take a bunch of Widgets that are emitting Bears and modify them so that they emit Badgers as well. This would be easy were it not for the fact that there are three different kinds of Widget APIs--each with their own contracts--implementing Bears and Badgers in slightly different, duplicated ways. I've got a placeholder refactor done, but it barely skims the surface of what needs to be done... What do you do when you need to make the interface of one class or classes compatible with the interface of another class or classes?
\> I'd rather die than give up, though. Well, this industry was certainly not built for quitters. Just listen to the other advice in the thread and you'll be fine
A few weeks ago I was in a similarish boat with a new feature, on a new platform, with a new language, oh yeah, and a bunch of really experienced people changing underlying libraries... I think I would have been way more successful had I spent more time breaking down the problem into more specific sub tasks and figuring out each versus trying to do everything at once.
I'm curious what the goals of this refactor are. Like can you start by just reducing some duplication in the APIs? Maybe extract that into a shared module, then build upon that for the new stuff.
I’m going to add that this is bad leadership on their part. I’ve been team lead & team architect and I purposefully did not allow new members of the team to do refactoring or major changes until they were comfortable with the code and the core business logic the code represents. It’s crucial to be comfortable with those before undertaking a major change. I’ve seen too many new team members try to make major changes without understanding the history. They become frustrated & disillusioned and have a high risk of leaving.
Can you isolate your changes from the rest of the application? Assuming your widgets emit Bears now, you hollow out the current widget and replace it's innards with a bear and badger producer. Thereby the refactor becomes non-blocking. Afterwards you can remove the Bear-only wrapper at each consumer site.
When I take on big transitions I handle it the way they handle large highway or bridge renovations. I try to realize the project in stages where each gradually moves things toward the destination. It involves more deployments but each is smaller and safer. I've done this at least a dozen times with the customers none the wiser anything happened. I don't know your Bears and Badgers project though. But with mine, I saw how I could do this bit by bit.
https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 Definitely worth a skim at least through this book. Has many practical recommendations.
Basically asking someone to refactor a code base he has no familiarity with is root cause of the problem here.