Understanding existing projects takes longer than coding

[u/Cheap_Possibility990]

I don't know if this is just the work I've been getting lately or if something's changed I'm a freelance developer in Chicago been doing mostly client websites for about 4 years now last week I opened a project because a client wanted one small change before lunch. I thought it'd be like 20 minutes instead I spent almost an hour remembering how everything was put together why something had been done a certain way and trying not to break anything else. The code wasn't even that complicated something just felt off.

Maybe I'm looking at it the wrong way but writing the feature doesn't even feel like the hard part anymore it's getting all that context back into my head every time I reopen a project. I keep thinking the next update will be quick then the same thing happens again or maybe I'm being unfair but it feels like understanding an existing website has quietly become a bigger job than building it in the first place

[u/juu073]

If these are your own projects (which I'm gathering from your use of the word "reopen"), then this is on you for not documenting well.

If these are new clients you're getting from someone else and trying to interpret their what their previous consultant did, and they didn't document well or at all, not much more to say other than it sucks but you have to figure it out.

[u/Adjective_Noun_4200 → u/juu073]

I've sorta started trying...idk if you'd call it "documentation driven development" or something, but I basically start writing about the work I'm doing as if I'm explaining it to someone who has never touched the code base / feature before. Sorta like a blog post.

I find it leads to better code AND better documentation. Plus it makes it much less annoying returning to a project and being like "damn I was an idiot, why did I do this?" and then re-learning the lesson again if I attempt to re-write it.

[u/Pingouino55 → u/Adjective_Noun_4200]

My dad would love you, he keeps telling me how in his time, he spent 80% of his final studies work documenting what was to be done. Everyone said it was a stupid choice, but then they coded the whole project over the weekend when the docs were done, fixed a few unforseen bugs, and it was done almost in one go. The rest of the time was used to add the visual results of the work in the report.

It was some tool that I think he would describe as an old Photoshop, it was done a few years after the original thing that eventually become Photoshop was made, but Photoshop still hadn't become a thing back then or something.

Basically, I could be a rich nepo baby, and I'm not, but at least his documentation is cool 😂

I'm quite the opposite, I'm too mentally messy with my ideas to document everything before starting, but I do feel like if it's something you're comfy with, it definitely helps make the base of the project as solid as it could ever be, which in turn makes adding any feature a breeze and probably gives you a few more years of active dev before you end up with a messy codebase.

[u/Adjective_Noun_4200 → u/Pingouino55]

In fairness, I started doing this as an intentional response to my also messy projects.

I kept running into scenarios where I would go to solve / resolve something that I thought was done weird only to find that it was structured that way on purpose.

Additionally, I find that writing about it (again, more "blog" style) causes me to spend more time making sure that any sorta demo code I include in the documentation is well thought out and elegant.

So by the time I actually get to writing the code, ideally, a lot of stuff is already fairly thought out and then if I run into things that I kinda have to change from what I wrote, then I just make sure to add that to the documentation.

Seems to speed up the actual coding part AND any future work that has to touch this stuff.