3 ms·
I don't see this answer, so here's my 2c. I think there is a small distinction in the act of engineering vs. developing, but we all cross that line without not
by hakunin 5y ago
I don't see this answer, so here's my 2c.
I think there is a small distinction in the act of engineering vs. developing, but we all cross that line without noticing. Software engineering is the process of finding the most efficient solution within your constraints by leaning on algorithm/datastruct fundamentals. For example, you don't look at a tool's marketing page, you look at what it's built upon, how it operates, and based on these fundamentals you understand how performance, reliability, and cost will scale. If the fundamentals are too complex, you might have to do some measuring. If you evaluate or build new tools on this basis, you engage in some software engineering. I don't think this has to be some sort of superior gate-kept thing. It's just a kind of work.
We could make a stretch and claim that there's also "fundamental analysis of maintainability", but I firmly believe[1] that maintainability is subjective. We don't call writers "story engineers", and I wouldn't call any immeasurable and subjective work "engineering".
Edit with additional thought: I think there is a perception downside to both: developer and engineer. The "developer" downside is that you're more likely to be perceived as someone who doesn't care about fundamental analysis, and you focus on getting things to work only in the conditions you're familiar with (i.e. on my machine). The "engineer" downside is that you're more likely to be perceived as someone so fixated on the measurable, that you completely ignore the taste and maintainability aspect (falling into the McNamara fallacy). If you can't measure it, it's not worthy of your time.
There are just perceptions, not reality. Naming is hard.
[1]: https://max.engineer/maintainable-code https://max.engineer/maintainable-code