Forem: Robby Russell 🐘🚂

Rails Core AMA - Rails World 2023: Hosted by...me!

Robby Russell 🐘🚂 — Wed, 18 Oct 2023 11:43:45 +0000

As a contributing member of the Ruby on Rails Foundation, Planet Argon is delighted to collaborate with the Rails Foundation Core members and other contributing members to improve and maintain the future of the Rails community for all of us.

In a remote work world, getting together in person is challenging, so we can't pass it up when an opportunity arises!

Recently, I headed out to Amsterdam for Rails World 2023!

Besides listening to insightful keynote talks and connecting with new and seasoned Rails practitioners, I was invited to host the Rails Core AMA Panel. Ten current 12 Rails Core members sat down to answer questions submitted by the Rails World community in the days leading up to the event.

In case you missed it, here’s a replay of the panel discussion.

originally posted on blog.planetargon.com.

How To Find Top Ruby on Rails Engineers In This Market

Robby Russell 🐘🚂 — Thu, 10 Nov 2022 21:15:51 +0000

Planet Argon is piloting a new service to help match Ruby on Rails engineers in the community with organizations that are struggling with their recruitment efforts.

But first, some background.

In 2005, we became one of the first companies to hire several Ruby on Rails developers. It's true. For a brief period, we were one of the largest employers of Rubyists, and these were some incredibly skilled individuals.

Several early-on employees went on to start and work at exciting startups. One of our first Office Managers took on the first non-technical role at a startup called GitHub. Other alums went onto places like GitHub, EngineYard, Kongregate, Amazon Web Services, and Stripe to name a few.

As a software consultancy, we've been able to recruit a lot of talented people across various skill levels. We've also inherited and worked on projects previously coded by hundreds of developers.

I also speak with a large number of organizations who are inquiring about our Team/Staff Augmentation services, which is essentially a "can we rent a few Planet Argon engineers for the next 3-6 months" conversation. Big-picture, these organizations would prefer to hire full-time employees, but for one reason or another, their recruitment efforts have been expensive, slow, and ineffective.

While our augmentation service is a healthy alternative, it feels more like a backup plan than a long-term solution.

When we partner up with them, we know, deep down, those organizations will replace us with their own hire… should they ever find the right person. Oftentimes, those organizations press ahead with their under-resourced team and cross their fingers that the right candidate will stumble across their job opening. 🤞

We send an email a month or three later asking, "Heya! Did you ever end up filling that role?" It's not uncommon to hear that they haven't filled it.

If that role was still available, periodically, I've shared those job ads with someone I know in the Ruby on Rails community who might be a good match. As a result, several developers have landed jobs and been happy and successful in their new roles. This made me curious to discover if there was an opportunity to do more with recruiting services.

Before RailsConf 2022, the idea of recruiting services came up again while our leadership team brainstormed new services Planet Argon could offer.

The previous year, we replaced several staff members who moved on to incredible opportunities that presented themselves during one of the busiest hiring sprees in the tech industry.

Jokingly, we said, "We've spent so much time recruiting Rails devs; maybe someone would pay us to do this for them, too?!" That’s when the lightbulb flipped on.

We know a lot of Ruby on Rails engineers. A lot of Ruby on Rails engineers know us.

We've been active contributors to the community since 2005.
We produce one of the top 10 podcasts in the community.
Every few years, we conduct the Rails community survey.
We created one of the most popular open-source projects (ohmyzsh) in the software industry.
We've hosted meetups, taken 60 Rubyists on hikes, even train trips across the United States.

Through all of these projects and experiences, we've established many relationships with people across the community.
During RailsConf 2022, I found myself reconnecting with people for the first time in a few years. Global pandemics can really shake things. Some engineers said they had found themselves in tricky situations.

For example, I spoke with a few people who had moved into management a few years ago, and it turns out they didn't love it. I asked if they considered stepping out of management and returning to an individual contributor role. Some of them said it was possibly an option, but most said they couldn't step down from their current team without feeling weird about it.

They'd need to find a new job elsewhere. But they weren't ready to cruise the job board sites, blast their resume everywhere, and wait for a callback.

Other engineers shared that they had been working at companies that broke their technology platform down into several different stacks, and they found themselves saying, "I honestly miss spending more of my day working in Ruby."

After the conference, I shared these stories with our leadership team. It really felt like we could help some of our Rubyist colleagues navigate these challenges.

We decided to take what we've learned from hiring Ruby on Rails engineers over the years and play matchmaker. We began vetting dozens of Rubyists who are (mostly) employed but curious should the right opportunity pop up.

As of this last month, we can now offer another option rather than saying "best of luck" to organizations contacting us for Team/Staff Augmentation who want to hire someone.

Our goal is twofold: to match skilled Ruby on Rails engineers with organizations where they can make an impact, stay engaged, and grow in their role; and to help organizations that are struggling to vet, hire, and retain experienced Ruby on Rails engineers.

Looking to Hire Ruby on Rails Developers? Learn more

Are you a Rails Developer seeking a new role? Learn more

Oh My Zsh: 2020 Year in Review

Robby Russell 🐘🚂 — Wed, 03 Feb 2021 02:12:38 +0000

Oh My Zsh: 2020 Year in Review

What. A. Year.

First off, we'd like to take a moment to acknowledge those who have been impacted by COVID-19. While there are a number of positives for Oh My Zsh in 2020, we can only assume that there are many within our community who have suffered greatly.

We may not know each other, individually, but know that we care about you. 🤗

// Detect dark theme var iframe = document.getElementById('tweet-1248302655195275270-674'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1248302655195275270&theme=dark" }

So...2020, let's dig into it.

Contribution Stats for 2020

Our year started off with the friendly commit to change the copyright year of the project by Angel_Kitty and the final commit of 2020 was a fix by our delightful core maintainer, Marc, to our new CLI update tool.

Overall, we had 457 commits to the main branch of Oh My Zsh, which included 13 new plugins and 2 new themes.

What were a few of those new plugins? Great question!

We landed new plug-ins for Bazel, sublime-merge, Microsoft .NET CLI, git-lfs, shell-proxy, a password generator, HTTPie, and Lando for Docker...to name a few.

To make this happen, we had many return contributors...but we also had 210 people have code accepted to Oh My Zsh for the first time!

For context, we are approaching 1,800 different people who have source code contributions in the Oh My Zsh that you've all come to love and use. 💘

Community Building in 2020

Outside of code contributions, we also want to reflect on a few other ways that the community expanded.

While this isn't a popularity contest, seeing that we passed 120,000 ⭐️ stars and 20,000 forks on GitHub in 2020 feels like such a great honor.

// Detect dark theme var iframe = document.getElementById('tweet-1263896626411696128-134'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1263896626411696128&theme=dark" }

¡Hola Discord!

In December 2019, Larson Carter (a core contributor and community organizer) helped us launch our very own Discord server. In June, the server got verified. We recently passed 4,000 members!

The Oh My Zsh Discord appears to be growing at around ~680 members each month. In order to nurture that community, a number of people have stepped up to help volunteer time to help people with their installation woes, configuration questions, and provide moderation.

In retrospect, I feel silly for asking Larson, "will anyone even use it?"

So many of you have all loudly answered that. 😜

Curious? Join our Oh My Zsh Discord today!

Partnered with MLH Fellowship

The MLH Fellowship is a 12-week internship for aspiring software engineers. MLH reached out to us to ask if we would provide mentorship and guidance to a few developers while they made contributions to Oh My Zsh.

We signed up for the program and ended up accepting a few updates to the project along with an official MLH theme!

😊 Big thanks to Larson for helping represent Oh My Zsh on that engagement.

Event: Q&A With Maintainers

We hosted a live Q&A session on September 18, 2020, and conducted that over Discord.

// Detect dark theme var iframe = document.getElementById('tweet-1307034733738635264-134'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1307034733738635264&theme=dark" }

It was a lot of fun! We definitely want to schedule more of those in the future.

Fabulous Community Content

We attribute much of our success over the years to word-of-mouth.
Nearly every person we meet in the community can point back to a friend, coworker, classmate, a speaker at a tech conference, or an author of a tutorial they read/watched online as having been where they first about Oh My Zsh.

🤔 Do you recall where you first heard of Oh My Zsh? Could you share your story in the comments?

Reflecting back on 2020, we wanted to highlight a few blog posts and videos that caught our attention. In no particular order.

Blog Posts

Speeding Up My Shell (Oh My Zsh) by Matt Clemente
The Ultimate Guide to Your Terminal Makeover by Shinichi Okada
Setting up the iMac - zsh, Oh My Zsh & Dracula by Sahil Parikh
...but I want a pretty PROMPT! by Inee Ader
Boost Your Productivity By Using The Terminal (iTerm & ZSH) by Michael Hoffman
WSL2: Making Windows 10 the perfect dev machine! by Christian Dennig
How to Set Up Your MacBook for Web Development in 202 by Mohammad Alhasan

📝 Did you write a blog post about Oh My Zsh? Please link to it in the comments!

Video Tutorials

...and Brodie Robertson has a few things to say about why you shouldn't use Oh My Zsh. We encourage you to watch it!

You Really Don't Need Oh My Zsh And Here's Why (Rant)

📺 do you have a good video from 2020? Please include a link in the comments!

🤓😍🙃 Delightful Tweets

Here are a handful of happy tweets that we've seen made about Oh My Zsh in 2020.

// Detect dark theme var iframe = document.getElementById('tweet-1257430689051541505-430'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1257430689051541505&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1263394368121040897-557'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1263394368121040897&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1212897940986970112-85'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1212897940986970112&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1253346224880734209-328'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1253346224880734209&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1297581716685627393-930'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1297581716685627393&theme=dark" }

Thanks for keeping us smiling!

GitHub README Project

Marc and I (Robby) were invited to participate in The ReadME Project, which gave us an opportunity to share our open source journey.

It also meant that we each had a good excuse to get dressed up--in the middle of a global pandemic--and meet professional photographers for a social-distance-friendly photoshoot. 📸 🕺🏻

Here are links to each of our stories.

Marc's ReadME Project

Inspired to not only consume, but contribute

// Detect dark theme var iframe = document.getElementById('tweet-1316471347149787136-204'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1316471347149787136&theme=dark" }

Robby's ReadME Project

Finding strength and purpose in collaboration

// Detect dark theme var iframe = document.getElementById('tweet-1314241004472598528-665'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1314241004472598528&theme=dark" }

Stickers, T-shirts, and buttons

We shipped a lot of t-shirts, stickers, coasters, and buttons in 2020. We appreciate the support and really enjoy seeing photos of them out in the world.

// Detect dark theme var iframe = document.getElementById('tweet-1286744700360118272-47'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1286744700360118272&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1326237667286155264-520'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1326237667286155264&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1302034971037634560-325'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1302034971037634560&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1298284226379423744-829'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1298284226379423744&theme=dark" }

Looking for new gear for 2021? do take a look around our online shop.

Keep Your WFH photos coming

Your WFH photos have been lovely. We appreciate them. You can see a bunch in the replies on this tweet.

// Detect dark theme var iframe = document.getElementById('tweet-1242898030207983618-837'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1242898030207983618&theme=dark" }

Hello, GitHub homepage?

...and who doesn't like seeing their logo on the new GitHub homepage?

🕵🏼‍♀️ 🎙 Setting the record straight...

In 2020, I wanted to test out a new feature in Twitter and opted to clear up any confusion about how to pronounce Oh My Zsh.

// Detect dark theme var iframe = document.getElementById('tweet-1316183160246337536-767'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1316183160246337536&theme=dark" }

How does this resonate with you?

Going into 2021?

We looking forward to sharing more about our plans as we head into 2021. Do keep an eye out on Github, Twitter, and on Dev.to. 🙃

Thank you, you, and you, and you over there, and yeah, you, the one still reading this, and let's not forget about you...yeah, you, the who just ate a 🍪. Thank you, too!

Love,
The Oh My Zsh team

Rails 6.1 is Coming Soon! How to Prepare Your App Now

Robby Russell 🐘🚂 — Mon, 07 Dec 2020 20:47:29 +0000

~~The next version of Ruby on Rails is currently being tested by the community and we anticipate a stable release in the next week.~~

Rails 6.1 is here! There are a number of memory optimizations, which should improve performance (aka speed!) of your Rails apps.

There are a number of new features, too. While there have been third-party libraries available for managing multiple databases, horizontal sharing, and switching connections on a per-database basis, it will be nice to now have this available for all applications.

Another nice feature coming to Rails will allow developers to enable a feature that will disable all eager loading of database associations. This will help us shut down those pesky N+1 queries.

I know that our team is thrilled to see that we'll be able to put an associated destroy call into background jobs.

Is your Rails app ready to update to 6.1?

Are you running on Rails 6.0.x? Yes, your application is ready for an upgrade.

If not, what version are you running?

Rails Version	Your Status	Latest Release
6.1.x-rc	🎉 You're on top of things!	Nov 2020
6.0.x	✅ Ready to upgrade	Oct 2020
5.2.x	⚠️ Almost Ready	Sept 2020
5.1.x	⚠️ Upgrade to 5.2.x ASAP!	March 2019
5.0.x	🚨🙀 OVERDUE for upgrade	March 2019
4.2.x	🚨😱💀 Bad situation	May 2020
4.1.x	🚨😱💀 Bad situation	July 2016
4.0.x	🚨😱💀 Bad situation	Jan 2015
3.2.x	🚨😱💀 Bad situation	Sept 2016

Why is everything prior to 5.1.x looking bad for you? Your application is no longer receiving security patches nor bug fixes from the Rails Core Team. (See the official Rails Security Policy)

We recommend that Ruby on Rails be upgraded one major/minor version at a time. For example, if you are running on 5.1 now, you need to upgrade to 5.2 next.

In an ideal world, your goal should be to get your application running on 6.0 by the end of 2021.

🤓 Read When Should You Upgrade Your Rails Application? to learn more about our rationale.

Wait, our developers think we should rewrite our application – do we still need to upgrade?

To be honest, we are not fans of big rewrites.

Our purpose at Planet Argon is to FIGHT THE BIG REWRITE. We even produce a podcast called Maintainable where we speak with experts in the industry on how to overcome the problems associated with technical debt and legacy code. We live and breathe this.

We understand the temptation to exclaim, "TIME FOR A REDO!" But we know, all-to-well, that rewrites are notoriously unsuccessful. If you need to maintain your existing app while building a new app, in parallel, you have a big task ahead of you. Furthermore, if you haven't established a cohesive process to keep that technology up-to-date, what makes you think you'll have better success with a different technology stack?

🤓 Read 3 Reasons Why You Shouldn’t Outsource Your Rails Upgrades to learn more.

Will our Rails upgrade hurt us?

Large companies like Shopify, Basecamp, and Github have been investing a lot of their Engineering time to contribute back to the core Rails framework. As a community, we are aiming to make sure that major/minor upgrades have limited breaking changes.

We're hoping that upgrades will continue to get easier than they were several years ago. Might that be one of the reasons why you're stuck where you're at? Did you navigate an expensive upgrade before?

Interested in a fresh set of eyes and a free action plan?

Get in touch so that we can help you explore a Rails 6 Upgrade.

This was originally posted on blog.planetargon.com

When Should You Upgrade Your Rails Application?

Robby Russell 🐘🚂 — Wed, 25 Nov 2020 00:43:12 +0000

A. Upgrade to the latest major/minor version each year, if you can.

As a general rule of thumb, Ruby on Rails has released a new version on nearly an annual basis. The core team has typically aligned these with the annual RailsConf so that there are new features and updates to demo in keynote talks.

This has consistently been the case for nearly each of the last 15 years...give or take a few.

I also understand that it can be a challenge for teams to plan and prioritize upgrades. I'll touch on that more later.

First, let's get down to brass tacks. We need to assess your situation.

What is the newest version of Rails?

The community is currently kicking the tires on Rails 6.1 release candidates.

Note: Due to COVID-19, the release cycle appears to have slowed down a touch.

What version is your app currently running on?

If your Rails application is not running on either 5.2.x or 6.0.x (or newer)...your application is at risk.

Rails Version	Status	Latest Patch
6.1.x	💚 Supported	Nov 2020
6.0.x	💚 Supported	Oct 2020
5.2.x	💚 Supported	Sept 2020
5.1.x	🚨 At Risk	March 2019
5.0.x	🚨 At Risk	March 2019
4.2.x	🚨 At Risk	May 2020
4.1.x	🚨 At Risk	July 2016
4.0.x	🚨 At Risk	Jan 2015
3.2.x	🚨 At Risk	Sept 2016

...you get the idea.

The older the version, the more at risk your application is.

Do you have multiple Ruby on Rails applications and want to have someone gather this information? We have a free google sheet template for you to document these details.

I encourage you to steal this template!

At risk of what, exactly?

Great question!

Like any software running on your laptop, smartphones... the software that we write to power our web application also has security vulnerabilities that are found. When these issues are found (usually by the good/friendly hackers who are kind enough to share what they discover), the Ruby on Rails Core Team will apply security patches and release a small update.

For example, if you are running on 5.2.9, they might release 5.2.10 to patch the security hole.
In theory, a developer on your team should be able to quickly bump up to the new version in the Gemfile with one line of code change, a run through your automated tests, and a deploy. ..and that known security hole is no longer a possible backdoor for the unfriendly hackers out there.

Note: this can be automated!

What about bug fixes?

The other benefit to staying up-to-date is that there are 🐛 bugs found within the underlying Ruby on Rails framework from time-to-time.

If they are critical enough bugs, the Rails team release will release a small patch for those.

Learn more about the official Ruby on Rails Maintenance Policy

What version are most Rails applications running on?

Every two years, Planet Argon surveys the Ruby on Rails developer community and shares our findings. This year, we have 2,049 members of the community share a number of details about their applications.

Based on the survey, ~62% of respondents said they were running on either 5.2.x or 6.x. (source)

Are you part of the other 38% that are running on an unsupported version?

How often should you update your version of Rails?

In an ideal world, your team would be aiming to stay up-to-date with Rails as new versions are released. But, we live in a world where each team has a wide range of priorities to juggle. Without a cohesive process to follow, teams will put upgrades into a someday/maybe list.

We understand why this happens.

Upgrades feel like a lot of work for little immediate payoff. However, this has a compound effect in that it results in making the upgrade path far more time consuming and risky to explore. As developers, we are risk-averse and product owners are worried about upgrades being drastically underestimated.

The reality is that some of the major version upgrades are far from trivial. Third-party dependencies tend to be a lot of the challenges that those upgrades need to navigate.

When everyone is afraid of breaking things in a working application – the decision gets delayed for another time, place, or even worse...left for future people added to your team to have to deal with.

As new engineers join your team and learn that keeping the applications up-to-date isn't part of your team's workflow, they will start to assume that it is not considered important within your company culture.

Note: Delayed upgrades can definitely impact your employee retention, too. When they aren't able to leverage newer features, libraries, and/or tools in Ruby on Rails, they may start to daydream about finding a new team where the grass may (or may not) be greener.

Regardless of how you spin it...this is problem. A problem that your team can (and needs to) solve!

Can't you just hire a professional to upgrade for you?

Yes! (...but I have written 3 Reasons Why You Shouldn't Outsource Your Rails Upgrades to explain my concerns about that as a long-term "solution").

Several companies have hired our team over the years to handle the underlying upgrade. We enjoy rolling up our sleeves and getting our hands dirty.

However, we believe that a better approach is to provide guidance to teams on handling their own upgrade.

Interested in helping get your team started? Take a look over our Rails Upgrade Kickoff service and fill out the form if you'd like to talk shop about how we can help your team manage their Rails upgrade process.

This was originally posted on blog.planetargon.com

How To Be A Good Guest (in another team's codebase)

Robby Russell 🐘🚂 — Tue, 24 Nov 2020 22:30:35 +0000

For nearly twenty years, I have regularly found myself (temporarily) in another team's software codebase. From being hired as a contractor, to providing emergency technical support, to helping companies understand the health of their application via a code audit...I have learned a few things (via trial-and-error) about what to--and more importantly--what not to do while being a guest.

This topic is near-and-dear to me. Recently, I was a guest on the Developer Tea podcast and we got deep into this topic. We got deep into it needed to split it up into two episodes!

🎙 Listen to part 1 and part 2.

Are you a freelancer or contractor about to temporarily participate in another Engineering team's project? Here are a few considerations for those first hours/days of being a guest.

(FWIW -- you can apply this to being a new full-time team member, too!)

Document Your Goals 📝

As a contractor, the company has likely brought you in to assist with something specific. What was the problem that they were encountering and/or feared they would encounter in the future?

Are you there because you have specific expertise that they have limited knowledge of, in-house?

Do they need help upgrading their Ruby on Rails application and you've helped dozens of teams do that? Has their application become unstable? Is their test suite taking far too long to run and they need you to help them speed that up?

Are you there to temporarily offset needing to hire a full-time engineer? (Aka staff augmentation)

Let's dig deeper into this one. Why do they need to bring in additional help right now? Did they recently lose someone? Has their team's Sprint velocity drastically slowed down? Are they needing to scale up for the next few months?

Whatever the case...you should understand what their underlying rationale is. You need to capture their WHY behind the decision.

If there is one thing that I've learned over the years...it is that when there are a lot of moving parts, we sometimes need to remind our clients of their own decisions.

As much as you would like to believe that everyone on the team you're temporarily joining is on the same page (and/or even support the idea)...it is wiser to assume they are not.

That's okay, though.

(Let's find comfort knowing that humans have this funny way of moving forward, together, despite an unpredictable level of chaos.)

This is why it is important for you to clarify what your goal is here. You will need to own the success of it. This is what they are paying you to do.

🚫 Anti-pattern: Being passive. Showing up on Day 1 and asking, "what do you want me to focus on? When will someone assign me tickets to work on?"

When you show up on Day 1, you'll want to reiterate why they hired you. Frame your questions around that.

"My goal is to help your team address X & Y over the next few weeks. Who would be the best person(s) to help me get up-to-speed on the current situation?"

Once you identify who your internal domain expert is, you'll want to reach out to them to schedule manageable blocks of time to a) reiterate your goals b) listen to them share their perspectives/concerns (capture these, too!) c) learn more about their capacity constraints, and d) ask them if there are other people on the current team who might also be helpful to help you reach your goal(s).

Make it a SMART Goal ⚽️

Take a moment to think 3-4 weeks into the engagement. You're having a one-on-one chat a team lead and they ask, "how is that project of yours coming along?" ...how will you respond?

Ideally, you should be able to respond with, "ON TRACK" or "OFF TRACK."

Software Engineers have been known to be risk-averse (for good reason!) but when we're hired guests, we should aim for removing ambiguity and/or diving too deep, too early, in a discussion. While we have to balance a lot of nuance in our jobs, let's keep be mindful to not overwhelm the person we're speaking to unless they are truly curious to get into the weeds with you.

We can do this by trying to clarify them via SMART goals.

💃🏻 ProTip: "We're on track!" > "I'm on track!"
(...remember, you are part of a team)

...wait, WTF are SMART goals? 🤔

Great question!

🧠 S.M.A.R.T. is a mnemonic acronym to capture our objectives by answering whether they are Specific, Measurable, Achievable, Relevant, and Time-bound.

Here is a helpful guide on writing achievable SMART goals by the fine folks at Atlassian.

Share your SMART goal 🥅

Rather than assume everyone shares the same understanding of the goal, it is important to share what you've captured with your new team members.

There are times when your new teammates might not believe a goal is achievable...especially if they've tried (and failed) to get there in the past. This is your chance to solicit input.

If it later comes up that they didn't share something useful when given a chance, then it'll be something you can recalibrate with them.

Avoid assuming that this is malicious. It's plausible that it wasn't on their mind at the time and they remembered it later.

Getting Into Their Code 👩🏼‍💻👨🏻‍💻

Let's assume that they are going to invite you to their code repository(s) and you'll be aiming to get their code up-and-running in a local development environment.

What kinds of changes are happening in their code?

One of the first things that I do after cloning a repository is to start browsing the output from git log. I'm looking to learn more about their team.

📝 Do they follow commit message conventions?
📖 Do the commit messages help tell a story?
🚢 Are they shipping new features?
🐛 Are they trying to squash a lot of bugs?
🎳 Who has been actively pushing code changes into the main branch(es)? (The bowling ball felt fun)

Using other fancy git commands, you can find files/areas of high churn, explore the maintenance (or lack thereof) of the test suite, how often documentation is updated, etc.

Will you be interacting with these people on the team in the coming days? Take note of a few observations.

"Wow, it seems like you've worked on a big feature recently. What was involved with that?"

"It looks like you've been helpful in squashing a lot of bugs recently. Is that a big part of your role here and/or do you rotate that responsibility across the team?"

How do you get their application running (locally)?

If you're lucky, the team will have up-to-date docs that'll help you quickly get their application running in your local dev environment. You might consider timing how long this process takes.

It can be helpful to report this back to a team lead to see if they are surprised by the information. If the team is encountering scaling problems, this can be one of those bottlenecks that slow down other new hires/contractors, too.

If anything, they can use this data point to properly map out a realistic onboarding timeline. Similar to capturing how long it takes for your test suite to run, how long deployments take, uptime... this is another useful metric to measure.

Recruit a spin-up buddy, if possible

When my team at Planet Argon are hired by a client, we try to have two of our engineers pair up on the process of getting the application running, in parallel. This way we can try to spot gaps in the documentation, debug issues quicker, and avoid having a scenario where one person who gets out ahead of the other.

If you are a solo guest working within a new-to-you team -- it might be a good idea to see if you can grab someone on the team to pair with you on setting up their application.

🤹🏻‍♀️ ProTip: If you want to get a feel for how complicated this process might be...ask one of their team members how anxious they would feel if their laptop died right now. 🙀 If they had a brand new laptop with a fresh operating system installed...how disruptive would that be for them? This is someone who has experience with their application and the underlying dependencies. If it is that scary to them...think about all the unknowns to someone brand new?

If you need to go rogue...

Should you not need to recruit someone to help you get up-and-running, then by all means, go on this solo mission but I encourage you to be extremely careful about this.

I've witnessed this a number of times over the years (by myself and members of my team). We'll begin to dig into our client's Ruby on Rails application, getting things up and running, and we forget to do the following.

Share our progress!

If the spin-up time takes a while, we would benefit ourselves (and our new teammates) by reporting on our smaller milestones.

A quick list of what's been accomplished and what remains should be simple enough to share. It'll give the team a chance to highlight if anything is missing from your list.

Update the documentation when we find any gaps and/or inconsistencies.

Our fresh perspective of reading and using the existing docs is a perfect time for us to create a new branch and commit updates so that we have a fresh pull-request to send when we're wrapped up.

🚫 Anti-pattern: Using language like "fixed" in documentation updates. Language like "updated" should suffice. Fixed has a different connotation. Assume it used to work fine at one point.

Acknowledge the great docs that exist!

While you are working your way through the documentation, if you are finding it to be well-organized and helpful, consider taking a moment to see who on the team was responsible for those updates. Look at the revision history. Reach out to the people who helped make your life easier today.

"Hi Kathryn! As I'm a frequent guest in other team's codebases...I see a wide spectrum of documentation in terms of organization and usefulness. I wanted to let you know that these are some of the best setup docs that I've seen. Thanks!"

"Oscar - I hit a problem while trying to install all the RubyGems because nokogiri was failing to build. I was about to start debugging it but noticed you had a helpful note in the docs about how to fix the dependency problem in Mac OS Catalina. You saved my afternoon!"

(Obviously, only do this if you found the documentation helpful; we don't want to placate anyone! 🙃)

The effort that we put into maintaining documentation tends to feel under-appreciated. Let's do our part to highlight when docs make our life easier!

🚫 Anti-pattern: Spending a ton of time trying to figure out how to fix a problem during the up-and-running phase without reaching out to other team members to ask if anyone had encountered it before.

If you spend several hours trying to Google for an answer on StackOverflow -- it is possible that someone on the team has but hadn't captured that in the docs before. This will help convey that you're humble enough to ask for assistance, which the team you're temporarily joining finds value in. We hope.

Be Vocal As You Dig into Your Project Work

Now that we're in a position to get crackin' on our work, it is tempting to put our headphones on and allow ourselves to get lost in the task-at-hand. While getting to a state of FLOW is important for productivity...we run the risk of being far too quiet for too long.

If the team has a good cadence on regular check-ins (do they have stand-ups? Slack channel updates?) then this might not be too much of a concern. Should they have a loose communication culture then we should be proactive over-communicators...especially in those first days as a guest.

What did you accomplish yesterday? What are you aiming to accomplish today? Do you have have any blockers?

Find out who might be able to help you remove a blocker. Do that earlier in the day so that you have a better chance of getting time scheduled with someone who can help.

🚫 Anti-pattern: Struggling to make meaningful progress in the first few days. We don't want our new team members to wonder what you've been up to. (While we can talk about how important it is for them to trust you...we need to earn some of that, too). Silence invites people to make assumptions. Influence the narrative!

As consultants, we are often hired for our expertise. We should avoid interpreting that as them expecting us to have all the answers. Let's just strive for having good questions.

Ask for Context Not Rationale

"Heya, quick question about this feature I'm starting to work on. Why did y'all design/build this it like this?"

🤦🏻‍♂️ Don't be that person.

Trust me, I've learned the hard way.

This is an ineffective way to win over your temporary teammates. Firstly, we shouldn't assume that the person(s) we're talking with had a hand in the design/building of something. They might have inherited it. They might agree with you if something was poorly designed... but I encourage you to be open, empathetic, and curious.

"Heya, I have a quick-wish question about this feature I'm starting to work on. Would you be a good person to help me get the scoop and/or backstory?"

Invite them to fill-in history. Listen. Assume that those who previously worked on it did the best that they could given the time/budget/resources available. Start from an assumption that they might agree with you.

You're there to help improve it not to be the person who can only point a flashlight 🔦 at it.

Note: if you find that they don't see a problem with it... you should find a way to have that collaborative conversation to explore that together. YMMV.

Leave the Team Better Than When You Found It

The long-term success of the team you're temporarily joining is not your primary responsibility. That isn't to say that you will not have an impact on it. With any team, it will change to a varying degree as people interact with it.

As consultants/contractors/freelancers...we have a unique and value perspective when we interact with different teams. If we're curious enough, we can spot patterns in the teams we participate in and share our observations.

If we care enough, we can highlight the things that you see are great about this team. The members of the team might be have been insulated by their team's bubble for a while. They may forget what it was like before.

On the flip side, if things seem toxic, let's find a meaningful way to convey that to the relevant people. We might not think it is our responsibility...oftentimes, it is not...but, again, the bubble might need to be stirred up. (I'm not advocating that you try to burn it all down...but you can share what you see is working or not compared to other teams you've been part of). Be mindful to not pre-diagnose the situation.

Raise underlying issues (versus pointing out the culprit).

🚫 Anti-pattern: Offering solutions versus experiments.
Compare "At another client, they used ABC. You should use ABC here..." versus "they experimented with ABC and had good success. Have you considered experimenting with ABC here before?"

Again, we're here to ask good questions.

Closing Thoughts

I know that I am scratching the surface at this topic. If you found yourself skimming this, let me summarize this into a few closing thoughts.

As a guest (in another team's codebase), please remember that you are a temporary member of that team now. Despite your technical skills, your goal is to be a productive and helpful contributor.

Be goal-oriented.

Avoid playing the hero.

Give credit.

Confirm assumptions.

Share kudos.

Stay organized.

Be thoughtful.

Propose experiments.

Be curious.

Be a good guest.

Top 10 Technical Podcasts (as Chosen by the Rails Community)

Robby Russell 🐘🚂 — Thu, 24 Sep 2020 22:15:08 +0000

Are you on the search for new podcasts to help you sharpen your coding skills? Well, I have good news!

In the spring of 2020, we surveyed over 2,000 Ruby on Rails developers from 92 different countries. One of the questions that we asked the community about was, "What are some technical podcasts that you enjoy listening to?"

Here are the top ten chosen by the community, as well as recommended episodes for you to check out!

#10 - Syntax

Syntax digs into a wide array of software development related topics on their podcast. Much of their conversations revolve around explaining the fundamentals across different technical stacks and platforms. Currently hosted by Wes Bos and Scott Tolinski.

#9 Maintainable

The Maintainable Software Podcast might sound familiar because a) Planet Argon produces it and b) I (Robby) am the host! On Maintainable, we speak with seasoned practitioners who have helped organizations overcome the challenges that are often associated with technical debt and legacy code. A lot of the conversations focus on team processes, communication challenges, growing as technical leaders, and diving into new-to-you projects.

To make the top ten list was a pleasant surprise!

🎧 Recommended episode: Robby Russell: Turning the Mic Around with Kayla Reopelle

#8. Full Stack Radio

Full Stack Radio is hosted by Adam Wathan. On the show, Adam brings on guests to share details about new tools that developers can use to build their applications with. The podcast is going into its sixth year with almost 150 episodes.

🎧 Recommended episode: Jason Fried - Running the Tailwind Business on Basecamp

#7. The Changelog

The Changelog is a series of discussions with innovators in the software development industry. Currently hosted by Adam Stacoviak and Jerod Santo, this podcast (amazingly) originated way back in 2009, way before podcasts were anywhere near as prominent as they are today. They chat with guests ranging from startup creators to veterans at Fortune 500 companies about technical topics, dev culture, workplace challenges, and more.

🎧 Recommended episode: Oh My Zsh with Robby Russell (hey, that's me!)

#6. The Ruby Blend

The Ruby Blend was a short-lived but widely appreciated podcast. It was a Ruby-focused podcast with panel discussions and guest interviews. They published 21 episodes before deciding to recently discontinue the project.

Rest in peace.

🎧 Recommended episode: Open sourcing a Ruby gem with Brittany Martin

#5. Rails with Jason

The Rails with Jason Podcast is an interview style format hosted by Jason Swett. Topics are usually Ruby on Rails-specific and Jason is known for his YOLO interviewing approach.

#4. Ruby on Rails Podcast

The Ruby on Rails Podcast is the longest running in the community. It's currently hosted by Brittany Martin. On each episode, Brittany digs into topics related to the Ruby on Rails framework and community with guests.

🎧 Recommended episode: 2020 Ruby on Rails Community Survey with Robby Russell (we discuss the results of this survey!)

#3. Ruby Rogues

Ruby Rogues probably has the largest number of episodes of any podcast. Topics covered on this podcast to vary between new features and functionality in Ruby/Rails and becoming better developers through interviews.

🎧 Recommended episode: Hiring Diversely with Sarah Mei

#2. Remote Ruby

Remote Ruby is hosted by Chris Oliver, Jason Charnes, and Andrew Mason. On this podcast, they dig into a lot of newer technical and community-related topics. There are interviews from time-to-time as well.

🎧 Recommended episode: Rails Hosting Survey results & Junk Drawers for Code

#1. 🚲 The Bike Shed 🎉

...and the front-runner is The Bike Shed! Chris Toomey and Steph Viccari host this podcast. Each week, they discuss the challenges of being a software developer, refining your craft, new technologies, lessons they've learned, and what is new in our community.

🎧 Recommended episode: I'm Not Allowed to Play With Other Shells

In Closing

First of all, a big thanks to all 2,049 of you those who shared their experiences in our community survey.

..and a huge, huge thanks to all the people who are spending time (and money) on producing valuable content that is freely available to our community.

this was originally published on the Planet Argon blog

Take the 2020 Ruby on Rails developer community survey

Robby Russell 🐘🚂 — Wed, 27 May 2020 15:18:18 +0000

Back in 2009, we invited our community to participate in the first survey about the state of deploying Ruby on Rails applications. Over the years, we've evolved this to include questions about tools, frameworks, and workflows in order to see how the environment is changing.

If you're a Ruby on Rails developer, please consider taking the survey and inviting your peers to do so, too.

You can take the survey at: https://planetargon.survey.fm/rails-survey-2020

To view more details and past results, visit https://rails-hosting.com/

🎙 check

Robby Russell 🐘🚂 — Fri, 22 Nov 2019 14:52:10 +0000

tap

is this thing on?

How do I prepare for a new dev joining my engineering team?

Robby Russell 🐘🚂 — Thu, 25 Jul 2019 16:48:53 +0000

Do you have a new developer joining your team soon? Are you planning to have them start working on one of your older apps/projects? How might you help them feel good about being able to a) get up-and-running and b) quickly contribute something to your project?

Here's one idea that you might consider doing before their first day.

🎧 Put your headphones on

👨🏻‍🎤 Listen to some Bowie

🔥 rm -rf /path/to/your/local/app

⬇️ Freshly clone your app

👩🏼‍💻 Follow your setup docs, step-by-step

🧟‍♂️ Get frustrated that they aren't up-to-date

🏃🏻‍♂️ Get app running, again

🕸 (while tidying your docs)

⤴️ Push your documentation changes up

🥾 Go outside for a nice hike/walk

🙃 Smile at the world

An invitation to listen to Maintainable Software Podcast

Robby Russell 🐘🚂 — Tue, 09 Jul 2019 15:50:19 +0000

Around a year ago, I was chatting with a good friend about an idea I had for a podcast. Over the last several years, I've learned that I've become really focused on improving existing software over building something new.

I'm not a maker. That is somewhat true, I prefer to spend more of my time improving something than making something from scratch.

The concept for the Maintainable podcast was to challenge myself with finding a diverse collection of experienced professionals from our industry--and to hear their stories about how they played a part in improving existing software.

While we, as an industry, are creating a ton of new things -- we also need to be focused on making the existing things better today than we found them yesterday. We don't need to label this as "legacy code"--it's just code.

As of today, my team has helped me publish 13 episodes (with several more on the way). I've had an opportunity to speak with people like:

Charity Majors of Honeycomb who thinks we need to spend more time "testing" in production.
Eileen M. Uchitelle of GitHub on how to tackle a large Ruby on Rails upgrade.
Matt Weagle, Engineering Manager at Lyft on coaching developers on how to better discuss technical debt
Coraline Ada Ehmke, Principal Engineer at Stitch Fix on the role of empathy in the workplace
Pim Elshoff a software developer at Procurious about communication tactics within technical teams
...and several other people that I have learned a lot from.

Have you heard any of the episodes yet? (and find value in it?) If so, it would mean the world to me if you could take a moment to add a rating on Apple Podcasts. 😊

if you haven't, I invite you to listen to an episode or two at Maintainable.fm.

Hello, Maintainable Software Podcast.

Robby Russell 🐘🚂 — Thu, 25 Apr 2019 13:33:15 +0000

First off, do we really need - another - podcast about software development?

For a number of years, I've been kicking around the idea of starting a podcast to talk with people about software but really felt like it's a saturated market. I kept telling myself that I wouldn't pursue anything that was focused on a specific technology choice (i.e., Robby on Rails almost graduated to be a podcast several times over the last 15 years?). I also have very little interest in talking about "what's shiny/new/hot in our industry", either.

There are plenty of podcasts for that.

Last year, I found myself thinking a lot more about what starts to happen to software after it's been through many different iterations, phases, engineering teams, and pivots. I'm really not an advocate of the BIG REWRITE and think that developers far too often find themselves starting to dread working on their code bases.

As a result, momentum slows down. Team's get discouraged. People quit. New people get hired. More people complain about the state of the code base. More time passes…and the problems have become far more problematic than they ever needed to.

Does this sound remotely familiar?

I'll be honest. You're not alone.

A lot of us have felt this. In many scenarios, we've felt that the only way out of the problem is to quit and find somewhere with a better code base to work on.
However, there are tons of scenarios where the company has good intentions but their trajectory has compromised their technology decisions…a few too many times. What they really need is an advocate - from within - to help them start making positive steps to their ideal future.

I want to talk about "The Messy Middle" phases of software development. (btw, a great book by Scott Belsky). This is why the team at Planet Argon has helped me launch the Maintainable Software Podcast.

On the podcast, I'll be speaking with seasoned veterans of our industry…who have seen some 💩 over the years and have been able to help organizations push through the problems often associated with technical debt and legacy code.

The first two episodes are now published for your listening pleasure.

On this first episode, I speak with Anna Filina about what technical debt is and how we don't need to ask for permission to adopt better development processes.

On the second episode, I speak with James Smith about ways to measure the reliability and technical debt of an application's code base.

You can learn more at https://maintainable.fm/

FAQs

Q. How often will you be publishing?

A. I'm aiming for weekly releases (for half of the year… maybe a spring + autumn schedule).

Q. Where can I subscribe to Maintainable?

A. Great question! Here are a few places

Q. What if I have some great stories to share?

A. If you think you'd make a good guest for the podcast, do get in touch with me via robby@maintainable.fm to pitch a topic or three.

Q. How can I help promote Maintainable?

A. Another great question, you ask the best ones!

You could share links on social media, follow Maintainable on Twitter, re-tweet links to episodes you find value in, post an honest review on Apple/iTunes, etc.