I recently gave a presentation on the Software Engineering Body of Knowledge focused on road maps for software learning. This involves much philosophy on how we think about software. The conversation surfaced many crucial fundamental views that often go unstated. I’ve enumerated them here.

I was thinking about responsibility for different kinds of quality in an organization and I noticed that different kinds of testing line up well with particular roles and software lifecycle phases. I’ve summed it all up in a quick visual.

I’ve been wrestling with the Software Engineering Body of Knowledge (SWEBOK) to distill an intuitive mental image for software knowledge. Here is my latest attempt incorporating insights from previous visuals.

The Software Engineering Body of Knowledge (SWEBOK) portrays the software lifecycle as a set of transforms. I realized that each transform creates an artifact, and these artifacts are key to connecting cross-cutting concerns into the lifecycle phases.

The Software Engineering Body of Knowledge (SWEBOK) states that software engineering transforms problems stated in natural language to problems stated in electrical current. This transform view emphasizes the continuity of the design process and highlights intermediate artifacts.

The Software Engineering Body of Knowledge (SWEBOK) defines the major categories of software knowledge. It even talks about relationships between topics here and there. However, the overall picture is never very clearly explored. I hope to remedy that.

The Software Engineering Body of Knowledge (SWEBOK) levels up our industry. It collects evidence-based standard practices that every developer is expected to know. This post will establish some background for SWEBOK, cover my high-level takeaways.

I have a wide range of techniques for testing code behavior. I can reliably increase quality over time no matter how large the feature set grows and even measure the completeness of my test suite (mutation testing). The same can’t be said for UIs. I have long struggled to automate UI tests at all, and manual tests don’t sustain as the system grows. However, I think I may now have a technique to close the gap.

You know what they say about sharp-dressed code. Every dev’s crazy about it… More seriously, developers often fail to notice well-written code, but easily recognize and curse poorly written code. Still, some of the greatest minds in our field have a great passion for well-written code (quotes below). Code clarity directly contributes to understandability, maintenance, quality, and more. Here I’ll discuss practical ways to write clean and maintainable code.

Patterns are generally taught in isolation (separation of concerns), but application of patterns is often highly interconnected. Here I’ll show how my most used patterns come together as a design system.