Hacker News Reader

Comment by nicoburns | Hacker News Reader

Is the suggestion that high quality code is slower to write / iterate on? Because that hasn't been my experience.

I think there are some code quality trade offs you get for free. You should always make those, like don't write shitty variable names.

But there are a lot code quality decisions where increasing quality costs more time. (at least in the short run)

Code consistency - When you write one module one way and a another dev writes it another. Do you rewrite one of the modules for consistency?

Doing the "Right" thing - When there is a better solution and a faster solution that is maybe less maintainable. Which solution do you pick?

Corrections - You wrote some code while learning a new library/technology/api and find that you used it poorly. Do you go back and clean this up?

Code Reviews - How nit picky are you? How good is good enough? If a dev writes out a large feature and you don't like the way he did it do you ask him to fix it?

Database Mistakes - as you learn about and build out your app you realize you made the wrong choice with some database modeling, do you fix it or write unnecessarily complex SQL to fix paper over it?

Analyze or fix CSS - A button looks weird, you're not sure why the css is causing it to render funny. Do you do a deep dive finding the root cause or do you just jam some inline css in there?

As you say, some tradeoffs are free, others aren't.

One mistake I made is introducing a complex state management solution early on (NGRX); it had many benefits for code quality and overall FE architecture, but it also introduced additional layers, which required more code here and there for all details.

Entities that we get back are stored separately, then put together through selectors when they're needed on a screen. And all that jazz does take time & energy.

The net result is data consistency across components/screens (which is great), separation of concerns and clean code (cool), but at the code of slower development.

Even though, as I'm writing this, I also think about the alternative. Not having it means having less structure, maybe more issues to fix everywhere due to the lack of consistency, etc. It's not a choice that I can weigh easily, even now. I knew the tech already, used it in production before, and it still wasn't easy after all. Details details ^^

First, great blog post.

> The net result is data consistency across components/screens (which is great)

You probably don't need to be told this, but... how badly was the data really going to drift during a session? If a user notices that part of the UI is stale, they just hit reload, not a big deal. This could be improved later.

Yep, good point. I do see it now. I absolutely didn't back when I started working on that.

I had just delivered & supported an enterprise front-end framework (https://stark.nbb.be/) for which we HAD to help fix issues with state management.

But of course, I just looked at it from the wrong point of view... The point of view of a technical guy, and not the one of a founder.

I'm learning.. ;-)

Back in the day a lot of OO startups burned precious time on taxonomy debates and UML diagrams. There are productive code quality discussions, and ones that don't ultimately matter.

I think one can make the argument that it’s cheaper (in the short term), but I agree that it’s not inherently faster to develop. But experienced devs who can build high quality well modeled software fast aren’t cheap, haha

That depends on the developer, some need to slow down, go back and rewrite, etc. Others write naturally good code without much extra effort. Maybe partly experience?

Reply on news.ycombinator.com