When A Beginner Asks For A Project To Do

Commentary

So, I'm about to start an adventure where I learn a new serverless (also known as 'Backend as a Service' or BaaS) technology and implement a small project with the new technology I've learned. Because there are large number of offerings for serverless(-for-me) technologies, we needed to have a number of projects to implement.

Sidenote, an argument could be made for implementing the same project across multiple serverless technologies, to expose the strengths and weakness of each of the technologies, as well as the service complexity and depth, in comparison with each other. While a worthwhile and valid argument if the adventure goal were to find a good technology fit for my company, the goal of the adventure is to explore the different serverless technologies. Variation is helpful with this exploration.

The first step on this adventure is commit to the adventure. Have done that.

The second step is generate a list of projects to consider for building. Each project needs a front-end app and a (serverless, natch) back-end API. Each needs a level of security. Each needs to store information. Each needs to have a set of models, and a set of actions. None of this is new information: I need a project to build.

So, I go off to the Intarwebs™, and start looking for "small web developer project ideas" and "projects for my web developer portfolio" and "what web project should I build?" and the like.

I'm expecting to find a nice, concise list of "Here, try building these. Each of them is a good, self-contained project that will explore some particular aspect of web development. You can document what you've done, put the code up on GitHub, and explore with potential peers the what-you-did, the why-you-chose-X, and the how-you-did-it."

Instead, there are a number of top posts that tell me, play around with building a form, build something with AJAX, build something with Bootstrap, learn Javascript!, learn about grid systems, and I just want to pull out my hair.

The reason for a project is to learn HOW to use these things. Reading examples or documentation doesn't mean using the code, playing with it, learning the nuances of the technology, and understanding what is going on with the code. Projects do that, they give someone a goal to complete, something with parts that great and parts that you have to trudge through.

Creating something that didn't exist before, making something you want to exist, THAT is where the high of programming starts. Using technology to solve a problem makes programming worth the time and mental energy. Learning for the sake of learning is fun, yes, but building something, THAT is better.

So, yeah, next time someone asks for a project, don't tell them to learn a technology. Instead, give them a problem to solve, something that you wish existed. Be excited about the project. She will have a project to build, and you'll have a problem solved.

And likely you'll have one fewer rant from me.

Comments

I had someone ask me for a project list the other day, and one thing that I found worked well was to spit off a large list of projects that all existed in the context of something else (in this case, Slack bots). The idea was that each project should be self-contained and build on the next one but only a *little* bit, so you'd be able to accelerate after your first one but still keep learning new things. For example:

- Build a slack bot that responds to "hello".
- Build a slack bot that sends you the weather for a particular city.
- Now make that bot take input for which city to look up.
- Now do that for a particular stock ticker symbol
- Now make it accept which symbol to look up
- Now make it track a virtual portfolio of a ticker symbol, and let you buy/sell it
- Now expand that to multiple symbols
- Build a bot that will remind you to get a haircut, or if you tell it you got a haircut can tell you when you need another one

Repeat, repeat, repeat.