None of the above is software engineering. It is all only programming in a haphazard manner.
Software Engineering (SE) is an engineering discipline concerned with a systematic, rigorous, disciplined approach to the design, development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.
In particular, software can be engineered when you apply engineering techniques. To learn such techniques, the best is to study a relevant SE Master's Degree. When you teach yourself, you may learn about programming, but I cannot imagine you learning engineering on your own.
Programmer comes and starts writing code, optimizing code, etc. (everything that matters to a programmer is code and nothing but code). Complex projects are often late, the budget is exceeded up to a few orders of magnitude, and the software does not solve requirements well. This is known as software crisis. The answer to that is the SE discipline.
SE comes and wants to understand the problem domain as the first thing. An engineering approach is applied, in particular Requirements Engineering (RE) (requirements elicitation -> requirements analysis -> requirements specification -> requirements validation).
The result of RE is typically a set of models such as contextual model, behavioral model, and business process model. From these models, SE understands the business problem and designs a software solution.
The design typically means SE translates requirement models into component-based system architecture and then engineers component design for each component individually. This results in a certain specification of component boundaries, component interfaces, and classes to compose components from.
Next step is someone who comes to these (usually auto-generated) interfaces and creates their implementation. That person may be a programmer. Finally, SE follows with software validation where everything is tested against original design and requirements.
In SE, projects typically have a project plan which allows engineers to plan, control, and monitor projects. In particular, software is engineered on time, on budget, to specification.
During the implementation phase of software, documentation is produced for every artifact and many Configuration Items (CIs) are generated. These need to be managed somehow. Usually, in SE, there is a Software Configuration Management (SCM) repository and Change Management. Another part of SE is Software Process (SP), i.e. RUP, Scrum, DSDM, Crystal, Waterfall, ...
SP must be documented and rigorously followed as in the documentation, without any exception, so that results are always reproducible. (ISO 9000). This refers to Software Quality.
Another SE topic is Software Measurement and Estimation which allows you to measure the efficiency of your SP, team performance, estimated project size (LOC - Lines of Code) i.e. COCOMO, estimated project delivery (man days), and similar.
There is still much more to SE than this short answer describes. Applying SE approaches instead of only writing code is how you practice SE.
Because SE is still an emerging field, it happens that non-engineers call themselves engineers. Unless they are applying engineering approaches, they are merely programmers.
For further reading, see Software Engineering by Ian Sommerville and www.ieee.org / www.computer.org. In these resources, SE is the engineering discipline. On Stack Overflow and in many companies, unfortunately, they borrow the term SE and use it as another name for programming.