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

191–200 of 213 posts

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

#191

Post by mavelikara »

throwawayboise wrote: post #184
mavelikara wrote: post #149

Earlier quoted context omitted.

Many early programers, Knuth etc, have described how writing programs on punch cards, submitting the job, picking up the results much later had a big influence on how they thought about programing. The lack of immediate feedback, counterintuitively, made them better programers it seems.

Or the people drawn to the tedium of early programming were just really good and mentally twisted in the right way to enjoy it. My first programming experiences were BASIC on TRS-80, TI-99/4a, and similar machines. It was instant feedback, for the most part, and I enjoyed being able to make small changes and seeing the results. I was around 12 years old and that worked well with my attention span at that time.

> Or the people drawn to the tedium of early programming were just really good and mentally twisted in the right way to enjoy it.

Agree.

I think what was happening was the the lack of feedback fit the mental models of the people who were attracted to computers early.

For another example of this,Ken Thompson famously said that he never quite understood why anyone would want to see the whole file they were editing instead of the single line.

But instant feedback attracted more people to programing.

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

#193

Post by vnorilo »

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…

I think "high iteration time" taken to the extreme is programming without a computer, like when taking a walk. You construct a very detailed mental model of how the program operates and interrogate it in your head.

This only works once you're a bit more advanced, but the one sure sign of a senior dev is the accuracy of their mental model. Which is also what allows you to write your piece without a continual back and forth with the compiler.

This all said, I greatly enjoy ping pong with a repl or instant hot reloading when doing visuals or sound.

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

#194

Post by yashap »

commandlinefan wrote: post #156
yashap wrote: post #21

If I had to order the things that make me productive, starting with the most important: 1. It’s easy to have a fair amount of confidence in changes without even needing to run them. Strong static typing, good/clean abstractions, local reasoning - little to no mutability, code is mostly pure functions with side effects pushed to the edges. Being able to just write a bunch of code without needing to run it at all (and…

> Being able to just write a bunch of code without needing to run it at all I work with a frightening number of programmers who assume that they can do this... so much so that they never bother testing to see if they were correct in the first place.

FWIW, I always write tests for my changes, as long as they have any impact on behaviour (i.e. not writing tests for adding a little logging or metrics, but am for any new or modified business logic). Every single dev having a strong commitment to automated testing is a requirement for an environment where you can sometimes get away without manual testing.

For any changes where it's not obvious that it'll work in practice, despite the tests, I also run the full app locally, and test manually. Or for any UI changes, obviously. For backend changes, for some codebases, running the full app locally is required for ANY change, period - hard to reason about code, little-to-no type safety, weak overall test coverage, etc. But if you have a simple backend change in an easy to reason about code base, that has great guardrails (great automated test coverage, great monitoring/alerts, canary deploys with auto-rollback), there really is not much reason to actually run the full app for a simple change, which is a nice productivity boost. Just make the tweak, write/modify tests if necessary, and if everything passes on CI, you're good to go.

For the 8 years before my current job, I was working in environments that weren't safe enough to do this ever, and was horrified when devs would merge without actually manually testing their changes. But my current company/environment has a codebase with strong typing and nice abstractions/local reasoning, great automated test coverage, and great monitoring/alerts and canary deploys with auto-rollback. Took me a bit, but I've embraced the "no need to run the app for simple changes" approach, and it works great in this environment - highly productive and still safe enough.

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

#195

Post by xcambar »

gfodor wrote: post #178
xcambar wrote: post #34

Earlier quoted context omitted.

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

As always, mentioning that Your Mileage May Vary (YMMV) puts the emphasis/decision on the people facing this or that situation rather than blindly applying advice found on the Internet.

And rightfully so :)

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

#196

Post by regularfry »

pjc50 wrote: post #78
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…

> Also, I'm tempted to continue the title with "...unless it's APL". Or lisp. Or smalltalk. Or forth. There's an entire subfield of computer science, headed by some prestigious people, who believe that working in a REPL is better precisely for these reasons. At this point I deploy the left-handed user argument: different developers probably find these tools and workflows have drastically different effects on their pr…

I genuinely don't know what to make of the handedness argument. On the one hand it makes a sort of intuitive sense (we're all individuals! Of course we all do things differently!) On the other we're all running on the same hardware, give or take. It strikes me as like learning styles: yes, people might have expressed preferences, but if you run the numbers we do all learn in fundamentally the same way, independently of what we say we prefer.

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

#197

Post by commandlinefan »

yashap wrote: post #194
commandlinefan wrote: post #156

Earlier quoted context omitted.

> Being able to just write a bunch of code without needing to run it at all I work with a frightening number of programmers who assume that they can do this... so much so that they never bother testing to see if they were correct in the first place.

FWIW, I always write tests for my changes, as long as they have any impact on behaviour (i.e. not writing tests for adding a little logging or metrics, but am for any new or modified business logic). Every single dev having a strong commitment to automated testing is a requirement for an environment where you can sometimes get away without manual testing. For any changes where it's not obvious that it'll work in prac…

> I always write tests for my changes

I wasn't saying you were one of those people - just saying I've worked with a lot of them.

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

#198

Post by regularfry »

dboreham wrote: post #176
petters wrote: post #91

Earlier quoted context omitted.

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

Only if your database lacks the tools to do it effectively. "The transaction commits" isn't exclusive with "and you can roll back to before it started".

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

#199

Post by MathCodeLove »

Jtsummers wrote: post #180
MathCodeLove wrote: post #179

Earlier quoted context omitted.

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.

Thanks! Haven't heard that terminology before.

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

#200

Post by wojciii »

dezgeg wrote: post #75
wojciii wrote: post #49

I do embedded work. I experienced this while working for a multinational. - A long build process and linker step that takes ages. 1-2 minutes for a small change. - Trying the change on a real device took perhaps 5 minutes. - A review process that can take days or even weeks sometimes. - There was a process that merged my change set which often failed and needs to be rerun several times - often 1-2 days were spent on…

At least you are lucky enough to be able try changes yourself. I am in the "fun" situation where team of 50+ SW engineers don't have single piece of test equipment needed for operating the hardware, and everything has to be manually tested by some QA engineer, taking 1-2 hours minimum...

It can always be worse. :) I feel your pain.

This was from an old job. I work a different job now with different challenges.

Post reply on HN