23 ms·

Mastering Programming: An Outline

562 points by KentBeck 10y ago

makuchaku 10y ago
I just noticed, this note is being served by www.prod.facebook.com? Note : ".prod.facebook"
- deleted 10y ago
  [deleted]
- sleepychu 10y ago
  Think dev is called .poke.facebook?
  - makuchaku 10y ago
    Nop, doesn't works. DNS won't resolve.
KentBeck 10y ago
I updated the description of 80/15/5, a career risk management strategy.
- Dangeranger 10y ago
  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.
- igravious 10y ago
  typo: "Beauty if a powerful […]"
- edpichler 10y ago
  About this item, I got me wondering: Should we never delegate a difficult work for someone that is specialist if it give us pleasure? Always we need to learn it first? I don't agree with this, maybe I need profit instead of fun. I can found fun in a lot of other things that I can't delegate on moment. Sorry if I am misunderstanding this part.
bcbrown 10y ago
> 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 10y ago
  I do this with life in general. You soon realise how bad you are at estimating, but it helps you improve.
  - xufi 10y ago
    Agreed. Thats what i'm trying to improve on myself while relearning the technologies I want to learn . As the saying goes "trial and error" .
  - wallace_f 10y ago
    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 :)
- PeCaN 10y ago
  A similar one when dealing with compiled languages with good type systems (Haskell, OCaml, Rust, Mercury) is to periodically build even when your code is broken and try to guess what error the compiler will give. This helped me a lot with those languages.
  - caconym_ 10y ago
    My process in these languages (Haskell I know pretty well, now in the process of learning Rust) is to sprinkle in `undefined`s and `unimplemented!()`s and whatnot so I can continuously use the compiler to check my work without actually running the code. It's a good way to test assumptions and refine a mental model, and it's also just plain useful for catching boneheaded mistakes as you go. I'm not sure if I'd say I use it as a crutch, but I certainly miss it when I have to use languages like ruby and Python.
elliotec 10y ago
I'd like to see this fleshed out more with examples, because I don't really know what some of these mean.
- Teeboo 10y ago
  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 10y ago
    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.
hcarvalhoalves 10y ago
This is a great summary. One could change the title to "Mastering Problem Solving" and it would be just as true.
keyle 10y ago
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.
- tobltobs 10y ago
  > They try most fringe/new technology, ... I would have thought that in area like IT where everything gets reinvented every decade (or less) a master programmer wouldn't have to look at the details to assess a "new" technology.
  - vessenes 10y ago
    I'm no master, but I am middle aged. I like to learn at least one new technology a year; I always learn something from working hands on that I might not have understood just from ideating about it.
  - tomc1985 10y ago
    Agreed; too much commitment. I hate 'trying everything' because I never feel good at anything, and more often than not "new technologies" in this scene are just someone else's old ideas, rehashed and made more complicated. Mastery requires focus.
- andyjdavis 10y ago
  > 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.
shadesof 10y ago
> 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 10y ago
  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 10y ago
    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 ;-)
quincyla 10y ago
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 10y ago
  Good point. Go for it.
partycoder 10y ago
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.
- qznc 10y ago
  The step before the "easy change" is "make change easy". This usually includes refactoring and paying off technical debt. Anecdote from one great programmer I know: When he fixed a single bug, it often came split into multiple commits. First, a few commits refactoring and cleaning up things. Then one tiny commit fixing the bug. Finally, one more commit removing now-obsolete stuff.
- caconym_ 10y ago
  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 10y ago
    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.
kevindeasis 10y ago
(ﾟヮﾟ) 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) ?
riazrizvi 10y ago
How does this drivel get upvotes?
- voltagex_ 10y ago
  What don't you like about it? Is there a better list somewhere? Have some of the tips mentioned there brought you undone at some point and that's why you don't like it?
- deleted 10y ago
  [deleted]
- dang 10y ago
  Please don't post like this here. Comments on HN need to be civil and substantive. If you want to make a criticism thoughtfully, that's fine, but don't call names. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newswelcome.html
- _pmf_ 10y ago
  It's Facebook. If they serve us a nice dish of fresh cow dung, we'll happily discuss taste and texture and which wine goes along with it.
  - dang 10y ago
    Please don't do this here.
sigill 10y ago
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?
- epaga 10y ago
  Great programmers often take a step back and ask themselves whether the problem they are encountering is only a symptom of a far larger problem, e.g. "maybe this entire component needs to be refactored instead of just tweaking these tests." or "maybe when customer asks for X what he actually wants is Y"
- richdougherty 10y ago
  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 10y ago
    Thank you. I was thinking of scale as a measure of order of magnitude and then it didn't make sense.
0mbre 10y ago
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.
- agumonkey 10y ago
  I couldn't upvote this enough. It's even a way of life that is larger than programming. Most of my math issues were about how I didn't really see the extent of a concept or the problem. When done suddenly things become extremely less resistant. Patience, depth, focus, lucidity.
- mercer 10y ago
  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 10y ago
    > notice this pattern in assembling LEGO What do you mean?
    - mercer 10y ago
jondubois 10y ago
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 10y ago
  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.
  - LoSboccacc 10y ago
    yeah many are really important, like the part about 'calling your shot' - I constantly see so many people testing solutions to problem at random, either copy pasted from internet or built using random auto-completion; they spend days and days circling around without ever understanding the changes they're making nor the goal their building towards. It's doubly painful when days after they come up with the random set of lines that produces the intended result and dozen unintended side effects and proudly declare 'see! I did it' the fact is this stuff has been in literature from the seventies. I found very little in this article that couldn't be found in 'code complete' or 'refactorings'. I just wish at some point developers will stop learning everything from scratch.
sleepychu 10y ago
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 10y ago
  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 10y ago
    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.
- delta1 10y ago
  I like this point of view and generally phrase it to myself and colleagues as "Debugging is the process of verifying your assumptions."
JayHost 10y ago
"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?
aryehof 10y ago
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".
mathattack 10y ago
Great outline. Given the source I would like to see it taken down a level of detail in the future.
raarts 10y ago
Old German proverb: In der Beschränkung zeigt sich erst der Meister.
- srik 10y ago
  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-translation-of-goethes.html http://johnirons.blogspot.com/2011/09/work-in-progress-trans...
  - joepvd 10y ago
    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 10y ago
Why prod.facebook.com?
Teeboo 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
        That's a fair challenge and I can accept I might be over-effusive in my praise.
Teeboo 10y ago
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 10y ago
  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 10y ago
    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.
caseymarquis 10y ago
It'd be interesting to compare this to "Ask HN: Habits of the master programmer?"
- spdionis 10y ago
  Why don't you create a new thread then?
  - caseymarquis 10y ago
    Lazy.
sklogic 10y ago
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.
arekkas 10y ago
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 10y ago
  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?
gavinpc 10y ago
"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
jasim 10y ago
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.
yoyo_io 10y ago
www.prod.facebook.com That's new to me.
- ad-hominem 10y ago
  Welcome to Facebook, where you are the product (even in the url)
minusSeven 10y ago
>Rhythm. Waiting until the right moment preserves energy and avoids clutter. Act with intensity when the time comes to act. What does this mean ?
- subie 10y ago
  Measure twice cut once perhaps? That's what I took from it.
- ArkyBeagle 10y ago
  Don't swing 'til the ball gets there. If it can wait, it probably should wait.

562 points by KentBeck 10y ago

makuchaku 10y ago

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

deleted 10y ago
[deleted]
sleepychu 10y ago
Think dev is called .poke.facebook?
- makuchaku 10y ago
  Nop, doesn't works. DNS won't resolve.

KentBeck 10y ago

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

Dangeranger 10y ago
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.
igravious 10y ago
typo: "Beauty if a powerful […]"
edpichler 10y ago
About this item, I got me wondering: Should we never delegate a difficult work for someone that is specialist if it give us pleasure? Always we need to learn it first? I don't agree with this, maybe I need profit instead of fun. I can found fun in a lot of other things that I can't delegate on moment. Sorry if I am misunderstanding this part.

bcbrown 10y ago

> 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 10y ago
I do this with life in general. You soon realise how bad you are at estimating, but it helps you improve.
- xufi 10y ago
  Agreed. Thats what i'm trying to improve on myself while relearning the technologies I want to learn . As the saying goes "trial and error" .
- wallace_f 10y ago
  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 :)
PeCaN 10y ago
A similar one when dealing with compiled languages with good type systems (Haskell, OCaml, Rust, Mercury) is to periodically build even when your code is broken and try to guess what error the compiler will give. This helped me a lot with those languages.
- caconym_ 10y ago
  My process in these languages (Haskell I know pretty well, now in the process of learning Rust) is to sprinkle in `undefined`s and `unimplemented!()`s and whatnot so I can continuously use the compiler to check my work without actually running the code. It's a good way to test assumptions and refine a mental model, and it's also just plain useful for catching boneheaded mistakes as you go. I'm not sure if I'd say I use it as a crutch, but I certainly miss it when I have to use languages like ruby and Python.

elliotec 10y ago

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

Teeboo 10y ago
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 10y ago
  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.

hcarvalhoalves 10y ago

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

keyle 10y ago

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.

tobltobs 10y ago
> They try most fringe/new technology, ... I would have thought that in area like IT where everything gets reinvented every decade (or less) a master programmer wouldn't have to look at the details to assess a "new" technology.
- vessenes 10y ago
  I'm no master, but I am middle aged. I like to learn at least one new technology a year; I always learn something from working hands on that I might not have understood just from ideating about it.
- tomc1985 10y ago
  Agreed; too much commitment. I hate 'trying everything' because I never feel good at anything, and more often than not "new technologies" in this scene are just someone else's old ideas, rehashed and made more complicated. Mastery requires focus.
andyjdavis 10y ago
> 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.

shadesof 10y ago

> 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 10y ago
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 10y ago
  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 ;-)

quincyla 10y ago

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 10y ago
Good point. Go for it.

partycoder 10y ago

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.

qznc 10y ago
The step before the "easy change" is "make change easy". This usually includes refactoring and paying off technical debt. Anecdote from one great programmer I know: When he fixed a single bug, it often came split into multiple commits. First, a few commits refactoring and cleaning up things. Then one tiny commit fixing the bug. Finally, one more commit removing now-obsolete stuff.
caconym_ 10y ago
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 10y ago
  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.

kevindeasis 10y ago

(ﾟヮﾟ) 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) ?

riazrizvi 10y ago

How does this drivel get upvotes?

voltagex_ 10y ago
What don't you like about it? Is there a better list somewhere? Have some of the tips mentioned there brought you undone at some point and that's why you don't like it?
deleted 10y ago
[deleted]
dang 10y ago
Please don't post like this here. Comments on HN need to be civil and substantive. If you want to make a criticism thoughtfully, that's fine, but don't call names. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newswelcome.html
_pmf_ 10y ago
It's Facebook. If they serve us a nice dish of fresh cow dung, we'll happily discuss taste and texture and which wine goes along with it.
- dang 10y ago
  Please don't do this here.

sigill 10y ago

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?

epaga 10y ago
Great programmers often take a step back and ask themselves whether the problem they are encountering is only a symptom of a far larger problem, e.g. "maybe this entire component needs to be refactored instead of just tweaking these tests." or "maybe when customer asks for X what he actually wants is Y"
richdougherty 10y ago
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 10y ago
  Thank you. I was thinking of scale as a measure of order of magnitude and then it didn't make sense.

0mbre 10y ago

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.

agumonkey 10y ago
I couldn't upvote this enough. It's even a way of life that is larger than programming. Most of my math issues were about how I didn't really see the extent of a concept or the problem. When done suddenly things become extremely less resistant. Patience, depth, focus, lucidity.
mercer 10y ago
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 10y ago
  > notice this pattern in assembling LEGO What do you mean?
  - mercer 10y ago

jondubois 10y ago

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 10y ago
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.
- LoSboccacc 10y ago
  yeah many are really important, like the part about 'calling your shot' - I constantly see so many people testing solutions to problem at random, either copy pasted from internet or built using random auto-completion; they spend days and days circling around without ever understanding the changes they're making nor the goal their building towards. It's doubly painful when days after they come up with the random set of lines that produces the intended result and dozen unintended side effects and proudly declare 'see! I did it' the fact is this stuff has been in literature from the seventies. I found very little in this article that couldn't be found in 'code complete' or 'refactorings'. I just wish at some point developers will stop learning everything from scratch.

sleepychu 10y ago

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 10y ago
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 10y ago
  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.
delta1 10y ago
I like this point of view and generally phrase it to myself and colleagues as "Debugging is the process of verifying your assumptions."

JayHost 10y ago

"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?

aryehof 10y ago

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

mathattack 10y ago

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

raarts 10y ago

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

srik 10y ago
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-translation-of-goethes.html http://johnirons.blogspot.com/2011/09/work-in-progress-trans...
- joepvd 10y ago
  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 10y ago

Why prod.facebook.com?

Teeboo 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      That's a fair challenge and I can accept I might be over-effusive in my praise.

Teeboo 10y ago

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 10y ago
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 10y ago
  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.

caseymarquis 10y ago

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

spdionis 10y ago
Why don't you create a new thread then?
- caseymarquis 10y ago
  Lazy.

sklogic 10y ago

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.

arekkas 10y ago

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 10y ago
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?

gavinpc 10y ago

"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

jasim 10y ago

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.

yoyo_io 10y ago

www.prod.facebook.com That's new to me.

ad-hominem 10y ago
Welcome to Facebook, where you are the product (even in the url)

minusSeven 10y ago

>Rhythm. Waiting until the right moment preserves energy and avoids clutter. Act with intensity when the time comes to act. What does this mean ?

subie 10y ago
Measure twice cut once perhaps? That's what I took from it.
ArkyBeagle 10y ago
Don't swing 'til the ball gets there. If it can wait, it probably should wait.