The irony at the heart of software engineering | Hacker News Reader

The irony at the heart of software engineering

tednesday.wordpress.com

That was a great chuckle

Methinks the author doesn't know what they're talking about

What specifically?

... all of it

As a software engineer I can say that in my 20 years of experience none of this is true. Like any technical discipline, different engineers have different approaches and experience. But this obviously false dichotomy of two camps and unsupported analogy with film critics strikes me as the writings of someone who has never actually worked in the field.

>the writings of someone who has never actually worked in the field.

I think it may be worse than that - I've had the fortune ('mis' or 'good') to listen to folks whose only experience with something was academic ... but at least they could parrot the Academia-Designed Best Practice™ when asked about something

This ... was totally different

> the writings of someone who has never actually worked in the field

Hmmm... Does it seem like they have never actually worked in the field due to the dominance of Camp 2? (Camp 1 people, IMX, excuse their lack of practical experience by publishing things along the lines of "doctors are not required to suffer from the diseases which they treat")

I have lots of experience.

The film critics analogy is not supported indeed, but I consider the rest of the article as brilliant. It reminds me Steve Jobs' interview about building team of A players instead of Bs and Cs. If some manager is OK about hiring Bs and Cs they will persuade the manager that what they did is the best possible way of solving the problem. In my opinion, existence of Bs and Cs in the team eventually causes an idiocracy crisis because typical A does not want to work with not A because of boredow and typical not A does not want to work with As because of hard to show off. Just look at your quotes:

> As a software engineer I can say that in my 20 years of experience none of this is true.

> this obviously false dichotomy of two camps

> the writings of someone who has never actually worked in the field

You are talking neither about needness of the work nor about to falsificate yourself's work nor about to falsificate at least your opinion. You are talking about your-opinion-is-always-true attitude. I don't know what you have defeloped per your 20 years of experience but you are talking exactly like the representative of the 2nd camp who does not consider the work as the most important thing ever. I don't know anything about you but I do not want to work with any person who considers his years as important point - because no C engineer (also scientist, music composer, mathematician) with N years of commercial experience will become at least B just by the matter of years.

The irony at the heart of this essay is that it doesn’t give any examples. It doesn’t make it possible to make any solid criticisms. I wonder whether the author is really seeking the truth, or whether they are just an example of the twisted faith they complain about.

For example:

> However, reality is much more sombre. The language explosion is more cancerous in nature. Each new language is a malformed confirmation of someones belief system.

Which languages? Name them, and state how they’re “a malformed confirmation of someones belief system”.

Modern C++ is one such example. It has a track record of adopting paradigms that are then rejected by consensus (strong OO). It adopts modern practices because other people like them. Not because it has practical evidence that they are worthwhile.

> I suppose the picture of computing is of a topsy-turvy growth obeying laws of a commercial "natural" selection. This could be entirely accurate considering how fast it has grown. Things started out in a scholarly vein, but the rush of commerce hasn't allowed much time to think where we're going. — JET

That statement is 60 years old and its truth continues to outlive its utterer: https://en.wikipedia.org/wiki/James_E._Thornton

I suspect that once the day comes when the hardware folk are no longer regularly giving us software folk a free lunch, there will be a rediscovery of the importance of "knowing what one is doing". But I fear, not before.

I can’t comment on C++ — haven’t used it in like a decade, hope never to work with it again.

Camp 3. Software engineers who want to implement a business requirement, do so in a way which is cost effective, will not be embarrassing to them and is easy to maintain, and have a life.

> cost effective

> easy to maintain

If the engineer can really fullfill both the requirements - he is in the first camp.

Read this article expecting validation of my own staffing dichotomy (oh no I may be camp 2) designated tigers and wolves. I can see evidence of the author’s claims in my own professional experience, but it has proven entertaining to see the evidence in this thread.

I think the article perhaps suffers from the issue of all personality taxonomies in that it attributes behaviors to traits which could have their genesis elsewhere. The discussion of testing really got me on this, as the defensive covering of every function with unit tests could just as easily come from a place of having been burned and wanting to catch regressions early - wanting to be proven wrong early - as desiring a logician’s rigorously pure programming experience.

Reply on news.ycombinator.com