
Ask HN: What does a disciplined programmer look like? - muzani
Paul Graham says that willfulness and discipline needs to be balanced:<p>http:&#x2F;&#x2F;www.paulgraham.com&#x2F;determination.html<p>But what counts as discipline? Morning routines? Or some strict way of working like XP programming?
======
twobyfour
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.

------
trcollinson
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.

[1]
[https://en.wikipedia.org/wiki/Fabrice_Bellard](https://en.wikipedia.org/wiki/Fabrice_Bellard)

------
AnimalMuppet
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.

~~~
muzani
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.

------
demygale
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.

~~~
luckydude
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.

------
mtmail
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.

------
luckydude
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.

------
Jugurtha
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.

~~~
muzani
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.

------
peterchon
consistency.

