After 10,000 of software development

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.