The Five Core Activities of a Software Dev
Last week I went through how to start thinking like a developer. #
This week will be focused on one of any programmer’s primary activities: maintaining a technical edge.
What happened this week? #
I'm dropping the snapshot approach. It's no longer useful!
I also came across a fascinating concept of proportion. The success of a given process is an emergent property dependent only on the presence of all required elements working in tandem, and if any one of those elements is missing everything falls apart.
Immediately, I pondered how this could apply to the profession of programming.
What are the essential elements of coding? #
Whenever I go from abstract concepts to practical application, I worry I sound ridiculous. Like this.
Didn't know Apple was into male modeling
But I really do think there’s a formula, a way to diversify your time portfolio, which brings about the greatest opportunity for success.
A programmer’s time must be split between these activities over the long term:
- Solving problems worth money to people (be it a job or app, you gotta pay the bills)
- Finding problems worth solving.
- Technical Learning (skills that become obsolete in 1-3 years).
- Non-technical learning (skills which, once acquired or improved, are valuable forever).
- Learning to learn.
Both technical learning, and learning to learn, are part of what I call the “technical edge.”
The “Technical Edge” #
Versions, frameworks and languages come and go. In order to remain relevant, I have to make sure to dedicate time to learning new technologies. There’s far more being created than is feasible for one person to learn, so the question becomes, “What do I choose?”
There are two principles which you can use to answer this question for yourself: 1. What solves problems in new and better ways? 2. Would learning X be an optimal use of time?
There’s absolutely no reason to move away from something that’s solid and working to something new if the new thing can’t improve upon the existing solution. So when a new technology comes out, figure out what it’s improving. If you can’t, or it’s not obvious, then it’s probably better not to invest time into it.
Best way to choose what to learn #
Look for whatever gives you small wins immediately. Large breakthroughs are created through the force of small wins puncturing through the mental and technological frameworks, leading to the next big iteration where you have that “This is such a better way of doing things!” moment.
If you are one of the LaunchCode hopefuls you might grasp at the meaning of this advice, but it won’t truly make sense unless you’re solving problems.
Once you’ve identified a language, framework or methodology worth learning, there’s another assessment to make.
Learning quickly, and learning well #
How long does it take you to read a technical book? How quickly can you actually start solving problems in the new framework or language?
Can you attack a chapter, abstract all the useful bits out and apply them immediately?
Learning is a skill like any other.
Here’s where there’s an interesting tradeoff. Learning is a skill like any other. You can learn to learn faster, decreasing the amount of time required over the long-term but increasing it in the short-term, or vice-versa.
Activities involved in learning to learn include speed-reading, practicing the development and application of conceptual models, utilizing memorization techniques, etc. And of course, just the act of learning one technical area deeply will make the next time you go through this process a bit shorter for every time thereafter.
The “learning to learn” approach incurs a higher startup investment of time than just diving straight in and learning the same old way you always have, but the end results have been worth the effort for me.
However, everyone is different and this approach to learning new skills might not be the best fit for you.
So I guess the ultimate answer is,
Next week, I'll go over exactly how to go about teaching yourself Ruby on Rails.