Hacker News Reader

Comment by declan_roberts | Hacker News Reader

> A piece of advice I've given junior engineers is to write everything twice. Solve the problem. Stash your code onto a branch. Then write all the code again. I discovered this method by accident after the laptop containing a few days of work died. Rewriting the solution only took 25% the time as the initial implementation, and the result was much better.

This is true, and I've discovered it myself by losing a branch.

However, who the hell has time to write everything twice? There's 1,000 things waiting to be written once.

View on HN

I fear not the man who has written 10,000 features once, but the man who has written 1 feature 10,000 times

My <TagComponent /> to render tags can kill a person

I'll bring the portal gun.

Interesting adaptation of the phrase. I think I may fear the 10k feature person more than the 1 feature

You'd think after a decade of writing forms and form validation on the internets I'd get better at it, but nope, have to reinvent the wheel every time for every framework/form library because nothing is ever finished or good enough. I had hopes HTML5 would fix it but it didn't.

You sound much more experienced as a web developer than me, so you probably know this exists, but just trying to be helpful I want to be sure you know about client side form validation in html5 https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_va...

I appreciate this doesn't cover anything more than the basics, so something like the normal behaviour of comparing two password fields for the same content doesn't work, but I find these controls are useful for getting something simple up and running.

This is full of issues. There has been a recent discussion about it here¹, you may be interested on that.

Also, it doesn't do much.

1 - https://news.ycombinator.com/item?id=41976529

this is unironically Ryan Florence and React routers

> However, who the hell has time to write everything twice?

Nobody. The article even says, "N.B. Obviously, don't write literally everything twice. It's a heuristic. Apply intelligently."

how are we going to have a robust internet forum if we are not allowed to interpret quotes to the extremes of their meaning in order to have an easy punching bag for our comments?

That's the part that made the least sense to me. If he doesn't actually mean to rewrite it twice, what does he _mean_? Copy and paste the old code? Rewrite half it? Typically (my "intelligent application") I will read the code I wrote yesterday and make improvements, is that sufficient?

I think the mitigating factor is "slow is smooth, smooth is fast".

If you raise the quality of your codebase, you can implement those 1,000 things faster, and you reduce the odds of they'll have to be reworked.

This only works if you are in charge of the timelines or have a manager who values quality over quantity

And/or an organization that has the faith and politics that allow to wait till smooth starts paying back and becomes fast. Frequently you also have everyone benefiting from smoothness but not everyone contributing to it which results in the folks who pump out tickets as fast as possible looking like they are just strictly better. Easy to adapt to and game as an IC, but I find it frustrating as a manager.

> wait till smooth starts paying back and becomes fast

By that time, you will have probably left the company and someone with less care about code quality will come and undo your work.

Also, like security, it is hard to show to a manager data and graphs showing how much we are saving

Yes, very true. You can only make it work if everyone is bought in and even then it's ready to regress by someone skipping steps and getting praise from the business while other engineers are fixing their stuff.

> This only works if you are in charge of the timelines or have a manager who values quality over quantity

And also if you're not in a bad starting position: you could have a system that is very hard and slow to work with, meaning that you can't feasibly introduce much easy to use functionality, especially if the domain logic is tightly coupled.

> smooth is fast

Such reasoning is based on a flawed assumption: that the value of time is constant in time.

While smooth is indeed fast in the long run, it is slower in the short run, and time before the release date is much, much, much more worthy than time after the deadline.

Shipping functionalities now and bugfixes later is what pays your salary. Waiting for the perfect code makes your customer seek comfort at your competition.

Most deadline are fake.

Tell that to the customer, as a web/mobile agency, when they ask you to contractually commit to a date for the release of their web app

Or when your boss sets a goal for 0 missed deadlines and lets people go for not hitting them.

Yes and no.

External deadlines are often meaningless, but customers are not the only users of the application. Once you release your part and keep developing/debugging/polishing your code, your colleagues can move on with their job and so on and so on.

As unfortunate and unnatural as this may seem to us programmers, shipping _is_ a feature in professional software development; and, in the quality/time continuum, "something now" beats "all of it tomorrow" in every scenario.

PS: I do get that the decision on releasing a product to the public has different constraints in the medical or aeronautical industry than a photo sharing website, still enabling the rest of the organization to move on with their tasks is too often underrated.

Yes indeed.

But you still have to put your stuff out there to test it.

All code is a cost. Features are what users pay for. There is scarcely objectively good code. One person’s smooth is another person’s rough.

Deliver stuff. Act on user feedback.

If you are not developing commercial software, the above is invalid advice.

In the world of professional software development, economic value is king. This rule has marginal declining utility after some point and in some cases it is just not worth it. Think prototyping, tight deadlines, etc. In an ideal world, taking some additional time pays off, in other worlds, it doesn't and gets you in PIP. inb4 you say that's not the kind of company you want to work in, most companies are like these and not everyone can afford to apply and get a place at the 2 companies in your country where code quality is actually valued

I once thought I lost a paper I'd written a while back (before OverLeaf and Cloud), and I've rewritten it only to find it back again: when I compared the versions, the second one had better sentences altogether. The core framing was there, but the quality was higher.

It doesn't get really good until the third rewite, in my experience.

That said I think it's worth noting the advice is to junior engineers. These days I feel most of my code is good enough most the time to not warrant a rewrite, as I can usually catch my self before doing something too stupid.

> as I can usually catch my self before doing something too stupid

About me, I dunno. I can usually catch myself doing something stupid. But fixing it on the act often takes time from finding the stupidity hidden in the more complex corners (usually on how the software interacts with other things).

Nowadays, I tend to stop to fix visible issues if other people are going to interact with the software. But if not, I find it much more valuable to get a bad thing there fast, so all the problems become known.

> who the hell has time to write everything twice?

If writing everything twice results in more maintainable code (eg higher cohesion, lower coupling, less verbose, more self-explanatory) then it's possible to get massive returns over the life of the module.

> However, who the hell has time to write everything twice?

The developer who's going to receive page duty alerts about the feature, will have to fix its bugs, track user analytics over the feature, suggest and implement improvements to improve these metrics, write documentation, educate and support other team members on it.

There’s a thousand things waiting to be written once… because they’re each coping with something else that was written once.

Write it twice, then you can use it a dozen ways, and now you’ve got a hundred things to write instead of a thousand.

Assuming you've written it correct the second time. If not, now you've got a deeper problem because it's most likely more complex. If things are waiting and coping with something to be written once again, how have you used your time to decide what needs to be re-written, versus something else that will probably be used more than you expected and needs a serious rewrite.

If you write code and don't think it needs to be rewritten, you are either an expert in your domain, or believe you have written code that fits your problem perfectly. Again, if you are not an expert in your domain, then what you have written is at best a solution that works without a second thought, but more likely could use another rewrite. Most software does not need a rewrite, but if we're talking about ways to reuse in a thousand ways, rather than a hundred ways, you need to have the luxury to rewrite code that is used in so many places that it's almost required.

This is "build one to throw away" writ small.

> Rewriting the solution only took 25% the time

So 125% time total

Yes, which the article mentions:

“So you get maybe 2x higher quality code for 1.25x the time — this trade is usually a good one to make on projects you'll have to maintain for a long time.

N.B. Obviously, don't write literally everything twice. It's a heuristic. Apply intelligently.”

Yeah, I'm seeing something of a fallacy in these comments that writing something once necessarily means it's written badly and will break/page people/etc. Sometimes you gotta get a lot of stuff done that has low complexity (e.g. in a startup) and writing it twice really is a waste of time.

A few basic sanity checks (some unit tests, a little discipline avoiding the abstraction high, whatever your flavour may be) is fine in many scenarios. Not all features require tons of monitoring and documentation. Everything in our line of work is a trade-off!

A heuristic becomes a fallacy only when applied without understanding the reasons behind it.

Every rule has exceptions, this isn't worth mentioning.

That is exactly what I'm seeing - heuristics applied lazily. If it wasn't worth mentioning it was at least worth replying to, right? ;)

Reply on news.ycombinator.com