This is about big impossible problems. Problems which you wish you could solve or can only dream of being a part of. We as programmers want to be a part of this. We want to be able to solve that big problem and we want it now.
The secret sauce to solving more problems is preparation. Preparation is learning what is needed to solve a problem. It is gathering all the prerequisites to solve a problem. Have all the prerequisites and voila, the problems becomes solvable.
The best thing you can do is set up your environment to require the least preparation but prepare anyway. This is why we have to specialize. This is why we have to choose a niche, a specific way of programming. It makes us able to solve those types of problems because they share the same prerequisites.
Your goal as a programmer should be to plug up as many unknown variables/prerequisites in all of your problem solving for your niche. When we learn something like web development we become able to solve more web problems. When we learn more graphics programming, we get more of the same problems unlocked.
That is how you solve impossible problems, you plug first the prerequisites.
Table of Contents
Test the framework
As programmers we should always try to find the best tool for the job. Within my set of libraries and frameworks first I always delay my final decision of framework or language.
Before I make the final decision I test the frame for 4 factors:
- Community support
- Having a team
- Online resources
- Ease of the framework
All 4 of these should be as high as possible when choosing a framework for a problem.
We need expert friends, a team of good people programmers. We need online resources and we need the optimal framework. We need people who are passionate experts as our friends, constantly vetting the doors of friendship and teamwork.
Sounds harsh, I know, but that is how the best coding projects are made. You create a Discord server, invite a bunch of programmers and seek out the best ones.
You yourself become the best you can be, plugging your prerequisites one at a time until one day you can solve those bigger and better problems.
Solve for the goal not the tool
This is how I advocate for picking your first language. It should be for a set of similar problems you want to solve. For example, graphics programming and web development. Both of these have capabilities in all languages. OpenGL and HTTP frameworks are the tool.
Thankfully in those fields you can choose whatever language you want, as long as you use the same framework, OpenGL or HTTP Frameworks. After this its more about picking a team and choosing your language based on your community.
But, for something like Machine Learning. The tool only comes in several options.
#1 R
#2 Python
#3 C++
But, do you really want to do machine learning in C++? Like, really? It is a much more fuzzy language compared to Python. For a beginner in machine learning we should prioritize the tool, Python.
At one point in the past, I wanted to make an internet browser in Java. But, I had no idea how browsers are made. I discovered it was near impossible to efficiently create a decent browser in Java for me in my current state.
I was using chromium as an embed in Java swing. But, the hooks going into chromium we’re not supported by any third party library or API. I would have to code the entire process by myself and in addition use lower level Java to customize the appearance of the browser.
It would have been an uphill battle with more and more challenges and the requirement of me making my own framework and API for chromium in Java.
What I discovered later was that this already existed in JavaScript. It is called Electron. It is the ability for you to create your own custom browser using a framework and API for doing so. That is essentially what a browser is. It is the API that communicates with a browser kernel.
Kernels like Blink, Chromium, trident and many more are simply wrapped by all these browsers from Chrome to Opera. Shall I build the wheel and create my own API or buy a tire and work from existing APIs. I tell you by principal, most people should buy the tire.
Electron is free and there are many browsers out there built on it. Had I chosen to create an API for a kernel it would have been many hours and head banging in Java.
It would be cool and innovative and one of a kind but no, not worth it.
Projects like WaterFox, Opera or other open source browser communities would be better options.
I could try to recreate this. But no, I won’t. Instead I would join a team and become a part of a bigger solution.
I have applied that analogy to many programming problems and have been able to solve more than ever because I focus on the big picture, using these code sources as references.
How to solve your sub-problems
After joining a team or leading a team you must break down that huge impossible problem into smaller solvable problems.
This is where your progress is made. Often in these situations the team exists for motivation only.
Presently, I love following a project called Spartan Engine. It is a community striving to create a game engine free and open source.
The leader of the team has created epic efficient rendering, scene saving and object manipulation.
But, missing features include a scripting API and feature specific implementations such as clothes and custom components.
A sub problem solvable by me is the scripting engine, an API for the core engine.
In this community a scripting API is highly sought out and needed for the engine.
No one in that entire community can help me create it. They would simply be there to encourage me.
Pick source references
When we are in a team solving an impossible problem, like a game engine, we use a large set of other code sources. Sources which act as a guide for how we implement specific features.
Our leader, Panos, reads other engine code all the time with much inspiration. We look at Godot’s, Ogre’s, Flax engine and many more, exploring their features and seeing how we can implement them.
To solve a problem like adding scripting, I would read Unity’s API life cycle, Godot’s Gdscript lifecycle and try to implement my own based on how these work.
I piece the best features of each and create my own, all in my own code. That is the typical path of development, the first time you do it.
Then afterwards we focus on a refactor and improvement. We are plugging up the prerequisites until we become our own leader in the impossible problem of game engine development.
This methodology,
- Choose a needed sub problem
- Look at other solutions
- Implement your own
- Refactor
Works for all sub problems and leads to filling more prerequisites.
Pick fodder problems
Choosing fodder projects is dirty business.
Sometimes we must create fodder sub problems. Issues which are not needed but we implement anyway.
For Spartan Engine that fodder problem would be creating an OpenGL implementation of the renderer (They use DirectX).
In my other project, Darkan, it would be a cache editor or CS2 Editor. No one would really use this stuff and it barely helps the project.
But these fodder projects would help me understand Spartan or Darkan and the code libraries they use.
Fodder helps me fulfill the prerequisites, plug those requirements.
I have done many fodder projects in the past. I would choose them based on what I need.
I identify the prerequisite then creatively come up with fodder.
For example, with Spartan Engine, I understood none of the code when I joined.
I hardly knew C++ and I hardly knew rendering, never mind rendering in C++.
How would I go about solving this impossible problem of Spartan Engine?
Well I started two fodder projects while hanging out in the Discord. 1st I want to finish a C++ masterclass on Udemy. That is fodder #1. #2 is going through an OpenGL blog in C++.
OpenGL is considered a great framework for learning basic rendering. Fodder #3 after the blog and Udemy course was rendering in a GUI framework, the same one used by Spartan Engine.
Slowly I piece meal my requirements for contributing to Spartan Engine.
What was my motivation? The team. I would hang out in the Discord voice chat and talk to the other developers, then fulfill my fodder requirements.
Eventually, after a few months I was able to make contributions to the engine and even start on scripting.
Ask around
The entire time I was fulfilling my requirements for my niche I was asking other developers questions.
Things that seemed arcane, mystical that needed explaining. How can I do X with Y. Where can I find a solution or article that explains some specific issue.
Summary
All this advice I am giving you, asking around, fodder projects, joining a team, picking a proper framework, it applies to ALL problem solving in code.
Someone like the Spartan Engine leader, Panos, has fulfilled so many requirements in graphics programming over years, he is able to solve any problem in any language in that niche.
That is the goal. The goal is to become a master at a niche. It takes much fodder, much prized implementation and a community to make it happen.
Anywho, I hope you learned something…
CTA: Check out my book on learning code
Happy coding!
Resources
6 Rules of Programming: https://jessenerio.com/6-easy-rules-coders-should-follow-to-learn-to-code-faster/
