Most active commenters

    ←back to thread

    628 points kiyanwang | 14 comments | | HN request time: 0.631s | source | bottom
    1. continuational ◴[] No.43629848[source]
    I think this "good devs don't complain" mentality risks real issues being overlooked and left unaddressed.
    replies(3): >>43629921 #>>43629958 #>>43629982 #
    2. wiseowise ◴[] No.43629921[source]
    Absolutely. I think it is incomplete: good devs never complain… they just give their 2 weeks notice and find a better place.
    replies(2): >>43629949 #>>43630002 #
    3. whstl ◴[] No.43629949[source]
    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.

    4. Manfred ◴[] No.43629958[source]
    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

    5. OvbiousError ◴[] No.43629982[source]
    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.

    replies(4): >>43630019 #>>43630092 #>>43630134 #>>43630184 #
    6. Cthulhu_ ◴[] No.43630002[source]
    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.

    replies(1): >>43630159 #
    7. zwnow ◴[] No.43630019[source]
    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.
    replies(1): >>43630148 #
    8. nindalf ◴[] No.43630092[source]
    If you can’t make a COBOL stack work it means you’re a bad developer. Don’t complain, make it work!
    replies(1): >>43634467 #
    9. olex ◴[] No.43630134[source]
    I agree. The author isn't saying that the best devs never complain about something. He's saying they never leave it at complaining and throw their hands up, but dig in until the find the underlying reason for the behavior, or a way to work around it, as long as the problem remains in their way.
    10. eptcyka ◴[] No.43630148{3}[source]
    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.
    replies(1): >>43630157 #
    11. zwnow ◴[] No.43630157{4}[source]
    Yea agree, sadly in dev communities there is a lot of gate keeping considering dev behavior on Stackoverflow for example.
    12. eptcyka ◴[] No.43630159{3}[source]
    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.
    13. bt1a ◴[] No.43630184[source]
    ... trust me..

    this time it really was a cosmic ray bitflip

    14. bigstrat2003 ◴[] No.43634467{3}[source]
    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.