[deleted]
3 lines of code shouldn't take all day
111–120 of 213 posts
Re: 3 lines of code shouldn't take all day
#112Earlier 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.
Interesting. I was thinking that you pay more attention with manual. The point of manual shifting is not in how the car works. The point is in knowing what will happen before it will happen.
To me, it diverts your finite attention to the mechanics of someone a simple machine can do.
Re: 3 lines of code shouldn't take all day
#113noob like me takes all day
Re: 3 lines of code shouldn't take all day
#114This 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’s called compiler driven development.
Re: 3 lines of code shouldn't take all day
#115By comparison I've worked with someone who pushed a '2 line fix' live which had fallout which lasted >2 weeks because their code was pushed without checking to production and had hard-coded their uid into the fix because it was a quick 'hack'...
The main reason when cornered was 'running pip install is too difficult to run the test-suite' (tests themselves took We eventually (1 week later) got permission to pull the release from our shared (pseudo write-only) storage area but as he was project lead he tagged a new minor version for his '2 line fix' without consulting anyone and our users were reluctant to move to a new bugfix release unless prodded with a red-hot poker.
Can't say I miss working with _some_ programmers turned managers.
Re: 3 lines of code shouldn't take all day
#116This 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 the same vein: I'm very used to "printf debugging". When I use a language where it's harder to do that, I feel like I improve as a programmer because I spend more time reasoning and thinking about my code instead of directly trying to fix the problem I have right now. As a more general thing: you can learn a lot by removing tools that you usually use from your toolbox. For example, going from a managed language to…
My strategy is you spend 80% of the time on the company problem, and 20% for learning. By that you have both the time to deeper your professional skills and get new inspiration from new technology.
Re: 3 lines of code shouldn't take all day
#117In a future post, I will go over how web developers needs to start taking iteration time more seriously as the influx of new tools and frameworks starts to bloat up build times. The newer tools in web dev have crushed iteration times to a fraction of what they used to be. A combination of things like esbuild, fast refresh, yarn's offline cache, and a few other bits can get your iteration times on a site you're manual…
> SvelteKit even goes further by using Snowpack to remove the bundling step entirely.
FIY SvelteKit is using Vite 2 instead of Snowpack
Source: https://twitter.com/Rich_Harris/status/1367577006355976194
Re: 3 lines of code shouldn't take all day
#118The other day I was working on an embedded system and running out of space for the program (512KB). It took me two days to rewrite a few sections to use compressed data instead of the "easier to read but bulkier" original way. The end result to the user was the same, but used 10KB less space.
Re: 3 lines of code shouldn't take all day
#119Going 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…
Interesting, in my experience React allows me to write more testable code in the front-end than I ever could. Given how React will handle updates to the DOM given changed state, I can extract complex state manipulation code (i.e. code that's most important to test) into independent functions that take state and an event and produce new state, rather than having that all intertwined with DOM manipulation code.
And when it comes to testing what your DOM looks like, even though that does often involve spying for changes (after all, you're testing whether they occur), that's not on the actual DOM but on the virtual DOM, which makes it easy and efficient to run in a non-browser environment.
Re: 3 lines of code shouldn't take all day
#120Going 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…
No if you delegate manual tests duty to your customers shorturl.at/mpxS4
Your shorturl is broken, also please don't use URL shorteners in here.