Live data from Hacker News

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

news.ycombinator.com

71–80 of 215 posts

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

#71
post #13

Earlier 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

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

This is definitely the best way. Start with the how you want everything to look and make your code match your expectation.

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

#72

Avoiding cleverness at all costs. Simple code that is easy to both read and write without strong efforts to follow senseless DYI or take on abstraction for the sake of abstraction.

Amen! Developers spend their first decade learning how to write complex code, and be clever, and compress everything into the fewest and hardest-to-read smallest amount of code possible. Their second decade they learn that simplicity and readability is always better, even if it does require more code. It's better to have 300 lines of simple, straight-forward, easy-to-read code than to have a 30 line version of the sa…

IME it's about time spent maintaining code rather than an age/experience thing, devs that flock like locusts from green field to green field will never learn, devs that maintain "clever" code will learn pretty quickly.

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

#73
Static typings + type inference

Parse, don't validate https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

All libs/products should be pure functions, with input output documented, making libs/products predictable

Use in-app event sourcing to reduce the need for global states states

DoD https://youtu.be/yy8jQgmhbAU In non bare-metal languages, this will be useful for readability

For errors, return instead of throw

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

#74
post #2

By far, starting to write automated testing as I code. The sheer number of bugs I find immediately and the number of bugs I find from changes that I didn't expect would be enough to justify it, but what is even better is that it forces me to keep my code testable , which also happens to correspond fairly closely to well-architected code . Not perfectly, but for something that is automated and always running, it's rea…

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

To piggy back on here. Don’t use mocking frameworks in tests. I’ve found it to be a great way to expose design flaws in the code.

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

#75

Hot 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…

What language? Is it a game?

I've been wanting to try that ever since I saw a video of someone developing an FPS in Common Lisp while playing it at the same time. They would modify the bullets and the way they made collision, then fire after each change to see the effect.

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

#77
post #75

Hot 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…

What language? Is it a game? I've been wanting to try that ever since I saw a video of someone developing an FPS in Common Lisp while playing it at the same time. They would modify the bullets and the way they made collision, then fire after each change to see the effect.

It's an open world roguelike in Clojure. It was counter intuitive to me at first, but modifying real-time behavior like rendering is even easier because the feedback loop doesn't involve player interaction.

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

#79
post #32

Functional Programming fundamentally changed the way that I solve problems. It also changed my expectations for how code should be designed. The concepts that influenced me the most were immutability and the power of mapping+filtering. Whenever I read a for/while loop now, I’ll attempt to convert it to the FP equivalent in my head so that I can understand it better.

map and filter are not concepts of FP - they are just syntactic sugar around for loops. fully evident if you check any native source code. many languages (such as go which I currently use) do not even have these functions but can apply FP. this is by design of simplicity and visibility: it does not get much easier to read than a simple for loop and know the exact iterations count at runtime.

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

#80

Avoiding cleverness at all costs. Simple code that is easy to both read and write without strong efforts to follow senseless DYI or take on abstraction for the sake of abstraction.

^this +1. took me years to learn.
Post reply on HN