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

121–130 of 213 posts

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

#121

Post by jarek83 »

Sounds like EA has (had?) actually pretty good developers. The game itself has so many things gone wrong that from the players perspective it's very hard to find any good words for. Shame that the company hates their customers so then customers started to hate anyone involved in EA. In the forums of the game, devs of this game are considered to be the laziest and the least skilled across the industry.

PS. Anyone did figure out whether DDA is officially in the code or is it just a matter of network quality difference between players and the server (the game stopped to be p2p in any mode)

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

#122

Post by Philip-J-Fry »

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…

When I was a beginner I'd write code and run it very fast, after each small change, even though an experienced developer could probably compile it in their head and see whether it worked or not.

I think just as you get more experience you tend to write more code before you run it. I've written an entire (relatively small) application and written the tests for it before I even thought about running it. Run it, few tests fail, iterate a tiny bit, done.

It's just natural as you get more experienced that you can reason about code in your head without resorting to running it to confirm it.

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

#123

Post by ineedasername »

Testing changes here could mean progressing through several seasons of career mode in order to test out a change

That's like the Groundhogs Day of programming. Living the same season over and over again, changing things until you get it right and can move on. Sure, ai guess that's kind of programming in general, but on this level it's most of your day. No developed cheat codes?

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

#124

Post by ChrisMarshallNY »

> 3 lines of code shouldn't take all day

Sure they should. I often spend all day on negative numbers of lines (I always say that the best code I write, is the code I don't write).

The complaint seems to center on CI/D services that provide inefficient build times. These increase the pain of "round-trip" implement-test-refactor.

That's quite valid, as this is how we tend to work, these days (at least, that's how I work). I often take it a step further, and iterate the design as I progress[0].

But I am one that got their start in the waning days of "big iron," when compute time was the costliest and most time-consuming part of the whole process. You'd need to schedule for computer runs, which would often happen overnight. This meant that it was very important to have your code complete, and debugged, before submitting it for compilation.

Argh. I miss it like I miss a case of food poisoning. It did teach me to do my homework, though.

[0] https://littlegreenviper.com/miscellany/evolutionary-design-...

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

#126

Post by jt2190 »

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…

> In other words, reducing the iteration time reduces the motivation to get it right the first time, and the associated deep reasoning/"mental execution" skills which are required to do so. In order to develop those skills, one should strive to write as much code as possible before running it, and a high iteration time assists with that.

A high iteration time [a.k.a long feedback loop] leads to distraction more frequently than to “deep reasoning”. Human brains seem to be wired to find distraction after about eight seconds have elapsed. [1]

Furthermore, let’s not forget that an IDE doing a lot of error checking real-time, often including partial compilation and execution, so nobody running an IDE is coding for a long period without compiling, they’re more likely coding for a long period without integrating.

If we reframe deep reasoning as “stay engaged with the problem while waiting for some feedback”, we can see that there are a lot of tricks for this: Unit tests, for example, or using a different medium like pencil and paper or a whiteboard. (I’m sure this group can come up with a great list.)

[1] “Response times: The three important limits” https://www.nngroup.com/articles/response-times-3-important-...

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

#127

Post by flohofwoe »

Entirely relying on unit tests for development can never be the only solution, because tests are quite simply not the product, and they shouldn't be a substitute/workaround for fast iteration right on the product. Easier said than done of course, especially in such a complex environment as game development.

The future for fast compiled-code iteration in game development will most likely be hot code reloading, so that code changes are compiled and implanted right into the running game instead of requiring a full linker run and then getting back to the right place in the game to be tested.

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

#128

Post by yjftsjthsd-h »

dotancohen wrote: post #102
danuker wrote: post #84

Earlier quoted context omitted.

I see it like driving stick vs. automatic. Sure, with stick you become aware of how the car works, the engine, torque and clutch, and you get more control. This might be good for learning. But automatic lets you pay more attention to the road ahead, whether you are a new or experienced driver.

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

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

#129

Post by ehnto »

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…

That is a really interesting perspective, and something I have noted about myself when working with Lambda in AWS, which has a god awful iteration time.

My two comments however would be that when you don't know your context, lots of probing is required, and that can take a lot of iterating. In industry work you're very often working on a small part of a larger software orchestration, and it's often entirely new to you when you're asked to work on it. So you don't get access or time to understand the full scope of the software to reason about. So you need to "discover" your context as it actually is at run time. This is especially true when bugsquashing.

My second comment, is that we should all have a good debugger. Having a debugger is like having a superpower. I can come into a codebase I've never encountered before, step through as it runs, gain enormously useful context, and solve the problem I wanted to solve, without ever running the code to completion or having to read every bit of logic.

If I'm working on someone else's codebase, usually I spend time reading to figure out the general architecture, then dive right in with a debugger and start stepping through. I find how to trigger the code paths related to my task, see what's happening as it happens, and get a really good understanding of how it's all running.

In what might be another controversial opinion, a working programmer without a debugger is like a working carpenter who's chosen to do everything with a knife. They may produce good work with their own way, but they could be faster with the proper tools.

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

#130

Post by bpicolo »

vbezhenar wrote: post #96
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.

1. That wouldn't work if code under test uses multiple transactions. 2. Rolling back a transaction is not exactly free. 3. Does not allow running multiple test simultaneously.

> 3. Does not allow running multiple test simultaneously.

It does with almost every form of transaction isolation mode. Read uncommitted in Postgres still behaves as read committed, so in Postgres you're never missing the mark here.

> 1. That wouldn't work if code under test uses multiple transactions.

A lot of abstractions interpret nested transactions as save points for this reason.

It's not the only valid pattern, but it is a consistently behaving one that's straightforward to implement and gets you most of the UX you want from integration test design.

Post reply on HN