index.md (3484B)
1 --- 2 title: "Getting (And Staying) Motivated to Code" 3 date: 2009-01-21T00:00:00+00:00 4 draft: false 5 canonical_url: https://www.viget.com/articles/motivated-to-code/ 6 --- 7 8 When you're working on code written by another programmer --- whether a 9 coworker, open source contributor, or (worst of all) *yourself* from six 10 months ago --- it's all too easy to get frustrated and fall into an 11 unproductive state. The following are some ways I've found to overcome 12 this apprehension and get down to business. 13 14 ### Tiny Improvements, Tiny Commits 15 16 When confronted with a sprawling, outdated codebase, it's easy to get 17 overwhelmed. To get started, I suggest making a tiny improvement. Add a 18 [named 19 scoped](http://ryandaigle.com/articles/2008/3/24/what-s-new-in-edge-rails-has-finder-functionality). 20 Use a more advanced 21 [enumerable](http://www.ruby-doc.org/core/classes/Enumerable.html) 22 method. And, as soon as you've finished, commit it. Committing feels 23 great and really hammers home that you've accomplished something of 24 value. Additionally, committing increases momentum and gives you the 25 courage to take on larger changes. 26 27 ### Make a List 28 29 In *Getting Things Done*, [David Allen](http://www.davidco.com/) says, 30 31 > You'll invariably feel a relieving of pressure about anything you have 32 > a commitment to change or do, when you decide on the very next 33 > physical action required to move it forward. 34 35 I like to take it a step further: envision the program as I want it to 36 be, and then list the steps it will take to get there. Even though the 37 list will change substantially along the way, having a path and a 38 destination removes a lot of the anxiety of working with unfamiliar 39 code. 40 41 To manage such lists, I love [Things](https://culturedcode.com/things/), 42 but a piece of paper works just as well. 43 44 ### Delete Something 45 46 As projects grow and requirements change, a lot of code outlives its 47 usefulness; but it sticks around anyway because, on the surface, its 48 presence isn't hurting anything. I'm sure you've encountered this --- 49 hell, I'm sure you've got extraneous code in your current project. When 50 confronted with such code, delete it. Deleting unused code increases 51 readability, decreases the likelihood of bugs, and adds to your 52 understanding of the remaining code. But those reasons aside, it feels 53 *great*. If I suspect a method isn't being used anywhere, I'll do 54 55 ```sh 56 grep -lir "method_name" app 57 ``` 58 59 to find all the places where the method name occurs. 60 61 ### Stake your Claim 62 63 On one project, I couldn't do any feature development --- or even make 64 any commits --- until I'd rewritten the entire test suite to use 65 [Shoulda](http://thoughtbot.com/projects/shoulda/). It was mentally 66 draining work and took much longer than it shoulda (see what I did 67 there?). If you need to add functionality to one specific piece of the 68 site, take the time to address those classes and call it a victory. You 69 don't have to fix everything at once, and it's much easier to bring code 70 up to speed one class at a time. With every improvement you make, your 71 sense of ownership over the codebase will increase and so will your 72 motivation. 73 74 ### In Closing 75 76 As Rails moves from an upstart framework to an established technology, 77 the number of legacy projects will only increase. But even outside the 78 scope of Rails development, or working with legacy code at all, I think 79 maintaining motivation is the biggest challenge we face as developers. 80 I'd love to hear your tips for getting and staying motivated to code.