What Is A Web Engineer? | A Detailed Explanation
Personally, I would consider the "engineer" in "web engineer" to mean they understand the more technical parts of building websites.
For example, a web engineer would understand how to make a web application whereas a web designer would only be able to make a static website. Briefly, a web application, is a website that allows the user to interact with it a lot more than a static website does. Some examples of this would be Twitter, Facebook, Quickbooks, TurbTax and many others. All of these websites allow the user to do more than view static content.
But, we went a little off topic.
At many workplaces, Google being a good example, software developers are all called engineers. Web developers are called web engineers, mobile developers are called mobile engineers, and game developers are called game engineers.
To many, engineer is just a job title and doesn't actually mean your job is any different than a developers.
So basically, when I hear someone say engineer instead of developer I assume they have a little more experience in that field, but that's not the full story.
But, we can take the definition further. If a mechanical engineer can predict how their product will behave then we should hold a web engineer to the same standard.
Therefore, a web engineer is someone that has a greater ability to predict the way software will behave.
So that means a web engineer can be a web developer, but a web developer may not necessarily be a web engineer.
That's because a web engineer is someone with a higher level of skill and therefore predictive power. Similar to the difference between a mechanic and a mechanical engineer a web developer can use the tools that the web engineer built.
A web engineer should be proficient in pattern design, automated testing, and fault-tolerant systems.
Below is how the University of Waterloo describes their Computer Science and Software Engineering degrees. This is useful because it's an actual authority using the term software engineering and they give a good description of what it is.
- Computer Science (CS) focuses on understanding, designing, and developing programs and computers. At its core, Computer Science concentrates on data, data transformation, and algorithms. Advanced courses present specialized programming techniques and specific application domains. The CS program is less structured than the CE and SE programs, giving students more flexibility to build depth or breadth in a variety of application domains or in the fundamentals of Computer Science.
- Software Engineering (SE) deals with building and maintaining software systems. It is more software-oriented and has a greater emphasis on large software applications than Computer Engineering. It is more applied than Computer Science, placing greater emphasis on the entire software development process, from idea to final product. It is also more disciplined than Computer Science, applying more systematic practices to help ensure that products are reliable and safe.
So a software engineer is someone that focuses less on the abstract and more on the practical. They're engineers and as such they should be able to build software through less trial and error and more predictably.
In the video the professors shows the a Calvin and Hobbes comic strip to illustrate his point.
It's a funny comic and makes a good point that software developers do typically do a lot of trial and error.
And, for a moment I completely bought the argument that developers cant predict software, until I read another users comment which said,
If anything his argument with the predictive is completely off and shows he hasn't worked with engineers and kind of assumes that he knows what they do (but being in academia, he probably doesn't know much). He uses that bridge cartoon as saying since civil engineers don't test bridges by adding more weight until it breaks, that they are predictive. The issue is, guess what, they do. Not with the bridge as a whole, but say we're working on a suspension bridge. Those cables are tested by taking a sample and adding tension until they snap. Do that enough and you have an accurate predictor of their strength and therefore you can measure their impact on the bridge as a whole. Aka, they take a unit, test it, and then use the results to see the total effect on the system. It's no different than software engineering. Engineering is a process. A process of using tools, measurements, tests, and math to build something.
My ex is a mech eng. She's working on a new forging process. The calculations didn't match up with the results the first time. So she took that, altered the simulation and repeated until theory matched reality.
Also, the 99% security vulnerability thing is a lot different. Mechanical engineers build jets, but those are still vulnerable to bullets. 110 years ago, engineers couldn't build skyscrapers in Chicago because the soil was too soft. Buildings aren't fireproof and most aren't even earthquake proof. The fact is, everything engineers build is vulnerable to something. The difference is those disciplines don't have people actively trying to find every weakness. Storms aren't trying to figure out the perfect place to hit a house with lightning to burn it down, but that's the challenge developers face. The fact is, we probably make things more bullet proof then most other engineers because they have a minimum level they have to surpass to be ok. Developers have to think ahead to what could exist in the future to bypass anything.
Putting aside the snarky nature of the comment, he has a good point. The typical product development lifestyle for an engineer involves many, many prototypes.
Murray Leardon a VP of a product development company is roughly quoted saying, "The light bulb took countless prototypes and you think you can build this in one go?" This was a remark when asked how he handles clients that think they can get a lot more done in a single prototype.
The next comment goes something along the lines of "that was a beautiful analogy" and I completely agree.
And the fact that software engineers can't predict every security vulnerability is just the same as an engineer not being able to think of every way his prototype could go wrong until he builds it.
Only through experience can they understand some of the pitfalls, and even then there will always be new things to be aware of.
You can have a web developer that goes through far more trial and error and just stumbles his way toward the solution without understanding the underlying architecture.
But, with time and a solid understanding of the fundamentals a mechanic could become a mechanical engineer just like a web developer could become a web engineer.
It's all about their level of skill.
It further enforces the need for the term web engineer. I think it's a completely valid term used in the right context.
But, the software industry is still pretty young and the language around it will continue to evolve. Considering that the education industry is inclined to distinguish a Computer Science degree from a Software Engineering degree I think we're already heading in that direction.
In the future it will also be likely that more companies require certification to work there. Many software development companies require a CS degree for the job position and I expect that number to increase over the years. Especially in companies that need to be more risk averse.
An interesting point, however, is that many electrical engineers actually don't need an engineering degree to practice electrical engineering.
This is likely because if a computer circuit malfunctions it can be easily tested for and won't cause a huge loss of life. If a civil engineer doesn't do their job correctly then people will die.
So, maybe a license wont become more of a hard requirement for software engineering. Only time will tell.
The last distinction that I think is important is the difference between frontend and backend web development.
I think calling yourself a frontend developer doesn't typically do enough to communicated what you actually do, but if you tell me you're a frontend engineer then I immediately think, "Oh, this guy builds web applications and not just static websites."
When you say you're a backend developer the distinction between a backend developer and backend engineer doesn't do as much because either way I know that you're going to be building out APIs. However, all the points I made above I think still hold for this case.
Anyway... enough rambling
Let me know what you think in the comments 😊