Tired.

I’m so, so, so tired, and yet, I’m trying to show up every day.

To make a long story short, I’m deepening my skills in JavaScript using How to Learn JavaScript Properly, I’m working through the final few sections of Think Python, and I do projects in Codecademy to keep my syntax knowledge fresh. I’ve written one correct program for Project Euler, and I wrote another one that brought my computer to its knees, memory-wise. Udacity┬áhas taken a backseat, but I need to keep plugging along. Though the classes aren’t the best, I find that the exposure I get to various topics is invaluable.

Things got a bit hard; the time I have to study is short, the urgent-but-not-import distractions pop up ever more frequently, the things I’m learning are stretching my mind to the point where it is painful, and I just want to quit and be content with where I am now, but I’m still going to show up every day anyway.

I hope this works out.

Areas of Improvement as of May 2015

This morning, I put the finishing touches on a script I’ve been working on for the past couple of weeks. This was the second large project I’ve worked on this year, and it was far deeper in scope than the first project. Given its immensity (perceived or otherwise), I’ve noted several areas where I can improve:

1. Planning

Whether it is during the development phase or during the QA phase, I need to be better about working in a systematic manner. So far, my methods are more haphazard than I care to admit (“Oh, I need to code this! Wait…let me write this section first! Crap…I don’t have this function available.”) This scatterbrained method of writing code is inefficient and makes it hard to work in a logical, linear way.

2. Testing

So, this is related to the need to plan, as discussed above. Above all, my issues stem from laziness, but we all know that, in the end, there aren’t shortcuts when you want to do well. I used to write test plans, and they were super helpful. They don’t have to be extremely detailed, but I do work best when I give some thought to how I am going to test something.

In addition to test plans, I need to remember that there is no substitute for using the debugger, even if the way the script is written makes testing cumbersome. I can’t just read through something and find what’s wrong that way, especially when I’m the person behind the code.

3. Estimation

I understand there’s no way to get around providing estimates regarding how much time things will take, but goodness, I was off by about 60 hours for this project. Granted, I don’t think anyone else realized the enormity of this task, but above all, I just need to realize that I can’t always make a solid promise. This is annoying, I realize, but better to say admit ignorance than to apologize (repeatedly) for missing deadlines.