Experiment

This blog is an experiment. It is not a well-planned structurally thought out masterpiece, but simply an experiment. 

Being able to experiment can very well be a valuable tool for any coder to have....wait... what?! Shouldn't all programmers only write well thought out thoroughly planned code at all times? While planning and design are undeniably very important tools to have and can not be ignored, experimentation has it's place. 

What is meant here by experiment? Simply randomly trying something just because reasons? No, what is meant here is experimenting as a tool for discovery. Any good experiment needs to be looking for something specific. In the scientific method (if I'm remembering this from school correctly) you would 1) form a hypothesis 2) conduct experiments to test that hypothesis and 3) observe the results.  Well, anyone can do a quick Google search to see it's a little bit more involved than that. (For example: https://www.sciencebuddies.org/science-fair-projects/science-fair/steps-of-the-scientific-method) It really all starts with a question. By the time you get to the hypothesis you should have just enough information to make a good guess - not enough to know the answer, but enough to make a good guess (or educated guess if you want to use more formal words). The same applies when using experimentation to program. You start with a question. Questions like: "Why isn't my code doing what it's supposed to?", "How can I use x language?", or "Can I actually do the thing?" could be possible starting points. From there, you can begin to think about the problem and gather some more data. After that, go ahead, take a guess (aka make a hypothesis). Why do you think your code is not working? Or how do you think you can go about building a thing? Take a guess, then build an experiment to see what works. 

Here's a few ways this can be used:

Ever want to learn a new language but just not really getting much out of the online tutorials that take you step by step through a process? Turn it into an experiment! If you are trying to write a 'hello world' program.... because well... we always start with 'hello world'.... then ask the question "How can I write a hello world program in language x?" Then dig in and find some data. You might look for how to setup your environment for language x, and how to print to screen in language x, etc. Now you can form a hypothesis... "I think if I do 1)a 2)b 3)c I can have a 'hello world' program in language x!" Then try out that experiment. If it's a success then you should see "HELLO WORLD" on your screen. If not, then you didn't actually fail - you just found out what method to NOT use. Simply take in some more information and try again!  Yeah, yeah I know, the "hello world" example, sounds maybe overly simplistic. If you're thinking that, you would be right! Why would I conduct an experiment for something that is so obviously step by step? Well, this is not intended to convince anyone to actually conduct an experiment to create "hello world" programs, but to use this method to try out interesting things beyond the tutorial while you learn. Instead of simply following the tutorial, ask questions, "OK so that's how you do that... but how would I...?: and dive in and discover how it works!

What if you are wanting to build a really cool game (or insert other really cool thing you want to do) but aren't sure if you can do it? Well, you already have your question, so you're done with step 1! Your question is "Can I actually do the thing?" In this case, you're not sure if it is even possible. Maybe you can't quite picture it, or there's one piece that you're not sure of. Dive in there. Learn just enough to see if you can test it out. Then do an experiment by building it as a rapid prototype. No need to elegantly design out a masterpiece here, you are doing an experiment to prove a concept: you are only asking "can it be done?" Once you have your prototype and have the answer to "can I do it?" now you can go back and actually design it properly. The key here is that you didn't jump ahead and build the whole thing (unless this was purely for fun and you don't care about maintaining the code). The key is you did just enough to see if you could do it. A bonus here is your prototype gives you some hindsight you can use while designing the full project.

Have you been coding with language x for years and years and have a really good grasp on how to use it but still feel like you're missing something?  Use experimentation to discover new things about a familiar language! Here's a question that might be useful: "I've been doing xyz in this way for years, it works... but is there a better way?"  Then gather some data and start experimenting! Maybe find multiple different solutions and try out each one. With your experience with language x, you will have good insight into which solution might be best. Once again, you aren't building production software here, you are experimenting to discover. Maybe your discovery will be that you have been doing xyz the best way all along but either way you will learn something new about something that before seemed all too familiar.

OK, well, now we're actually talking about production software... *gasp*.... Don't worry, I don't mean building the software through experimentation alone and disregarding good design. I'm not endorsing spaghetti code here! *scream* But what happens when you are following your well thought out thoroughly planned design and start to run into problems? Experimentation can be used here as a tool to solve problems. If you are debugging you can ask a question like "Why is my code doing this [insert faulty code behavior here]?" Then gather information about that part of the code. This could involve looking at the actual code, looking at surrounding code, doing online research, using a debugger to see what is going on (or even using print statements :P ). Then, once you have a good grasp of the problem you can form a good guess as to what is causing the issue and how it can be solved. Afterwards, you can create an experiment to test it out!  *Debugging obviously is it's own tool, and will probably get it's own post at some point... but it fits in well here.

This list is not exhaustive. Hey, maybe you can experiment to see where else experimenting is useful for coders? So.... go out there and mad science your code!