(Apologies for the developer-centricness of this post)
“Go out and get your hands dirty!”, “The best way to learn programming is to program!”, “Just build something!”.
This advice is often directed towards people who have yet to ship a product or service. To some, it’s perfect advice. To others, it may be a mistake.
Concept vs Execution, and that Big Gap in between
I think the main factor is where you are on the concept-execution-continuum (CEC). Specifically, the advice above is gold for those right at the gap.
This is because conceptual work is inherently foreign, and is learnt through the process of gradual osmosis. On the other hand, contextual work means applying what you know to a current problem; it assumes that you have the knowledge to do so.
Fortunately, conceptual understanding is oftentimes accelerated by actually having an example/problem to work with.
To put things in more concrete terms, someone who is starting out with Git will have to understand how Git branches and merges work instead of trying to endlessly commit to the master repo.
The issue is that a lot of the time, no one is going to tell you that you’re doing it wrong. I’m just as guilty as anyone else of picking up idiosyncratic bad habits that fail to go away. Taking the time to consult with someone more experienced usually trumps running in headlong yourself.
However, there are some areas which demand a thorough conceptual understanding before even beginning to delve further.
One such example is writing concise Mathematical proofs. The first introduction to an epsilon-delta proof often leads to mass confusion. Even if you can graphically represent the epsilon-delta definition of the limit, there’s this huge gap between seeing that image in your head and writing down the proof to a new problem.
When it comes to complex software design, we are faced with exactly this scenario. Like it or not, you can’t just dive into shell scripting, you have to conceptually “get it”, which only comes after many months of acquiring the necessary technical background.
Bradford Cross described it best in his post ‘Learning About Machine Learning – 2nd Edition’ , where he says,
“The caveat is that you need to be honest with yourself about when you encounter something that you do not understand and you are unable to work through despite trying your best. At this point you’ve found your way to some material that you do not have the foundation for. Put the book down, insert a bookmark. Close the book. Walk away. Go find a resource to build the foundation. Come back later. Repeat.”
Why Bother WIth all this rambling anyway?
If you intend to make a mark with your software at a large scale, you’re bound to run into complex issues that require deep technical understanding of your domain.
Some people have gotten there simply by trying and failing, but more often than not, these people are outliers. There are some people who just “get it” when they see a squiggly mathematical equation. And more often than not, this affinity for the task leads to a propensity to put the hours in.
In short, these people are smarter than most of us and have put in way more hours to their work than most of us.
The rest of us need a strategy. Specifically, we need the patience to let ideas sink in, while constantly striving to understand the fundamentals. Like it or not, the slowest way initially (grokking the fundamentals) is the fastest way eventually.
The Brain Keeps on Working
The surprising thing is, you may be further along the conceptual line than you think.
For those who have struggled with math, I’m sure you’re familiar with the feeling of frustration, when you’re just unable to see why and how these squiggly formulas work together to form a solution. Countless numbers of examples and clarification don’t help either.
That’s were most people (and sadly, teachers) give up. But some people continue reading and digesting the material. They may not spend a lot of time with it, but it’s certainly not being relegated to the bottom of their thinking stack.
Then a couple of days later, they see another example of the formulas in action, and suddenly, everything clicks.
The brain works 24/7 on problems higher up on the thought heirachy. The trick is then to constantly ensure that the important concepts retain that high-up position.
It usually can’ be Rushed
Trying to accelerate this process seems to suck in general. Rushing into epsilon-delta proofs yields sloppy assumptions and procedural memorisation; you know what you’re doing, but you don’t know why.
That’s not too big of an issue for passing math exams, but when it comes to building complex software, you need to start off on the right track if you’re intent on staying sane through the inevitable debugging sessions and server failures.
So what should I do now?
I still think that we should jump on opportunities when they present themselves. But I also think that we should have the discipline to see how complex a problem truly is, and have the professionalism to back away when we know something’s temporarily out of our reach.
So start on what you know. But always bear in mind the conceptual gap and slowly attempt to close it.
Final Words
Those who succeed in executing a successful product or service are either close to, or beyond that concept-execution gap. They have a good grasp of their tools, and oftentimes a good dose of domain expertise as well.
Developers often take for granted how long it took them to master their toolset. Everything from mastering emacs (or vim, but not textmate), to understanding the flow of git, to recognising weaknesses and integration in APIs, is necessary to write good code and ship good products.
That said, we’ve seen many people write sloppy code while still being able to please their customers. They usually pay for it with a high level of stress, but they suck it up, and arrive on the other side wiser. For some people, this may be the preferable, and maybe even necessary path (especially if money is really tight).
And then there are people like Marcus Frind, whose understanding of his server architecture has led to some astounding scalability miracles at Plenty of Fish.
As a personal preference, I’d like to be in that latter crop of developers, and so, I’m biding my time to learn the ropes while tinkering with what I can. Though I’ve got nothing yet to show, I certain have my covert ops waiting to be unleashed!
—
Get the PDF or the Print to view the concepts more clearly!
{ 0 comments }
