
Ask HN: How do you do the groggy code you don’t feel like doing? - rjromero
When you first start a project, the coding space seems “open” and you can’t do anything offensive or messy, as time goes on however this window really closes and you end up having to code within more and more layers of complexity. Towards the end you’re really down the pipe and you are writing code between 6 different classes inside deep nested functions and checking callbacks, etc...<p>I’m sure you know the feeling. It sucks. It’s really easy to start a project and get going but over time it’s just really really difficult to manage a growing codebase. In fact I’ll get 90% of the easy code done first and love it and then procrastinate the last 10% forever.<p>So how do you prevent this? What programming paradigms do you use? For me at least this is really a problem with giant OOP projects where it can get sticky between the classes and who is a delegate of what and who calls back to what.<p>How does anything ever get done in gigantic codebases for operating systems and planes for example? Maintaining a codebase of that size honestly sounds like a miracle.
======
FroshKiller
I always approach my work as the solemn responsibility to respect others'
time. Every necessary change I shirk from making will waste the time belonging
to users and other developers. It's very easy to do boring work when you can
appreciate that you are preserving the most precious resource there is.

------
mabynogy
> ...really a problem with giant OOP projects...

OOP is an issue in itself in most languages providing OO features (excepting
smalltalk).

It's worse with statically typed languages.

> What programming paradigms do you use?

Write DSLs. Avoid using/writing frameworks.

------
muzani
It's a psychological thing. It's the dirty work. Someone has to do it.

I just grab a couple cans of Red Bull, some L Theanine, pull up my
metaphorical gloves and go in.

The book Mythical Man Month states that in large codebases, about 1000 lines
of code are written per person per _year_. Coding style can be perfect and it
could still be a pain to go through. Sometimes it's a pain simply because the
coding style is "perfect" \- it could end up verbose or too clean for comfort.

But you gotta do what you gotta do. Think of all the lives you improve by
doing this. Reward yourself afterwards.

------
mslate
Tests help.

Get color on what kind of mammoth of an existing codebase you'll be dealing
with before accepting the offer.

99% of engineering jobs require working with existing codebases, which in turn
have a huge impact on your on-the-job performance and career outcomes.

It's helpful to get that info up-front if you can. If you cannot, you're in no
position to complain.

