I am twelve weeks into becoming a self-taught programmer and I am still having a blast. While I often feel like I am behind schedule there is no denying that I am enjoying the process.
Part of what inspired this whole journey in the first place was remembering how much fun I had when I dabbled in programming all those years ago. That child-like sense of wonder hasn’t gone away as my wife can attest to.
One of the things I learned more about last week was Responsive Design and the importance of Mobile First.
When I worked on my Portfolio Project a few weeks ago I was all excited that I was able to use media queries to make the page responsive to different screen sizes. As good as that was, I now realize I did two things wrong.
For starters, I did the layout backwards. I designed the page for full-size screens first and then added media queries to make the page responsive to smaller screens. The best practice is to design the page for mobile first and then adjust the layout as necessary for larger screens.
This leads to the second mistake, which was to let standard screen sizes dictate my media query breakpoints. Instead, I should have set the breakpoints based on how the content looks as the screen gets larger.
Designing mobile first not only ensures that your site looks great on smaller devices, which what many people use to consume their content on now, but it also ties in naturally with how Cascading Style Sheets work. Using a mobile-first principle when creating responsive webpages leads to fewer conflicts in your code.
Setting breakpoints based on how the content looks as the screen gets larger creates a better-looking layout and leads to fewer media queries. Trying to account for all the popular screen sizes in your code is a lot of work. Plus, in a few months, a new generation of devices is going to come out and make all those settings obsolete. The mobile-first principle lets you start small and then expand the screen size, adding the appropriate media queries as the look of the content changes.
This article does a great job of explaining these concepts and more.
Being able to find the solution to a problem is a critical skill for a programmer.
As a new programmer, these resources are great but they can often lead to situations where you don’t actually understand your code.
The code might work but you don’t know how or why.
I experienced this last week with the z-index property.
TIL what z-index actually means, which is funny because I have used z-index in my code before. pic.twitter.com/KItsFZ4rT7
— DLV Programming (@DLVProgramming) December 14, 2017
I have used z-index before but I never really knew what it did. I used it for my Holiday Tree Project to style the garland and create the snow effect but that code was based on snippets picked up from around the web.
It is easy to fall into the code snippet trap, especially for new programmers. You pick up a little something from here, a little something from there. Your project ends up being a sum of all these pieces.
Best case scenario, you end up with a working program that you only understand a small fraction of. Worse case scenario, your program doesn’t work because you have different sections of code conflicting with each other and you don’t understand enough of it to find or fix the problem.
This doesn’t mean you shouldn’t use code snippets or search for answers on the web. Just remember that is only one step in the process. Once you find the answer, make sure you understand how and why it does what it does.
Don’t be the guy who uses z-index in his code without knowing what it does, no matter how cool the results.
Time to get serious! pic.twitter.com/JrkesRFmNE
— DLV Programming (@DLVProgramming) December 17, 2017
I have heard a lot about Algorithms over the last few months. Much of it could be summed up as “Algorithms are hard”, so I was both nervous and excited to finally start working on them.
That is a story for next week though…