# Applying Systems Thinking to Software Development and Code Reviews

DevFeed: [Applying Systems Thinking to Software Development and Code Reviews](<https://devfeed.tech/articles/lessons-learned-from-systems-thinking-22318.md>)

Original publisher: [Read original article](<https://www.thecodedself.com/systems-thinking/>)

Author: Keegan Rush

Published: 2017-09-20T00:00:00Z

Content type: opinion

Language: en

Sources: [The Coded Self](<https://devfeed.tech/sources/the-coded-self.md>)

Topics: [systems](<https://devfeed.tech/topics/systems.md>), [Development](<https://devfeed.tech/topics/development.md>), [Code review](<https://devfeed.tech/topics/code-review.md>), [engineering-culture](<https://devfeed.tech/topics/engineering-culture.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [code-review](<https://devfeed.tech/tags/code-review.md>), [developer](<https://devfeed.tech/tags/developer.md>), [development](<https://devfeed.tech/tags/development.md>), [productivity](<https://devfeed.tech/tags/productivity.md>), [software](<https://devfeed.tech/tags/software.md>), [systems](<https://devfeed.tech/tags/systems.md>)

## AI overview

The author shares lessons from an Agile Poznan meetup on systems thinking and its application to software development. The article argues that improving systems, safeguards, and development pipelines can address recurring problems, reduce blame and micromanagement, and help teams focus code reviews on more meaningful issues.

## Source excerpt

I was lucky enough to attend my first meetup in Poland this month: Agile Poznan. The talk was on Systems Thinking, a topic that bored me in college but fascinated me when I entered the real world. Applying systems thinking can reveal the origins behind events and behaviors we see every day. Using this clarity can make you a better software developer, and a better asset to your organisation in general. Here are some of my insights from the meetup. A quick definition A system is made up of elements that share a purpose. Elements can be people, machines, or other sub-systems within the system. The elements are connected within the boundary of a system. You can identify a system through its elements and the connections between them, its purpose, and its boundary. Identifying the elements is easy. The purpose, boundary, and connections might be a little harder to find. It's not the fault of the person. It's the system. A surprising majority of problems can be mitigated when you stop blaming the person that made a mistake, and build your system so that the problem won't happen again. The person is just the messenger that's showing you that the house is burning down. Code reviews used to occasionally frustrate me before I came to this way of thinking. I'd find myself reiterating the same comments repeatedly. I want to learn, and I want to help others to learn, but learning gets diluted when we are forced to focus on miniscule issues like styling in a code review and miss the real opportunities for growth. I see using a tool like Danger, or adding any linting or code formatting to your development pipeline, as a great application of systems thinking. You're building safeguards in the system that will allow you to focus on more important and nuanced issues. The performance of an organisation depends on the quality of systems, not of individuals. The overhead of trying to micromanage every individual in an organisation outweighs the possible benefits. You simply can't maintai