Here are some random thoughts that have been bouncing around my head for the last couple of days. 

Keep your codebase in a releasable state.  If you are practicing scrum or some other iterative process, make sure your code is releasable at the end of an iteration.  I’m not exactly sure what you do if you’re practicing something like Kanban, but the idea is the same.

Release your application often.  Even if it isn’t to production, go through the process of releasing your code as frequently as you can.  This will force you to design everything to streamline the release process, and it will help identify barriers to releasable code sooner rather than later.

Better yet, automate your releases by practicing continuous deployment.  Even if it is only a release to a lower environment, continuous deployment can be a huge time saver.

One of the best ways to learn a new application and its codebase is through fixing defects.  Unlike new features, which often contain some subjective requirements, defects are usually much more cleanly and tightly defined.  Does that mean that an application with a lot of defects has a shallower learning curve than one with higher quality?

There are few rules in software development, and the answer to any question about software design is “it depends.”  Limiting your abstractions may be the right thing to do, or introducing lots of abstractions might be a better choice.  Sadly, as developers, we have to evaluate each scenario and make the best guess we can with the information at hand.  Then we have to undo that decision 6 to 18 months later when we realize we made the wrong decision.

If it feels more like work than a hobby, You’re Doing It Wrong.  You’re going to spend 8 to 10 hours a day, 5 days a week, “working.”  You better find something you enjoy, or that’s 40-50 hours a week you’re going to spend being miserable.

There.  I feel better now.