3 lines of code shouldn't take all day • Hacker News Board

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

#101

Post by hu3 » Thu, Dec 16, 2021, 10:59 AM UTC

vbezhenar wrote: post #72

cjfd wrote: post #48

Earlier quoted context omitted.

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…

This is where Go shines in my opinion. It's really hard to write smart Go code.

Sure it is a bit verbose but dam is it easy to understand due to sheer bluntness and lack of magic.

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

#102

Post by dotancohen » Thu, Dec 16, 2021, 11:04 AM UTC

danuker wrote: post #84

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…

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-connected smartphone calling them incessantly, which is propped up close to eye level and blocking part of the windscreen.

Contrast to manual drivers, who will happily drive along without music. Far less prone to distractions and far less likely to touch the phone.

One could argue that the focused people who enjoy driving do prefer a manual transmission, to which I'll agree, but I'll counter that the manual transmission itself fosters that focus and enjoyment in the driving experience. The boring automatic is what invites distraction and does not foster enjoyment in the driving experience.

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

#103

Post by dotancohen » Thu, Dec 16, 2021, 11:06 AM UTC

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 love chasing down other people's bugs. I often get to fix other developers new shiny features shortly after they've hit production. And I love the challenge.

It's also nice that bug chasing has less of an expectation of giving good times estimates, which the software industry is famously poor at anyway.

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

#104

Post by marquis_andras » Thu, Dec 16, 2021, 11:09 AM UTC

vbezhenar wrote: post #72

cjfd wrote: post #48

Earlier quoted context omitted.

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…

Michael Feathers uses several definitions of legacy code, depending on the situation. In your situation, he defines legacy code as follows.

"legacy code is the product of ... when your team turns over faster than your code turns over." [1]

1. https://www.software-engineering-unlocked.com/legacy-code-mi...

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

#105

Post by dotancohen » Thu, Dec 16, 2021, 11:09 AM UTC

petters wrote: post #91

vbezhenar wrote: post #69

Earlier quoted context omitted.

Docker helped me to significantly increase unit test speed on one project. Each test was recreating database, run dozens of DDL scripts over and over (to ensure clean environment). I reimplemented in in a way that DDL scripts were run once, then container with database was commited to an image and that image was re-used for every test. Also multiple containers were run at once, so tests could be run simultaneously. D…

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.

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

#106

Post by dotancohen » Thu, Dec 16, 2021, 11:11 AM UTC

wruza wrote: post #89

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…

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…

For what it's worth, a popular Python testing framework uses something like `expect` under the hood to simply check that the output matches a predefined output.

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

#107

Post by dotancohen » Thu, Dec 16, 2021, 11:12 AM UTC

marquis_andras wrote: post #104

vbezhenar wrote: post #72

Earlier quoted context omitted.

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…

Michael Feathers uses several definitions of legacy code, depending on the situation. In your situation, he defines legacy code as follows. "legacy code is the product of ... when your team turns over faster than your code turns over." [1] 1. https://www.software-engineering-unlocked.com/legacy-code-mi...

Those two definitions just sold the book to me. Thanks.

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

#108

Post by jeffrallen » Thu, Dec 16, 2021, 11:24 AM UTC

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…

Hello, fellow ex-Cisco employee.

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

#109

Post by fbn79 » Thu, Dec 16, 2021, 11:32 AM UTC

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…

No if you delegate manual tests duty to your customers shorturl.at/mpxS4

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

#110

Post by barrkel » Thu, Dec 16, 2021, 11:35 AM UTC

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…

If you're ramping up, you cannot write a significant amount of code without errors. If you try, it's much harder to figure out which change caused the failure of a previously working system, because you're less aware - by definition, ramping up - of the mapping between edits and failure modes.

Once you're ramped up, yes, it's more efficient to produce more code and fix the odd issue that crops up. I rely more heavily on high level, slower running functional tests on code where I've been the primary author or have worked on the system for a long time. But just be aware of what you're optimizing for: tenured employees.

I wouldn't kid yourself that it's "deep reasoning", beyond people on a dopamine kick, or beginning programmers working with simple data structures. You can't reason much about a system you don't know, because everything is details - millions of lines of code, you can't mentally evaluate it. It's not until you've built a mental model of the moving parts, and are able to mentally abstract away details not relevant to your task, that you can think things through in the large.