Dr. Seuss Guide to Code Craftsmanship

I have a two-year-old daughter who adores Dr. Seuss. And as I was reading Cat in the Hat for the 214th time, I realized Dr. Seuss had it all figured out.

His words are odd. The cadence confusing. But there’s a gem hidden in all his children’s rhymes.

You see, Dr. Seuss would have made an excellent engineer. Because great code isn’t about choosing the perfect method name or building out 95% test coverage. All that is great, but it doesn’t make great code.

YOU DO.

It likely never feels that way. There’s a rhythm to software development that goes something like this:

  1. “Easy. I’ve got this.”
  2. “Uhhh, maybe not.”
  3. “HALP! I have no idea what the f*ck I’m doing.”
  4. "How did I not think of that before?"
  5. “I AM A GOD.”  

This process is okay if you’re comfortable having a mild psychotic break every sprint. I’m not.

I think we’re going about it all wrong. Putting ourselves — our egos — above our code. No judgment. I do it too. We’re human. It’s okay. 

But I think we can bypass our egos and the emotional ups and downs it produces. 

Imposter Syndrome

If you haven’t heard of imposter syndrome, it’s a concept describing high-achieving individuals — like you! — who struggle to internalize their accomplishments and experience a persistent fear of being exposed as a "fraud."

And if you think I don’t feel like a total fraud every time I stand up in front of a crowd at a conference, you’re wrong. 

I think any thoughtful, intelligent person deals with self-doubt. Some of us deal with it a lot. 

A few months ago, I did something pretty stupid. I volunteered to demonstrate a mock technical interview in front of 100 students.

My motivation was pure. Students at Turing, the code school where I learned to program, are terrified of technical interviews. Because they’re scary. Right?!

(And junior engineers seem to think seniors code like Neo.)

So my mentor, Ian Douglas, and I thought we’d show them what to expect. Ian would throw some tough questions at me and I’d illustrate how to handle questions you don’t know the answer to. 

I don’t normally quote Mike Tyson, but he has one great saying I love. “Everyone has a plan until they get punched in the mouth.” 

Dr. Seuss.019.png

Ian asked his first question and I froze. I realized that 100 people were staring at me. Expecting me to know the answer. And that all of them would leave thinking I’m an idiot. 

Which left me looking a lot like a sad pug — can we make #sadpug a thing?! It was scary, but I muscled through it as best I could. Like every technical interview I’ve had, I left feeling a bit down. The quiet but persistent whisper of doubt left me skeptical of my technical abilities. And I started wondering again if I was really cut out for engineering.

This feeling was reinforced when I found out a student had expressed disappointment at my performance to Ian. He thought my answers were weak and, if it were a real interview, I should not be offered the job. 

Gonna be honest, I cried. 

Because it fed into all the doubts I’ve had over the last year. When I graduated Turing I had a lot of success in the job search. I was offered 4 jobs which made me feel extraordinarily lucky and wonder if I somehow oversold my talent in those interviews. 

But the last year hasn’t been easy. I’ve struggled. And I’ve worried constantly that I haven’t been growing fast enough. That I had beginner’s luck. That I won’t be able to get another job. Certainly not one I love. 

Imposter syndrome isn’t limited to me or you or this industry. Imposter syndrome is a human problem. There’s something called negativity bias. And it’s played a crucial role in keeping humans alive all this time. Basically, if we hear a noise in the dark, our brains assume it’s a lion about to eat us. Not a mouse scrambling through the grass. 

Negativity bias is awesome if predators are an everyday threat. But we don’t have to worry about being eaten much these days. These days, negativity bias adds stress and anxiety to our lives. Certainly to mine. Who’s had a good day only to wonder what disaster is awaiting you around the next corner? As if we can only have so much good before it’s balanced out by something terrible.

Like many of you, my heroes are the extraordinary men and women in history who stood up against a fearsome power and overtook it. The little guy going toe-to-toe against the giant. And, against all odds, winning. 

I love stories of underdogs. I actually think we all do. Because it’s fundamental to American culture. We were founded by rebels and embody the attitude of we’re gonna make it on our own — no matter what it takes or how hard it is. 

It doesn’t matter the risks. It doesn’t matter the odds. We believe, as a people, that hard work can overcome just about anything. 

I like to think sometimes about what it felt like to be Caesar standing before the Rubicon or Hannibal facing the Alps. I picture strong, confident men. Filled with hubris and might. Commanding enormous armies filled with men loyal to their cause and their cult of personality. 

But I know how their stories ended. They — in that moment — did not.

Abraham Lincoln might never have been president. (He had lost 8 elections prior.) George Washington could have been hanged for treason. And Rosa Parks might have decided to sit where she was supposed to.

It’s easy to look at historical figures and think how courageous they must have been. How sure of themselves they were to take the action they did. They weren’t. Like each of us would be, they were scared. Afraid they would fail.

Dr. Seuss

Dr. Seuss started life as Theodor Seuss Geisel. His first book, Mulberry Street, was rejected 27 times. 

Walking home from the book's twenty-seventh rejection, with the manuscript and drawings tucked under his arm, he ran into a friend from Dartmouth College. His friend — Mike McClintock — had been made editor of children’s books that morning at Vanguard publishing. 

Geisel said later “If I’d been doing down the other side of Madison Avenue, I’d be in the dry-cleaning business today.” 

It may feel as if all your accomplishments can be attributed to luck. And everyone else’s to their intelligence and hard work. That’s not true. Every success story is a little of both. 

So if we know this is the reality, how can we feel like it in our everyday lives? Dr. Seuss has some hints. 

 

Find A Mentor

Sometimes the questions are complicated and the answers are simple.

I firmly believe that your mentors should be people outside of work. It’s important to remember that humans are motivated by different things and sometimes it creates a conflict of interest. 

For example, your boss — as awesome as he or she may be — will likely not recommend you ask for $20,000 more than you currently make because he or she does not want to pay you that. Whereas someone without that conflict of interest may recognize that you’re currently underpaid. 

I have 2-3 mentors in tech whom I trust implicitly. Whenever I need encouragement, honest feedback or career guidance, I call them. They’re generous with their time and believe in me as a person and as a professional. 

That all sounds great. But how do you go about finding a mentor? 

My best advice is to be vulnerable. Do the scary thing. Reach out to people you respect and ask them to coffee. Mentorship doesn’t have to be a formal arrangement. It can be an organic friendship between two professionals. 

 

!Networking

Why fit in when you were born to stand out?

People talk a lot about the importance of networking. But, to me, networking conjures an image of a silver-tongued salesman with slicked back hair working a room and collecting business cards. I don’t know about you, that’s not my kind of thing. I’d rather sit at home and watch Netflix. 

So let’s not call it networking. Let’s call it connecting. And that requires vulnerability — the foundation of genuine relationships.

There are jerks in this world. And being vulnerable is risky. Everyone in this room has had their hearts broken. We’ve been hurt. Exposed. Rejected. That’s why we have walls. To protect us. 

But there are an extraordinary number of wonderful human beings that walk this planet. Those are the people I’m asking you to be vulnerable for. Those people are good and kind and trustworthy. They deserve to know you.

 

Be You

Today you are You, that is truer than true. 
There is no one alive who is Youer than You.

The real you. Nobody is better at being you than you. Seriously. Your authentic self is a 1000% better than you acting like someone else. If you spend your time thinking you need to be different, you’re cheating yourself — and the world — of something amazing. You. 

The freedom you will feel when you are authentically you is flabbergasting. Plus, the rest of us get to know someone pretty freaking cool. 

 

Stay Curious

You have brains in your head. You have feet in your shoes. 
You can steer yourself any direction you choose.

If you haven’t read Mindset by Carol Dweck, I really can’t recommend it enough. It’s a life-changing book about growth mindset and enthusiastically learning new things without fear of being “bad” at it. 

It rejects the notion that we are limited to our god-given talents and instead focuses on the ability to learn new skills. Even if we’re initially pretty terrible at something. 

I think a great way to exercise this concept is to constantly try new things and take lessons in random subjects. I have a friend who takes improv and another who’s in salsa classes.

A few years ago, I decided to get my motorcycle license. Will I ever own a motorcycle? Probably not.

But, much to the chagrin of my mother, I wanted to prove to myself that I could do it. I showed up to a classroom of adrenaline-junkie 18-year-olds and one recently retired man. I didn’t exactly fit in. But guess what? It was a blast. It didn’t matter that I looked like an idiot. And, to be clear, I definitely looked like an idiot. But I had fun and I learned something new. 

You all are here, which means you care about learning and growing. Never let that be extinguished. If learning fuels you, make sure you make it a priority. Which brings me to...

 

Keep Learning

The more that you read, the more things you will know.
The more that you learn, the more places you’ll go.

Negotiate an educational stipend. When you start a new job, ask what the budget is for conferences. And don’t accept “it’s as needed” as a response. It blows my mind how many of my peers have to beg their boss for a $150 ticket to a local conference when sales and marketing regularly spend $2000 on booze for potential clients. 

Developers must adapt to changing technology. That means constantly learning and absorbing information. Your job isn’t to pump out 40 hours worth of code every week. Your job is to be a subject-matter expert and continuing education is a huge contributor to your success in that role.

 

Take Small Risks

If you never did you should. These things are fun, and fun is good.

If you want to learn a new technology or implement a change at work, do it. It’s better to beg for forgiveness than ask for permission. Create a proof of concept and then advocate for it. 

And don’t be afraid to fail. Everyone in this room has or will bring down the site at one point in their career. That’s awesome. Because that means you’re trying. You’re doing something. Keep doing that. 

And when you do fail, publicize it.

 

Publicize Failure

Today was good. Today was fun. Tomorrow is another one.

This is admittedly a weird one. But start sharing when you screw up is especially a great idea for those of you who are senior or principal engineers. 

It’s the best thing you could do for your team. When people I respect tell me their mistakes, it sends the signal that it’s okay to take risks and fall flat on your face. And you’ll be amazed at the response. You’ll see your team share lessons learned and become more collaborative.

A culture of being “right” all the time is toxic (and all too common). Collaboration will nosedive, silos will develop and people will cover their tracks when something goes wrong.

 

Celebrate Your Successes

Unless someone like you cares a whole awful lot, nothing is going to get better. It’s not.

I like to keep a “Yay Me!” file. Whenever someone sends me a nice note or emails my boss about what a great job I did on something, I save it in my “Yay Me!” folder. 

The alternative to this is to keep a gratitude journal. And before you scoff at the image of a diary on your nightstand, hear me out. Taking the last 5 minutes of your day to jot down the 3 things you were most grateful for that day is a surprisingly helpful practice. 

Remember negativity bias? We focus on the bad by our nature. Reminding yourself of everything going right in your life does wonders for your mental health.

 

Keep Going

And will you succeed? Yes you will indeed! (98 and 3/4 percent guaranteed.)

I’m a fan of running toward the open door until the moment it closes. Perhaps you want to launch a business in a year. Or move to a different city. Or just found out you’re expecting a child. The natural inclination is to start planning, to think a year in advance and have that plan dictate your everyday behavior at work. 

Don’t. There’s no reason to treat the next year as biding time. Just keep going and figure everything out later. Avoid planning in detail so far in advance — it only causes you to slow down and not take opportunities that you normally would. Anything could happen, plans fall through. Just keep going, but...

 

Pace Yourself

Step with care and great tact, and remember that life’s a great balancing act.

Burnout is real, folks. I’ve been in this industry a year and I can already feel the reaper coming for me. If you’re ambitious, the hardest thing to do is to recognize that careers are marathons, not sprints. 

Embrace work/life balance. Make it a priority. 

I went through Turing with a 6-month-old. Which meant my schedule was pretty intense. I woke up, got her to the nanny and went to school. I left school at 4:00, ate dinner and put her to bed. Then I did homework from 6:00 – 9:00 before going to bed (more like collapsing). That routine was my life for 7 months. 

It wasn’t easy. There were a lot of tears and wine involved. But my daughter was a critical part of my success in school. She gave me balance. Demanded I stop. Take a break. Play. Read books. And say goodnight. She gave me a break from coding and school provided me a reprieve from being a mom.  

Don’t answer emails after dinner. Don’t look at your phone the minute you wake up. Don’t work on the weekends. 

Play is not just a different kind of work. Find what you love and embrace it with child-like joy. Eat great food. Spend time with your families. And pick up that hobby you’ve been thinking about for the last few years. We get one life. And we all deserve to enjoy the shit out of it. 

 

Don't Be an Asshole

A person’s a person, no matter how small.

It’s golden rule time, folks. I’m amazed at how small of a world it really is. And people truly matter. They’re really all that matters.

It’s easy to go full Frank Underwood when you’re in a position of power. When you have the advantage. But take a step back. Be kind.

I believe we get what we give. You can’t control the behavior of others, but you can definitely control your own. Empathy is a powerful tool. Use it. You have absolutely no idea what someone else is going through. 

 

Embrace Your Humanity

Think and wonder, wonder and think.

You’re not a snowflake. Neither am I. Who’s left a crappy job and thought, “Good luck, you won’t last two weeks without me!” Only to find out the business kept on chugging along. The future of the planet doesn’t rest on your shoulders. Nor mine. And think about what a relief that is! I feel less stressed just thinking about it. We’re humans. We’re fallible. 

Here’s the cool thing. The more human you are, the more vulnerability you show, the more people will grow to trust you. 

None of this is to say you can’t make an impact. Quite the opposite. You will leave your footprint on this world. Whether it’s with the people you love most, your community or the globe. But you can let go of the pressure that you’re critical to everything. People will pick up the slack if you let them. Relax. Let go.

 

Value Old Friends

You’re in pretty good shape for the shape you are in.

Hold onto your childhood friends. The people who knew you when you were young are the most honest friends you’ll have. They don’t expect anything of you. They don’t see you as fancy or special or important. 

To them, you’re still the scrawny kid with glasses who sucks at kickball. And they love you anyway.

They’ll kick your ass when you need a dose of reality and they’ll sit beside you in silence during the worst moments of your life. 

They’re not perfect. None of us are. But they’re worth more than gold. Make sure you tell them that.

 

Make New Friends

Think left and think right and think low and think high. 
Oh, the things you can think up if only you try!

Create a small group of trusted peers. I have two groups like this. One is more for shooting the shit with people I like and the other is focused on goal accountability. 

The former is a small group of wicked smart, ambitious, female developers. They’re strong, resilient and full of grit, which means they inspire me and lift me up when I need it. 

The latter is called Wine + Goals because we literally drink wine and discuss goals. (No one said we were creative.) One Wednesday a month, 7-8 of us from varying industries and career paths sit down to discuss our highs and lows of the month and our goals for the next. Then we’re randomly assigned an accountability partner for the month, who checks in on how things are going. It’s a small, friendly kick-in-the-ass. 

 

Embrace the Suck

“Everything stinks till it’s finished.

Some days are going to suck. Nothing will go right. 

You’ll get decaf coffee and a fork with your oatmeal. It’ll take you 3 hours to debug a method only to realize you reversed a boolean value and should have figured it out 2 hours and 59 minutes ago. Not that that’s happened to me. You’ll get in a fight with a loved one and hit every single red light on the way home. 

Want to know what I do on those days? I break out a bottle of wine — yes, I drink a lot of wine — run a bath and turn on Real Housewives.

What I don’t do is start evaluating my life choices. Let bad days pass by. Look forward to the morning. Start again. 

 

Quit Comparing

I’m afraid that sometimes you’ll play lonely games too. Games you can’t win ‘cause you’ll play against you.

Stop comparing yourself to others. I know, I know. Easier said than done. But one of the most detrimental things you can do yourself is compare your bloopers to someone else’s highlight reel. 

I’m a great example of this. When I give a conference talk, I know every time I say "um" or "so," miss a bullet point or get off-track. But it’s not nearly as obvious to the audience (hopefully). 

Remember imposter syndrome? It would be very easy to look at me and assume that I must know more than you. But I don’t. I promise. You know things I don’t. And everyone has something to contribute.

Focus on what you can give. Forget about what the person next to you is doing.

 

Life is Short

How did it get so late so soon?

But it’s also long. Many of the choices you make won’t matter. Some will matter a lot. 

Live your life. Enjoy every moment of it. Friends who make you feel bad about yourself aren’t friends at all. Drop them. Surround yourself with people who inspire you, challenge you and love you. 

Play. And laugh. Show humility. Never stop learning. Be kind. And remember… 

 

"You have brains in your head. You have feet in your shoes.

You can steer yourself any direction you choose. 

You’re on your own. And you know what you know. 

And YOU are the guy who’ll decide where to go."

 

YOU are what makes your code great. I believe in you. And you should too. 

 

Implementing Quicksort

A few weeks ago, Ian Douglas asked me to help give mock technical interviews for Turing students. As someone coming out of a code school, tech interviews are the emotional equivalent of walking into Mordor. They're absolutely horrifying. (Full disclosure: I cry after every tech interview. And then drink heavily. I can't be the only one.)

I've been thinking a lot about the questions asked lately. And, unsurprisingly to you, O(n) and sorts come up frequently. I'm not going to go into too much detail about O(n) because, frankly, I don't feel qualified. Greek symbols in math scare me. They're like warning signs for the rest of us. 

For developers, the purpose of these questions is to measure your understanding of time complexity — the length of time your algorithm (function, method, code) takes to process the result.

O(n) refers to linear time. The algorithm will take more time proportionate to the size of the input. 

 
o(n).001.png.001.png
 

Sample Problem

Let's take an interview question like: Write a function that takes a list of integers and returns it from least to greatest in O(n) time. Godspeed if you have to do this on a whiteboard. Sending good thoughts your way. 

Sorts have always fascinated me and I don't know much about them so it's a great opportunity to learn something new. (If you haven't seen the Hungarian folk dance of bubble sort, you're missing out.)

I'm the first to admit that computer science fundamentals are a growth area for me. I'm far from an expert in the area of well-known algorithms. A little googling and I found that the most reliably linear algorithm for sorting is quicksort. Awesome. (I should say here that algorithms are always evaluated on worst-case scenario. And in worst-case, quicksort is not O(n). That said, it's pretty darn good.)

A little more googling and it turns out quicksort should be called hardestsort. But I decided to give it a shot anyway. 

An article on DevCamp gave me a start. But, Ruby's syntactic sugar was too much for me. I couldn't tell what was happening. This solution is beautiful, but I need to keep looking.

This StackOverflow post (note the verbose quicksort algorithm toward the bottom) led me to Khan Academy and helped me break down what exactly is happening. 

Here's how quicksort works:

  1. You have a list. Yay for arrays!
  2. You choose a pivot point. This is an index in the list you'll use to split the array into three parts: the left array, the pivot and the right array. From my research, I've seen the pivot selected randomly, as well as first or last index being used. Let's talk about this using the first item in the array as the pivot. 
  3. Compare the pivot to the value to its right. If the pivot is smaller than its neighbor, leave it. If the pivot is larger than the value to the right, switch their positions. 
  4. Buckle up for recursion. Move the pivot and do the same thing. 

Handcrafted Quicksort

Let's dive into some code. 

If you're still confused about what's happening, let's look at the output. This is the list each time we call quicksort(). I added a bit of color whenever two values are swapped.

 
$ quicksort([0, 7, 0, 87, 4567, 18, 65, 55, 55, 99, 987, 2345678, 0, 1, 10000])
 

Pretty cool, huh? 

Fancy Quicksort

OK, I feel like I have much more of a grasp of what's actually happening. I'd be lying if I said I could deliver an hour-long lecture about it, but I'm learning!

I wanted to revisit the "elegant" version I saw before. And found this lovely video.

To the code, Batman! 

This implementation involves meta-programming (I'm a little nervous about this) and extending the Array class. 

OMG is that so much better that the first go. 

Remember how we pass the block in with the less than symbol? This sorts the numbers greatest to least. If you were to call partition(&pivot.method(:>)) instead, it would sort the values least to greatest.  

For more reading on the partition method, check out the docs

I sincerely hope this helps you on your next interview question on sorting. But like I said, if you're at the whiteboard, I'm sorry. Good luck!

Intersection of Life + Career

I was lucky enough to connect with Brandon West this morning to talk about developer relations. (He literally wrote the book.)

Brandon asked me a question I can't say I've ever heard before: "What are your career and life goals?" The "and" struck me. I've never really thought of my life goals as being separate from my career goals. Which may or may not say something mildly unhealthy about my life view. 

I naturally spent the afternoon obsessively thinking about it. This is what I've come up with. (Yes, this illustration is my 267th draft. I killed a lot of trees today. Don't judge me.)

Professional

BE ELECTED TO POLITICAL OFFICE

I'm from DC. Isn't that enough? 

This has been a dream of mine since I was very small. My family are yellow dog Democrats — meaning we always vote Democrat. And for good reason. My grandmother grew up in rural Alabama with her widowed mother and two sisters during the depression. FDR and his social programs absolutely saved their lives. 

I believe strongly that we're all in it together. That most of us are only 3 mistakes away from the homelessness. And that being poor isn't a measure of morality or hard work but of misfortune. I want to ensure that all of us have the social safety net that allows us to reach for our goals and care for our families.

PROVE WOMEN CAN BE BADASS DEVELOPERS

It's not enough to be a badass developer. I'm a lady dev, which means it rests on me and others to pave the way for women and people of color. This matters to me

I want to continue to grow technically. Sometimes I forget I've only been doing this professionally for a year and it's OK to not know everything. Heck, do any of us ever know it all? No. 

I want to play in other languages (hello, Python and Go) and get quicker with syntax. I want to gain enough experience that I can identify solutions faster. And finally, I want to get better at speaking developer. The hardest part of being a junior is having an inkling of what the answer is and not knowing what it's called. 

(I also want to destroy the current style of technical interviews. But that's a different blog post.)

BE A CEO/CTO

I'm someone that can home in on a vision and make clear decisions. I'm a generalist which means I know a little about a lot. I have a small enough ego to recognize that I can't do everything and must hire people who are smarter than me. And I feel a deep responsibility for those around me, which means I won't be a fly-by-night leader. 

Personal

WIN A POWERLIFTING MEET

I am not as strong right now as I used to be. And it's hard for me to even type that. Pride is powerful. I feel guilt and shame when I go to the gym right now and can't lift as much as I used to. 

The truth is, it was almost unavoidable. I had a postpartum complication that took me out of the gym for 6 months and then I went to a code school for 7 — you try going to the gym during Turing. 

I had to focus on other things, my health and my career. I like to describe priorities as separate flames fueled by the same source. If your career flame flares up, the others will dim. And isn't that true? I find when I hit a stride in my personal life, my work suffers and visa versa. 

I'd love to get back to my previous strength level and eventually surpass it. It would be amazing to win a powerlifting meet. Even if I'm 45 by the time I do it. 

In the meantime, the gym is still my happy place. I can go, work off aggression, think through hard problems and listen to what I like to call my battle music. 

WRITE A BOOK

If you're wondering why someone who used to be a ghostwriter hasn't written a book, it's because writing a book is insanely hard. It takes intense focus and hundreds of hours of dedication. I lack the discipline, simple as that. This one is definitely a stretch goal for me. 

LEARN A SECOND LANGUAGE

My daughter is bilingual. She's two. This embarrasses me at a deep level. How is my two-year-old bilingual and I'm not? I got REALLY lucky. Her nanny speaks to her exclusively in Spanish and is the sole reason my daughter has this extraordinary advantage in life. 

I am partially fueled by a desire to not let my daughter outsmart me this early on in life. I'm first to admit she will at some point — isn't that what we all want? — but she's not gonna realize she's smarter than me until she's at least 16. 

But learning another language, specifically Spanish, also speaks to a deeply-held belief of mine: America's immigrant culture should be celebrated. 

There are 41 million native Spanish speakers in the US. And another 11 million who are bilingual. How cool is that?

But yes, it's mostly that I don't want to be outwitted by my toddler.

The Intersection

GIVE A TED TALK

OMG. Don't you want to give a TED talk?! I'd just about die. And then wave my hands in the air while jumping like a 7-year-old who just found out she got a puppy.

For me, TED talks are the pinnacle of public speaking. And it would absolutely be a dream come true. 

START A COMPANY

I specify product company here for a reason. I've run a consulting business before (where @editingemily came from).

I loved it. And it taught me an extraordinary number of hard lessons. I will always favor people with entrepreneurial experiences on their resumes for this reason. You learn things you would never observe while gainfully employed. 

It also taught me a lot about me. How I handle ups and downs. That I hate reconciling accounts. Why no one recommends starting a family business. 

But I don't like consulting and freelancing for two reasons:

  1. It's difficult to scale. Consulting by its nature is high-touch. As far as growing the company, you can hire more people or raise prices, but that's pretty much it. And there is a limit to how much money you can charge per hour. A SaaS product is created once and — if developed well — can be scaled and sold to millions. 
  2. Slow feedback loop. Humans are difficult. If you have 10 human clients, it's much harder to get honest feedback about what you're doing right and what you need to improve on. (People don't like hurting other people's feelings, even when you beg.) But if you have 10,000 customers, you can bet your butt they'll be complaining on Twitter the minute they don't like something. And those angry tweets and emails are gold. 

So what's the product? I have a folder with all my cockamamy ideas. But that's a few years off at least. I have a few more lessons I'd like to learn first.

MENTOR + CONNECT

There is no better feeling than the helping someone else. It doesn't matter what it is. Maybe it's as small as an introduction or a job referral. Or helping dozens of Turing students get through the program — both technically and mentally — so they can become kickass developers too. 

The bottom line is I love people. And if I can do something to help another human, I'm going to. It brings me endless joy and makes me feel fulfilled both personally and professionally. 

That's the list. It'll likely change and evolve as I grow. But it's a good starting point. 

Pythons + Vipers: Empathy in Tech

I want to talk to you a little bit about snakes. Specifically, pythons and vipers. (Well, sorta.)

When I was researching this topic, I pretty much thought a snake was a snake. After all, they all have scales and embody the devil — right? But I was wrong. 

Pythons move in rectilinear progression. Scientists actually used to think they used their ribs to "walk." Instead, they use their scales and muscles to pick up parts of their body off the ground and move forward in a straight line by scrunching and expanding. Like a very scary inch worm. They're big, slow (they move at about 1 mph) and non-venomous. They're constrictors, so they squeeze you until you die and then eat you. Fun!

Vipers use undulatory locomotion — favorite phrase of the week! — to propel themselves. It's that serpentine movement we're all used to. They're small, fast and venomous.  

But humans aren't like snakes. Humans are herd animals. 

Evolution

I know we don’t like to think of ourselves as equal to the other creatures that walk this earth. We cook our food and use computers, after all. We build robots and shoot humans (and monkeys and dogs) into space! We must be more advanced.

But at our core, we are herd animals.

We’re just not as fierce as some other animals — specifically the predators I think we like to associate ourselves with. Who doesn't have a CEO who considers himself or herself a "lion of industry?"

We don’t have the speed of cheetahs, the strength of bears or the armor of rhinos. In fact, we’re pretty weak.

Take me for example. I don’t have a lot of fat to survive a long winter. I’m not strong enough to fight off large predators. I have no camouflage, venom or other defenses.

No, humans have only survived because we have each other. Once we figured out the basics of food, water, fire and shelter, we were able to create specialization and division of labor. Some of us hunted. Others gathered. We shared food. We protected each other and raised children together.

I don’t know about you. I think that’s pretty cool.

Group > Individual

But this evolutionary dynamic has one critical repercussion: The group is held far above the individual.

As a result, our brains desire conformity.

Think about your group of friends. Shut your eyes. Really take a minute.

  • What do they look like?
  • What are their characteristics?
  • What do you like most about them?

Most of my friends are white, college-educated and have a similar socio-economic status. I prefer being around people who are smart, strong-willed, hard-working and ambitious.

If I’m honest, they’re not too dissimilar to me. Or, more likely, they reflect my favorite parts of myself.

This affinity for conformity goes well beyond our friendships. Which brings me to social influence and social conformity.

Social Norms

We all conform to social norms. We follow (most) traffic laws. Sure, we speed, but usually within that grey zone of 10 mph over the speed limit. We dress up for weddings and funerals. We bring a class of wine to parties and speak quietly in libraries.

These are all behaviors we don't even think about. They were taught to us through our everyday social interactions throughout our entire lives. And these social norms dictate our behavior.

Think back to high school. (I'm sure it was a super awesome time for all of us.) The popular kids set the canon for what was “cool” and the rest of us spent way too much energy trying to catch up. We wanted to belong.

Some conformity is referred to as non-conscious automatic mimicry. Like when we yawn after seeing someone else yawn. 

But conformity generally describes how we adjust our behavior and thinking to the rules of the group. It’s something psychologists have been interested in for a long time.

Asch + Conformity

In the 1950s, Polish-American psychologist Solomon Asch performed a simple test on small groups of people sat around a table. 

His study — looking at conformity and social influence — was presented under the guise of a study on visual perception.

Volunteers were shown a standard line and three comparison lines. Then they were asked to identify which of the three lines matched the comparison line.

Now anyone with their glasses on would be able to tell you it’s B.

But imagine sitting there. You're in a room with 5 strangers. You'll respond last. The person to the left of you says the answer A.

Huh? You shrug it off. He looks a little weird anyway. Then the next person responds with A.

You’d probably start wondering if you were stroking out. Or going blind. Or have a brain tumor...

What the volunteers didn’t realize was that everyone else in the group was a plant. The last person to respond was the only true participant. A common deception in studies — sneaky scientists.

In every group, the real participant struggled. Should they trust their own eyes or go with the group? 

And here’s the disturbing part: more than a third of participants gave the wrong answer.

Asch and other researchers have found people more likely to conform if:

  • They’re made to feel incompetent or insecure
  • They’re in a group of three or more
  • Everyone else agrees
  • They feel as if others are watching

Rejection

Think about a time you’ve been excluded from a group. Or different in some way. Again, think back to high school.

Were you bullied? Didn’t quite fit in? Perhaps you were defined by your group of friends — nerds, goths, athletes or mathletes.

Remember how you felt? Different. Rejected. Alone. It sucks in the short-term. And absolutely brutal to experience for years, even decades.

You may be the oldest engineer on your team. Or the youngest. Perhaps you use Emacs and everyone else uses Vim. You're the only woman or person of color. The only person with depression or anxiety. Maybe you have diabetes or a disability. You're married. Have children. Care for an ailing parent. You're gay. You're straight. You're transgender. 

Celebrate Diversity

We’re all a bit different. I think that should be celebrated.

But that isn’t always the case. Sometimes, often, our differences divide us. Or create subtle social norms that drive our behavior — and the behavior of those around us.

I’m an extrovert. But I was raised in a household of three extremely sensitive, introverted artists — talk about stereotypes.

Through years of attrition, they taught me to be sensitive to the way introverts communicate. I recognize that the quietest voices in the room are sometimes the most valuable.

Against all my extroverted instincts, I hold my words to allow the thoughtful introverts around me to gather and convey their thoughts. It takes energy but it is absolutely worth the effort.

It's Hard But Worth It

Before I continue, I want to acknowledge that embracing differences is hard. Especially at work. We all have a job to do. 

Social diversity — the kind that comes from diversity of race, ethnicity, gender and sexual orientation — can cause conflict, discomfort, distrust, disrespect and more restricted communication.

That all sounds awful. Is there an upside? Hell yes.

Being exposed to diversity alters the way you think.

  • Diversity enhances creativity and innovation
  • It encourages teams to seek out different perspectives
  • It improves decision-making and problem-solving
  • And it increases the bottom line of organizations

I’m not making this up. There are decades of research to support this. NCWIT — the National Center for Women and Information Technology — located in Boulder, is a great resource for more information on this topic.

#womenintech

Unsurprisingly, I’m a woman in tech. This term gets thrown around a lot. And god knows everyone is well aware of the diversity problem in tech.

I’m not asking you to solve it. Or implement changes at work. Or even really care.

What I’m going to ask you to do is pay attention. For a few minutes, I want you to let go of assumptions or questions or rebuttals. I want you to hear me. To feel empathy for my experience. And the experience of so many others around you.

I’m the only female engineer on my team. In 95% of the meetings I attend, I’m the only woman in the room.

And while that in and of itself isn’t that bad…

A lot of the time, it doesn't feel like the left picture below. It feels like the one to the right.

I’m different. And that subtle social cue makes it just that much harder to speak up. To take a risk and share an opinion. Because if I go against the group again, I risk being further isolated.

That’s heavy, I know. And I want to be clear: I’m not asking you to solve diversity issues in tech. It is so much bigger than you and me.

What I am asking of you is to do one thing. Just one thing.

Pay Attention

At your next meeting observe those around you. Who’s different and who’s the same? Is their behavior equal? Are those who are different given a chance to speak and are their ideas really heard? If the idea is implemented, is credit given to the correct person?

Search your own assumptions and actions. We can all share more empathy with those around us. And make tech more awesome in the process.

Post-Conference Depression

There’s a phenomenon in tech — the post-conference depression. You’ve probably experienced it. Though you may not have realized it.

Here’s how it goes. You attend a conference. After you arrive, grab your nametag and t-shirt, you settle into a chair. There’s some awkward introductions. Maybe you see someone you know five rows up from you.

A mic screeches and a hush falls over the room. The first speaker dons the stage. There’s usually a few technical issues because — let’s face it — a room full of engineers can’t figure out an AV system to save our lives.

Then something magical happens.

Conference Magic

A developer, someone just like you, starts to share a problem you’ve had. The topics run the gamut:

  • How to sell DevOps to your team.
  • Lessons learned from that time your boss asked you to upgrade Ruby from 2.1.1 to 2.4.1 overnight after he figured out it’s no longer supported (even though you’ve written 14 emails and had 2 architecture meetings about it).
  • ChatOps and how it can simplify deploys.

Your shoulders relax. You chuckle. You realize you’re with your people. You’re home.

The next speaker comes up with an equally enlightening talk. You realize that everyone deals with the same bullshit you do day in and day out. We don’t have it all figured out. But we’re trying. We’re sharing lessons learned. We’re striving to be better.

That night, you grab a beer with a group of conference attendees. You meet some new friends and lament as a group about how incompetent your manager is, how you haven’t gotten a raise in 2 years but seriously don’t want to go on technical interviews because it would destroy your ego if, as a senior with 12 years experience, you bombed bubble sort. (Not that any of us have had that conversation…)

The next day is even better. Sure, you’re all a bit hungover. But the room is relaxed. There’s fewer awkward encounters. You’re friends now. All victims of the same bureaucracy and overwhelming tech debt.

Heading home that weekend, you’re full of ideas.

A new blog post you need to write. A new book concept. Hell — you’re making business plans for that company you’ve always wanted to start. The sun shines a little brighter. The air is a little fresher. You feel like you can breathe again. Like you’ve got it all figured out.

Off To Work...

Sunday comes too fast and you’re off to work again. Monday morning, after nabbing your favorite liquid treat from the coffee shop — and a chocolate muffin, admit it! — you stroll into the office with a little extra pep in your step.

Right into a brick wall.

But you muster the strength to fight against the overwhelming sense of dread permeating your office. You know the other devs just don’t know how bright a world it can be. They haven’t heard your awesome new ideas.

So you sit down and write out a thoughtful email. You collect your top 3 favorite talks and include the videos. Proud of your work, you click “Send.”

And wait. And wait. And wait. Crickets.

No one mentions it during standup. It’s just the usual, somber regurgitation of what each person worked on the previous day. No one replies. Your boss is too busy bouncing from meeting to meeting to read email.

Throughout the week, you realize you’re just one person. Trying to change the hearts and minds of 9 others. You knew it wasn’t going to be easy, but you didn’t expect this much pushback. No, apathy.

The week progresses and you start wondering if you can be the change agent you thought you could be. Should you start studying bubble sort? It may be time to face the whiteboard again…

This is the post-conference depression. What was irritating but tolerable becomes staggeringly deflating. You saw the light at the end of the tunnel only to realize it was a train.

Change Agents Are Like Water

You work from home Thursday to escape the melancholy and shuffle into standup Friday morning. A colleague taps you on the arm before the scrum master begins calling on people, third-grade style.

“Loved that talk on Apache. Let’s look into whether we could implement the same solution.”

After the momentary look of shock and confusion falls off your face, you smile and nod. “Awesome. Yea, let’s do it.”

Change is slow. Painfully slow. You are not an earthquake. You are not a mountain violently emerging from the surface. That kind of sudden change doesn’t last anyway.

True change agents are like water. Slowly and consistently, they carve grooves into the landscape. They don’t quit. You shouldn’t either.

JavaDay Kyiv

Turns out Ukrainians spell Kiev as Kyiv. And I was lucky enough to travel there to speak at the JavaDay conference. 

Andrii and the entire JavaDay Kyiv team did a phenomenal job. There was even a live band! I'll post videos of my favorite talks as soon as they're up. 

 

The City

I was more than impressed with Kyiv and the people who live there. Though language was a struggle — and more than once I played charades with a stranger — everyone I interacted with was lovely and went out of their way to help. 

 

KYIVAN PATRIARCHATE

Kyiv is full of ancient and amazing churches. I stayed down the street from the Ukrainian Orthodox Church of the Kyivan Patriarchate, a beautiful church with stunning paintings delighting its walls. 

I was touched and impressed by the level of reverence displayed by visitors, so much that I felt compelled to cover my head with a scarf. 

 

 

Kiev Pechersk Lavra

The other highlight of the trip was Kiev Pechersk Lavra, a monastery founded in 1051 A.D. (or C.E.? What are we doing these days?)

While I didn't get to go into the caves for which the monastery is known, the churches and chapels above ground were beyond anything I've ever seen. Every wall was covered in ornately carved gold and paintings of saints. 

If you're ever in Kyiv, I highly recommend you visit it. 

 

 

My Jetsetting Daughter

I made the brave (stupid?) choice to bring my daughter along. She's obsessed with buses and trains so I heard a lot of "Bus!" and "Toot toot!" every time we boarded another one. 

 

 

Arsenalna Station

I accidentally stumbled into the deepest subway station in the world. Arsenalna station is over 346 feet deep and required a trip on two extremely long escalators which moved alarmingly fast. 

For my DC friends, not only is their subway called Metro as well, they don't tolerate escalefters! Finding common ground. This is how we solve world problems, folks. 

Ukrainian Beer

 

International Toilets

I absolutely love seeing the different styles of toilets that exist all over the world. So here's two I ran into during my visit. Yes, the one on the right is a squatty potty. That was interesting to say the least!

 

Humpty Dumpty + DevOps

I’m convinced Humpty Dumpty is a story of DevOps gone wrong. 

Humpty Dumpty sat on a wall,
Humpty Dumpty had a great fall.
All the king's horses and all the king's men
Couldn't put Humpty together again.

First, who asks a horse to do surgery? Hoofs can’t hold scalpels. Second, either the king’s men are inept or they’re not communicating. Two kindergarteners with some Elmer’s could have done the job.

You see, Humpty is a deploy. He was fine in staging but shit the bed in production. Now the site’s down and your boss is threatening everyone’s jobs. IT is saying the code is broken. The developers are saying it’s a server issue. 

Meanwhile, Humpty is bleeding out. And your customers are complaining on Twitter. Which means a customer service rep has entered the #incident channel to tell you the site’s down. Yea, no shit, Tom. 

Sound familiar? 

We’ve all been there. A deploy goes awry and the entire department is up in arms, defending themselves and blaming each other.

All The King’s Horses and All The King’s Men

So there we are. In chaos. The site’s down. The boss is pissed. 

I don’t know about you, but I always think best when my boss has morphed into Al Capone and I’m staring down the barrel of a metaphorical Tommy Gun.

Not.

At first glance, you might think we’ve assembled the best team to handle the crisis. There are engineers who know the code inside and out and an ops team that can handle any systems fire. 

Yet, it doesn’t work out that way. It always devolves into a blame game. You know the scene.

Developers say…

  • “It’s a server issue.” 
  • “My code worked in staging.”
  • “A configuration must have changed.”

Operations people say…

  • “Has to be a code change from the last deploy.”
  • “What was just deployed?...”
  • “Why are we the only ones that know what is broken?...”

All the king’s horses and all the king’s men aren’t working together.  

Let’s Stop Fighting

Ok, first, I’m not going to address all-out fist fights. Because honestly, if your department hosts a weekly version of Fight Club, you should really change jobs. 

I’m talking more about what could be described as friction, attitude, or a general inability to tolerate each other without eye rolls and audible sighs. What I like to call good ’ol Southern-style passive aggressiveness.

I’ll give you an example. 

I recently had some mild conflict with one of our DevOps guys. A day after a deploy, a feature on one of our sites — the ability for admins to upload new photos — wasn’t working. The user didn’t receive an error message after uploading. The new photo just didn’t show up. 

A project manager (PM) messaged me and an ops guy.

I had 20 minutes before another meeting — why are there so many meetings?! — so I felt a little pressure to locate the issue quickly. I should have recognized that I was on edge and ill prepared to deal with the situation at that moment.

But I didn’t. I’m human. 

To make matters worse, an eerily similar issue had come up during testing in QA. During that code hunt, the ops team lovingly implied that it was my problem. And after an hour or two of log reading and double-checking my work, I discovered it was in fact an ops issue. 

Not that it isn’t my fault sometimes. I make plenty of mistakes. And then I obsess about them for months...

Fast-forward two weeks and here we are again. So I’m primed and have plenty of attitude. My bad. 

I holler across the room to see what the logs say. 

“I don’t know.”

Um, wanna go look it up?! 

OK, I didn’t actually say that. But I’m 80% sure I got the message across with my eyes. 

So I track down the production logs while coordinating with the PM so I didn’t have to test the issue in production. 

Minutes pass and now I’m in my meeting trying to do both. Because multi-tasking is proven to be so effective. 

The production logs have nothing but 200s and everything looks good. 

Finally, the ops guy checks the S3 logs. Surprise, surprise. The image is there. Pff! Not my fault. (My inner dialogue may or may not be an eight-year-old.)

Yep, you guessed it. Another ops issue. 

Now it’s not that I think operations issues are easy. They scare the shit out of me. But I get a little huffy puffy when I’m constantly met with “it must be the code.” And I’m sure it’s beyond irritating that ops teams constantly get “it must be a server issue.” 

Which brings me to my core point: we need to work together, guys.

“Dev”.concat(“Ops”)

Change is hard. I dislike it as much as the next person. But I think this cultural shift is worth the struggle. 

By now you’ve probably heard something about DevOps. It’s all the rage these days. 

But if you aren’t an expert in what exactly the term DevOps means, here’s a quick history. 

The term was coined by Patrick Debois and Andrew Clay Shafer while attending a conference in 2008. Hilariously, Patrick had planned to speak about DevOps at the event, but received such negative feedback that he decided to skip his own session. (TIL don’t give up on ideas just because you get a poor response.)

John Allspaw and Paul Hammond joined the #devops conversation with a talk called 10+ Deploys per Day: Dev and Ops Cooperation at Flickr. The talk is 40 minutes but very much worth your time. Just play it during dinner tonight. Your kids are gonna love it. Promise.

Since then, DevOps has become a term that encompasses a company culture where developers and operations people work together. 

Traditional Thinking

Before we continue toward DevOps nirvana, it’s important to recognize your development team has a fundamentally different priority than your operations team. 

Like it not, developers are measured by the number of features they release. No CEO has ever cracked open code to review your thorough test suite or pondered at the glorious variable name you picked out. (I appreciate it, though. So you have that going for you.) 

If all of us decided to tackle our growing mound of tech debt this month instead of working on the latest and greatest idea your sales team came up with, you better believe we’d be hauled into someone’s office and chided. 

But operations people are measured on an entirely different aspect of the business: site reliability and uptime. And you better believe keeping a site up 99.999% of the time is no easy feat. 

I’ll spare you the math. That’s a little over 5 minutes downtime per year. FIVE. MINUTES. PER. YEAR.  

So, to break this down, developers must deploy new code to release new features. But deploys are the most frequent cause of downtime. 

No wonder we’re natural enemies. 

Be The Change

What we need is operations teams that think like developers and developers that think like operations people. 

It’s not easy. But it is simple. 

Operations: Empower Your Developers

Trust your team

You’re on the same side. If a developer says the code works, trust them. They’re not lying to you. And they don’t want to make your life a living hell. They honestly believe the code works. Which brings me to...

Give read-only access to all developers

To what? To EVERYTHING. I’m not saying to hand out root access like candy. But you are not the gatekeeper of information. Do you like being interrupted every 5 minutes so you can copy and paste an error message? I didn’t think so.

Developers are writing the code that runs on your systems. It’s not a reach to think they should be able to get some feedback about whether it works. After all, don’t expect developers to jump in and help when they don’t have access to your machines. 

Create consistent platforms

Integrated platforms are easier to develop and support. Pay attention to the parity between environments. Staging and production should be identical. That means the same allocated resources and the same data. Otherwise deploying will always be a roll of the dice. 

Share source control

Keep your configuration tools on GitHub with the rest of your company’s code. Code is code. It’ll be much easier for operations and developers to solve problems together if everyone knows how to locate the affected code.

Add your devs to the on-call rotation

My friend likes to say, “You build it, you support it.” No one likes to be woken up at 2:00 a.m. And if you’re tired of stumbling through the dark toward your computer in the middle of the night, share the pain. There’s no reason developers shouldn’t be on rotation. Remember, they can access logs and view your configuration tools now. Awesome!

Simplify deploys

Pushing code to production should not be a production. Unnecessary steps increase the opportunity for error and decrease the number of people who can deploy.

Oh, one more thing. Stop preventing developers from deploying their code to the QA and staging environments. Seriously. If I have to ask permission to test my shit anywhere other than dev, you deserve to put out the fire. 

Developers: Stop Being Assholes

Make operations part of the planning process

Thinking about a feature? Include operations. Talk about what will change before you write a single line of code. Discuss why this feature is important, who will need to be involved and what the risks are. You can’t deploy mystery code and then get irritated with your operations team when they start asking 100 questions. 

Make small changes. Deploy. Repeat.

If your feature requires you to change 30% of your app’s spaghetti code, break the feature into smaller pieces. Not sure if your feature is too big? Apply the same rule you use for method naming. If the method needs an “and” it’s doing too much. Small deploys make it MUCH easier to determine what went wrong in case of failure.

Communicate

You know how you already included operations in your feature planning? Notify the operations team when you deploy too. Whether you use Slack or HipChat, make sure all developers and operations people have a single place to communicate. Lots of companies use an #incident channel. Find what works for you and then use it. 

Yes, and…

There’s a rule in improve that forces participants to say “yes, and…” rather than “yes, but…” Try this next time you’re in a meeting and the results will likely surprise you. That simple language change will make everyone feel heard, validated and a part of the team. 

Be open to other options

If someone on operations says there’s going to be a problem, listen to them. That means shutting your mouth and really hearing what they have to say. You’re an engineer, not God. The core competency of operations is site reliability. Let them help you. The solution you come to together will be much better than the one you thought of on your own.

Have some humility

If someone was woken up in the middle of the night because of something you released, say sorry. Buy some coffee. Help ’em out. Own your shit. When you take responsibility for a mistake, your colleagues are much less likely to make a voodoo doll of you and keep it by their bed. 

Practice Failing Together

Failure is never a question of if, but when. 

You will fail. A deploy will bring down the site. A typo in your configuration will bring users to Twitter fisticuffs. 

It happens. We’re human. And until Skynet, we’re all stuck dealing with our occasional mistakes. 

Have a healthy attitude around failure

You need to 80/20 your failure preparedness procedures. It’s okay to spend 80% of your time trying to prevent failure, but devote at least 20% to practicing how you will handle failure when it happens. We all half ignore the safety talk given at the start of every flight, but I appreciate that oxygen falls from the ceiling in the event Bane decides to crash my plane.  

Stop pointing fingers

Avoid blame. It never feels good to make a mistake. And when 20 people are required to rectify it, it feels even worse. When I screw up, I’m embarrassed. And if I feel attacked, I become defensive. I think most of you would probably say the same. Let’s give everyone a little slack. It could have been your typo. 

Leave your egos at the door

When I started powerlifting seriously, I joined a small team of intimidating lifters. The head of the group — a 60-year-old Juggernaut-like man whose traps rose to just under his ears — had one rule: leave your ego at the door. It didn’t matter that we had to strip off 400 pounds every time it was my turn to squat. All that mattered was that I listened, learned and respected the team. We could all learn a lot from that. 

Recommended Reading

Here’s a short list of books you may be interested in:

And no, I haven’t read all those books. I’m convinced people lie about how many books they’ve read. Or I watch too much Netflix. Don’t judge me.

Pushing a Node App to Heroku

If you're used to pushing Rails apps to Heroku, deploying your first Node app could be a pretty frustrating experience. 

It was for me. 

Here's some tricks to help you deploy:

  • Add Node as an engine dependency in your package.json file:
"engines": {
"node": "4.1.1"
},
  • Delete your node modules and reinstall all your dependencies in your production environment. To do this, run `rm -rf node_modules` and `npm install --production`
  • Double-check everything worked. Run `heroku local web` and visit http://localhost:5000 to see your app as it will appear once deployed.
  • If everything looks good, deploy as usual.
$ git add .
$ git commit -m "Added a Procfile."
$ heroku login
Enter your Heroku credentials.
...
$ heroku create
Creating arcane-lowlands-8408... done, stack is cedar
http://arcane-lowlands-8408.herokuapp.com/ | git@heroku.com:arcane-lowlands-8408.git
Git remote heroku added
$ git push heroku master
...
-----> Node.js app detected
...
-----> Launching... done
 http://arcane-lowlands-8408.herokuapp.com deployed to Heroku

For more information on deploying Node apps to Heroku, read through Heroku's very helpful instructions.

How Websockets Work

Oh, websockets. 

I had trouble conceptualizing websockets and understanding how information is passed from the server to the client. 

Here's the analogy I finally settled on: websockets are a lot like tossing a ball with a friend at the park. 

Websockets and Balls 

Pretend you're the server. You send out a message asking if anyone wants to play.

Your friend (the client) happens to hear and sends back another message, "Hell yea, I'd love to go to the park!"

This conversation is essentially opening the connection between two sockets. Now you're both listening to each other and can receive any messages sent. 

But here's the deal: Because you're the server, you can play ball with multiple friends at the same time. Your friend, the client, isn't so powerful. He or she can only interact with you. 

Set Up Your App

Before we dive deep into websockets, let's set up a basic Node app to work with them.

If you haven't already, make a directory and `npm init`. Work through the initial setup and then install Express: `npm i express --save`.

Within your app, create a server.js file.

This just requires some of the dependencies we'll be working with to get this app off the ground.

Create a folder called `public` and create a file within it called `index.html`. This will be the file we send to the client when they visit http://localhost:3000. Why 3000? Well, that's what we're setting on line 12 above. We're telling this app to listen on port 3000. 

In your console, type `npm start`. Then visit http://localhost:3000 and return to the console. You should see a message: "Listening on port 3000."

Cool, huh?

Ok, now we'll get to the websockets. 

We've set up the server above and now we're going to pass that variable into socketIo. (Don't worry about line 22 for now — that's for another piece of functionality.)

Now open another tab in your browser and visit http://localhost:3000. Return to your console and you should see a new message: "A user has connected. 1"

When you visited the site as a client, the server recognized the connection and notified you. 

Can you guess the difference between line 27 and line 29?

`io.sockets.emit()` sends information to ALL the sockets listening on your connection. 

`socket.emit()` sends information to one specific socket. 

How to Work with Websockets in Real Life

Now let's build some extra features to pass information back and forth between the server and the client. 

Add the following to your index.html file. 

Create a client.js file in your public folder. Then add the following.

Now experiment with your connections by opening up a bunch of tabs in your browser. See how the connection count increases and decreases as you open and close tabs.

The awesome part of websockets is that they're LIVE. You don't have to refresh the page. The connection automatically updates the information based on what's happening in real time. 

Got something to add about websockets? Feel free to comment below.

Starting a Node Project

Getting started is usually the hardest part of any project. Here's what to do. 

  • If you haven't already, download Node
  • Make a new directory and cd into it: `mkdir myapp` and `cd myapp`
  • When you enter `npm init`, you'll be given a series of options for your app. Press enter to accept the default answer or enter your own. 
name: (myapp)
version: (1.0.0)
description: An amazing app
entry point: (index.js) server.js
test command: mocha
git repository: https://github.com/{your username}/myapp
keywords: node, javascript, app
author: Emily Dowdle
license: (ISC) MIT
  • I'm going to use express and mocha. To install these dependencies, type `npm i express --save` and `npm i mocha --save-dev`

Turing as a great tutorial for creating and unit testing an express app. I highly recommend you follow along to get some more experience.

 

Video Code Along (Part 1)

 

Video Code Along (Part 2)

I was interrupted in the middle of recording. Here's the final part.