Sometimes a negative amount of code lines took me whole days...
3 lines of code shouldn't take all day
181–190 of 213 posts
Re: 3 lines of code shouldn't take all day
#182This 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…
Oh dear. Oh dear, oh dear.
Let me tell you, time to iterate on a huge 50 year old code base is through the roof and reaching out into interstellar space. The resulting code is pure and utter trash.
I would kill to have to have a quick feedback loop and at least be able to address quality issues through training, culture, or technical controls.
The alternative is fighting against a giant, heavy machine with a lot of inertia in the wrong direction.
Re: 3 lines of code shouldn't take all day
#183Entirely 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…
> Entirely relying on unit tests for development
I don't think anybody is ever suggesting this - but I do see people suggest the opposite: that all testing should be end-to-end "black box" testing, and unit tests are a waste of time. If you actually want to ship something that works reliably, you have to do both unit testing and end-to-end (integration) testing. I've never seen anybody sacrifice integration testing. I have seen them sacrifice unit testing.
Re: 3 lines of code shouldn't take all day
#184This 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…
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.
Re: 3 lines of code shouldn't take all day
#185Uhhh... just improve your build process.
Re: 3 lines of code shouldn't take all day
#186This 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.
I have been coding for over 30 years and I can barely write one function without at least making some typos if not logical errors. I would never code for a couple of hours without compiling/testing.
Re: 3 lines of code shouldn't take all day
#187Earlier 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.
Would it be possible to cp /var/lib/your-database /var/lib/your-database-clean after it's been set up, then after each test just overwrite /var/lib/your-database again? I'm sure that the database will need to be properly shut down and restarted, but that is far less expensive than rebuilding a large database each time. Disk is cheap. CPU and memory are the expensive assets.
[deleted]
Re: 3 lines of code shouldn't take all day
#188Bill Atkinson, the author of Quickdraw and the main user interface designer, who was by far the most important Lisa implementor, thought that lines of code was a silly measure of software productivity. He thought his goal was to write as small and fast a program as possible, and that the lines of code metric only encouraged writing sloppy, bloated, broken code.
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
Re: 3 lines of code shouldn't take all day
#189I took 4 days to find root folder and I'm still finding, I think coding is not for me
Re: 3 lines of code shouldn't take all day
#190Going from "manual testing" to automated testing is the biggest jump. Unfortunately, lots of folks (both developers and managers) fall into the trap of thinking they will "use up" their development time on automated tests, and not really thinking how much time they're already wasting just to do (incomprehensive and hand-wavy) manual tests each time. And while this strategy might work for the folks who actually wrote…
This is where I stop understanding modern ui frameworks. Instead of making an ui inner machinery (controllers) as a set of modules which could in theory run even in a non-browser environment, they pile up everything together into dom/etc. UI could be just a thin layer over usually testable ui-controllers, whose methods could be called by either controls or offline test suites (as in most desktop frameworks). But nope…
This is how both Vue and Angular work.
You have a “data” as a model sitting between the DOM and the controller (mainly methods and watchers). There are some gray lines, like computed properties, but otherwise the controller can run without the DOM and vice versa, you can easily force the model into a state to see how the view will look like.
A lot more testable than the old spaghetti of onClick and getElementById().addEventListener.