There are very few companies that were fundamental to the technological advancement and the expansion of the internet in this century. One of them is most certainly Google. With their product portfolio evolving over the last 25 years, they had to deal with massive scale and complexity, as well as make countless trade-offs when architecting their systems. The experience and knowledge gained through that process are worth paying attention to, and we're lucky to have a direct insight into how engineering is done at Google.

This is the first article in a series where we cover the book Software Engineering at Google by Titus Winters, Tom Manshreck, and Hyrum Wright. 📕 We will go over various aspects of software engineering as a process, including the importance of communication, iteration and continuous learning, well-thought-out documentation, robust testing, and many more.

In this article, we explore the definition of software engineering, to set the right context before jumping into other, more detailed topics.

Getting the right perspective

As engineers, we all participate in the activity of software engineering almost daily, often without really defining it clearly. The book gives us a very concise definition of software engineering.

Software engineering is not just the act of writing code but all of the tools and processes an organization uses to build that code over time.

The emphasis is on over time. ⏰ That's where the difference between software engineering and programming lies. Programming is all about writing code that solves a given problem. Right here and right now. However, when you start considering how this piece of code might evolve and change, whether you or your teammates will understand it a few months from now, if it will be scalable or become a maintenance burden, that's where you step into software engineering.

With this as a focal point, we can more clearly outline what it is that we're trying to accomplish and better understand which things are important in that venture and which might be just distractions.

Core principles of software engineering

We can outline a few principles that are worth paying attention to and framing engineering decisions around. Here's what the book suggests.

• Time and change - how code will need to change over its lifetime. As a general rule, the longer the expected life span of your software, the better it should be optimized for change, related to either technical or business reasons.

• Scale and growth - how an organization will need to adapt as it evolves. A programming task is often an act of an individual. Software engineering task is a team effort. That has to be factored in the processes and tools you end up using.

• Trade-offs and costs - how an organization makes decisions based on the above. There is a factor of at least 100,000 times between the lifespans of short-lived code and long-lived code. It is silly to assume that the same best practices apply universally on both ends of that spectrum.

Conclusion

Here's a short summary of things we went through:

• definition of software engineering

• difference between programming and software engineering

• core principles of software engineering

Next up, we will go over the role iteration plays in the engineering process. See you! 👋

If you liked the article or you have a question, feel free to reach out to me on Twitter‚ or add a comment below!

Further reading and references

• The original Twitter thread with notes from the book

• Link to purchasing the book

• Photo by Alain Pham on Unsplash