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.
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.
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.
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.
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.
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.
There's a balance though because I learn a lot by DOING, I can only read/learn/think about something so much before it just gets fuzzy and I can't keep anymore in my head.
I agree. I actually think it's the single most important skill for beginner to intermediate programmers. Not structuring the code or managing complex abstraction, just having a reliable mental model of the program and the environment.
I've often seen beginners struggle because they get so used to the compiler or the (often manual) tests catching errors that they just try things "to see if they work" without understanding what they're trying. But they don't consider two important questions: "what do you want to happen?" and "what do you expect to happen?".
If you can answer both of those, you can figure out whether your code will work before you write it. In many cases when programmers struggle it's because they don't know the answer to one or both. They're left just trying stuff until something works, but there's a lot more things that don't work than things that do, and a lot more bad solutions than good ones.
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.
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.
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
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 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 also is an intriguing story.
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].
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.
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?
(ﾟヮﾟ) 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) ?
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".
"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]
[+] [-] keyle|9 years ago|reply
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|9 years ago|reply
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.
[+] [-] tobltobs|9 years ago|reply
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.
[+] [-] 0mbre|9 years ago|reply
[+] [-] mercer|9 years ago|reply
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.
[+] [-] agumonkey|9 years ago|reply
[+] [-] therealdrag0|9 years ago|reply
[+] [-] ry_ry|9 years ago|reply
To continue the theme - When the only tool you have is a hammer, every problem looks like a nail.
[+] [-] ry_ry|9 years ago|reply
[deleted]
[+] [-] therealdrag0|9 years ago|reply
[deleted]
[+] [-] bcbrown|9 years ago|reply
That's probably my favorite bit of advice. It really helps with understanding how much your assumptions diverge from reality.
[+] [-] sgentle|9 years ago|reply
I've often seen beginners struggle because they get so used to the compiler or the (often manual) tests catching errors that they just try things "to see if they work" without understanding what they're trying. But they don't consider two important questions: "what do you want to happen?" and "what do you expect to happen?".
If you can answer both of those, you can figure out whether your code will work before you write it. In many cases when programmers struggle it's because they don't know the answer to one or both. They're left just trying stuff until something works, but there's a lot more things that don't work than things that do, and a lot more bad solutions than good ones.
[+] [-] dmolony|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] sargas|9 years ago|reply
[+] [-] mathattack|9 years ago|reply
[+] [-] aphextron|9 years ago|reply
[+] [-] PeCaN|9 years ago|reply
[+] [-] shadesof|9 years ago|reply
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
[+] [-] endgame|9 years ago|reply
[+] [-] elliotec|9 years ago|reply
[+] [-] Teeboo|9 years ago|reply
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.
[+] [-] KentBeck|9 years ago|reply
[+] [-] Dangeranger|9 years ago|reply
[+] [-] edpichler|9 years ago|reply
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.
[+] [-] igravious|9 years ago|reply
[+] [-] sleepychu|9 years ago|reply
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
[+] [-] delta1|9 years ago|reply
[+] [-] sklogic|9 years ago|reply
Good luck asserting these assumptions and factoring them in your designs.
[+] [-] jasim|9 years ago|reply
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 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 also is an intriguing story.
[+] [-] sigill|9 years ago|reply
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?
[+] [-] quincyla|9 years ago|reply
Otherwise, these points are difficult to contextualize, retain, and apply.
[+] [-] jonathantm|9 years ago|reply
[+] [-] arekkas|9 years ago|reply
I aknowledge what Kent Beck has done and what facebook is doing but this doesn't deserve to be on HN front page.
[+] [-] dasil003|9 years ago|reply
[+] [-] kevindeasis|9 years ago|reply
[+] [-] aryehof|9 years ago|reply
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|9 years ago|reply
[+] [-] sleepychu|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] gavinpc|9 years ago|reply
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
[+] [-] JayHost|9 years ago|reply
How about just put in the work and learn the hard way?
[+] [-] minusSeven|9 years ago|reply
What does this mean ?
[+] [-] ArkyBeagle|9 years ago|reply
[+] [-] subie|9 years ago|reply
[+] [-] hcarvalhoalves|9 years ago|reply
[+] [-] mathattack|9 years ago|reply
[+] [-] caseymarquis|9 years ago|reply
[+] [-] spdionis|9 years ago|reply