软件工程师能算工程师吗？

看到这个标题的时候挺激动的

但是读完了之后挺失望的。In other other words, something becomes engineering if enough engineers say it's engineering. 所以三篇文章，采访了很多人，这些人都说软件工程师，所以算工程师了。

能从其他工程行业学习什么呢？Crossovers wanted more time to think about things before they did things. 意思就是动笔之前多花点时间。问题是花时间干啥呢，真要预先设计吗？

而 hackernews 的评论区，我觉得更精彩一些

Crossover guy here. I worked as a ChemE for 11 years, then as a software developer for 20. Regardless of terminology, the two fields are very different. If I have to design a process to separate two liquids, I have a few options available, and all are highly constrained by physics and a lot of math and equipment design has gone into optimizing them. But when writing code to solve a problem, the number of possible ways to accomplish it are endless, and other than big-O notation there's not a lot of constraints put on the solution.
I lived through the "design patterns" trend, which seemed like an attempt to create a software equivalent to the "unit operations" we ChemE students all learned, but it was basically a flop because in the end you can use almost any design pattern to solve a given problem.
I don't much care whether you call it "engineering" - but the gap between the smokestack industries and software remains.

软件开发的 option 更多，而且没有效用函数来评估每种 option，甚至连要优化什么指标都不清楚。

I'm a mechanical engineer. Not every software developer is an engineer in my book, but many if not most are.
Engineering is a method of problem solving: accomplishing goals within a specified framework by using your understanding of the situation to identify constraints and predictably satisfy requirements.
To translate that into something more clear: if you can quantify what you're doing, and within some range you know you'll succeed and outside that range you will fail, you are doing engineering. If you're regularly doing engineering, you're an engineer.
If you regularly find yourself saying "we need a server response time of less than x" or "we only have y amount of memory to work with" or "this layout reduces churn by z%", you're doing engineering. Even if the numbers are only implicit (for example saying it has to run on a phone is just a standing for it has to meet the quantitative requirements to run on a phone) it still counts.
There are plenty of software developers who are more artisans than engineers - they don't think in terms of satisfying requirements and what is "good enough" but rather in qualitative terms. Perhaps they are more interested in how their software is made than what it actually accomplishes, or perhaps they aren't really trying to accomplish anything specific and are more just hacking for its own sake. If nothing else, plenty of software developers simply don't question why they are doing something in a given way, deferring to past experience or taste over understanding. Note that in many situations, the artisanal approach is perfectly valid, though in cases where predictable and optimized solutions are really necessary, an engineering approach is really warranted.

这位老兄的评论更直白一些，就是 Engineering 需要量化指标，而工程师的目标就是把控这个指标在合理的范围内。

从错误率，响应延迟，吞吐量等指标的角度。毫无疑问，软件开发是真正的工程。我们需要考察各种 option，从容错，延迟，吞吐这些指标的角度衡量各种 option 的好坏。

然而 Software Engineering 这个词更多的是和软件开发过程，面向对象设计这些无法量化的玄学关联在一起的。很难说目前 Software Engineering 名词下概括的这些东西是真正的工程。