bob.tsThis article started with what began as a simple conversation with my son who was curious about my job. He was seven years old when this conversation took place.
ME: Programming is like your LEGO©s. I take all the parts and put them together.
SON: Sometimes my friends take what I have done apart. Then, I have to figure out how to fit it all back together. If the parts don't quite fit, then have to find a way to get them to work together.
ME: Putting LEGO©s together and building what you want can be tough. Sometimes it's very challenging.
SON: Especially trying to remember everything you've done. Sometimes you just need to take a deep breath and try again. It's like in the movie, Meet The Robinsons, "just keep moving forward."
Here's the actual quote from the movie ...
“Around here, however, we don't look backwards for very long. We keep moving forward, opening up new doors and doing new things, because we're curious.” - Meet The Robinsons
Code Review
This conversation actually occurred during a time when I had documented some issues on a code review (as a reviewer) and got a particular bad reaction from the developer. This issue got bad enough that I had to block the code from moving forward ... something I had never done before and have not had to do since.
That review and the conversation with my son were the reasons I wrote Better Code Review Practices.
This simple conversation rocked me deeply. Because of it, I started examining the core foundations of how I develop as part of a team.
Sometimes you just need to take a deep breath and try again. ... "just keep moving forward."
This can apply to so many areas of development; code reviews are only one area of impact.
Failing To Succeed
“You build on failure. You use it as a stepping stone.” — Johnny Cash
As developers, we fail ... all the time. The way I develop is based on repeated failures. I wrote some chunk of code that might work, it fails, then I rework the code to get a bit closer to what I wanted.
Write, Fail, Repeat ... a D.R.Y. anti-pattern?
I've often found myself describing my experiences as a developer (to non-programmers or junior developers) as continuous failure, "I've written so much broken code that I now know what not to do ..."
"Oh yes, the past can hurt. But the way I see it, you can either run from it or learn from it." -- Rafiki (The Lion King)
Banging Our Heads
"I have not failed. I've just found 10,000 ways that won't work." - Thomas Edison
Digging into a potential front-end issue (bug), I've been so lost in the code that can't see the more general patterns; feeling as if I am "banging my head against a wall." Allowing myself some time to reset and approach the issue from a different direction has often provided some critical information.
Fixing Bugs
"Have no fear of perfection — you’ll never reach it." — Salvador Dali
While tracking down bugs in code is painful, I believe seeing code I wrote changed by someone else even more so. Somewhere deep down, I see the code as mine and I didn't ask for their help. I'd like to think I'm, good at sharing ... I'm not.
Refactoring Code
"All men make mistakes, but a good man yields when he knows his course is wrong, and repairs the evil. The only crime is pride." — Sophocles
I've written some horrible code. I've also written some truly inspired code. Neither was done in one sitting ... and, neither was or will be perfect.
Having had the chance to work on an amazing project and write some of the inspired code I mentioned before (a script parser and engine) for a client, I can say with authority that refactoring the right way at the correct point in the development process can yield something truly amazing.
The original form of the parser / engine that I wrote worked. It actually worked pretty well. I asked for the time to refactor the code, not once, but twice (yes, I asked for two refactors of the same set of code in that initial meeting). To my surprise, I was given the time.
Through the first refactor, I was able to begin abstracting out the core functionality. Within the second refactor, I was able to implement some necessary tracking and optimization. Code that worked pretty well became something remarkably stable.
Over the next two years (with this code in production), a total of three bugs were found in a code base of over 120,000 lines with pretty heavy complexity. This success was solely based on the fact that I was allowed to take a step back and refactor the original codebase.
Adjusting CSS
Working with Cascading Style Sheets is one of the front-end areas of development that I am truly passionate about.
"Get a good idea and stay with it. Dog it, and work at it until it’s done right." - Walt Disney
There have been times when I've had to adjust the CSS I created because:
- Of mistakes I've made the the design.
- I didn't understand the requirements as I worked the design.
- The requirements changed.
Regardless of the reason for the adjustment, I've learned that my best work came when I took the time to take a step back ... to breathe and appreciate the work that was already in place. This often allowed me to clearly see the path forward.
Conclusions
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths. All our dreams can come true, if we have the courage to pursue them. If you can dream it, you can do it." - Walt Disney
In my company (Leading EDJE), one of the Core Values is, "Do the Right Thing, not the Right NOW Thing." In development, there are many things that can break or go wrong. These issues can't stop us; There are just as many opportunities to learn and grow, if we allow ourselves to see those opportunities for what they are.
I've learned that being a good developer means that I need to be able identify when I've learned as much I can on a particular path. To get to a deeper understanding means taking a step back, "take a deep breath and try again." My son saw all of this and got me to take a serious look at how I approached almost every part of the work that I do.
"Just because it's what's done, doesn't mean it's what should be done." -- Cinderella (Cinderella)
