8 Coding Habits You Should Add To Your Workflow: A Guest Review of The Pragmatic Programmer

Today, we have a guest review from Edgar Hurtado, a python enthusiast and PHP/ JavaScript web developer hailing from Valencia, Spain. Like me, Edgar is also predominantly self-taught, utilizing free online resources to his advantage to skill up.  I met him through the CodeNewbies community and even though his blog is new, I’m already an active reader.  I asked him to share his review of Andrew Hunt and David Thomas’ popular book, “The Pragmatic Programmer”. He happily obliged!


One of the most recommended books a code newbie can find when browsing through internet is this book. A simple search on Google typing books every programmer should read reveals this fact (e.g: 1, 2, 3). However, I always thought that this was a specialized book for professional programmers, something currently out of my scope.

Nevertheless, I heard one of the authors of the book, Dave Thomas (@pragdave), in two episodes of CodeNewbie (part I, part II) and he was very convincing in saying that the newbies could as well take advantage of reading it. Therefore, finally I made up my mind and read it. It took me over 2 months to finish it with a path of 30 min – 1 hour of reading per day.

If you take in count the advice that Andrew and Dave give, you’re going to be a better programmer for sure.  However as a newbie, sometimes I feel that I can’t apply the majority of things I’ve read. Once you reach past the first half of the book, it starts to focus on things useful for big development projects. For example, there’s a chapter about testing and automation which convinced me that I should be testing more, but they talk about developing tools for automatic testing, and I think that will over-complicate the little projects I do (mostly school homework and bonfires from FreeCodeCamp).

On the other hand, the things I did really understand make the book worthwhile.  Some of the advice I want to include in my workflow are:

  1. The DRY principle (Don’t repeat yourself) is not just related with using functions in your code, its influence should affect all the knowledge written in the project, for example the documentation. This is achieved by writing the documentation in your code and then use some documentation generator that looks on your code and makes the docs automatically from it. You write it once and have it in different formats.
  2. Store information in plain text files which are more likely to last over the years without compatibility issues (something that already happens to me with .doc, .docx and .odt files).  The data that a program uses should be on a plain text file rather than inside the code.
  3. Always comment your code, but the comments should say why you do something, not how. How you achieve something is already written in your code.
  4. Know the best text editor you can use for all the writing tasks. This means using an editor for writing code, writing txt files, markdown, and so on (in my case I’ve chosen VIM).
  5. Automate as much as you can. Generating documentation, running tests, writing code (through snippets), etc. Something that I’m not doing at all and still having to figure out how to do it.
  6. Fix issues as soon as you detect them. If you let them pass in your code for “later fix”, they’ll spoil the code and more bugs will appear until the project becomes nonviable.
  7. Sign your work, be proud of it, and accept criticism from others, but above all, be critical with your own work.
  8. Design by contract. Before starting the project the boundaries should be clear (our customer requirements), and we should develop towards meeting those requirements. No less but no more because it’s easy to fall into a spiral of improvements that will make the project never ready for shipping.

As you can see, even though I think there are a lot of things in the book that I can’t use right now or are beyond my current coding skills, “The Pragmatic Programmer” is still an excellent book.  What’s more, I’m sure that I’ll read it again in the future when my skills were improved to extract more useful information.

In conclusion, I would recommend you to read this book, or at least the first half of the book if you’re a new programmer, no matter what your skill level is.


Edgar S. Hurtado is a biologist who discovered his passion for programming through MOOCs right after finishing his degree. That passion led him into vocational training on web development, with self-paced resources and the objective of gathering strong programming foundations for his ultimate goal: becoming a Bioinformatician. You can follow him on twitter @edgarshurtado.

Post edited by me. View the original.

Guest Post: Skill Up and Save by Attending Remote Cons

Remember Rashida’s great review of the JavaScript class hosted by Girl Develop It!  She’s back to give us a short update and share some advice. Please welcome Rashida as today’s guest contributor on attending conferences while saving travel costs.


A lot has happened since my last post. To recap:

– I finished the GDI Atlanta Intro to JavaScript course (barely…because I was 9 months pregnant)

– I had a baby the same week that I finished the GDI Atlanta course

– I set unrealistic goals for continuing to learn to code while on maternity leave

– I took a risk & started applying for jobs anyway

– I GOT A JOB (and it’s remote)

And this is only the beginning. Now that I’m officially in the tech industry, now more than ever do I need to continue to invest time in learning. In addition to the many unfinished tutorials in which I’m enrolled, conferences are another medium that I’m incorporating into my learning strategy moving forward.

Conferences are great way to learn more about your topic or language of choice and network with other developers.  I attended Rails Conf last year and had such a great experience. I was able to sit in on talks about topics I knew nothing about, which isn’t always a bad thing. Sometimes listening when you don’t understand can be a step in the direction of comprehension down the road.

Since Rails Conf, I’ve been very excited about attending even more conferences in order to further my skills and my education in web development. When I found out about JS Remote Conf, I knew I had to attend. Although conferences are awesome, they can also be expensive. If you have to travel to get there, the expense skyrockets. This is how attending a remote conference can work in your favor.  I attended JS Remote Conf from the comfort of my bed, in my PJs (thank you very much), for three days. The speakers live streamed their talks, while the sidebar contained a chat module where attendees could interact and ask questions.

Another great thing about attending JS Remote Conf was that even when I couldn’t tune into a talk, they were all recorded so that I could always come back later and watch them again as a registered attendee.  Some of the talks went entirely over my head, but as I mentioned before, that’s OK! You don’t have to understand everything as you are learning. The more that you consistently dive in and learn about challenging topics, the more it will stick.

If you are interested in registering for a remote conference this year, check out this site www.allremoteconfs.com to see what’s up and coming in the next several months.


Rashida is a Front End Developer for Black Fin, Inc.  Despite numerous coding hiatuses, she has become the ultimate comeback kid. When she’s not knocking out front-end tuts like a boss, you can often find her on Twitter @rashidathompson.

Part II of Andrea’s Raspberry Pi Adventures!

Fellow Our Code reader Andrea shares the latest update on video tracking project built with RaspPi in today’s Part II post.  In the first part of series, Andrea detailed her planning process, sharing logistics on materials, networking, and getting the microcontroller to connect. Click here to read Part I.


Where I was at the end of my last post: I had a pineapple, and a Raspberry Pi B+ [along with the camera module], which I had programmed to take a photo at a given time three times each day. I was testing the idea of using a power pack to provide power to the Raspberry Pi.

Using my power pack turned out to be a bit of a fail.  It was a power pack I’d been given for free as a promotion by a mobile network, so I didn’t have the highest of hopes for it. While it did supply adequate power to run the Pi without the rainbow square in the corner (which indicates not enough power to the Pi), it didn’t hold enough power for it to run for more than a short amount of time. It was more in terms of hours, than days. Weeks would have been the best scenario for a portable power supply. I ended up moving an existing extension lead, and used a charging cable I had for a previous phone, secured with a bit of Blu-tack to make sure it wouldn’t move the Pi around at all. Plugged in, I left the Raspberry Pi running for a few days to see what it would produce.

I also had to play around with the placement of the Raspberry Pi. I’ve played around with cameras a lot, but I wasn’t sure what the camera module would be like. The official documentation told me that the camera was fixed focus, with the depth of field being from 1m in front of the lens to infinity.  You can read a little about focal length and depth of field here.

Placing the pineapple 1m in front of the lens wasn’t going to work. For one thing, my window sill wasn’t that long, and it would make the pineapple much too small in each photo. It was time to get creative! I knew other people must have had the same issue; time lapse photography is a pretty popular Raspberry Pi project, so I took to the internet to see how they were dealing with it.

A few sites and forum posts tried to reassure me that I could in fact change the focal length of the lens by delicately turning it, but considering I’d just managed to snap the small plastic frame I’d bought to hold the camera module, I wasn’t about to go anywhere near the lens with a pair of pliers! Some of the more DIY Raspberry Pi discussions online introduced me to the idea of using a lens from a cheap pair of reading glasses. Suddenly it was like the clouds were parting above me! I consider photography a hobby of mine, so I was familiar with the idea of using lenses to bring a subject in closer and fill the frame. I also knew of a camera shop around the corner from where I work, so I decided to drop in and discuss what I wanted to do with someone.

lensI prefaced my explanation with “Now, this may sounds a bit odd, just bear with me!..”  Thankfully the guy had heard of the Raspberry Pi before, and thought my project sounded kind of cool! He wasn’t too familiar with the camera module itself, but when I explained that the lens was pretty small, (around 1cm wide- just estimating), he pulled out a drawer of various lenses. For someone who loves photography, the sight of that drawer was pretty sweet! I explained that the depth of field started around 1m but I wanted to bring that in to probably about half that distance, but that I wasn’t completely sure exactly how close the subject would be. I ended up getting two Hoya lenses, a +2 dioptre lens, and a +4 dioptre lens- because the effect of the lenses is cumulative, that meant I would be able to get the effect of +2, +4, or +6, depending on how far I decided to sit the subject from the camera. You can read about dioptres here.

Because I’ve positioned the camera module inside the Raspberry Pi case, I had no real way to attach the new lenses. There are small clips at the top/front to hold it, which is quite nice–keeps it all together.  The Raspberry Pi inside the case and the cables were already Blu-tack’ed into place, so I thought that Blu-tack’ing the lens to the front of the case seemed like an okay solution. I had previously considered using black electrical tape, thinking that it also might cut down on any glare, but was worried that it might leave a residue on the Pi case and also on the lenses, so decided against it.

admin-ajaxI attached the +2 lens to the front of the Pi case and the difference was obvious! I was super impressed with the images that were being produced! It felt great to have images that were so well-focused on the first try after fighting with the camera module for so long to get ones that were almost okay. I stayed with the +2 lens: the subject filled the frame nicely and the lines and edges in the image were crisp.

The HDMI cable I used to connect the Pi to the TV I was using as a monitor doesn’t get left in place when I’m not using it- it’s a pretty awkward location, and the cable is quite thick. Whenever I’m finished tinkering around with the Pi for a while I unplug the cable, and then use my phone as an overpriced level to make sure that the Pi’s case (and the camera inside!) are level.  This just makes sure that the photos are as consistent as possible when I stitch them together to make a video.  It would be kind of funny/weird if someone got seasick from watching it though!

Now I had to leave the Raspberry Pi and the pineapple, cross my fingers and hope for the best!


A Kulbaba: When she’s not playing with sugar or getting covered in chocolate in my day job as a pastry chef,  she’s busy with all sorts of geekery!  Andrea blogs mainly about learning to be a front-end web developer, and her tinkerings with a raspberry pi.  Follow her on Twitter @AKulbaba and read her blog Part Timer here.

Rashida Reviews Her Week in Girl Develop It’s JavaScript Class

Rashida’s #MotivationalMonday guest post grabbed so many readers’ attention that I’ve invited her to share her coding journey with us on Our Code.  In today’s post, Rashida discusses her first week in the Intro to JavaScript class sponsored by Girl Develop It.  If you haven’t heard of the organization, GDI organizes classes, lectures, online hangouts, and hack nights for women who are learning to code. Click here to find a chapter in your city, and join me on twitter to congratulate Rashida on completing her first week in the class by sharing this post!


As I continue my long journey to becoming a front-end developer, I’ve realized that I can’t escape learning JavaScript. I mean, HTML & CSS are great to know, but you won’t get very far only knowing markup languages if you want to become a true programmer.  From what I’ve observed, becoming an actual front-end programmer means getting down & dirty with JavaScript.

Overcoming Intimidation

My first attempt at learning it was in 2014.  I was enrolled in the Skillcrush Web Designer Career Blueprint.  The last module of the 3 month course was an introduction to JavaScript. Let’s just say I didn’t make it past the first 3 lessons.  I was so intimidated by the syntax that I gave up before I even started.  In the back of my mind, I knew that I’d eventually have to just suck it up and conquer my fear of JavaScript.  I kept thinking to myself that maybe it wouldn’t be so bad.  Every programming language has its difficulties, so trying another would only lead me down a similar frustrating path.

Over a year later, I’m now enrolled in another Intro to JavaScript class, hosted by Girl Develop It Atlanta.  I actually got pretty lucky because a fellow dev-in-training offered me her free voucher since she wouldn’t be able to attend due to being accepted into a coding bootcamp.  Who am I to pass up free learning?!  (Sidenote: thanks again, Mallory!)

Intro to JavaScript Class

This class is a 4-week series on Tuesdays throughout the month of October.  Each class is 2 hours long and there are around 20 ladies total enrolled.  The first class covered a brief history of JavaScript and basic programming concepts such as variables, data types, and functions.

// Think of a variable as storage for a value that you can go back & retrieve later
var firstName = "Rashida";
var lastName = "Thompson";
var age = 29;
var favoriteColor = "pink";

firstName + lastName; // Calling these 2 variables result in "RashidaThompson"

document.write("I want to order a pizza."); // This is an example of a string.  
//Strings are enclosed in quotes.

// Function example
function sayCheese(name) {
    var firstName = "Rashida";
    alert("Say cheese, " + firstName + "!");


So far, one concept that I’m having trouble grasping is the return keyword. I understand that using this keyword returns a value and also stops a function, but beyond that, I don’t understand its importance.   As I do more research, I’ll be sure to come back with a better understanding and an example of my own.

What I really like about the class so far is that we learn a concept and then we immediately practice it by writing our own code. No question is a stupid question and the learning environment is very open & relaxed.  Stay tuned for updates over the next 3 weeks!


Rashida is a marketer & mom-to-be transitioning into web development after many years of denying her techie roots. Despite numerous coding hiatuses, she has become the ultimate comeback kid. When she’s not knocking out front-end tuts like a boss, you can often find her on Twitter @rashidathompson.

Andrea’s Raspberry Pi Adventures

Next to my hackathon series, the most read series on Our Code was #MarchIsForMakers, where I offered an introduction to microcontrollers and wearable projects for newbies.  Due to the success of that series, I made a mental note to do more posts about computer hardware, specifically microcontrollers such as the Arduino and Raspberry Pi.  What I love about microcontrollers is that they are essentially micro PCs that can be programmed using Ruby (with Artoo or the SerialPort gem) and Python.  Things you can make with microcontrollers, such as heart monitors, small robots, drones, and casual wearables have caused an uptick in Internet of Things (#IoT) programmers and tinkerers.

Fellow coder and Our Code reader, Andrea, has been using RaspPi to create a video tracking project.  I thought it would be great to showcase her project for others who want to follow along and learn more about RaspPi’s capabilities.  She politely agreed.   Here’s Part I in Andrea’s Raspberry Pi Adventures.


I’ve been really excited about one of my personal projects for the past couple of weeks, but haven’t wanted to say too much in case it wasn’t going to be feasible for whatever reason.

My project: I’m a bit of a windowsill gardener, and I thought it would be pretty cool to create a time lapse video tracking the growth of a couple of my plants. A combination of confidence in my green thumb (courtesy of one of my friends) and too much time spent on Pinterest has resulted in a pineapple plant growing in my living room. We go through a lot of pineapples at my day job (working in a hotel), so sourcing one wasn’t hard. I just cut off the top of the pineapple, cut away all of the flesh from the stem, peeled away some leaves and trimmed away until I could see some of the roots.  At that point the pineapple stem was placed in a jar of water.  The remaining leaves stick out and sit on the edge of the jar, keeping the stem from going too far into the glass. The stem sits in the water for a few weeks while the roots grow, and once they’ve reached a few inches in length I moved the stem to a plant pot with soil. Slowly new leaves start to grow, and I’m at this point with my pineapple now.

The logistics: I decided to use a Raspberry Pi for this project. It’s an extremely cool, adaptable microcomputer, and you can learn more about it from their official site. I’ve been wanting to play around with one of these for a while, and this was the perfect opportunity! I was originally planning on using a wifi adapter to send the images (taken two or three times each day) directly to cloud storage, but in the interest of power consumption I’m just going to be saving the images to the Pi, and harvesting them weekly. Looking at power- power supply is cited as an source in a lot of online posts about Raspberry Pi issues, so I was happy to see that my power supply and cable did supply adequate power.  The Pi makes this obvious by displaying a rainbow-coloured square in the upper right corner of the display if it isn’t receiving what it deems to be enough power.

Since I’m planning on having the Pi on a window sill, and would like it to still be fairly discreet, I’m actually going to try using a power bank to power the Pi. Ideally, I would like the Pi to send me a notification (perhaps via Bluetooth, or over the internet) when the power drops below a certain level, but that may be slightly beyond me for the time being. I’m currently testing my power bank to see how long it can supply power for before it needs recharging.

A few weeks ago I ordered a Raspberry Pi B+, along with the camera module, and last week ordered a micro SD card, mount for the camera, and a case for the Pi itself.

Raspberry Pi microcontroller

Raspberry Pi microcontroller



Initially, I had hoped to set up the Pi using SSH, but I got a bit frustrated after a few failed connection messages, so picked up an HDMI cable this week, and set up the Pi using a television for a monitor, and a controller that we have for one of our other devices. Suddenly I was making great headway! It took a few tries, but I set up the camera and wrote the command to take a photo and save the file to a certain directory, and then edited the crontab file so that the script runs three times each day.

Raspberry Pi Welcome Screen

This is the point that I’m at, so tonight when I get home from work I’ll see if the Pi is still running and on my next day off, or when I next have time, I’ll connect it back up to the telly so I can see how many photos were taken, also helping me figure out exactly how long the power pack will last.

It’s also worth noting that everything here was bought separately- you can buy kits, but I wanted these specific cases: the one for the Pi itself, and that particular one for the camera.

I’d love to hear from anyone who has used a Raspberry Pi before! They seem really versatile, and I’ve been reading about some of the really creative things people have been doing with them!


Stay tuned to read more about Andrea’s RaspPi project.  I will be posting any followups here in the future.

A Kulbaba: When she’s not playing with sugar or getting covered in chocolate in my day job as a pastry chef,  she’s busy with all sorts of geekery!  Andrea blogs mainly about learning to be a front-end web developer, and her tinkerings with a raspberry pi.  Follow her on Twitter @AKulbaba and read her blog Part Timer here.

#MotivationMonday Series: From Back to Front-end…Again

This guest post is part of Our Code’s new #MotivationMonday series.  In this series, featured writers will be documenting their coding journeys as they prepare to become established and seek jobs in web development.  Our guest today is Rashida Thompson, who’s love for blogging and design fuels her ambition to become a front-end developer.


My name is Rashida, and I guess you could call me the comeback coding kid.  I *officially* declared my desire to learn to code at the beginning of 2014.  It’s now nearing the end of 2015 (what?!) and I’m in the same place that I started…at least it feels that way.

So begins my struggle story…

I’ve had a love for tech practically my entire life.  From constantly upgrading gadgets, creating numerous blogs, and considering majoring in engineering in college, I just knew I had to find my place in the tech world.  Flashback to 2011, I became serious about blogging and created my first WordPress blog.  Personal branding was a super big deal at the time, and I needed something to get my name out there so I could get my dream job.

I’ve always loved writing so I thought I’d be great at blogging.  Instead, I found myself becoming more interested in tweaking my theme than I did actually creating content.  Hmm…maybe I was on to something. I continued playing around with WordPress off and on for the next year and a half, but I needed more.

Enter Codecademy in 2014.  I discovered Codecademy online and decided to give it a shot.  I finished the HTML & CSS courses like a boss.  All of a sudden, I felt more confident that I could actually learn this scary code stuff and get a job!  Soon after Codecademy, I took the Skillcrush Web Designer Career Blueprint and sharpened my HTML & CSS skills even more.  I’m a visual person, so seeing the fruits of my efforts directly in the browser was exciting.  Until something didn’t work, and then it became frustrating.  Nevertheless, it was a rush.

Later into 2014, I kept hearing amazing things about a programming language called Ruby and how it encouraged developer happiness with its syntax.  Oh, and if you also learned Ruby on Rails, there was an abundance of jobs waiting on you for the picking.

Did someone say abundance of jobs and they pay well?  Where do I start?!

Long story long, I joined Rails Girls Atlanta, started looking up Ruby and Rails tutorials online and got to learning.  Except, it wasn’t very fun. This back-end stuff was supposed to be fun and exciting…right?

Regardless, I continued to spend copious amounts of time studying and set unrealistic goals for myself to really learn Ruby on Rails.  It just wasn’t sticking.  I kept taking hiatuses for coding in ridiculous acts of desperation.  Was I that desperate for a dev job that I forgot the real reason why I wanted to learn to code? It seemed so.

I had to reassess my priorities and my own reasons for beginning this journey.  Of course I want a job as a developer, but after having so many jobs that I didn’t like, it was time to actually spend my time on the things that I wanted to do.  So I’m back on the front-end track.  I love HTML & CSS and though JavaScript scares me, I’m ready to take it on, too.  The point is that there’s no point in doing anything if you don’t love it.  With the upcoming birth of my daughter in 3 months, now more than ever am I dedicated to pursue the thing that I love and create a career from it.  This isn’t just for myself anymore. This is for my daughter, who will grow up to see me as a role model, and potentially become interested in STEM herself.   I would be doing a disservice to the both of us by giving up now.  So I’m committed every day to learning even just a little bit.  My goal now is a junior front-end developer position by the beginning of 2016.

Is it lofty?  For me, it definitely is.  Is it possible? Absolutely!  I have a direction, purpose, and nothing can stop me now.


Rashida is a marketer & mom-to-be transitioning into web development after many years of denying her techie roots. Despite numerous coding hiatuses, she has become the ultimate comeback kid. When she’s not knocking out front-end tuts like a boss, you can often find her on Twitter @rashidathompson.

Insight on Developer Testing

Editor’s note: Our Code will be featuring more guests posts and interviews with web designers, developers, and engineers with experience in order to provide more insight on what it’s like to work in tech. These posts will be career-centered and discuss topics on an expert level. I’ll make sure to mark them for you all in the “News and Views” category. Enjoy!


Testing is a significant aspect of development. Yet it is often underrated and undervalued. Many developers are of the mindset that testing is only to be done by Quality Assurance professionals. Some even feel it isn’t “their job” to test. Others do it, but only begrudgingly.

Testing code, however, within the greater context of quality assurance, begins with the developer. The old “throw it over the wall” mentality has gone by the wayside in favor of iterative development that aspires to create higher quality systems. This requires a shift in thinking and doing.

Because testing comes in many shapes and forms, it is often a dynamic and expensive activity. But developers, in essence, test code all the time – whether through handling exceptions, fixing compilation errors, or debugging.

Testing that occurs at this level helps assure that the code base is robust and error-free. Integrative testing ensures the system functions as it should and behaves as expected when acted upon in predictable and unpredictable ways.

To what degree, then, should developers test? The most common form of testing is unit testing, writing code against a module with different inputs to test that different scenarios are handled. However, in addition to this, a simple smoke test of one’s developed feature, so-called “golden flow” testing, that runs through the normal end user path can behoove the developer in both assuring quality and expanding his or her comprehension of the system in totality. This kind of testing usually suffices but it depends on the complexity of the feature. In a TDD (Test Driven Development) environment, some Developers work hand-in-hand with QA professionals to feed the system a set of scenarios and then handle for such scenarios in-code, working in reverse from a “quality first” model.

At the very least, if your organization has no unit testing in place it is imperative to make sure your feature passes a basic smoke test before handing it over to QA. This helps increase efficiency by removing an iteration cycle. It also helps Developers think like testers, ultimately making their code more robust and potentially bug free.


Rice Om. is a technical and content marketing writer based in Los Angeles. She can be reached on Twitter at @OmaryMedia.