Almost weekly, a friend or acquaintance asks me, “I want to learn how to code; which language should I start with?” More or less every two weeks I get a DM on LinkedIn that starts with: “My son should get into programming; what is the best language for him?”
It’s not just people who have never coded before. Often I get these messages from people who have several years of coding experience.
I’m not saying this to complain.
Join TNW in Valencia!
The heart of technology comes to the heart of the Mediterranean
I make my living sifting through the pros and cons of various programming languages, frameworks, and AI models here on Medium. I benefit greatly from people with such questions.
The questions are quite intuitive. After all, everyone wants to work with the best possible tools and build their software skills as quickly as possible.
And when you see that every developer seems to be using a different technology stack, it makes perfect sense to wonder which one is the right one.
The thing is, it all depends on the problem at hand.
No technology in itself is good or bad; it just depends on what kind of problem you want to solve. In the end, programming is just that: solving problems with the help of a computer.
So for people who want to get into programming or improve their software development or data science skills, the question shouldn’t be “What should I use?” Python or Juliet?” The question should be, “How can I better solve software problems?”
How to solve problems
For full disclosure, I am not a computer scientist by profession. I’m a particle physicist who happens to be using concepts from programming and data science because I’m dealing with massive amounts of data from particle accelerators.
That said, physicists are just as much in demand as computer scientists. It’s not because of their knowledge of neutrinos or black holes; it’s because of their problem-solving abilities.
Abraham Lincoln is said to have said, “Give me six hours to cut down a tree and I’ll spend the first four hours sharpening the ax.”
For programmers and data scientists, this means spending time understanding the problem and finding high-quality solutions before they start coding. In the average coding interview, candidates are expected to spend less than half their time actually writing code and the rest of the time understanding the problem.
1. Understand the problem
Never skip this step!
The key to understanding a problem is being able to explain it to someone unfamiliar with it. Try writing it in plain English or your native language; draw a small diagram; or tell a friend. If your friend doesn’t understand what you’re talking about, go back to the problem statement.
Important questions to ask are:
- What is the input? What is the desired yield?
For example, the input could be a series of data and the output could be a linear regression on the data.
- What assumptions underlie the problem?
For example, you assume that there is (almost) no measurement error in your data.
- What complicates this problem?
For example, the data you have may be incomplete or the data set may be too small to draw firm conclusions.
2. Solve the problem
Every big problem consists of many smaller problems. Considering our previous linear regression example, consider the following sub-problems:
- Clean up the data
- Finding out which variables in the data are meaningful to the regression, and which can be safely ignored
- Finding the right tool to run the regression with (this is where the old question about programming languages and frameworks comes in)
- Evaluate your results and bug-check
Breaking down the problem will help you make a good plan for your work.
It’s also more motivating, as you hit small but significant milestones along the way. This is much more satisfying than sitting in front of a mountain of work and feeling like you’re not moving forward.
3. Start with an example
The devil is always in the details.
Instead of starting with the whole project, take a small piece of it. Try to see if your plan works, or if you need to adjust it due to unforeseen difficulties.
This will help you get your head around the hard parts. Many problems sound simple, but when you start building them, one roadblock comes after another.
In our example, instead of using all relevant variables, one could first perform a linear regression on a number of variables. This does not earn you points for completing the project; however, finding bugs in your scripts while still dealing with a small amount of data can be a life saver.
If you throw all your data at the machine, let it run for hours, and then come back to realize the script has hung half way through, you’re going to be very frustrated.
Believe me, this happens a lot!
Run small tests first and make sure your solution works as you intended.
This is the meaty part. Now you can build the solution to your big problem.
Throw all your data to the code. Perform a chic model. Do whatever you want.
Once the three previous steps are done, this should go pretty smoothly!
If there are any errors, you may need to go back to steps 1-3 to see if you’ve got it all figured out and haven’t missed any bugs.
Just because you’ve found one solution doesn’t mean you’ve found the best solution. Don’t run and call it a day; think about how you could optimize your solution and how you could do it differently.
You may want to talk to your colleagues and ask them how they would solve the problem. Is their approach different from yours?
You can also try to identify the biggest bottlenecks in your solution, ie the parts that take the most time and resources to implement. How can you improve them?
Finally, think about how your solution might evolve in the future. Would new software frameworks or the use of AI improve your solution? How might your solution contribute to solving other, even more complex problems?
Famous Last Words
People, including myself, are often obsessed with different programming languages and the latest framework that could make everything 1000x more efficient.
It’s worth reminding yourself that this is less than half of what it takes to become an excellent programmer. The other half is problem solving.
Problem-solving skills are not acquired overnight.
But if you apply these steps, ask the right questions, and do it often, you’ll be on the right track to taking your career from good to great.
This article was originally published on Medium. You can read it here.