Archive for the ‘Programming’ Category

Temporary Burnout…

Wednesday, April 13th, 2011

For two weeks recently I suffered from a significant lack of sleep. All of it completely self imposed by projects I decided to take on.

As I sat there about to go to bed at a normal time (11pm) for the first time in weeks, I took note of some of the side-effects I’ve noticed while I kept pushing.

  • it’s hard to concentrate, especially for long periods of time
  • Almost impossible to work through even medium complexity code in my head
  • It’s actually hard to go to sleep, maybe adrenaline kicking in?
  • Very little creative thinking, more like a drone
  • I suck at conversations, and I probably sound like an idiot
  • I can’t plan anything more than 20 minutes in advance
  • I experience random, dramatic outbursts of energy, and it’s a bit creepy for people around me
  • My co-ordination stinks, I keep stubbing my fingers
  • I feel achy and sore
  • It feels like my heart is beating faster (a weird thing for me) I did check it and it’s normal, just feels faster
  • Time goes by faster (perhaps explaining the heartbeat)
  • I can’t be bothered to listen to podcasts or any of the other sources of information that I usually do

Kind of like this guy:

I think this all means that I suffered a temporary burnout. It’s a very bizarre feeling, almost like I didn’t have complete control over my body and mind.

I’ve heard some people say that in order to successfully run a startup, you need to be putting in 60-80 hours a week to get things off the ground. After these two weeks, I full-heartedly have to disagree. I don’t see how that sort of schedule can lead to any sort of creative thinking, unless you’re looking for hallucinations, which depending on your goals, you just might be! I suppose in short bursts like this (ie: a week or less) for a deadline might be necessary, but working at this pace as a long term strategy just seems silly to me.

After this craziness I’ve decided to go back to a more regular schedule and already I’m starting to feel the side-effects I mentioned above fade away. I’m really looking forward to feeling more normal again

[UPDATE: Apr. 28th, 2011]: I just wanted to confirm again, I’m feeling fine.  I found this period to be a very interesting experiment.  I feel like I learned quite a bit about myself and specifically the type of person that I don’t want to be.

I Just Test-Drove My First Development

Thursday, September 2nd, 2010

I’ve been hearing about the benefits of Test Driven Development (TDD) for awhile now, but have never taken the time to try it out with any of my own work.

That was until this past week.

The code that I work in with my job doesn’t really lend itself to TDD simply because it’s all straight-through procedural code. The few functions that do exist would only be able to be tested by checking the raw HTML that the emit against an expected result. It’s possible, but extremely tedious so we just avoid it completely.

Recently though, I had the opportunity to write some new code, a small module completely independent of any of our existing code. I decided to give TDD a shot and see how things went.

It took a bit to get PHPUnit up and running on my dev machine, but once I did things started to progress nicely. I stubbed out some of my initial functions and got my tests failing, it was pretty exciting in the way that playing with new tech usually is.

I’m by no means a TDD expert, but here’s some things I noticed with my experience so far:

  • I REALLY need to refresh my Object Oriented design skills, it’s been too long since I’ve used them
  • By doing just the minimum to make the tests ‘green’ I wrote far less code than I thought I would
  • My current code is far too coupled, I need to watch out for that because it’s hard to test
  • Once some tests are in place, refactoring is awesome, you know instantly if you broke something
  • TDD feels like another safety net above source control
  • Writing tests isn’t as hard as I thought
  • TDD is a completely different way of thinking about writing software

I’m pretty excited to continue on this path and fully explore what TDD can offer. I’m thinking some continuous integration and maybe, just maybe, some automated UI testing down the road. It’s a brave new world!

What’s your experience with TDD been like? Any tips PHP specific or not? Please just leave a comment below.

After 10,000 of software development

Monday, March 22nd, 2010

At some point in recent history I hit a milestone and didn’t even realize it. It wasn’t a certain birthday (although next year is the big 3-0) or a 6 figure salary (sadly), but something a little more practical. The milestone I passed was 10,000 hours as a professional software developer. According to some it typically takes 10,000 hours of actively pursuing a skill before becoming successful at it. I don’t know if I can yet call myself a ‘successful’ developer, however recently I have come to a number of realizations that may be related to my 10,000 hours of experience. I’m not going to come up with 10 things just because it sounds good in a title, and I rather like the number 7, so lets see if I can put together 7 good realizations that can hopefully be useful to somebody.

Realization 1: The first production code I wrote was REALLY bad
It wasn’t exactly littered with GOTO statements, but the first thing I noticed when I went back to look at it was that it was really hard to read. My variables were all over the place, their names didn’t make any sense and the comments were essentially useless. Now that I have had Realization #5, I don’t write code like this anymore.

Realization 2: I really sucked at estimating how long things would take
I used to look at a problem and say ‘Ah, that’s pretty easy, it should only take a day or so’ (I still hear new people say this from time to time and cringe) However once I get into it, the time seems to melt away. I may get my original function up and running, however there’s certainly a bunch of edge cases I never thought of. Or, my favourite, the data I thought I had access to wasn’t actually available to a specific part of the code I’m working on, so I suddenly have to write a bunch of plumbing code. Perhaps the UI sucks once I see it working, or maybe I’ll be lucky and it’s just slow as hell.

Realization 3: A hack that works, in the end, still works
There’s doing it right, and there’s making it work. In the end, your customers don’t care how you do it, as long as you make it work. If it doesn’t work but it’s done right (which is possible by the way) then you wont have any customers so you’ll be screwed anyway. So, if you need a hack to fix something, go ahead, just note it in the comments and your bug tracking tool so that you can plan for it when you come back to refactor.

Realization 4: Deleting code is AWESOME
When I started programming, it was all about writing code, as fast as possible, so that I could see things moving forward. Now, my priorities have changed. I’ll look at some code and ask myself “Does this really need to be here?” The most exciting part of my day is when I get to hit the DELETE button on 100+ lines of code. Deleting code for me generally leads to more flexible software so that the next time I have to actually write some code, I often need less of it to get the job done.

Realization 5: Being able to read code is much more important than knowing how to write it, and reading code is harder than writing it
Let’s face it, unless there’s been a drastic development in cloning technology that I’ve managed to escape, there’s only one of you. There’s a LOT more of everybody else. You can be as efficient as you want, but you will NEVER be able to write more code than all of them. You don’t think the same as everybody else does, so you probably wont think about problems the same way others do. You NEED to be able to read someone else’s solution to a problem and understand what’s going on. If you don’t you’re very likely to introduce some pretty painful bugs into the system. I’ve been reading through Coders at Work and one of the primary skills each of the interviewees advocates is being able to read code. They’re way smarter and more experienced than I am so their advice is worth listening to.

Realization 6: Code doesn’t have to be perfect, more often then not it’s impossible
This is somewhat related to #3, but from a different perspective. It’s not worth it to hold on to code until you’ve convinced yourself that it’s perfect. Your users will tell you when it is perfect, so get your code out to them fast to get their feedback. If you’ve spent a month working on something and you feel it’s perfect, but your users have never seen it, you’re going to be a lot more apprehensive when you release it just because if they hate it you have just wasted a lot of time. I hate wasting time, it’s just not worth it. So, get your code out quick, get feedback, and iterate. It’s a bit of a cliche, but small course corrections are much less painful than large rewrites.

Realization 7: I feel like I know less now than I did when I started
I think this applies to any field, not just software development, but now that I have a bunch of experience at my back, my eyes have been opened to how much I DON’T know. When I started I felt that I was getting closer and closer to fully understanding what this is all about. Looking back that was incredibly nieve. Like an episode of LOST, each new thing I figure out exposes all these additional questions that I didn’t even realize existed. There’s just no way to know EVERYTHING. So don’t try.

While I started this post with a plan for 7 realizations, it’s not an exhaustive list, so if you have something you have realized with your experience, please let me know in the comments. Also, I’ve been writing this blog for awhile now, but I’m curious what others think of my writing, so feedback of that sort is greatly appreciated as well.

Don’t Forget to Ask Why

Thursday, February 4th, 2010

As programmers we are constantly  worrying about the ‘hows’ of things.

  • How am I going to make this function faster?
  • How can I write this query without joining 16 tables?

More often than not though, when writing code we forget to ask the really important question, WHY?  We take instructions from our clients and users and immediately get to figuring out ‘how’ we’re going to make it work.  We plan out how we are going to set the IDs for our DIVs and whether or not we want to use jQuery to make it work.  We get so excited to dig in and start writing code that we forget to ask that critical question to figure out why we need to write it in the first place.  Perhaps the reason that your client is asking to change the colour of a block of text is actually because the page layout doesn’t make sense for the situation.  Maybe they think a help button is needed next to your feedback form because your form labels aren’t making it clear what you’re asking for.

Sometimes the answer to ‘Why?’ will be an unjustified ‘Because that’s the way I want it to be.’ The thing is that is totally OK, at least you asked the question. There will be plenty of other times where the answer will reveal a deeper issue, and it’s sometimes even easier to fix those instead of making the change that was requested.  Which as a programmer, should appeal to your genetic desire to get more done by doing less.

So go ahead, the next time you get a change request, ask why, the answer may surprise you.

Diving into iPhone development

Saturday, July 4th, 2009

After many long months of decision making and cash saving, I have finally decided to dive head first into the wonderfully complicated world of iPhone application development. It is something that I’ve had in the back of my mind since I first got my iPhone almost a year ago, but at the time with my wedding and everything I wasn’t in the market to get myself started.

The first step on this journey involved me purchasing my first Mac ever, the 13″ Aluminum MacBook. I was tempted to go with the Mac Mini instead, however for the money the MacBook just offered too many advantages.

I have to admit, after giving it an honest shot, I’m really starting to like how OS X does things. It definitely isn’t perfect but it is a refreshing change for somebody who has been looking at a Windows desktop for the last couple years. The mental workflow took some getting used to, though I’m now feeling nearly as comfortable on my Mac as I do on my Windows machine, with only a couple of exceptions that I don’t need to get into during this post. Maybe some other time.

So far I have really liked the Xcode development environment as well, like everything else on the Mac, it just takes some getting used to. Before you know it everything just makes sense. Even though I’m sure there’s a ton of stuff included in Xcode, it all sort of hides in the background instead of being right in my face and adding to the confusion. I was able to build and execute a simple iPhone simulator app very quickly without having to resort to a tutorial.  I’ll admit that was a pretty exciting moment for me!

I still have an absolute TON of things that I need to learn before I start releasing stuff on the iTunes App store, but I’m going to do my best to document what I learn as I go.  I’ll also try to point out any useful resources that I find along the way.  I’m sure there will be plenty of surprises, it’s all very exciting!

Wish me luck!  Hopefully I don’t suck at this…