A philosophy of enjoying oneself first, and foremost, will provide the greatest encouragement to continue going forward.
The Macy’s-Gimbels Approach
I often describe things as Mallory-Everest, and along those same lines I also use the descriptor Macy’s-Gimbels. Feel free to follow the link back to my explanation of Mallory-Everest … or continue reading to better understand what I am referring to when I say something is Macy’s-Gimbels.
This all started after my umpteenth watching of one of my all-time favorite Christmas movies: Miracle on 34th Street, (the original 1947 release in black and white … the colorized version is nice but I digress). There is a wonderful scene in the movie where Kris Kringle (portrayed by Edmund Gwenn) recommends a lady shopper go to the competition (Gimbels) for a gift the store (Macy’s) did not have in stock … and thus providing the impetus to coin the phrase, “The Macy’s-Gimbels Approach”; and in this case how it applies to real customer service.
To see the Movie click here.To hide the Movie click here.
Here is a link to the movie online (although noted on the site you can download the DivX Plus Web Player for Windows or for Mac from these links).
The scene I noted above can be found at … um, well … I’m going to watch the movie (again); I’ll try to remember to note the time and add it later 🙂
Multitasking = Bad
Multitasking is one of the worst ideas ever to be conceived … do one thing at a time; do it well; do it right; then, move on.
Perhaps the above is overly simplified, but the idea behind it is really simple. Trying to do more than one thing at a time is simply asking to be interrupted at any conceivable moment; and, what’s worse about the situation is the one that will be generally interrupting you is yourself.
If you really need to get something done, then focus on that particular item and get it done.
If you have a list of items that need to be accomplished, prioritize them first; then get them done … one at a time.
You’ll thank yourself for doing this, twice. First for not interrupting yourself, and second for doing the job well and getting it right.
It’s The Little Things
Some may say “don’t sweat the details” and I would reply, “but it’s the little things that make it great”.
The attention paid to the finer details of code will always play an important part in how well the code works. The documentation written to excess will only serve to better explain the code down the road when updates and improvements are made. This is not to mention the great benefits it will also serve when other developers start working with the code.
Almost anyone can write good code, it really doesn’t take much with today’s search tools and the wealth of knowledge shared in the developer communities, but …
… sweating the details is what great code is all about; and this new project is being kept to this basic tenet.
Beginning A New Project
Although I have been considering this idea for some time I only just recently started putting code to (digital) paper on a new project … and, yes, it is WordPress related. What can I say? I really enjoy working with the platform.
Now, the reasons I am writing this here:
- I am still available for other projects … just letting everyone know this one is important, too.
- I am approaching this project from an entirely new view point
- I know this will be good for the community
- I know this will be good for myself
Once I am satisfied most of the features are working in a stable alpha-code state I will be looking for some adventurous individuals …
… but, what is this new project?! Stay tuned for more information.
Code Documentation
Some may say the code is the documentation … and others may reply with the documentation is the code. I believe both are true; and, more importantly, they are not mutually exclusive.
First off, the code quality should be (if possible) in a format that is easily (human) readable. The idea is to provide the person looking at the source code an easy-to-follow layout as well as providing sensible separations between the various code structures.
The code should also be semantically written using naming conventions that help explain why each code construct exists, as well as providing an appropriate indication of what the code will do.
The above two ideas do not preclude the requirement for document blocks to be also included as appropriate in the code, as well as additional code comments explaining specific details that may not be readily apparent from reading the code.
Essentially, the point of view I recommend with documentation is quite simple:
Imagine it is six months later and you did not write the code yourself. Does the documentation you provided properly explain the who, what, where, when , and why of the code? … because in six months time, if you have not been working with the code all along, it will likely be just like you never wrote the code in the first place. Now, imagine what another developer would be going through.
Good UX is not solely in the realm of the end-user.
Most importantly, write the inline documentation when developing the code. You will find it much easier to write the documentation while you develop the code versus going back after the fact and writing it then.
Also, I find it much easier to focus on the task at hand if I do the document framing (read: basic outline) prior to writing the first code structure. Ideally this will also provide the scope of the code as well.
Coding Standards
Over the last 15 or so years, I have learned many things about writing code; about documenting code; and, about providing support for this same code, too.
Coding Standards
When writing code, I make every effort to keep a consistently structured format with the use of white-space, tabs, etc. This helps to provide clear delineation of code elements and structures, but more so it provides easier to read code. If code is easy to read, it is easier to understand.
In my opinion, this is a hallmark of quality code. I cannot recommend strongly enough how important it is to keep a project’s code consistently structured, formatted, and documented. If this is not consistent, it could easily give an impression the project itself is not consistent … or worse, flawed?! It’s also much easier to edit well structured code.
My structuring convention, since I tend to focus on WordPress related projects, is very similar to the coding standard documented on their codex page: WordPress Coding Standards.
A project’s code should also implement a consistent version number convention. This can be as simple or detailed as you want but I would recommend it also have its own explanatory documentation.
For example, a recent article I read regarding the Semantic Versioning Specification provides “a simple set of rules and requirements that dictate how version numbers are assigned and incremented.” I’ll likely be adopting this, or a very similar specification for my projects.
Another important coding standard is using a consistent naming convention:
In computer programming, a naming convention is a set of rules for choosing the character sequence to be used for identifiers which denote variables, types and functions etc. in source code and documentation.
Wikipedia – Naming Conventions (programming)
The keys to quality coding standards are these:
- adopting and/or creating documented specifications; and,
- being consistent in how they are applied.
Look for more upcoming posts in this series … next up: code documentation; followed by, code support.
Honesty
The more honesty a man has, the less he affects the air of a saint.
Johann Kaspar Lavater
Conspiracy Is Optimistic!
Conspiracy is optimistic! You can shoot the bastards! We can have a revolution!
Steve Jobs – Wired, February 1996
To see My Thoughts click hereRead My Thoughts later
I could not help but think: wow! I know I have been quoting a lot of Steve Jobs recently (I really like quotes from interesting people) which have been arriving in my inbox via a subscription to DailyLit’s “The Wisdom of (Steve) Jobs” Click on this link to DailyLit if you would like to receive these in your inbox.
WordCamp Toronto 2011 Takeaway
Although WordCamp Toronto 2011 was last weekend there were several ideas I will be taking away from it in regards to future development, best practices, as well as some interesting concepts and discussions. To keep it simple I’m just going to list these items (with their inspiration):
- Install MultiSite for use with Theme Demos (Ron and Andrea Rennick)
- Look into PhoneGap to make HTML5 WebApps for the iPhone * Review Sencha Touch as well (Trevor Mills)
- Review all of my Themes to add a ‘description’ parameter to the register_sidebar and register_sidebars definitions * Update the codex, too, if it is not done yet (Jeremy Clarke)
- Monetize What You Do (Christopher Ross)
- Develop “site” plugin(s) (Rick Radko)
- Use inline documentation * PHPDoc (Chip Bennett)
- Review do_action and apply_filters in place of conditional function checks (Chip Bennett)
There were many more ideas and great pieces of advice, as well as some really sound tips and suggestions through the day (which I simply made myself comfortable in the Developer track for the duration).
The above were just the ones I specifically made note of (literally using the “Sticky Notes” program). Don’t ask me why I didn’t use EverNote at the time, but all of the above are now listed in an EverNote list for future reference and recollections.
Some of these ideas I am already putting into action, such as the inline documentation in a PHPDoc style; some items I had already been looking at; and others are more as reminders to keep thinking about what can be done.
Just like my site tagline at WPFirstAid: It’s WordPress … anything is possible!