On the one hand it feels a little premature to write this post now. I don’t know yet if I will be a success or not. Somehow, despite the uncertainty, I’m somehow still here after a year. I’ve had my share of ups and downs. These tricks have helped me get though the challenging periods, now and at other times in my life (like grad school.)

1.) Have your fight song cued up and at the ready

I think the most frustrating thing about entrepreneurship is the number of elements that are out of your control. For me, I’m greatly impacted by changes to the Google search engine, and advertising payment rates. It can make you feel helpless when these things seem to be conspiring against you. And there will be times when it feels like their conspiring against you.

I have a collection of girl power ballads I like to play when getting discouraged. My current favorite is Fight Song, which dethrowned the long time champion – Watch Me Shine by Joanna Pacitti.

Music can be a great influence. Find what makes you feel invigorated, and be prepared to play it on loop in the background. Or maybe full volume. Whatever you need to get past the humps.

2.) Retreat to your strengths (even if their not your core business)

Sometimes the music pick-me-up isn’t enough. Sometimes the best way to boost your ego is to work on something you excel at.

I’m a good coder, but even the best coders get stuck sometimes. Rather than keep hitting my head into the wall when I’m getting frustrated with a particular bug or trying to implement a new feature, I sometimes refocus on another activity. Sometimes it’s a different app. Sometimes it’s photography. The trick is to find something that can help rebuild your confidence in yourself. It usually doesn’t take long before I feel my self efficacy start to return to it’s former state. A well planned half hour break can make me feel re-energize and ready to re-tackle that problem. If you suffer from impostor syndrome, like I do, self-efficacy breaks are a necessity.

3.) Spread out your weaknesses

Most people who start a business focus on the skills they have, and forget about all the other aspects that go into making a business work. A photographer is more than someone who excels at photography, a tutor is more than just a masterful teacher. There’s marketing, budgeting, financial record keeping, etc.

One of my bigger weaknesses is technical writing. If I ever decide I no longer want to be a non-employer, and I get successful enough, I’m hiring a technical writer. Or maybe a technical writer/social media manager. Since that’s not an option now, I like to spread out the technical writing and do a little each day. It may be tempting to put it off, but that makes for really unpleasant days when I do nothing but technical writing, get tongue tied over word choices and start to feel frustrated. I’m much more likely to get discouraged those days.

4.) Track Metrics

You don’t know how well you’re doing unless you track your progress. This month is shaping up to be a bit worse than last month, but at least it’s still twice as good as last year. If I wasn’t tracking how my business was operating year-over-year, it’d be easy to lose track of my overall growth.

I like to keep lists of accomplishments for the day. The more things I’ve gotten done (business related or otherwise) the more energized I feel to keep going. I’m more likely to be productive in the evening, and hit the ground running the following morning.

I lost two days and a half days this week updating from version 3 of the d3 library to the current version 4. What started out as a smooth transition quickly veered off course thanks, in part, to (1) functions being renamed, (2) Functions keeping the same name, but doing something different, (3) the defaults changed, and (4) class names changed.

1.) Functions Renamed

Giving the D3 developers the benefit of the doubt, there are times when it makes sense to change a function name rather then deprecate the old name and keep it along for legacy reasons: the functionality changes. This is especially true when the functionality change is ever so slight. A developer using a library may not think to retest every corner case. Changing the function name creates a compilation error, which will force the developer to re-test their code.

After reading the documentation, and adjusting from names like d3.scale.linear to d3.scaleLinear I noticed something was still not right.

I went from pretty graphs like this with nice subdued gridlines, readable axes and axis legends:

To (in my opinion) rather hideous ones like this:

Of course there were no errors or warnings to help me get started figuring what went wrong.

2.) Functions with the same name and different functionality

The first thing I wanted back was the horizontal grid lines. The problem was subtle, so subtle that I only found
it by carefully analyzing several v4 examples. Where I had been creating the grid by adding additional tick lines using the argument yAxis.ticks() (as in .ticks(yAxis.ticks())) I now had to call yAxis.tickValues() (as in .ticks(yAxis.tickValues())).

I’m not sure whether the functionality of ticks() changed slightly, or it’s returning a slightly different object that can no longer work as an argument. At least it’s now working. In fairness, ticks() is a function call off of the scale object whose name did change, however a warning that the argument could no longer be used to set the tick values would have been greatly appreciated. That is not a change any developer would anticipate needing to make.

3.) The defaults changed

Notice the difference in axis font sizes & fonts? The difference in fonts actually accounts for the difference in size. Previously I hadn’t explicitly set either font size or style, so it defaulted to whatever the page was set to. The only reason I can think of to change the defaults is if you needs some guarantee on size value to keep elements from overlapping. It’s a stretch, but it’s also a minor fix.

4.) The class name changed

This is the most aggravating change because it’s also the least defensible. Notice how my tick lines went from light gray to black? I had specified the light gray in my (cascading style sheets) CSS, a styling markup language. In CSS you specify an element either by it’s id or by a class name. Each element can have a single id, but infinitely many classes. When the class name changed, my css rules were no longer applied. It would have made more sense to simply add a new class name to the object, not remove it.

Avoiding future pain

Not updating is simply not an issue, not for web applications. Bugs will be discovered, vulnerabilities too. I owe it to my users to remain up to date so they can continue to use my apps. Still, there are things I can do to lessen future pain. I moved my graph declarations to their own javascript file, effectively creating an interface layer between my apps and d3. Now at least all the pain will be contained to updating a single file.