I am a programmer

I am an information Manipulator.

The problem I have with "software engineering" is that it's not real engineering. Sure you might do thinking to create proper requirements, design, build a prototype, build the real thing and iterate, use agile or whatever.

But comparing programming to actual, real-world engineering is a different kettle of fish. Engineers make things with actual physical requirements - if they're not met, people will die. You're not going to be doing proper engineering unless you can sue the engineers for the wholes in their software that caused people to lose money from their bank. Sure it works and may well solve a problem, but it's not engineered.

Real software engineering is using formal methods to do your utmost to prove that your stuff actually will work (Intel does that for some of their chip development) or make 5 different control systems for your rocket and have them vote on the correct course to add extra backup to prevent fuckups (NASA did this for the Apollo iirc - the EU Ariane didn't, so they had a rocket crash at one point).

Until that happens, you're just going to be developing sandcastles - you're going to have buggy software that will break at some point - because software development is so fast that it's not worth the effort to engineer from the get-go.

In other words, coding is coding - you can have good coding that uses best practices - but if you call it engineering you're deluding yourself in most cases.

The title makes it sound as if the author is in complete disagreement with Patrick's essay (and perhaps he feels that he is) but it's not how I see it.

Both articles are about the way you present yourself, not really about the "programmer" label. Sure, your label is part of what do for a living, but the important point brought up by both articles is that you have to recognize what your value is in the workplace and use that as your selling point in order to achieve job satisfaction and/or recognition (that's the way I understood them anyway).

I was thinking more of the web stuff that people do, so may be overstating my case. There are cases where you really need to make things safe - NASA's Apollo rockets and medical equipment to name a few. Also, when I talk about suing engineers I meant suing a big company such as Microsoft for the glaring security problems in earlier versions of Windows. Some Windows machines would be hacked within minutes of connecting them to the internet - in my mind that's simply negligence on the part of the developers - them being liable for creating an insecure product would force them to develop a properly secure solution - in other words to actually engineer it properly.

Where you have a hardware-centric approach, I'd assume that the whole system, software included has been pretty well tested and engineered to a great deal.

But banking software and I postulate most software that hacker news contributors write is probably going to be inherently flaky in some respect. The main fault for this is that writing software is so quick and easy compared to creating something physical that will last.

It's due to the push to get something to market and the "easy" nature of software development that leaves true engineering discipline by the wayside.

Yes, you can be in a situation (especially when people's lives depend on it directly such as medical equipment) when you are properly engineering a solution, but I still stand by my premise that most software development is not software engineering - you're just making sandcastles.

-- ...but the fact of the matter is that I'm a programmer. It's what I do best and it is the job title that I associate with most

and then

-- What you call yourself or what other people call you is utterly irrelevant.

I am utterly confused and no better at my job.