7 ms·

One of the important lessons you need to learn is that code is a liability not an asset! All else being equal, from a balance sheet perspective having more code

One of the important lessons you need to learn is that code is a liability not an asset! All else being equal, from a balance sheet perspective having more code puts the company in a worse situation. Your job as a software developer is, roughly, to deliver maximum business value with minimum cost, and that includes writing minimum code to accomplish the task. That is what the senior developers are talking about when they're saying you've written too much code. It does sound to me like they've got a well designed system if you can add new features simply by making a small modification and some configuration to the existing code. As long as it's also well tested and well documented (that may be lacking...), you've got the ideal codebase: one in which you can add large amounts of business value with only incremental changes. You mention that this is "great for the business but not much fun for me". I think this is a sign of inexperience. Part of what makes something fun is how difficult it is. If something is too easy it's boring; if something is too hard it's frustrating. In the middle we find things fun. The reason writing lots of greenfield code is fun for you is because it's easy. Understanding and modifying existing code is harder, and that's currently too hard so you find it frustrating. You need to push past this stage to improve as a developer. As you get better, it will become easier to work in existing code and will stop being so frustrating.

arethuza 11y ago
A junior dev I worked alongside a few years back got quite angry with me when we were facing an "interesting" problem - he was well into thinking how he would write code to solve the problem meanwhile I had googled and found an existing utility downloaded it and demonstrated that it worked - 0 lines of code required.... [NB To be fair I had the same sense of disappointment myself years before when I was quite proud of a package to do CLOS object persistence and a more experienced chap told me there already was something to do that...]
RivieraKid 11y ago
The first paragraph is just plain wrong. Code is an asset. Edit: Nice to have a comment downvoted, even though what I said is true.
- pjc50 11y ago
  It's kind of like conventional depreciating capital assets like buildings. A building requires maintenance, utilities, taxes, repairs and so on. If your building is too large for your needs, the costs can become a debilitating albatross round the neck of the business. There have been plenty of European aristocracy bankrupted by having a house that was too big. In programming terms, it's very tempting to say, "this room is untidy, I'm going to build a new one." It's certainly more fun than tidying your room. But this is how you get sprawl and bloat.
  - RivieraKid 11y ago
    Well, you can simply give up ownership rights on the code. If code was indeed a liablity, it would be profitable to transfer ownership to (for example) me.
    - Someone 11y ago
      You can give away your castle with a license indicating that nobody can keep you out, too, but that doesn't guarantee that it will be maintained so that you can keep using it, either.
- mbrameld 11y ago
  You're being downvoted because while you were technically correct you completely missed the point and your comment adds nothing to the discussion. But at least you got the satisfaction of "correcting" somebody, eh?
  - RivieraKid 11y ago
    I got that he was trying to say something along the lines of "more code = more maintanance"... but code is simply not a liability. (Yeah, I have a natural urge to correct stuff that's incorrect, but that's not an uncommon trait.)
vbtemp 11y ago
> One of the important lessons you need to learn is that code is a liability not an asset I cannot upvote this enough.
- deleted 11y ago
  [deleted]
- RivieraKid 11y ago
  This is simply not true. If code was an liability, it would be profitable to transwer owenership of it to other people. I haven't noticed any software company doing that.
  - e28eta 11y ago
    Maybe not what you meant, but I immediately thought of SaaS. Or various companies' policies of open sourcing non-core software. Both of those are along the lines of "I need code to do this thing, but I don't want to be the (sole) maintainer." You could write your own language, IDE, OS, build system, source control, networking library, logging library, shopping cart, payment processor, etc.
  - pc86 11y ago
    That's an overly pedantic use of the word "liability." It simply means that all things being equal, it is better to do $THING in 50 lines of code than it is to do it in in 500.
  - lojack 11y ago
    This is easy to explain when you treat third parties as liabilities as well. For many companies this is a bigger liability than maintaining the code in house. I recently made the decision to have a third party build a component as opposed to doing it in house. The cost and time to build a component in house vs using a third party ended up being a wash, but the third party offered to maintain and support a solution so this presented less risk to us. This major risk we incurred was in vendor lock-in. These types of trade offs happen all the time. Think about virtually any SAAS offering that could otherwise be built in house.
  - 11y ago
jmilloy 11y ago
Great comment. It's a bit hazy when you say that code is a liability and also that they've got an ideal codebase because you can add value easily due to the existing code. Maybe something more like: "new code is a liability, and tested, extensible code is an asset."
- a-priori 11y ago
  In this metaphor, all code (new or old) is a liability and the revenue/value stream derived from it is the asset. As a developer, you're trying to maximize assets minus liabilities. It's okay to take on a liability as long as it's balanced by a greater asset. But buying on margin increases your volatility and risk exposure, so you shouldn't take on more than you need to. Assuming zero transaction costs, it's always a good idea to substitute less code for the same benefit.

arethuza 11y ago

A junior dev I worked alongside a few years back got quite angry with me when we were facing an "interesting" problem - he was well into thinking how he would write code to solve the problem meanwhile I had googled and found an existing utility downloaded it and demonstrated that it worked - 0 lines of code required.... [NB To be fair I had the same sense of disappointment myself years before when I was quite proud of a package to do CLOS object persistence and a more experienced chap told me there already was something to do that...]

RivieraKid 11y ago

The first paragraph is just plain wrong. Code is an asset. Edit: Nice to have a comment downvoted, even though what I said is true.

pjc50 11y ago
It's kind of like conventional depreciating capital assets like buildings. A building requires maintenance, utilities, taxes, repairs and so on. If your building is too large for your needs, the costs can become a debilitating albatross round the neck of the business. There have been plenty of European aristocracy bankrupted by having a house that was too big. In programming terms, it's very tempting to say, "this room is untidy, I'm going to build a new one." It's certainly more fun than tidying your room. But this is how you get sprawl and bloat.
- RivieraKid 11y ago
  Well, you can simply give up ownership rights on the code. If code was indeed a liablity, it would be profitable to transfer ownership to (for example) me.
  - Someone 11y ago
    You can give away your castle with a license indicating that nobody can keep you out, too, but that doesn't guarantee that it will be maintained so that you can keep using it, either.
mbrameld 11y ago
You're being downvoted because while you were technically correct you completely missed the point and your comment adds nothing to the discussion. But at least you got the satisfaction of "correcting" somebody, eh?
- RivieraKid 11y ago
  I got that he was trying to say something along the lines of "more code = more maintanance"... but code is simply not a liability. (Yeah, I have a natural urge to correct stuff that's incorrect, but that's not an uncommon trait.)

vbtemp 11y ago

> One of the important lessons you need to learn is that code is a liability not an asset I cannot upvote this enough.

deleted 11y ago
[deleted]
RivieraKid 11y ago
This is simply not true. If code was an liability, it would be profitable to transwer owenership of it to other people. I haven't noticed any software company doing that.
- e28eta 11y ago
  Maybe not what you meant, but I immediately thought of SaaS. Or various companies' policies of open sourcing non-core software. Both of those are along the lines of "I need code to do this thing, but I don't want to be the (sole) maintainer." You could write your own language, IDE, OS, build system, source control, networking library, logging library, shopping cart, payment processor, etc.
- pc86 11y ago
  That's an overly pedantic use of the word "liability." It simply means that all things being equal, it is better to do $THING in 50 lines of code than it is to do it in in 500.
- lojack 11y ago
  This is easy to explain when you treat third parties as liabilities as well. For many companies this is a bigger liability than maintaining the code in house. I recently made the decision to have a third party build a component as opposed to doing it in house. The cost and time to build a component in house vs using a third party ended up being a wash, but the third party offered to maintain and support a solution so this presented less risk to us. This major risk we incurred was in vendor lock-in. These types of trade offs happen all the time. Think about virtually any SAAS offering that could otherwise be built in house.
- 11y ago

jmilloy 11y ago

Great comment. It's a bit hazy when you say that code is a liability and also that they've got an ideal codebase because you can add value easily due to the existing code. Maybe something more like: "new code is a liability, and tested, extensible code is an asset."

a-priori 11y ago
In this metaphor, all code (new or old) is a liability and the revenue/value stream derived from it is the asset. As a developer, you're trying to maximize assets minus liabilities. It's okay to take on a liability as long as it's balanced by a greater asset. But buying on margin increases your volatility and risk exposure, so you shouldn't take on more than you need to. Assuming zero transaction costs, it's always a good idea to substitute less code for the same benefit.