I hate the term "coder".
It's like calling a designer a "drawer".
It's like calling a designer a "drawer".
I wrote a comment a while back attempting to capture and explain my thoughts on the greater responsibilities and competencies of a software engineer [1]. The effective engineer has a holistic approach to software and business:
> Engineering in the software field isn't /always/ about building super-reliable things. That is one factor that I think differentiates it from other engineering fields. Engineering in the real, physical space has safety implications that typically require a high level of rigor at minimum. If a bridge fails or a building collapses, that's catastrophic. Physical products are only useful if engineered to a high level of quality. However, software is useful across a wider spectrum of reliability: if a back-office web app used by the recruiting team has to come down for maintenance for 2 hours on Sunday, that may not be a showstopper.
> Consequently, part of software engineering is understanding what level of robustness is needed to meet business goals, and building to it appropriately, with appropriate costs, and understanding the properties of the built system. Controlling the [tradeoffs] is what makes it engineering.
[1] https://news.ycombinator.com/item?id=5809358
Furthermore, the effective software engineer, who in a corporate environment is also an effective businessperson, understands and influences the strategy of the business, and breaks down that strategy into goals which then influence the design and implementation of software. (Regarding earlier threads about whether programming is a dead-end job:) A wider perspective on what constitutes software development, and its role in business in general, also yields better long-term career development opportunities than focusing on being solely a "programmer".
Are really all other engineers doing work as delicate and safety-critical as brain surgery? I'd imagine (not that I know, really) that a lot of risk-averseness in more concrete engineering fields simply has to do with the bottom line: if a design has already been put into production, what if there is a fault in that design and subsequently all the final products of that batch? With software, you can just nag the end users to update.
There isn't any substantial difference between some types of software engineering and other engineering disciplines. The HDTV antenna I unboxed this morning was a travesty of "engineering" and is the electrical engineering equivalent of a crappy todo app. OTOH, my day job developing software is as rigorous as the physical engineering I've been involved in (my undergraduate degree is in Electrical Engineering and I worked in that field for about a decade).
The "problem" is that most software doesn't need to be engineered any more than the average garden fence does, so there is a lot of drawing of false parallels.
And as far as nagging users to update, that can be a little difficult if your software is embedded in the controls of a diesel engine somewhere in the South China Sea.
Of course, going to school for an EECS degree also should instill such values, including engineering ethics and codes of conduct.
Yes. There are, of course, exceptions.
In my non-screen tiem I try to make beautiful things out of wood. The "correct" term in that community for what I strive to be is "cabinetmaker". I am not offended when people call me a carpenter. Their understanding of "carpenter" is a bridge from their mindspace to mind.