Being a develubber is hard. For the past two days, I've been studying the payments code from when a project is finished to paid. This is the first project where I have to sift through existing code in a codebase that is very daunting to me.
The past two days have also been difficult for me because I'm trying to do other things on top of this one task. I've taken 3 meeting with coaches, called a potential intern (I should have said no to this), chose to follow-up with the Shark Lab folks that I met last week over email and Facebook, got sidetracked with the Overdeck foundation giving $1M to DonorsChoose and wrote our own press release, and on top of that it snowed today so I worked from home. I should have gone to the office today.
If I learned anything from these two days is that if I want to be a more effective develubber I should do one thing and do it well. That means do the develubbing and say no to everything else. This is really difficult for me to do.
For the past 4 years my brain has learned that I am most effective when I multitask. Multitasking when develubbing I think slows me down. I don't know if I have a real solution for this other than to be extremely self disciplined.
Let's say that I become extremely self disciplined about saying no and only focusing on develubbing. What is new that is difficult about develubbing?
There are certain things about Rails that I am unfamiliar with. This is the first project in a long time where I've had to read a lot of Rails code. I think I should spend a weekend reading a Rails book just to refresh my memory. Again, I think I am missing the fundamentals.
That said, I think one of the best ways to learn Rails is to learn by doing. This is something that I saw that was very effective at the Shark Lab. Everyone there learns by doing. If you don't know how to draw blood from a shark, don't ready a book. Just try it and learn from someone who knows how. This is where Jeff has been very helpful for me. After I did a first pass at describing what happens between finished and paid, walking through my questions with Jeff was very helpful. Though, I think we would have been more effective if we were sitting next to each other in the same room. Though, maybe something like ScreenHero would solve my problems.
It is easy for me to get sidetracked and once I get sidetracked I can get overwhelmed. Because I am very critical of every part of the product, I get get sucked into a hole really quickly. For example, my task is to document what happens between finished and paid. I found that when I get to things that are designed poorly (i.e. payout form, collection_started mailer) I tend to want to document those things right away. I cannot stand when the visual portrayal of Experiment is not what I expect it to be. That makes me feel like Experiment is lowering our standard for what we claim to be good design. Because I get sidetracked and start to go down these trails, I miss the main mission which is to document what happens between finished and paid.
To become a better develubber, I really need to force myself to stick to the hardest problems. It might take me longer to figure out and it may make me more frustrated, but I will learn faster. I think what would help me here is if I had longer periods of uninterrupted time. And, I should be at the office not in my apartment where I can wander to the kitchen to make food and then fall into a food coma and pass out.
With all these things said, I am still very much enjoying being a develubber. I feel like I am learning every day and even though I still feel like every day my key learning is there is so much I don't know I don't know, I really do enjoy that feeling. The more I learn the more things I know I can learn in the future. I know that if I keep learning all the things eventually I will run out of time to learn the rest of the things I want to learn. I guess that is an okay way to die.