In my ongoing quest to find good books that are both manga and non-fiction, one coder in my network recommended "The Adventures of Johnny Bunko" by Daniel H. Pink. It shares six essential career lessons through a man with a dead-end job summoning a fairy-esque career advisor with magic chopsticks.

Stay with me here, as I found the book valuable. Especially since I'm early in my career and could use some advice. To my surprise, each tip fit well with my coding career so far. So much that I wanted to share those insights with you all.

So I asked myself, what if instead of "The Adventures of Johnny Bunko," he had been a programmer by the name of Johnny JavaScript? How would the six career essentials have changed?

Turns out they really withstand the test of time.

1. There is no Plan

The book's first, and in my opinion most important tip, is you can never plan for what twists your career will take. Who knows where you'll be in five years, or even one. Industries may change or die. You could relocate to a new country. Trying to plan long-term is virtually impossible.

As someone who writes JavaScript, I completely agree that long-term plans rarely work out.

Frameworks, languages, libraries, patterns, they all change rapidly for coders. You can't learn a few tools and last on those for more than a few years (at best). If you learned Angular a few years ago, now React is in higher demand. If you learned a CSS float-grid framework, now CSS Grid has arrived. Even if your tools stay the same, you'll need to update them for any related changes and deprecations.

Successful programming careers are instead built on fundamentals like:

• Learning to learn
• Understanding and writing documentation
• Popular programming methodologies, like the MVC model or object-oriented programming
• Basic syntaxes and rules common in all languages, like data types and functions
• Communicating well with others, especially designers
• Choosing the right tool for different jobs.

These are skills we learn for fundamental reasons, because they're inherently valuable in the face of change. No matter what tools, frameworks, or companies you work for, these will be helpful.

My original plan was journalism, yet here I am in my current job using Ember, a pattern library, React in my spare time, and dabbling in Rails and UX design. All in a city I never expected to move to, with a company I'd discovered at a local meetup. Who knows where I'll be in five more years?

Wherever I am, my fundamental skills will help. That's the only real plan.

2. Think Strengths, Not Weaknesses

A while back I started learning Ruby and Rails, since it was one of our app frameworks. It was also because while I was strong on the front-end, my back-end coding was lacking. I thought improving where I was weak was important to long-term success.

After struggling to get close to where my coworkers were, I realized the next lesson the book shares: focus your strengths instead of your weaknesses. I was nudged along by two realizations:

1. I didn't enjoy the back-end as much as the front-end - it didn't give me a feeling of flow. I could get lost in CSS and JavaScript for hours without tiring out. Improving on and using it made for a much better workday than Ruby. It kept my job from feeling too much like work.
2. Splitting my energy between too many things thinned my efforts and hurt my progress. If front-end is something I'm good at and enjoy doing, I need to be willing to go all-in on it. That's what would make me a pro, not just a hobbyist.

So don't obsess over building up your weak areas to those of the pros around you. Learn enough to be dangerous in any areas you need, but know which ones fit you best. Front-end? Back-end? Information Architecture? UI and UX? Data and Analytics? There's lot of options to focus on in the programming world.

The "full-stack developer" meme is a virtual myth. Find something that gives you flow and pour your passion into it.

3. It's Not About You

Like most young coders, I tend to focus most on personal projects: how cool they are, what skills they show off, the new tools I learn through them. I've put hours into them and released them to the Internet, hoping people would love them.

Unsurprisingly, this never happened.

Then I made a repo of markdown files full of notes about programming - syntaxes, tips, reminders, etc. I even included some nonfiction notes to record valuable insights. I made it to better retain knowledge yes, but I also made it thinking others would find it useful.

// An example of my notes:
// a small snippet from my notes on Ember Models

##### Loading Multiple Models

If you need to load multiple models as a single promise object, the `RSVP.hash` tool lets you do this. It accepts a hash, where each value is a promise. This way you can have a promise activate once all the promises are resolved, such as a loading screen being toggled off.

model(params) {
  return Ember.RSVP.hash({
    character: this.store.findRecord('character', params.character),
    teams: this.store.findAll('team')
  });
}

It was my first real repo I made not just focused around my work. It's also my most popular repo by far, with over 40 stars and several forks.

I never noticed what all this meant until I read this lesson from the book:

You're here to serve, not self-actualize.

The most popular repos I've seen are popular for an obvious reason - others find them useful. It's why frameworks like Bootstrap, Foundations, Rails, and Ember are used so widely. They took their skill and focused it outward, not inward towards vanity projects.

It's also why, when I asked a job recruiter years ago what skill people want from coders the most, she said good communication. Most programmers she's found talk to computers great, but can barely speak with humans. This limits the value they can bring from sharing their knowledge with others.

As a young coder this has been a tough lesson, but I'm getting there. I'm slowly getting the confidence to pick up and fix issues no one has taken yet, which my manager has approved of. A larger goal of mine is contributing to open-source projects, even just a little, but I don't think I'm there yet. But I want to do more of these things since I know it helps everyone's career, which ultimately comes back to help me too.

But this pragmatic reason aside, I try to keep one principle is mind: Before you code, check your ego at the door.

I try to remember this even for personal projects. It's why when I practiced Vue, I made a commute calculator so people can see how wasteful their drives to work are.

Not the best way to help others, but baby steps.

4. Persistence Beats Talent

Many times I've tried to run an app and it crashes. The first few times it was a long and frustrating process, trying every idea I got it right. I always thought once I got better, I could intuitively find the issue faster.

Fast-forward a few years, and I am finding these build bugs faster. But only because they're the same as bugs I've seen before. Whenever there's a new one, I'm back to fighting tooth and nail to fix it. It's always a struggle, like the code is testing my will to keep going. I only fix the bug by digging in my heels and trying with new and old tricks. No matter how much I learn, getting better relies on me being persistent with how I solve problems like these.

This book confirmed a lesson I've been learning each time: the world is littered with talented people, but if they're not persistent in how they learn and work, people who are will pass them by.

I could be the most talented programmer in the world, able to write eloquent functions, thorough documentation, and utterly DRY CSS that doesn't make the angels cry. But if I wasn't persistent in learning and improving, none of that would matter. Persistence is the main reason I, and the more experienced developers I work with, can:

• Debug complicated bugs
• Build a large app to scale
• Manage issues with legacy code
• Keep up with industry changes
• Hit tough deadlines

Talent matters, but these require more persistence than talent. Otherwise all these essential tasks will be half-finished and the company flounders.

That's why persistent is so vital in programming. Persistence doesn't just beat talent, persistence is one of the most important talents. Because every skill is only as strong as your persistence in improving it.

5. Make Excellent Mistakes

Programming is all about mistakes sometimes, isn't it? After a year or two most coders will have found:

• Code they wrote became obsolete after a few days
• Tests meant to prevent mistakes not catching new regressions
• The wrong frameworks and methodologies were chosen (often cause they're new and shiny!)
• CSS written in haste that coders tear their hair out over for years
• Changes pushed that inadvertently crash servers on a Friday afternoon

All these are typical for most apps or software. Thankfully all these mistakes give a learning experience. We learn what other tests to include, which frameworks work for different needs, and what CSS won't incur God's wrath. Coding is built on learning and improving.

The caveat is this only works when we accept and learn from our mistakes. When something goes wrong, breathe and say out loud, "I did this wrong. I'll avoid the same mistake next time by doing X."

An "excellent mistake" is one where the benefits of how we grow from it outweigh its initial consequences. At that point it's not longer a failure - it's now a success.

The great thing about coding is that it's all about making mistakes, and we can turn all these mistakes into excellent mistakes.

6. Leave an Imprint

This may not be the most important tip in the book, but it's last because it's the heaviest. You must ask yourself one question:

Did my work matter?

Our lives are finite. We should use our time to make a positive difference. To leave a good imprint behind us. But people often avoid this heavy question until they're older. By then it'll likely be too late. Even if you don't like the answer.

Considering how what we program increasingly affects the lives of others, this is an especially important question for us. Ethan Marcotte wrote a great article on how design is never neutral, and I believe this applies to coding. The code we write has many far-reaching purposes and effects:

• How information is organized, or hidden, from those who need it
• How personal data is collected, analyzed, and even sold
• How users interact with interfaces, which can either enhance their experiences or manipulate their attention
• How accessible our applications are, such as for people with disabilities or in disadvantaged areas with worse Internet access.
• How algorithms can enhance, or worsen, the experiences of workers and users alike.

My point is the same from Marcotte's article - much as we may believe our code is neutral, it never is. Especially as programs increasingly define society, relationships, jobs, and livelihoods.

This tip is about knowing what kind of imprint you leave. Your work will always leave an imprint somewhere - with an ethical, moral, or political effect. It may be tiny or enormous, but it will be there. Know what kind of imprint you want to leave. Not just with your career, but with your whole life.

Ask yourselves these questions now before you look back and wish you'd done it differently. They truth may not set you free, but it can at least nudge you to a better path.

Conclusion

"The Adventures of Johnny Bunko" helped take many inklings I'd had about my career and crystallize them into actual advice. Despite being written ten years ago, it's stayed relevant. One could even argue it's only become more important as the coding industry has grown.

A blog post like mine could never replace the book itself, so I highly recommend buying a copy, both for the advice and the quirky presentation. At the very least I hope these tips, from my perspective as a coder, show just how useful this book can be.

Because as much as I love coding, that love can't just carry me for my whole career. I've got to learn how to play the work game. These six tips helped me realize it's not just possible to learn the work game - coding makes it worth learning.

Realizing that may be more important than any career advice I've heard.