Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
rutee07876662dClone it into a lower environment and test it. I find that people who pass on knowledge by explaining the process rarely remember how their code really works. It's better to find those loopholes before he's gone. Going through the code, testing, and "experiencing" the process yourself instead of just accepting what he says will help you understand the whole thing better. If not, you can ask for clarifications.
When that happens, this "regular app dev" feeling will go away because you will feel more involved with the codebase and believe me, you will find something you'd want to change or improve. There's always something. The priorities can come up after that.
vomitmachine21961d@rutee07 So in tandem with doing all this priotization. I've actually been doing something like what you're saying but on the main project that sees a ton of maintenance. You're super correct, he doesn't remember where 90% of his codebase is coming from or how it works, I've tried keeping him engaged but he just disregards it at this point.
I'm currently working in our dev environment and have a few things to fix before upgrading to prod. The last developer at work also suggest partitioning the work I plan to do on this monolith into small chunks and pushing out stuff like a layering update piece by piece. I feel like that has some really good merit and could get me off on a good foot.
There's still some stuff I don't fully understand about the big project but I'll be able to figure it out come next week when he's gone. Thanks for your insight man.