× {{alert.msg}} Never ask again
Get notified about new tutorials RECEIVE NEW TUTORIALS

Focus on How, Not What

Jonathan Eunice
Jan 19, 2015
<p>Many mentorships seem to begin with “What web app framework should I use?” Or what DBMS, ORM, JavaScript and/or CSS framework, asset-build system, test harness, source code control system, cloud server…</p> <p>The question is very understandable. People are piratical and impatient. We want to get going, quickly. <em>Now!!!</em> We want immediate results. Yet the question usually also falls somewhere between “premature” and “complete nonsense.”</p> <p>How can I <em>possibly</em> know what specific technology or implementation best suits a task’s needs before we’ve spent any time discussing the task; your environment, skills, and other realistic constraints; or what tradeoffs you find acceptable and unacceptable? Do you imagine there is just one possible answer? One clearly and unimpeachably “best” solution? There isn’t. There are usually at least a few choices that are all popular, well-supported, and completely apposite. In some cases, there are dozens.</p> <p>But the gross improbability of identifying a good choice based on only the most loosely-stated desiderata—that isn’t even the big problem here. The bigger issue is that those asking the question often don’t understand enough about the problem to properly consider what would make a good or bad choice. They have no real “<a href="http://en.wikipedia.org/wiki/Frame_of_reference">frame of reference</a>.” No “reference level.” They’re going on product names they’ve heard someone mention, or techniques they saw in some Google result or Stack Overflow post.</p> <p>I’m not criticizing you, Dear Questioner. When I’m exploring a new area, I do the same thing. “What’s best?” is the most natural of questions. It’s just not the best one.</p> <p>A better question is “How can I do this thing I want to do?” As much as possible, you should focus on the problem you want to solve, or the skill you want to gain, and let the tool choices follow. Focus on the <em>how</em>. Build skill. Build a <a href="http://en.wikipedia.org/wiki/Software_prototyping">prototype</a>. Built it to be fast, ugly, and only good enough teach you how to do the task better—something you will throw away when done.</p> <p>If you choose tools first, and learn only about those, and insist that your initial efforts lead directly to your production code, then you’re probably not not making the best tool choices. Worse, you’ll be building your novice errors, understanding, and expectations into code that you’ll be living with for a very long time. A lot of the best, most powerful tools for advanced users are not very good for, friendly to, or approachable by, beginners. It’s not realistic to start kids or novices on time-trial bikes and fixies. At the same time, that banana-seat bike with training wheels that was so amazingly fantastic when you were five is not going to seem so cool when you’re a teenager, and it’s going to be downright terrible if you become a cycling athlete.</p> <p>Focus instead on the <em>how</em>. Build skills and understanding you can apply to whatever tools you use initially, but that can also transfer to other tools you might choose once you have a deeper understanding, or when your needs change. Instead of “What should I use?” focus on “How should I do this?”</p>
comments powered by Disqus