Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

141–150 of 215 posts

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

#141

Post by quii »

tcbasche wrote: post #71
mandeepj wrote: post #16

Earlier quoted context omitted.

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

Hello, I wrote learn go with tests!

Your comment is exactly what I try to get across in the book but it's not always easy.

If you cant decide how you want something to look (as that's not always easy) just take a punt on something. Make sure it's a small decision and make something useful. Sure you might have to change it, but at least you'll be basing that on some real feedback.

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

#142

Post by Tainnor »

iainmerrick wrote: post #134
Buttons840 wrote: post #105

Earlier quoted context omitted.

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…

Interesting examples. I am still conflicted about DI. I have seen it used too little which means that classes become basically untestable. OTOH, things like Spring (don't know about Dagger) seem so overcomplex and hard to figure out, I can certainly understand your point. I've had some luck with just hand-rolled DI in certain cases (e.g. a class that I know is mostly coordinating other classes; in that case, I might just inject all the dependencies manually for easy testing but provide a default constructor for actual production use), but I think it's hard to find the right balance.

Agreed about the annotations; it's one of the annoying things about Java, IMHO. The language itself is so inexpressive that people have to resort to annotations to do basic stuff. I think some level of "metaprogramming" can be useful (regardless of the language), either for boilerplate reduction or for removing aspects like logging from the main code, but it's too easy to become "clever" about it (not just in Java; Rubyists abuse metaprogramming way too often too, for example). I generally favour "explicit over implicit", which also means that I generally dislike inheritance because of all the non-local reasoning.

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

#143

Post by stevekemp »

I can't think of a specific technique, but one thing that has been very useful has been exploring the use of fuzz-testing.

I'm pretty much adding fuzz-testing to all my current/new projects now. It doesn't make sense in all contexts, but anything that involves reading/parsing/filtering is ideal - you throw enough random input at your script/package/library and you're almost certain to find issues.

For example I wrote a BASIC interpreter, a couple of simple virtual-machines, and similar scripting-tools recently. Throwing random input at them found crashes almost immediately.

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

#144

Post by Tainnor »

WClayFerguson wrote: post #55
hellofunk wrote: post #28

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…

Sure, but the converse is that when you have a 10k+ LOC project, you can't read that program linearly anymore. I find that sometimes proponents of "straight-forward code" strive for code to be immediately understandable line-by-line, but in big projects, this is not how you navigate a project; you have to create the right modules and abstractions, otherwise you will get lost.

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

#145

Post by newzombie »

A surprising one is to avoid all kind of jumps (early return, breaks and continues).

A broader one: writing expressions as much as possible. Basically, it means avoiding unnecessary mutations (and jumps).

Then avoiding architecture. Thinking algorithms that process data (instead of "systems") has been transformative.

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

#146

Post by iainmerrick »

Tainnor wrote: post #142
iainmerrick wrote: post #134

Earlier quoted context omitted.

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…

Interesting examples. I am still conflicted about DI. I have seen it used too little which means that classes become basically untestable. OTOH, things like Spring (don't know about Dagger) seem so overcomplex and hard to figure out, I can certainly understand your point. I've had some luck with just hand-rolled DI in certain cases (e.g. a class that I know is mostly coordinating other classes; in that case, I might…

I've had some luck with just hand-rolled DI in certain cases (e.g. a class that I know is mostly coordinating other classes; in that case, I might just inject all the dependencies manually for easy testing but provide a default constructor for actual production use)

Same here! I think that approach works really well when you’re able to use it.

I’d love to try removing the DI framework and see what you get just rolling it all by hand, but that’s a tough sell in a large pre-existing project.

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

#147

Post by phonebucket »

speedplane wrote: post #89
muzani wrote: 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.

> It's not a problem until it's a problem.

I see it as a problem waiting to happen until it happens.

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

#148

Post by AndrewDucker »

Immutability. I don't use it all of the time. And sometimes I use bits of the knowledge I've picked up through playing with it. But encountering it made me think a lot more about how state is available through the systems I write, and that definitely made me a better coder.

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

#149

Post by valand »

j88439h84 wrote: post #121
valand wrote: post #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…

> in-app event sourcing What's the difference between in-app and not?

Event sourcing is already widely used as app to app communication. But few realize that it is plausible to take that paradigm and use it for module to module communication in-app.

That line serves as reminder to utilize that, not to exclude non in-app event sourcing

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

#150

Post by valand »

charlieflowers wrote: post #94
valand wrote: post #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…

Thanks for that "Parse, don't validate" link. It definitely is the clearest explanation for type driven development I've found. Turns out, years ago I was writing some C# code and I found myself wanting to explore something like that. However, it wasn't idiomatic for C# (especially at the time), and I talked myself out of it. Since then, I've wondered if that's what people mean by type driven development. It's cool t…

Is C# nowadays friendly enough for type driven development?

Using TypeScript daily, I have a great time with type driven development. (C# and TS was created by the same guy)

I was never comfortable with Java community approach of automating stuff, with their heavy use of reflections, method name parsing instead of being strict in typings, use generics, macro, templating, etc.

Post reply on HN