Introduction

Pursuing a career in software engineering implies, at a minimum, a certain tolerance for change, if not an active pursuit or embrace of change. Processes and best practices evolve over time, as do the tools and even the languages themselves. While there are not a lot of truly new languages that have been released in the seven years since the first edition of this book was published, several languages have become more popular, including Go, Kotlin, Rust, and TypeScript. Ideas that appear in one language may surface in another, when the authors or maintainers of the language decide that the ideas are worth incorporating. Possible examples of that sort of cross-pollination, with capabilities being implemented in Python that may have originated in other languages, include the property decorator (.NET Framework had recognizably similar capabilities a year earlier) and the ability to annotate or type-hint functions and callables (a key capability of TypeScript, version 1.0 of which was released a year prior to Python’s support for the idea).

Even the titles have the potential for change. The previous edition of this book started with a breakdown of the various levels, grades, or ranks that organizations often use to indicate degrees of experience, expertise, and wisdom expected of their development personnel.

Those categories have not changed significantly in the intervening years:

• At a junior or associate level, the aspiring software engineer is typically someone who does not have much experience. They probably know the basics of writing code, but are not expected to know much more than that.
• The level between junior and senior is typically where the first real exposure to and experience with software engineering starts to happen: Understanding how different pieces of code interact and come together as a system, and the principles involved in the design of systems rather than just writing code, are a major portion of the growth or knowledge expected.
• A senior-level practitioner has enough experience, even if it is focused on a very specific set of products, projects, or systems, to firmly grasp all of the technical skills involved in typical software development efforts. There is also, typically, a solid handle on the non-technical or semi-technical skills involved as well. Key among those are policies, procedures, strategies, and tactics that encourage or enforce business values like stability of a final product and predictability of development efforts. Seniors may not be experts in those areas, but are expected to recognize and call out risks, and provide options and suggestions for mitigating those risks before they become actual issues.

Typical title breakdowns for these levels include junior/associate developer/software developer/software engineer; developer and software engineer, sometimes with organization-specific suffixes; and senior developer/software developer/software engineer. In the past several years, a new category has become common enough that it bears mention and discussion: staff engineer. Staff engineers are senior-level technical leaders who can provide guidance on complex problems and systems, architecture, system and design strategies, and perhaps more in the context of the organizations they work for.

The dividing line between programming and software engineering falls somewhere within the differences between the mid- and senior-level titles, as far as technical capabilities and expertise are concerned. At a junior level, and to a lesser extent at the mid-level titles, efforts are often centered around nothing more than writing code to meet whatever requirements apply, and conforming to whatever standards are in play. Software engineering, at a senior developer level, has a bigger picture view of the same end results.

The bigger picture involves awareness of, and attention paid to, the following things:

• Standards, both technical/developmental and otherwise, including best practices
• The goals that code is written to accomplish, including the business values that are attached to them
• The shape and scope of the entire system that the code is a part of