Being a programmer is not about knowing how to write code and learning an application framework. Application frameworks have a tendency to lead newcomers to miss the point, and stall their journey just as it’s getting interesting.
Writing code with a framework is a great place to start, and can achieve impressive results. However, the relative ease of working within a framework, and perhaps especially the impressiveness of the results, can make the next steps seem daunting.
It’s important to remember that application frameworks provide a structure that is designed, maintained and cared for by intermediate and advanced level programmers.
They are taking care of the gnarly details of the application, so that only the code for a particular implementation needs to be written. You don’t need to write the code that makes that type of application a reality.
This is all well and good. Awesome in fact. I love frameworks and work with them all the time. I’ve designed and developed frameworks. They are useful, important and helpful.
But it’s important to remember that the hardest part of the work is being done for you. You are essentially configuring an existing application, adding the behavioral details for a particular implementation.
In terms of your learning process, this can be detrimental.
Application frameworks, along with other high level libraries, are so high level, that the results can lead newcomers to feel that they are programming, while it is more accurate to say they are configuring the work of others. They are newcomers riding on the shoulders of more experienced programmers.
Forgetting that, or not being aware of it, can lead to giving yourself credit for the programming to produce an app, when in reality you did only a small portion of the work, and it was the easiest part.
This can lead to a perception that it is an end to the journey of becoming a programmer, while in truth it is only the beginning.
It doesn’t become clear to you unless you’re an experienced programmer. Even then, you might not have thought about it. But being a programmer is not about writing code. You learn to write code, but after that you stop thinking about it. It just happens. It’s not what programming is about.
Allow me an analogy to help illustrate this, if you will.
Experienced chess players know that the first thing you learn is how to move the pieces around the board. You learn that the bishop moves diagonally, the king moves one space in any direction, knights are funny and move in a special way etc.
There are some caveats to the way the pieces move around the board, and it takes some time to learn. But after you’ve played a few times, you don’t think about it very much. After a while, you don’t think about it at all.
Once you get past the beginner stage, you no longer need to think about the way the pieces move around the board. You no longer need to think about the mechanics of the game. You just know where the pieces can move when you look at them. You don’t need to think, “can the bishop move more than one space?”
These thoughts have to leave for you to advance to being an intermediate level player. There is too much else to think about at the intermediate level for you to still be thinking about the mechanics. You have to just get that.
Once you get past being a beginner, playing chess is not about how the pieces are moved around the board. Playing the game is about strategy, tactics, concentration, study, memory, endurance, commitment, politics, and interpersonal skills to name a few.
Programming is no different, although some of the skills are. Once you have been programming for some time, often years, you will no longer need to think about how the syntax works. Any changes or new developments in the syntax will be quickly absorbed.
Programming becomes about the structure of the code you are working with, the interfaces you design that enable modularity and make your code reusable, how you will separate out the responsibilities in order to best support the needs of your application and not lock in approaches that could hinder future developments. How you will make it testable.
And the learning process never ends.
Application frameworks take care of the vast majority of these decisions for you, and can make it easy to be sloppy with those decisions within the code that you do need to design, as they are limited in scope and protected by the structure of the application framework as a whole.
Sure, you can still make a big mess of it, and this is not to suggest that application frameworks remove all of the complexity, or that working with them isn’t programming. The point here is to illustrate that there is a tendency to shield you from the hard stuff, which can lead to avoiding learning it. Being aware of this means it can be addressed.
When working in an application framework, programming becomes about being aware of the decisions made by the framework, and how best to work within them. Being able to have made those decisions yourself, and understanding why, helps you to work with them more effectively, especially as your applications grow in size.
So what can be done?
Spend some time building software from scratch.
Move away from application frameworks and libraries in your personal projects and build things yourself.
Design your own class hierarchies. Build a set of reusable modules to solve a particular problem. Work directly with databases. Create a web app from scratch. Parse JSON by hand. Get involved in open source projects. Learn functional programming. Create some algorithms. Automate some common tasks. Make some cool things happen. Take things apart and put them back together again. Don’t be afraid of making a mess.
Learn from Martin Fowler, Kent Beck, Dave Thomas.
Whatever works for the space you’re in. Find what works for you. Push your limits, list the areas you’re aware of but don’t understand, study and talk with others. Keep learning.
Having this experience will feed in to your work with application frameworks and make you a better programmer.
I hope this was useful. It’s certainly a simplified take on things, and done to highlight an important issue that I see often while mentoring.
Thank you for reading, and enjoy the journey!