The formal definition from the book is
An algorithm is an ordered set of unambigous ,executable steps defining a terminating process.
Programming languages aire built to be unambigous. We all agree what the primitives are and how they are combined. The compiler is the enforcer.
The primitives in a language have both syntax - what it looks
like and semantics - what it means. The syntax of assignment in
a = b;
The semantics are that the value stored in b is copied to a.
In some object oriented languages, this might be doen with the syntax
but the semantics are the same.
The book gives a number of clever examples of how to approach problem solving.
Most of what CS people do is to solve problems. Generally, problems
that havn't been solved before.
A good approach is to solve any part you can and use that to attack the rest of the problem. Get your foot in the door. This is similar to solving multiple simultaneous equations.
Often you can't fully define the problem until you start solving it. The best requirement are a working program. Prototypes can lead to understanding the problem enough to lead to a solution. This is a process of stepwise refinement. Design it from the top down and build it from the bottom up.
Sometimes you need to change the point of view. For example, we have a big form that is used to fill in information about code inspections. We then looked at it from the point of view of different interfaces for different roles and uses. This leads to a very different solution. Describing the problem to someone else is another way to change perspective.