Are you a Developer, or a Software Engineer?
Job titles can be a contentious point. To some, they matter a great deal, and to others, they don't matter at all. Things get extra interesting when you start throwing around the word "Engineer" though. What does it mean to be an Engineer? What does it mean to be an Engineer of Software? What is Software? Does it include websites?
There are a lot of people who don't consider web development to be true software development. There are even more who consider neither of these things to be Engineering, but that is not the case.
The following excerpt comes from Engineers Australia
Software Engineering is about creating high-quality software in a systematic, controlled, and efficient manner. It is an approach to designing software to maximise quality and reliability by treating it as a formal engineering process.
In other words, Software Engineering means approaching software design and development with engineering processes. Taking this approach helps the Engineer to ensure higher quality and reliability.
As with everything, there are varying degrees of skill and care with which you can approach the art of Software Development. It is possible to build a system without applying any quality gates, without doing proper design, and without having proper processes in place. If you're lucky, maybe some of the systems will even work when you're done. "Maybe" isn't good enough for businesses, though. "Maybe" has no place in enterprise software or any software at scale.
If you are a professional developer, you have a responsibility to your employers and your clients to deliver robust, quality software. That kind of software is made by applying engineering practices.
Ensure that you and your team are writing clean code. The code should be simple to understand by reading it for the most part. It should be well-documented enough that the more complex parts are still understandable. Your code should be well tested, and your tests should run in CI on every commit. Systems should be planned out and documented well before any code is even written. Plans and designs are easier and cheaper to change than code.
Use the planning phase to identify design flaws, and improve where you can. Coworkers should review your plans and designs the same as they do with your code.
Your team needs to communicate well, and often. Nobody expects one person to have all the answers. If you are unsure of how to solve a problem or approach a situation, don't be afraid to ask for help. Two heads are better than one, and effective communication and teamwork lead to well-engineered systems.
At the end of the day, it's not what you make, or what language you use that determines whether you are a Software Engineer. What matters is how you solve the problems you are presented with, and how you deliver value to your stakeholders.