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

151–160 of 215 posts

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

#151

Post by Dowwie »

skishor wrote: 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…

Learning Rust helped me become a stronger Python developer.

I've been working full time with Rust for long enough that I've acquired an intuition about ownership such that a lightweight borrow checker in my mind monitors ownership designs in Python. I use mutability sparingly. I use compositional design. Etc.

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

#152

Post by tadhgds »

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…

Can you elaborate on why this was transformative?

The dropping of standards is always going to make things a bit easier on yourself but if there isn't really much more to it than that, is proclaiming "It's okay to be messy" really a good thing?

I don't think(I might be wrong) other engineering fields can get away so lightly with such attitudes, why do you think we can? Particularly in light of so many security disasters unfolding around us. How can you justify an attitude that seems to move in the opposite direction of where many believe we should be heading, i.e. tighter control, more strongly enforced standards and a distancing from the 'move fast, break stuff' ethos

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

#154

Post by DonCopal »

Buttons840 wrote: post #105
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.

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…

Clever:

    for(let i=0;i
Readable:

  for (let i = 1; i

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

#155

Post by Tainnor »

iainmerrick wrote: post #146
Tainnor wrote: post #142

Earlier quoted context omitted.

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

you could do it as a personal side project without merging it into the mainline and you might learn one of three things:

- handrolled is better and the framework stinks

- there are some disadvantages to the framework, but after doing it all by hand you also understand how it makes a lot of things easier

- it's a tradeoff that largely amounts to which kinds of problems you're personally more willing to put up with (quite likely outcome)

in any case you would learn something

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

#156

Post by renox »

JamesBarney wrote: post #135
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…

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

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

-I remember being called to help rewrite a few lines of Perl (the other developer didn't manage to do it): it took me two or three hours with constantly looking at a manual to rewrite these few lines in a Perl that a beginner could understand.

The end result had the same line number than the previous version..

-Configuration files made of C++ template for dubious reasons..

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

#157

Post by mlrtime »

lucasmullens wrote: post #50
mlrtime wrote: post #27

Moving from my college years of emacs on the server to a proper IDE on the desktop.

Do you use any emacs key bindings in that IDE?

Yes, but compared to an IDE (Pycharm in this case) there is no comparison.

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

#158

Post by goto11 »

ericb wrote: post #64

Making debuggability (transparency) a first-class design criteria. For many (most) systems, there are designs that make perfect sense, but will be hard to debug. When I started designing so that programs could tell me what they are going to do, what they are doing, and why, and so that their state, wherever possible, could be expressed into a structure where I could "see" the wrongness, my development time went way d…

Yes! This is so much more important than whether you use "for" or "map".

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

#159

Post by sethammons »

Ocerge wrote: 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…

We call this phase the PoC effort (proff of concept). Rough draft, I like that too.

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

#160

Post by mekster »

newzombie wrote: post #145

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.

Why avoid early returns? If something doesn't match a condition to process anything in the function, then it's cognitively better to return early and say that case should be left out before possibly doing anything weird in it.
Post reply on HN