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

3 lines of code shouldn't take all day

devtails.xyz

Post reply on HN
Print view View original

171–180 of 213 posts

Re: 3 lines of code shouldn't take all day

#171

Post by mannykannot »

marginalia_nu wrote: post #160
mannykannot wrote: post #132

Earlier quoted context omitted.

I think that final sentence is unduly pessimistic - after all, if practice did not play a big part in expert programmers becoming that way, what did? What hope is there for the novice who is frequently making off-by-one errors and the like? Maybe you are saying that there is no deliberate method of practice, but I think there is: whenever you correct one of your mistakes, try to figure out how you might have written…

> I think that final sentence is unduly pessimistic - after all, if practice did not play a big part in expert programmers becoming that way, what did? What hope is there for the novice who is frequently making off-by-one errors and the like? It's not that the knowledge can't be acquired, but this is a type of knowledge often can't be explicitly practiced through some training routine. A beginner may of course learn…

I agree that competent, experienced programmers look at code differently, and much less linearly, than do novices, and there have been studies that show this. On the other hand, a person could (and people do) spend years programming without learning to look at code in this way. The people who do improve must be doing something different.

There are no shortcuts, AFAIK (though I think most people can achieve most of their potential in less than a decade), and I am sure you cannot get there through rote learning. Are you suggesting, however, that the sort of approach I am advocating is not very helpful, or just that it cannot be explicitly practiced?

Re: 3 lines of code shouldn't take all day

#172

Post by PaulDavisThe1st »

e12e wrote: post #165
PaulDavisThe1st wrote: post #162

In 1989, I was working at my first (very short lived) US job, for Bell Labs (not the Bell Labs, but related). I was working on their "office-scale" phone switches, the kind that allowed you to forward a call from one extension to another. There was a hard-coded limit of (I think) 16 forwards, and for some reason it was decided to increase this to (I think) 64. This involved changing a constant in a header file, a doc…

Don't leave us hanging - how far over budget did it end up? ;)

Under budget, but at the end of that week, having successfully pushed through this DRAMATIC CHANGE, I drove from Phila. to the Outer Banks (NC), crashed, rolled the car 3 times, totalled the car, broke my arm, could no longer get to work, decided to marry my first wife, and left to work for a company I could commute to with a broken arm. Small change, big ramifications :)

Re: 3 lines of code shouldn't take all day

#173

Post by TheDesolate0 »

mannykannot wrote: post #136
GreenWatermelon wrote: post #94

Earlier quoted context omitted.

Getting a particular piece if code running from the first time is so unexpected that I'm like "Huh... that's pretty cool" everytime it happens. no need to spend 3 more minutes looking at the code when a 2 seconds build will tell me there's a Segmentation fault right there, or when Valgrind will tell me I missed a free ().

Only a small fraction of segmentation-fault-causing errors will be revealed in 2 seconds of testing. Thinking about all the ways your code could fail, and being able to keep a mental track of the constraints you need to observe, is a useful skill to acquire.

confused crustacean noises

But, seriously, I do NOT miss C/C++.

Re: 3 lines of code shouldn't take all day

#174

Post by elfchief »

yjftsjthsd-h wrote: post #128
dotancohen wrote: post #102

Earlier quoted context omitted.

> But automatic lets you pay more attention to the road ahead, whether you are a new or experienced driver. In my experience, drivers who primarily drive an automatic are easily distracted from the task of driving. They turn around to their children, fiddle with the radio or climate control, I've even seen many adjust their seating position and steering wheel position while in motion. Not to mention the internet-conn…

That really sounds to me like manual vs automatic is a manifestation of underlying personality traits. Or possibly just age.

Or just... wrong.

I know a bunch of people that prefer manual transmissions. And every single one of them also prefers loud music while they're driving.

Re: 3 lines of code shouldn't take all day

#175

Post by JoeAltmaier »

elfchief wrote: post #174
yjftsjthsd-h wrote: post #128

Earlier quoted context omitted.

That really sounds to me like manual vs automatic is a manifestation of underlying personality traits. Or possibly just age.

Or just... wrong. I know a bunch of people that prefer manual transmissions. And every single one of them also prefers loud music while they're driving.

Or, me. Never turn the radio on at all. Driven manual all my life. Prefer it.

Re: 3 lines of code shouldn't take all day

#176

Post by dboreham »

petters wrote: post #91
vbezhenar wrote: post #69

Earlier quoted context omitted.

Docker helped me to significantly increase unit test speed on one project. Each test was recreating database, run dozens of DDL scripts over and over (to ensure clean environment). I reimplemented in in a way that DDL scripts were run once, then container with database was commited to an image and that image was re-used for every test. Also multiple containers were run at once, so tests could be run simultaneously. D…

Normally you'd open a transaction, run the unit test, then roll back the transaction. That makes each test start at the same, clean state.

That's not normal, because the test is now not testing the code in its eventual context (which is : the transaction commits). In my experience unfortunately this is a very common pattern (tests are far removed from "reality").

Re: 3 lines of code shouldn't take all day

#178

Post by gfodor »

xcambar wrote: post #34
gfodor wrote: post #26

Earlier quoted context omitted.

Another much under-utilized way to speed up test suites: delete tests

I understand the underlying message but I prefer the equivalent following phrasing: "check test suite coherence". It moves the deletion as a means towards the coherence rather than as an end in and of itself, and also includes refactoring as an option. I hope it helps the less experienced developers grab the intention more explicitly.

I think the core point isn't about coherence, but tradeoffs. Some tests are not worth holding onto: ones that are slow, flaky, and test code that is of marginal importance. In those cases, the ideal tradeoff can be to delete the test. Perhaps to rewrite a better one, or perhaps to just 'eat' the risk incurred by removing it in favor of improved iteration times and the other long term benefits of not having to maintain it.

Re: 3 lines of code shouldn't take all day

#179

Post by MathCodeLove »

jmnicolas wrote: post #43
userbinator wrote: post #37

This is probably a controversial opinion, but I think that working in an environment where time-to-iterate is high is actually very beneficial for improving your skills. It's one of those things that may feel overly burdensome in the short term, but is better in the long term. I say this as someone who taught programming with beginners, and observed what many of them will do when given an IDE, which at the scale of t…

Your example is valid for beginners but once you're getting experience you don't code like that anymore. After 13+ years of C#, on simple projects I can code for a couple hours without compiling and get the pleasant surprise that my code work the first time I run it. And I'm certainly not a genius, I'm a 1X programmer.

What does "1X" mean in this context?

Re: 3 lines of code shouldn't take all day

#180

Post by Jtsummers »

MathCodeLove wrote: post #179
jmnicolas wrote: post #43

Earlier quoted context omitted.

Your example is valid for beginners but once you're getting experience you don't code like that anymore. After 13+ years of C#, on simple projects I can code for a couple hours without compiling and get the pleasant surprise that my code work the first time I run it. And I'm certainly not a genius, I'm a 1X programmer.

What does "1X" mean in this context?

"Average", as opposed to a 10x "rockstar" or above average programmer. Or a -1x or -10x incompetent programmer.
Post reply on HN