4 ms·

I am trying to work out if you are being ironic in your reply or not. I am a software engineer. My job is to solve problems, not to "write code". It just happe

by collyw 5y ago

I am trying to work out if you are being ironic in your reply or not. I am a software engineer. My job is to solve problems, not to "write code". It just happens that most of the solutions will involve code. The less code that can be written to solve a problem the better. More code is a liability not an asset.

dvfjsdhgfv 5y ago
> More code is a liability not an asset. Unfortunately not all managers agree on that point,
- anfilt 5y ago
  Generally, that less code means relying on someone else's code which depending on the circumstance could be a bigger liability.
  - collyw 5y ago
    Using well tested libraries is likely more reliable than something I have written myself. Though in my personal experience Python (or Perl) libraries seem to be far higher quality than JavaScript libraries.
    - gorjusborg 5y ago
      I used to feel this way, strongly. Now I think about whether the downsides of relying on third party dependencies are outweighed by the upsides. Supply chain attacks are real. Project maintenance suffers for many projects in the long term. If you can write a left-pad function, just write left-pad. If you are implementing a 200 page open spec for a system that needs to interoperate with 100s of other systems, consider looking for a community effort to rely on and contribute to.
      - collyw 5y ago
        Yes, I am pretty much in agreement with you there. It's a balance, and as you say smaller things may well be better without a library, but larger things maybe not. And there are going to be exceptions to this rule of thumb.
blowski 5y ago
I'd say @Cthulhu_ is giving the real reason we'd tell our friends in the pub, rather than the bullshit justifications we give our managers.
- Frost1x 5y ago
  Definitely not a BS reason, at least for me. The less code I write, the less I have to work (in general). If I can reduce total effort, accomplish the goals for those who pay me, and still pull in good income, I'm happy. If I get bored because I've been so efficient at making the people who pay me happy that I have bored free time, I'll use all that slack time I've buffered up to try something different or new without time pressures, otherwise, maybe I'll just go to the gym or for a walk. I like programming, but I don't want me entire life to be nothing but programming. I don't know how some code 60+ hours a week every week. I did that when I was a kid and was mesmerized by the computing industry and wanted to know how things worked--I'm no longer mesmerized. The mysticism is gone and for me, it's just about solving interesting problems using computers that improve people's lives. The less code I have to write to survive, the more choice of direction I have in any additional desires to code. If you're doing theoretical CS work then by all means, pursue the mysticism, but that typically isn't in code, that's in developing foundational theory. I don't want interesting problems in my code if it can be avoided, I want my code to help with interesting problems in the real world. Interesting problems in my code means I have complexity to deal with and makes my software more prone to issues, difficulty maintaining, difficulty adapting. The simpler the solution where feasible, the better. Some roles don't give you this sort of flexibility to make sure you're not bored and in those roles, that's where you see these elaborate overly complicated systems where people tuck things into the deliverables when they're unneeded. To me, that's a management and/or structural problem. I don't think my desires are all too different than most peoples desires, no matter what people in professional environments say to make sure they still get paid and are professionally progressing.

by collyw 5y ago

dvfjsdhgfv 5y ago

> More code is a liability not an asset. Unfortunately not all managers agree on that point,

anfilt 5y ago
Generally, that less code means relying on someone else's code which depending on the circumstance could be a bigger liability.
- collyw 5y ago
  Using well tested libraries is likely more reliable than something I have written myself. Though in my personal experience Python (or Perl) libraries seem to be far higher quality than JavaScript libraries.
  - gorjusborg 5y ago
    I used to feel this way, strongly. Now I think about whether the downsides of relying on third party dependencies are outweighed by the upsides. Supply chain attacks are real. Project maintenance suffers for many projects in the long term. If you can write a left-pad function, just write left-pad. If you are implementing a 200 page open spec for a system that needs to interoperate with 100s of other systems, consider looking for a community effort to rely on and contribute to.
    - collyw 5y ago
      Yes, I am pretty much in agreement with you there. It's a balance, and as you say smaller things may well be better without a library, but larger things maybe not. And there are going to be exceptions to this rule of thumb.

blowski 5y ago

I'd say @Cthulhu_ is giving the real reason we'd tell our friends in the pub, rather than the bullshit justifications we give our managers.

Frost1x 5y ago
Definitely not a BS reason, at least for me. The less code I write, the less I have to work (in general). If I can reduce total effort, accomplish the goals for those who pay me, and still pull in good income, I'm happy. If I get bored because I've been so efficient at making the people who pay me happy that I have bored free time, I'll use all that slack time I've buffered up to try something different or new without time pressures, otherwise, maybe I'll just go to the gym or for a walk. I like programming, but I don't want me entire life to be nothing but programming. I don't know how some code 60+ hours a week every week. I did that when I was a kid and was mesmerized by the computing industry and wanted to know how things worked--I'm no longer mesmerized. The mysticism is gone and for me, it's just about solving interesting problems using computers that improve people's lives. The less code I have to write to survive, the more choice of direction I have in any additional desires to code. If you're doing theoretical CS work then by all means, pursue the mysticism, but that typically isn't in code, that's in developing foundational theory. I don't want interesting problems in my code if it can be avoided, I want my code to help with interesting problems in the real world. Interesting problems in my code means I have complexity to deal with and makes my software more prone to issues, difficulty maintaining, difficulty adapting. The simpler the solution where feasible, the better. Some roles don't give you this sort of flexibility to make sure you're not bored and in those roles, that's where you see these elaborate overly complicated systems where people tuck things into the deliverables when they're unneeded. To me, that's a management and/or structural problem. I don't think my desires are all too different than most peoples desires, no matter what people in professional environments say to make sure they still get paid and are professionally progressing.