Live data from Hacker News

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

news.ycombinator.com

111–120 of 215 posts

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

#111
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…

I've got a slightly different take on messes, and using another RL analogy I call it "don't put your dirty dishes in the sink." If you have a couple dishes you can't wash right away it is tempting to put them in the sink instead of on the counter: from a distance it looks neater, any spills are contained, etc. Where this falls apart is if you add a few more dishes, and then more, and now your sink can't serve its main function because it's full of dishes, and some of them are full of dirty water so you can't just move them back to the counter, so washing just the one dish you need requires you to either undertaking cleaning the whole sink or delicately juggling the thing under the faucet while water sprays everywhere, and washing all the dishes now requires a mop.

Code messes are similar. Sweep them under a rug or toss them in a closet and your code will look clean, just like your counter looked clean while those two dishes were in the sink. And like the sink you can quickly get to the point where those closets are scary to open and no one wants to walk on that rug because it makes weird crunchy noises.

So how does one leave ones messy code "on the counter"? Well in my "writing C with vi" days I actually outdented any code that I didn't consider clean/good/permanent. Like all the way to the left, regardless of where it would naturally be indented at. It stuck out like a dirty mug on clean granite, and no one (importantly including me) failed to notice it.

With modern IDEs and auto-formatting and the somehow unavoidable use of Python I no longer use that technique, but I will comment any such code liberally with #HACK or #TODO or similar

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

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

They are not equivalent - for loop prescribes the ordering of processing, but map and filter can work in any order. They are often associated with FP because to define these operators, you need to be able to pass functions as parameter to other functions, which is a thing that surprisingly many languages struggle with.

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

#113
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…

> Once the mess becomes a burden, it's a good time to clean up. Definitely the way to go. It's not a problem until it's a problem.

Still, you may want to be careful with this attitude, as some people have... let's call it, high tolerance to mess. When you stumble over something every time you enter your room, but proudly proclaim "not a burden, works for me, all under control!", then you "suddenly" need to add a huge feature quickly, having a clean room can help to do it in shorter timeframe.

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

#114
post #81

Learning different programming paradigms. For example, logic programming with Prolog makes you think about solving certain problems quickly and efficiently in a declarative style. Strongly-typed functional languages like SML and OCaml make it easy to use types and pattern matching to reduce errors and shift some cognitive burden from yourself to the compiler. Lisps allow you to quickly prototype functions in the REPL…

>shift some cognitive burden from yourself to the compiler This is the best way I've seen the advantages of static type checking articulated.

The line I use is: "I'm a very bad programmer, but I'm very good at making the compiler force me to get it right".

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

#115
Off the top of my head:

- Reading books (e.g. Clean Code, Refactoring: Ruby Edition, Practical Object-Oriented Design, ... these left a mark)

- Going to conferences (Rubyist? Attend a talk by Sandi Metz if you have a chance)

- Testing (TDD at least Unit Testing)

- Yeah, the usual stuff: quick deployments, pull requests, CI/CD ...

- Preferring Composition over Inheritance (in general and except exceptions :)

- Keeping on asking myself: what is the one responsibility of this class/object/component?

- Spending a bit more time on naming things

- Have a side-project! It's a fun way of learning new things (my current one is https://www.ahoymaps.com/ - I could reuse many things that I learnt also in my 9-5)

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

#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 of people with this knowledge is very small in most teams and sometimes there's none.

Also, it's not okay to be messy unless you are working on a school/university project.

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

#117

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…

Generally bigger than that, though long clever statements using functional idioms like you suggest could be hard to read in some languages.

Cleverness also refers to architecture, designing meta-types to encapsulate all sorts of things that just don't need the flexibility, over-designing a system in anticipation of future needs that may never come. Sometimes it's a delicate balance and often only experience can dictate how "clever" one should be.

Many developers just out of university, or still in it, in certain languages, like to run with clever things they can do with the type system to abstract away all sorts of stuff, which becomes painful later.

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

#118
post #86

I used to just write code fast and forget about it, only slightly caring about the finished product. After having to build and support 2 fairly large applications(for use on a company intranet) I will fully plan, document and test my software. No more clever code, no more quick hacks. I also gave up on Javascript and node.js, and I mostly do c# now because of type safety.

Caveat: sometimes you just want to finish something. Specially when prototyping or creating an MVP, it's important to have a hard focus on the end goal.

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

#119
Migrating from JavaScript to Typescript and declaring interfaces for classes and data structures forced me to put more thought into each piece before I start implementing. Now I’ve cleaned up a lot of old code I didn’t have much visibility over thanks to the compiler warnings.

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

#120
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…

You're not quite disagreeing with the analogy, you're actually re-enforcing it. What you've really taken exception to, is the OP's perceived standards of 'hygiene'.

And between say 'medicine' and 'refuse collection', standards of hygiene and priorities can and will be wildly different.

Post reply on HN