A programmer is not someone who types super fast (yes, you have been fooled by movies and TV series).
Programming is about problem-solving.
Most of the time, a programmer is thinking about the problem and how to solve it.
Problem-solving is a skill that requires creativity.
And just like any other skill, it can be learned.
The best way to learn is to practice with different problems and projects.
Solving different problems will teach you different skills.
Don't worry too much about syntax, you can always google it if you don't remember, but the reasoning behind solving a problem is something you have to develop by yourself.
The general problem-solving flow is like this:
- Analyze and understand the problem
- What are the inputs
- What is the required output
- Plan the solution
- Break the problem into smaller parts
- Break the parts into tasks
- If you get stuck, step back a little and rethink your approach
- Test the solution
- Fix errors that might appear, face them like challenges, not annoyances
- Iterate the steps until success
Programming teaches you to think better.
Problem-Solving flow
A program doesn't exist without a goal.
You code because someone in your company or an external client requested a solution for a problem they have.
Developing a system is a project and as such, must be treated as one.
You have a new project to develop, a new program, there some important things you should check before coding to maximize the chances of success of your endeavor.
The first thing is:
Stakeholders and their problems
Ask yourself: who is using this program? what for? what problem do they have that I am solving?
Stakeholders can be your boss, a client, or the actual person who is going to use the program, the so-called end-user.
Talk to these people.
Don't assume you know what they need, you will waste time and resources and feel frustrated when you find out that what you built does not fill the gap as needed.
Take notes in an organized way of everything they tell you.
These notes will turn into the second thing:
Requirements
Every software has requirements like:
- "I must be able to manage my customer data"
- "I need the input X to become output Y"
- "I have thousands of spreadsheets with sales information and want to know how much did we profit monthly on average in the last 5 years combining their data"
Analyze and understand the problem and turn it into requirements you have to fulfill, describe in words what has to be done for your program to be successful.
The third step is to:
Break down the requirements into tasks
The requirement "I have thousands of spreadsheets with sales information and want to know how much did we profit monthly on average in the last 5 years combining their data" translates to:
- Create a way to input/import all the spreadsheets
- Process the data to get only what is related to sales profit, since the spreadsheets have a bunch of information I don't need such as names and addresses
- Group the sales profit by month and average them
- I have to output another spreadsheet with the result
With these written down, you have a clear path on what to do and you are able to track your progress and report it back to the stakeholders and show them you are advancing in each task.
If your requirement includes a screen or a form in a website, you can also draw a rough sketch of how it is going to look like, which field goes where, to serve as a model.
You then discuss these tasks and sketches with the stakeholders to check if you understood the problem well and if you are on the right track.
This is a good point to find some mistakes and correct the direction before wasting resources coding a solution.
The fourth step is to:
Design and code your solution
Now you can work on your code.
Define which libraries you will need, which functions should you create, what approach should you use.
This varies a lot from programmer to programmer, my solution will differ from yours and they will be both right.
There is no single solution to a problem in programming.
The fifth step is to:
Test and iterate
First, test it on your own and check your test cases.
In the example of the spreadsheets, you can try to use just a few files, say 3, to check if your code outputs the same results that you achieved but doing the process manually.
Doing the process manually is simply taking each spreadsheet and making the process of taking the average monthly profit by hand, just like the end-user would, and yes, it usually takes a long time to do it.
It is usually better to ask the end-user to provide this manual test case instead of doing it yourself because they will most likely do it faster and more accurately.
If your code doesn't output the same, you have to iterate, find the error, fix it, and test again until it matches the expected output.
If your test ran alright, give the solution to the stakeholders, so they can try it with more test cases and give you feedback if there is something to fix, enhance, or if your solution is just right.
Embrace this process and you will be way more successful than just sitting and coding in dark.
Finding help
What to do if you get stuck?
It does not matter if you are a beginner or a pro, you will eventually get stuck.
I've been coding for a long time and I still get stuck.
Finding a way out of a problem by yourself is a major ability for a programmer and you should get used to it.
If you see an error, the first thing is to stop and read it carefully.
Sometimes the error is very explicit in telling you what went wrong and what you should do.
See error messages as a friend pointing you in the right direction.
Some errors are not so friendly though.
In this case, Google is your best friend.
Chances are, someone has been through this error before and there is a solution for it on the internet.
Just copy and paste the error message on Google and look for the solutions available.
You might need to open more than a few blogs and forums, but trust me, this is a part of the process, and getting good at it is really important.
I encourage you to spend some time reading the official documentation of anything you are learning in tech.
Some documentations are just bad, but most major technologies have good docs and Python is one of them as you can see here Python Documentation.
Learning from the source is a great advantage in this ever-evolving world of programming.
You might also like:
Top comments (0)