Most people, over the history of program writing, have approach software development without going anywhere near what is mentioned on this page. At least explicitly. The matters discussed here are not required, but they can enhance your abilities in writing code. The short version is, computer science is not the same thing as software writing, IT, or help desk and you can do those things without a computer science perspective and background.
Data Structures, Algorithms, and Mathematical Analysis
A few ways exist to get exposure to the concepts of data structures, algorithms, and mathematical analysis. University programs is one route. However, there are many people who are professionals in a subject not related to computers but who write code. The code could be spreadsheet macros such as the case in many industries and situations. Long-term, traditional study opportunities to specialize in these concepts are often at odds with other obligations. Books and websites exist to progressively expand knowledge of these matters on a more flexible schedule.
An idea behind data structures, algorithms, and mathematical analysis is to create solutions that have wider applicability. That can require a higher investment of time with the result being the assumption of better capabilities in more areas. Another idea is the application of proven solutions to certain kinds of problems that narrows the gap between the identification of a problem and its resolution. Sometimes none of this will work according to practical sensibilities followed by expert consensus that says to prefer simpler choices over sophisticated methods.
Many books and websites exist for this and it is actually the most important thing to understand and exercise. The concept is not as large as it seems. True, some organizations that have software written do have persons dedicated to the verification and certification of software. A common idea is that the person who writes code, tests that same code before it is offered to others. You test what you write. The most basic way is to simply create the program, run the program, and visually observe the presence of defective behavior. Any defective behavior observed you then address. You can go further with tools such as debuggers, logs, memory checkers, automated scripts, test harnesses, and many other methods for asserting the quality of software you write.
When errors occur, you track down the cause of error if it is not obvious, resolve the direct or indirect cause, verify the error does not exist and that the correct operation is enacted. Some tools allow you to probe a program (remember that a program is different from source code) in a very deep way so you not only resolve present errors but potentially resolve errors proactively (prevent them). A broken program involved in an active business process is a disruption to business and can undermine the efforts of those who depend on it.
Most software development activity that fail, usually fail due to verification and certification. Whether learning software or putting into practice; intermediate skilled or expert, any project involving the creation of software will see the most effort in this area. Problems usually stem from an inability or an unwillingness to test at even a basic level. Improperly working software, even if the code compiles without error, is generally not acceptable.
A type of database exist that keeps track of the changes to a source code file. It has many uses that include allowing multiple people to work on a single program. Two of the most recommended ones are Git and Team Foundation Server. Books and websites exist that discuss the use of these tools in detail. Different approaches and considerations are involved in individual versus team use of revision control systems.
Requirements Management and SDLC
An explicit process called requirements solicitation and management is usually facilitated by individuals under the title of Business Analyst. That usually occur in larger organizations or situations in which different aspects of a software development process is carved out maximize attention to each aspect. Several books exist that discuss Software Requirements process and some familiarity with the concept and practices in this area are useful in terms of a systematic process for learning what the goals are and how those goals should be represented in software.
Requirements is at the head of an overall process called the SDLC, or Software Development Lifecycle. An individual may execute this process. Anyone who writes a complete computer program from beginning to end has essentially done just that although implicitly. The parts of the SDLC are Requirements, Design (business and technical), Construction (writing code, putting technical components together), Testing (verification and certification), Deployment, and Maintenance. People who do full-stack software development often lean more towards conducting the full SDLC. A few websites discuss the SDLC and are well advised to know.
Numerous terms exist in connection with software development. Parts 1 and 2 of this series introduced the concept of writing code independent of this vast lexicon of concepts. The perception of how software is written is often in contrast with reality. Systematic approaches to software exist in a number of ways and can be useful when thoughtfully applied when appropriate.
The last two articles discuss platform specific software development. The platform you chose for a software program can be important. I present some considerations when deciding the means for aligning software to platform.