To learn is to share. To share is to teach. To teach is to learn.
How Fast Is Fast?
My daily work related duties centre around providing support. Mostly technical but sometimes very general but one of the questions that comes to mind often is how fast should a replay be sent to a technical support request?
Don’t get me wrong, a quick response is generally at the top of my list but that does not always mean an immediate response is required.
My main focus for the day is to reach and maintain an “inbox zero” state for the primary support incoming access points I manage, and I do this quite well. I also generally will, in a sense, rapid-fire responses back to the support requestors until an inbox zero state is reached. The ideal being to create a sense of an online conversation without the use of a messaging system. (This is a constraint I am bound by in the support environment I work with … and a subject for a future date.)
Given the above, this does lead to times where it is more sensible to wait a short period of time (generally only five minutes or so … sometimes more, sometimes less) before sending a response. For example, (remembering that text has no tone, just what you imprint upon it) the email may be one of frustration, misunderstanding, urgency or any combination of the three; or, any other customer concern they believe needs immediate attention … every person believes their site to be vitally important and that is generally going to be the case no matter what.
What do these paused replies do? In many cases, having read over the issue then taking a moment to consider the underlying “emotions” in the description will help provide a more accurate, clearer response. Immediately replying to a scathing review, an unreasonable demand, or for that matter any request that cannot logically be accomplished in the timeframe implied (or in some cases specifically detailed) could lead to more animosity from the user. Explosive situations need to be defused first.
How does “inbox zero” affect all of this? Once your incoming support requests are cleared then you will be able to take these few moments as needed to focus more specifically on the more problematic issues being brought forward whether that be something specific to the product, or the person using it.
Also remember, all of the “easy” questions that you get to answer still need the consideration of a difficult question; but, by their very nature of being “easy”, they will also allow you to be quick to provide assistance as needed. Enjoy these support requests and take full advantage of them; recognize these easy questions are providing you more time for the difficult questions you will inevitably get in the day.
One more thing, when someone takes the time to say “thanks for the quick response”, or “I didn’t expect to get an answer right away”, or most anything recognizing your efforts to be efficient with your work, recognize the users time in all of this as well. Not every user of your product is going to tell you they have a problem so addressing the ones that do is that much more important so the ones that don’t tell you will become less as time goes on.
Work With WordPress Not On WordPress
“Working with WordPress” and “Working on WordPress” may seem synonymous but the philosophy of each phrase will definitely affect the code you share and support going forward.
When you work with something, it becomes a partnership, a collaboration, a team effort and more often than not an ongoing relationship; while working on something is more like getting it done and moving on … like fixing a car.
All of the major functionalities of most any application, plugin, theme idea can be found in WordPress core code already, the key is in the creative implementation of that code.
Obviously you may need to add some custom code to accomplish building your idea or adjust some specific functionality to be applied differently but that is also the basis behind using the various API and hooks readily available in WordPress. You just need to extend where needed and fine tune the rest. It’s WordPress … anything is possible!
It’s all there for the … taking. Yes, you can take the code and use it as you see fit, just remember to give credit where credit is due and provide the proper attributions.
Not sure where to find something, or even if it exists? Try these developer references:
- https://developer.wordpress.org/ (the new!)
- http://codex.wordpress.org/ (the old, but still useful)
Maybe you just need a nudge in the right direction? Have you tried any of the numerous Slack channels where many WordPress community members share their time and thoughts (not to mention ongoing development conversations)?
- https://make.wordpress.org/chat/ (get started)
- https://wordpress.slack.com/messages/announcements/ (get involved!)
Stay in touch with what is happening with WordPress development, too. Keeping up with new functionality and corrections to core will only benefit you in the long-run. It might even spark an idea using some new functionality being added to core.
As you continue to improve your own WordPress projects, especially with a community of thousands contributing back to it, you will most likely need to build less and less on WordPress while moving to building more and more with WordPress. You may even be one of those contributors that makes life easier for another WordPress developer.
Why work on something, some might even say re-inventing the wheel, when you can simply get behind the wheel and start driving with WordPress from the start … or work with WordPress and help others get the start they may need to bring their awesome ideas to life.
I will always advocate working with WordPress, what are your thoughts?
Competition
If they’re not trashing you, they’re not worried about you.
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.
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.