Sadly just an outline but I didn't mind that. Good read.<p>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.
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.
> Call your shot. Before you run code, predict out loud exactly what will happen.<p>That's probably my favorite bit of advice. It really helps with understanding how much your assumptions diverge from reality.
> When faced with a hard change, first make it easy (warning, this may be hard), then make the easy change.<p>This is my favorite bit. Katrina Owen mentions this in her talk on refactoring. "Make the change easy; then make the easy change."<p><a href="https://www.youtube.com/watch?v=59YClXmkCVM" rel="nofollow">https://www.youtube.com/watch?v=59YClXmkCVM</a>
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.<p>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.<p>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.<p>The best I have so far come across in a book is "Coders At Work". <a href="https://github.com/aosabook/500lines" rel="nofollow">https://github.com/aosabook/500lines</a> 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. <a href="http://damienkatz.net/2005/01/formula-engine-rewrite.html" rel="nofollow">http://damienkatz.net/2005/01/formula-engine-rewrite.html</a> 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.<p>Then there's stuff I just don't understand. For example:<p>> 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].<p>What does he mean by scales?
There is wisdom behind these bullet points. This wisdom could be better communicated through a series of fleshed-out articles with real life examples.<p>Otherwise, these points are difficult to contextualize, retain, and apply.
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.<p>I aknowledge what Kent Beck has done and what facebook is doing but this doesn't deserve to be on HN front page.
(ﾟヮﾟ) 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.<p>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.<p>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<p>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]<p>[0] <a href="https://www.youtube.com/watch?v=rI8tNMsozo0&t=9m49s" rel="nofollow">https://www.youtube.com/watch?v=rI8tNMsozo0&t=9m49s</a>
"Move fast and break stuff
abstract stuff and build quick
Move Fast With Stable Infra"<p>How about just put in the work and learn the hard way?
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.<p>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.<p>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.<p>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.<p>Programming is an adaptive skill and should change based on economic/scale requirements.
While the author is known (technical coach at Facebook, creator of XP software methodology), I sort of disagree.<p>You can follow this guide and still be a low value programmer. This guide won't take you to mastery level.<p>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.
Despite hating anything XP, I can strongly relate to this one:<p>> When faced with a hard change, first make it easy (warning, this may be hard), then make the easy change.<p>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.
What? Seriously, what?<p>What argument are you making here? Boxing / Ali was an analogy to demonstrate the widespread respect of the engineering community that KB has earned.<p>/awkward<p>To be clear; my post was not about you being boxer.<p>/awkwardoff
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.<p>Original post >><p>"Doesn't give him the chops or credibility to tell others how to program or solve problems."<p>...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.<p>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.<p>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?