My People

I am reminded, time after time, how fortunate I am to be surrounded by people at work and in my personal life who naturally get me. While not every single one of them may agree with me on certain ideas, they respect my views nonetheless.

I recently read a piece by the very talented Michael Lopp that summarized my feelings perfectly. Some of the aforementioned people live on the other side of the country while others are my neighbors — but ultimately, they are my people.

Michael outlines:

Your people are your people because while you may not always agree, you are comfortably on the same frequency. Because of this frequency alignment, you invest in them instinctively because while people look at you like you’re crazy, they do not. You answer their emails quickly. You arrange drinks when they are in town — always. They are your people and in a world chock full of people, your people are uniquely yours.

While I should always be grateful, it’s easy to take things — especially people — for granted. With the holidays in full flight, I thought that it would be the season to reflect a bit more on my life.

So, thank you to the people out there who get me. They are undoubtedly my people. You should be thankful for the ones in your life, too.

Simplicity Is Complicated

Edit #1: You are working on something important. It’s obviously something that requires a lot of attention and time. You know that it has to be simplified because you have to eventually explain why and what it is you did to people who may not have the experience and knowledge you possess. You mull over it because simplifying things is complicated.

Edit #2: A lot of important things can be complicated, but they need to be simplified so people can understand them. Writing, software, chairs, napkin holders, and cars are all examples of things that are complicated but should be simplified for everybody.

Edit #3: Since nobody really likes using complicated things, simplifying them is hard and takes a lot of time and attention to get it right.

Simplicity is complicated.

The Magical Room

Too often do we fall under the impression that building something, especially in the world of software, entails being handed a specification by the product and design team and then fleshing out the code for it. It’s sometimes treated as two step process, more or less.

From what I gather, this is an especially common pattern present at large companies where creative momentum is more restricted and thus structurally defined. In many cases, this practice dictates the roles of everyone involved in the building process: managers are responsible for communicating workflows and product features from designers to engineers and shuttling the questions and concerns that arise between multiple parties. And, for the most part, this gets the job done — product managers spec out a feature, designers mock it up, and then engineers go off and build it. If everyone understands and performs their respective jobs, the traditional conveyor belt of building software works and the product ships. Everyone is happy.

But, this process doesn’t work for everybody. And nor should one enforce this style simply out of tradition.

I am undoubtedly lucky to be working with a team that understands and respects the importance of iteration. The constant bouncing back and forth of ideas between product and engineering until a refined version surfaces from the depths is no easy task, though; it requires 100% participation from everybody involved and forcefully waives your personal feelings. This style of creation lends weight to the school of thought that design and engineering are inexplicably connected — that, the sum of them is ultimately greater than their individual selves. It is with this understanding that product creation should — with some degree of flexibility, of course!— be more than just a two step process.

With that being said, it is then without a doubt that the constant iteration and discussion of ideas between design and engineering inevitably yields a more thoughtful, polished, and delightful product than had they not worked in close collaboration. As Steve Jobs mentioned in The Parable of the Stones:

That’s always been in my mind my metaphor for a team working really hard on something they’re passionate about. It’s that through the team, through that group of incredibly talented people bumping up against each other, having arguments, having fights sometimes, making some noise, and working together they polish each other and they polish the ideas, and what comes out are these really beautiful stones.

While not everyone may subscribe to this process, it is essential to note that a team should be adaptable and open to change if a process does not work. Resistance to process adjustments in the face of obvious failure is an ingredient for creative disaster.

The road to shipping great products is not an easy one. But, with enough concerted effort, we can all smooth out the bumpy ride by not blindly adhering to die-hard processes. There is no win-all way to building delightful things but there should be a place where engineers and designers should feel free to express their views. I’d like to call this place the magical room.

The magical room is free of bureaucracy. It tolerates failure and encourages iteration. It welcomes many ideas but lets only the best ones stay. It bears witness to constant creation and destruction. It is a workshop, playground, and safe haven. It is free of thirty page product specs and sales forecasts. It discourages rigid rules and encourages improvisation.

It protects the creative process.

Unfortunately, this room does not exist in many organizations. And if it ever did and no longer does, it got torn down by the Hands of Process.

As a strong advocate of ensuring that this magical room continues to exist at not just where I work but at other organizations as well, I cannot help but champion building this room more than enough.

It is where great products are ultimately built.

Easy Reading is Damn Hard Writing

I often struggle with finding the right words to convey what I want to in my writing. Writing loquaciously is easy; writing simplistically is hard. Consequently, the problem is then invariably finding harmony in your wordplay insofar that you do not come off uninteresting or overbearing, or even worse—both! To a certain degree, many budding writers, including yours truly, fall into that trap, where they concern themselves more so with how they’re trying to write something, instead of what.

My middle school English teacher often touted the importance of “finding your voice”, which I wouldn’t doubt many of you have heard, with slight variations here and there. To this very day, I still don’t really know what that adage implies, but I can say that it’s valuable to find a groove in your writing so that you stop worrying about how the words will fit together — then, as long as you focus on your message’s theme, the words will fall into their places naturally. If it doesn’t feel right to use a particular word or to phrase something in a distinct way, then don’t do it. As with many things in life, trust your gut instincts; writing is no exception.

I admit I sometimes have trouble deciding if there is a right way to construct a sentence this or that way. When I was a much younger adolescent, I would flex my advanced SAT vocab when penning an academic essay to prove that I was “smart”. This was clearly demonstrative of juvenile behavior but I didn’t know any better back then. To my ego’s obvious discontent, my English teacher was good enough to tell me to stop spewing unsuitable verbiage because my sentence flow started to sound very unnatural. While you certainly could put a Ferrari’s engine inside a Prius, it doesn’t mean it’s going to be necessarily faster, more responsive, or better-looking; in fact, it would be a gross inconsistency of design and engineering, and actually quite aesthetically distasteful! The same can be said for writing: just because you can inject some fancy word here or slide in complex syntax there doesn’t necessitate it will feel natural and casually intelligible. I then instead present a more earnest solution: phrase your writing as if you’re having a dialogue with another person.

The caveat is trying to sound relaxed, but not too casual. Concerned, but not serious. Objective, but not indifferent. Sincere, but not saccharine. I believe — along with numerous other techniques and experienced-earned devices — that this is the magical tight rope that great writers have attempted to tread on throughout the years to perfect their balance. Only through countless attempts and embarrassing falls will a writer eventually master walking this tight rope.

One pattern I’ve noticed about great thinkers is that they tend to be great writers. They are economic with their words, but not frugal. Sentences are crafted carefully with clear intent. Obvious words are chosen. There are no redundancies. In a digital age in which we share many correspondences through text, the way you address people with your words reveals a lot not only about how you communicate, but how you think. As the famous Nathaniel Hawthorne once said, “Easy reading is damn hard writing.”

Selling Your Product

On a recent flight down to San Diego, I was sitting next to a woman who is the vice president of sales at a ice cream distribution company. We struck up a conversation and before I knew it, we ended up discussing technology. Now, like most normal people who aren’t engineers, she is not the most tech-saavy person in the world. Hearing her say “I just use my iPhone for mostly email, calendar, and text messaging” is rather a common utterance amongst the general populace.

Since she told me what she did for a living, it was only fair of me to indulge her on my profession. I told her how I make this little iPhone/iPad app for a small tech startup called TuneIn. Naturally, she became curious and it was obvious that she wanted me to Sell the Product to her.

If you’re a software engineer like me, “knowing” the product you’re working on doesn’t just mean being an expert of the code base. It isn’t just taking a design spec and engineering it into reality. It isn’t just writing documentation on how specific parts of the code work.

It’s knowing how to sell it.

What good is a product if you cannot market it to your customers? We engineers are an introverted bunch; we live in text everyday and turn that into magic and abstractions. Selling your product shouldn’t be a job reserved for the marketing and product people at your company. It’s a job that everyone working there should know how to do, even the people that write code. At the very core of it, we shouldn’t just know how to make the product work, but why. Because your customers don’t care about how you implemented it — they want to know why they should use it.

So, I sold my company’s product by telling her a story, or in engineering-speak, a use case. She instantly understood the value proposition and downloaded the app as soon we landed.

Know your product. Know how to sell it. It may take a bit of practice but it’s a skill worth learning. We makers of things often get stuck in the “How” mindset. Know the “Why” and master it.

The First Six Months

Back in September of last year, I started my first real job, working as a software engineer at TuneIn. I came in with limited knowledge, experience, and a small toolbelt, not knowing whether I’d be ready, especially with such a talented and world class engineering team present. The technical challenges we face everyday are tough to solve. There are no predetermined and finely tuned test cases to write code against like we were conditioned to back in school. This was not a safe incubation chamber to write poor code in with the only punishment to be an arbitrary letter grade.

This was different. This was the real world where bad code can mean many bugs, headaches, and revenue loss for the company.

Being the youngest engineer at TuneIn, my peers stand as giants to me. I am constantly humbled by their experience, expertise, and breadth — as well as depth — of knowledge in their technical domains. However, due to the openness and the relative permeability of ideas across different engineering disciplines, I cannot help but be a sponge in this endless sea of knowledge. While my coding chops are by no means extraordinary, they have unquestionably taken gigantic leaps since I started working.

I soon realized that it’s not just merely the act of doing that helps improve your craftsmanship, but doing it with people who are better than you at it that significantly helps you become great at your craft.

Be open to learning. Be receptive to failing. Surround yourself with people who are better than you at your craft. The rest will naturally follow.

Value of Destruction

During the first year or so of my programming voyage, I bumped into many roadblocks. Some algorithms were broken, this method didn’t do everything that I wanted it to, that class needed refactoring, and other such hurdles were common. I was afraid to modify certain parts because I thought that that was the only way to do it, and if I changed or deleted it, I’d be wasting unnecessary time. But I always ended up with a better and more elegant solution when I just erased the darn thing and started over.

It’s not always about fixing what’s broken. It’s about starting over and forging something better.

I think the reason why I had this fear of deleting code and starting from scratch back in the day is because I thought only parts of my code were incorrect, and thus finding the erroneous portions and deleting them would do the trick. But, you see, that is the trick—find what’s broken, then fix it. But there’s a catch: previous code tends to cloud your perspective. Therefore, any headway you make is consequentially tethered by prior thinkware; past assumptions ultimately are not conducive to novelty. This is bad and you may very well end up at a worser place than you were already in. I cannot remember a time when destroying code and beginning anew hasn’t been beneficial.

I’ll provide a personal anecdote: when I first started designing API, I wanted to make it as good as possible without ever touching it again. But as anybody with experience in architecting API can attest to, it’s not an easy task—in fact, it’s almost impossible to get it right the first time! You’re bound to scrap and rewrite much of it. But as a stubborn rookie, I was relucant to start over. However, once I overcame my pride and rewrote it, it turned out much better. I just had to admit to myself that it sucked and needed to be discarded. 

So cast away the anchor of familiarity and don’t be afraid to start over from scratch once in a while. Ironically, you have more to gain than you have to lose.

The Next 50 Years

They will be scary. They will be crazy. They will be amazing.

When you look at human technological progress up until the Renaissance, it really wasn’t all that impressive and glorious. Sure, there were some important milestones: inception of stone tools, the wheel, gunpowder, paper, and other raw materials. They, more or less, enabled the basic means such as transportation, resource management, and transfer of knowledge. But they weren’t giant leaps, relatively speaking. Agrarian societies were still prevalent and most of the world’s population did not live in cities.

Progress was slow.

However, things started to change around 1800. The Industrial Revolution happened. Many scholars argue that this pivotal period served as the point in history when mankind started witnessing the genesis of truly rapid growth. Vertical integration, the assembly line, and mass production of goods proved to be essential catalysts that skyrocketed the rate of manufacturing. Nearly the whole world was affected by this and many of our goods wouldn’t have existed had it not been for the inventions that were created during this significant time period.

Fast forward to now—you’re most likely reading this on a computer, an iPad, or probably even a smartphone. Can you believe that’s even possible? A little electronic device that’s connected to a complex global network consisting of millions of machines—each (in)dependent of the other—all able to speak to one another thousands of miles away at blazing speeds via bursts of electric signals encoded as a series of 1s and 0s!

Even as an engineer, I still find that mind-blowing.

And come to think of it, the personal computer hasn’t even been around for half a decade yet. We live in a remarkable age in which doctors can pull up a patient’s information on a glass-interface aluminum slab, customers can pay for a cup of coffee with their smartphones, and people can control their thermostats over the Internet. Most people 50 years ago probably wouldn’t have seen this coming.

Everything is changing. Education, medicine, software, design, entertainment, transportation, energy, and God else knows what. And they’re changing faster than we can keep up with them. Whether people of the future will call our age the Digital Revolution or not, I know that the next 50 years will be amazing.

There is Nothing to Writing

Ernest Hemingway:

There is nothing to writing. All you do is sit down at a typewriter and bleed.

Hemingway, while putting it frankly, certainly has it right. There is no magic way to do something—you just do. But that doesn’t always translate well in our minds. We will expend our energy in finding shortcuts to something before pursuing it instead of just diving in head first. It makes the undertaking appear more accessible. However, we mustn’t forget that 99.99% of the work still remains even after “eliminating” shortcuts.

When I embark on new endeavors, I often joke to myself on how I’ll just “YouTube or Wikipedia it” to learn the material. It’s usually my ironic way of mentally preparing for the arduous journey of going down a rabbit hole. But think about it: wouldn’t it be great if we could just rapidly acquire skill and knowledge, like they do in The Matrix, without actually doing work? Imagine the time and energy it’d save!

As of the year 2012, mastery, and even competency, of a craft requires thousands of hours of labor so there’s no getting around that. Shortcuts obviously make the learning easier, but be wary: do not misplace your objective of getting good at a craft with solely finding shortcuts. Instead, shortcuts ought to be treated as instruments of insight that you find during your journey. They only become problematic when they destroy, corrupt, or leave out nuggets of understanding and intuition. Because when they do, you’ll be spending unncessary time holing up gaps of understanding where your “shortcuts” unearthed in the first place.

All you have to do is to just sit down with your craft and bleed.

Apple’s Next Foray

Among the many great items announced during today’s WWDC keynote, Passbook certainly caught my attention. In short, it’s an app that integrates with popular brands such as Target, Starbucks, Fandango, United Airlines, Amtrak, and several others.

It’s a big slap in the face to not only the rare—if ever used—Google Wallet but Pay with Square.

With over 200 million credit cards in its database, Apple knows that it has a noticeable advantage over popular competitors such as Amazon. And I doubt that those brands being initially rolled out with Passbook will be the only ones.

Apple dominates digital music, movie, and app distribution. Payments, it seems, will be Apple’s next foray. It’s a relatively difficult industry to crack from what we’ve seen thus far, but this is a momentous step for the Cupertino giant—more so than we realize.