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

71–80 of 213 posts

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

#71

Post by bipson »

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…

Came here to say this.

I even see the mindset spreading to other activities, like writing an abstract, paper, proposal or preparing slides:

I regularly (more often than not) see students using their supervisors as "CI-chain", submitting iterations with lots of stupid errors, half-baked sentences, unclean structure... because they learned to hit CTRL-b and see what comes back.

Of course there are reasons to talk about half-baked ideas, but if your task is writing a proposal or a section, you should at least be happy with what you wrote before you send it to the Prof, you're wasting his time.

But I also want to say that CI, unit tests and quick iterations are still helpful, even if you know how to approach a problem (i.e. think, research, draft, test, revise, etc.)

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

#72

Post by vbezhenar »

cjfd wrote: post #48
dinvlad wrote: post #39

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

Very good points. In his book 'working effectively with legacy code' Michael Feathers actually defines 'legacy code' as code without tests. Largely because of reasons like you state.

What do you think about code being too smart for current team? I encountered that use-case three times in my career. It was C++ program which was written by very bright person, used template magic, boost and stuff. Rest of the team were ordinary C developers. After that person left, they had to rewrite his program, because it took too much time to understand how it works and to fix or improve it. Second case was when someone wrote some helper program with Haskell which happened to be important. Same story, nobody knew Haskell, nobody wanted to invest into learning, so rewrote in node.js. Third story: someone used reactive API with Java (Spring Flux) and again same story: team don't understand it and slowly rewrote it with ordinary blocking API.

Does that code counts as legacy?

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

#73

Post by brokenkebab »

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…

Your stance looks self-contradictory. An introduced change either brings enhancement, or not. In the latter case you wouldn't expect anybody to be excited. It means one only gets dopamine boost when getting closer to a goal set, i.e. the feedback works absolutely right. If after a bunch of such changes one arrives at "barely working" it indicates poorly defined goal, and/or lack of underlying knowledge. And has nothing to do with length of compilation. Actually, that's what we can expect from beginners, right? With quicker feedback they, most likely, will have a chance to absorb knowledge quicker.

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

#74

Post by max002 »

Haha, so true. People are used to old ways. I know its not c++, but If you run docker on mac or Windows for web dev or any other project that has thousanda of deps you know how painful docker sync is and how slow/crash prone. But hey "docker is easy" :)

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

#75

Post by dezgeg »

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

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

#76

Post by marginalia_nu »

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…

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 the code. The syntax of code is a no-brainer activity. I've been adding semicolons at the ends of lines for longer than some developers have been alive, it's not going to be something I miss. A beginner needs to focus on the details of the lines, which means their code becomes myopic and line-focused. I don't think you can meaningfully widen the scope before you're able to do the simple steps automatically.

Experienced developers typically don't sit like Hari Seldon predicting branches 50k instructions into the future with some extremely elaborate grand master plan, they're so fluent in the code and architecture that they don't need to. This is tacit knowledge that is acquired along the way, I don't think it can be meaningfully practiced.

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

#77

Post by torginus »

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…

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 almost impossible-to-trace bugs, I'm often tempted to do a bunch of changes, and then test them all at once, which will invariably result in something breaking and me having to spend an inordinate amount of time to figure out what went wrong.

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

#78

Post by pjc50 »

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

Perhaps also a "code kata" thing. It may be worthwhile to make beginners do each for a few months just so they have the experience (and find out their own "handedness")

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

#79

Post by angarg12 »

If what is slowing your iteration speed is testing, I'd say you are in a somewhat happy place. At least you can write test, speed up the build, or somehow improve the situation.

What drains my soul is when you need to use legacy or poorly designed tools that slow you down and you can't do much about. Here are real examples of times I wasted entire mornings: tools that, if you make a mistake, leave the environment in an inconsistent state, and then you need to manually fix it (it isn't documented and changes on a case by case basis). If you miss anything or make another mistake, start from the beginning again.

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

#80

Post by blippage »

darkwater wrote: post #66
DarylZero wrote: post #36

Earlier quoted context omitted.

That's not the reason. The work itself is not fun. Even if the whole project has no career purpose, it's more fun to write new code.

It can be fun, it just depends on who you are. Sadly most developers prefer to follow PM and churn in features instead of this precious work.

I actually enjoyed a maintenance project I was on. There was less time pressure. Finding and fixing a bug is a logic puzzle in its own right.

So things can be largely a question of perspective.

Post reply on HN