151–160 of 213 posts
There's a reason why old-school Naughty Dog games were so refined.
I like Android Studio's approach to running unit tests: It will run them on the host PC instead of deploying them to the target, so you can avoid the often long deployment process.
How I wish a single line code change only took a 15 second build. The java app I work on regularly takes 3 minutes for a single line change. Then you just need to pray that jrebel will work today and actually hot reload your change. Otherwise you have another 8 or so minutes of redploying weblogic. Of course the ideas suggested in this can help, but when you need to run an integration test which also takes minutes to…
I also once spent a week pursuing a small-but-necessary authentication flow change across two dependencies (one of them owned by a different team) and three tests, only to be fired for talking to the other team members directly (I was a mere contractor) rather than playing 'telephone' and relaying everything through my management and their management, which would have made it take a month instead.
[0] It was actually five lines of code.
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…
The problem is many times, you can't really reason through the issues your encountering. For example, if you are trying to talk to a server with an undocumented API flow, or you're trying to coax an in-house library to life, you have no option but take baby steps and test every single change to see if you made progress. In environments (like C++) where the compile times are high, and it's pretty easy to introduce alm…
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…
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.
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…
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'm one if the people that thinks that coding in paper is a great learning task. I tend to not ask people to do that in practice because it's a very effective way to lose control of a classroom, but I do use the second best task that is asking people to explain their code.
Anyway, if thinking about the code is not your focus, the increased feedback cycle is all cost and no gain.
Neves Law says that "the harder a bug is to find, the smaller the fix will be". The worst Neves ratio I ever saw was about a week to two bits, where a plus (0x2b) had to be changed to a minus (0x2d).
Earlier quoted context omitted.
Isn't that just what it's like to be a beginner? I think it's difficult to grasp when you've been coding for a few decades that new developers don't immediately see what effects a piece of code has, they can't just look at a loop for 2 seconds and say "oh, there's an off-by-one there". Sure, I can worry about the big picture while I'm typing out the code because I don't need to pay much attention when I'm typing out…
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…
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 to check off common errors they've been told about, and may arduously step through the code in their head line by line, but an expert sees the code is wrong unconsciously and understands what the code does without stepping through it. The only way to learn that is to engage with code for decades. There are no shortcuts.