A little bit before Father’s Day this year, I mentioned to my wife that I’d found an interesting, fun way to help my three daughters learn more about what consumes pretty much all of my waking moments: Programming.
Here’s what I found:
Dash and Dot have currently taken up residence in our living room and come out to play pretty much every day. By having them around, my oldest daughter is routinely reminded that she can, in fact, control their behavior. And the younger two kids are getting fun exposure to technology.
Like many programmers, my love of programming is a joy in life that I get to experience consistently, and I want to share that passion and joy with my kids.
I also feel like it’s just as amazing to find other kids and share the wonder with them, because their enthusiasm is contagious.
This enthusiasm is why it is so important for all of us as programmers to think about our craft as something we can and should teach to children.
Think about it for just a minute — who’s going to inherit what we start now? Without giving children (whether our own or someone else’s) a good foundation for approaching the future, I feel like we’re doing them all a disservice. It’s never too early to inspire kids about the future by showing them the power of programming.
The best thing that’s happened to me as I’ve started teaching my daughter is that I’ve rediscovered the joy and passion that I had when I first learned how to bend a computer to my will.
Sure, I’m biased in my fatherhood. But I think we can all learn some important lessons when we take the time to teach children about the wonders of writing code.
Keep It Simple
Kids don’t need to know they’re learning about algorithms. In fact, they probably don’t even need to know the word algorithm.
But if you can teach them to get a machine to follow directions, whether that machine is a robot (of which there are several varieties) or just using the Scratch or Scratch Jr. program on your tablet, algorithmic building blocks help kids learn how to better appreciate the language computers speak in.
The most important thing we need to realize about kids is that, just like adults, they all have different learning and engagement styles. So, finding a way to get them engaged at their level really helps increase their interest.
Whether it’s through toy robotics, Lego Mindstorms, or a fun tablet app, if we find ways to make programming fun for kids at an early age, we can help them keep wanting to program computers throughout their lives.
Furthermore, the value of teaching this skill to children is reflective. By thinking about how to explain complex situations in the most simple of terms, you’ be helping yourself learn to break down programming problems into simple units.
Ultimately, the simpler the unit of work that a piece of code is doing, the easier it is to debug and maintain. So teaching kids to code is teaching yourself to write more maintainable code!
Terminology — Who Cares?
At 6 years old, my daughter doesn’t need to know that she’s working on an algorithm, doing incremental programming, or debugging. The terminology in this case has very little value to her, because she can’t associate it with the actions she’s taking, yet.
However, I can teach her useful practices and good habits starting even this young, so that she can carry them forward with her into the future, both in a classroom and in life.
It doesn’t matter if she knows that she’s debugging or using good modularity practices right now. What does matter is that she’s working on problem solving strategy and getting excited about seeing how code transforms into action.
If we can start teaching kids at an early age how to respect the code they write, and do it in a way that keeps it fun, then I have a feeling we’ll have more coders who enjoy doing the work and find it fulfilling and rewarding.
The main thing we want to encourage in kids is a passion for problem solving, using blocks of code.
How to Start Teaching Programming at Home
Robotic Amazement
I can’t speak about the other robotic teaching tools out there, but Dot and Dash uses several different tablet/smartphone apps to help kids learn to control the robots.
By using robotic toys to teach children, we’re tapping into something that they already do all the time. Kids love to tinker with and explore objects in physical space through building, imaginative play, and all kinds of other things they can use toys for.
By bringing programming into the physical space through robotics, it makes the programming steps tangible. It’s more interactive than just changing the way a screen lights up or prints words, and allows kids to be more engaged with the software they’re creating.
So, I’d like to highlight a couple of the Dot and Dash apps here.
This introductory one, called Path, is intended for kids as early as kindergarten or first grade (5–7 years old), and I can attest that my 6-year-old really enjoys making the robot zoom around in random circles and play funny noises in the process.
This one is introductory, because all it takes to use it is drawing a picture of the path you want the robot to move in, and then pushing a play button. It teaches very basic problem solving by moving through a small number of steps at a time.
The next step up, called Blockly, is meant for kids 6 and up—though I can say I also really enjoy using it, and I’m [REDACTED] years old. If you’re familiar with Scratch or Scratch Jr., then this app will feel really familiar, because it uses a similar style of block programming to control the robot.
Once you’ve gotten a kid to master the basic process of making a robot follow directions with Path, you can introduce them to Blockly, because they’re going to realize they can get more specific control of the steps being taken by the robot.
Also, learning to use Blockly requires a small amount of reading skill. Path doesn’t really require the ability to read, just to follow pictographic directions.
There are all kinds of ways you can use your creative muscle and kids’ imagination to challenge them with solving puzzles, robotic or otherwise. The main idea is that they get engaged in problem solving and get lost in the process of doing so.
The other night I got my 6-year-old to use Path to navigate the robot through a maze I made out of Lego Duplo blocks. It was a powerful experience to share the problem-solving path with her in a way that we both connected with at a really fundamental level.
Firstly, it taught her about taking incremental steps, because the first time she tried to do the maze, she tried to solve the whole maze at once. The robot smashed its face into the wall repeatedly.
We both got a great laugh out of watching a robot ram into a lego wall hard enough to knock it over. This face-slamming bug taught her a second lesson—problem solving can be tricky, but it’s also a way to get some really good enjoyment out of life.
As she fine-tuned each of the steps the robot was taking, she started learning a little bit about the third idea: debugging. She made small adjustments to the path of the robot as it went along the maze to make sure it wouldn’t run into any walls.
And then, eventually, it reached its goal. The shriek of joy that came out of her mouth made my day so fantastic!
This little moment of family life helped me realize something: that connecting with the playfulness in a child is a great way to get them passionate about learning to code.
Because playful robots are so much fun, kids will want to stay engaged with the robot, learning to program, not even realizing they’re learning a critical life skill.
Apps
If you don’t want to shell out over $200 for a toy for your kids (let’s be honest, we got the toy for me, not the kids), there are ways you can inspire kids to enjoy programming with tools you might already have.
As I’ve already mentioned, there’s a smartphone/tablet app called Scratch Jr., which uses block-style programming to animate sprites.
If you don’t have access to a tablet or smartphone for a kid, https://scratch.mit.edu/ teaches programming using blocks on any computer with an internet connection.
Scratch and Scratch Jr. are popular enough you can find several video lessons on using them to teach problem solving. Similar to the Path or Blockly apps, there are problem-solving challenges that teach kids how to use the tool, and then once they have learned the tool well enough, they can start experimenting and exploring on their own, just as me and my daughter did with the robot.
As long as there’s a path with predetermined steps for the kids to take to level up their skills, they’ll eventually get the idea to start experimenting on their own.
Then you’ll find all kinds of fun programs get made—whether it’s the robot running around the room, or watching animated characters on screen following programmed steps.
Talk to Schools Around You
It might surprise you how much school systems are investing in STEM education nowadays. Public schools have finally started realizing that the future of our country and our planet depends on getting kids really involved in learning creative problem solving.
Most public schools have shared resources like tablets on which kids can use to learn technology skills. And in some cases, you’ll likely even find schools willing to purchase a Dot/Dash combo to use the tablet to teach problem solving skills with robots.
Options For Non-Parents
Throughout most of this article I’ve been operating on the premise that you, the lovely reader, have kids (or nieces/nephews) of your own that you can use these tools and apps with. But if you don’t, there are organizations you can volunteer with to empower kids who want to learn how to code.
Summer Coding Camps
Though possibly a bit on the pricey side for parents, you can always get involved with kids and code by connecting with them during a summer coding camp. A couple of good options for this are things like Youth Tech and TechSmart Kids.
Other Kinds of Volunteering
Though you may not necessarily be able to find a dedicated tech camp in your local area, one thing you will likely find an abundance of is organizations that need help from adult individuals to work with at-risk kids.
Look around for Big Brothers Big Sisters or Boys and Girls clubs you can volunteer with, or see if there are tutoring opportunities with other local after-school groups. Often, organizations that work with children really need more volunteers. You might have to have a background check before you can, but I promise they’ll be really excited to get help from someone who knows programming.
If you’re unsure about where you can look to help out, you can always look for opportunities in places like Volunteer Match or Idealist.
You can also talk with your colleagues that have kids. I bet they’ll have one or two good ideas for ways you can bring programming wonderment to the younger audiences.
Programming is Cross-Disciplinary
The main thing that you can gain by exposing kids to programming, whether it’s at home or at school, is the realization that it crosses all disciplinary boundaries.
In Scratch Jr., you can use the tools available to make a movie out of programmed characters on the screen. This activity moves programming into the arena of fine art.
You can also do things like tell the application to repeat two shifts three times, for a total of six shifts. So now we’re doing math. Add in a robot like Dash, who can launch a projectile at a stationary target, and now we’re talking about science.
In order to learn how to use the tools that make these applications work, kids have to read the screen to follow the instructions, crossing into the realm of language arts and critical thinking.
The benefits of introducing programming (and robotics) into a household or school certainly can’t be overstated. The discipline itself brings passion and interest to every subject, as long as you (the adult programmer) use your imagination to determine how to make that subject connected with programming.
Programming Means Magic
More important than anything else, the wonder I experience through the eyes of my oldest child reminds me of the number one most important thing about programming:
It’s Fun.
The ludicrous speed at which we all feel obliged to move ourselves forward makes it easy to lose sight of this simple truth about programming.
I don’t know about you lovely readers, but the first time I got a computer to tell me, “Hello, Jason,” I just about wet my pants with excitement. Who cares what language I did it in, or whether or not I used best practices?
I got a computer to communicate with me. That made me feel like a wizard with superpowers.
Teaching kids to code will make code exciting for you again, too—in ways you probably haven’t felt in a while.
Find a kid that you can teach to code. See the wonder of it through their eyes. I promise, you’ll feel magical.
I’ve got a new job where we do things a little bit differently than how I have in the past.
I honestly can’t think of any other company that I’ve heard of that routinely and systematically adopts pair programming paradigms. I imagine most of the companies I’ve worked for in the past have had accountants in the background saying something like “I don’t want to pay twice as much for solving a problem; why in the world have two people work on the exact same thing at once?”
This new workplace’s complete adoption of pair programming is a visible difference that really deviates from the norm in the job scene in my area.
For the purposes of this story, I define pair programming as having two people working on the same computer solving the same coding problem at the same time.
Don’t panic! While the “talking to another human being through most of the day” aspect may sound terrifying, it’s really not. In my experience, having two people working on a piece of coding really does prove beneficial in the end.
Sure, the more introverted members of this blog’s readership (i.e., most of us) probably get a bit terrified by this prospect. But I promise, pair programming is worth it. The value that has come from having a pair to program with has really changed the way I see high-quality code.
Pair programming has made my code easier to read, reduced the overall size of my class files, and generally just simplified code that used to be way more complex.
Having learned the strengths of pair programming, I’d strongly encourage you to bring up the practice with your managers and team. The value of having someone else working directly with you on your code cannot be overstated. Sure, there are a few drawbacks; however, in my experience, they’re vastly outweighed by the net positive pair programming provides.
So, what is it that differentiates pair programming from flying solo?
The Physical Setup
In order for pair programming to work properly, the first and most important factor is the hardware setup. Pairs must literally share one computer.
The way we make this work is with two very large, very high-resolution screens, two keyboards, and two mice. The monitors are set into mirror mode, and each person gets control of a keyboard and a mouse.
That way, we can easily jump in as we have ideas we want to turn into code, without having to say, “Hey, can I have the keyboard for a minute?”
It’s truly coding in parallel. And it has all kinds of benefits.
Pair Programming Has a Cadence
If you walk into my office and don’t take much time to stop and notice what’s really going on, pair programming will probably just look like a whole bunch of programmers grouped in twos, with each pair sharing a computer.
It may not look a whole lot different than people programming by themselves, or like anything more than two people working on the same desktop.
But pair programming has a pattern and a cadence to it—it’s not just individual programming twice. If it were, all the value of programming as a pair would be lost and pairing up wouldn’t be an investment—it’d just be an added cost and a waste of one programmer’s time.
The general pattern of a pair builds heavily on a good routine of testing. And it depends on the pair to ensure the tests are well written.
Pair programming adds significant value by dramatically increasing the quality of the output we generate. The number of defects in the code we create is very small compared to in previous jobs I’ve worked on. And we rarely implement the wrong business logic because we always have to justify our logic to the person sitting next to us.
There are certain patterns that programmers can only achieve as pair programmers, and lately I have found myself really yearning for a second pair of eyes any time I write code—not just at work. (The unfortunate reality is I have to program by myself at home. But it’s OK—I make do.)
The routine we follow as a pair looks like this:
Write a functional or integration test, write a unit test, write the code to pass the test, refactor the code, review the code, QA the code.
That probably seems pretty familiar, but every single one of those steps happens with two people at the keyboard(s). And the testing part really has a different feel to it, which I’ll cover in more detail a little later.
The one thing that makes pair programming a hard pill to swallow is the accounting cost associated with it. The non-tangible benefits of pair programming dramatically outweigh the cost of paying two developers to work on the same problem, but without appreciating how pair programming can hugely benefit the outcomes of a project, accountants will just see it as twice as expensive.
Instant Code Review
Real-time code review is one of the most obvious benefits to pair programming.
When you have two people actively engaging with the lines of code on the screen, more typos and logic errors get caught.
And if the code getting written doesn’t make sense for the problem domain it’s being used in, pairs are twice as likely to realize that the current direction of the code needs to change.
In fact, recently I was working with my pair on one of our cards. We were about an hour into it when he said something like, “I think another team already solved this problem.”
Turns out he was right: a different team had already written a library to do what we were trying to do. Which probably would have taken us the rest of the day to do. So we saved a ton of time by having two heads problem-solving.
Pair programming is the next evolutionary step in code review. If you’re not doing any kind of code review while you work on code, you should be. Almost all creative output benefits from review; this blog, for example, has editors—a whole staff of them.
Code review is just like having an editorial staff — it helps you catch things that you would otherwise miss. Because we’re human, and humans miss things.
Pair programming provides a real-time review of what you’re working on. Which means you’re much more likely to have two different people’s buy-in for every line of code.
If you believe every line of code is a business decision, then having two people make that decision together just makes way more sense.
Pairing and TDD
I’m not going to deep dive into the tenets of Test Driven Development (TDD) on this post because it’s a subject that deserves its own consideration.
Suffice to say that TDD means that you always have tests that don’t pass, and then you implement production code to make them pass. It’s where the term red->green->refactor comes from.
However, pair programming plays a crucial role in the success of thorough TDD. It’s the absolute best way to ensure your tests are testing the right thing — because your pair works to make sure that the business logic being tested is the right one. A test only has value if it tests the correct things.
In our pair programming setup, one person writes the automated unit test and the other person writes the production code to pass the test. Which opens up the doors for… dun dun dun… EVIL PAIRING.
Evil Pairing
When I joined my current team, I’d never even heard of the concept of evil pairing—in fact, I was so new to pair programming that the pattern of evil pairing was completely foreign to me. And then I got to be evil. And it was so much fun.
Defined succinctly, evil pairing is the practice of writing the smallest amount of code possible to pass a unit test, therefore proving the test incorrect or incomplete.
Even beyond how much fun it is, evil pairing has a really important function. It forces us to make sure our tests are just as good as our production code. Because without good tests, you really can’t have good production code.
The best way I describe this situation is to provide a contrived example of some test code and the evil way to make it pass. Thanks to Microsoft for giving me a decent baseline to work from.
You can see the evil way of passing this unit test in my gist here:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It’s obvious that a test for prime numbers shouldn’t fail if a value is anything other than one. Yet that’s exactly what I did—and the unit test passes.
That’s how I see evil pairing—the person implementing the code to solve the test should write the least code possible to pass the test.
We use this practice to expose edge cases or other scenarios the test hasn’t initially covered. (It also has the important fringe benefit that the person doing the implementation gets to evilly cackle when they pass a test in a horrible way.)
Sharing the Big Picture
As a general rule, neuroscience studies suggest our working memory can hold at most seven items at one time.
I don’t know about your programming projects, but in mine, there are almost always more than seven concepts to keep track of while I’m problem-solving.
If you add a second brain, however, that doubles the number of things we can keep track of at once. So now 14 ideas can be rattling around in your combined working memory.
Generally, it’s a good idea to have one person thinking about the most immediate problem at hand, while the other person tries to keep the big picture and the overall architecture of the system in mind. Often these thoughts overlap.
Sometimes they conflict with one another, and that’s when you have to have a conversation about the best route forward.
Usually, this conversation sounds something like a recent one I had about our data storage patterns. We weren’t sure whether we should use ORM or just plain SQL, so we talked about it for a little while and ultimately decided that plain SQL made more sense. This was despite the fact that we were using ORM for data storage at the time.
I was writing some ORM code, and my pair was thinking about how to solve the problem using SQL instead. The SQL made more sense. So that’s what we changed direction towards. Ultimately our code has had much less complexity and we have an easier time explaining it to one another, so it was a good win.
Pair Sovereignty
As a general rule, our teams consist of enough people to make at least two pairs of programmers at any one time. And we work in very close proximity to one another.
Generally speaking, everyone on the team works in pairs. On occasion, we may work by ourselves, but we value pair programming as a practice and strive to always incorporate pair working into our day-to-day routine.
We change pairs frequently so that we all get to work with one another on a routine basis. This also helps us create code that’s been written by a team and not just one (or two) people.
One thing that really helps this layout work is that we strongly believe in pair sovereignty. As one pair works diligently to solve a given problem, other pairs don’t interrupt that pair with suggestions like “it might be better if” or anything else that breaks the pair boundary. While you’re in a pair, your pair rules the code you’re working on, bar none.
This helps us stay focused on the problem we’re solving as a pair and not worry about what the other pair’s problems are. We’ll see it in code review, so there’s no concern we’ll lose track of business knowledge from a pair we’re not working with.
Dealing with Distraction
In an environment where your whole team shares a space and there are no cubicle walls (or actual walls) separating you from each other, it’s easy to get distracted and veer off on tangents that have nothing to do with the problem you’re solving— or even with work at all.
In these cases, my team has a safety word that we use. If anyone on our team says the word “cinnamon,” it means that we’ve noticed we’ve been off-track as a team for several minutes and that the distraction has become unproductive in general.
Distractions are good; they help with team building and general camaraderie. But sometimes they get out of hand, so that’s why we can say “cinnamon”—as a gentle reminder it’s time to get back to work.
This kind of communication tool is important for any team layout. But with pair programming, there’s almost always a conversation happening. So we need a way to ensure that those conversations don’t distract us from our problem-solving goals.
Community Isn’t a Distraction
Even though we can sometimes veer off course and stop talking about the problems our team is solving, our team’s open-air communication builds better communication overall and acts as a safety net for our team. It helps us work better together and solve problems more consistently as a group.
Introverts Enjoy It Too
One of the big differences you’ll notice between pair programming and solo programming is the all-around focus on keeping people engaged with one another. It’s almost impossible to find a dark corner room or cubicle and hide from the rest of the team because we all notice—and care—when one of our team members isn’t available for pairing.
It’s not that we condemn the practice of taking a break—we all understand that we’re introverted people and need quiet sometimes. But we like working together. And we all understand that solving a problem alone can be very isolating and demoralizing. So we’re always helping one another any way we can.
Communication
In order to ensure we don’t end up with silos of knowledge where one pair has all of the information about a given solution, we also routinely do something called a pair switch. Either within a timebox or at logical breaking points (depending on what the team decides to do), we will regularly have one person stay at a machine, while the other one goes to a different pair.
This rotation helps ensure the whole team has context for the whole solution architecture, and it dramatically breaks down knowledge silos. It’s the best way I’ve ever seen of dealing with the problem of one person becoming the only subject matter expert in a domain.
Compare this with solo programming, where you could spend a day (or more) solving a problem and not really talking with anyone about the problem you’re engaged with.
Even if you take the time to do a post hoc code review of the code you’ve written, the rest of the team loses the problem-domain context that you gain in the moment, which can’t be recovered without a really involved code review.
If you’re going to have a code review to cover everything you learned solving a problem, it will probably take just as long as solving the problem in the first place. And most places won’t be willing to code review for that long.
The Turnaround
So what happens in situations where you’re in a pair and your combined knowledge of the problem domain isn’t enough to get through the current task?
There’s one more tool that we have in our toolbelt, and it’s called “the turnaround.” That’s when we literally say the phrase “turnaround” to our team, and everyone turns away from their desk and towards the team to discuss the problem at hand.
Usually, it takes less than five minutes of turnaround discussion to come to a reasonable agreement as a team about how to solve the issue. On occasion, turnaround time can take quite a bit longer to come up with the correct path forward, but typically it’s pretty quick.
The other day, the topic of a turnaround was simply me verifying that we wanted to call our database table “Chewbacca.” I couldn’t remember, so I asked the team. It took about fifteen seconds. But that fifteen seconds saved us a ton of cognitive dissonance later if I’d just decided to call it “HanSolo” instead. (Obviously, names are changed to protect the codebase, which I’m not allowed to disclose)
Regardless of the timing, as long as the whole team understands the direction we’re taking with our code, the main goal of the turnaround is met.
Pair Programming is Fun
More than anything else, what you get as a pair programmer is a sense of having fun with someone else who loves programming as much as you do.
I’ve worked in places before where I put on my headphones, cranked out code for eight hours a day, and then went home. It’s an introvert’s dream—but it can also be isolating and frustrating.
Pair programming completely eliminates the isolation that our programming jobs create, on purpose. It encourages community and enriches our overall team experience.
I find myself in an interesting and exciting position in my new role with Asynchrony Labs. My team is a really well-oiled machine (something I’ll write about in depth at a later point) — but because of this, sometimes our testing time leads to us having some pretty decent lag in-between “productive” moments.
I’m actually using the lag right now to write this article— it’s pretty common that at least once (if not several times) a day, we have to fire off a build which includes all of our levels of integration testing. Right now, that’s zeroing in on 20 minutes where we have “time to kill” at our desks.
There are times we use this downtime for camaraderie. Since we’re a pair-programming team, often our pairs will share humorous stories we’ve heard or interesting anecdotes from the programming community.
There are times when we use this downtime for administrative tasks, like tracking hours, answering emails, or stepping away from our desks to grab a snack or take a quick walk.
But that’s not enough to fill every gap. At times lately, I’ve taken to perusing Twitter or Facebook just to pass the time, and often, even these don’t really hold my attention, because on any given day, I’ve already checked them for 20 minutes.
So this leaves me with time. Time to think. Time to reflect. Time to take better advantage of my time. And so far, I’ve been really bad at it.
I’ve spent some of this downtime just kind of checked out or bored. I’ve spent some of it doing things that don’t really enrich me, my team, or my project (like checking Twitter or Facebook compulsively).
There are so many ways I could spend 20 minutes a day (or more) doing productive things that will help me in the long-term with my career or my home life. But for some reason I haven’t thought about them at all—until now. Here are some things that I’ve recently started incorporating into my downtime that’s made me feel much better about my own personal productivity.
Writing
As in, what I’m doing right this second as I wait for the build to pass or (hopefully not) fail. I’ve stepped away from my habit of writing for a while; I’ve missed it, and now the writing bug is ready to seize the day again. Generally my writing happens either in long-form (such as this blog article) or as journaling.
I’ve started journaling more using the Bullet Journal System, which has given me several ideas for blog topics and helped me with self reflection. Logging the specific things I’m working on every day, alongside logging my ideas, helps me come back to them later instead of losing track of them altogether.
I’ve also started using this time for blogging again. The large bulk of this article came to pass during one of my build downtimes.
I hope to pick up my writing momentum and be more motivated to do so again. Writing really frees me up as an individual and helps me share my experiences with those around me. I’ve been a bit… ahem… off the wagon for the last several months, but now that things are in a good place at my office, I should certainly be writing more again.
Reading
There are so many books on my list that I can’t even begin to imagine getting through all of them in any realistic timeframe. Some of them apply directly towards my career or my ultimate end-game for income. As such, some of them are very technical. Right now I’m diving deep into Clean Code by Robert C. Martin.
I also recently rediscovered my love for fiction. While there’s so much enrichment that can happen when reading various non-fiction and educational material, fiction has really proven to me that disconnecting from reality for a little while really makes a big difference. It helps me clear out my headspace from all of the general distractions that don’t really help with anything, to make room for more critical thinking, creative thought, and overall general brain health.
The list of novels I want to read is much shorter than my non-fiction list. But reading really has become important to me again, after neglecting it for a while. Right now I’m really itching to read the Wheel of Time series, because I imagine it will take me away on a grand adventure when I do.
When I’m at work, I tend to focus on reading non-fiction enrichment topics, because I feel like I have so much more to learn all the time. My reading list of non-fiction, related either directly or tangentially to programming, is rather long. As such, when I do sit down to read I like to hit no more than one chapter at a time, taking notes in my Bullet Journal and really absorbing what it is I’ve read about.
Collaboration
Often my team spends time talking with each other while we wait for things to happen. We talk about ways we can improve our current codebase. We talk about ways we can bring in new project work. And we just talk about life.
And now the shy introverts reading are going “Hold up! Talking, as in… with people?!” Yes, talking with people really helps get programming creativity going. While I totally get wanting to read that cool article or check on that programmerhumor post, sometimes it really does pay to just turn around and talk to another person. I promise!
I’m very proud of the fact that my team is close-knit. We have a certain inherent safety in our working relationships with one another, and much of that stems from the fact that we all talk to each other about anything and everything several times a day.
We build this trust through camaraderie and regular open and honest feedback. Team onboarding includes a 30-day reflective review from other team members, providing honest critical tools that new team members can use to actively respect the culture of the team.
We also like to use something called a Team 360 on occasion. In these kinds of conversations, the whole development team sits down and comes up with one strength and one weakness for each team member, and then we have one-on-one talks with each other about our ideas to help one another get better at working as a team.
No matter how big of a mess we end up making, we always have each other’s backs and make decisions as a team. Lone guns need not apply!
Going for a Walk
One of my teammates and I go on a walk at least once a day now. We generally just go outside and walk around a couple of city blocks, so that we can get fresh air and sunshine.
It helps clear out the mental cobwebs and reset our brains for focusing. Getting away from the desk altogether really helps make desk time more bearable.
Going for walks isn’t your only option, but it sure is a good one. You could also look into getting a standing desk, to get the blood flowing. You might also try an exercise ball. I’m sure there’s other ways to get a bit of movement at the desk. Either way, I highly recommend moving around more. As I wrote about in The Programmer’s Great Clinical Depression, physical exercise really is one of the best ways to get a brain boost.
As we continue to evolve and become more and more expert in a particular subject, it’s important that we don’t develop tunnel vision. Sure, we need to continue to re-up ourselves on our already acquired hard skills. But so much of what we do can’t survive if we don’t appreciate our own selves and strengths beyond what’s in the codebase.
I’ve found myself relishing the times I spend doing things not related to my line of work.
I’ve taken up working on some of my fine art skills lately, specifically learning how to do hand-lettering (or calligraphy) and also refining my abilities with graphite and other drawing media. I also come up with silly illustrations that my team really appreciates.
I don’t spend much time doing this activity at the office because I don’t know that it’s the kind of enrichment that our employer encourages us to do during our build downtimes— but I may soon find myself experimenting with these things at the office if it seems like I can find a good time to do it.
Here’s one I did about pair programming:
Code
Oddly enough, we don’t spend much time working on code-related tasks while we wait for our builds to pass. It’s possible that we could learn a new tool or pick up the basics of some mechanism or another in our current stack, but I think we all realize that the soft skills of our team and inter-team communication have plenty of value, instead of just 20 minutes spent working on hard skills that we’re already super confident with.
Those code projects that we do work on during downtime tend to be very short-lived and focus on small pain points we have as a team. One of the more recent code snippets we wrote captured the amount of time we use as a team each day and then saved it as an entry in a csv.
We’re also working on a way to extract data from our task management tool and use it for reviewing metrics. We’re accessing it via a pretty mundane REST API right now, but it will be interesting to see if we can’t collate some of the data and make meaningful adjustments to team workflow based around what we learn.
It’s Not a Waste of Time
One of the most important things that my employer and my team remind me of during these builds is this: the downtime is absolutely, positively, not wasting our time.
We’re enriching ourselves, and allowing ourselves to become better programmers and better team members. The things we do when we’re not actively coding on a card on our board directly impact our mental health while we are working on the cards on the board.
Hopefully you’re lucky enough to get downtime while you’re on a team doing a build. And, hopefully you’re able to use that time to find the important parts of yourself that aren’t in your code.
I’d love to hear your suggestions for how you use downtime, or whether or not you really get to use it yourself.
In October of this year, I started my fifth job. I made this decision because, after looking at all the factors, I knew it was the right move.
But what really kicked me over the edge was the knowledge that my last job may have been about to disappear, because the company is for sale.
Sometimes in our careers it may seem like keeping a familiar and comfortable position is the best bet, but in this case leaving my job behind really seemed self-explanatory.
Learning to Program, a Brief History
I started professional life as a college undergraduate. I call this the start of my professional life because the idea behind college is that it’s supposed to be professional preparation.
After that, I spent a short amount of time getting my feet wet as a “web programmer”
in an ASP.Net 2.0 / C# application at Bass Pro.
From there I went on to a Windows client/server shop that had a whole bunch of old VB6 code and some new C#/.Net Code at PaperWise.
Then it was on to REST with Java, Spring, Hibernate, and eventually Groovy at O’Reilly Auto Parts.
In my last job at Skyfactor I worked in the world of Object Oriented PHP.
And this brings us to now. Thanks for reading along.
5 Jobs in 8.5 Years
Averaging two years per job seems pretty crazy. However, in my experience, employee turnover in programming positions is high and two years seems like a pretty normal average.
In the past, I decided to change my job in order to improve my financial situation.
At Skyfactor, some negative environmental factors created a toxicity that dramatically increased my stress level and decreased my overall morale. Job security was also a concern for me, as Skyfactor is for sale.
Note: Toxicity can be worse than increased stress. An openly hostile work environment is much more toxic, and unfortunately they do exist.
All things considered, though, it’s important to think of yourself as a serial monogamist with your job, and not as a loyalist. Sure, pretty much every company gives nice perks for sticking around, like more vacation or higher 401k vesting. But I promise you that none of these perks come even close to the amount of financial compensation I’ve gained through changing jobs.
Compared to the start of my career, I’m earning 270% more.
I imagine that even sticking on a promotion path and getting raises, it’d be near impossible to end up with a salary 270% higher than it was eight years ago by being a loyalist. I can’t prove that, but I’m pretty sure people don’t get raises like that by sticking around.
In every case except for my most recent job change, salary and benefits were the primary motivators that drew my attention to new employment. By knowing my market value at any state in the game, I have been able to have honest and candid conversations about what my employment expectations are, and then make rational decisions about career changes accordingly.
Like I said above, it’s not just about the salary, though.
After interviewing with my current employer and doing a bit of investigative homework, it became abundantly clear that they take employee engagement and overall job satisfaction very seriously. By moving to Asynchrony, I feel as though I have left behind toxicity and entered a place where career growth can really take place.
My Mission, Should I Choose to Accept It
For the first time in my career, I feel as though my mission statement and that of my company really, truly, connect with one another.
Here’s my mission statement for my career:
Through servant leadership, elevate to a higher standard of quality and productivity all professionals I engage with.
Servant leadership is the underlying theme threading through everything we do at my new job with Asynchronys. I finally found an employer that seems to have a very similar mission statement to mine.
This makes a big difference.
I don’t honestly know offhand what Skyfactor’s “mission” is. I probably should, but it wasn’t apparent even after working there for two years. And servant leadership certainly didn’t seem to fit their overall story well. The top-down chain-of-command made it difficult.
At O’Reilly Auto Parts, the mission is stated in their radio advertising: being the best aftermarket auto-parts dealer in the market. Again, this didn’t really help me with servant leadership and software quality because they’re more interested in selling parts than writing software.
At PaperWise, there was command-and-control chain-of-command again.
And at Bass Pro, things were pretty good except for the pay, so that’s why PaperWise won me over with a big raise.
Finding a New Gig
Knowing What You’re Looking For
My career mission statement sat prominently at the top of my resume during this most recent job hunt. I realize this goes against some of the other advice John gives on this blog, but if there’s anything I know about John, he pushes people to do what’s best given their situation.
His advice is fantastic. But it’s not one size fits all.
In every interview I had, I could immediately tell whether or not the job was going to fit well for me depending on whether or not the interviewer asked me how I define servant leadership.
If they care enough to ask about it, they probably care enough to encourage it, too. If they don’t care enough to ask, they’re probably not looking for servant leadership.
The best interview experiences I had didn’t really put a huge emphasis on hard skills. Sure, they all put me through various technical challenges, but that was before I even got a chance to meet the hiring interviewers.
Once I started talking about myself as a fit for a role, I saw two trends emerging in terms of what employers want. Some employers want active, engaged, and well-rounded employees who will challenge the status quo to push the company to a new standard of excellence.
And some employers would be just as happy hiring robots to write code, if such things existed.
I tend to avoid the second kind of employer. It’s perfectly fine if someone wants to earn a paycheck by working routinely on routine problems with routine solutions.
Someone else can have those jobs. They don’t tend to play nicely with servant leadership.
My resume makes it pretty obvious that I care way more about soft skills than hard ones.
However, I want my employer to depend on me as a person because at the end of the day, all of us have human needs.
Network Knowledge
My professional network reaches pretty far, which served me quite nicely as I began the process of hunting for a job.
Randomly applying for jobs just because they’re “Springfield, MO” located and because Indeed.com posted them doesn’t work.
Every single position I applied for, I had at least some kind of connection with people already working there.
Sure, my connection with Asynchrony was a little bit of a stretch, but hearing about it from a friend of a friend made it way easier to find. Even though I didn’t really know anyone there personally, having that connection helped substantially.
Blog Boasting
Seriously. Blog. If there is absolutely nothing else you take away from this website, you should be writing about your skills and experiences.
Every successful interview I had included this phrase coming from the interviewer: “I read about ___ on your blog.”
Every. Single. One.
Having a blog separates me from almost all of my peers, even the ones I consider vastly superior from a hard skills perspective.
Though I don’t have literal hard numbers, based on some prodding I feel like I’m earning more than people I know who have more experience than I do.
The blogging works. Period. It’s the number one best investment of time I’ve ever made in my career.
The Moment of Clarity
For me, the hardest thing about deciding to change a job is the why part of it.
Honestly, I’ve never been in a place that treated me like yesterday’s newsprint at the bottom of a birdcage.
In contrast, I’ve also never been anywhere that wanted to set me free and nourish me well enough that I could fly further than ever.
With my last employer, Skyfactor, things became clear when the executive management told us, “Skyfactor is for sale.”
While I respect the team responsible for making the sale happen, the risk and unpredictably that comes with a statement like that isn’t something that a dad of three young children could tolerate.
Even if Skyfactor had the best reviews on the planet (which it doesn’t), being in a position where I would have had to worry every day about my job getting sold out from under me didn’t make sense.
Couple that with the fact that I was working for a company that left me feeling disrespected and underappreciated, and the markers became clear: moving on became necessary.
So to the job market I went, which brings me to now.
Is Loyalty Dead?
Gone are the jobs of yesteryear where people had 45+ years with the same employer, pension funds, and all of the other longevity perks that come with that kind of tenure.
As employees, we expect to have a big part in the future of our employment. We want mutual respect and investment.
We invest time in our employer. They invest resources in us.
I think with the right kind of culture and ideals, some jobs can definitely last more than two years.
I think that tools like the Glassdoor website will make employers more likely to concentrate heavily on a culture of retention because it will become more evident to employees when the grass is actually way greener somewhere else.
I think that the companies that care about employee well-being will do whatever they can to ensure cultures of longevity.
And those who don’t will continue to employ serial job monogamists.
I look forward to working for someone with a much stronger longevity mindset.
Over the years as a serial career monogamist, it’s become apparent to me that employees really want to have an engaged employer who looks at each employee with an open mind and an open heart.
The best employers are the ones who know how their mission should inform and steer their employees, and also know how to make their employees feel like they’re a critical and crucial part of the company mission.
I’m looking forward to learning more about my new career. And as I do, I’m excited about the prospect of not having to write another article about job changing for a very long time.
I have a multi-year history of clinical depression, diagnosed by several different medical professionals. It doesn’t come up often in day to day conversation, and generally speaking I don’t actually experience any symptoms.
But my depression hangs around. When I don’t take the time to appropriately work towards good mental hygiene, it comes back. Sometimes it gets ugly. Thankfully, this hasn’t happened to me in a couple of years. But it can happen, so I have to remain vigilant.
You may have already thought to yourself “Why in the world would I read a post about clinical depression? This blog focuses on programming, not mental disorders.”
I can answer that question in simple terms: the lifestyle of a programmer dramatically increases likelihood of clinical depression.
Depression Can Suck It
I make no qualms about this point, whatsoever. Depression is demon-spawn.
The disparaging awfulness that comes from depression makes the tangibility of evil seem exceptionally real.
Depression lies to you. It tells you you’re not worth it, that the world hates you, and that everyone would be better off if you weren’t around any more.
That’s on the days when taking the covers off and getting out of bed happens. Sometimes, depression will even sap the will to move.
Depression makes you feel like ending your own life. Because you feel like you can’t escape it – everywhere you turn it’s standing there mocking you, telling you how shitty of a person you are.
Yet, oddly enough, in a large majority of cases (mine included), lifestyle choices can help it change from all-consuming into easy-to-ignore.
Concentrate on getting enough Omega-3 fatty acid in your diet
Socialize (not just on Facebook!)
Avoid Rumination
Get Enough Sunlight
It’s important to go outside and get sunlight directly.
Which is something programmers, locked inside and coding for hours on end, often struggle with. Even if you work in a building with lots of glass and get sunlight while you work, unfiltered sunlight really matters. Even the best windows filter out some of the natural spectrum.
A couple things happen when we spend a few minutes outside every day.
First of all, our body is better equipped to regulate the amount of melatonin getting into our bloodstream naturally. This makes us sleepy at bedtime. Which is a good thing.
Second of all, it helps our body generate, regulate, and absorb serotonin. Chemically speaking, the way our brains handle serotonin directly impacts our ability to fight off depressive thinking. While I’m not as well versed on the comings and goings of what serotonin does in our brain, without it, we wouldn’t be feeling happy.
Plenty of evidence in our genome suggests that we haven’t really changed much since we grunted, scratched our armpits, and didn’t wear much covering our body parts. That’s right. I’m talking about cave-people.
You know what cave-people did when the sun went down? They went to sleep. It’s not all that easy to hunt without a light source.
A well regulated circadian rhythm does quite a good deal in brain regeneration. It helps us re-build brain cells, and use that serotonin efficiently.
When you go outside and get your brain to make melatonin correctly, listen to it. When your brain says go to bed… GO TO BED!
Programmers have a unique problem with this that really screws us up. We get way too much light that contains blue-spectrum wavelengths when we stare at computer screens all day.
One thing that helps me make sure I’m not tricking my brain? I use a hue adjusting program, like f.lux, to redshift the screens on my devices. Blue light suppresses our brain’s natural capability to react to melatonin properly. So tone down the blue light, turn up the red light, and make your brain think your laptop is a campfire.
Also, don’t stay up all night reading or tackling interesting side projects. While we all know how awesome the high is of solving a computing problem – sometimes we’re better at solving those problems if we just sleep on them.
Also – this one’s a biggie and will probably make you angry, get the TV or Computer out of your bedroom. I once had a great doctor tell me “The bedroom is for sleeping and sex. Period.” That’s advice you can take to the bank! If you bring externalities into the bedroom, sleep hygiene is super hard to achieve.
As a general rule – you really want to hit at least 7.5 hours of sleep every night. Anything less, and the rejuvenative and restorative affects sleep has just don’t get the job done.
The cool thing now is that smartwatches make it really easy to do sleep tracking. Though I don’t have any hard evidence about how accurate these are, I can tell you my Pebble does a pretty phenomenal job helping me ensure I’m getting the right amount of sleep.
Sweat
Ideally, sweat at the same time you’re getting those great natural rays of sunshine.
If you use the pomodoro technique (you should) then go sweat during the 15 minute long-break that it affords you. Walk a couple of laps outside of your office.
For me, walking helps me clear the cobwebs, re-focus for the next task at hand, and feel re-energized to focus in chunks again.
Getting the heart-rate up to the cardiovascular “breaking a sweat” range really helps.
When our bodies get exercise, we create something called endorphins. That’s the best natural high in the world, because we’re programmed internally to want to stay physically in shape. But as programmers, we sometimes spend too many sedentary hours in a chair.
Our paleolithic ancestors depended on sweat and fitness. Otherwise Mr. Sabertooth would have made a meal out of them.
Sweating Beats Stressing
One of the most important things you can do to reduce your stress load is to go take a walk if you’ve had an intense conversation.
Our emotions – and depression – all have direct link-ins with the hormone levels in our body. Back to those cave-people again. When we got stressed as cave-people, it was usually because we were about to die.
Stress works a little differently now. But our bodies still depend on us getting endorphins to counteract the cortisol hormone created by stress.
The best way to recover from an acutely stressful situation or conversation is to go for a brisk walk. Get your heartrate up a little bit. Your inner caveperson will thank you for it.
Sweat Can Break Sleep – Be Careful
Endorphins tend to trick our brain into thinking that it’s not a good time to be asleep. Back when we lived in caves, endorphins usually happened when we’d just been out hunting in the daytime, or when some kind of predator jumped upon us. Which means sleeping with endorphins flooding our brains is super hard.
Make sure you leave at least an hour (preferably several) between working out and going to bed. Once the endorphins wear off, the melatonin works even better than it would have if they hadn’t shown up in the first place.
Get Plenty of Omega-3 Fatty Acid
The gray matter of our brain uses one very important chemical as the basis for all of the other things happening up there.
Omega-3 Fatty Acid comprises a large majority of the stuff we use to think.
Unfortunately, most food produced in the USA is severely lacking in Omega-3 fatty acid.
I take a fish oil supplement every day, because I suck at eating right, right now. And I know plenty of programmers who think fast-food is an acceptable food group. I promise you, fast food is severely lacking in Omega-3 fat.
If you’re lucky (or dedicated) enough to live on free-range grass fed beef and wild-caught fish as your source of protein, this is not going to be an issue for you.
Grain fed food tends to lead to a disproportionate amount of Omega-3:Omega-6.
The fun thing is, the amount of Omega-6 you eat doesn’t really matter for brain health (though it might clog your arteries). As long as you push your Omega-3 uptake higher, it’s more about the ratio than the raw amounts.
Talk to Real, Living, Human People
I’m on several different Slack teams. Slack is an absolutely fantastic tool for team collaboration and idea sharing.
It’s a great way to keep in touch on projects. But it’s also a great way to lose touch with humanity.
Facebook, Twitter, Instagram, Slack, and all of the other platforms that allow us screen-focused individuals to connect with people actually have one extremely critical drawback.
Humans need human connection. Cave dwellers thrived in tribes that lived together, grew together, raised families together, hunted together, and died together.
Our brains crave interpersonal interaction. Which, for most programmers, seems pretty hard. Often introverted by nature, most of the programmers I know tend to keep to themselves and avoid actual human-to-human direct interaction. If nothing else, you can’t really spend a lot of time talking to others when you are working out a difficult portion of code or testing for the 80th time.
It’s important to have humans in your lives. Otherwise, your support network seems limited during those down times.
Don’t Shit On Yourself
This last one is hardest for me. Any time I accidentally cut someone off in traffic, or make some other socially awkward faux pas, I tend to beat myself up about it for a long time.
It’s hard not to overthink a situation. Especially because I’m a programmer, so I get paid to think. All the time.
Programming is an extremely subjective profession, which involves lots of peer-to-peer review time. Which also involves me constantly having to do a really good job of explaining why certain concepts have to apply, and why the team-appointed standards matter.
But, if my depression weren’t under control, I’d regularly worry about insulting a team member; or whether or not I screwed up in that bad traffic.
Here’s a hint – the colleagues I have grow better all the time. As of yet, I’ve never caused a traffic accident or any noticable road rage.
Dr. Ilardi’s book recommends setting an actual, literal, timer for what he calls rumination. If you can’t come to a meaningful actionable conclusion about a negative thought after 10 minutes, it’s time to shut that thought off.
We’re programmers. We have plenty of other things we can devote a huge amount of our brainpower to. Self-loathing really shouldn’t be one of them.
Pharmaceutical Help
I’m not super great at brain chemistry. Or chemistry at all, really. But, I know that chemical interactions in the brain dramatically impact depression.
Click on the link. I promise I’m not making up this acronym. It’s the Mother-F’r gene.
Mutations in this gene can reduce your brain’s ability to naturally produce something called L- Methylfolate Reductase.
Which can lead to depression susceptibility, because a reduction in that chemical is important to a chain reaction in the brain, allowing serotonin to work properly.
So, I take a couple of prescriptions to help. One’s called Deplin, and the other one is a low dose of Lexapro.
If I get really really good at sticking to the Six Steps of an Antidepressant Programmer’s Lifestyle, I may be able to drop off the Lexapro. But, for now – it stays as part of my regime. Likely for the foreseeable future until my kids get a bit older and I get better at managing my time.
Otherwise, I know that I’m not doing as well as I should be. And I don’t want to be that depressed again. Ever.
Beating Depression Makes Me Stronger
I reiterate – I have to be vigilant in order to make sure I can call my depression “beaten.” It never really goes away. I have to beat it every day.
You may wonder about the title, and why I included the word “Great”.
What makes depression great is diligently fighting the things that make depression worse. I actually feel more capable of being accomplished than I did before I started becoming depressed.
Living life in a way that combats depression improved my confidence substantially.
Though I’m by no stretch of the imagination the epitome of good diet and exercise practices, just knowing how much a good dietary lifestyle (note – this does not mean going on a diet) and regular exercise regime makes a big difference. It leaves me with more happy days and less stressful ones.
Mental and physical health have extremely tightly woven direct links to one another.
Take Great Care of Yourself
Depression forced me into improving my physical health and mental hygiene, but now I’ve got a great, always present motivator not to lose track of it.
That’s what makes depression great. Being depressed isn’t great. In fact, I hate it.
But, having depression always around reminds me to take care of myself. That is great. It’s kind of like my own internal accountability system.
If I don’t take care of myself, my depression returns. That’s all there is to it.
I’m motivated to take care of myself.
Hopefully, after reading this – it will help you see why self-care is so important, and so often neglected, especially for us as programmers. And you will be motivated as well.
We all deserve to feel great; and, most importantly, to be great.
