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.

Comments

Post a Comment

Popular posts from this blog

A Common Technical Lead Pitfall

"That item is nearly done. I just need to run it past the team lead to make sure it's good to go." Have you ever heard a phrase like that? What about something like this? "So, I had that finished and then I ran it by the team lead and he made some great suggestions to make this more reusable. Unfortunately I'll basically have to rewrite the entire thing, but it should make it easier in the future." Do you see anything wrong with either of these scenarios? What about this one? "The team lead is out of town, so that item will have to wait until she gets back so she can look it over." Situations like these come up every so often in development. There are some simple solutions to each of these. With the last one, the team lead should have designated someone to act in her stead while she was out. In the second one, the poor junior developer should have worked closer with the team lead from the start. The first one, though, isn't really an
Keep reading

Maze Generation in JavaScript

Image
This article will outline the algorithm for random maze generation with backtracking and show code examples of the steps of the process. This algorithm is obviously useful for random maze generation, but the concepts can also be applied to other areas where random input or path generation is needed. The basics of this algorithm are as follows Initialize an object to track nodes that are visited Generate the nodes in the maze. Generally you'll want to track the node's edges. You may also want to give the node an ID of some sort. If you want to cut down on recursive calls, you'll also want to track its possible edges (aka all its neighbors). You'll also want to store this as an object instead of an array as it speeds up lookup times. Choose a starting point in the maze Mark the node as visited while there are potential neighbors to visit Randomly select a possible edge to visit Add that node to the edges for the current node Add the current node as an edge on the selected
Keep reading

Leadership Experiment Update 2

This week was a bit of a slower week. A number of people that usually participate in the channel were out of town. Even still, we had some decent thoughts on these two articles: Every Day We Must Sweep and  From Engineer to Manager: keeping your technical skills . I'd like to share one observation I made: Be Vulnerable Often times as leaders we think we need to appear invincible. For some reason we think in order to lead, we can't show weaknesses. While that may be a good mindset to have towards an opposing force in war, it doesn't work well towards those you lead. If you want those you lead to follow you, you need to be vulnerable at times. You need to show them your weaknesses and how you overcame them or how you're overcoming them. This doesn't mean you need to be publicizing your weaknesses, but it could mean recognizing them when they come up naturally or sharing stories about them while mentoring and coaching those you lead. Why Be Vulnerable?
Keep reading