You may ask yourself “well, I do get the basic idea of how that break-out-game runs. But how do I convert that ‘logic’ into real programs”?
The goal of this book is not to teach you one specific programming language, but to get you into a “mindset” of solving problems/tasks from the perspective of a programmer.
This perspective is to look at the goal, understand what the goal really is about (not marketing blabla, not the boss’ understanding of what is needed, but WHAT is the real deal? What does the program you are to write NEED to do, what input does it work with, what is the processing that’s applied to the input and what is the desired output – and what can go wrong, what “bad” output is possible and can you deal with it?).
Then break down this understanding into manageable blocks. Call those blocks “functions”, “features” or “tasks” – the important step here is to defocus from the (probably frightening larger-than-life) goal and concentrate on what you CAN handle, what you CAN solve and where you CAN be successful.
I cannot stress this more. Or well, maybe I can stress this a bit more: Imagine you want to safe the world. All of it. The whole universe. All realities. Every human being, especially those you like. If that goal isn’t larger-than-life enough, add becoming a God to the task, or maybe becoming two Gods.
How do you achieve this goal? Probably not by “just doing it” – as many life-advisors will tell you.
But what about starting by saying “thank you” when someone helps you (maybe she holds open a door for you, maybe someone did a good job and your initial reaction is “she was JUST DOING HER DAMNED JOB why should I thank her for DOING HER STUPID JOB that is all she has to do and if I was to thank everyone who is only doing their bloody job I would be thanking half the world all the time”). Pick up the litter you just dropped and place it where it belongs (no, that’s not your neighbor’s garden).
You get the picture. If you don’t, please do ask someone who knows how to be nice. Start there. Start with something you can do. Then have a look at what else is looking wrong. Pick one problem at a time and get comfortable with your solution.
Adjust your solution when you are able to bombard it with unexpected data – say “Thank you” to someone who let go of the door just when you were about to go through. Don’t forget to wipe your nose before thanking her, you don’t want to spit that blood on her costume.
Yes, we are still talking about programming here.
Tackle one problem at a time. Everything’s a problem. There are no “no-problems” in programming. Check if your solution works with wrong data. Write test input/test output routines.
And document what you are doing – you do not have to write a novel about “this routine is printing information on the screen. The screen is the thing the user is starring at. The user is the thing sitting in the chair in front of the desk. The chair is …” – just write “outputs information to user”, if you really had to write a “printf” routine for whatever reason.
And document WHY you are doing it “this way”. Like “we do not have to check for negative positions on the ball, because there is a wall defined at position 0 anyway”.
I know that documentation is considered “coward’s weak spot” amongst many professional developers. Please do believe me: Professional developers sometimes get older than 22 years and start tending towards gratefulness if their 22-years-old-self took the time to write some notes and what, why and where in the code 30 years ago. Even 10 years.
Programming languages change. You may not be able to use the same language in 10 years that you used to write a solution today. Having code documented, at least a bit, will help a great deal when converting an older tool into a new language that you have – then – been using for months or years and don’t remember how things worked all that time ago.
Test your program – be it on the computer, in real test scenarios, or be it on paper by doing some manual calculations. Run some “correct data” that you know the outcome for through it and some “obscure nonsense” and check that you can handle the results.
This sounds like it is taking up a lot of time. And it is. In my experience “development” is about 2/3 to ¾ understanding the problem, dissecting the problem, checking solutions for reliability. The rest is writing code, documenting the code, doing backups and drinking coffee/tea. I am not kidding.
There are people (and there are situations I have been one of them) who will “hack away” and solve every problem along the way (or think they do). Without exception the results of such hacking-marathons are not “durable solutions”. Yes, sometimes you do not NEED “professional, long-term solutions”, you need to crack a nut now and have it working for a few days, even if you have to sit at the keyboard all the time and do hot-fixes.
This, however, is not how life should be. It is stress (though it can be fun), it is dilutional. You don’t constantly take leaps of faith, jumping blindfolded onto crowded roads at rush hour, all naked with a loaded shotgun in your hand pointing at your belly button. You may do that once or twice because you have to – but USUALLY you walk up to the traffic lights, press the button, wait a moment, cross the street, then put on some pants and unload the gun. Or something like that. You USUALLY take care. You USUALLY do it the proper way.
You should know that there is a “proper” way and WHY there is a “proper” way. When you have to get messy, you should know that you are doing it differently now for a reason and that you CAN NOT tell your boss “this is a perfect solution”. You can NOT have marketing sell the results as the “final product”.
That is what THEY are doing. You should know better.