I do like the idea, but like cooking, coding can have a million different ways to get the same result.
You want to cook the "perfect" steak. First, anyone who says "well done is a good steak" is wrong. But, like with coding, anybody who says "ALL functions should be 10 lines or less" is wrong. There are some cases where it is true (some people do like well done steaks and some applications can be written with functions being 10 lines or less).
I think that if you try to go with the cookbook example, a lot of people are going to come out of it thinking that there is only 1 way to write the statement they want.
There are thousands of ways to write a computer program that does the exact same thing even using the same language. Even writing a "hello world" application. If you set a group of people in front of computers with Visual Studio 2015 installed and, without writing any requirements out, just tell them "write a hello world program on this computer", there are so many ways to do it. One guy may have ASP.NET experience and write up an overly complicated web application for hello world. The next guy may do it in visual basic and just show a messagebox. While the next one does a console app in C# to print hello world and then pause. And then there is me who would write a single line bat file that prints out "hello world" (@echo hello world).
My opinion, the first step to learning to program is learning to think about what is actually being asked and then figuring out, based on the tools I am provided, what is the best one to use.
The next thing a "new" programmer needs to learn is to ask "what is it you are trying to accomplish?". I don't know how many times I've been asked "can you make a program that does this? Ok, now add this. and this. and this. and ..." and in the end I have rewritten the stupid thing 2 or 3 times simply because the end user didn't tell me what they needed; they told me what they thought they wanted.
Heck, not that long ago I wrote up an SSRS report for an end user. They'd enter a serial number, and it'd spit out some information about it. Then they asked for a second report that they would use information from the first to get more information. I put it all into 1 report and the end user was super happy and even said "I didn't think we could do that. That was why I wanted it in 2 reports. This saves me so much time". Sometimes end users like to come to the programmers with "solutions" instead of "problems" and it is very rare that their solutions actually solve their problems the way they expect.
TL;DR - I think the cookbook idea is a neat one, but it may get people thinking there is only 1 way to skin a cat. Might be better to teach "new programmers" to think critically about a problem before they start cooking. When the customer says "I want a steak" and you bring them a perfectly cooked steak and they say "this looks nothing like fish", the programmer is going to lose it.