Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Thursday May 01 2014, @01:52PM   Printer-friendly
from the relax-its-a-holiday dept.

An outrageous, insightful, and sadly accurate commentary on programming. I found this an extremely entertaining read and agree with most of it. It doesn't offer solutions, but certainly highlights a lot of the problems.

"Double you tee eff?" you say, and start hunting for the problem. You discover that one day, some idiot decided that since another idiot decided that 1/0 should equal infinity, they could just use that as a shorthand for "Infinity" when simplifying their code. Then a non-idiot rightly decided that this was idiotic, which is what the original idiot should have decided, but since he didn't, the non-idiot decided to be a dick and make this a failing error in his new compiler. Then he decided he wasn't going to tell anyone that this was an error, because he's a dick, and now all your snowflakes are urine and you can't even find the cat.

Personally, I think things will only get better (including salaries) when software development is treated like other engineering disciplines.

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by egcagrac0 on Thursday May 01 2014, @08:01PM

    by egcagrac0 (2705) on Thursday May 01 2014, @08:01PM (#38622)

    Change requests don't need to be signed off, the new implemented code does! Nobody should be unable or afraid to make changes to the code.

    You're absolutely right, of course. Go ahead and play with it, except it doesn't go live until it's been thoroughly vetted and blessed.

    ... only "playing with it" is usually not something I see the engineers do. They get informed of a specific problem, and design a specific solution to address that problem while attempting to not introduce any new problems.

    There is almost zero need for documentation inside of development. The code (and tests) is the documentation.

    That's not a particularly engineerly attitude. The engineers I see make careful notes about what changes they're making and why, and usually have a brief discussion of their design decision (and why any obvious alternates were rejected) in their notes.

    Interfacing with the laity is important; they're usually the ones who sign the checks.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by tibman on Thursday May 01 2014, @11:52PM

    by tibman (134) Subscriber Badge on Thursday May 01 2014, @11:52PM (#38693)

    The engineers I see make careful notes about what changes they're making and why
    You're completely right. One of the very nice things about writing software is version control systems. Any change you make and "commit" has the specific things you changed, a comment why (optional), and usually a relationship to the task that told you to do it (mostly for time-tracking reasons). Then usually someone will come behind you and check what you changed and have a discussion with you about it.

    Interfacing with the laity is important
    You're right, i was far too flippant. I apologize.

    "playing with it" is usually not something I see the engineers do
    Now this is a difference between my experiences and yours. In my experience, software engineers enjoy the challenge of attempting to optimize or better organize something. Sort of like the boyscout rule of "leave it better than you found it". They salivate over the thought of completely rewriting a piece that everyone hates.

    --
    SN won't survive on lurkers alone. Write comments.
    • (Score: 2) by egcagrac0 on Saturday May 03 2014, @04:57PM

      by egcagrac0 (2705) on Saturday May 03 2014, @04:57PM (#39269)

      I think one of the differences here is you're talking about software engineers, and I'm talking about hardware engineers (EE, ME, etc). If we're discussing the idea that the software guys should be treated with the same kind of respect as the "other engineers", I think it's valid to compare the different behaviour patterns.