I am running a series of workshops for colleagues cross training to C#. The theory content is fine, but I am finding it hard to come up with interesting exercises for them to do.
Anyone have an ideas or links to exercies that are simple enough for noobs, but interesting enough to keep their interest?
All the classics usually work very well:
I find that exercises in their native problem space are best. What kind of code are they going to be writing? What sort of problems will they face daily?
I recall one from my COBOL training days that involved formatting text for cheques, the input was a monetary value - eg $123,345 - and we had to output the value in words - One hundred and twenty three thousand, three hundred and fourty five dollars.
Was interesting because there are quite a number of ways of coming up with the solution, and nearly everyone in the class had a different implementation - not all of them equal!
The best thing you can do is just start programming something you would find useful or interesting. I find it's a lot easier to stick with things that I'm actually interested in. For example, when I wanted to learn sockets, I created an IRC clone.
There's no reason to stick to toy problems all the time. You'll be surprised how easy it is to develop something useful if you just start working on it and keep working on it, and then you'll have learned something as well as created something you can show off to others.
Seeing as it is a series of workshops would it be possible to build a useful, if small, application from start to finish. I understand the value of the classic programming problems but it is sometimes nice to learn a new language by solving a real world problem as opposed to an abstract puzzle.
To be honest, one of the more interesting coding exercises I have done has been writing your own rouge-like. Not only does it tend to be a bit on the fun side because you are working on a game that you will (hopefully) be able to play when you are done. It also exposes you to a good variety of data structures, input processing, algorithms, and design principles.
Plus, there is a decent amount of information out there on getting started on it and active enough communities that you can find help if you get stuck.
Well the most simple yet interesting things to code i found are libraries of any type. Like mp3-Library, CD-Library, Book-Library, ...
It is easy to do. Like starting with a console program which lists the available items from a file. Then improve it step by step.
Like add a GUI, a Database, or a webinterface.
Then you can go bigger like interacting with the media, hardware recognition of items (like barcodescanner or webcam) or building a webstore for it.
I found that this is a exercise which is able to show something of every aspect of programming.
You can ask them to implement some simple games, like minesweeper or tic-tac-toe.
Another vote for a rogue-like. Though it may be a tad intensive for people with no prior experience.
An autoencoder neural network is interesting, yet pretty small if you set it up right. Go from 8, to 3, to 8 nodes, and show that if you train over making only one input active, you only need three internal nodes.
I have introduced colleguaes to C# by letting them implement a simple order application using the deFacto architecture of the company. This way they touch the db, Data Access layer, business layer and ui layer. The application is no more than an order table, orderlines, users and products...
My answer would depend on what languages your colleagues already know and your organization's application domain.
Here's a strategy I've used with programmers coming from a procedural programming environment (e.g. COBOL, C, VB): Take a small program task couched in terms of their application experience, and start with a "brute force" procedural solution in C#. Then, as you introduce each new concept specific to C# (OO, LINQ, etc.) challenge them to see how that concept can simplify/streamline the procedural code, increase its maintainability, flexibility, testability, etc.
At the end of a series of presentations, you've evolved the program from a a design they might initially recognize into one that uses the kind of new design thinking and language features you wish to encourage. This allows them to see the rationale and contribution of each concept you've introduced.