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."
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.