Why I prefer soft talks and the hallway track at conferences

This post was originally a TweetStorm. You can see that Tweetstorm storified here

After RubyConf 2015, I was encouraged by Sarah Mei and Ernie Miller to write about my experience.

I left that conference, with feedback that I preferred the wetware, soft skill, and hallway tracks.

I can watch a “soft” talk and then go on to engage with others in the hallway track in a discussion of the questions or concepts posed.

Though I gain value from a hard or technical talk, the most I can use that as a start to a deeper conversation is “I liked that talk” or “I will use that technique later.”

Talks like Avdi Grimm’s at Lone Star Ruby, Sandi Metz’s at Keep Ruby Weird, and Carina Zona’s at Ruby Conf stay with me.

I still think about those talks. I’ve had further discussions about those talks. I refer to them in conversation with other people, devs & non-devs alike. Now this doesn’t mean that I don’t think you should sit in “hard” talks. If you do & they bolster you. You do you.

I’m talking about some level of ripple effect that occurs from a “soft” talk. It may not speed up your test suite. Yet, it might change how you write features, or how you test. Or more immediately, again, make you start conversations about the topic.

Additionally, I feel as if I leave “soft” talks with questions. Open questions, which propel me to chat with the speaker.

“Why did you say this?”

“What did you mean by that?”

Leading to, “Who are you eating dinner with?” or “Thank you, can I buy you a ☕🍻🍩?”

It helps foster a human connection that doesn’t always come from leaving with a mind full of code. Let’s say I leave and spend 6 hours building something in Padrino. Could I have spent those hours building something with someone?

If this is you though, scream it from on top of a mountain. Maybe take the time to ask, “Who wants to hack on Padrino and test suites for 4 hours at ___?”

So all I’m saying is, rethink avoiding those soft talks, because they may create conversations & friends you didn’t know you could.

Thoughts on learning as a junior dev

This post was originally a TweetStorm. You can see that Tweetstorm storified here

As I’ve been spending more time working with junior developers, including my time with Austin Coding Academy, Dev Bootcamp, and Codecademy I’ve noticed a few patterns that intrigue me about the way we teach programming.

Usually we start with HTMl then CSS then JavaScript. This makes sense to me because it starts with concepts a lot of people have cursory experience with at the very least. Whether that’s using MySpace or building email campaigns. There are numerous other opportunities where these languages are used outside of being a pure developer.

Weaving education together rather than teaching silos

Yet, it feels to me that online learning platforms that teach these in silos rather than a meshed method lose opportunities to teach core coding superpowers. By doing so they teach the basics of Web Fundamentals without the supporting tools.

Everyday I work as a developer, I make as much use of my browser’s DevTools, the command line, and git. It seems learning about these tools, along with including lessons surrounding how to learn outside of a platform or finding answers to questions not in the lesson, are sorely missed. This is something I see regularly with early junior devs and recognize in myself as well.

Fair enough this may lead your user away from your learning platform, I understand that is not something you want to encourage as a business. However, does it not make them a more successful developer and thus have a better overall experience with learning on the platform.

I’m of the opinion that you can teach DevTools and research while you teach HTML and CSS. There’s no reason you should get to JavaScript or even jQuery without these skills. They solve so many early struggles.

Teaching superpowers early on

Now to my second point. In line with this, familiarity with the command line and git feels like it would also benefit from being taught earlier in the jr dev process for no other reasons than to give them super powers over their machines.

With great power comes great responsibility. Sure they could go off and delete their entire system accidentally. That’s a lesson in an of itself. There’s something to feeling like you’re a badass console cowboy.

Again these are core skills that if someone doesn’t continue on into Web Development helps them solves other problems or move into other IT roles.

More importantly, I think is the feeling of exploration and discovery. It feels to me that learning the command line creates a path to learn git which as of my experience leads to Github or some other similar platform.

Even if that feeling of exploration is overwhelming or daunting it’ll usually open your eyes to a whole new world. All of a sudden you can find a whole host of resources. Things like:

  1. AngularJS Learning
  2. Engineering Blogs
  3. Free Programming Books

Learning environment versus learning platform

My concern with some learning platforms is that you continue through them and then think, “What’s next?”

This isn’t entirely the fault of a platform or a course. It’s just as much about the student. Yet, why not tease them with further exploration, you’ve learned this and this, you should learn this or watch this or be involved with this.

These programs have no doubt thought about this. Some are much better than others. This is my number one belief in the value of a developer bootcamp environment. Some might see it as “join a bootcamp, get a high paying job” , but in hindsight it’s “consider joining a bootcamp to find a community”

This is the shtick you here from high cost colleges too, which should give students equal pause. Doubt or educated doubt is not a bad thing. It’ll challenge your preconceptions. It’ll also help you ring true during these opportunities.

You will of course learn a lot in these environments but that will only increase through interaction & growing with your peers in comparison to working in isolation.

Prototype and Inheritance in JavaScript (presentation)

This presentation is an additional resource based on the lessons learned in Part 2 of my series of three about JavaScript Inheritance and JavaScript Prototypes.

Basics of JavaScript Prototype-based Inheritance (Part 1)

Basics of JavaScript Prototype-based Inheritance (Part 2)

Basics of JavaScript Prototype-based Inheritance (Part 3)

You can find the code for this series here.