The code in this chapter is for demonstration purposes only, showing the application of some of the topics and practices noted in the chapter.

Job titles for roles in software development are widely varied, even before accounting for the distinct levels, grades, or ranks indicating seniority in the field. Role titles include variations of Developer and Engineer, the latter usually prefixed with Application, Software, or some specific technology focus. Examples of these foci include Front End, Back End, and Full Stack for application-focused roles, and Infrastructure or Network for roles that relate to those technologies. There are many more variations. Levels, grades, and ranks include Junior or Associate for those with the least amount of professional experience, Senior for those with a substantial amount of expertise, and, more recently, Staff variants for those with even more experience. A typical progression, focusing on Software Engineer as the base title, might be:

• Associate Software Engineer
• Software Engineer
• Senior Software Engineer
• Staff Software Engineer
  ...

There are three easily identifiable areas of focus that differentiate software engineering as a discipline from simple programming. A fourth (let’s call it user interaction) either weaves through the other three or is broken down into its own groups.

Software engineering must pay heed to standards, especially non-technical (business) ones, and to best practices, which are often independent of business needs. These may or may not be followed but, since they are standards or best practices for a reason, not following them is something that should always be a conscious (and defensible) decision. It is not unusual for business-process standards and practices to span multiple software components, which can make them difficult to track if a certain degree of discipline and planning is not factored into the development process to make them more visible. On the purely development-related side, standards and best practices can drastically impact the...

There can be as many distinct questions that can be asked about any given chunk of code as there are chunks of code to ask about — even quite simple code, living in a complex system, can raise questions in response to questions, and more questions in response to those questions. If there is not an obvious starting point, these basic questions are a good first step:

• How easily understood is the functionality?
• Who will be using the functionality?
• What will they be doing with it?
• When, and where, will they have access to it?
• What problem is it trying to solve (why do they need it)?
• How does it have to work? If detail is lacking, breaking this one down into the following questions is useful:
  • What should happen if it executes successfully?
  • What should happen if the execution fails?

Teasing out more information about the entire system usually starts with something as basic as the...

There is more to software engineering than just writing code. Experience, attention to detail, and asking questions about how the code functions and interacts with the rest of a system are important aspects of evolving from a programming to a software engineering mindset. The time required to acquire experience can be shortened, perhaps significantly, by simply asking the right questions.

There are also factors completely outside the realm of creating and managing code that contribute to that mindset. They focus mainly on what can, or should, be expected from the pre-development planning around a developmental effort, and that starts with understanding a typical software development life cycle. Knowing what the expectations for each successive level are as you progress to more senior roles, and what to pay heed to in order to meet those expectations, will help in achieving those roles. They will also improve your coding skills, helping to form good habits that can be applied...