I am a programmer in Missoula, Montana. I have a Ph.D. in mathematics (combinatorics, graph theory). I analyze and visualize data. I write algorithms and applications. Here is a recent project on industrial automation. I recommend Forth. I have also worked with Unix-style tools such as Linux, Bash, Awk, and C.
In 2009 I confirmed by a construction of Kierstead and Trotter that the performance ratio of the first-fit algorithm for coloring interval graphs is at least 5.
My resume is a PostScript program typed by hand into a text editor. PostScript is not just a document format, but a programming language. You can run PostScript programs with Ghostscript, produce PDF with ps2pdf, and produce SVG with Inkscape. For a code sample, open the PostScript version of my resume in a text editor such as Vim.
Forth is the best choice. This essay by Jeff Fox recommends Forth to young programmers. Starting Forth by Leo Brodie is a good introduction to Forth (and programming in general) available online. JONESFORTH by Richard M.W. Jones is nicely annotated (first read jonesforth.S, then jonesforth.f).
Sometimes my solutions involve cooperating programs in several languages. Often I get by without special database management software, as it is easy to do random file access in C and build indices with Bash, Awk, and sort.
For visualization I have used Graphviz, SVG (viewable in Firefox), and PostScript. For graphic user interfaces I have used GTK+ and Python's Tkinter (Tk) module.
I like the Small Combinatorial Library of Dan "sigfpe" Piponi written in Haskell. An entry on surjections at MathOverflow gives another demonstration of how useful mathematics can be in answering questions that arise in programming.
Rarely do I hear of people programming in PostScript, but you could teach it to beginners. There is broad appeal in the graphics. The evaluation model is simple and fun. The PostScript Language Tutorial and Cookbook is easy to find. On many Linux systems, you can type PostScript commands into the default text editor; output shows up in the file browser; and if you open the file there, you get an output window that's automatically refreshed when the file is saved. Is there a simpler development environment?
Agile.1: Individuals and interactions over processes and tools.
If you can describe what your team does only in terms of people, you are screwing up.
Agile.2: Working software over comprehensive documentation.
With Agile, people write the documentation they feel like writing. Usually it's none, and that's too little. Before Agile, software worked most of the time and people fixed bugs and wrote new features. With Agile, it's the same, but no one can say exactly what the software does.
Agile.3: Customer collaboration over contract negotiation.
Great idea! Don't deliver anything specific.
Agile.4: Responding to change over following a plan.
False choice. Do both or lose! When change comes, adjust the plan. If you respond to change without a plan, you lose the advantage of your strategic assets.
Project Euler is great. I have solved around 160 problems. I recommend it to students. However, (1) sometimes you have so many apples that before you eat them all, you are tired of apples, and by apples, I mean diophantine equations. (2) The site is addressed to those "for whom the basic curriculum is not feeding their hunger to learn." That's fine, but I would have had trouble understanding and solving many of these problems without my institutional experience. Thank you to my teachers.