Hacker News Reader

> If programmers were paid for lines of code, copy-pasting would be best practice, and all kind of verbosity and unnecessary code or boilerplate, even dead code would be everywhere.

Huh. Is that what it "would be" like.

I have technical leads tell me to copy paste code all the time instead of making better abstractions. It drives me slightly mad.

I've generally followed the rule of thumb:

If you're doing the same thing in two places, ok, if you are doing the same thing in three places, refactor.

Let's me get away with copy pasting while I'm quickly prototyping something out, but reminds me that I need to clean it up before I try to iterate again. Plus, it's unlikely that I'll hit the right abstraction on the first or second time I see a problem. Better to wait until I've seen it three times before refactor.

I am of a different persuasion. Even if you are doing one thing, but it is indeed a thing, refactor it as a separate abstraction. You will end up with a better set of building blocks.

all the better for maintaining a clean suite of unit-tests too!

True.

> while I'm quickly prototyping

I think any kind of skullduggery is fair game at this stage when you just want to "get it to work". For me the rule of thumb to go beyond this point is the commit (or push if I'm using git). After that point you lose control of it. Other people see it, and start to poke around and change things and retrospectively delivering on your good intentions to provide "done" code becomes more difficult. Always do a personal review before letting your code out of it's box. Of course if you can find somebody who's interested get their feedback too ...

I'll forget to do it if I wait until the third time. I can't keep track of everything, you know.

My worry in that case though is you could end up with a whole heap of unnecessary abstractions which can make reading by a third party (or yourself even in 6 months) a little more tricky. I'm seen so many functions of the like of `Util.checkNull(String str)` where simply `str == null || str.empty()` would have done.

Indeed. Most "enterprise" Java code just makes my almost cry when I have to read it. WET is the order of the day.

I've been doing mostly front end JS work the last year (as opposed to dabbling), and whenever I have to go back to do Java stuff again, it's really painful.

But hey, we got static types, right? So we "know" our code has few if any bugs in it. (riiiiiiiight)

> With code, less is more, less code to do the same means easier to read, easier to maintain, less bugs.

Whilst this can be true, it's not always the case. Squashing code down to fewer lines can also mean doing something in a way that is much harder to understand or hides bugs behind complex subtleties in the code. Obviously it's a balance, and "lines of code" is, as usual, a poor metric of code complexity and readability.

For me, fewer lines means that it is easier to get a whole picture. More verbosity often induces splitting code in many methods.

As always there is a balance, but I am more often annoyed by gratuitous verbosity than by cryptic constructions.

>With code, less is more, less code to do the same means easier to read, easier to maintain, less bugs.

I'll show this quote to my lil bros living in ~/bin/*.pl

Consider the amount of code required to implement Perl's built-ins.

I think a 10x programmer is someone whose efforts increase profits by 10x. A lot of people think they are 10x programmers because they can optimise something that nobody really cares about.

  I think a 10x programmer is someone whose efforts increase 
  profits by 10x.

Careful ;-). I think that falls into the same trap drKarl's critiquing. Someone spewing unnecessary lines of code can jack up their line count and bill more hours, thereby increasing profits. They aren't making complex problems disappear.

If you're in a billable hours environment, you can't be 10x as profitable by billing more hours. You need a higher billing rate (that is actually paid by clients). This is hard to get and keep if you are inefficient.

I agree that pulling it off requires help. That said, I've seen it happen where folks turn a (should be) 1 day task into a 10 day project. That's 10x more profitable.

To be fair to the parent comment, I think he's getting at the super programmers that crack problems others can't. This capability provides competitive advantages. Maybe I'm talking about the other side of the table and did a poor job at that. Sorry!

Sure, I understand the gist of what you're saying (and what the parent comment was saying.) But the example doesn't work.

Programmers at a consultancy/agency are probably billing 20-40 hours no matter what. So if someone spends 80 hours on an 8 hour project, that just means they didn't work on other projects. This impacts cashflow. Additionally, an inflated bill may be challenged and marked down. So, there's no way for a programmer to be 10x more profitable unless they had nothing else to do otherwise.

Now, a company can be 10x more profitable if they hire enough programmers so that they have the capacity to inflate every project. ;)

To be a 10x programmer at a consultancy, you need a combination of a high billing rate and long hours, but the easiest way is to implement a productized service that is billed by value/fixed price instead of hourly.

For example, I know someone whose company was paid $81,000 for him to build an application, but he made a lot more for them charging about $40,000 to re-implement the same thing over and over for other customers. He didn't hit 10x, but he contributed mid six figure revenue in a year whereas the $81,000 was paid over 18 months. Obviously, he couldn't have done this if he was inflating his time.

That was my immediate reaction as well. "10x" means "10x productivity" which is likely inversely proportional to the SLOC/etc. If you have to spend your time writing code that isn't meaningful that's code that erodes productivity.

You've figured out my rhetorical trick :)