BrainAs creators of the web we must keep up with an ever changing environment with new libraries specifications and trends. I come across these changes at work granted but I gain most of my knowledge online and on my own. This article is is going to cover how to discover and explore how and why behind the technologies used. After years of just picking up new things seemingly on the fly, this is the pattern I have derived . Hopefully this carries through to others and helps them find, experience and learn new things.

Explore

This is one of the most important steps. This is where an eagerness to learn and find new technologies and techniques is critical. I am a firm believe in knowing everything I possibly can in all fields a near impossible task to achieve but at least I always have something to work toward. This is also the first step. Find something new to learn. Play with examples of what you want to do. Dig around others code base to get a taste of how things are being done under the hood. Then look for similar things and think about what other ways there might be to solve the same/similar problems. Check blogs about design and development to track down the latest and upcoming trends and seek current solutions and try to develop your own solution to these elements. If something can be done using a technique you already know investigate why someone elses might be better.

Experiment

This is where I gain most of my understanding of something I am looking at for the first time. When I actually am hands on with the code. At this point I have usually read any documentation that accompanies a bit of code so I know how to use, what it is intended for, etc.

If you have found an example of a technique I like reproducing it on my own from scratch. Just read through the example code and try to find logical steps in which the processes occur. In the case of front-end UI types of things I follow I like to have the code up and then follow it based on the order in which someone interacts with it. So first find any event handlers and see any functions they fire. If there is any setup code/functions we can find those and work our way backward to see what they needed to do for the rest of the process to continue smoothly. Change things, break things and then see what cause things to break and fix them.

When developing from scratch test as I go to avoid any errors immediately. In this case test frequently when changing the code because in changing just a few lines of code and then testing if anything goes wrong it’s usually pretty easy to determine where the error is occurring especially if it’s a semantic error not a syntax error. Seeing the result of my own code solidifies it in memory and it is my own codebase so I am already more familiar with it if I go back to look at it for reference. I like to keep examples of learning something new as bare and simple as possible so I have a nice clean reference for the next I want to use it or if I want to give a demonstration of how something works to another developer.

Expand

Once you gain an understanding apply this knowledge to a project you are working on or create a new project to create which will include this. I was working on building a url shortener in PHP and SQL from a tutorial and used this project as a way to apply some new AJAX knowledge I had just gained to refactor all of the javascript that was being used in a better way I also added in some event handling and front-end validation to really tighten up the front-end and prevent the need for back-end validation to kick via my refactored AJAX request. So I was applying and improving code which was entirely new to me while working on a greater project which was done in PHP and MySQL which is far from my area of expertise. If you can apply knowledge and rebuild a technique yourself and find areas to expand and improve it than it’s likely you have a true understanding of what you have learned.

Keep in mind that there are so many different ways to solve a single problem. There are also many correct ways to solve a single problem. However the best way is heavily dependent on the project and all of the factors that are at play. I generally look for as simple a solution as possible. Simple doesn’t always mean the least lines of code either. Simple is easy to understand and logical. Other things to keep in mind are how well a solution plays with the rest of one’s code base and how easy it will be to change, update and refactor should the project need.