> 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.

People learn to work better by reflecting on work. So any framework for self-observation is better than none.

I suspect that algorithms as a framework demonstrates the structural aspects (e.g., how some searches are more extensive), but might hide the driving factors. Indeed, the article examples were almost all hacking personality, not technical or process solutions.

E.g., most over-engineered solutions are driven by fear, often itself driven by critical or competitive environments. Conversely, much of the power of senior/staff engineers comes from the license to cut corners afforded their experience. Or people use the tools they know.

You can't get to great by holding onto good. It's easy to go from bad to good, but takes some courage to toss good to start over for great. The lesson there is that we stand (hide?) behind our work, and we need to let go of it to improve it.

A meta-lesson is that managers need to deeply understand personal space of each developer and the social dynamics of the team before they can do their job effectively, and a key part of that is likely checking in with developers in a way that enhances their courage and self-observation instead of making them fearful and paranoid.

I fundamentally disagree with the "gun to the head" strategy.

One of the major projects I worked on was a virus genome analysis pipeline. Our initial funding was for single-segment virus analysis, but about a year into the project, our grant collaborators needed to demonstrate multi-segment virus support within two weeks. My PI and I agreed on a quick and dirty method that would produce the analyses needed and could be done in the allotted time. That piece of code was fundamental to how the whole pipeline worked, however, and so as the pipeline grew, it took on the shape of the "gun to the head" decision we had made to the point where other, more essential features of the pipeline had to be delayed so I could come up with more workarounds.

There were clearly other issues at play here (scope creep and lack of separation of concerns were huge). My time at the lab came to a close, but if I were to have a chance to continue that project, I would start over from scratch rather than deal with the baggage that that one "gun to the head" moment created.

I understand that it's a heuristic and not meant to be taken as 100% truth for every situation. I also understand that it's trying to avoid that "paralysis by analysis" that's so easy to fall into. I just question how useful it truly is as a heuristic, especially since it seems to go against the "write everything twice" algorithms presented in the rest of the piece.

Review: An anonymous "distinguished CEO and engineer" suggests if you can't complete a feature in a day, delete your progress (except for tests) and start again the next day.

The author then recounts advice he gives to juniors, which is to stash the work and rewrite it, claiming that the next day the work will be rewritten in 25% of the time and 2x quality. This is unsubstantiated though. For juniors this suggests it will help them develop their capabilities to reason about implementations of problems without needing to face a a large amount of them.

The author then gives another advice which is to ask for a solution to a problem then after the initial proposal, ask for a 24h solution. This is meant to generate "the real solution". He likens it the a path algorithm heuristic to reach your goal quicker.

Overall the methods are not well discussed in terms of pros and cons, nor substantiated with experiments.

Opinion: I think they may help some juniors who need to build up experience and may become stuck in development patterns. But they would rarely be useful to develop someone to be a senior, if all they do is chase fast implementations. In a way the post gives conflicting advice: write twice and write better, and think twice and think about the fastest way to achieve the goal, instead of engineering a problem.

The author hasn't really convinced me of these approaches, and especially the last one smells of eXtreme Go Horse.

These are useful mental tools, to have in your mental toolbox, and apply them as they seem appropriate, but don't make a religion of any of them.

A related old idea about writing/reworking software three times: "Do it. Do it right. Do it fast."

Startups provide ample opportunities to get experience with what the article calls "gun to your head heuristic". You have to decide what and how to compromise.

And, if you want your startup to be successful (not just hit your metrics/appearances, and then job hop), you can't just do it like school homework (where the only goal is to slip something past a grader, and forget about it), but you have to creatively come up with a holistically good compromise solution, given all the factors. If you do this well, it's creative magic that can't be taught, but can be learned, through experience and will.

> Start working on the feature at the beginning of the day. If you don't finish by the end of the day, delete it all and start over the next day.

How experienced is this “CEO and engineer”?

A thing that took me several years to agree to is that almost everything can be coded within 24 hours if really needed - gun to the head situation. Will it be perfect/efficient/beautiful/... probably not. But it should roughly work like its supposed to.

If something cannot be coded within that 24 hours, something else is odd, not the feature. Transitioning from SWE to DevOps and then Leadership roles, most of my day actually is spent with all the reasons/excuses why "it cannot be done", and try to eliminate them. Probably my developers hate me for it, but I always push hard for an immediate first solution instead of doing days of soul-searching first, but over time we encounter and solve enough roadblocks (technical, social, educational, ...) that it actually happens more often than not to have surprisingly fast (and good enough) solutions. That speed is a quality in itself, since it frees up time to come back to things and clean up messes without the shipping pressure mounting up over days/weeks - something working is already there on day two.

The trick is of course to _not_ sell this 24 hour solution to upper management ever, or else it will become a hell of a mess fast once this becomes the outsider expectation.

Although I disagree with the arbitrary limit of “one day per feature”, I agree with the broader point that useful constrains drive creativity.

The generalisation I would make is: if you think, not just of a specific solution, but of the space of possible solutions, it makes it easier to find a point in that space which best "fits" (space, time, architecture) the program you're working on.

Rather than trying paths in the dark, first look at a map, then try a few paths.

"Gun to your head" gives you quick working solutions. But then when you avoided the headshot you run away and leave that quick-fix-mess to someone else. So this should not be a long time strategy. Sure if your runway is approaching the end, do whatever is needed to stay alive.

If you write a design doc first, you can save yourself a lot of time. It's very quick to write a new design, and designs are also much faster to revise than code is.

I spent 90% of the time reading and trying to understand the business logic behind the code that lies in the place that I think I need to put my feature in. So far, no methodology helps much with this part of software engineering.

The remaining 10% is rather straightforward.

For "write everything twice" I would say write some parts many times. You don't have to write everything twice. Most code are optimal or good enough already, but you should be willing to re-write some parts over and over again.

The "write it twice" strategy should be more common.

The alternative is "write it once and be stuck with it". You want tech debt, cause that's how you get tech debt.

By definition, the first time you do something, you will learn a ton. So you've gained two things: 1) hard-won technical knowledge and 2) a bunch of sub-optimal code written before you obtained that knowledge. The way I see it, keeping that proof-of-concept code around forever is a terrible tradeoff - giving up #1 to save #2 at any cost. Code isn't that special, especially on the first pass.

Side note: “write everything twice” (WET) is originally meant as a reaction to DRY (“don’t repeat yourself”). I think the author uses the credo here for something else (which is still good advice).

I agree 100% with this approach, and I'd love to see some research to back it up.

I think a lot of software development is "way finding" - Experimentation to figure out an architecture, an implication, a performance improvement, etc.

We often don't a) call them experiments, and b) we don't constrain them well. I.e., we use the scope of the feature to bound the experiment, instead of taking a step back to figure out the right approach, we dive into implementation.

I'm curious if there's a more formal way to think about this all?

Previous discussion:

Algorithms we develop software by (18.08.2024)

https://news.ycombinator.com/item?id=41284409

> "gun to the head" heuristic

Never underestimate the power of hiring a new employee and training them how to do what the software would do, thereby writing zero lines of code.

That $250k in initial feature development costs + maintenance might only be $75k in personnel costs a year, which is a break-even of ~4 years. Depending on the problem, that might be the best option.

Is the title a play on the "Algorithms to Live By" book.

Sounds clever :)

It is the worst advice I have read. If the goal is to divide everything to fit in a day, it would be better to use a static analyzer to enforce certain rules.

Nice play on words from Lakoff's "Metaphors We Live By"

Gun to the head solutions: no tests, no quality, no future planning, hacks on top of hacks, tech debt.

As a manager, this "thought exercise" is dangerous. You think it is a fun and harmless exercise to your reports to really focus, your reports at best think you don't trust them, and at worst think you are threatening them with violence (hypothetical or otherwise) unless they tell you what they think you want them to say. Psychology safety will be at rock bottom pretty quickly.

Nice job you have there, would be a reaaaaalll shame if anything hypothetical happened to it huh? Now estimate again, and this time don't make me angry <imitates pulling a trigger of an invisible gun at someone's head>.

Absolutely terrible behaviour.

[dead]

[dead]