|
|
|
|
|
by ntrepid8
3877 days ago
|
|
Engineering is usually considered to be concerned with the application of science and math to build systems and solve problems. On a continuum with pure math on one end and applied physics on the other, most things that we think of as engineering fall more toward the applied physics end. Computer science is much closer to pure math than chemical engineering for example. That said, I think computer engineering is a real thing and just because SV uses engineer as an aspirational title doesn't mean that writing code has nothing in common with engineering. Software manages all kinds of critical systems from automobiles like the author mentioned, to auto-pilot in airliners, and control systems in power plants. Maybe one day we'll have a recognized PE designation for pure software engineers too. |
|
If you are capable (and understand):
+use a build and deployment system,
+use a testing suit/framework whatever,
+a bug-tracking system, a source control,
+good practices of programming (programming styles, pertinent programming patters, etc),
+capable of do good estimations (cost/time/human resources) to tackle a problem,
+you are capable of understand the pros and cons of software architectures (i.e. client-server, distributed, pipelines, multilayered system, etc),
+do metrics and estimations of progress (not only bugs found/corrected but also milestones met)
+and develop a roadmap (for example understand what tasks are blocking, what goals are reachable, what are secondary or skip-able, and what is shippable).
Then you are pretty much a software engineer.
Now this is not structural or civil engineering, and are not comparable. For example given favourable conditions (good foundations, no mayor disasters or other problems) a civil engineer is almost guaranteed to come up with a viable bridge design. But for software the design are not only the sketches, or diagrams, is the code itself, and even with favourable conditions (money, people, time) your software might fail.
Now for me a CS they are more good to do models. They are good to reduce a problem in models that are more close to logic and mathematics and therefore are more apt to be tested and proven. Yet that doesn't mean they could solve a software problem either. They could prove the model, but that doesn't mean that the model is realistic or that the best answer to a specific problem.