Blogging for CodeNewbie

I’m excited to announce that I’ve started blogging for CodeNewbie!

If you haven’t heard of it, Codenewbie is an organization dedicated to helping people learn to code. They have a Podcast, Blog, weekly Twitter chats, and a ton of other resources for people at any point on the journey of learning to code.

I’ll be writing the Ruby Roundup series, which is published every 2 weeks. My first blog post is live here.

Check it out!

What Every Junior Rails Developer Should Know

Not long ago, I shared a link to an outstanding video called What Every Junior Developer Should Know.

That talk was geared toward Front End Developers, but most of the content overlapped with the subjects that Back End Developers should know.

I happened to come across a diagram that my instructor from The Iron Yard shared on the first day of class.

When I first saw it, I was familiar with only about half of the terms on the diagram, but coming back to it after 6 months as a Junior Developer, I feel that it is a great summary of the tools and topics that I use every day.

As one reader pointed out, although the diagram says “Ruby on Rails Competencies”, it is actually a diagram of the skills required to become a Full Stack Developer. Many Ruby on Rails developer roles will never touch some of these areas, such as Javascript, HTML and CSS–which are Front End skills. Large companies often have dedicated teams handling databases and testing, as well. However, having at least some familiarity with these topics is important.

That being said, the following categories are the primary focus for a Rails developer: operating system, command line, WWW, Ruby language, Rubygems, Rails Framework, Git and IDE/Text Editor.


One blog post isn’t enough space for an overview on all these topics, but here is the first:

  • Operating System:
    • Rails developers generally develop on a Mac or on a Linux Operating System; Windows is not compatible with many software development tools
    • Mac OSX and Linux are both based on the Unix operating system, so they are similar in many ways
    • The Mac OSX is generally easier to use, but less customizable, and only run on Mac computers, which are expensive
    • Linux comes in many flavors, such as Ubuntu, Fedora, and Centos
    • The benefits of Linux are that it is free and customizable, and it can be installed on any computer
    • The downside is that installing and running software can be more complicated on Linux, especially since most users are tech people. The documentation is not very newbie friendly, but fighting through setup issues can be a great learning experience if you have someone to help when you get stuck
    • What you need to learn:

Learning the Mac OSX or Linux operating system is a great place to start.

Leave a comment if you found this article helpful. If it is helpful, I’ll try to go into more detail on the other topics.

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.

Simple Template for Ruby Test Driven Development

Recently, I decided to spend some time practicing Test Driven Development by solving Project Euler problems with TDD.

This led me to an interesting problem: outside of Rails, setting up a test environment is a time-consuming task.

Inside of Rails, all of the configuration is taken care of for you. But Rails was overkill for my needs–I didn’t need models, controllers, views, Active Record, automatic pluralization, leprechauns, unicorns, fairy creatures, or any other unruly magical beings.

I just needed tests.

So, rather than fight with unwanted magical behavior, I invested an hour in research and created a very, very basic test environment.

If you’d like to use it, feel free to clone my repo:

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.

Back in Coding Bootcamp

I’m going back through coding bootcamp. Well…kind of.

I’ve been wanting to improve my Javascript skills, since my original experience learning Javascript was…how to describe this…like having a pie thrown in my face.

My first experience with Javascript was around week 6 of coding bootcamp. I was just starting to understand the basics of Rails when–SPLAT!–Javascript! and then SPLAT!–Jquery. I ducked in time to dodge AngularJS.

It was a poorly-timed introduction, so I ended up initially hating Javascript. I mean, come on…does any language really need that many parenthesis? And don’t get me started on semicolons. (And yes, I have heard of LISP but I will continue to complain about Javascript’s parenthesis until I learn LISP, which I am penciling into my calendar for “never”.)

Javascript and I got off to a bad start, but I’m not one to hold grudges. Javascript, I forgive you for the pies, and I will try to accept you, semicolons and all.

I have decided to start again from scratch, as if I had never seen a line of Javascript code in my life.

Besides wanting to relearn Javascript, I had also become very curious about FreeCodeCamp. I wondered:

Does Free = low quality?

Could you really get an education equivalent to a full-time bootcamp from an online course?

How does one go about making a coding bootcamp free, when every other one charges Harvard tuition?

That curiosity brought me to sign up for FreeCodeCamp, and so far I am very impressed!

I hadn’t expected to learn anything in the first few lessons, since I already knew HTML and CSS quite well. To my surprise, they were much more than a great refresher.

For starters, HTML5 and CSS3 have a lot of major changes. Come to find out, I had not picked up on all of the important ones, despite reading an entire book on it.

Much more important than the additional practice and a deeper dive into the syntax changes, was the quality of the exercises.

I should mention that FreeCodeCamp did not create the exercises. They are simply a curator, serving up the best free resources on the internet, saving you the time of figuring out which resources are worthwhile.

The exercise that impressed me most was an exercise in General Assembly’s Dash program, which teaches you to make an animated robot using only HTML and CSS.

It’s an incredibly creative use of the tools–I never would have imagined that such a thing could be created without Javascript or pre-made images. The exercise really broadened my idea of how I could use HTML and CSS.

FreeCodeCamp has me hooked. It appears that I am once again in Coding Bootcamp.

Working Conditions

My workplace has a very unique setup for the developer room.

Most developers work in small, silent rooms. This makes a lot of sense, because deep thought is easier in a silent environment.

At my company, we have a completely different setup: no less than 30 people in a big, open room. We have 12 backend developers plus business analysts, an Iteration manager, a Product Owner, and Quality Assurance people. Basically, we have every person who touches our app crammed into one giant, open room.

It’s an environment full of distractions, but pairing makes things easier. When you’re paired with another person, your focus narrows, and you can concentrate on just that person, blocking out the chatter of the rest.

On the plus side:

  • Getting help is a non-issue. I can’t count the times that someone has overheard my pair and I talking and chimed in with, “Oh, I had that problem yesterday. This is how I got past it.”
  • It pushes the developers to cultivate advanced social skills, by forcing them to deal with issues like negotiating music selection and volume. Conflicts come to a head quickly and are remedied just as quickly, allowing for a more cooperative environment.
  • We get to know our teammates very, very well. Team-building is automatic.

The downside:

  • Introverts have a limited capacity for social interaction. I lean only slightly toward introversion, and I leave work every day with my well of socialization depleted. I crave silence and there’s nowhere to find it, at work or at home.
  • Working through something alone is impossible. When my pair steps away, I try to think through the problem alone, but if I’m not talking out loud about the problem, I can’t hear myself think.

Some of the other developers like the setup, and others hate it. As a new developer, the ability to get help is especially valuable, so the benefits currently outweigh the costs. We’ll see if that stays true as I gain more experience.

On a side note, it seems that the cure for Writer’s Block is to write about it.

Writer’s Block

I have Writer’s Block, so I figured, “I should probably write about that.”

I’ve started at least 5 blog posts in the past week. I’ve deleted more lines than I’ve written. (Yes, it is possible. You just have to delete someone else’s writing.)

A few things I’ve started to write about:

  • The opportunity to leverage coding bootcamps to improve the IT gender gap
  • Puppet shows with the kids
  • Ruby Enumerable (I’m walking through the documentation, writing a program for each Enumerable method)
  • Work: I’ve finally gotten enough of a grasp of things to start contributing in very, very small ways

Each time I start to write, my brain screams, “Stop! No! Don’t want to think!” and then red lights start flashing and a mechanical voice says, “Powering down.”

I’ve been pair programming daily at work, stretching my brain power and my social interaction limits to the max. It’s only now, as I write this, that I’m realizing just how fried my brain is. Thinking about it hurts.

(Mechanical voice): Switching to auxiliary power. Shutting down all non-essential brain functions. Good. Bye.

The Developer Pit Crew

Software development is a roller coaster ride for the ego.

For every “Aha! I’m a genius!” moment, there are 10 “I’m a freakin’ idiot. How did I ever pass Kindergarten?” moments.

It takes a certain amount of ego to survive a job that is 90% error messages, 100% of which were created by “Guess who? Your-very-own-personal-self.”

We like to blame the computer, but deep down, we know it’s doing exactly what we told it to do, which is, again, 90% of the time, to tell us “Wrong! You are a big, fat idiot who should have been held back in Kindergarten.”

It’s no surprise that seasoned developers grow a nice, sturdy shell around their egos that deflects all potential criticisms with a scoff and a raised eyebrow. We must forgive these experienced developers for sounding like they think they are Almighty, Powerful Sun-Gods Who Make Rain as a Side Hobby. They don’t mean to come off as egotistical, they’ve just forgotten to remove their ego shell before socializing.

That, of course, does nothing to help those of us who still have thin, scab-like ego shells. The criticisms bounce right off the seasoned developer’s backs and skewer us like a Junior-Developer-Tortoise-Kabob. (Tortoise because of the shell–get it? No? Well, you probably shouldn’t admit that. Not admitting what you don’t know is one of the unspoken rules of software development. Violators get sent back to Kindergarten.)

So, how does one survive the daily ego-barrage?

This is where the Developer Pit Crew comes in. (Yep, we finally got to the reason for the title.)

The Developer Pit Crew is the group of people who can be counted on to remind you that, “No, you’re not an idiot. Yes, you did graduate Kindergarten, and no, that was not a clerical error.” For a female developer, this pit crew has the additional responsibility of reminding you that “Yes, you do belong, even if it’s a boy’s club,” and “No, being a geek does not make you any less feminine,” and “No, you have not grown a neck beard or a lightening-shaped scar.”

For me, those people are:

1) My husband, who beams with pride when I go off on a Geek Tangent, and tells me there’s nothing sexier than a smart woman. (And who then, patiently answers, “Yes, I mean you.”)

2) My brother, who told me, “There are people much dumber than you who learn to do this. I know you’re way better than you think you are.”

3) My dad, who, because he is also a software developer, is hard to argue with when he says I know what I’m doing. (Not that I don’t try.)

That’s a pretty bad-ass pit crew, if I do say so myself.

Tower of Babel

I’m a month into my first job as a developer, and I’m beginning to learn the language–not the programming language, but the company language.

In my first weeks, there were so many new terms being thrown around that I felt like a Martian at a UN meeting. There are at least 50 languages spoken here, and it’s very difficult to tell which language a word belongs to, when everyone keeps mixing them together.

First, there are the programming languages: a steam pot full of Ruby, Java, HTML, CSS, and Javascript.

Then, there’s the company-specific language: application names that have nicknames for their nicknames, department names that sound like people names, computer names that sound like band names, people names that sound like computer names, and acronyms for BLOODY EVERYTHING.

There are a Lori and a Dori, neither of which are human. There are a Toddy and a Will, both of which are human, neither of which uses the name reflected by his email address.

There are 3,000 Johns and so far all of them are human. I am, however, working from a very small sample size. It’s quite possible that non-human Johns will be discovered with further analysis.

There are a Puppet and a Jenkins, which could have been humans or computers or bands or departments, but are in fact, tools that Google could have explained to me.

I would try to document these things for the next new dev, but even as I speak, Loris and Johns are being replaced by newer, more abstract acronyms.

I guess it’s every MAN for herself. (MAN’s a department, right?)