Ask HN: What change in your programming technique has been most transformative?

As an example, the team I work on has been adding more precondition checking to all of our applications. The simple act of stepping back from the perceived data-flow and explicitly declaring what we believe should hold true has uncovered several bugs in our understanding of our applications.

We've likened it to having someone review a paper you've written: you often read what you think you wrote, not what's actually written.

This got me to questioning what others have found to be transformative in their development practices.

I throw away rough drafts all the time for non-trivial work that I don't fully understand yet. There are different approaches to it, but I usually just create a throwaway branch to hack out a naive solution until I run into the non-obvious roadblocks and then try again. I used to try to _really_ understand something before coding a solution, but not being afraid of throwing away a rough draft has helped my mindset a bit in terms of working out difficult problems. It's not a novel or huge concept but it works for me.

1. Using REPLs: The tool or the principle.

REPL means Read-Eval-Print-Loop and its a place where you can run code immediately and get immediate feedback. For example F12 in your browser and use the console to do 1+1. But you can also use that console to interact with your code in the browser, the DOM and make http requests.

But I also see REPL as a principle - to get as quick feedback from the code you write as possible, and things that help this are:

* Quick compile times

* Unit tests

* Continuous integration

So that each stage is as quick as possible. I write code and within as second or two know if it failed a test. Within a few seconds maybe I can play with the product locally to test it manually. Once committed, I can see it in production or a staging environment at least pretty quickly.

You can then have bigger REPL loops where a product manager can see your initial code fairly quickly, give you feedback and you can get stated on that right away and get it out again for review quickly.

I don't think there is any excuse not to work like this given the explosion of tooling in the last 20 years to help.

2. YAGNI

Writing over elaborate code because it is fun! That's fun at first but you soon learn it's better to write what is needed now. There is a balance and writing absolutely shit code is not an excuse, but adding too generic code because of stuff that might happen is also a problem.

I would say: Automated testing and a functional programming mindset.

Even for legacy projects, starting with adding regression tests for every bug you find is a great way to introduce testing. And when you add new features, you can write tests for that as well.

I find that a FP mindset is helpful mostly because it tends to reduce the amount of global or spread-around state. This in turn makes testing and quickly iterating in a REPL a lot easier. Also when later the time comes to debug, it's much simpler if you don't have a huge amount of state to set up first.

And even if a lot of state is required, having it be an explicit input to a procedure is helpful because it makes it much clearer what you need to set up when doing manual testing.

Ah man. Reading these comments make me so happy. Automated testing from the start. Code as you go. Love every bit of it.