The Unlikely Role Model

When I first started blogging, I had a vague idea that real, live people might read my blog. Perhaps 3 or 4 people would type in a random URL, end up on my page, and spend a few minutes reading about Yak Shaving.

For the most part, though, I expected that my writings would float out into digital space, bouncing around in zero gravity with all the other unloved bits and bytes of the universe.

What I did not picture was that I would ever get the beautiful opportunity to be a role model for other Unlikely Developers.

When I say “Unlikely Developers”, I’m talking about people who don’t fit the mould: people who, by not fitting the stereotype, are constantly at risk of convincing themselves–or being convinced by others–that they are not cut out for this.

Writing has always been cathartic for me, but what has been even more cathartic is connecting with my readers.

Through my blog, I’ve met several people who were just beginning their journey–women, parents, low income and minority coders-in-the-making who are so passionate about learning to code, and so worthy of a spot in the tech world.

They’ve shared their joys with me as they get their first job or get accepted into their school of choice. They share their frustrations when they can’t get past a problem and wonder, “Am I kidding myself to think I could really be a developer?”

It is such an honor to be a part of these wonderful people’s lives, and to be the one to tell them, “That’s normal. I felt it too. You CAN be a great developer.”


Chaos, Order, and Code

I’ve noticed I go through a certain set of phases each time I move into a new job or get a promotion:
  1. Disorientation: I’m too new to have a clear picture of what it takes to be successful in the job. I complete the tasks, but feel aimless, as I don’t know which actions are truly impacting my success, or even what success looks like.
  2. Chaos: I gain a clear picture of all the skills I must master to be truly effective in my job, but I don’t know how to prioritize the learning. As a result, my approaches to mastering those skills are scattered and chaotic, making it difficult to see my progress. This is the frustration stage.
  3. Planning: I reach the point where I have sufficient information to make a plan. I analyze the skills I must master, prioritize them, and estimate how long it would take to master each skill. I begin to feel in control.
  4. Order: With plan in hand, I attack each skill gap ferociously. I steadily gain confidence as I watch the dominos fall. I am calm and focused.
  5. Knocking on the Door of Mastery: I master enough of the skills that my progress becomes apparent to others. Others start celebrating my successes, but I’m still not satisfied.
  6. Mastery: The dominos have fallen. I have attained a level of mastery that meets my own standards. The difference is small but noticeable to others. The difference is everything to me.
  7. Thumb Twiddling: Having mastered the skills, I wonder what to do now that my list is complete.
Both Coding Bootcamp and the first months of my job felt chaotic. I had too little time to stop, reflect and plan.

Yesterday evening I finally found the time to plan. I laid out every skill I needed to learn, ranked them by importance and by my current skill level, and made a graph showing the intersections between skill level and importance level. (Geeky, yes, I know, but that’s been established).

Other developers often try to be helpful by suggesting obscure tools and languages you should learn. They mean well, but if you try to follow everyone’s advice, you end up with DADD (Developer ADD). Sorting out what is truly important is a very difficult task. The graph helped me visualize the top priorities, which means I can finally stop chasing after every stick another developer throws.

It is such a relief to have a plan again.

Coding Bootcamps: A Fork in the Road for Tech Diversity

For years tech companies have lamented “The Pipeline Problem”: the shortage of female and other diverse candidates in the hiring pool.

The opportunity to change that dynamic may come from a surprising source: Coding Bootcamps.

Computer Science and other STEM majors consistently fail to attract female students. The reasons are complex, but 3 important factors are:

  1. The stereotypical profile of a Computer Science major does not meld easily with the average woman’s self-image. Young women recoil from Computer Science for the same reasons that men recoil from nursing. We simply cannot reconcile our self-image with the image we attach to that career.
  2. Computer Science programs involve intense competition between students. This feels very uncomfortable to women, who are taught to cooperate rather than to compete.
  3. Men get greater exposure to and encouragement in technology and math throughout childhood, meaning that female students arrive at CS101 already at a disadvantage. The teachers assume a certain level of knowledge from their students, and when a student does not have that base of knowledge on day one, she assumes she must be “less talented” or otherwise unsuited to the profession.

Examining the issue more closely, however, we see that girls are given less opportunities to explore computers. Subtle messages from parents, teachers, friends, and popular culture steer girls away from computer games, tech camp, and the joy of disassembling household electronics.

We may never know how much of the difference can be attributed to societal attitudes versus natural preferences, but ask any 3-year-old, and they can tell you what gender a construction worker or a nurse “should be”. The ideas about Software Developers evolve a bit later, but only because toddlers are not yet familiar with that career. Try asking a 10-year-old to draw a Software Developer. If you find one who draws a woman, $100 says her Mom’s a developer.

So, how do Coding Bootcamps factor into all of this?

Coding Bootcamps are in their infancy. There’s still time to mould them into the missing link for tech diversity. Mistakes were made at the inception of college-level Computer Science programs. Those mistakes can and should be remedied, but it will be an uphill battle. Coding Bootcamps have the opportunity to “do it right” from the beginning.

Another advantage for Coding Bootcamps it that their students are generally a few years older than college students. Those few extra years of maturity can make a world of difference. An 18-year-old college freshman still has a relatively unstable self-image and still feels the pressure to conform. A few years later, she will generally shed her desire to conform, accepting both the popular and unpopular facets of her personality.

Coding bootcamps come in at just the right time–late enough to give the student a chance to experience the work world, but early enough to leave years for a fruitful career.

By the time women gain the maturity level and motivation to buck the ideals of popular culture and fight the uphill battle to claim their place in the tech industry, they have often assumed enough family and work responsibilities that the traditional CS degree–with all its forays into interesting but impractical subjects–is so time-consuming as to be impractical.

Coding bootcamps, with their narrow focus on practical skills, give students the chance to learn the critical fundamentals in a short sprint, and then fill in the gaps on their own time.

How can Coding Bootcamps take an active role in changing the dynamic?

  1. Explicitly state all prerequisite knowledge, along with how to obtain it. Never assume knowledge, no matter how basic you believe it to be.
  2. Give added support to diverse students. Recognize that they may have unique challenges, such as the need to balance outside responsibilities and school, gaps in foundational knowledge, impostor syndrome, or feelings of social isolation.
  3. Implement Social Rules: Stepping outside of your socially-ordained role is taxing on the ego. Micro-aggressions, whether intentional or unintentional, can have devastating impacts on diverse students. Hacker School has a very impressive student manual with social rules that I would love to see implemented in every Coding Bootcamp.
  4. Partner with companies that are looking to improve diversity. Large companies can pay for bootcamp training for employees who are looking to switch from a non-technical career into a developer role, or simply hold their jobs while they retrain.
  5. Give up on the ideal of the Natural Super Genius Developer. Natural talent? It’s a myth. Talent does have a genetic component, but genes are expressed differently based on environment. Deliberate practice is the key to mastery of any subject, and propagating the myth that some people are born with the ability to write beautiful code only discourages budding talent.

We are at a fork in the road, and now we must choose: Will we continue with the status quo, checking the box for “minimum diversity level attained” or will we recognize this unique opportunity, and address the systemic issues that sustain our homogenous technical culture?

What Coding Bootcamp Doesn’t Teach

When I was going through Coding Bootcamp, I wondered if I would really learn the skills I needed to be a software developer.

The answer is that coding bootcamp is only a small piece of the journey. Learning to code is a marathon, and attending coding bootcamp is like sprinting 500 yards to get to the gigantic water station. By attending coding bootcamp, you’re able to dump that refreshing, icy water on your head much sooner than the steady joggers, but the race doesn’t suddenly end. You still have endless miles ahead of you after you reach the water station.

Here’s a snapshot of what you learn in each phase of the marathon:

The Stretch (Learning Before Bootcamp):

  • HTML and CSS: The Building Blocks of Basic Websites. (see General Assembly’s Dash or Codecademy HTML & CSS)
  • Basic Programming Concepts: Exposure to loops, control flow, data types, etc. (see Codecademy Ruby or Learn Ruby the Hard Way)
  • Basic Command Line Skills: changing directories, moving files, etc. (see Learn CLI the Hard Way)

The Warmup Laps (may be before or during bootcamp, depending on school)

  • Object Oriented Programming concepts: Classes, objects, encapsulation, polymorphism, etc. (, $25/month)
  • Basic Database Concepts (SQL / Relational Databases)
  • Model View Controller
  • REST

The Sprint (during Coding Bootcamp)

  • how to solve problems with code
  • how to make websites with code
  • how to get data from other websites through web services
  • practice making and breaking a lot of stuff

The Water Station (reaching your first job, where you get paid to learn and have more resources)

  • Practice coding all day without sacrificing the ability to support yourself
  • Have constant access to experienced developers for help
  • Get company-provided resources: libraries of programming books, Lunch and Learns, etc.
  • Get a clear picture of what specific skills you need to learn

The Rest of the Marathon

  • Learn about design patterns (see Principles of Object Oriented Design in Ruby)
  • Learn about Data Structures (, $25/month)
  • Deepen your knowledge of every subject you studied: databases, Ruby, Rails, web services, command line
  • Learn the operating systems, text editors or IDEs, monitoring apps, deployment and hosting apps, and other tools your work uses. (God help you if you have to learn Vim as a newbie.)
  • Learn Agile best practices. Learn to scream and claw your face if your company uses Waterfall-style development.
  • Learn other languages that give you a new perspective on code: C++, Java, Assembly, and Lisp are frequently mentioned as brain-stretching languages.

The hardest part of the journey is the beginning. It’s like running without water.

Things get easier once you reach your first job. Coding becomes a built-in part of your day, rather than an extra task that must be squeezed into the crevices of your life. Yet, once you start your job, you find that just learning on the job is not enough.

There’s still so much to learn, so you lace up your running shoes and get back on the track. If you’re like me, and you love the feel of the road beneath your feet*, this will be a joy rather than a burden. You never reach the finish line, you just learn to love the race.


*You might get the impression from this post that I love to run. HA! I wish. I love running about as much as I love drinking Clorox.



Human Readable Documentation for Ruby srand

How does the Ruby’s srand (seed random) method work, and why would one use it?


I often come across Ruby methods that seem to be documented for something other than a human being.

When I read documentation, what I’m looking for is:

  1. What is it?
  2. When would I use it?
  3. How would I use it?

Most of the time I can find a blog post that fills in the gaps, but I came across a Ruby method today where I couldn’t find any useful documentation: srand.

After poking at it for about an hour, here’s my attempt at documentation:


First Some Background on Random Numbers:

Here’s a secret: They’re not really random. (Shhh, don’t tell the anti-Geeks.)

In reality, it’s not possible for a computer to generate a list of truly random numbers. What they do instead is take a seed number, muck around with it a bit until it’s changed to another number, and then spit out that number. Since we don’t know the algorithms used for the “mucking around” bit, even if we knew the seed number, the result would still seem random.

Usually the seed number is generated by the computer using a combonation of elements such as the exact time the random number was requested and the process ID of the program. These elements change constantly, so if you request a random number now, and again 1 millisecond from now (because you’re a really fast typer), the seed number would be different. When the seed number is different, so is the resulting “random” number.



Now, onto how srand works:

What is it?

Srand lets you pick the seed number so you can generate a list of numbers that seems random, but is actually predictable.

When would I use it?

Srand is most likely to be useful during testing.

Let’s say you wanted to test a method that normally uses a random number. In order to test if it’s working correctly, you would have to know what result to expect, and that’s not possible if the random number is generated every time the test is run.

Srand would let you simulate the idea of a program handling random numbers, but with results that are still predictable enough to test.

Or you could:

Use method aliasing to overwrite Ruby’s normal rand method, memorize the first 100 results with your chosen seed number, and convince people that you’re psychic by consistently guessing the next “random” number.

How would I use it?

1. Set the seed number:


2. It will return a list of random numbers that would be generated using that seed number:


3. The next method that uses rand will use the seed number you specify.

for i in 1..10

puts i


This will return the same random numbers you got when you first typed srand(1234). In this case it will return the first 10 numbers of the set.


4. The seed you set works only once, so the next time you call rand, it will not use your specified seed number.

for i in 1..10

puts i


–> now returns a different number.

And that, my dear readers, is how srand works.

Pairing with Intent

Why did you pair program today?

No, I’m not asking why you pair program in general. Anyone can list the benefits. I’m asking “Why did you pair program today?”

The articles I’ve read all claim that when pair programming is done right, participants will reap a host of benefits, including:

  • Increased Discipline (Less goofing off)
  • Better Code (2 brains are better than one)
  • Resilient Flow (One pair handles an interruption while the other maintains the flow)
  • Improved Morale (More enjoyable than programming alone)
  • Collective Code Ownership (Less finger pointing, more shared trophies)
  • Mentoring (Natural way to share knowledge)
  • Team Cohesion (Definitely will know each other. Hopefully will like each other.)
  • Fewer Interruptions (People know you’re busy because you’re thinking out loud)

I’m not disputing the accuracy of the list. YES, these benefits result from effective pair programming.

The mistake is in the assumption that all pair programming sessions will produce all of the benefits.

I assure you that is not the case. In reality, each session delivers a small subset of these benefits. The benefits produced depend on several things:

1) The participants’ relative skill levels

2) Their personalities and relationship with each other

3) The goal of the pair programming session.

Let’s look a few of the team roles and how they benefit most from pairing:

The Junior Developer

  • Benefits most when:
    • working on an issue just above his/her current level of knowledge
    • paired with a person who excels in mentoring others
    • NOT paired with the most senior team members (the gap in knowledge becomes frustrating for both)
    • given solo time to fight through simple issues on his/her own (builds confidence)

The Senior Developer

  • Benefits most when:
    • working with someone who has domain-specific knowledge
  • Provides most benefit when:
    • Working on complex or critically important issues
    • Paired with a developer who is only slightly less experienced
    • Paired with the express intent to mentor

The Mid-Level Developer:

  • Benefits most when:
    • Paired with a Senior Dev on a complex issue
    • Paired with another mid-level dev on a standard-complexity issue
  • Provides most benefit when:
    • Paired with a Junior Dev with the express intent to mentor
    • Paired with another mid-level dev on a standard-complexity issue

The Shy Dev

  • Benefits most when:
    • Paired with someone who forces him/her to socialize

The Introverted Dev

  • Benefits most when:
    • Encouraged to pair, but given the freedom to work alone to get a break from socializing

The Extroverted Dev 

  • Insufficient data for analysis.

Pairing is an incredibly effective tool, but it is just that: a tool. No tool is right for every job, and not having a pair can be better than having the wrong pair.

It’s time we start asking ourselves: What am I trying to accomplish with this pairing session? What pair will benefit most from tackling this specific issue? Would pairing be helpful or wasteful on this particular issue with this particular pair?

Learning On the Job

Today a friend who is about to start his first job as a Junior Developer asked me a great question:

“Do you still find the time to study outside of work or has on the job learning become way more valuable?”

Here’s what I told him:

I definitely learn a lot of things at work that I would not learn outside of work, but I also spend quite a bit of time filling in the gaps outside of work.

For example, sitting with a developer who is awesome with Git shows me some new Git features I never would have learned on my own, but it also tells me, “Okay, apparently there’s still a lot I need to learn in that area”, so Iend up studying it at home.

Basically, I’m exposed to a lot more things and get a better idea of what I need to learn, but then I have to put in outside time to learn them. (Which is a little hard because my outside time is so limited).
Overall, I think the best learning experiences are a mix of being taught and teaching oneself.
When I’m paired with someone who likes to teach, I think I learn as much or more than I do alone. When I’m paired with someone who doesn’t stop to explain, I end up wishing I could spend the time teaching myself.
In an ideal world, I’d have plenty of time for both types of learning. For now, I’m soaking up everything I can from my peers, and trying to squeeze self-teaching into the tiny slivers of time left after work and family take their share.