Discipline in Software Engineering

Recently, I read an article called "Great Development Teams Have a Culture of Discipline." The article got me thinking a bit about discipline and work especially as a Software Engineer. It even got me Googling quotes about discipline. I'll share just a few here:

I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times. - Bruce Lee

Confidence comes from discipline and training. - Robert Kiyosaki

Discipline is the bridge between goals and accomplishment. - Jim Rohn

Discipline is rarely enjoyable, but almost always profitable. - Darrin Patrick

There are many, many other similar quotes about discipline and many of them are very good.

Looking at these quotes and considering the points made in the article, I started to wonder how well I was doing with discipline. Would I consider myself a disciplined individual? A disciplined employee? A disciplined Software Engineer?

That last question got me thinking, what does it mean to be a disciplined Software Engineer? When I think of that, I immediately think of the book Clean Code and treating software engineering as a craft. If I'm a disciplined Software Engineer, I'll write tests, I'll practice TDD, I won't stop at working code, I'll refactor until the code is clean, I'll be ethical, and I'll do my best to be professional in my craft. Sometimes this means doing things I don't enjoy. I mean, I can't say that I really enjoy TDD, but I do see great benefits from it when I do practice it. I can't say I really like refactoring at times. Sometimes it can be a real burden. But I see great benefits from it when I do decide to refactor especially after a particularly burdensome refactor.

In the technology industry these days, there's a lot of focus on having fun and employee satisfaction, and rightly so. There's a ton of research indicating that happy employees perform better in many aspects of work. Employee retention is very high when employee satisfaction is also very high. Focusing on things that make employees happy is critical. However, I think we sometimes forgo valuable activities in the name of employee satisfaction.

The thing is, there are some things in software engineering that we need to do regardless of if it's fun or not. There are things that are less glamorous, less intriguing, less engaging that simply need to be done. From testing to documentation to continuous learning to negotiations. There are things we need to do that we may feel pressure not to do that should be done anyway. They're that important and they're that valuable. Sure, writing documentation isn't very fun. We're software engineers. We want to be creating things or fixing things. We don't want to be bothered by activities that take us away from that. But documentation can be critical especially on a large team or a growing software project. As new members join the team or as the occasional seasoned veteran leaves, documentation can help in quickly getting people up to speed on areas of the project they're not familiar with.

In the end, we're professionals working for a real business in a real world. While we are here to do things we enjoy, we're also here to do what the business needs us to do so that the business makes money and we're successful as a software team. If that means writing documentation, then write that documentation. If that means being a stickler about process so that we can scale and take the team to a new level, then so be it. If there's some activity that we're not doing but we know would be valuable for certain reasons, then we should be disciplined enough to recognize that, hit the pause button, and right the ship.

I believe we can be disciplined about the important things and still have loads of fun while at work. There's a continuum there and each company and team needs to decide where they want to be on that continuum and if the trade-offs are worth it. The more disciplined you are, the less freedom and autonomy the teams will have, but you'll likely have awesome documentation, tests, code, etc. The less disciplined you are, the more freedom and autonomy the teams will have, but things may happen out-of-process, the code might be dirty, there may not be any documentation, etc. At the extreme ends of the spectrum, you'll likely see a lot of attrition. Somewhere in the middle you'll find the sweet-spot for your team.

--

Feel free to leave your thoughts in the comments below! The above thoughts are a bit raw and unrefined. Writing this post helped me refine them a bit, but I still feel like I'm missing something.