Benchmarks of Failure and The Budding Developer Ego

I firmly believe that the most difficult part of becoming a software developer is the psychological aspect: balancing your ego as it morphs into a tomato-shaped pincushion, pricked daily with the bite of tiny, insignificant failures.

As a budding software developer, you cannot simply be satisfied with your current, comfortable level of skill. You must always seek out greater challenges. You must always take on tasks with a high risk of failure. It’s the only way to grow.

The failures come in many forms:

  • Not knowing something you think you should know
  • Not knowing something someone else thinks you should know
  • Failing to complete a task that seemed oh-so-easy
  • Seeing someone else complete that task, confirming that it was oh-so-easy
  • That stupid error message that just will not go away, no matter what you try
  • That stupid error message that goes away when it shouldn’t have
  • Breaking the build
  • Having to swallow your pride and ask for help
  • Having to swallow your pride and ask for help AGAIN
  • Oh, yes, and again
  • And again
  • And again
  • And again

It’s a hard world to live in, and I can’t help but be fascinated by the strange ego dichotomy that it produces, with some egos shrinking into Impostor Syndrome, whispering to their owners that they are morons who have somehow been lucky enough to fool the rest of the planet, and others growing into Lernaean Hydras, sprouting ever more vicious, condescending heads after each ego blow.

We must take steps to protect our fragile egos, lest we become the Incognito Imbecile or the Hydra-veloper that so many before us have become.

One technique I use to protect my own ego is to use what I call “Benchmarks of Failure”.

I had observed 2 things:

  1. With software tests, we expect failure as a step in the process. We set our system up for failure, document the failure (by watching the test fail), do some work, and then watch the failure turn into a success.
  2. The most satisfying things I’ve accomplished as a Software Developer all involved succeeding at something that I vividly remembered failing at previously…solving a problem that I previously did not have the skill to solve.

That led me to the thought: Why can’t we follow a similar process in growing our skills as a Software Developer?

Here is my “Benchmarks of Failure” process:

  1. Try a difficult new task and document:
    • The date
    • Whether you were able to complete it
    • How long it took to complete
    • How many times you had to ask for help
    • (Optionally) The array of curse words you hurled at yourself
  2. Set some goals:
    • What would you like to improve? The time it took? Just completing the task? Not having to ask for help?
    • When would you like to accomplish this by?
    • What would you need to learn more about in order to achieve that goal?
  3. Come back and watch yourself succeed

It would seem that this would only help prevent Impostor Syndrome, but I’m convinced it would also help the Hydra-velopers out there. After all, I think an overactive ego is really just a symptom of deep-seeded insecurities.

I am blessed to work on a super-supportive team, but I know way too many developers who have been planted in toxic soil. Perhaps, if this generation can better shield our own egos, we could help plant a stronger next generation. I’m picturing it now…a world with no Impostors and no Hydra-velopers.

What Every Junior Developer Should Know

It is very, very rare that I find a video worth devoting 2 hours of my life to, but today I found one. In my case, I actually devoted 4 hours of my life to this 2-hour video, because having children doubles the time it takes to do everything. (Scientifically proven.)

The video is Stuff Every Junior Developer Should Know, a speech given by Laurie Voss to a group of students at Hack Reactor.

Omar goes over the top things that more experienced developers wish Junior Developers knew.

Amongst other things, he goes over:

  1. Security & OWASP Top 10
  2. Performance: Speed, Efficiency, Throughput & Latency
  3. Caching
  4. Coding Antipatterns
  5. Databases: pros and cons of the most commonly used DBs

What really makes this talk unique is that he approaches each of these topics with no assumption of prior knowledge. His explanations are simple and straight-forward. He’s not giving a deep-dive on any of these topics; he’s giving just enough info for you to understand the concepts, identify whether you need to learn more about that area, and be well prepared to digest the resources he recommends for further learning.

If you have time to watch the video, I absolutely recommend it. If you don’t have time to watch the video, there’s a recap on Github, but be warned: it isn’t complete, and you will miss a lot of the best content.

The person who posted the recap, Omar Duarte, asked for contributors, so I put in a pull request recapping the section on security and OWASP. Hopefully it will be merged in, but if not, you can see it on my fork of his repo.

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.

Pairing Effectively with a Junior Developer

Pairing a junior developer with a more senior developer is an excellent way to get the junior person up to speed quickly. It can also have unexpected benefits for the senior developer, since the junior team member will often question things that a senior team member would not think to question.

“Why does Bicycle inherit from Grapefruit?”

“Um, I don’t know. It’s been that way since before I got here. At first I thought there must be a reason, but I didn’t want to ask, and then I guess I just got used to it. Yeah, we should probably change that.”

It’s easy to forget, however, that pair programming–especially with a junior team member–is a demanding task that requires a unique set of skills. The greatest programmer on the planet could be utterly incapable of mentoring a junior developer.

A great mentor needs:

  • Patience: He must be able to wait for a person to solve the problem, even when he could have solved it himself in a fraction of the time.
  • Excellent communication skills: He must be able to explain what he does and why. He must also be able to ask questions that provoke thought while boosting, rather than undermining, the learner’s confidence.
  • Awareness of body language: He must pick up on the clues that say, “I get it,” or “I’m lost”, or “I’m thinking. Now is not a good time to interrupt.”
  • Belief in the value of teaching: He must believe that teaching the junior team member is a valuable use of his time–that it is worth reducing his capacity in other areas so that the new team member can learn. He must find satisfaction in seeing the junior team member make a great leap in understanding, even if that leap of understanding was at the expense of short-term productivity.

The best mentors:

  • Meet the learner on their level, without judgment. Rather than assuming a certain level of knowledge, they quietly assess the learner’s current knowledge and make a plan to move them forward from there. If the learner turns out to know more or less than expected in a certain area, they quickly adjust.
  • Let the learner drive, but never forget to navigate: They start by telling the learner explicitly what to type. Next, they hint at what should be typed without saying it explicitly. Later, they simply ask Socratic questions to get the learner thinking in the right direction. As the learner progresses, they give less and less guidance, but they are always ready to step back in when the learner gets lost. Even when the learner is completely lost, they do not take over the keyboard–they simply get more and more explicit in their instructions until the learner is back on steady ground.
  • Gently praise and reassure: Learning something new is taxing on the ego. Hearing an occasional “Good job” or “That’s okay. You’re doing fine,” reduces frustration and keeps the learner motivated.

Mentoring is a complex skill. Anyone can learn to mentor, but it comes more naturally to some than to others. Some developers will see the value in mentoring a new team member, and others would rather be responsible for only themselves.

When a new developer joins the team, it’s critical to pair them not with the best developer, but with the best mentor.

New Developer (dis)Orientation

I find that I’m slightly less disoriented every day.

My first month at my new job was a complete blur. Then the holidays passed and I was able to spend more time pairing.

One day I realized I had started to understand the majority of the conversations around me. Meaningless acronyms started to make sense, and I began to understand the cards on the wall (each of which represents a small development task) without having someone explain them.

A few days later I was “driving” (being the one on the keyboard) with Vim and Tmux–both tools I’d never used before I started this job.

A few days after that, my pair started challenging me with questions like, “What should you do next?” At first I thought, “I don’t know, and I’m not sure I’ll ever know. I don’t even think I understand the problem.”

It was only a couple of weeks ago that my pair was having to tell me explicitly what to type. Over the past week I’ve been able to make progress on issues even when my pair steps away or leaves early.

The last two days were especially eye-opening.

One of the Senior Developers spent a couple of hours walking me through the notification system, which is one of the most complex parts of the code. Somebody got really meta-programming-happy in that big pile of code spaghetti.

Yesterday was also a great learning experience. I paired with another developer who was hired around the same time as I was. He has a good bit of experience in other languages, as well as a deep understanding of Linux operating systems, but this is the first time he’s worked in Ruby on Rails or used Git.

In other words, we have exactly opposite skill sets.

We spent the day going back and forth, with him teaching me advanced Bash commands, and me teaching him Rails. Then we picked up a card and worked through it together. With our complimentary skills, we were able to complete it without help from the Senior Developers.

I can finally visualize what it will be like to be an asset to the team, rather than a liability.

New Developer Snipe Hunt

Today is day 4 of the New Developer Snipe Hunt. It is theoretically possible to set up the development environment for my company’s massive, monolithic, fire-breathing, underpants-staining legacy-code-laden Rails app on a Vagrant box, and that is exactly what I and the other new Junior Developer are tasked with doing.

I swear to God, that app is running on black magic.

There is no other logical explanation for the fact that so many cobbled-together support applications should find the spiritual harmony to work together and produce a viable application that does not take customers hostage and boil them into a thick, boney stew.

(muffled screams)

Oh, Lord, it ate another developer. If I’m not back in 10 minutes, tell my husband I love him.