Hacker News new | past | comments | ask | show | jobs | submit login

Another case of someone discovering, after 10+ years in tech, that code is a liability and you're supposed to solve problems instead of chasing trends and padding the resume.

Great that he's spreading the word!




> you're supposed to solve problems instead of chasing trends and padding the resume

Yeah I thought that until I had to look for a new job and my resume just had boring old technology on it. Now I make sure I do some padding!


Agree, commenter above you might have thought resumes and interviews are related to the job we ought to be doing and they aren’t.


History is filled with re-discovery and explanation of things that were blindingly obvious to the generation that came before.


"Those who cannot remember the past are condemned to repeat it."

― George Santayana

"I've got news for Mr. Santayana: we're doomed to repeat the past no matter what. That's what it is to be alive."

― Kurt Vonnegut


"Those who can remember the past are condemned to watch everyone else repeat it."

-- I have no idea who originally said this, and DuckDuckGo doesn't seem to be especially helpful in enlightening me on the origin of this particular corollary to Santayana's quote


On an individual level, Vonnegut is wrong. On a societal level, he is right. Santayana is still right.


There's even an expression for it: reinventing the wheel.


No, reinventing the wheel is alright; at best you may find a new and better kind of wheel, at worst you'll still learn something. This is forgetting that wheels can be round.


Our lifetime is finite. Given the choice, I'd rather invent the car than reinvent the wheel.


It's nice that different people have different interests. I, for one, find materials science fascinating and car engineering rather bland.


Thus, reinventing it, no?


Learning from the past isn't to prevent you from reinventing the wheel but from reinventing the pothole.


Nothing wrong with reinventing potholes...

https://www.indy100.com/article/this-man-is-painting-penises...


Only for those who don't understand the euphemism :). That guy actually learned from past mistakes and avoided reinventing them (methods that never worked).

What the original saying is about is pretty clear from the words "condemned" or "doomed" to repeat it (depending on the version). [0]

The saying is not about "reinventing the wheel" as in "refining/reinventing something already positive". It's trying to steer people away from major mistakes. Like ones that lead to great human tragedies and loss. Of course, everything can scale, it can affect an individual or the whole world.

[0] https://en.wikiquote.org/wiki/George_Santayana#Vol._I,_Reaso...


The funny thing about that expression is that wheels have never been reinvented. As far as we know. The Summarians had them, and the technology spread through contract with other civilizations. But not as far as we know re-invented anywhere else.


I think people at the same epoch living in other continents did reinvent them.


That's independent invention, not re-invention. Reinvention requires that you could conceivably be aware of / be using an existing technology, but instead you choose to create it from scratch yourself.


Fair enough, I guess you're right.


No, your mandate is to advance your career, not solve problems. If you’re rewarded for resume padding more than problem solving then keep resume padding.


It is nice to be idealistic, but what you wrote is true. Just like people think companies are doing best things for their customers. Companies do what is best for them, and it happens to align with what customers need, sometimes it is better for company to do something that is not good for their customers. The same applies to employees, most of the time what you do aligns with company goals, but when it does not, you have to change job or do something else.


chasing trends is a problem but suffering java <5 too

You can deliver so much more, so much safer using other techniques...


I think it makes sense to keep up with the latest version of the programming language you use, and keep updating the codebase.

The important part is not introducing an entirely new language that no one knows, or changing around the entire architecture without really being able to understand the long term consequences.

Also, after moving to C#, I don't know why anyone uses plain old Java anymore. C# runs on Linux now. It's not the 90s anymore. Oracle is the dinosaur and MS now is kind to its developers. Plus I'm hoping that client-side C# will take off with WebAssembly.


As a previous fan of C# and a long time Java sufferer, I'm pretty sure it's too little, too late for C#. Sadly, years of being locked to Windows has stunted the C# ecosystem and given Java enough time to get less horrible.

Java 8+ is okay. Lombok helps. There's other great, mature libraries around. There's a choice of IDEs. There's JREs to choose from - there's even JVMs to choose from. Gradle makes build files not suck and makes it easy to add static checking and linting to the build process. AFAIK, C# doesn't have auto-formatting options outside the IDE.

As much as I used to have your view, Java is alive, works fine, and makes money. Or Minecraft mods.


Many consulting shops actually use both, they see it as an asset instead of doing platform wars.

Not only Java vs C#, rather JVM and CLR languages.


Because there are plenty of platforms where Java runs and C# does not, the world is not constrained to Linux and Windows.

Copiers, phone switches, IoT gateways, SIM cards, military control units, drones, Intel ME and a couple of phones.

And all of them have libraries that work across all JVM implementations, regardless of the OS, not the hit-and-miss that still happens between Framework and Core, without a good story how to go cross platform [1].

As for Oracle, they rescued Java while no one else cared [0], kept Maxime alive transforming it into Graal, made several improvements to the language, while allowing jars from 20 years ago to still run unmodified in modern generations of the runtime.

I use both platforms since their initial releases. Each of them has plus and minus.

[0] - Only IBM did an initial offer, that they withdrew afterwards.

[1] - Naturally there is Xamarin, but it isn't without its issues and doesn't run everywhere where Swing, SWT or OpenFX run.


> MS now is kind to its developers

As long as you like telemetry: https://github.com/dotnet/cli/issues/3093


> The important part is not introducing an entirely new language that no one knows

> I don't know why anyone uses plain old Java anymore

You see, if we refuse to change, we can't ever get better.


Sorry, I meant on new projects. I'm not talking about using the latest and shiniest thing, I mean using C# or Python or some other language.

However if youre strongest in Java then you should probably do Java.


I think the best example of this is IDE and text editor preferences.

They are totally regional, programming-language subculture, and age related

The proponents of Atom/VSCode/Sublime/VIM etc will swear by it to the level of gatekeeping other competent software engineers away from them if they don't use that particular editor, and they all do - or can do - the same thing.


Code is not "a liability".

It is a tool that can be used masterfully or utterly abused.

Every craftsman has to invest in their tools. And for someone to truly master their craft they must sometimes hone their tool skills speculatively, without short-term gain, and by sacrificing the time and attention used for other things, like actual projects.

If everyone just obeyed their project manager and always focused 100% on the problem at hand, we would be producing sad, boring things. If you want to see what that's like look at enterprise applications.


Code absolutely is a liability. It is not a tool, it's a means to an end.

A simple tool, like a hammer, is not volatile over time. The house that you build with your tools is. It will weaken and rot, and given enough time it will crumble. It takes care and maintenance to keep it safe to live in.

It is the same with code in production; at some point in time in the future, through no fault of your own, the code can become "wrong" as reality changes around it.

Code is also costly to maintain, sometimes even for small code bases. As the world changes, so must the code.

One of the definitions of "liability" in the Merriam-Webster dictionary [0] is "a feature of someone or something that creates difficulty for achieving success". This definition is often met by code.

[0] - https://www.merriam-webster.com/thesaurus/liability


Strictly speaking, code is both an asset and a liability (as in double entry book keeping, you can’t have one without the other). It depreciates over time.

A simple tool like a hammer is rarely treated like an asset as it is expensed up front.

Code can generate cash flow through its replication and exchange, or its application. Whether this is higher than its depreciation and maintenance costs determines whether you’re losing money on it.

The above is an analogy of course, In actual financial accounting we typically see only see code or “knowledge capital” on the books after acquiring another company, usually as a fat chunk of “goodwill”.


> It is not a tool, it's a means to an end.

You could almost call it "something (such as an instrument or apparatus) used in performing an operation."[0]

[0]https://www.merriam-webster.com/dictionary/tool


If you are going to use my own trick and use the same dictionary against me, at least have the common decency to also use my own words against me!

Definition 1C in the link you provided lists "a means to an end" as a definition of a tool, which I explicitly mentioned code was.

So I must concur, code is a tool. But I'm adamant that it is also a liability.


It may not be sexy, but a good chunk of civilization runs on sad, boring enterprise applications. I for one am proud to build apps that are useful enough that businesses are willing to spend a large amount of effort and money to use them. Even if they are so ugly that they occasionally cause users’ eyeballs to bleed.


Code is absolutely a liability. Every line written must now be maintained which incurs an ongoing cost.

What was missing in the gp comment is that code is also an asset. The goal is to have the value of the asset greater than the liability. This ratio changes over time given a multitude of factors like problem domain and how well the original code was written.


Agreed. A favorite quote: “[E]verybody wants to build and nobody wants to do maintenance.” - Kurt Vonnegut, Hocus Pocus

For a long time, my bias was to write code when faced with a problem, without realizing the debt I was taking on and the other solutions available.

https://www.nemil.com/on-software-engineering/dont-write-cod...


In the real world with limited resources, limited skills, limited budgets and limited brain power, yes code is a liability. Not only a liability, but a liability among other things.


>In the real world with limited resources, limited skills, limited budgets and limited brain power, yes code is a liability.

That's an unbalanced conclusion. Code can be a liability but it can also be an asset.

Do we have limited resources? Maybe writing new code can help. E.g. In cars, the electronic fuel injectors have computer code determining the optimal amount of gas to inject to minimize fuel usage. Fuel efficiency is improved over older "non-computer-code" carburetors. Computer code is an asset that's equivalent to discovering new proven oil reserves.

How about the limited resource of bandwidth on networks? Code and algorithms like h.264/h.265 that shrinks video enough to make it practical to stream to homes maximizes the existing network without having to lay a bunch of new fiber optic cables to every house.

And consider all these YC companies that aren't worth much today. How do they become more valuable? They need to write more code. New features that customers find valuable requires coding. Even if the startup's code does not have patents, it will still be part of the tech portfolio assets that the acquiring company will include in the purchase.

The "code is a liability" seems to be true if one limits their focus to negative situations like npm leftpad and the Boeing MCAS accidents. In contrast, I don't think the astronauts thought the Apollo Guidance Computer was a liability if it helps them get to the moon.


Code may be necessary to write software, but it's still a liability. All else being equal, accomplishing a task in n lines of code is worse than accomplishing it in n - 1 lines.

That's where those aphorisms come from. No code runs faster than no code! No code has fewer bugs than no code! No code is easier to understand than no code!


We all know that. We are not arguing with that. We all understand that code is always written to solve a problem or make something more efficient, or create a new functionality. In that way it is most of the time an asset. That is a given. What we are talking about is a higher-level view which you get from a lot of experience in big codebases and big projects, in which code is almost always also a liability. It means that when you write a piece of code, the wise thing to do is to always assume that it will be a liability (in addition to all the wonderful things it does) to someone, in some situation, in some time. That way one can easier think through all the ways this liability can show itself, and thus somewhat mitigate those ways. Returning to original topic, choose a stable mature language/system which a lot of programmers know, instead of a new shiny one (even though the shiny one might be 5% more efficient in lins of code or something) - is a great way to reduce the liability surface in the future.


> That's an unbalanced conclusion. Code can be a liability but it can also be an asset.

maybe that's why he said:

> Not only a liability, but a liability among other things.


>maybe that's why he said: > Not only a liability, but a liability among other things.

It was my mistake then and I misinterpreted "among other things" to mean : "Code is not just a liability but it's a liability among the other things I just listed like limited resources and limited brainpower" instead of "Code is a liability among other things I won't say explicitly like code also being an asset".

Because I interepreted it the 1st way, I wanted to emphasize the opposite view: that limited brainpower is why code can be an asset to relieve humans from mundane boring calculations to redirect that precious brainpower to higher level creative thinking. Limited resources also motivates new code that can be an asset to expand those resources.


I can understand being confused by that wording, it wasn't the greatest. :)


Code is a liability; functionality is an asset.


If you want to spend time learning new tools, that’s fine. Don’t do it during a critical project. Don’t make your learning projects a liability for your colleagues.

Craftsmen are experts at applying a limited set of tools. That’s why they’re craftsmen. You hire them because they’re the best at doing the thing you hire them to do.


> My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.

~ Dijkstra (1988) "On the cruelty of really teaching computing science" (EWD1036).


Exactly, if it was a liability, you would simply delete it, because unlike real liabilities, it's legal.


You don't delete it because it's a liability in the maintenance account but it's an asset in the features account.


So everything is a liability?


In the double entry bookkeeping sense that GP is using it, yes, everything is a liability. They’re also necessarily equal, which I think is where the disconnect between the analogy in the post and the analogy here comes from.


> If you want to see what that's like look at enterprise applications.

If you think that is an argument against enterprise, you might want to take another look. I spent the early part of my career in enterprise, then moved to startups that serve government customers. Every app I have ever written is boring. I've been working on one boring app for most of the last 7 years. 7-figure ARR, and acquired, but boring.

Yet I consider my career, and those apps, to be great successes.


Coding is a tool.

Code is the result of that tool. If you use a tool to build something you're constantly repairing/maintaining, then its a liability.


I thought this was one of the best articulations, though. All it needs is a CC-BY-SA license so it can be used outside of one blog.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: