Also, when I see a codebase I don't understand, if I'm paid to work with it, I spend my time learning the stuff. Debugging tools help: traditional general-purpose debuggers, graphics debuggers like pix/renderdoc, network tools like wireshark/fiddler, OS-based tools like strace/procmon. For different projects different ones are the most useful, sometimes even custom built tools are most useful.
Ask HN: Have you ever inherited a codebase nobody on the team could understand?
171–180 of 222 posts
Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?
#172Earlier quoted context omitted.
>maintaining bit-for-bit identical output The worst projects are those when the company doesn't really want to upgrade, so the only requirement is "make it exactly like the old system" In my first job out of college, I upgraded an approval workflow engine from VB3 to C#. It was written by someone who had never heard of state machines, so it had a weird ad-hoc design that would e.g. get confused if two documents were…
If those calculations are business rules, then you absolutely do need to make it output the same as the old system in those ways because its the foundation upon which a bunch of assumptions are made.
Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?
#173Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?
#174Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?
#175Earlier quoted context omitted.
Same - send us some info so we can do this too.
I'm not OP, but I would be turned off by this comment because it sounds demanding.
Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?
#176Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?
#177No. I have inherited code that is very difficult to understand, though. What typically happens is that it is mostly left alone. As the years go by, small changes are be made, only making the situation worse. Developers occasionally offer to management to take the time to refactor it, but management refuses to prioritize that work. Eventually, new requirements are drafted that the existing code simply cannot meet with…
So it's a matter of 1 vs 2 refactors, and the management chose one by delaying as long as possible.
Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?
#178I’m a consultant and make a living saving bad projects. That’s literally why I get phone calls for work. Keep in mind that I work in high level modern languages, I’m sure there’s some crazy proprietary cpu running a robot in a Detroit factory. In any case there’s never been something that I’ve run into that I’ve not figured out. It takes time, and the hard part usually is not figuring out what it does but the weird e…
Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?
#179I once inherited a large enterprise system I had to build a full working development environment for and then learn the code base and help bring a team up to speed. The product was essentially made up of 5 code bases in a single repo that built and deployed 5 different executables that worked together. That itself wasn't so bad, it was mostly modern C# and I found it a decent code base to work on. What was bad was th…
Ha, I just left a job that had multiple VB6 apps and services that we were actively maintaining and extending. Getting the development environment setup wasn't too bad. What drove me bat shit crazy, was the fact that the mouse scroll wheel isn't supported in the IDE. I was part of the third team that left in as many years. Just another lesson of a single individual being the only decision maker across all departments…
I legitimately can't work out if such an intolerable boss is more painful or the constant need to scroll the IDE and having to do it without the mousewheel.
I feel for you. I truly do.
Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?
#180Earlier quoted context omitted.
Being able to solve those problems like "it ain't no thing" is part of being a senior developer.
Sure, and man are the easy wins satisfying. Fixing shitty data access methods/patterns is one of the easiest ways to get a "WOW!" out of a client or product owner if you're stuck in the low-visibility silo of backend dev[0]. I've just been repeatedly surprised over the years at how very, very many people are making real money, and consistently finding work, yet don't seem to know which way is up. And I don't mean gre…
I'm dying.