Live data from Hacker News

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

news.ycombinator.com

131–140 of 215 posts

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

#131
post #3

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…

This is an interesting idea, I think I often do this subconciously but I might take your mindset next time and tell myself I can chuck the first draft away.

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

#132
Can't believe this list doesn't include revision control systems. So many benefits. Without these, you can't easily work with others. Never again break code then scratch your head wondering how to return it to previously working state (we've all been there). Have a documented history of changes over time. Support for branching. Also amazing for efficiency and not so frequently used are pre and post commit hooks for CI/CD.

Basic inline documentation. Who wrote it, when and why. What else did you consider. How does it differ from other solutions. Why is it designed the way it is. Brief history of design changes. What state did you reach in testing. What are the forward looking goals. Takes 5 minutes, pays for itself many times over in future. 90% of effort is maintenance.

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

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

Sounds like you're remembering John Carmack developing VR using racket:

https://www.youtube.com/watch?v=ydyztGZnbNs

edit:

Also check Arcadia for Clojure:

https://www.youtube.com/watch?v=_p0co13WYPI&feature=emb_titl...

And developing flappy bird in clojurescript (canonical figwheel example):

https://www.youtube.com/watch?v=KZjFVdU8VLI

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

#134

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.

Can anyone give a specific example of code they've worked with that was "too clever"? Based on my experience, if a coworker wanted to "avoid cleverness" I imagine we'd end up arguing over something like a for-loop versus a map, but such small code decision matter very very little in comparison to overall architecture, and where you place the "seams" in your system. So I ask, when you have felt that code is "too cleve…

A couple of examples from Java/Kotlin code:

- Too much business logic hidden behind dependency injection (using Dagger in this instance). I think DI should be used sparingly, to decouple large subsystems like the database or the network. It can feel clever to inject everything, so your system is super modular and decoupled, but that just makes it much harder to understand, with little or no real benefit.

- Somewhat related, excessive use of annotations to accomplish tasks that could be done in a more straightforward way with normal code. For example, in Android, you might have an annotation that adds some fragment to your activity as a mix-in; but is that really easier than just calling a function to do the same thing?

This stuff starts to cause real trouble when there are 1000 occurrences sprinkled through your code, and suddenly you need to step through it to debug a tricky problem. Straight-line code is vastly easier to deal with.

So I’d say “clever” is more of a problem at an architectural level, rather than inside individual functions.

At the low level, shorter is almost always better. If somebody comes up with a clever way to reduce a function from 10 lines to 4, say, that’s great -- as long as its purpose is clear and it’s testable.

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

#135

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.

Can anyone give a specific example of code they've worked with that was "too clever"? Based on my experience, if a coworker wanted to "avoid cleverness" I imagine we'd end up arguing over something like a for-loop versus a map, but such small code decision matter very very little in comparison to overall architecture, and where you place the "seams" in your system. So I ask, when you have felt that code is "too cleve…

> Can anyone give a specific example of code they've worked with that was "too clever"?

Code that relies on implementation details of a library that a good portion of developers wouldn't necessarily know. In C# if your code relies on LINQ being lazily evaluated to produce the correct answer it's probably too clever.

Using reflection in static languages like Java or C# when it's not necessary.

Writing code that passes functions around when you don't need to.

Chaining together a series of map/filter/reduces in order to avoid writing a simple for loop.

> Based on my experience, if a coworker wanted to "avoid cleverness" I imagine we'd end up arguing over something like a for-loop versus a map, but such small code decision matter very very little in comparison to overall architecture, and where you place the "seams" in your system.

> So I ask, when you have felt that code is "too clever", was it because someone used a map, but you're more comfortable with for loops, or was it bigger than that?

This rule basically comes down to all things being equal try to write straightforward code. If you can write two functions in 5 lines of code but one function will be more easily understood by a more novice programmer, go with the more straightforward approach.

>My first job was maintaining some PHP. The author didn't know what a function was. The code was a 5,000 line script, top to bottom, with basic control and looping logic nested up to 17 deep (I counted). It was horrible. Yet surely, the author had avoided cleverness at all costs; he had built a working system with only the most basic tools, those being all he knew.

No one is arguing that writing straightforward code is the most important code quality to strive for, just that before you implement that currying solution to reduce the number of lines of code from 40 to 35. Think twice.

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

#136
post #82

It's okay to be messy. Treat code mess with the same techniques you would treat RL mess. Sometimes you sweep it under the rug. You can toss it in a closet or attic. You can buy a shelf or box and toss everything in there. You can clean it up seasonally, like set aside a sprint for it. Some kinds of messes are hazardous and absolutely should not be tolerated - this is similar to leaving milk out or trash piling. Many…

This. Do it the stupid way first, I've heard it said.

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

#137
A lot of really good answers in this thread. I had a great mentor years ago and she really taught me the importance of working cleanly and professionally. Proper code formatting, checking your comments for spelling mistakes, indentation, auto formatting on save, linting, writing solid documentation, rebasing and tidying up your commits to create clear steps that a reviewer can step through. All of the things that often get overlooked but are very important in how you come across as a professional developer.

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

#138

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.

Can anyone give a specific example of code they've worked with that was "too clever"? Based on my experience, if a coworker wanted to "avoid cleverness" I imagine we'd end up arguing over something like a for-loop versus a map, but such small code decision matter very very little in comparison to overall architecture, and where you place the "seams" in your system. So I ask, when you have felt that code is "too cleve…

I once decided that the SNMP agent for an embedded device should not implement the leafs (responses) by simple hard coded C functions, one for each implemented leaf on the great standardized ASN.1 tree.

Instead I implemented some kind of ASN.1 tree parser, which parsed to lisp, then I tied that through C bindings to some kind of callback to the lisp functions, and clever reuse of datatypes and whatever. I don't even remember how it worked!

I don't remember if it did all the processing on the device or if I had (the same flavour) lisp running in the build system too. I just remember that in the end, even I didn't know exactly how it worked or how to hunt down the inevitable bugs. It looked very elegant though, with lots of autogenerated types from the ASN.1 spec.

The C code which eventually replaced my unholy mess had to handle the datatypes manually in each function, but it was easy to understand and easy to update. Fewer bugs too, I'm sure. And one less dependancy. (The lisp engine.) It didn't have the automatic integration with our vendor MIB file, you'd have to manually add or update functions in the C code whenever someone in another part of the company decided to update the MIB file.

Small price to pay. I'm not saying the "elegant" idea could have been made workable and easy for other developers to understand, but definitely not by me in that point in time. Lisp at the time was my hammer and I saw a lot of nails. (I wasn't even any good with the hammer for actual nail like things, I think.)

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

#139
post #116
post #82

It's okay to be messy. Treat code mess with the same techniques you would treat RL mess. Sometimes you sweep it under the rug. You can toss it in a closet or attic. You can buy a shelf or box and toss everything in there. You can clean it up seasonally, like set aside a sprint for it. Some kinds of messes are hazardous and absolutely should not be tolerated - this is similar to leaving milk out or trash piling. Many…

Wrong. Absolutely wrong analogy. You can't discount people who keep code clean, modular and simple. It's not an easy thing to do unlike cleaning your house. It just takes one's will to clean the house but when it comes to keeping your codebase clean, it's much more than just will. Sound knowledge of software architecture and design principles is required to write and keep your code clean and unfortunately, the number…

That's true in a way but with the huge caveat that cleanliness of a home is very objective. Everyone recognises and agrees when a home is very clean or very dirty.

Software architecture isn't like that at all. Developers routinely have massive fights and disagreements over whether something is clean or not. One person's clean is another person's over-engineered monstrosity.

This changes the equation quite a bit. In any sufficiently big team either one person has to be top dog and enforce their personal perception of clean on a perhaps unwilling team. Or you have to flex and tolerate multiple competing definitions in a codebase, which if you have "clean freaks" in the team can lead to constant pointless refactoring and rewriting.

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

#140
- Letting code crash early and hard, deciding what parts of the code i never think about handling - Dependency Injection (ObjectOriented/Functional), controlling when stuff gets created vs. used - Accepting to having some level of redundancy in code, using code to configure stuff (wrappers, adapters, factories) and not trying to pull out everything from the start - Figuring out what parts of what i could test i should test, being fine with just coverage - Writing a cli for every project - Learning how to transform code without breaking it for long periods of time
Post reply on HN