1. Overview

Engineers solve practical problems in real life, using detailed understanding of reality. They do so in a context:

Mathematicians study abstract symbols. If they detect a possible pattern, they examine it rigorously to determine if it is exactly repeatable. They then report these findings to other mathematicians. If others can confirm the findings, then the analysis becomes part of the cultural legacy.
Scientists study the world. If they detect a possible pattern, they examine it rigorously to determine if it is repeatable. Sometimes it is not exactly repeatable. They then report these findings to other scientists. If others can confirm the findings, then the analysis becomes part of the cultural legacy.
In order to allow others to attempt to confirm/reject the findings, one must describe the findings in a well-understood way. This usually requires using mathematical techniques to construct a "model" "hypothesis", which if confirmed is upgraded by community concensus to a "theory".
Engineers try to solve problems (get to the Moon and back; design a building 1000 ft tall which withstands high-winds and airplane crashes; communicate around the world at the speed of light; etc.). If the problems were easy, anyone could do it puttering in the workshed. Engineers handle tasks which are not so easy or obvious. Once they develop a design which works well, it tends to enter the cultural legacy, though perhaps with patent or copyright restrictions.
In order to solve difficult problems, one must typically recognize the critical aspects of the problem, find or build abstract models of those aspects, solve the design problem, and translate back to the real world. There are many ways to do this -- rules-of-thumb, computational models, scale models, full-sized prototypes, etc.

There is a key difference. If mathematicians or scientists communally agree to a wrong answer, their reputations are perhaps tarnished, they reinvestigate, and they propose new/better hypotheses. If engineers make mistakes (even if they trusted the current scientific theories), buildings fall down, rockets explode, and people get electrocuted. Therefore, society has demanded that engineers have degrees from accredited institutions (ABET-accredited in the US), plus in some cases professional licenses.

2. Thinking like an engineer

polya57 explains thinking, and the need to translate complex problems into simpler problems for solution. It is nominally for mathematicians, but applies to engineering. The question is, how does one do this practically? From J. J. Shipp's chapter on "Hair-care Products" (in williams96, referenced in Chemical_Engineering):

Make sure that the brief is clear. There is little point in developing a wonderful product if it is not the one that was requested. The brief should include, at a minimum:

Required performance parameters in as much detail as possible.
Benchmark products, unless the development is in a completely new area.
Guidelines on cost.
Proposed claims, and how these might be justified.
The required timing.

Do not produce a Rolls Royce where a Mini would suffice or vice versa. On the one hand, the accounts department will be extremely unhappy. On the other, the product being launched will fail to deliver its promised performance.

Do not use new raw materials if ones from existing stocks will do the job just as well; avoiding unnecessary proliferation of the raw material stocklist will benefit purchasing, stock control, space, and cashflow.

Specifications often appear virtually identical, while in practice similar products from different suppliers do not perform identically. This can be very important for detergents and emulsifiers. Alternative sources of supply can be investigated as a separate issue.

Ensure reproducibility on scale-up to full-production. making use of suitable plant and equipment. Dialog with experienced process plant operators can be invaluable.

Keep formulations as simple as possible; there should be a sound reason for inclusion of each ingredient.

Try to develop products which can be made as simply as possible; i.e., with minimum energy requirements (heating, stirring) and minimum time in the tank. Large-scale processing equipment is very expensive; careful formulation can help to optimize the use of tank space and tank time.

Engineering is usually an iterative cycle of idea and analysis, as both the customer and the engineer learn more about the problem space and the desired outcome.

Ideas come from independent design shops, dreams at night, zigzag thinking, brainstorming, focus groups, taking a vacation, etc. In other words, you have to be somewhat away from the task to see it in new ways.

Analysis starts with knowing what you want to analyze (the factors or features to be tested), and then constructing and running those tests. There is generally a tradeoff between the richness/fidelity of the test environment and time/money required. Therefore one usually plans a sequence of analyses from quick-and-dirty (to filter out really bad designs), to full-up/near-production-ready.

Notice "generally" and "usually". There is always the possibility that good ideas were incorrectly filtered out early in the sequence. If the payoff is high enough, it pays to do parallel development. Totally different design teams work on the same problem. Effort is made to keep the teams isolated so they do not contaminate each others thinking. Sometimes it is competitive bidding on government contracts. Sometimes it is competing firms in the marketplace. Sometimes it is within a firm, doing risk-abatement alternatives.

2.1. Collected experience

What has actually worked in the past? Dimensions of frames, ribs, etc for wooden boats follow this tradition. Industrial age steam engines and boilers, and iron bridge truss dimensions follow this tradition. Even today, an electronics hobbiest might throw in a few 0.1uF capacitors to filter high frequency in a circuit.

These findings are often collated in handbooks filled with tables.

In each case the assumption is that the components are comparable with the experience base, and that the design isn't radically different. If you try to use pine with oak-based timber-frame dimensions there will be problems. If you try to do a 50-story timber-frame building (even with oak), there will be problems.

2.2. Scale models

The problem space is different enough that collected experience does not provide answers. We suspect that the problem space is complex enough to defy computation, but that it can be approximated with relatively cheap (compared to full-up) scale models.

These include boat-hull half-models, 1/12 or 1/3 scale boat prototypes, tank tests for hull efficiency, car and airplane wind tunnels for aerodynamics, tidal basin models, cyclone generators, architectural models, etc. In each case one has to validate the model against reality, and perhaps make sizing adjustments to ensure the findings are relevant to the task at hand.

2.3. Prototypes

Full-sized prototypes are used when neither collected experience nor scale models capture the problem space adequately for good design and analysis. The prototype can be a fully functional item, or can address only specific aspects of the problem. E.g., A full-sized airplane cockpit made of plywood may be ok for instrument panel layout, but not for tests of electromagnetic interference.

Prototypes are generally more expensive than other testing techniques, so are reserved for the last step before full production. Further, as other techniques (esp computational modeling) become more powerful, fewer prototypes are needed.

2.4. Computational Engineering

As scientific theories became richer, computational tools more powerful, and design components more standardized, there has been a move to computational modeling.

2.4.1. Symbolic Math

Some (very few) physical problems allow exact solution. That is, you work out the scientifically-correct mathematical formula, enter the parameters, and obtain the design. In textbooks it works fine. In real life the math can be quite tedious to juggle. Thus, one uses a symbolic math package (e.g., Maxima) to manipulation the equations.

2.4.2. Numerical Mathods

More typically, the problem cannot be formulated as a solvable set of symbolic equations. Instead, various iterative approximations are used. These usually require large grids (100's or thousands's of nodes), recalculated hundreds or thousands of times.

Despite the cost of computers and the setup time, this can be dramatically cheaper and faster than any other kind of analysis. The biggest payoff is usually that the iterative idea/analysis cycle can spin much more rapidly, thus giving much better quality for a given time-to-market.

The computational tools started as domain-specific (e.g., architectural, naval, electronic). However, it turns out that that many physical phenomena behave per laws with similar mathematical forms. Once you have computational tools to construct and analyze such models, the tools apply broadly. Continuous flow problems in any technology can be modeled in Finite Difference or Finite Element Models (FEM). Feedback systems in any technology can be modeling with Laplace transforms and matrix solution of systems of differential equations. Vibrations in any technology can be addressed with time-domain/frequency-domain analyses.

3. General Computational Tools

The techniques all rely on iterative calculations -- lots of them. You need a computer. In the olden days, this was a room full of people with slide rules. But for the past 50 years, it has been electronic computers. While the techniques can be done on x386-type PC's, it is more appropriate these days to use a multicore 64-bit computer with lots of fast RAM. A box with AMD x2 64-bit dual core CPU with 2+GB RAM and 100+GB disk, running Linux and using OSS tools will cost under $1000. For tougher problems, a mini supercomputer (e.g., 4 such CPU boards, running Beowulf) can be built for under $2500.

The techniques almost all rely on matrix math, and usually expect blas and lapack to be available. Blas and lapack in turn can be optimized for specific platforms, via ATLAS. If you get Ubuntu AMD x86_64 workstation, you get all these tools for free. You also get some analysis tools, though you may want to add your own -- sticking with OSS if at all possible.

In other words, you can do serious analyses for under $1000 and state-of-the-art work for under $3000. Plus of course your time for understanding what is going on.