4 ms·

I think this "good devs don't complain" mentality risks real issues being overlooked and left unaddressed.

wiseowise 1y ago
Absolutely. I think it is incomplete: good devs never complain… they just give their 2 weeks notice and find a better place.
- whstl 1y ago
  Especially in the current job market climate. I talk regularly to recruiter friends and there seems to be a bimodal distribution going on, with some developers finding jobs straight away vs unlucky ones staying unemployed for months on end. I recently helped a couple devs that were laid-off in 2023 and still haven’t found anything else.
- Cthulhu_ 1y ago
  Or to phrase it differently, they take ownership and responsibility of their own problems and have a problem-solving mindset. If the problem isn't solveable by them but caused / exacerbated / the solution is blocked by their job, they can find another one. Or could, in any case, after a bizarre hiring boom it seems the market has quieted right down again.
  - eptcyka 1y ago
    Exactly, instead of just assuming that a component just does that, they focus on understand fixing underlying problems. Boils my blood when people with years of experience just allow bullshit issues to stew and just blame the platform/device/user/library.
Manfred 1y ago
Are you talking about the "Never Blame the Computer" section? I don't think that addresses complaining, but rather redirecting blame to something nobody has control over instead of digging into the issue and finding the root cause
OvbiousError 1y ago
The full quote being > Most developers blame the software, other people, their dog, or the weather for flaky, seemingly “random” bugs. > The best devs don’t. > No matter how erratic or mischievous the behavior of a computer seems, there is always a logical explanation: you just haven’t found it yet! I don't see how you can conclude from that that real issues would be overlooked? I interpret this to be the opposite.
- zwnow 1y ago
  Idk lots of popular languages/tools simply suck, addressing issues is interpreted as crying about it by more experienced devs. Experienced that a lot in my career so far. So I think the original comment is fair.
  - eptcyka 1y ago
    If an experienced developer looks at someone who tries to address suckage of a tool/language sucking and then characterises the behaviour as crying about it, it is the experienced dev that also takes part in the suckage.
    - zwnow 1y ago
      Yea agree, sadly in dev communities there is a lot of gate keeping considering dev behavior on Stackoverflow for example.
- nindalf 1y ago
  If you can’t make a COBOL stack work it means you’re a bad developer. Don’t complain, make it work!
  - bigstrat2003 1y ago
    This is unironically true. There's nothing wrong with wanting to use different tools which are better suited for the task. There's nothing wrong with trying to convince people "this tool isn't right for the job, let's switch". But after all that, if the decision is to stick with COBOL (whatever the reason may be) - a good professional does the best they can with it. If you can't suck it up and write stuff in COBOL, you aren't a very good developer.

Absolutely. I think it is incomplete: good devs never complain… they just give their 2 weeks notice and find a better place.

whstl 1y ago
Especially in the current job market climate. I talk regularly to recruiter friends and there seems to be a bimodal distribution going on, with some developers finding jobs straight away vs unlucky ones staying unemployed for months on end. I recently helped a couple devs that were laid-off in 2023 and still haven’t found anything else.
Cthulhu_ 1y ago
Or to phrase it differently, they take ownership and responsibility of their own problems and have a problem-solving mindset. If the problem isn't solveable by them but caused / exacerbated / the solution is blocked by their job, they can find another one. Or could, in any case, after a bizarre hiring boom it seems the market has quieted right down again.
- eptcyka 1y ago
  Exactly, instead of just assuming that a component just does that, they focus on understand fixing underlying problems. Boils my blood when people with years of experience just allow bullshit issues to stew and just blame the platform/device/user/library.

Manfred 1y ago

Are you talking about the "Never Blame the Computer" section? I don't think that addresses complaining, but rather redirecting blame to something nobody has control over instead of digging into the issue and finding the root cause

OvbiousError 1y ago

The full quote being > Most developers blame the software, other people, their dog, or the weather for flaky, seemingly “random” bugs. > The best devs don’t. > No matter how erratic or mischievous the behavior of a computer seems, there is always a logical explanation: you just haven’t found it yet! I don't see how you can conclude from that that real issues would be overlooked? I interpret this to be the opposite.

zwnow 1y ago
Idk lots of popular languages/tools simply suck, addressing issues is interpreted as crying about it by more experienced devs. Experienced that a lot in my career so far. So I think the original comment is fair.
- eptcyka 1y ago
  If an experienced developer looks at someone who tries to address suckage of a tool/language sucking and then characterises the behaviour as crying about it, it is the experienced dev that also takes part in the suckage.
  - zwnow 1y ago
    Yea agree, sadly in dev communities there is a lot of gate keeping considering dev behavior on Stackoverflow for example.
nindalf 1y ago
If you can’t make a COBOL stack work it means you’re a bad developer. Don’t complain, make it work!
- bigstrat2003 1y ago
  This is unironically true. There's nothing wrong with wanting to use different tools which are better suited for the task. There's nothing wrong with trying to convince people "this tool isn't right for the job, let's switch". But after all that, if the decision is to stick with COBOL (whatever the reason may be) - a good professional does the best they can with it. If you can't suck it up and write stuff in COBOL, you aren't a very good developer.