I am a programmer. I live in Gilbert, Arizona. I analyze and visualize data. I write algorithms, system software, and applications. Here is a project on industrial automation. I recommend Forth for its commitment to simplicity, clarity, and parsimony. I also use Unix-style tools such as Linux, Bash, Python, Awk, and C. To some extent I can work with Windows and applications from Microsoft. For example, I have written desktop applications in Python that run on Windows systems.
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.
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. It has been many years since I have needed a database management product. Usually it is easier to do random file access in C; build indices with Bash, Awk, and sort; and keep backups.
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. Graphics programming is fun. The evaluation model is simple. 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?
If you are building software, you are trying to create a program that runs on machines to complete some task. One person can do this work. Many people can do this work. Software is not about the number of people working, or their roles, or the nature of their communication. Programming is usually easy once the task is well defined, and until the task is well defined, the programs you write may not be useful. Adding people or meetings doesn't help. You should organize your efforts around defining the task.
A proven strategy is to define a modest task and expand it incrementally. You don't have to write a specification before programming begins, as in the "but waterfall" argument of the Agile enthusiasts. But you do have to write a spec, and this responsibility, if assigned to a group of people, belongs at the top of a hierarchy, not in a system of meetings among stakeholders.
In practice, Agile means frequent meetings and no documents, both bad ideas. Is this intentional? Let's read the Manifesto. They favor...
Agile.1: Individuals and interactions over processes and tools.
Let me get this straight. You can describe what you do in terms of people, not things, and you are an expert in automation?
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.