Slowing down to speed up, My First Project #2
Tags: beginners, python, career, tips
Published: 2019-03-15 00:10:24

---
title: Slowing down to speed up, My First Project #2
published: true
description: Further Lamentations of a rookie
tags: beginner, python, career, tips
series: ChiPy Mentorship
---

### Started from the bottom now we're here!

Twas a night like any other, the wind was blowing 60mph causing a windchill of -16 Fahrenheit in the Arctic that we call Chicago. I sat in front of my computer and pressed "Yes" when it asked if I was sure that I wanted to erase everything on my hard drive and then I waited in grim anticipation. I was free from the jungle of packages, libraries, and downloads but the tough part was yet to come, I had to rebuild from scratch.

![Burn](https://i.kym-cdn.com/photos/images/newsfeed/000/000/130/disaster-girl.jpg)

**Rewind**

*500 Screenshots on the Desktop
*1000 random files downloads
*100 random apps
*Every python package known the modern man
*RAM 15.99/16
*HDD 978gb/1000gb

I absentmindedly went about my life with no computer hygiene habits and it all hit me at once. I searched my computer for a file that had three copies, I couldn't tell image-1 from image-18, and I'd pay someone to find out where the latest version of this project was. In a huff of frustration I pushed everything to the git repo and committed first degree arson with full intent on complete destruction of all property then watched it burn. In reality, I factory reset my computer and started from the bottom so that I could get here. It has been a frustrating period but I've learned three things in this phase of the project and all have a direct correlation. 

**Containerization > TDD/BDD > Refactoring** ... in that order.

### Virtual Environments and Containers

One of the volunteers at the first project night asked our group where our virtualenv was and we all looked at him a bit clueless. He chuckled and said "Always use a virtualenv, always". It was a random side note as he helped us move forward but it became instantly relevant for me the next week as I was sending my computer back to ground zero. Once I was ready to rebuild my computer, I looked up virtualenv online and one of the first results was why I should use Docker instead. In a nutshell docker containers are apps packaged up nicely for isolation and portability. They are by far more complex than that but the definition served my purposes. I downloaded docker and other docker stuff and created docker accounts as I thought that it didn't seem much better than virtualenv. Turns out Docker, which may be awesome, is over optimization for my first project. It's also a new world of learning while I'm still learning the basics of getting this project off the ground. Virtual Environments served me just fine. Essentially, a virtual environment is a folder inside your project that houses all dependencies and requirements so that they don't affect your global settings. A simple "pip install" and "source activate" then we're off to the races.

![Over Optimization](https://imgs.xkcd.com/comics/the_general_problem.png)

Why should everyone use Docker, Virtual Machines, or Virtual Environments? In a perfect world, all projects will use the same version of every package and you'll never have to worry about in compatibility. In our world, one program uses python2.7 and the other uses python3.6, and yet another never upgraded past 1.6.1 for some hare-brained reason. These tools, to varying levels of success, allow you to work in all these programs in isolation. 

### Test Driven & Behavior Driven Development

As I began trying to insert my code into a django app, I realized that I should practice with a simpler program to see what this looks like running correctly. I happened up a book called [Obey the Testing Goat](http://www.obeythetestinggoat.com/pages/book.html#toc) while looking for Django tutorial. Besides the interesting title, the author made test driven development seems like one of those things you invest a lot of effort into upfront and then it pays for itself endlessly. TDD is the process of writing a failing test which evaluates how a section of code should behave then writing the code that makes it pass. Not in one fell swoop though, write the minimal piece of code that allows the test to get one more step forward towards passing. At first this is an agonizingly slow process which you feel adds little value but when I wrote first couple, I immediately saw the need. I encountered a major problem, I had code that couldn't be tested. As I was trying to figure out if it was my lack knowledge in testing or my lack of knowledge in coding, I realized that my code wasn't scalable. I performed many transformations then calculations and neither were stored anywhere. I was working with CSV's of increasingly larger sizes  and just moving everything in and out of dataframes. [TDD/BDD has two main tenants](https://qualityswdev.com/2010/03/24/the-purpose-of-test-driven-development-tdd/):

1. Testable Code: Testable objects have their dependencies passed in and are easily understood when reading. In other words, rather writing a function that uses another function, each function takes its own inputs and produces its own outputs. This is what's known as "loose coupling" and the opposite, "tight coupling" is a system of functions that depend on each so that if you change one then it has unintended consequences down stream due to the reuse of the function. Anyone can see the headache this would cause. 

2. Enable refactoring: Simply put, you can continuously improve your code with the confidence that it still behaves in the expected way.

My code was neither testable nor enabled refactoring which led me to my last bit of learning. 

### Refactoring

This might be a bit confusing because I technically couldn't refactor because I had to change the behavior of the code. Nonetheless, I learned that code that is designed well normally goes through multiple revisions before it is optimized satisfactorily. [Refactoring is a systematic process of improving code without creating new functionality that can transform a mess into clean code and simple design.](https://refactoring.guru/refactoring) 

### Takeaways

This phase has been about learning good programming habits. Habits that don't come intuitively but save so many hours and headaches in the future. It's a lesson that crosses multiple disciplines the difference between those make it and those that don't. Successful people form and improve upon productive habits by continuous practice. I've learned some of the good habits that make up a top notch software engineer. What's next to cement them into my regular process. I'm writing my code in a cleaner way and introducing a database that my code interacts with. I'm writing a full testing suite into my django app. Overall this is really coming together and I've learned more than I could have imagined. No wonder anyone with any amount of experience says that you should always be working a new projects to stretch your skillset.

#### Until next time