There is a 35 years old result in Logic (the Curry-Howard
correspondance) that states (simplifying a bit) that algorithms are
like (isomophic to) proofs. If you take the specification of a
program/algorithm such as,
Given a sequence of integer, give a sorted sequence of the same integers in ascending order. This may be read as
the statement of a theorem
For any sequence of integer, there is a sequence that contains the same integers in ascending order. And any
algorithm meeting the specification will actually correspond to a
proof of the theorem.
Most professionnals will never be asked to use this correspondence (at least in the current state of the technology), but it does provide
some understanding of the programming process.
What this indicates is that to understand algorithms, you have to
inscribe them in a structured body of systematic knowledge, as much as
possible, as you would do for mathematics. And mathematics does also
play a role. What matters is understanding the structural
underpinnings of the type of entities you are dealing with, so that
you have an organized vision of what can or cannot be done, when and
how. Note that some algorithms use other algorithms as components, exactly as
some theorems are used to prove others.
Or to put it another way, you can work programming and algorithmic
design exactly the same way you work on a mathematical problem. In
mathematics, you learn a collection of definitions and of theorems that
involve these definitions. Given a problem, you try to identify
structures or entities that meet the definitions you know, for both
hypothesis and conclusion, and you try to apply the theorems to get a
When given a programming problem, you do exactly the same: you try to
identify data structures or abstract types and programming structures
that would adequately represent the entities you are supposed to deal
with, and then you try to compose various algorithms (theorems) to
actually get the work done.
In mathematics, what matters in some cases is the proof technique
rather than, or as much as, the result. You sometimes have to reuse
the same proof technique in a different context. The same goes for
algorithms. If you understand how they are designed, you can use a
similar design for other algorithms, in situations where known one do
not exactly apply. So it is not just knowing algorithms that matters,
but much more understanding them, understanding what makes them tick
the right way. And that is not always easy. Some research
improvements in algorithms result precisely from trying to understand
the deep reasons that make some of them work the way they do. And
this often involve understanding mathematical structures.
More generally, understanding a mathematical theory is not rote
learning of a collection of definitions and theorems (though it
sometimes help for specific very technical aspects). It is getting an
overall, structural mental picture of the various aspects of the
theory and the ways they interact. The same goes for algorithms.
For example you may want to study and understand in a global way how
one can deal with graphs. The various algorithms may have relations.
Then, given a problem, you may recognize that part of it may be seen
as a graph problem, and deal with it accordingly.
This said, the world may be a somewhat simpler place for most
programmers. But the more you understand, the better you do.
I would like to point out that this is not the only facet of
programming. Of course, a good program must use good algorithmics. But
it often is not enough. Style and architecture matter. Your program
must be easy to understand and maintain. From a mathematics point of
view, this may correspond to what is called an elegant proof.
The choice of the programming language may matter, as the choice of
the right notations may matter in mathematics. But that is a bit
beyond your question.
I am sure there is a lot more to say.