3 ms·

> nobody cares about how good is your code the person who has to maintain it?

sbhn 8y ago
Yeah, somebody has to work super hard, to make somebody elses job super easy. Write it yourself, or maybe you cant, and blaming someone elses code is a distraction to take the attention away from yourself.
- afarrell 8y ago
  It is a poor carpenter who blames his tools. Why? Because a skilled carpenter has money to buy the best tools. Tools matter. Developer experience matters. Cognitive cost matters when tools are used by non-infinite brains. If you don’t believe that, then build a product with a confusing UI and try selling it. New != good though.
  - noir_lord 8y ago
    It's rare that new ever equals good, even the best stuff takes time to mature into good. It starts with interesting and then moves on to good later I think.
  - rangibaby 8y ago
    A skilled carpenter has the tools that are necessary for the job, their price doesn’t matter. In a couple of industries I have worked in there is a tier of expensive tools that are basically ways of extracting free money from professionals (when someone else is paying) and rich amateurs who want to feel superior to their friends
    - afarrell 8y ago
      > A skilled carpenter has the tools that are necessary for the job, their price doesn’t matter Very true. A skilled carpenter is discerning about his tools and know where it matters to spend more money.
afarrell 8y ago
Or the business owner who is frustrated that their product still lists Czechoslovakia as a country. (Yes, this is true of ADP)
afarrell 8y ago
When you walk into a restaurant, do you notice if they have an efficiently laid-out kitchen with mise-en-place, good relationships with their suppliers, or a refrigerator at the proper temperature? No. But you do notice when you food is slow to arrive, the food doesn't taste fresh, or the chicken gives you food poisoning. —— You also probably notice if they are using roof tiles as plates, but that doesn’t make them good cutting boards in the kitchen.
- christophilus 8y ago
  Yes. I notice those things. I notice if they have an A or B or C rating, which is a reflection of some of those. I notice if they are in business, which after 5-10 years, is a reflection of some of those. I notice if the employees seem happy or frazzled which is a reflection of some of those. The same goes for software projects. It's not always clear to me what the code quality is beneath the products I use, but the products I use for the long-haul almost certainly either A.) have reasonably high quality code or B.) are reasonably complete, because they are well maintained and don't sink beneath the weight of technical debt, and they persist over the course of the years.
austincheney 8y ago
You can also rephrase that as a business concern. Instead of how ugly the code is or how challenging it is the more important factor is how long does it take to accomplish a given change. The challenge there is if you have isolated yourself to a happy path you have no idea what the edge cases are, what the regulatory concerns are, or what prior business concerns have already been addressed. You really have no idea how long the task will take to complete or the scope of actual work. It is a big risk to leave your framework dream world and embrace reality. By living in reality I know how to account for those various concerns. I can provide a more accurate estimate of effort and still get it done 8-12x faster. You don't get better at anything by closing off reality and hiding from failure. The problem with using a bunch of unnecessary abstractions and tools is that you have to choose between two really horrid scenarios. Do you give up on speed of delivery and product quality to work within the tools in place? Or, do you account for all the business concerns and deliver quickly by creating a one-off and possibly fighting those existing tools to do it? The best way to know what to add to a project (dependencies) are those things you known you will deliberately never maintain and that require a one time configuration. For example I use a linter to check my code. It is a dependency that I never modify, I never reconfigure, I never look into its code, and I almost never update. If I were forced to peer into the code and read all about how it works and really get intimate with it I might as well just write it myself, because you will be maintaining it just the same anyways.

sbhn 8y ago

Yeah, somebody has to work super hard, to make somebody elses job super easy. Write it yourself, or maybe you cant, and blaming someone elses code is a distraction to take the attention away from yourself.

afarrell 8y ago
It is a poor carpenter who blames his tools. Why? Because a skilled carpenter has money to buy the best tools. Tools matter. Developer experience matters. Cognitive cost matters when tools are used by non-infinite brains. If you don’t believe that, then build a product with a confusing UI and try selling it. New != good though.
- noir_lord 8y ago
  It's rare that new ever equals good, even the best stuff takes time to mature into good. It starts with interesting and then moves on to good later I think.
- rangibaby 8y ago
  A skilled carpenter has the tools that are necessary for the job, their price doesn’t matter. In a couple of industries I have worked in there is a tier of expensive tools that are basically ways of extracting free money from professionals (when someone else is paying) and rich amateurs who want to feel superior to their friends
  - afarrell 8y ago
    > A skilled carpenter has the tools that are necessary for the job, their price doesn’t matter Very true. A skilled carpenter is discerning about his tools and know where it matters to spend more money.

afarrell 8y ago

Or the business owner who is frustrated that their product still lists Czechoslovakia as a country. (Yes, this is true of ADP)

afarrell 8y ago

When you walk into a restaurant, do you notice if they have an efficiently laid-out kitchen with mise-en-place, good relationships with their suppliers, or a refrigerator at the proper temperature? No. But you do notice when you food is slow to arrive, the food doesn't taste fresh, or the chicken gives you food poisoning. —— You also probably notice if they are using roof tiles as plates, but that doesn’t make them good cutting boards in the kitchen.

christophilus 8y ago
Yes. I notice those things. I notice if they have an A or B or C rating, which is a reflection of some of those. I notice if they are in business, which after 5-10 years, is a reflection of some of those. I notice if the employees seem happy or frazzled which is a reflection of some of those. The same goes for software projects. It's not always clear to me what the code quality is beneath the products I use, but the products I use for the long-haul almost certainly either A.) have reasonably high quality code or B.) are reasonably complete, because they are well maintained and don't sink beneath the weight of technical debt, and they persist over the course of the years.

austincheney 8y ago

You can also rephrase that as a business concern. Instead of how ugly the code is or how challenging it is the more important factor is how long does it take to accomplish a given change. The challenge there is if you have isolated yourself to a happy path you have no idea what the edge cases are, what the regulatory concerns are, or what prior business concerns have already been addressed. You really have no idea how long the task will take to complete or the scope of actual work. It is a big risk to leave your framework dream world and embrace reality. By living in reality I know how to account for those various concerns. I can provide a more accurate estimate of effort and still get it done 8-12x faster. You don't get better at anything by closing off reality and hiding from failure. The problem with using a bunch of unnecessary abstractions and tools is that you have to choose between two really horrid scenarios. Do you give up on speed of delivery and product quality to work within the tools in place? Or, do you account for all the business concerns and deliver quickly by creating a one-off and possibly fighting those existing tools to do it? The best way to know what to add to a project (dependencies) are those things you known you will deliberately never maintain and that require a one time configuration. For example I use a linter to check my code. It is a dependency that I never modify, I never reconfigure, I never look into its code, and I almost never update. If I were forced to peer into the code and read all about how it works and really get intimate with it I might as well just write it myself, because you will be maintaining it just the same anyways.