Ask HN: Do you have to write lots of complex code before you can simplify it? | Hacker News Reader

Ask HN: Do you have to write lots of complex code before you can simplify it?

5 pointshoodoof11 comments

Ugh.

I have to write so much complex code to make whatever I am building work, then I have to go through a challenging phase of simplifying it down to the minimum working code.

When I look at the minimum working code that is the result of this process I think "why the heck couldn't I have written that simple code in the first place - it would have taken me 25 minutes instead of 8 hours".

Blah. I'm sure some genius programmers out there only ever write the minimum code in the first place.

View on HN

Sounds normal. At first you want to get something that works, and works correctly. This is rarely achieved by small and optimized code.

Once you have the correct code, you'll also have a more complete understanding of the problem and it's parts.

At this point you can start simplifying, optimizing and so on.

Also, having a correct code makes that job easier, since now you can have both a proven set of tests and a reference - errors are trivial to catch.

> I think "why the heck couldn't I have written that simple code in the first place - it would have taken me 25 minutes instead of 8 hours"

You didn't know it back then, now you do. The path from there to here resulted in that understanding, and the hindsight through the understanding makes the past looks absurd.

Where are you finding you're rewriting the most code? Is it around the interface or data structures at use inside the code? Or something else entirely?

I find getting the data and data structures correct leads to the simplest implementation -- and chipping away at the code as you go along trying to make it simpler and faster is usually how a solution evolves.

I don't know if anyone writes the perfect implementation of anything complex the first time -- you have to work at it.

Alot of it is trying to make something work but not fully understanding how the framework I am programming works, and as my understanding grows of the framework I keep pulling apart and modifying my code.

Eventually I get the code to behave in a predictable manner and get my functionality implemented then I start removing all the dead ends and mistakes and misunderstandings.

Rinse and repeat several times until the code is as simple as I want it to be.

Well, it seems like once you learn the ins and outs of the framework, things will go more smoothly? I've avoided complex frameworks (or ones that have too much magic baked in) for this reason over the years.

I embrace frameworks. Short term learning pain, manyfold medium to long term gain.

It might be hard to learn to drive an 18 wheeler but better than building it yourself.

But sometimes all you need is a bike. Or a pair of sandals.

I don't have to, I think, but often writing more-complex code than I'd otherwise want is sometimes the most efficient way to get things done, because otherwise I'd get stuck in analysis paralysis. Also, I tend to shy away from the more "succinct" option because it seems like it'd lock me into certain choices, with more edit distance between design decisions.

It's standard iteration process. This is why most of design and development process diagrams are displayed as continuous circle. Nothing has been perfect for first try.

Speed and/or size improvement in next iteration is much better than completely reworking because of: missed or bad requirements understanding, compatibility issues etc.

As was already mentioned, you have to have something working. Only this can be improved. Without working code any speed or size optimization is useless.

This is pretty normal.

Remember 90% of code is crappy. Your job is to make something work, and then you can go back and make it work better.

That's like expecting to type out an essay perfect the first time. It's perfectly normal to write a draft and iterate on it many, many times until it gets good.

With coding, it can take a while of working with rough code to identify the abstractions that simplify problem.

Yes. One way to shortcut the process is to write some design notes prior to typing any code.

This design could then be reviewed by your colleagues.

This is the same mental process but may save a lot of tedious typing and then undoing again when you consider a better design

Reply on news.ycombinator.com