
Mastering Programming: An Outline - KentBeck
https://www.prod.facebook.com/notes/kent-beck/mastering-programming/1184427814923414
======
keyle
Sadly just an outline but I didn't mind that. Good read.

I'd add a few things I've noticed over the years. Great developers like to
pair program on tricky stuff, because they always learn something. They will
try 2 different implementations if they're not sure which is best, and then
the right one will then be obvious. They back their arguments with real world
proofs. They try most fringe/new technology, even if it's not right for the
current project. They hold large amount of domain knowledge in their heads.
They admit when something is twisting their brains, draw it on paper, talk
about it and then bang it out. They fantasize about what-ifs, in a perfect
world, scenarios. And they love to share knowledge.

~~~
andyjdavis
> They try most fringe/new technology

I have actually found the opposite. The best programmers I have known are
often the most reluctant to try new technologies. At least until the
technology appears to have reached some sort of critical mass and it has been
shown to be virtually guaranteed to increase their already very high levels of
productivity. Partly this is just an experience thing. After you see enough
shiny new things wrapped up in spin and hype the task of peeling that stuff
away to get an honest assessment becomes unappealing.

~~~
sklogic
Exactly. I have not seen a _new_ thing in many years. All the so called "new"
things are simply rebranded decades old ideas.

~~~
samirm
Isn't everything?

~~~
ChristianGeek
Even your statement isn't new! 2200 years ago King Solomon wrote, "There is
nothing new under the sun." We just keep finding different ways to rehash the
same core concepts.

------
0mbre
Something that is helping me a lot recently is trying to know all there is to
be known about the tools/concept that I am using and the problem that I am
solving. Too often have I used tools I half understood to solve problem that I
didn't define clearly enough.

~~~
mercer
Yeah, this is a bad pattern I started noticing even way back when I mucked
about with Wordpress theming. Hell, I could go further back and notice this
pattern in assembling LEGO. And sadly I still catch myself doing it even now
whenever I'm caught up in this "this shit doesn't work, let me try _that_ real
quick" loop, where 'that' is only one of many variables I don't really
understand.

What I've noticed works best for me is to nip it at the bud rather than bail
out of that loop. Because once I'm stuck in the loop, I find it hard to sit
back and think about things properly.

The worst cases for me is when I try more than one 'new thing' at once, which
usually happens in new projects. Most recently I set up a new project and
decided to try out typescript, a new back-end tool, and another build process
all at once. I couldn't get it working, and only once I dived into it I
discovered there was one 'little thing' (javascript's current module
kerfuffle) that caused most of the issues.

What I hates most about these episodes is that at the end, all I learned was a
tiny bit more about disparate systems that I still don't master. Huge waste of
time.

~~~
viewer5
> notice this pattern in assembling LEGO

What do you mean?

~~~
mercer
Well, usually the first time I'd have some new package of Lego, I'd want to
construct the exact thing I bought from the instruction booklet.

Sometimes I'd be working on different parts at the same time and use a piece
that was similar to another. I recall a few times looking everywhere for the
missing piece or disassembling a part to find it only to find out that another
little part I assembled had the missing piece.

------
bcbrown
> Call your shot. Before you run code, predict out loud exactly what will
> happen.

That's probably my favorite bit of advice. It really helps with understanding
how much your assumptions diverge from reality.

~~~
dmolony
I do this with life in general. You soon realise how bad you are at
estimating, but it helps you improve.

~~~
wallace_f
Sounds like a good idea and seems to be worth a shot. Actually, I am thinking
about why I put so little effort into this, currently. I will take your
suggestion and see how it goes :)

------
shadesof
> When faced with a hard change, first make it easy (warning, this may be
> hard), then make the easy change.

This is my favorite bit. Katrina Owen mentions this in her talk on
refactoring. "Make the change easy; then make the easy change."

[https://www.youtube.com/watch?v=59YClXmkCVM](https://www.youtube.com/watch?v=59YClXmkCVM)

~~~
endgame
This is excellent advice, and I've seen it replicated as far back as Fowler's
book on refactoring. Does the trail go further back than that?

~~~
mikekchar
I may be mistaken, but I actually remember Kent Beck saying it in his original
TDD book. That was the thing that made me understand how refactoring can take
the place of big design up front. The best part is that you only work on
things that you need as opposed to wandering around changing every piece of
code that you don't like ;-)

------
elliotec
I'd like to see this fleshed out more with examples, because I don't really
know what some of these mean.

~~~
Teeboo
Well luckily there is a book for that ;-)

1996\. Smalltalk Best Practice Patterns. Prentice Hall. (ISBN 978-0134769042)

1996\. Kent Beck's Guide to Better Smalltalk : A Sorted Collection. Cambridge
University Press. (ISBN 978-0521644372)

1999\. Extreme Programming Explained: Embrace Change. Addison-Wesley. Winner
of the Jolt Productivity Award. (ISBN 978-0321278654)

2000\. Planning Extreme Programming. With Martin Fowler. Addison-Wesley. (ISBN
978-0201710915)

2002\. Test-Driven Development: By Example. Addison-Wesley. Winner of the Jolt
Productivity Award. (ISBN 978-0321146533)

2003\. Contributing to Eclipse: Principles, Patterns, and Plugins. With Erich
Gamma. Addison-Wesley. (ISBN 978-0321205759)

2004\. JUnit Pocket Guide. O'Reilly. (ISBN 978-0596007430)

2004\. Extreme Programming Explained: Embrace Change, 2nd Edition. With
Cynthia Andres. Addison-Wesley. Completely rewritten. (ISBN 978-0201616415)

2008\. Implementation Patterns. Addison-Wesley. (ISBN 978-0321413093)

>> Selected papers

1987\. "Using Pattern Languages for Object-Oriented Programs". With Ward
Cunningham. OOPSLA'87.

1989\. "A Laboratory For Teaching Object-Oriented Thinking". With Ward
Cunningham. OOPSLA'89.

1989\. "Simple Smalltalk Testing: With Patterns". SUnit framework, origin of
xUnit frameworks.

~~~
elliotec
I didn't mean the entire Kent Beck bibliography, this is obviously a different
thing than his books or he would've referred to his books. I just would like
to see this particular outline expanded slightly is all.

------
KentBeck
I updated the description of 80/15/5, a career risk management strategy.

~~~
Dangeranger
Several of these have been suggested to me by mentors, many others are new.
This is a fantastic list. Thank you for your thoughts and advice.

------
sleepychu
My top piece of advice: Programs behave predictably, when something impossible
is happening it's because one of your assumptions is wrong. When that happens
you'll find the bug the moment you start testing your full set of assumptions.

For some reason, even though this is invariably true, my friends at school
didn't appreciate "I can't understand why I'm seeing this weird behaviour",
"One of your assumptions is wrong!" xD

~~~
sklogic
There are bugs in compilers. Hardware faults. 3rd party library faults and
inaccurate documentation.

Good luck asserting these assumptions and factoring them in your designs.

~~~
sleepychu
I'm happy to risk verifying those last ;-)

EDIT:

>inaccurate documentation. With the exception of this one, I usually assume
that you need to verify the behaviour of a library/feature you've not used
before.

------
jasim
These are attributes that everyone can, on honest personal judgement, can
mistake to possessing themselves to varying degrees. But it might be a useful
list to read through when stuck at a problem that is simply not giving way.

Unless we have the chance to learn from and be coached directly by a master,
what would be helpful is narratives on how they think and solve problems.

The best I have so far come across in a book is "Coders At Work".
[https://github.com/aosabook/500lines](https://github.com/aosabook/500lines)
promises to be another. Rich Hickey did great service by talking pragmatically
about the meta aspects of programming through Hammock Driven Development and
Simple is not Easy. Dijkstra's and Alan Perlis' writing that has been gaining
a resurgence in popularity is also of a similar ilk.
[http://damienkatz.net/2005/01/formula-engine-
rewrite.html](http://damienkatz.net/2005/01/formula-engine-rewrite.html) also
is an intriguing story.

------
sigill
The article makes a number of good points. The first three points in the
"Learning" section resonated very well with me.

Then there's stuff I just don't understand. For example:

> Multiple scales. Move between scales freely. Maybe this is a design problem,
> not a testing problem. Maybe it is a people problem, not a technology
> problem [cheating, this is always true].

What does he mean by scales?

~~~
richdougherty
He might be suggesting that you can consciously consider the problem different
at levels of detail. You can step back and look at the problem in its wider
context ("the big picture") and you can also zoom in and focus on aspects of
the problem in more detail.

~~~
sigill
Thank you. I was thinking of scale as a measure of order of magnitude and then
it didn't make sense.

------
quincyla
There is wisdom behind these bullet points. This wisdom could be better
communicated through a series of fleshed-out articles with real life examples.

Otherwise, these points are difficult to contextualize, retain, and apply.

~~~
jonathantm
Good point. Go for it.

------
arekkas
After reading that, I don't feel a bit smarter then before. That's usually how
it goes when you make a bold, universal statement about something and put it
into 10 lines of text.

I aknowledge what Kent Beck has done and what facebook is doing but this
doesn't deserve to be on HN front page.

~~~
dasil003
True, but then long protracted explanations don't necessarily do a better job,
they are prone to missing the forest for the trees. The beauty of the short
bullet point is that it makes the practitioner think, sort of like a zen koan.
It will be utterly useless to someone who hasn't already put in the practice
to be on the brink of enlightenment already, but then again, what other way is
there to truly learn?

------
kevindeasis
(ﾟヮﾟ) Anyone else knows other paths/checklist from beginner programmer to
expert/senior programmer in different domains (front-end,back-end, dev-
ops/sysadmin, android, ios, system programming, gaming, 3d, image, video) ?

------
aryehof
I also think it important to understand the nature of the environment your
problem is in, because it so much flavors the approach and the solution.

If in computer and data science, emphasis is on algorithms, data structures
and ADTs. But if in business, commerce and industry it's the representation of
complex domain concepts, real and abstract, and their interactions that are
key.

In some ways there is a fundamental divide between the two. While the ops
advice is valuable, for me an understanding of where and how to apply
techniques across that divide is one of the biggest impediments to "mastering
programming".

------
makuchaku
I just noticed, this note is being served by www.prod.facebook.com? Note :
".prod.facebook"

~~~
sleepychu
Think dev is called .poke.facebook?

~~~
makuchaku
Nop, doesn't works. DNS won't resolve.

------
gavinpc
"Good design is about taking things apart." \--Rich Hickey

I think that statement captures several of these. He says it in the context of
methodology and "architectural agility" in a great talk called "Simplicity
Matters." [0]

[0]
[https://www.youtube.com/watch?v=rI8tNMsozo0&t=9m49s](https://www.youtube.com/watch?v=rI8tNMsozo0&t=9m49s)

------
minusSeven
>Rhythm. Waiting until the right moment preserves energy and avoids clutter.
Act with intensity when the time comes to act.

What does this mean ?

~~~
ArkyBeagle
Don't swing 'til the ball gets there. If it can wait, it probably should wait.

------
JayHost
"Move fast and break stuff abstract stuff and build quick Move Fast With
Stable Infra"

How about just put in the work and learn the hard way?

------
hcarvalhoalves
This is a great summary. One could change the title to "Mastering Problem
Solving" and it would be just as true.

------
mathattack
Great outline. Given the source I would like to see it taken down a level of
detail in the future.

------
caseymarquis
It'd be interesting to compare this to "Ask HN: Habits of the master
programmer?"

~~~
spdionis
Why don't you create a new thread then?

~~~
caseymarquis
Lazy.

------
sklogic
Despite hating anything XP, I can strongly relate to this one:

> When faced with a hard change, first make it easy (warning, this may be
> hard), then make the easy change.

It aligns well with my natural process: for any problem, spend most time
designing and implementing a DSL for it, and then solve it trivially in this
DSL.

------
raarts
Old German proverb: In der Beschränkung zeigt sich erst der Meister.

~~~
srik
A bit of searching found this translation

> The master shows himself first in confinement

Thanks. In the process I found this beautiful poem.
[http://johnirons.blogspot.com/2011/09/work-in-progress-
trans...](http://johnirons.blogspot.com/2011/09/work-in-progress-translation-
of-goethes.html)

~~~
joepvd
Not a German, and not a native English speaker, but I would propose the
following (depersonalized, inaccurate, paraphrased, bastard...) translation:

    
    
        Mastery reveals itself by the limitations of its scope.

------
MciprianM
Why prod.facebook.com?

------
jondubois
This article should be called 'Mastering large-scale team programming'. In
reality there is no single correct approach to programming. All
programmers/engineers/developers have different specializations.

Some developers are really good at getting an MVP out the door quickly but
their code may not quite work at scale. Others are good at working in large
teams on large projects, others work better alone or in small teams. These
different types will produce different types of code - the utility value of
various programming habbits changes based on team size, project size and
urgency requirements.

There could be some 'Master MVP programmers' and 'Master team-player
programmers', 'Master large-project programmers'... You can rarely put them
all under a single label - As developers we tend to get stuck with particular
styles depending on which kinds of companies we have worked for.

It is not quite correct to assume that because a company is financially
successful and handles many millions of users, that its methodologies are the
only correct way to do things.

Programming is an adaptive skill and should change based on economic/scale
requirements.

~~~
phillipwills
I wouldn't say that this article is describing a correct way to do things.
It's more of a set of guidelines to follow, and I'm glad someone wrote them
down.

I've been doing these things, but I generally have a hard time concisely
describing it. Of course, these aren't hard and fast rules. More of a guide to
thinking about problems to help programmers be more efficient and accurate...
More precise...

I don't really know how to describe it, but one day, you find yourself doing
these things more... Stuff gets easier... Things just start to click.

I'd like to add one more, though maybe it's really just another way of putting
one of the other statements.

Stop worrying about all the unknowns in the project. Work on what's known,
usually the unknowns will become more clear as you progress.

~~~
jcbrand
> Stop worrying about all the unknowns in the project. Work on what's known,
> usually the unknowns will become more clear as you progress.

Good advice which applies not only to software development. I've found that
focusing on what's currently known and on what I can change removes anxiety,
allows me to move forward and then usually the unknowns resolve themselves
along the way.

~~~
mcguire
It works very well, until it doesn't. Then you have a pretty interface, an
elegant test suite, and a big black box full of entropy and ignorance labeled
"then a miracle occurs".

~~~
phillipwills
Even when that does happen... and I'd argue that it often does not, if you've
done the work to make your interface pretty, and write a precise, accurate
test suite, you've usually done the work to make the actual functions neat and
orderly...

Even when you end up with a black box full of entropy, it's segregated from
the rest of the system. You can feel free to change the rest of the system
around it and know that the black box will keep doing it's job, as long as you
keep using the well-written API within spec.

But, that's not all you get... because you took the time to write the tests,
you can refactor this entropy box to your heart's content... until it starts
looking more approachable. You've got your tests around the API, right? Then
you don't even really need to change them to do the refactor work. The only
reason to change the tests would be if you want the function to do something
else (or you missed something, of course).

Take small steps... refactor out a couple lines at a time... run the tests
with each iteration. Based on previous experience, you're going to end up with
a fairly clear and concise implementation... not to mention performant.

~~~
mcguire
Absolutely! Get something working and then keep it working while making small
steps.

On the other hand, the example that comes to mind is Ron Jeffries' TDD sudoku
solver.

I've seen several systems where the magic black box is doing things
hilariously wrong---as long as it works on the test cases and the production
results are sufficiently difficult to verify, it'll be accepted as gospel.

------
yoyo_io
www.prod.facebook.com

That's new to me.

------
partycoder
While the author is known (technical coach at Facebook, creator of XP software
methodology), I sort of disagree.

You can follow this guide and still be a low value programmer. This guide
won't take you to mastery level.

And, there is also a sense of irresponsibility around one item: "easy
changes". Easy changes as in, duct tape programming? That's pretty much
turning your project into a Jenga tower... you add your "easy change", that
incurs technical debt, fix a problem... but lower productivity for following
changes. Also sets a bad example for other people to follow.

~~~
caconym_
Did you only read the bold text? This is very different from "duct tape
programming":

> When faced with a hard change, first make it easy (warning, this may be
> hard), then make the easy change

~~~
partycoder
Given the fact that duct tape programming is what the majority of people do
nowadays, I would be more explicit about what an "easy change" means.

------
Teeboo
What? Seriously, what?

What argument are you making here? Boxing / Ali was an analogy to demonstrate
the widespread respect of the engineering community that KB has earned.

/awkward

To be clear; my post was not about you being boxer.

/awkwardoff

~~~
jondubois
You can't blindly accept everything an article says just because it is written
by a respected person. It means nothing at all.

Karl Marx was also highly respected until he was proven wrong...

~~~
Teeboo
I am not blindly following it. I think it is sound practical advice given by a
titan of engineering.

I have yet to read anything of yours which says why I _shouldn 't_ listen to
Kent Beck.

For every well respected opinion or technology there is always a group of
naysayers. A cadre of individuals who offer nothing of insight in return.

In 1906 John Philip Sousa claimed the phonograph would ruin music. Don't be
that guy.

Don't be the guy that says GUI's will never take off, that touchscreen phones
will not sell, that the Godfather was a bad movie etc.

You are being contrarian for the sake of it. Kent Beck has a massive canon of
work which advances the predictability and success rate of software
development. You can challenge bits of it, improve it and contribute.

You are being _that guy_ that makes sweeping generalisations which advance
nothing.

What, specifically, do you think needs improved in the OP's article?

~~~
blub
By a titan of software development processes, if there even is such a thing.

Titans of engineering are people like Torvalds, Carmack, Engelbart, Wozniak,
Codd, Lamport, Wall and many many others.

Including process people in that list would be mistaken.

~~~
Teeboo
That's a fair challenge and I can accept I might be over-effusive in my
praise.

------
Teeboo
EDIT: Just reviewed your Twitter. It's 2000 tweets of snark and criticism of
everything you come across - GoT, other coders, Agile, politics. I doubt we
will get anywhere constructive on this thread but my original post remains
below.

Original post >>

"Doesn't give him the chops or credibility to tell others how to program or
solve problems."

...that cannot be serious. Am actually smiling at that. Also laughing at the
idea that modern coders think they have nothing to learn from Grady Booch.

Plinkplonk you are absolutely someone I would never want on my team or
contributing to a product I was involved in. Aggressive, combative and
dismissive of the precedents that laid the foundations for modern software
engineering. You need to mature (my opinion). Your post has not painted you in
a flattering light.

But feel free to prove me wrong - in your eyes what DOES give someone the
chops to support others with engineering advice? What do they need to have
accomplished?

~~~
plinkplonk
If someone has built significant cutting edge software and/or has proven
himself to be a 1 percent engineer, I'll gladly listen to her _on matters of
engineering_. That doesn't make her an expert on say designing space craft.

The point is Booch hasn't written any cutting edge software. He just sold
methodology (and books and consulting). Which makes him an expert in selling
books and consulting.

I don't want agile gurus/methodology vendors telling me how to do
_programming_. I'll gladly listen to their advice on how to build a career
around a methodology. Just a personal preference.

I mean if I wanted to know how to write a 3d game engine, I'll listen to John
Carmack or Tim Sweeney, not a methodology consultant. If I wanted advice on
investing, I'd listen to someone who has proven chops as an investor - say
Warren Buffet.

again, just my _personal_ preference.

I'll ignore the personal attacks and your comments on my twitter account etc,
which has nothing to do with my comments here and is borderline stalker
behavior.

Whatever floats your boat. All good. This is the internet

~~~
Teeboo
Not borderline stalker; was just interested in your experience. Was hoping you
would blow me away with cutting edge engineering you speak about. _shrug_

Agile vendors don't tell you how to do your job. They tell you how your job
fits within a whole and that whole can be delivered quickly if you play nice
with others.

Not surprised you struggle with the concept given your tone. Clearly not a
growth mindset and fixated only on your technology.

Nice summary of Booch by the way, neatly side stepping his programming
experience and Master's in electrical engineering or his work supporting
design patterns. _eyeroll_

The hate is strong in you.

I would also add, with a little glee, Agile vendors are not going anywhere and
you will be listening to them for a long time to come; you know why? Your boss
listens to them. Don't be bitter at consultants, the game chose them.

~~~
plinkplonk
" They tell you how your job fits within a whole and that whole can be
delivered quickly if you play nice with others."

These guys have no special expertise in this either. They haven't (mostly)
worked on high performance programming teams or led successful companies or
launched killer products. But if you give them a chance they'll try to sell
you 'methodologies' on all these and more.

They make their living selling ill thought out ideas to clueless middle
managers. What makes them experts in "how your work fits into a whole?"

Lol getting a masters in electrical engineering and having written forgotten
books on design patterns makes you an expert in how to 'master programming'
and work in high performance teams? News to me!

Ignoring your personal attacks as usual. Heh.

~~~
Teeboo
You understand Booch did not write the master programming list referenced by
the OP. (No doubt you will edit to remove that erroneous reference but _shrug_
)

Saying Kent Beck, Ken Schwaber, Jeff Sutherland etc has not led successful
companies or worked in high performance programming teams he he he. That's
class.

I hope this post is immortalised :-D

So if Agile is ill-thought out, what is not ill-thought out? By all means, you
have the stage...

