Now that I've been in the "real world" for some time, many of my youthful assumptions and expectations have been shattered - many of which related to my chosen profession.

The past few years I've really been mulling over "what is it that I do". For example, on a good day I delete more lines of code then I write - so clearly my job is not to write code, and it certainly isn't to delete it either. This article is very well written, and I very much agree with most of it. I'd also recommend this one. http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...

Reading the article, and seeing where the author is coming from, and I honestly don't see it in the way that he describes.

An engineer (one in the classic sense), and a software engineer (someone who engineers code and bits to create software) can both be explained as "I find solutions to otherwise complicated issues others cannot while encompassing outside and unforeseen circumstances". Now, that phrase there can be applied to a thousand other careers and jobs.

But I think we use the term software engineer because we haven't quite come up with a "perfect" term to describe what is being done when code is being written.

Writing software is not easy for all people. Just like writing a paper is not. Understanding logic, flows, and cross-compatibility takes experience, time and understanding.

That said, I don't think the term software engineer is completely incorrect, but I also don't believe it is the best one to use either. I see it as we will either find a better term for what we mean when we say 'software engineer', or just end up using that generic term because it is understandable enough to describe an umbrella definition.

From Wikipedia -

> The American Engineers' Council for Professional Development (ECPD, the predecessor of ABET)[1] has defined "engineering" as:

>The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation or safety to life and property.

If your programming really hasn't involved any of this, perhaps "programming" isn't the right word for what you've been doing?

so what about the building process in other disciplines--for instance, a multi-story urban office building? From start to finish, this sort of project involves (among others) architects, civil engineers, and carpenters. The task in front of a programmer, at any given time, might look more like architecture (eg, proto-typing), or building a simple rig to performance test pub-sub technology candidates to see which can satisfy the system's throughput requirements. Other times, i'm the plumber or the carpenter.

what's more, i don't think those functions map to types of developers (ie, architects => systems programmer; carpenters => front end dev) rather at any given time, a systems programmer could be "architecting" engineering, or plumbing; likewise for a front end dev.

(here, i have expressed in my own words, an essay i read maybe five years ago, perhaps by Paul Graham).