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.
(Score: 2) by egcagrac0 on Thursday May 01 2014, @08:01PM
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.
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.
(Score: 2) by tibman on Thursday May 01 2014, @11:52PM
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
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.