When You Do It Right, And On Time

Tim Oxley posted on Twitter a common frustration I experienced for 5 years.

If I rush it, there are errors, if I take my time to get it right, it takes too long. I hate this industry.

Around 2005, I stopped having this problem. Whether that’s the 10,000 hours rule, or the 5 year rule (can’t find citation, but it’s out there), that’s when I stopped hating my code after I wrote it. I clearly hadn’t mastered programming, nor Flash, yet life was a lot more enjoyable when a task/milestone/project was complete.

I knew I had reached it when I completed 2 projects, both different. One was a mid-size Flash widget project, about 2 months worth of work, and another mid-size Flex project, 4 months worth of work. When complete, I actually felt content with the code base. Granted, there will always be the desire to re-factor until the end of time; that’s good attitude to have as a developer. But I knew, then, that I had reached a milestone in my career. I couldn’t find context online, and it didn’t seem at the time my peers could relate (we didn’t have Twitter then).

That was 5 years ago, and although I take it for granted now, I thought it was important to bring up, and remember again for those who may be struggling today. That, and to point out a glaring misconception as well.

First, even to this day, I am continually learning. I am constantly spending time to get better at my craft. Whether that’s playing with new IDE’s, different Test Driven Development Strategies, or delving into other complimentary skill sets like Design & User Experience, the “mastering software” never ends. It’s a misnomer to claim I’ve “mastered my craft”. What I HAVE mastered is the ability to get a job done, with confidence, the right way. The “right way” is subjective, but so too is programming. As long as the client pays me, it solves the users’ problems, and the software continues to work beyond it’s intended lifespan, then I’ve done it right. That’s a great feeling to have, and you should celebrate reaching this point, as well as all the milestones you reach in your career leading up to this point. Reading Twitter daily, a lot of programmers remember to do this.

Second, there is a misconception anyone can reach this pinnacle (*ahem* plateau). The majority of software success comes from being setup to succeed. Success in this case meaning you feel like you did it right, and met your deadline. Now, in software there is no such thing as a deadline since users don’t know what they want, you’re forced to figure this out over an indeterminate timeline. The best you can hope for in large projects is an accurate velocity to emerge a few weeks in, with no technical debt throwing off your numbers a few months in.

Naturally, none of that works in Design Agencies. They have Flash Developers who utilize many of the same tools and technologies as Flex Developers do, but they have deadlines; real ones that are immovable. A lot of the above tried & (mostly) true practices are thrown out the window, and the technical debt mounts as the time in which a coder must complete her work decreases. This doesn’t take into account the fact that most Agencies don’t even realize they are building software. Design comps 1 week before the project is due? Happens all the time.

Given the circumstances that effectively set Flash Developers up to fail, they may never reach that 5 year pinnacle, even if they’ve already invested 5 years. Some may have already reached it! The point here is that while I’ve seen some happy mediums result, you’ll be hard pressed to utilize a lot of the more Enterprise/larger project focused practices and methodologies in an Agency environment. Thus, it’s perfectly acceptable to reach a pinnacle that allows you to master Flash Development at an agency.

Anyway, I just wanted to point it out again that, yes, things do get better. You will reach a point where you actually don’t loathe your code once you’ve written it. At that point, you get to focus on new problems, and/or focus more time on others. Also, remember that 5 years is just what I’ve heard corroboration from. We have a lot of smart people in our industry, and it’s reasonable to reach that point a lot sooner. Not to mention the fact we tend to work long hours, even after we’re no longer working on work which can get you there sooner.

Remember: If you write code, you feel like it sucks, and you want to make it better…. it’ll WILL get better. That, and you have the right attitude!

6 Replies to “When You Do It Right, And On Time”

  1. Awesome post! I feel that this can be broken up into a couple of smaller milestones. 1. Knowing that you can probably create any component (must be possible) they throw at you, 2. You feel good about the code you wrote to implement the components, and 3. Being able to architect a solution with confidence. Celebrate the small victories (or milestones)

  2. Can say that I’m somehow getting close to reaching that milestone right in my 5th year as a Flash Dev for the advertising business (AKA HELL!). Every time I commit changes to my component sets/framework, I tend to refactor a few classes just for improvement and not with the feeling that ‘I’ve done it the wrong way’. Getting better all the time I say.

    That post was of great encouragement to me. Thanks a lot!

  3. I too feel that I am reaching that plateau, I’m fortunate enough to work with a couple of really focused developers who always strive to improve, whilst looking out for each other.

    In my 4.5 years in the industry, it seems to me that design agencies still think that flash developers are just knocking up animations with bits of code here and there. The don’t realise that AS3 is now a serious language, and that means developers are writing applications with ever more complexity. We are constantly having to keep up with what ever is the latest buzz, PureMVC, Papervision, AIR the list goes on and on.

    One of the most important aspects of a project is the initial gut feeling about the timing you give to your project manager. You sketch a few diagrams, look at the components, maybe code up a prototype of your unknowns, then you give then a figure off the cuff that you BELIEVE is possible. What you tend not to do is consider the inevitible bugs and workarounds that will surface. My advice in reaching the plateau is you are in charge of this, do not be put under pressure to do something too quickly, I know this is not easy but giving yourself that little bit of padding will make you feel so much better as you start to gain momentum.

    Finally, we are a fantastic community, always looking out for each other and posting about problems in blogs, not to show how good we are, but in the hope you can help another developer avoid the pain you went through with a problem.

  4. Can not but agree. Its a truth and truth is always hard to face. But for right attitude nothing is impossible.
    Nice post. I have already spent more than 5 years and I do not think I have reached that milestone yet. About deadlines, yes, I do agree it gives a lot of confidence and satisfaction when its finished, and still there is someone on the back of my mind saying, we can do the codebase better.

  5. @jesse great post and I 100% agree however I think you are missing one important piece that goes hand in hand with the experience plateau. It’s like Donald Rumsfeld said “There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don’t know. But there are also unknown unknowns. There are things we don’t know we don’t know. ”

    Being confident in what you know and knowing what you don’t know, but not letting what you don’t know stop you from doing what you don’t yet know how to do. When you can grasp that concept and realize you will never know everything you can become a much happier and content developer because you are no longer chasing the eternally moving carrot. Instead you can become focused on doing the best you can with the resources you have available at that moment and also work towards enhancing those resources and abilities for future use.

Comments are closed.