Programmers don’t need to be “smart”
I recently overheard someone say that to be a programmer, “you have to be smart”. Putting aside the debate of what it means to “be smart”, I can say with absolute confidence, that this is not the case. A good programmer/developer/webby person will typically flourish with four traits (of which “smart” is not one).
- an interest in languages or math
- enjoys problem-solving
- learns well on their own
- works well on their own
While these are the four traits that have allowed me to earn a rewarding living as a developer, I’d say 1, 3, and 4 are even optional depending on your work environment.
The best programmers I know are the best because of personalities and traits that match well with the industry, not anything related to IQ. And like most work, human skills are the top of the requirements list to be successful and get things done.
Changing HTML markup for WordPress galleries
The default markup for WordPress galleries is a little… odd. If you want to change it, the
post_gallery filter is what you’re looking for; see
wp-includes/media.php around line 671 for the goods.
Jetpack and wordpress.com accounts
With the new features in Jetpack 2.0, it’s more important than ever to keep straight your wordpress.com accounts – particularly if you’re developing sites for clients that will be using Jetpack. I won’t pretend to understand all of the details yet, but some quick research and perusing of the sparse, user-centric Jetpack site led me to the following.
Continue reading Jetpack and wordpress.com accounts
No need for that $locale business anymore
It’s no longer necessary to include a locale file within your theme’s functions.php; check this ticket: http://core.trac.wordpress.org/ticket/20448
I’m sad, Montreal.
I’m sad, Montreal.
What we’ve always suspected is finally coming out in the Charbonneau Commission: we work hard, simply to be robbed (on a stunning scale) by those supposed to be looking after our interests.
Montreal is sick; let’s get you fixed up.
What, Why, How
I’m thinking the #WordPress Codex and Theme Review guidelines would benefit from a “what, why, how” approach to documentation:
- What: describes the function or requirement
- Why: why is it this way? Best practice, performance, security concerns?
- How: a simple and clear code example of how to use or implement what is being discussed