Learn to program
Before you begin
There are many ways to make the same thing in programming.
You try, retry, err and succeed. Reject one solution in favor of another.
Sooner or later you'd like to go back to one of your previous states or use one of your side findings and can but vaguely recall it unless you are using some kind of version control.
If you are already using git, you can probably skip this section.
If you are not using git yet you should begin using it.
I cannot say git is the best version control system for all cases. Coming to git from ClearCase I really miss ClearCase's handy features and hate git's aggressive merging when it fails to merge but changes files in merging attempt...
And still if you are just starting - start with git.
It scales perfectly. You can start using it in minutes and grow your skills as you use it.
You can use it locally or create a free account at one of git repository hosting providers.
GitHub is the biggest pond out there with large community and learning lab.
GitLab looks more corporation-oriented and still offers free accounts.
There are other providers offering remote git repositories.
Git is distributed version control system.
This means each local copy of a repository contains its full backup updated each time you make a pull.
If there is any problem with repository on the server, the most recent copy held by collaborators
can be copied back to the server to restore it.
You can version control files of almost any type. Though majority of diff and merge tools ( Meld being my favorite ) are text-oriented with additional features for comparing code, you can still find diff/merge tools for images and other file types.
Version control allows you freely explore new ideas and keep all your findings within your grasp
no matter which one of them you'll choose to include into certain version of certain project.
You can change your mind anytime and revert any file, any number of files or even entire project to its earlier version.
You can track what and when was changed and who made the change.
It seems to me, it's already enough reason to start using git right away.
You can even build it from source: Building git from source on CentOS
Any deliberate doing begins with deliberate thinking
Programming thinking is going from what to how.
Yes, I know about 5W1H.
You need to distill all those why, who,
what, when and where
to one What:
what your code should do?
Then you can begin thinking about writing it 😉
You take your big What and decompose it.
Decomposition should look and feel natural to you like taking peas out of the pod.
Peas can be anything: objects, functions etc. but it's better if peas from the same pod are of the same kind.
And yes: peas are in pods, pods are in sacks, sacks are in ...
So you decompose and decompose until your what becomes how.
E.g. when you need to read from file the next question is "How to read from file?"
The step is small enough to be implemented without further decomposition.
When your decomposition is done and implemented step by step, look at your big What again and try decomposing it in totally different and still logic and natural way. Try it at least while you are learning and have time to exercise...
- I know 3 main ways of abstract decomposition:
- Structures and procedures - in order to organize data put it into structures
and then process the data with procedures.
E.g. so simplest clent-side JavaScript manipulates DOM data. - Agents - you combine data structures with procedures into objects that do work and hide implementation details from consumers of this work down the line.
- Pipeline - you have some input data and convert it into output basing solely on the input and conversion rules.
They call these 3 ways imperative, object-oriented and functional
programming.
They even divide programming languages into procedural, object-oriented and functional though
it's quite clear that good general-purpose programming language should support all 3 styles allowing programmer to
choose the best fitting for each problem.
While doing my small projects I tried to record my thoughts in "From WHAT to HOW" section.
To learn how to program you need to program
Programming language is just this - language.
When you learn to write, you:
- Copy. Don't copy-paste. Take pains typing what you see.
- Write dictations. Don't follow tutorials blindly. Change examples slightly and observe effects.
- Write expositions. When you meet an algorithm description or pseudocode - try to code and test it.
You can find some of mine in "Digest". - After all the above you are ready for your own essays.
Happy coding!