Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I really enjoy refactoring. Like, doing it by hand (5 miles uphill in the snow both ways) rather than AI. I don't even understand why I enjoy it, because if done right, there's no visible change. When people ask me why I'm so pumped up after having worked on the codebase all day long, I can't give them any sort of answer that makes sense (coming from a small business with a smaller dev team). It's just... "I'm future-proofing our website and we won't see any direct results today but things will be so much easier going forward..."

There's something about the puzzle. Looking at my old, deranged coding workarounds that tried to solve problems that have already been solved a thousand times before with established paradigms; and then moving them toward said best practices; and doing it in a way that no NEW technical debt is created. It's just satisfying.

I think one of the best learning experiences for me has been the fact that I created a bunch of sloppy shit by hand, auth and all, which forced me to learn things the hard way. All along the way, people were shouting from the rooftops: "use established libraries, dummy!", which is the same advice I would give to somebody today. But by doing things the hard way, I learned so much more about the inner workings. And, I've also given myself a decade's worth of refactoring work, which I really enjoy!



Probably it's just the same dopamine hits that make things like watching the Windows 98 Defragger soothing.


Me as well. One of my formative experiences was reading Refactoring (Fowler). At the time I felt skeptical that it could make a difference --- I had mostly written scientific/research code at this point. I decided as an experiment to apply it to a dissatisfaction I had with the structure of a codebase and it was a revelation. It really made it really concrete what people meant by "a codebase is a system", made me see code from a higher level, almost like a continuous tissue or web you could pull and prod.

It's quite sad to think this experience might be on its way out, and it really highlights that "junior problem" from AI. There is just no way around diving in to get an intuition for things. Naur warned us of this 40 years ago but the lesson never seems to get learned.


> I can't give them any sort of answer that makes sense ...

Pride of workmanship. For those who understand, no answer is needed. For those who don't, no answer will work.


Ha, many years back I had to write a template processor for some system configuration handling. Manager told me last guy did most of the work so test and wrap it up. I instead had to throw it out as it was so crappy, wrote much smaller code, with no dependency and really put soul in logging where it showed cleanly how tool is navigating all directories, picking placeholders and replacing with values and so on.

No one really cared but it satisfied me and make me really happy.


I'm curious how heavily you have test suites built up as guardrails while doing this, to prevent regressions and such?


I have often done huge refactors over the last 20 years on systems where there are none. It's very satisfying turning a 1,000 line class file into 100 lines.

But all my refactors have been in statically typed languages.

To speculate on the reason why, which the GP asked, I think perhaps it is two things. It's the same satisfaction from tidying a room or your workbench. But it's also slightly narcissistic unfortunately. I think you've shown you're better than the other programmers. Much, much, better when you end up with massive reductions in TLOC.

And with tests, the irony is that the resulting code is often so much easier to reason about, you start spotting really obvious bad assumptions in the original implementation.

It's one of the reasons I've always been fairly skeptical about the true value of unit tests (integration, I get). That and the fact that projects I've worked on that did have unit tests catch like 1 bug a year. Maybe it's just the size of systems I traditionally work on (smaller teams, or even 1 person teams, so man-years worth of effort rather than decades or centuries).


I enjoy studying different refactoring patterns and real-world examples.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: