2 ms·

> We need to be focused on solving problems, and if we aren't sure what problem our code is solving, we need to stop coding and figure that out. I am not sure

> We need to be focused on solving problems, and if we aren't sure what problem our code is solving, we need to stop coding and figure that out. I am not sure whether this is a good advice - for a quite subtle reason: I do claim that most code (including most of the code that is written "for code's sake") does solve a problem, and most programmers at least unconsciously are aware of this fact - and that's why they write this "code for code's sake". The issue rather is that other people (say, "the suits") want that the code solves a different problem than the one that the code solves.

hef19898 3y ago
Assuming tue devs don't live in a vaccum, it is other people eho define the problems to be solved. Doing so consiously, and not unconsiously by chance, is what engineering does. Producing something to produce something, while ignoring the problems you where handed to solve (doesn't matter if it is clients, customers, regulators or management), is pointless. The tricky bit is figuring what the real problem to be solved is, I agree. Ignoring that question and doing whatever comes to ones mind first doesn't really work so.
- aleph_minus_one 3y ago
  > Producing something to produce something A central argument of me is that this situation "produce something to produce something" rarely happens - this is in my opinion rather evil propaganda from people who hate programmers and their way of thinking. Such code nearly always solves a problem - often one that the managers don't understand. Just to be clear: it does happen that the code solves a problem in a bad way - this is where in my opinion the trope of "code for code's sake" comes from.
  - qayxc 3y ago
    > this is where in my opinion the trope of "code for code's sake" comes from. Some companies still use metrics like LoC to assess employee productivity. In such cases it might become a necessity to write code that's just there in order to look good on the next quarterly evaluation sheet.

hef19898 3y ago

Assuming tue devs don't live in a vaccum, it is other people eho define the problems to be solved. Doing so consiously, and not unconsiously by chance, is what engineering does. Producing something to produce something, while ignoring the problems you where handed to solve (doesn't matter if it is clients, customers, regulators or management), is pointless. The tricky bit is figuring what the real problem to be solved is, I agree. Ignoring that question and doing whatever comes to ones mind first doesn't really work so.

aleph_minus_one 3y ago
> Producing something to produce something A central argument of me is that this situation "produce something to produce something" rarely happens - this is in my opinion rather evil propaganda from people who hate programmers and their way of thinking. Such code nearly always solves a problem - often one that the managers don't understand. Just to be clear: it does happen that the code solves a problem in a bad way - this is where in my opinion the trope of "code for code's sake" comes from.
- qayxc 3y ago
  > this is where in my opinion the trope of "code for code's sake" comes from. Some companies still use metrics like LoC to assess employee productivity. In such cases it might become a necessity to write code that's just there in order to look good on the next quarterly evaluation sheet.