Doing More with Less Code | Hacker News Reader

Doing More with Less Code

codewithoutrules.com

67 pointsitamarst45 comments

This post is flawed, starts with the wrong proposition that "10x programmer" means a programmer that writes 10x as much code, that is, it uses number of lines of code as a metric which is a completely wrong metric (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.

With code, less is more, less code to do the same means easier to read, easier to maintain, less bugs. So, a 10x programmer means a programmer who is 10x as productive, that is, delivers 10x as much features, fixes 10x as many bugs or not even that, since sometimes you have to do refactoring which improves the codebase a lot in several ways but doesn't provide as a result either features or bugs.

Actually I would expect the mythical 10x programmer to produce LESS code for the same functionality, and most probably be reducing the amount of code littered by other lesser programmers and starting refactorings that would create abstractions, split classes and make the code more modular, that would have as a result deleting classes and methods, and overall reducing the number of lines of code rather than increasing it...

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.

You've figured out my rhetorical trick :)

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

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

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

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

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)

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 heard of the mythical 10x programmers, programmers who can produce ten times as much as us normal humans.

I'll repeat what I've said before on the "10X" label which causes so many arguments...

To make peace with the "10x" label, I suggest people just think of it as a figure-of-speech instead of a rigorous mathematical term. We don't get hung up when people say "Star Wars IV was ten times better than Phantom Menace" or "I'm not even 1/2 the football player I used to be."

Even if people were to use a new term such as "3-Sigma Programmer"[1] instead of "10X Programmer", the ensuing debates would still be the same.

E.g. "Some people say 3-σ programmers write string parsing loops that are better in speed and quality than 99.7% of the other loops but that 3-standard-deviations-above-the-mean is a myth... etc"

Argument pattern is the same: take a label, any label, hyperfocus on some literal meaning to the exclusion of all else and debate why that mathematical interpretation fails in the real world.

You can interpret the label(s) literally as math or as an English meme. I propose that one of those interpretations will keep your blood pressure from rising.

As a counterpoint to the article, if a programmer knows how to convert a Ruby program with 100 lines and rewrites it in C/C++ in 600 lines so it executes 15x faster and uses less memory so the company can better utilize densely packed virtual machines in a cloud deployment, that's what many would call a "10x programmer" even though none of the inputs & outputs are mathematically "10" anywhere. The programmer wrote more lines of code so that another metric of effectiveness was optimized. The LOC increased but that's irrelevant.

[1]https://en.wikipedia.org/wiki/Standard_deviation

Just to extend your example, that programmer would be a 10x programmer if the achieved goal (runs 15x faster and uses less memory) is valuable to the company.

Adding value depends on the context. If the main problem for the company is that the feature set is not attractive to clients, then speeding things up 15x and using less memory may not make a difference. If however, the feature set is amazing, but customers complain about the product being slow and eating up too much memory, then said programmer is adding a lot of value, thus "becoming" a 10x programmer.

For years I've held the belief that my job (software developer/whatever) is to do as little as possible but it's mostly been met with bewilderment and disdain from most people I've offered it to.

This applies to an even greater extent in a highly resource-constrained environment (such as my startup). My job is as much about what I choose NOT to do as it is about what I actually decide to take on; as .5 of only 1.5 software engineers at my workplace, the lion's share of my role relies on me placing the correct bets on what features (or automation workflows) to implement.

Sadly people often see it as obstruction or laziness, when you point out the possibility that they, and by extension you, might be better of without some feature.

The issues I most often face is explaining the running cost, be it due to complexity or hardware requirements. Some potential or minimal income always seems to trump long term savings. Another is "the customers expect us to have XYZ feature", regardless that you can prove that only a limited number of them actually use it. Far less than required to cover the running cost.

A lot of comments here are focusing on the 10x label meaning. I agree that the author wrongly suggested this applies to LOC, but these are great points for any developer:

- Use the sharpest tool in the shed (programming language, framework, etc)

- Leverage existing code

- Reflect on the problem up front before writing any code

- Relentlessly question if you really need the feature you're adding

These things are the most important things I've learned over my career, and it's astonishing how few people actually do this at all, let alone well. Things like that are the reason I'm moving more towards design, architecture, and project management, because people are generally fucking awful at it.

About the LOC measurement

http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...

My previous job's commit diff was -15k, while still writing a lot of the features. I smiled when I saw that.

The article mentions using libraries to save time.

It's worth remembering that when using a library one should know how it works; not knowing how it works may cause bugs and make development last even longer.

Some libraries are quite useful. Others are strait from the desk of The Ministry of Silly Walks, requiring an obscene amount of facading, adapting and what have you.

It's not like you need to pick through the entire source though. You just need to read the docs. Reading the docs will likely be faster than writing your own.

I've seen people write their own XML parsing libraries, try to handle dates + timezones on their own, and write REST API helpers for products that already had official packages. In each of these cases, even a brief look at some docs and a wild-ass-guess would've been more productive. It's super frustrating to watch.

In my last project I used, ng-admin + postgrest for the administration panel, postgrest behind a small gateway with oauth2 (nodejs rocky + oauth2) to feed the user facing app. Uploads are done directly to S3 that automatically triggers lambda functions to update the database. In the old times I would have done all these with Symfony and it would have been lots more of code.

I also learnt to appreciate more unix command line tools, I think twice if need to write an script, for instance to do webscrapping, sometimes you can get what you need just using curl | pcegrep | uniq | sed, and move on, if you then have the need for more scrapping then yes, it makes sense to invest the time on using a library, scripts etc.

Unless you're in a leadership role, only half of those ideas are going to be available to you.

Also, if you are constantly switching directions without also constantly coming to a deeper understanding of your problem space / market, then all you're doing is destroying momentum rather than creating it. Deeper understandings require orders of magnitude more time, data, and effort to understand the data.

Eventually you'll get that insight but in the meantime it's better to just keep moving forward.

the sounds of a hundred thousand project managers rolling their eyeballs at the prospect of every junior programmer thinking the project doesn't need to be done, or the feature request is pointless.

Every time I refactor something in the code my goal is a PR with net negative lines.

But it takes experience and maturity to not to silly things trying to hit this goal. Sometimes it's just not possible.

0.1x as a term exists only because it's cute.

Instead, perpetually try to be a 0.9x programmer.

> Every time I refactor something in the code my goal is a PR with net negative lines.

Assuming your customer doesn't use cost per LOC as a metric...

That would be awful. I'm glad I have yet to experience that yet. Not sure I could tolerate non beautiful code for the sake of a business metric.

Hardy's rule can be adapted to programming: to code it better, think it gooder. One big difference in productivity comes from making good design decisions early on and not taking shortcuts that weeks later turn into spaghetti hacks.

To me this is the most important thing i have learned in 15 years of coding. Its also the reason why I hate interview "tests", I don't come up with a good design straight away. I prefer to get in idea of what is needed, then think about it for a few days while working on other stuff.

If someone uses interview tests in that way they're doing it wrong.

That's not what interview tests are for; they're for demonstrating a base level of competence and how you think about code during a discussion of the code. Also for acting as a catalyst for more discussion about programming.

You are so right. Good design doesn't just pop out of nowhere. It does emerge early on, but requires work and time while the complexities of the problem are groked.

"10x Dev" doesn't mean "10x Code" it means "10x Productivity" (which hopefully translates to something meaningful for the business). That almost demands a language that allows concision.

Reply on news.ycombinator.com