Month: March 2017

How do we measure a programmers ability? Can we? I believe evaluating a programmers code to see how 'clean' it is would be a decent benchmark.

To write clean code, you have to do as Robert Martin says and "limit the amount of WTF moments you cause for another programmer looking at or working on your code". For me, this makes sense and seems like a good way of describing why clean code would be important.

When someone is viewing your code they are seeing how you think, how you come to a solution, and whether or not your code would cause more problems than it solves when minor condition changes come into play. In CSS, there are certain standards for how you write CSS code to style HTML. Not including the classes used from libraries, you want to limit the amount of classes and ids, only using them when absolutely necessary. Otherwise, you should be targeting the elements on the page using pseudo code like ':last', ':first', or 'nth:child()'. This allows for greater scalability, when your conditions undoubtedly change. For styles that need to be applied across a range of different elements, that is where adding a class would come in. Here's an example that helped me wrap my head around the power of elegant solutions.

Think about how a train operates, the track allows the train to move quickly and stay balanced. A train is simple, it's elegant, and the solution to mass travel at high speeds has been solved by the train for years.

When a train travels into a city environment, questions like, how does the wheel adjust to a flat surface, arise. However here lies the beauty, it doesn't have too. No adjustment is required, except slowing down of course. Instead it's one wheel, one train, and it can run on an above ground track or a track that resides below the ground.

In software development and as software developers this is what we should strive for. Finding solutions that can withstand the test of time. Obviously, technology is changing at an exponential rate, but that doesn't mean we can't push for a high level of code reusability.

Code reusability, is a corner stone of good software. The more modular the code is and the more able the code is to face varying conditions, is another way to measure a programmers ability to write clean code.

When we think about solving problems in this way it does require extra work, more thought out actions, but it allows more room for future adjustments.

Questions like.. is this the best solution? How does the code I'm implementing affect future actions? What problems does this code cause, when changing it slightly? While learning responsive Web design, these issues have been personified.

Here's an example, I adjust the padding of my image to better fit the flow of my website at 1280px+, all though as it scales down, issues arise. Well you may tell me that media queries will save me, and all though it's true to a degree, you have to hard code each break point.

Now imagine if I was having issues with more than one element. It could be done, and it would serve as a temporary working solution, but only open the door to issues later on.

Moral of the story, take extra time to thoroughly plan out how the program will function from the methods to the flow of your website. Don't be afraid to step outside your comfort zone and stack overflow better solutions, that have longer life spans when new conditions are introduced.

The goal of writing clean code is to make your code easy to read and understand. Simple is better and less is more?

Lets think about how a train operates, the track allows the train to move quickly and stay balanced. The track to train wheel is an elegant solution to cutting out the what if factor. A train is simple, it's elegant, and the solution to mass travel at high speeds has been solved by the train for years. 

When a train travels into a city environment, questions like, how does the wheel adjust to a flat surface, arise. However here lies the beauty, it doesn't have too. I pondered this question and thought about an adjusting wheel, well after all of 5 secs I could already imagine the slew of issues with that solution. Instead it's one wheel, one train, and it can run on an above ground track or a track that resides below the ground.

In software development and as software developers this is what we should strive for. Finding the simplest solution that achieves our end goal and also allows for future unknown conditions, like the environment change when a train enters a city. Staying away from overcomplicating our code and packing too much in one area is the best method for future expansion.

When we think about solving problems in this way it does require extra work, more thought out actions, but it allows more room for future adjustments.

Questions like, is this the best solution? How does the code I'm implementing affect future actions? What problems does this code cause, when changing it slightly? Here is an example that I experienced when I was learning responsive web design.

In responsive web design, the end goal is to make websites that scale nicely to smaller or larger screen sizes. The most common method for doing this is using Twitters bootstrap library to make the process easier. However, lets imagine I was writing without bootstrap.

I add an image to my page and then begin making the window narrower. As the window shrinks, the image stays the same size. To counter this, I use media queries to resize the image manually at each breakpoint. A breakpoint for this specific instance, is when the image size is no longer compatible with my page.

So problem solved right? I can just write 10 or so media queries and the image scales to how I want. However, even though it has the appearance of responsiveness, we are only setting ourselves up for future issues. Now lets say the original image was not right, we want something bigger. A lot bigger.

We resize the initial image and oh would you look at that. Everything is on fire. The previously set media queries are now off by the degree we changed and the only way to give the appearance of responsiveness is to manually reset the values for each media query.

Now this is only a single image, what if a week later I needed to change five different elements. Now that's a huge task, many lines of code, hours of tweaking, and all so a week after that we can repeat the process. Well, thank god for bootstrap, and other built in responsive functionality we can take advantage of.

Hopefully, the idea of spending hours and hours in an infinite loop of minor changes because we didn't properly think through future expansion, scares the hell out of you. So spend some extra time prior to touching the keyboard, think it through, and try to remember in software development the first solution you think of isn't necessarily the best choice.