Discipline is about being aware of your own counterproductive tendencies and being willing to do things that aren't entirely comfortable or natural to you in order to be productive.
For instance, I have one colleague who has a tendency to perfectionism, and will spend months tracking down every tiny possible corner case that we're never going to hit, in a small low-priority feature in a CRUD app that wouldn't destroy anyone's lives if it went down for a week. For him, discipline means checking himself frequently and asking what the actual ROI is of where he's about to spend his time.
I have another coworker who loves to start new projects but getting him to finish them is worse than pulling teeth. For him, discipline is about follow-through.
My own job happens to include a lot of responsibilities other than programming. For me, some days discipline is about letting the Slack conversations around the other projects that I'm responsible for and anxious about slide for an hour or two so I can get in a little flow time with the code. Other days it's about putting down the fun coding project so I can make sure someone else's project doesn't go off the rails.
Discipline is different for each person, and it starts with self-awareness - which is the sort of trait that will serve you well in other ways - both in life in general and in any career.
When I think of disciplined programmers, I think of Fabrice Bellard.[1] In fact, I think of him so much that he is the person who I have modeled my own practices after.
Here is a short list of a few of his accomplishments:
1) He won the IOCCC twice.
2) He built the TinyCC boot loader.
3) He wrote a fast pi calculator that won a World Record on commodity hardware.
4) He wrote QEMU and FFmpeg.
The list just goes on and on. He is not productive because he has a specific morning routine. I don't know if he follows specific XP practices, but I would doubt that he follows most of them. But I have noticed a number of things he does do:
1) He is relatively paced in his timing. He generally doesn't give crazy time estimates and is very realistic about how long his work will take him.
2) He sticks with similar technologies and has Mastered them. Just like a Master sushi chef can't easily make french pastries and wouldn't bill himself as a pastry chef, a software programmer who has completely Mastered a language like C shouldn't just bill themselves as a Master at Lisp.
3) He is always learning and expanding his Master of his knowledge. It's incremental but very impressive.
4) He has no problem taking calculated risks in his development, and often he can make them pay off.
I would say he has definite patterns. He works and works hard constantly. But I don't think he ascribes to any particular methodology.
Discipline means thinking about the error paths in your code, not just the happy path.
Discipline means regular testing.
Discipline means documentation.
Discipline means fixing the bugs - not just the "bad" ones, but the annoying little ones. (Not every bug, though - some bugs truly are not worth fixing.)
Discipline means communicating with your coworkers (including those annoying bosses and managers). It means making estimates, and taking enough time thinking them through that they're actually something close to accurate.
Discipline means thinking about the design before you start coding. (This does not mean that you can't explore before deciding on a design. It also does not mean that you can't iterate the design after discovering some issues with it implementation. In fact...)
Discipline means refactoring the design and code so that changes fit, rather than just being hacked in somehow.
Maybe a summary: Discipline means working like the code is going to be used for the next twenty years, rather than like it's going to be used only for the next week.
But a common theme in PG's writing is to hack... it literally is to be used for next week. Productivity is measured in lines of code. Technical debt is acceptable; as a lot of the code will be erased anyway in an early stage of a startup.
Besides the designing before coding part, I don't think this was quite his intent when saying discipline.
One aspect of discipline that I think is underrated, is to take notes as you work. What you were thinking, what you tried, what worked and what didn't. It helps with reflection even if you never go back and read the notes.
This is a good one, I forgot that one. How I do it is I type up the notes at the end of my day, I always put them in a file called "STATE" in whatever directory I'm working in.
I document what I was trying to do, how far I had gotten, what I think I need to do next.
I can't tell you the number of times that as I'm writing up the notes I go "ahhhhh, that's it!" and off I go for another few hours and actually finish.
And in the times where I leave it, it's so much faster to get up to speed the next day after reading the STATE file.
And my coworkers at the time knew that I did this and would do stuff like
$ cd /home/bk/lm
$ find . -name STATE -mtime -1
to see what I was working on. Not saying that's a good way to communicate, but it worked for us at the time.
Regardless if you put in one hour or eight (or unhealthy 16) hours per day into your project/startup a disciplined programmer works on the most important task. That might be the one leading to most growth, profit or just avoiding damage to the business. That task might be utterly boring, and there's 100 other task that are easier, faster to implement or more fun. Discipline in my opinion means you choose that boring task.
Docs and tests are good one. Lots of people like the fun part of coding, which is getting some new thing to work. I've taught myself to like docs and tests, to the point that when I'm reviewing a changeset I look to see if there are docs and tests and just push back right away if there are not.
If you get into that groove, write the docs first. When you have to explain your feature, write out the command line options, all of that, you have to sort of imagine it all in your head, you start to think about is this the way other commands work, am I being consistent, etc. I find that when I do the docs first I do a better job on the code, especially the UI parts or where it fits with other code.
And tests, regression tests. When I started BitKeeper we did regression tests with every command. So frigging pleasant. It got to a point where you basically couldn't break BK if you passed the tests, or at least you had to be really sneaky.
I agree with twobyfour that it's different for different people, his/her comment that you need to be self aware is a really good point.
I have a polar star / meta kind of rule and chunk down from there:
me[i+1] > me[i]
`i` can be time but is not specified so it can work with any granularity you like: year, month, day, hour, minute. It also works for space: the me in a place needs to be better than the me in another place.
Discipline not being discouraged. One of my favorite sayings since I was a child is "Ad augusta per angusta". At one point I was reading about two to three books or equivalent per day. Now I can't do that and it's discouraging. Discipline to push through that and read during commute what amounts to a book or two per week. Pales in comparison, but it takes discipline not to be discouraged by the disparity.
Discipline also to think more about what I read: from compulsive consumption to pondering and trying to learn from what I read to serve my day to day life, instead of merely getting high on "knowledge acquisition". Wisdom vs knowledge, if you will. A great slogan is Wharton's "Knowledge for action". I like that.
Discipline in outsmarting myself. I'm writing code and I know that I'm not as smart as I am, so I leave a trail of thoughts in the comments to take my future self by the hand on why something was written the way it was, and where to go from there. Plenty of TODO detailing the reasons (so they may be changed if the reasons became invalid). My future self loves my past self for being so thoughtful and prescient and patient with him.
Discipline to avoid shortcuts. "Move fast and break things" is bullshitese to me. It's bullshit and I think people who live by that aren't the one fixing the broken pieces. Shitty code is seldom clever and those who shit it seldom refactor it. Discipline to acknowledge the fact that if I think I'm moving faster by skimping on variable names, I'm being a moron and others may pay the price.
Discipline in trying to think hard about my code and constantly refactor it, unbeknownst to my employer who tells me the code is good as it is and not to break it by refactoring it, to which I retort it's as good as it is (or not as bad as it was) because I constantly refactor it. It means writing documentation for imaginary code beforehand and how I would use it, it means once written getting non-programmers to try to follow the docs for an API so if a non-programmer who's never written a line of code can get it to work easily, future maintainers won't have too much trouble. It means to learn new tools to make better docs. Discipline in taking care to write good exception messages that when raised communicate I'm on top so at least the user doesn't panic and knows if there is a detailed message for it, it's okay. A message that explains why it happened and what to do about it (even giving a list of Linux commands to run to narrow down the scope or fix it).
Discipline in consistently trying to learn more about how the mind works (Hebb, Ebbinghaus, LTP, and how these beautiful tentacular beasts we have in our skulls work). It is about triggering a break-point when I have a good idea and dumping the context to know why and how I had it, trying to go as far back as I can. It also works on bad ideas. Discipline in having a pen with me. It's having a pen and a notepad on my bedside so I can note my thoughts right when I'm about to sleep: ever had a great idea right before you gave in to Morpheus and were glad because you'll implement it "tomorrow" only to wake up having forgotten about it? It's happened to me but I know better than to count on myself remembering it.
Discipline in being intellectually honest and not bullshit someone who knows less than me on a tiny specific point. This includes myself (I have a check: do I know what I'm telling myself or am I just bullshitting myself? Can I prove to myself I know what I'm talking about and what are my arguments? Do I at least have a starting point to get the factually correct information? If yes, what am I waiting for to get it?).
Discipline in observation. I'm fortunate to have a wide range of interests (but even that is a fruit of discipline: maintaining the interest I had as a child and not letting it die). Observe other fields and get inspired, borrow things, mindsets, tools, practices, etc.
Discipline in catching myself when I think something is "obvious". Is it really? During sophomore year in college we had a course in Strength of Materials. A very counter-intuitive and beautiful thing is why a pull-up bar is hollow (a tube) and not full. Discipline to have a magnifying glass on "intuition" and guard myself against thinking something is "trivial" because things rarely are.
Discipline to ask why someone wrote a line of code the way they did. It's easy to think we're smarter than the next guy, it's easy to change a weird line of code, but it takes discipline to figure out why it was written the way it was. Chesterton's fence and what not.
Discipline in asking people questions, asking them to explain to me what they do and why they do it. Whether a banker, a shepherd, a soldier, a surgeon, a dentist, a mechanic, an author, an illegal taxi driver.. I care about process, motivations and incentives: what do people do, and why they do it.
Discipline in seeking universal truths. I have a feeling I'm about to have a great insight about something, I don't know which. It's akin to feeling a presence in the dark, you don't know what it is and if there's anything there in the first place..
PS: If you have that universal truth about mind mastery, economics, and happiness.. Please share your secret here. I accept panaceas and silver bullets.
Thank you for the detailed reply. It's a very good one, and I think it does boil down into doing the harder thing instead of the lazy one, especially really tempting things like lying to yourself.
For instance, I have one colleague who has a tendency to perfectionism, and will spend months tracking down every tiny possible corner case that we're never going to hit, in a small low-priority feature in a CRUD app that wouldn't destroy anyone's lives if it went down for a week. For him, discipline means checking himself frequently and asking what the actual ROI is of where he's about to spend his time.
I have another coworker who loves to start new projects but getting him to finish them is worse than pulling teeth. For him, discipline is about follow-through.
My own job happens to include a lot of responsibilities other than programming. For me, some days discipline is about letting the Slack conversations around the other projects that I'm responsible for and anxious about slide for an hour or two so I can get in a little flow time with the code. Other days it's about putting down the fun coding project so I can make sure someone else's project doesn't go off the rails.
Discipline is different for each person, and it starts with self-awareness - which is the sort of trait that will serve you well in other ways - both in life in general and in any career.