Honestly at a team level - code reviews. At least one other developer reviewing every line of code that is written is transformative in the quality of code that is produced. A lot fewer problems, a lot more maintainable.
Ask HN: What change in your programming technique has been most transformative?
11–20 of 215 posts
Re: Ask HN: What change in your programming technique has been most transformative?
#12I've recently joined a team that focuses massively on test-driven development, and it's just such a great way to shake out dumb bugs and focus on the requirements and the problem you're trying to solve.
Also recently did Thorsten Ball's Interpreter/Compiler books which focus heavily on unit testing the functionality (I can't recommend these books enough).
I now can't imagine going back to a pre-TDD world
Re: Ask HN: What change in your programming technique has been most transformative?
#13I've recently joined a team that focuses massively on test-driven development, and it's just such a great way to shake out dumb bugs and focus on the requirements and the problem you're trying to solve. Also recently did Thorsten Ball's Interpreter/Compiler books which focus heavily on unit testing the functionality (I can't recommend these books enough). I now can't imagine going back to a pre-TDD world
I did Learn Go With Tests which was my first intro to TDD and I found it enjoyable even if the author is little overly pedantic about his preferred testing approach.
However at work, I often find that I feel like I can't write unit tests before starting code because I just don't know how it's going to get built until I start poking at the code. I'm not sure how to break out of this
Re: Ask HN: What change in your programming technique has been most transformative?
#14I've recently joined a team that focuses massively on test-driven development, and it's just such a great way to shake out dumb bugs and focus on the requirements and the problem you're trying to solve. Also recently did Thorsten Ball's Interpreter/Compiler books which focus heavily on unit testing the functionality (I can't recommend these books enough). I now can't imagine going back to a pre-TDD world
I did Learn Go With Tests which was my first intro to TDD and I found it enjoyable even if the author is little overly pedantic about his preferred testing approach. However at work, I often find that I feel like I can't write unit tests before starting code because I just don't know how it's going to get built until I start poking at the code. I'm not sure how to break out of this
What does your pre-code design process look like? Might beef that up; its what has helped me quite a bit.
Re: Ask HN: What change in your programming technique has been most transformative?
#15I've recently joined a team that focuses massively on test-driven development, and it's just such a great way to shake out dumb bugs and focus on the requirements and the problem you're trying to solve. Also recently did Thorsten Ball's Interpreter/Compiler books which focus heavily on unit testing the functionality (I can't recommend these books enough). I now can't imagine going back to a pre-TDD world
How have you achieved a balance between too little and too much testing? I worked on a project that had a ton of tests, but they seemed to be "over fitted."
Re: Ask HN: What change in your programming technique has been most transformative?
#16I've recently joined a team that focuses massively on test-driven development, and it's just such a great way to shake out dumb bugs and focus on the requirements and the problem you're trying to solve. Also recently did Thorsten Ball's Interpreter/Compiler books which focus heavily on unit testing the functionality (I can't recommend these books enough). I now can't imagine going back to a pre-TDD world
I did Learn Go With Tests which was my first intro to TDD and I found it enjoyable even if the author is little overly pedantic about his preferred testing approach. However at work, I often find that I feel like I can't write unit tests before starting code because I just don't know how it's going to get built until I start poking at the code. I'm not sure how to break out of this
> However at work, I often find that I feel like I can't write unit tests before starting code because I just don't know how it's going to get built until I start poking at the code. I'm not sure how to break out of this
You'd start with shallow functions and quality asserts. Initially, you'd have broken tests, you have to write code to fix them, and that's your TDD.
Re: Ask HN: What change in your programming technique has been most transformative?
#17Hot code reloading. It was one of the best decisions I made when I added it to a hobby project I've been working for the last six years. Most of my development time for this project is spent adjusting code while the app is running. The feedback loop is incredibly tight and the most engaging of all of the projects I've ever worked on.
I'm working on extending auto reloading to all of the assets in the project because I know that tight feedback loops are that important.
Re: Ask HN: What change in your programming technique has been most transformative?
#18I've recently joined a team that focuses massively on test-driven development, and it's just such a great way to shake out dumb bugs and focus on the requirements and the problem you're trying to solve. Also recently did Thorsten Ball's Interpreter/Compiler books which focus heavily on unit testing the functionality (I can't recommend these books enough). I now can't imagine going back to a pre-TDD world
I did Learn Go With Tests which was my first intro to TDD and I found it enjoyable even if the author is little overly pedantic about his preferred testing approach. However at work, I often find that I feel like I can't write unit tests before starting code because I just don't know how it's going to get built until I start poking at the code. I'm not sure how to break out of this
I'm not even thinking about "how it's going to get built" when I write test-first. I'm just writing (test) code as a client that's calling an API. It just so happens that the API (method, or method + object) in question doesn't actually exist yet, so the first thing I do is let the IDE generate them so it compiles.
Once the code compiles I go into the implementation and make it work.
Now and then I realize during implementation that I need some additional parameter, but it's easy to add that.
Re: Ask HN: What change in your programming technique has been most transformative?
#19Programming in a team and accepting that it is not 'my' code but 'our' code. Not feeling slightly pissed when someone else changes the (not my) code. For me, this was a total game changer and a complete change in programming style. The focus changed to using the most common idioms, the clearest and cleanest and most concise way of writing stuff down, and avoiding smart hacks or, if necessary, encapsulating and documenting smart hacks. Not being shy of writing stuff multiple times until it really is clean and inviting to be read and understood. Using a very strict style (including when/where to put white space and line breaks) that everyone else also uses so that code is easy to read for everyone. It improved my programming enormously and the bugs/line ratio went down. It also gave a much better intuition to smell fishy code. It also took quite a while to internalise, but I now always code like that, also in private projects and in quick hacks scripts in, say, Perl.
My second most important change was to learn how to use contract based programming, or, if the language has poor support, at least to use a ton of asserts. This, for me, feels like stabilising the code very quickly and, again, improved my bug/line ratio. It forces me to encode what I expect and the code will relentlessly and instantly tell me when my assumptions are wrong so I can go back and fix that before continuing to base the next steps on broken assumptions.
Re: Ask HN: What change in your programming technique has been most transformative?
#20Earlier quoted context omitted.
I did Learn Go With Tests which was my first intro to TDD and I found it enjoyable even if the author is little overly pedantic about his preferred testing approach. However at work, I often find that I feel like I can't write unit tests before starting code because I just don't know how it's going to get built until I start poking at the code. I'm not sure how to break out of this
I'm not even thinking about "how it's going to get built" when I write test-first. I'm just writing (test) code as a client that's calling an API. It just so happens that the API (method, or method + object) in question doesn't actually exist yet, so the first thing I do is let the IDE generate them so it compiles. Once the code compiles I go into the implementation and make it work. Now and then I realize during imp…
I guess to me:
1) Writing a test that calls an API and asserts that everything resulted correctly from it is more of an integration test in my opinion - in this case I can agree this can be written beforehand.
2. If I'm changing my tests as I write my code then it doesn't matter if I go test-code-test-code vs code-test-code-test. I have still changed my definition of "correct" on the fly based on something I found out as I implemented.