| I think that software engineering is related with practices. 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. |