Almost weekly a friend or an acquaintance asks me, “I want to learn to code; which language should I start with?” More or less bi-weekly I get a DM on LinkedIn starting with, “My son should start programming; what is the best language for him?”
It’s not just people who’ve never coded before. Often I get these messages from people who have several years of coding experience under their belts.
I’m not saying this to complain.
The heart of tech is coming to the heart of the Mediterranean
I make half a living from prodding the pros and cons of different programming languages, frameworks, and AI models here on Medium. I profit greatly from people having such questions.
The questions are quite intuitive. After all, everyone would like to work with the best possible tools and build their software skills as quickly as possible.
And when you observe that every developer seems to use 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 on its own is good or bad; it just depends on what type of problem you want to solve. At the end of the day, programming is just that: problem solving by means of using a computer.
So, for people who want to start programming or enhance their skills in software development or data science, the question should not be, “What should I use, Python or Julia?” The question should be: “How can I solve software problems better?”
For full disclosure, I’m not a computer scientist by trade. I’m a particle physicist who happens to use concepts from programming and data science because I deal with humungous amounts of data from particle colliders.
That being said, physicists are similarly sought-after as computer scientists. That’s not because of their knowledge about neutrinos or black holes; it’s because of their problem-solving capabilities.
Abraham Lincoln is quoted to have said, “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”
For programmers and data scientists, this means spending time understanding the problem and finding high-level solutions before starting to code. In the average coding interview, candidates are expected to spend less than half of their time actually writing code, and the rest of the time understanding the problem.
Don’t skip this step, ever!
Key to knowing whether you understand a problem is whether you can explain it to someone who isn’t familiar with it. Try to write it down in plain English or your mother tongue; draw a little diagram; or tell a friend about it. If your friend doesn’t understand what you’re talking about, you need to get back to the problem statement.
Key questions to ask are:
Every big problem consists of lots of smaller problems. Given our previous example with the linear regression, you might want to consider the following sub-problems:
Breaking the problem down helps you make a proper plan for your work.
It’s also more motivating, because you’ll be achieving small but important 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.
The devil is always in the details.
Instead of starting with the whole project, take a little piece of it. Try whether your plan works, or whether you have to adapt it because of unforeseeable difficulties.
This helps you get your head around the hard parts. Many problems sound simple, but when you start building them there is one roadblock after the other.
In our example, instead of using all relevant variables, one could perform a linear regression on a couple of variables first. This won’t give you any points for project completion; however, finding bugs in your scripts when you’re still dealing with a small amount of data can be life-saving.
When you’re throwing all your data at the machine, running it for hours, and then come back to realize that the script hung up midway, you’ll be very frustrated.
Trust me, this happens a lot!
Run small tests first, and make sure your solution works as you envisioned it.
This is the meaty part. Now you can build the solution for your large problem.
Throw all your data at the code. Run a fancy model. Do whatever you want.
Having completed the three prior steps, this should run through quite smoothly!
If there are errors, you might have to go back to steps 1–3 to see if you’ve understood everything already and haven’t overlooked any bugs.
Just because you found one solution doesn’t mean you found the best solution. Don’t run off and call it a day; think about how you could optimize your solution and how you might be able to approach it differently.
You might want to exchange with your colleagues and ask them how they would solve the problem. Is their approach different from yours?
You could also try to identify the biggest bottlenecks in your solution, i.e. the parts that take the most time and resources to execute. How can you improve them?
Finally, reflect on how your solution might evolve in the future. Would new software frameworks or the use of AI make your solution better? How could your solution contribute to solving other, even more complex problems?
People, including myself, tend to obsess over different programming languages and the newest framework that might 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.
You won’t acquire problem solving skills over night.
But if you apply these steps, ask the right questions, and do this often, you’re on the right path to taking your career from good to great.
This article was originally published on Medium. You can read it here.
Get the most important tech news in your inbox each week.
Check out the TNW Conference 2022 post-show report →
The heart of tech
Copyright © 2006—2022, The Next Web B.V. Made with <3 in Amsterdam.
source
—
Note that any programming tips and code writing requires some knowledge of computer programming. Please, be careful if you do not know what you are doing…