Engineering manager, Kotlin enthusiast, speaker, and dad. Writing about tech, work, and life.
Being pragmatic is engrained in me. I’m at my best being practical and boring.
Here’s the problem — experience has taught me that you’ll never do your best work through sheer pragmatism alone. While I’m good at weighing options and making decisions, I’m not that visionary who can conceptualize grand ideas. While planning comes very naturally to me, I find it difficult to inspire others. And though I’m good at shipping, I often do so using following established conventions.
So while the incremental, risk-averse nature of being pragmatic can be good for many aspects day to day of work, it’s not everything.
What you’re good at and what’s good for you aren’t always the same thing.
To make long-term, deep progress in your professional growth, you need to think big sometimes. You need to try things that don’t have predictable outcomes. You need ideas and ways of thinking that inspire innovation. You need to stretch way beyond your comfort zone.
But as a pragmatist, how can you do all this when it’s so foreign to you?
Look for opportunities to work with people who are the opposite of you — the dreamers, big thinkers, and contrarians. These will be the people who will push you toward bigger and better things.
Yes, it’s going to be very hard and uncomfortable for you. You’re going to feel like you’re on a bizarro planet where everything is backwards and nobody thinks like you. This is a generally good thing.
Having people challenge your baby-steps thinking with big-leaps thinking is a good thing. Not understanding what the hell one of your colleagues is thinking (at first) is a good thing. Having healthy discourse around big ideas is a good thing. And shaking hands and finding compromise is a great thing.
Their thinking will seem far out there and executing their ideas will seem impossible. But in end you’ll pull it off — not in spite of you, but because of you. You’ll be better in every way because you stretched well outside your comfort zone. And really, what’s more rewarding for a pragmatist than shipping something you didn’t think was possible?
According to Marissa Mayer, long hours and weekend work (in person) will lead to success.
Yesterday I read this article about Marissa Mayer. This quote infuriated me (emphasis mine):
My husband [the venture capital investor Zachary Bogue] runs a co-working office in San Francisco…And if you go in on a Saturday afternoon, I can tell you which startups will succeed, without even knowing what they do. Being there on the weekend is a huge indicator of success, mostly because these companies just don’t happen. They happen because of really hard work.
I read my fair share about the tech world. I haven’t encountered statements this utterly arrogant and silly in a while.
Let’s break down that quote. She’s saying…
What in the actual fuck?
This idea that someone could “tell you which startups will succeed, without even knowing what they do” is so comically arrogant, I honestly can’t tell if she was being serious.
I guess this kind of thinking from Mayer shouldn’t be all that surprising.
After all she’s the CEO who banned remote working. To her, working together in person, in the office, is the only way to do great work.
As a refresher, here’s a snippet of the leaked memo Yahoo! sent to its employees:
To become the absolute best place to work, communication and collaboration will be important, so we need to be working side-by-side. That is why it is critical that we are all present in our offices. Some of the best decisions and insights come from hallway and cafeteria discussions, meeting new people, and impromptu team meetings. Speed and quality are often sacrificed when we work from home. We need to be one Yahoo!, and that starts with physically being together.
Because let’s not forget — being physically present means you are doing your best work! Speed and quality can only happen in person! Never mind that many other companies have been successful with remote teams.
So maybe that helps explain why Mayer believes she can walk into an office on a Saturday, survey who’s there in person, and can declare the winners.
Because to her, if you’re not there physically, you’ve already failed.
In the same article, Mayer talks about her experience at Google:
The other piece that gets overlooked in the Google story is the value of hard work….The actual experience was more like, “Could you work 130 hours in a week?” The answer is yes, if you’re strategic about when you sleep, when you shower, and how often you go to the bathroom…For my first five years, I did at least one all-nighter a week, except when I was on vacation — and the vacations were few and far between.
While that might sound crazy to most of us, I don’t really have a problem with it.
She was making a decision for herself. She decided to work long hours, pull all nighters, and eschew vacations. That’s her call. ¯_(ツ)_/¯
But it’s not OK to imply that kind of work/life imbalance is a key to success for others.
Hey, if someone wants to work themselves into the ground, that’s up to them.
But spreading the message that hard work and success can only be achieved through long hours and weekend work — that’s not OK. It’s patently false, and it’s already far too pervasive in our industry.
Look, I get it — by every objective measure of Ha Ha! Business Success™(financial, title, industry stature), Mayer is insanely successful. She has achieved far more in her professional career than I ever will.
But I also don’t work weekends. I don’t work 130 hours a week. I don’t commute to an office.
My measures of success are way different. I goof off with my kids a lot. I read. I watch movies. I eat donuts and pizza. I occasionally travel. I sleep 8 hours a night. I’m rarely stressed. I revel in being boring and old.
And I do that all while genuinely enjoying my job and the people I work with (who I rarely see in person).
In Mayer’s world, I could never be a success.
I’ve never been so fucking happy to be a failure.
Life as an impatient programmer
I have to admit — patience has never been one of my strengths. My parents tell me over and over, “Try to be more patient!”
It’s never quite stuck.
I get why they harp on me. Impatience is by definition pretty negative sounding:
having or showing a tendency to be quickly irritated or provoked.
But is being impatient always such a bad thing? Consider the alternate definition:
restlessly eager
“Restlessly eager”. I love that!
Said a different way, it means you’re enthusiastic, dedicated, and ambitious. You just have a little trouble directing all that energy.
But what if you could harness all that enthusiasm?
It may sound strange, but being impatient has helped shape my programming career in a positive way.
If you’re like me, being impatient can help you become…
Hey, being impatient doesn’t sound so bad after all!
I know, I’m making it sound like being impatient is all roses and it’s the key to success.
Of course it’s not that simple. Harnessing your impatience into positive energy is easier said than done. I’ve fucked up plenty because of my impatience.
Over the years I’ve found that, like many things, balance is the key. Not everything can be the ire of your impatience.
Try to pick your battles. Try not to get worked up about minor bullshit. Try to direct that energy at the important stuff.
Ask yourself lots of questions. When do you get impatient? When did you turn that energy into a success? When did you fail? What’s worth spending that valuable energy on? Who on your team can help keep you in check?
If you can answer those questions, you’ll be on your way toward harnessing your impatience.
You’re lucky. Not everyone is blessed with impatience. It’s a powerful motivator and a great source of energy. Use it to your advantage!
If you liked this article, I’d really appreciate if you click the heart button down below. Thank you!
We’ve been hard at work making Basecamp 3 and its Android app the best way to run your projects and small business. Won’t you give them a try?
When a teammate asks me a question, one of my favorite responses is “It’s your call.” It’s such a simple yet powerful phrase. In just a few words it conveys…
Trust—Confidence—Respect—Autonomy—Ownership—Empowerment— Responsibility—Decisiveness
How can such a simple phrase mean so much? Take this common scenario — a team discussing what to work on next. Here’s one version of that conversation:
Julie: What should I work on next?
Shelley: How about a native homescreen?
Melissa: I’ve always wanted breadcrumb navigation!
Sara: Another option would be to squash some 🐛
Erica: File upload feature would be cool
Now there’s absolutely nothing wrong with a back and forth like this. Julie has opened the door for feedback, and the feedback provided makes total sense. But imagine the same opening line with a single response:
Julie: What should I work on next?
Shelley: It’s your call 😀
Immediately the whole tone of the conversation has changed for the better. Instead of asking for permission and being given specific directions, Julie has been empowered to make the decision herself. She now has complete ownership. She’s free to explore and make her own choices. She’ll assess all the open tasks. She’ll drum up her own new ideas. She’ll decide what’s next based on her own criteria of importance.
More importantly the team has expressed sincere trust, confidence, and respect in her and her abilities to do everything. They’ve said “whatever you decide is cool with us.” Full autonomy like this has significant long-term benefits to teams —no managers, increased motivation, time saved, sharper assessments, faster decisions, happier people, improved independent learning, better teamwork and so much more.
All of that accomplished by just saying a simple phrase.
When it comes to software development, conversational opportunities like this come up pretty frequently. Keep an eye out for questions about:
Of course when you’re asked for your opinion, you can certainly give it — you don’t want to leave people completely hanging. But before you do that, consider challenging the person asking the question by simply saying “It’s your call.” You’ll be pleasantly surprised by the outcome, and the long-term benefits are well worth it.
For a while now, interest in programming has been skyrocketing. So there are a lot of beginners out there starting their careers — and that’s a wonderful thing!
If you’re one of those beginners, eventually you may start thinking about the long-term prospects of your new skills: How do I take a new skill like programming, grow it, shape it, and tune it over time so I can achieve longevity in the industry?
I asked myself that same question early on in my career. Now, a mere 15 years into it, I’m hoping I can give you some answers.
Below are a few general strategies that have helped me become (and stay) a successful programmer over the long haul.
Over the course of my career, I’ve always tried to pick work where the people I’d be working with are exceptionally talented. To put it more bluntly, I try to put myself in the company of programmers who were way better than me.
This is crucial, because the best way to improve (at anything) is to learn from people better than you. It might be a nice ego boost if you know more than everyone around you, but you’re otherwise just flat lining your actual progress.
When I’m around these talented programmers, I constantly keep my eyes and ears open for nuggets of wisdom. I watch how my fellow programmers carry themselves, how they breakdown a problem, how they talk to each other. I look at their code for patterns and style choices that I can mimic. I remind myself to talk less and to listen more.
Unless you’re the Michael Jordan of your respective field, there should always be someone better than you — this is a good thing!
You have nothing to lose and everything to gain in such a situation. Take advantage of it.
I’ve found it beneficial to leave my programming comfort zone once in a while. It helps me think differently by challenging a bunch of established ideas I already have.
For sure, you don’t want to do this constantly because it can be hard to get into a rhythm with your normal area of work. But in moderation it can really open your mind to new ways of thinking.
My comfort zone is Java and Android. But over the last year, I’ve taken on stuff well outside that zone. But what’s important to remember is that none of this stuff was particularly easy or comfortable for me. In fact much of it was downright uncomfortable, nerve-wracking, and filled with doubt. At times I literally felt like I had no idea what I was doing.
But as challenging as they were, I did them anyway because I knew how valuable those experiences would be . They gave me the opportunity to work with a variety of the programmers, let me reacquaint myself with technologies I’d fallen behind with, and let me learn brand new stuff that few others in the company got to. All of that made me a better programmer.
So find a programming task that takes you out of your comfort zone and make it your next project. Then watch it pay off in spades.
When you’re just starting out, you’re going to have a lot of questions. That’s OK! What’s most important is how you choose to find the answers to your questions.
One philosophy that’s always served me well is to be independent. Usually this means that I’ll try to do most things myself first, and only when I really get stuck, I’ll ask for help.
Being independent has tons of benefits, but to name just a few…
The next time you have a burning question, see if you can answer it yourself, even if it takes a little longer than asking someone. It’ll be worth it.
Becoming a successful programmer is, like anything worthwhile, hard work. But these strategies have always served me well in the long run. I hope they can help you get to where you want to be, too.
My family and I just returned from a 12 day vacation to the San Diego area, where my brother, mom, and dad all live.
We had a wonderful time. We did all the typical vacation stuff — Legoland, beaches, pizza, beer, excessive ice cream eating — and my kids got to spend a bunch of time with their grandparents and uncle.
What made this vacation truly wonderful wasn’t just the fun activities and family, but that I got to enjoy every second of it without a single bit of stress from work. Work was the furthest thing from my mind. I was focused solely on relaxing, recharging, and spending time with my family.
You might be thinking — what’s so special about that? After all, vacation is a time when people unplug from work, relieve stress, and let go of all their worries, right?
Sadly — no, not really.
Search Google for “people working on vacation” and a disturbing amount of negative results come up — a worrying trend of unused vacation days, people who constantly work on vacation, and even life hacks on how to do work while on vacation. ☹️
The American “vacation” in today’s work environment is in pretty bad shape. How bad?
U.S. respondents receive less paid vacation time than any of the countries surveyed — 18 days in the U.S., compared to the average of 24. — TripAdvisor
They found that among employees with access to paid time off, nearly five days went unused in 2013, and 1.6 of those days did not carry over to the next year. That totals to 169 million days of lost vacation time for Americans. Time
Fears of keeping your job, being passed over for promotions or lead projects, coming back to a staggering pile of work, or feeling like you’re the only one who can do your job all push Americans to stay at the office… Money
This trend was strongest among millennials: 35 percent said they worked each day while on vacation, and 21 percent said they returned to work less productive. — Money
Not that this is always voluntary. … 24% say they were contacted by a colleague on a work issue, 20% by a boss. And while 20% gave up part of their time off because they were in pursuit of a promotion, nearly the same number (17%) stayed connected because they feared for their jobs. Money
So, to recap:
Wow, American vacations sound fucking horrible!
While these statistics are damning, we’re all adults here. Much of this is under your control, so it’s up to you to take action.
First and foremost, use your vacation days — all of them. Sounds obvious, but this should not be difficult. I don’t care how much your love your job. Find a way to use them. You’ve earned them and they’re part of your overall compensation, and you’re flushing money down the toilet if you don’t.
And when you do take those hard-earned vacation days, you need to turn on your internal “work can wait” mode for the entirety of your vacation by…
Sadly, there’s one thing that is kind out of your control. And of all the stats I read through, this one bothers me the most:
24% say they were contacted by a colleague on a work issue, 20% by a boss. Money
Holy shit! Who are these sadists that contact coworkers when they know full well they’re on vacation?!
Look, I’m sure there are very rare cases where someone’s life is literally on the line and you need to be contacted. And if you’re the brainiac who left a bunch of half finished work right before a deadline, you deserve to be bothered during vacation.
But more likely this is a sign of blatant disrespect by the person making the call. So let’s just be crystal clear: if your coworker is on vacation, leave them alone. Deal with it.
Beyond what each individual can do to make their vacations work-free, it’s important for business owners and CEOs to encourage that behavior and weave it into the company’s culture.
Why should work-free vacations be a priority for businesses? Speaking from experience, when I come back from a work-free vacation, I’m…
As a business owner, imagine multiplying those feelings across all your employees throughout the year. I bet you’ll have one hell of a productive workforce. 📈
We can’t fix the entire vacation epidemic across the country, but we can try to fix what’s within our sphere of influence. Both as individuals and as companies, let’s do our part by insisting our vacations be work-free.
We spend literally thousands of hours at work each year — let’s make those few hundred hours away from work really count!
Unlike most articles that introduce you to a language, I’m going to avoid using too much programming lingo. Instead, I’ll try using plain English in the hopes that it’s more accessible to beginners. 🤗
Some notes about the code examples:
Let’s get started with seven of my current favorites!
One of my absolute favorites.
// Java
if (firstName.equals("Dan")) {
person.setTeam(programmers);
} else if (lastName.equals("Dihiansan")) {
person.setTeam(designers);
} else {
person.setTeam(others);
}
// Kotlin
when {
firstName == "Dan" -> person.team = programmers
lastName == "Dihiansan" -> person.team = designers
else -> person.team = others
}
when blocks are effectively the same as a simple if block, but look how much more readable that is!
There’s a similar convention when only one argument is being checked. Typically this would be a long, ugly switch/case statement in Java.
// Java
switch (firstName) {
case "Dan": person.setTeam(programmers)
break;
case "Julie": person.setTeam(programmers)
break;
case "Andrew": person.setTeam(designers)
break;
default:
person.setTeam(others)
}
// Kotlin
when (firstName) {
"Dan", "Julie" -> person.team = programmers
"Andrew" -> person.team = designers
else -> person.team = others
}
I swear, this alone is worth writing Kotlin.
Using Anko, a library built for Kotlin, click listeners are ridiculously easy.
I hate writing these in Java so much that I could barely bring myself to write an example here. But I soldiered on. 😭
// Java
view.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
System.out.println("This is horrible");
}
});
// Kotlin
view.onClick {
println("WAT")
}
By using the Kotlin Android Extensions, you no longer need to bind views to objects to start working with them. You can access them directly without any binding. Zero. None.
// Java
EditText composer = findViewById(R.id.composer);
composer.setText("Allo!");
// Kotlin
view.composer.text = "Allo!"
That might not look like a big deal in isolation, but think about how much of your Activity/Controller code is the ceremony of binding a view to an object before you can start to work with that object. Kotlin bypasses all of that.
One line functions can technically be written in Java, but you’d be going against generally accepted styles.
Kotlin’s inherent brevity makes one-liners (officially called single-expression functions) quite common, and they look great. No extra lines and no braces required.
// Java
public String fullName() {
return getFirstName() + " " + getLastName();
}
// Kotlin
fun fullName() = "${firstName} ${lastName}"
Bonus: the return object type is implied, so Kotlin will automatically know the method is returning a String without ever having to write “String” anywhere.
You may have also noticed in this example 1) no need for public and 2) string interpolation.
Kotlin has extended objects you’re familiar with and made them even better and packaged them into the Kotlin Standard Library.
Take String comparisons for example:
// Java
if (name.toLowerCase().contains(firstName.toLowerCase())) {
...
}
// Kotlin
if (name.contains(firstName, true)) { ... }
Not a huge difference, but enough to improve readability in many places. The standard library has tons of these kinds of tweaks. Perfect!
if (whatever != null)Null checking is so painfully common in Java that if (whatever != null) is probably in your recurring nightmares.
Kotlin has a number of impressive null safety features built in, and let is just one of those ways to achieve more readable code.
// Java
if (message != null) {
System.out.println(message)
}
// Kotlin
message?.let { println(it) }
Here if message is not null, Kotlin will let the block (what’s inside the braces) run. If it’s null, it just skips it.
There’s one other bit of awesomeness — notice the println(it) statement? The it keyword allows you to reference the object the let began from.
I mostly love this operator because of its name. It looks like this:
?: // Turn your head to the left, you may see someone familiar
Fun name aside, the real reason this is great is because it handles the common scenario of “if something is null, I want to give it a value, but otherwise just leave it alone”.
// Java
if (people == null) {
people = new ArrayList();
}
return people;
// Kotlin
return people ?: emptyArrayList()
Here if people isn’t null, it returns. If it is, it returns whatever is to the right of the Elvis operator.
So that’s just a brief look at some things that make my life better every day working with Kotlin.
If you’re interested in getting started with Kotlin, their documentation is very good, and you can poke around the interactive Kotlin Koans. I tend to struggle with things like koans (feels too much like school work!), so if you’re like me, I’d encourage you to try building something real.
I’m on my way back home from Google I/O 2016. It was a fantastic conference — I met some great people and learned a lot.
But while I was there, I saw something horrifying, something I couldn’t shake from the moment I saw it…

“Eat. Sleep. Code. Repeat.” was printed on everything. I’d seen the phrase before, but this time it burned into my brain, probably because it was being so actively marketed at a large conference. I literally let out an “ugh” when I saw it.
Look, I get it — Google I/O is a developer conference, and the “eat, sleep, code, repeat” phrase is intended to be a clever way (albeit a completely unoriginal one) of saying “coding is awesome and we want to do it all the time!” I appreciate the enthusiasm, I do.
But there’s a damaging subtext, and that’s what bothers me. The phrase promotes an unhealthy perspective that programming is an all or nothing endeavor — that to excel at it, you have to go all in. It must be all consuming and the focus of your life.
Such bullshit. In fact it’s the exact opposite.
A truly balanced lifestyle — one that gives your brain and your soul some space to breathe non-programming air — actually makes you a better programmer.
Life outside of code helps nurture important qualities: inspiration, creative thinking, patience, flexibility, empathy, and many more. All of these skills make you a better programmer, and you can’t fully realize them by just coding.
It’s no secret that the tech industry loves hyperbole. How will you ever reach the coveted title of ninja, rock star, or wizard if you don’t spend all your waking, non-eating hours programming?!
I’ll give my standard advice: ignore the hype.
It’s wonderful to be so dedicated to your craft that programming is all you ever want to do. I love that enthusiasm. It can carry you to great heights.
But if you want to become the very best programmer you can be, make space for some non-programming activities. Let your brain stretch its legs and you might find a whole new level of flow.
For all its warts, Java has served me well. And as Android’s native language, it’s been a true blessing in disguise. Who knew all those years of writing webapps would turn into such an awesome mobile opportunity?
But I’ve never had strong feelings about Java itself. I liked some things about it, and I hated others. Whatever…it did the job. It was fine. For many years my perspective was simple — I didn’t have to love Java (or whatever programming language) to do my work well. That all changed a few months ago when I wrote my first Kotlin class.
It was a popup adapter in just 86 lines (17 of which were package and import statements), and I couldn’t get over how concise and readable it was. I could barely comprehend how little I wrote to get something to work. It took me a few passes, but all of a sudden, I sensed the difference. This wasn’t just about language features or what the FAQ said the language was capable of. This was about how I felt.
It was genuinely fun. I found myself smiling. I found myself saying “holy shit” more than a few times. I’d read code over and over and couldn’t believe how much I was accomplishing in so few lines. I couldn’t believe the clarity of the writing. Over the next few days, I wrote more and more Kotlin. I wrote my first extension. Then I converted an existing helper class and instantly cut 94 lines. I wanted to write more!
With just a few hours of effort, I cut 94 lines without breaking a sweat. I was amazed, excited, and having a ton of fun. I was also slightly freaked out by this weird new experience brought on by a programming language.
Then it finally dawned on me. Oh my God, this is it. This is what loving a programming language is like.
Over the next couple of weeks, that warm fuzzy feeling just grew and grew. Whenever I’d have to work with Java, it was painful. I’d find myself rushing through it and making stupid mistakes because I had more important Kotlin files to attend to. But when I opened the Kotlin files, I felt at home, relaxed. The code was beautiful and expressive. It was concise but powerful. I kept finding new ways to write more clearly, more directly. And I was happy!
And so that’s where we’re at in the love story. It’s still really early, and who knows if this is just infatuation or true love. For all I know it’ll all come crumbling down. But no matter how it turns out, I learned this very valuable lesson (and it only took me 15+ years)…
Nobody can truly decipher a programming language‘s greatness for you. No amount of explanation will help you feel a great language at your fingertips. They may try, but it won’t fully click. You have to experience it for yourself.
If you’re programming now, but don’t love the language you’re writing, I’d encourage you to try one that has a reputation for positive vibes: Ruby, Kotlin, Swift, or Coffeescript. And don’t just read the docs and do tutorials — pick one and try building something real.
A couple years ago I attended a conference in Austin. There were a lot of great speakers, but the one I really wanted to see was Mike Monteiro. I’ve admired Mike’s work from afar for many years because it’s so honest and direct.
I watched Mike’s entire talk, What Clients Don’t Know (and Why It’s Your Fault), and enjoyed it thoroughly. It was so great, I wanted to say thanks — it’s the least I could do for something I liked so much. I looked through the crowd for a while, but was never able to find him.
But I still wanted to say thanks, so I took a shot and sent him an email, fully assuming he wouldn’t read it. I kept it brief — I introduced myself, let him know that I’ve admired his work for many years, and thanked him for a great talk.

My email to Mike wasn’t anything special. Brief, friendly, and with a dash of personality. That’s it! Later that morning as we hung around the lobby, Mike walked up to me and said hello. We shook hands, and he mentioned he got my email and said thanks for that. The whole interaction was maybe 30 seconds, and I probably made a fool of myself.
But my foolishness aside, I got to meet someone who I admired. All it took was the simple act of saying thank you in an email.
So if you admire someone, want to say thank you, or just want to strike up a conversation, don’t be afraid to send a nice email. All the headlines keep declaring that email is dead, but it absolutely isn’t. Let your ideas, genuine gratitude, and personality shine in an email. You might be surprised what it leads to.
I have a confession to make — I’m not a rock star programmer. Nor am I a hacker. I don’t know ninjutsu. Nobody has ever called me a wizard.
Still, I take pride in the fact that I’m a good, solid programmer. One who works hard at his craft and really enjoys it, even without the fancy labels.
Yet every week I see a call for ninja programmers, who I assume slice lines of code with incredible precision. I read about tech rock stars, who I imagine write functions as beautiful as the “Stairway to Heaven” solo. I hear people throw around the word hacker (and the associated hack, hackfest, and hackathon) as if haphazardly chopping something into little bits or prying your way into an unauthorized system is a good thing.
And lest we forget about those amazing wizards, who can turn nothing into something with their…

There are no magical spells that will fix your code’s ills. With such cool sounding names and implied mystical skills, it sure sounds like these are the archetypes that all programmers should model themselves after.
But what if, like me, you don’t relate to these labels at all? If you don’t share the sensibilities of a rock star-ninja-hacker-wizard, you must be doing something wrong, right? Nope.
I’ll admit it — instead of ego-filled, high-risk, thrill-seeking badasses who can conjure up magical solutions, I have much lower key role models. I’m more akin to a librarian, scientist, artist, and carpenter.
Compared to a rock star-ninja-hacker-wizard, those labels do sound a little boring. But you know what? There’s absolutely nothing wrong with that.
Because when it comes to programming and building great products, I don’t want a rock star-ninja-hacker-wizard lifestyle. I don’t need the spotlight or fame. I don’t want to stay up until 4 a.m. every night and burn out. There are no magical spells to cure my code’s ills.
Instead, like a librarian I enjoy quiet and order. When code is well organized, things are easy to find and less likely to break, avoiding a bunch of noise and heartache.
Like a scientist I enjoy analyzing problems, trying different angles to solve them, and then sharing my findings. I want to understand how things work, and I want others to benefit from that understanding.
Like an artist I need to occasionally think outside the box, tap my creativity, and be able to see in abstracts. I want to embrace imperfection.
And like a carpenter, I really enjoy building things. Sometimes that means following a specific plan, and other times you just work with what you’ve got.
I bet there are a lot of you out there who’ve thought along the same lines. You see these silly terms used so casually — they make no sense, yet are often used to describe seemingly attractive job postings. Part of you scoffs, wondering how the use of this lingo ever got started. But a small part of you wonders why you can’t relate to being a rock star-ninja-hacker-wizard.
For those of you who feel that way, I say this — don’t listen to it. Ignore it. If you see a job posting with those words, run away fast and far. Relish the fact that you’re not a rock star-ninja-hacker-wizard. You’re probably already a great programmer doing great work, just without all the unnecessary glitz and glamour.
And whether you know it or not, everyone around you appreciates how much of a quiet badass you really are.
If you think building a software product is tough, try building a legendary car from scratch.
I recently watched A Faster Horse, a documentary about the development of the 2015 Ford Mustang. It examines how that Mustang, whose nameplate is an icon in Ford’s history (and America’s), went from idea to final shipping product — a five year process.
The amount of work it takes to produce a new car is absolutely dizzying. Take the following list for example, which is just a small sampling of the thousands of high-level items the Ford team is tasked with:
And if all that weren’t enough, once the car ships, it’s out of your hands. Recalls occasionally happen, but even those are typically for tweaks and safety, not reshaping the car itself.
Compare that to what we do in modern software development:
When I sat back and thought about how vastly different these industries are, a few things jumped out at me:
It’s that last point that really stuck in my head.
We (myself included) can sometimes get bogged down by the challenges in building software. If you’ve ever had a frustrating day of programming, team battles, or a tough interaction with a customer, you know the heavy feeling I’m talking about.
But compared to building a car from scratch, we’ve got it so good — writing software is easy!
Of course I don’t mean to trivialize our work or make reductive statements about our day to day problems. We all have tons of responsibilities on our shoulders to make great products that our customers love. On a daily basis we work on problems we don’t fully understand, critical bugs, and important features, all within a set of team dynamics and personalities.
But as hard as it is to tackle those issues, our struggles are relatively tame. If you take a look at the world around you, I bet you can find products that were insanely hard to ship, arguably much harder than software.
I personally think about the engineers at Boeing who are building massive jumbo jets every day. I’m in awe of construction crews who regularly build 50 story high-rises in Chicago. I’m fascinated by the amount of work that went into building my Nexus 6P so precisely.
A car or airplane has to be near perfect when it ships. A building must have every detail planned and triple checked. A phone must be engineered to the millimeter.
But modern software doesn’t have to be any of those things. We have a huge advantage — we can ship imperfection.
Software development brings us incredible freedom — freedom to build and ship things in days, not months; freedom to iterate and tune until our heart’s content; freedom to plan a little, but not excessively; freedom to be imperfect.
I am all for being detail oriented, but perfection is unobtainable in software. I’ll look closely at every detail of a feature and consider all the angles. Often there are imperfections, but if it’s a close call and the feature is good enough, I’ll always vote for shipping instead of holding it back.
This is not to say you should take shipping lightly. You should always consider the impact to your customers and understand any risks you might be taking by shipping an imperfect feature. And I’m not saying you should go rogue and ship things that fall outside the acceptable standards of your team or company.
But it’s also healthy for you and your brain to ship regularly— to put something out there, feel a sense of accomplishment, and let your customers react to it. You can hem and haw all day, but ultimately your customers will be the true judge of your work, not you or the people on your team.
And hey, if it doesn’t work out, just be glad you weren’t building a car. If something goes really haywire, you don’t have to institute a global recall. Refocus on the problem, reconsider it, fix your app, and ship it again.
Recently there have been a lot of people out there quitting Facebook, myself included. Some are upset by the experiments that Facebook ran to see how users would react to changes in stories they were fed. Others, like me, are simply realizing how much pent up frustration Facebook is causing.
A few recent examples of people coming to their senses…
That’s just a few examples among many, many other people who’ve left but haven’t written about it.
But the theme is the same throughout - there’s growing discontent about how Facebook is using our information to advertise to us, and even experiment on us. And more importantly, it’s becoming clear that Facebook is just plain making us unhappy.
That was my reason for leaving. My goal has been to cut anything out of my life that annoys me or makes me unhappy. When I was on Facebook, I was annoyed by all the ads and irrelevant content being shown to me. Everything about it just made me feel bad.
Part of it was that nothing seemed under my control. Stories I had no interest in would constantly pop up. People I didn’t know at all would show up in my stream because someone I barely knew commented on one of their photos. Even if I defriended a bunch of people, it was like winning the battle, but losing the war.
It was a constant cycle of being presented a bunch of news I didn’t care about, a bunch of people I didn’t know, and photos of picture-perfect lives (of which, I am 100% guilty of as well).
Perhaps more than anything though, I didn’t feel any type of actual social connection with any of my real friends. Everything was rushed - like or get liked, and move on. It gave me the perception that I knew what was going on with my friends, but I really didn’t. Facebook personas are mostly just the shiny coating that people present, nothing more.
I decided to try and stir things up a bit. To a group of my real friends, I wrote the following manifesto (slightly edited for privacy).
(A little backstory: before Facebook existed, I ran discussion forum software on my personal domain. The references to dankim.org/forums in the letter are to that forum software we used for a couple of years).
Hey friends,
You may have noticed I deactivated my Facebook account. But most likely you didn’t, because Facebook is a shitstorm of noise.
Harken back to 2000 (or whenever it was) when the actual dankim.org/forums existed. It was just that - a forum, a place for conversation. We had lots of lively, fun discussions and we felt connected. And Gary had a place to write a daily poll.
I’d argue that fun and that feeling of being connected is completely gone on Facebook. And I miss that, a lot. All of our lives are busier than they’ve ever been. I desperately want to keep up with you guys, not every God damn person I’ve ever met.
When it was 15-20 of us on dankim.org/forums, it was a place just for us, nobody else. It wasn’t about acquaintances, it was about real friends. We discussed way more, and so we connected way more.
Facebook claims to keep us connected with our friends, but it doesn’t. Instead we post a picture, a link, or a one-sentence status. People drive by and give you a like, and they move along to their 500 other friends.
These voice of our real friends are drowned out among all the other less important voices (and ads). Think about it - out of all your Facebook friends, how many do you really care about?
And even if there is something awesome you say or do, we don’t comment because we’d expose ourselves to your hundreds of friends (and probably most of their friends, depending on the utterly impossible to understand privacy settings). We don’t comment or discuss because we don’t want everyone to hear us - just our friends. Another missed connection.
By contrast, the forums were way more engaging and fun because they were safe. Nobody could get in without my permission. There was zero chance of an accidental photo tagging, or posting to your wall instead of the group. And because it was safe, we talked about whatever. We made fun of each other. We wondered how Gary came up with a new poll daily. Nobody read our shit, guaranteed, except the group of friends.
And maybe last, but certainly not least - Facebook is horrible for long form writing like this. There is no chance I could write anything like this on Facebook.
Writing on Facebook is painful. If you write more than a paragraph, it gets truncated so people can move onto the next story. Comments are trimmed and hidden so you can’t read what your friends wrote. Nowhere else in life are conversations built with “likes”. It’s fucked up.
I’ve now been away from Facebook for a couple of weeks, and I don’t miss it at all. And I’m not just saying that to prove a point or to rationalize the choice I made - I genuinely feel better, every day.
At the ripe age of 36 - a modest 18 years after starting to do my own finances - I think I’ve finally figured how to budget my money properly.
It’s not that I’ve ever been in a bad financial situation. I’ve always had positive cash flow, reasonable debt, and a decent retirement account. So it’d be easy to say that my budgeting systems must’ve been working.
But I never felt like I really understood budgeting that well. I knew what I did was working OK, but my system felt wishy-washy, even unstable. And with two kids, you don’t want things to be unstable!
Recently I started using You Need A Budget - known as “YNAB” to its loyal customers. I’ve heard people say great things about it, but never tried it. But boy am I glad I did. It’s been truly eye-opening.
YNAB is not only a nice piece of budgeting software, but more importantly it’s a method. It’s a philosophy about how to realistically budget your money each month, built around a very simple idea: give every dollar a job. That guiding principal, combined with rule three: roll with the punches, has really make clear what was once fuzzy.
YNAB works because it runs counter to traditional, strict budgeting methods. With conventional bugeting, you’re told to set dollar amounts for everything you expect to spend money on, and never to go over those amounts. But that kind of budgeting has a common result: you routinely blow through a budget category (or your entire budget), then chalk it up as a failure. And after a couple of months like that, it’s easy to get frustrated and give up.
YNAB doesn’t do that. It actually encourages the exact opposite. It recognizes that you’re likely to blow a budget category month to month. As Jesse, the founder of YNAB says:
My wife and I have been married almost ten years, and we have operated using the YNAB Rules of Cash Flow the entire time. We have never, ever stayed within budget for every spending category.
The key, instead, is to roll with the punches. If you go over in one category in a given month, that’s OK - just make sure to adjust accordingly. Maybe that means next month spending less in that category. Maybe it means reducing your overall spending next month. Or, do what I do - I move money out of another category that has a surplus, and zero out the category I’ve overspent on. I’m Even Steven going into the next month.
How ever you choose to manage it, flexibility and recognition are the important strategies to remember. By allowing and encouraging adjustments, YNAB helps you see your spending habits develop. You can really monitor and consider where your hard earned cash goes.
And of course, YNAB’s excellent software helps you along the way. Moving money between categories is easy. Entering new transactions is simple, either on a smartphone or computer. And it identifies where you need to make adjustments - either in a category, or for the month.
YNAB is very focused on cash flow, and I think that’s why it works so well for me. By keeping an eye on my cash flow and assigning every dollar a job, there’s no guesswork. Long term stuff like savings, vacations, and college funds take care of themselves because cash has been assigned to them. And in conjunction with something like Mint, I can watch my YNAB cash convert into long term investments as well.
YNAB is really, really fantastic. I finally feel like I have true clarity on my spending. No matter what your budget size or financial status, implementating YNAB could really make a huge difference in your life.
The Spring 2013 quarter at The Starter League has begun, and we’re excited to get started!
Part of that excitement is the chance to make every quarter successively better. Everyone on The Starter League team takes teaching and learning seriously. We’re always looking to improve so that we can build the best learning experience for our students.
Recently I ran across a fascinating article about how people learn. It’s worth reading in full, but there were a few key insights that really stood out.
Your capacity to learn in a given session is limited to just a few ideas. When more is covered, less is retained.
We think about this a lot. We have eleven weeks to build your core skills, get you coding, and sustain your confidence. We focus on teaching within your capacity so you can retain what’s important.
We know we can’t cover everything in eleven weeks. Our goal is to give you the practical skills to code confidently, build, ship, and continue your journey.
Memorizing facts and techniques is necessary, but applying that knowledge to a real problem is crucial to learning and retention.
This is why we believe so much in Starter Night. It’s a chance to take what you’ve learned and build an app to solve a problem you care about. It’s the culmination of many weeks of hard work, and it’s an experience that will help you learn more deeply.
Having been a student last quarter, I can attest to the value of building something real. Our team was frustrated with friends who forgot to return our stuff. In four weeks we built an app from the ground up and shipped it. It was a proud moment, and one that I can’t wait for each of you to experience.
Everyone has different backgrounds, so it’s important that we make a connection with you.
When we understand where you’re coming from, we can help answer the questions that will help you learn – why is this worth learning, and how is it applicable in the real world?
The best thing you can do is be present.
This doesn’t mean you need to be the loudest voice in the room. Find what works for you. Pair up during class. Ask questions to your classmates or instructors. Participate during in-class exercises. Grab a beer and talk code. Come to office hours for one on one help. Do your homework. Code alone. Code often. Read ahead. Write about your experiences.
We’re students too. We want to keep learning and getting better at what we do. And we can’t wait to start learning with you.
Today I had some time to reflect on the changes I made in the past two months. I came to a simple conclusion: Life isn’t just good. It’s great.
The reason is astoundingly simple. I recognized a part of my life that made me unhappy and changed it. For me that was work.
Work is a huge part of our lives. It consumes (at least) 40% of our non-sleeping hours a week. That’s a lot of time to spend being unhappy.
So I made a drastic change. I quit my job in management and decided to learn to code again. I wanted to build my ideas, not just talk about them. I wanted to surround myself with like-minded people.
Being accepted to The Starter Leaguewas where the positive change started for me. I’ve been encouraged and challenged since day one.
In just six weeks I’ve learned practical coding skills through fun projects – an animated solar system, a weather app using responsive design, and CSS3 for awesome things like creating logos. Outside of class I’ve used those skills to rebuild my personal site.
I’ve also learned about the importance of writing, which is highly encouraged at The Starter League. Problem solving and making real software is immensely fulfilling, and writing helps it sink in. Both aspects have helped me to think more clearly about everything.
Most importantly my life is in order. I’m happier so I’m healthier. I have an amazing, supportive wife. My twin boys are healthy, happy, and learning. I get to see them grow up every day – more than I ever would have if I stayed in my old job.
It may sound corny, but I realize now how important it is to be happy. And it only took me 35 years to figure that out.