Sorry to hear about the burnout. I hope you are on the right way to recovery. Hang on and take care! I hope my 2 cents as an internet stranger can help.
Indeed, the default should be to assume the best intentions of people. Also, people can have a bad day and be snarky. Next meeting they might as well be friendly.
Staying positive and not letting (potential) negative feedback derail you, works like magic in the long run.
If someone is really picking on you, or they genuinely disapprove of your work, you will find out in due time.
I would argue that legacy code has more chance of going along with test code than new code. Often code is written and tests grow during its maintenance.
Another thought... if I'm tasked with maintaining or adding features to existing code, should I feel responsible for writing tests for the existing codebase?
- There is usually a "test" folder, but what they test look nothing like the actual code, they often don't even compile, and if they do, they fail, and if they don't, that's because every failing test is disabled.
- Refactoring? What refactoring? Usually, all you see is an ugly hack, usually noticeable because the style is different from the rest of the code base. The old code is generally commented out if it is in the way, left alone as dead code if it isn't.
- Writing tests yourself? It would require you to put the test framework back in order first, they don't have the budget for that. Something as simple as reformatting the function you are working with is already a luxury.
- Sometimes, some refactoring is done, but that's only to add new bugs as to keep things exciting.
Still, as surprising as it may seem, I actually like working with legacy code. It is a challenge, understanding what it is doing (without reading the documentation of course, as if it exists, it is full of lies) and trying to leave it in a better state than it was before in a reasonable amount of time. It is great at teaching you all the antipatterns too, very useful if you end up in a greenfield project later on and you don't want it to end up like all the legacy code you have worked on before. If people actually use it, it will, but you can at least delay the inevitable.
> Another thought... if I'm tasked with maintaining or adding features to existing code, should I feel responsible for writing tests for the existing codebase?
Do you trust yourself enough to not break existing code while maintaining or adding features to it? What would be the consequence of you screwing up? Where would your screw up get noticed? Is it a scary person or group of people who will chase you down to fix it?
I've worked long enough to not trust myself at all anymore, regardless if it's old code or new. Then I evaluate according to above. Usually I land firmly in "yeah, better test it"-territory.
The goal of existing and new functionality is reliability.
What you touch will be on you. So writing a test for your own things, and testing what you are using of the legacy code as you go is a good way to maintain your own coverage in case someone else breaks something in the legacy code, or maybe an update to a library or something goes sideways.
Since you'll be doing a good job of mapping it out below is something elsee. The nice thing is LLMs can help a lot with writing tests.
Reliability can be achieved in a number of ways.
Where I've come across an unknown spreadsheet gone wild, or a code base who's jedi knights have long since vacated, I try to get a sense of putting together the story of how the project started and how it got to where it is today.
If I was cold, I'd first focus on the most critical parts, the most complex, and most unknown potentially to put testing around first.
If refactoring was a goal, for me that means it has to run the same as the old code. One way to do that is see if the existing code can become a service that can be compared to the new service.
LLMs have been really fascinating for me to apply in this regards because I've had to map and tear apart so many processes, systems, integrations and varying interpretations and memories.
AI can even explain what most code is doing no matter how convoluted it is. From there, things like test driven development, or test driven legacy code stabilization is much more doable and beneficial not just for the legacy code, but keeping the AI behaving if it's helping with coding.
>Another thought... if I'm tasked with maintaining or adding features to existing code, should I feel responsible for writing tests for the existing codebase?
Write tests for new additions to the code, when making major overhauls to sections of it, or when a bug is discovered that the old tests did not catch.
Those are the 3 cases I would say you should add a test.
#3 is most important, in my experience.
I'm confused. The only thing both have in common is that they are pens. For the rest they are on opposite ends of the pen spectrum. Unless a pencil or a felt tip are called pens as well?
The thing is, writing on paper is much slower and hurtful than typing, but then again maybe that's the point when the goal is to keep it brain-stored and understood.
Belgium: the only handwriting i can do properly is cursive (each word is a connected string of curly letters). I often cheated on the capitals because they are a bit grandose curly in cursive. We wrote notebooks full with cursive in different languages, that's how most languages were thought. My 12yo kid was thought exactly the same hand writing but he has to write less because the usage of fill-in books in stead of empty notebooks.
