I ended up making a ton of progress on a side project recently, and was super excited about the quality of code I was churning out. What's really amazing is how far I've come recently in my skill as a developer. Earlier this year I was pretty proud of building a simple URL shortener, that basically does one thing (shorten urls) and was completely untested. It was just three months ago that I experienced a bout of paralyzation on another side project due not not knowing how to write tests - since that app was substantially more complicated. But now in just a weekend I was able to write a lot of fully tested code that I'm really proud of. Here is why I think I've improved so much in just a short amount of time.
1. Writing A Lot Of Code
I've made over 1000 commits this year according to Github ranging from simple one line fixes to massive feature branches. I'm guessing that I coded about twice as much this year compared to last year, when I first really got into coding. This is because with all this practice I've become much faster, and as a result can output a lot more code in the same period of time.
2. Being In A Supportive Environment
I've been at Doorsteps since May, and (along with our amazing consultants at Neo) this is by far the biggest reason I've improved. I'm treated well, I have lots of support, I have many people I can go to to ask questions, and I am highly encouraged to learn. There isn't pressure to deliver, just an expectation that you should show up and do your best. Most importantly none of my colleagues have ever lorded their knowledge over me, and made me feel inferior, which is an all too common practice among software engineers. As a result of being in such a supportive environment, I look forward to working on our codebase, and am unafraid of approaching everything from a beginners mindset, rather than be fearful for my employment if I don't know something.
3. Doing Lots of Pairing
We are big on pairing at Doorsteps. Although we normally pair often, for the past month we've even been trying to pair even more. As someone who is just starting their journey to becoming a master software craftsman, this has been enormously helpful. I get to watch the thought process of senior engineers tackle all sorts of problems. I can ask questions, figure out the patterns they use to work though things, and then adopt these patterns myself. When I'm driving, I get their help immediately when I get stuck, and their suggestions for refactoring in real time. Without a doubt all this pairing has accelerated my learning tremendously.
4. Using Pull Requests
Beyond pair programming, we also have adopted a pull request model at Doorsteps. This means that when you start a feature, you branch out from the master branch, write your new code, then request another person on the team review it before merging it in. This other person adds a second (and often third) set of eyes on your code, and will usually find a few places that the code could be improved. Having my code critiqued has helped me avoid anti-patterns, and adopt best practices. Furthermore, having to review other people's code has been really helpful. I get to see how they solved the problem, which is sometimes a different way I would have approached it - a great learning exercise.
5. Doing Lots of Test Driven Development
I'll never forget the first TDD demo I saw while I was at the Flatiron School. A senior engineer at Pivotal Labs had a brand new application and before he wrote a single line of code, wrote a test first. The test failed, then he wrote the actual code in the app, and passed his test. My mind was blown - it's like he somehow had this magical instinct of knowing what he was going to do before he did it. I spent most of 2013 figuring out how to write application code, but was very fuzzy on tests. In fact it took me many months of doing TDD on our app at Doorsteps until something finally clicked. I now am at a stage where I can write a fully tested application. This is a huge step for me, and makes me a lot more confident of my abilities to branch out future in the future, knowing my code is much less likely to break.