An analyst starts with an object and then looks for things he can prove about the object. An algebraist starts with the proof, and then looks for objects for wh

An analyst starts with an object and then looks for things he can prove about the object. An algebraist starts with the proof, and then looks for objects for which the proof is valid. Both methods have advantages and disadvantages. An analyst can get bogged down in the details of the object he studies. An algebraist has the tendency to make trivial statements complicated. It is rare to take a result from the algebraic side and apply it in your concrete situation that you get something that wasn't already immediately obvious. Personally I lean to the analytic side, although the algebraic approach can be helpful if you apply it judiciously and take care to only generalize when this has an advantage and not just for the sake of generalization. If you look at the history of mathematics, most of the good stuff has analyst roots, and was only later incorporated in an algebraic framework. Though this could easily be my bias for what is good stuff. Even traditionally algebraic subjects can be often approached analytically. For example if you do group theory by starting with group actions, it gets an analytic feel (and in my opinion, everything becomes much clearer). The reverse is also true, that's how many of the algebraic subjects initially started: take a bunch of proofs from the analytic side, and see for which classes of objects they remain valid. In programming you have something similar. Programmers that try to generalize their code as much as possible are algebraists. Dependency injection is an example. Programmers that say "YAGNI" are analysts. If you like interfaces and design patterns you're probably an algebraist. If you like bottom up programming you're probably an analyst. If you like Haskell, you're probably an algebraist. If you like Lisp you're probably an analyst.