My regular job mostly consists in developing mad experiments aiming to improve the editing experience of WordPress.
Sometimes, though, all our teams rotate to maintenance tasks for a while.
In my latest maintenance rotation, I had to fix an issue caused by a very odd incompatibility between one theme and the WordPress.com API.
After a relatively long investigation that also involved other people, we eventually pushed a fix.
The customer support person who reported the issue thanked me, then inquired about the process, and if there were books they could read to learn more about how to investigate issues.
It occurred to me that I have never given much thought about my own process, and if it could be learned from books.
Book Smarts?
I’m not book smart.
I’ve dropped out of university, and mostly self-taught programming off dodgy sites in the early noughties, where I’ve learned countless bad practices that I’ve spent years to overcome.
I don’t consider myself a great programmer, even.
I’ve got plenty of deficiencies, I suck at math, I have often trouble following the clever code written by my more talented colleagues, and I still need to look up the reduce and memoize docs, even if I’ve used them hundreds of times.
Street Smarts!
Nonetheless, I think I’m good at what I do, and it’s 99% thanks to my experience.
I’ve spent about 2/3 of my career working as a solo developer.
On one hand, I had nobody above me to teach me the tools of the trade.
On the other, whenever I screwed something up, I had no safety net below me, nobody to ask for advice or help.
Inevitably, I had to suck it up and figure the bug out all by myself, spending hours scouring Stack Overflow, trying to narrow the investigation in any possible way, discovering new tools, new functions, new debugging methods, and so on.
Year after year, I slowly turned from web developer to problem solver.
Being a problem solver doesn’t strictly mean that I excel at solving problems. I’m no Mr. Wolf.
But I’m pretty good at sleuthing and dissecting the problem, tracking down bugs across countless codebases, different environments, old browser quirks, uglified files, exotic programming languages, and whatnot.
Growing up as a jack of all trades (which is unavoidable — maybe even essential — when you are a solo dev or a freelancer) gave me flexibility.
I can dive into anything really, and I’m usually able to come out on the other side with a pretty good idea of what is happening.
For me, this was an excruciatingly slow process that spanned many, many years of hands-on work experiences.
I’m sure others got to my same level in a fraction of the time, but I really doubt my skillset can be learned from books.
Applied Practice
I was hired by Automattic as a JavaScript Engineer to work on Calypso, the WordPress.com dashboard built with React.
But Automattic is an extremely dynamic work environment, and all its developers, sooner rather than later, will start touching all parts of the stack of many different products, built with different programming languages, frameworks, and build systems, and often just loosely integrated between each others.
We all soon realize that excelling in one particular skill doesn’t cut it: we need to be adaptable to any curve ball that these different, unfamiliar products can throw at us.
We are encouraged to take responsibility and ownership of everything, which makes us better at observing and interpreting the big picture.
My street smart skills turned out to be very convenient for such environment, and I’ve thriven in it so far.
If you think your specific skills aren’t perfect, but you have a penchant for deep-diving into many different codebases and figuring out how to improve them, why don’t you drop us a line and try to land an actually nice job for a change? 🙂
Copons Blog 