hexdevs

hexdevs: Hey, there!

Stefanni here.

Before you listen to this amazing
episode, we have something to ask you!

you!

feel like you've been stagnating
in your current position as

a Ruby on Rails developer?

to the next level?

Stuck in a mid-level position?

you been applying to jobs
and getting rejected?

[Stefanni] It can be hard to improve
your skills outside of your work.

What if you knew exactly how to
get your Software Engineering

skills to the next level?

hexdevs.com/workshop and
get on the wait list today!

Enjoy the episode!

Stefanni, Thiago, Ernesto:
Ernesto worker is the founder and

cto@fastruby.io and Ambu labs.

He is the maintainer of database
cleaner bundler leak, and next rail.

He just told us today that fast Ruby
has recently inherited other important

Ruby code quality projects, such as.

Rio stats, metric Fu and Rubik
critic, which is a great jam.

We watched your talk in
a previous watch party.

Uh, the talk is name escaping the tarpit.

Thank you so much for such a great talk.

People got surprised with the jams
that you mentioned so many genes

that can use to improve code quality.

So that's really amazing and yeah.

Welcome Ernesto.

It's so great to have you on the.

Uh, Jaguar and Stephanie, thank
you very much for having me.

And, uh, yeah.

Also for hosting a watch party for
my talk on code quality on skunk.

Uh, it's great to be here.

And by the way, what else has gotten
people surprised by your talk?

Do you have that information?

Yeah, I think I've gotten
some really positive feedback

from a lot of developers.

I presented this talk and the
Philadelphia Ruby meetup, uh,

Ruby confu S RubyConf Australia.

And I got a bunch of comments
from people and mostly positive.

And some comments are from people
who don't believe in code coverage.

So.

Yeah, I definitely stood out because I
believed like code coverage as a metric

has always been something that adds value
and builds trust and an application.

And knowing that 70% of the code is
covered by tests, uh, usually is a good

thing in my book, but there are some
people out there that don't believe that.

And that sometimes, you know, they have
had bad experiences where they have.

An application that had 90% code
coverage, and then they opened the

test suite and they just looked, it
was exercising the code, but it was

not expecting anything from the code.

Yeah, I guess there are outliers out
there of people who have gamed the code

coverage metric, but I don't believe that
takes the value away from that metric.

And.

Escaping the carpet is mainly focusing
on churn, complexity and code coverage.

By combining, combining all these metrics.

The idea is that you can get insights
from your code base and know what

things you can improve next to
reduce tech debt and in your project.

It's interesting that you mentioned
people that don't, don't like this

metric very much code coverage.

We also have to be careful with.

Uh, the test suite, because
it's still code, right.

It's not just some crazy code that
you write just to do some asserts.

So the test suite is also code slate.

It should be good code.

Right?

So this is one of the problems that
I see sometimes where people treat

their tests, not with the same care and
consideration compared to their code.

For sure.

Yeah.

In terms of, you know,
running a test suite that is.

A good test where it is like,
yeah, what is a good test suite?

Sometimes you do have like
really good code coverage.

Let's say 80%, but the test suite fails
one or seven times out of 10 times that it

runs because it has flaky specs in there.

You need to be careful about the
quality of the test suite as well, so

that you can trust that it executes.

He tests the behavior of your code,
but also it doesn't frustrate you when

you're trying to run it and you get
to like rerun and rerun and rerun.

That's definitely something you want
to avoid and, uh, definitely improve

if you find that in your application.

For sure.

And one of the things that is also
important is the performance of the.

Test suite, because like you mentioned,
sometimes you have flaky tests and you

want to run the test suite on CGI or
on your computer, but then it takes

a long time, like 40 minutes now,
or to run and then something fails

and then you have to run it again.

It's kind of in the honey.

Is there any tip you can share to.

Maybe improve the performance, like
testing parallel, things like that.

Yeah.

That's usually what we see in our clients.

Um, it's got fast Ruby that I, oh,
we work with clients that have been

running rails for the past 10 years.

So as time goes by, their test
suite takes longer and longer.

So what they end up doing as.

Parallelizing their test suite to
run it multiple shards or jobs.

And that way they reduce the total
time that it takes to get the

feedback from their test suite.

But, uh, yeah, I don't have a
lot of, uh, advice in that sense.

I think it's important and
there are definitely gems out

there that help you see what.

Scenarios in your test suite
are the least performance.

If anything, if you notice that your
test suite is super slow to find gems

that can tell you like which ones,
which scenarios are the slowest ones.

Sometimes the slowness is because of.

Consuming like a third party API
that you shouldn't funny story.

I once did that and ended up finding a
security hole in an API that I was using.

But, um, yeah, don't do that.

Try to stub and mock all
those third party services.

So they don't have to
slow down your test suite.

It's still.

I'm a developer that is working on
the code base that I simply know it

is a mess, but I have no idea how to
get out of it, how to get started.

Maybe the tests are in that situation
that we are just discussing now.

And the easiest solution
is to find another job.

What would you say is another alternative?

What would you advise me?

Um, oh, that's a good question.

I think the main thing is to think
about why are you in the tarp pit?

Like, why is it so hard
to ship small changes?

Why is it that.

Tweak small things in your application
and seven different things break.

Why is it so hard to find
root causes for bugs?

And that ideally will tell you like,
okay, there are a bunch of things

that are wrong with your code base.

I wouldn't recommend that you take.

Three months to pay off
all the technical debt.

Uh, I don't think that's
a good approach to say.

Um, yeah, I'm going to take three
months to fix all the technical debt

and then everything's going to be fine
because it's a, it's basically a habit

that you need to build in your team and
sometimes you do need, um, All the time

you need management approval to say
every week or every sprint we're going

to dedicate 10, 20% of the sprint to
paying off some of the technical debt.

If management in your company is not open
to something like that to like gradually

pay off, you know, 20 minutes, an hour
of technical debt in every sprint.

I think then, yeah, maybe you do need
to find another job or you need to.

Continue to try to communicate why
it's important to pay off technical

debt because we write Ruby code
and we understand that program.

Your happiness is very important
and Ruby gives us great tools to

write code that makes us happy.

But of course, as the application
evolves and as many hands.

You know, submitting changes and all that.

There's always a possibility that
it will become super complicated

and super hard to maintain.

You know, there are very small
things and I really like, uh, Ben RN

stains, uh, code quality challenge.

Um, he has this initiative where you
can do one thing at a time and it's

just like 20 minutes and you do this
thing for 20 minutes and then, okay.

You pay it off a little bit.

Yeah.

Of the technical debt.

It could be something as small as, okay.

We have a test suite.

We want to see what the
code coverage percentage is.

So we're gonna add, you know, this
snippet of code and at the end of every

CIO, Iran is just going to tell us code
coverage is 50% or 51%, but adding that

change should take you less than 20 miles.

And that gives you an idea of where
you are in terms of code coverage.

Another thing that you
could do after that is to.

Skunk to your project and say, okay, after
you get code coverage for the test suite,

run skunk and tell me which files are the
most complex and have the least coverage.

And of course, these are all like
research activities that you can do to

kind of find your location in a map.

And then once you know your
location, you can actually take.

Decisions to move in the right direction
and slowly pay off technical debt.

I like the approach of doing small
things in that consistent basis,

because if there is, if it is something
that it's not already part of the

culture, you probably don't want
to try to force everyone to do it.

I don't know, every day or
every week, something like that.

I also liked how you suggest.

Just doing something small that
you can do without perhaps even

needing approval from management.

I believe that that's one of
the main reasons is it's not

the priority of the company.

Do you think it's possible to do it even
without having any support from your team?

Yeah, for sure.

I think, you know, it's definitely not
the best path, but if you don't get

approval for management, if they're
like, no, we're, we're going to.

Continue with our approach of,
you know, dedicating two sprints

a year to pay off technical debt.

What you can do is with every change use
ship, or which would every patch that you

ship, you can slowly pay off technical
debt is going to take you a little

longer, but let's say you're fixing a bug.

So you use TDD.

You write the test first to reproduce
the issue, and then you fix it.

And then.

That's a very small way to ship,
not just the patch, but also test

that, you know, make sure that
there's no regression in the future.

Uh, if there is no test suite and
you want to do this, basically just

start with very small tests that just
tests that one method that's failing

and boom, you have like a test suite.

It only covers like 1% of your code
base, but at least 1% is higher than 0%.

So.

That's great.

If you're working on changes that are
like a little bit more involved, what

you can do is gradually change some of
the portions of code that you're using.

Touching.

So, you know, like the it's called the boy
scout rule or where you go in and you do

your thing, but then when you come out,
the, the code is better than when you

started doing the thing you were doing.

So let's say you had to touch,
you had to touch a file that

has a thousand lines and maybe.

While doing your work, you notice
like, oh, well they're clearly

two responsibilities in this file.

So break it down into two files.

And now you have two files of 500 lines,
which is a little more manageable.

Now of course, some managers and some.

Code reviewers are going to go and
say like, why are you doing this?

Like your task was to fix this button
and your can be like, well, yeah,

it was to fix the button, but I also
want it to improve the code base.

And I mean, ideally you won't
get in trouble for it because

ideally you are reducing complexity
and making things simpler.

But if you do get in trouble
for it, yeah, it might be a good

time to find the, a new job.

And my company's hiring, you know, and we
appreciate people who go the extra mile.

So feel free to, yeah, for sure.

So if you're listening in, you're working
at a place that don't do appreciate

good code quality, it can just talk to
your Nestor and get a job at last Ruby.

I really like your approach because
it's easier to lead by example.

So if you're working at
a place that doesn't.

Great engineering culture and
you don't care much about tests.

I had that experience in the
past and it's kind of annoying.

And the only thing I could do was I had
to lead by example, it's kind of tiring

and frustrating, but whenever I worked
on something, I try to add at least

the beat, a little bit of tests and do
some refactoring and things like that

is not always possible of course, but I
think that everybody appreciates when.

That's, you know, even if they don't
do that, even if your peers, they don't

really write tests or they say, oh,
we don't have the time or whatever,

if there is no culture related to
that, but they always appreciated.

So they say, oh, you had some tests here.

That's great.

And they, they even talk about it later.

Oh, did you see, uh, uh,
the task for this code base?

They start learning more about it,
but I think everybody likes it.

Everybody appreciates, uh, tests.

Yeah.

Leading by example is,
uh, is another idea.

Yeah.

I wanted to ask you folks, um, about that.

Like, have you ever tried following
this approach and you found that.

The person reviewing it or your
boss did not appreciate it because

as I said, this takes more time.

So maybe you took four hours instead
of one hour, or maybe took like

two days instead of like two hours.

Uh, but did you ever experience like
pushback when ever, uh, this happened?

In my experience, it was actually hard.

I was still learning the
best practices for testing.

I knew they weren't testing
that behavior that much.

Like I didn't trust the tests
that much, but also I didn't know

how to improve them a little bit.

So it was extra hard for me
because I wanted to improve, but

I also didn't have the support or
yet the, the knowledge to do it.

And I think maybe that might even
be one of the main reasons why.

It's extra harder sometimes for
some people, depending where they

are working is I do have to drive.

I do know this is not good, but I, I
don't know, but I am the one who cares.

Yeah.

I think, um, you know, as, as
developers, you know, were, who

are getting into a project or a new
client that we're working with, we're

always eager to fix things, right.

And to make things better.

And sometimes, yeah,
it is hard to balance.

The fact of like, okay, you're learning
a new system and not just a new system,

a new culture, new best practices,
new coat style, all, all of that.

So it's like, okay, how long
does it take for you to learn?

Like the way a team works and an
application was built and the minute you

start submitting like this small changes
to pay off what you think is technical.

That's why I like the idea of like,
establishing kind of like a baseline

of code quality and saying like, okay,
these are the tools we're going to use.

Where are you going to use Robocop?

We're going to use, um, Ruby critic
and we're going to use simple

cough to judge quality and like
the changes and then the code base.

Uh, and I think only after you
have set a baseline, you can

probably be more comfortable about
the changes that you think will.

Move the project in the right direction.

Everybody has the same understanding,
but yeah, I think it is hard.

To adapt your own ideas to
like someone else's project.

And especially as a consulting shop, like
we are, we have a hard time with that and

we just need to make sure that we respect
the, the practices that our clients have.

It seems to me, I seen that you mention
you develop software for clients

and do you have to convince them.

That's so important.

Do you need a budget for tests
or do you just say, oh, I'm

going to build this feature.

I'm gonna upgrade your rails version that.

Kind of included in the budget?

Well, we are a consulting shop and we work
on two types of projects, mainly like we

build new applications for companies and
entrepreneurs that have an idea and want

us to build it for that sort of project.

We certainly ship code, but also
code comes with test suites.

So we.

Don't even mention it when we're talking
about it, but if there's someone technical

in the client side and they want to know
how we work, it's like we ship code, but

we also shipped to a test suite with it to
make sure that their behavior is always.

Now for rails upgrade projects.

Um, the things that we do is we don't
really touch the test suite that

much, to be honest, we might tweak
little things, but an ideal project

for us is a project where we change
all the libraries underneath the

application and some of the code that
uses the rails, API and Ruby API.

And.

The test suite continues to pass, you
know, in rails four, two and rails five.

Oh.

So we don't really write a lot of
tests for the rails upgrade projects.

Uh, we do have like a pretty
high threshold where we tell

our clients if they don't have.

70% or more in terms of code coverage,
we can't really take on their project.

Uh, and we do that because we learned,
we learned the lesson in previous

projects where we took on clients
that had 50% code coverage and.

We presented our estimates and
then our estimates were off because

manual QA took a way longer time
than just running the test suites.

Uh, an automated test test suite.

We, we only take clients that
have like a solid, solid tests.

Uh, and it's not just
about code coverage for us.

Like, it usually means like if we're
talking to a potential client that

doesn't have a test suite coverage is 0%.

It's a major red flag for us.

Uh, it's not just tech debt.

It's probably culture.

Debt is probably like, you know,
communication that tooling that, and.

What we usually propose to these sort
of clients is to work with us, to

create a test suite that tests like
the critical flow of the application.

But, uh, so far nobody has
taken us up on that offer.

I found it really clever how
you filter out the clients.

And all that I can think of is
that will be a great question

to ask in a job interview.

We usually ask, how is the.

Tech dev culture if we get there, but
usually is how is the team culture

valuable would be really good to ask.

How good is the test coverage?

How is the culture with tests?

I never thought of asking that,
but I, I think it could also

be applied to top interviews.

Yeah, I think that would be a good idea.

I know that there are tools out
there, like cold climate and.

Seen, um, that help, you know, clients
and projects have like, uh, an eye on

the code quality of the application.

But when I built skunk, the idea was
very ambitious of course, to say,

okay, maybe in the future, someone
will say, what is your skunk score?

Average?

You know, I would love to know your
code coverage percentage, but also your.

Uh, Scott score average.

And that way you would know a little
bit more about the application.

You're getting yourself into one question
I definitely would recommend to people

who are considering a job is to ask the
potential company, what version of rails

and Ruby they're using in production.

In fast Ruby that I, oh, we talked to
a lot of companies out there that are

running like rails three to four, two, and
they've been around for 10 years or more.

Some of them are determined to upgrade
and they work with us and some are okay.

Just having a very old
version of rails, but yeah.

That is definitely like
a signal to consider when

accepting or rejecting a Java.

Do you see any differences
in the business?

So for example, companies that
are okay having another version of

rails, are they tech companies, are
they, sales companies are companies

that do something that is not.

Tack or maybe they don't have a product.

Do you see any differences in the mindset
versus the business side of things?

How, how they do things, what they sell?

Not really.

I mean, we don't
specialize in any industry.

If anything, we specialize
on JavaScript, uh, react JS.

Rubian and rails.

So we're very much tech focused
and not so much industry focused.

Um, we'd definitely work with companies
that have from one engineer in

their develop and their development
team to 500 engineers in the.

Engineering department, I would
say it's probably more common in

smaller companies with smaller
engineering teams that are focused on

shipping changes, uh, patching bugs.

They have a roadmap and technical debt
is seen as a distraction as in, uh, we

will pay off, we'll pay it off later.

Like this is not a priority.

We really need to ship this
for, you know, black Friday.

So we're okay.

Focused on tech debt.

Later, but usually later never
comes anyway, but yeah, I definitely

have seen a lot of these issues,
not just in small companies, but

also like huge companies out there.

I think it's, it's probably like a
cultural problem, like, uh, teams focusing

on shipping things and the roadmap and
technical debt kind of takes a back seat.

And sometimes you see like
these, oh, we're going to.

Uh, one or two weeks or a whole, I
don't think a whole month is reasonable,

but like, let's take two weeks,
everybody working on tech debt and

let's bring it down, but once a year,
and I think that's a bad strategy.

I think it's more important to have that
built-in and every sprint a little bit.

So yeah, I think companies that
have that embedded in their culture.

Better companies to join.

One thing that Stephanie talked
about about the interview thing is

something that I've seen is sometimes.

The company has, let's say
good teams and bad teams.

So one of the teams, they have
a good tech lead and they care

about code quality and testing.

But then in other teams
they don't care as much.

And so you're like, oh,
I joined the company.

I interview for the steam, but then
you work on another project that

doesn't really have any code coverage.

So it can be misleading sometimes to ask
about the code quality, because you're

never sure where you're going to land.

Right?

Yeah.

I mean, I think you're probably
talking about like huge companies.

I think there are also like
ton of companies out there that

only have one rails monoliths.

Yeah.

You'll get more or better.

Information.

And even if you're joining a huge
company, I think you would probably be

okay, asking like information about the
component that you're going to be working

on, to get an idea of what version of
Ruby and rails here you're working on.

I need to actually improve
the way that we sell.

Rails upgrade services, because I think
we're still doing a pretty bad job at

communicating, like the non-technical
results that you can get by upgrading.

And one of them is definitely like
people related, like nobody wants

to work on a rails for application.

Uh, nobody wants to join like a
team that's running rails three.

Because every time you need to
fix something, it's like, you

have to go on these archeological
expedition to find the API for the

current or the old version of rails.

So one of the things that I mentioned
in my sales calls is that if you

upgrade a route six one, it's
going to be easier to hire people.

And right now, you know, the market
is crazy for tech talent out there.

So these little things make a
difference and people want to work in.

Departments and applications
that are not constantly on fire.

Uh, people want to work
40 hours a week or less.

I think tech debt is tightly
coupled with the, with that idea of

programmer happiness and not being
a firefighter in, in your job and

not only hiring people, but also.

Keeping the goods people, right.

Attrition rate, because no
one wants to work on an old

code base for, I agree a lot.

And also from the perspective of the
majority of people that are still in the.

Meet level career.

You want to work on the new things.

You want to keep your skills sharpening.

You know, you don't want to stay stuck
working on old things because they're

probably getting stuck in your career.

It's going to be harder
to get out of that work.

And it's really interesting how
showing that in the terms of, Hey,

if you don't take this decision
now, even though it doesn't.

You might not make sense.

Now it's just part of
the long-term planning.

That's really clever in our last
door, you mentioned skunk, which

is the jam that you created.

And from all the jams that we
mentioned in the beginning rails, the

stacks metric full will be critic.

Is this the only one that you created?

Or did you also create another one?

Yeah, it's definitely the, the one I
created and it has been the most popular,

uh, I've created other gems in the past.

Um, but they weren't that popular.

Um, but, uh, yeah, recently we found
ourselves kind of becoming cold call

maintainers of Ruby gems that have been
abandoned by their previous maintainers.

Uh, or you know, that the maintainers
that we're currently working on

them moved onto something else.

Um, so Ruby critic, um, I started
contributing to it and I thought

it was a really cool idea.

And I started trying to
fix a couple of things.

And when I was building skunk, I
wanted to combine complexity and

churn data with, um, Code coverage.

There are two great articles by one by
Michael feathers, another one by Sandy

Metz, where they talk about this idea
of the churn versus complexity graph.

And in order to find
insights about a code base.

Which is awesome because you can
quickly see which files are the

most changed and the most complex.

And you're like, okay, I probably
want to stay away from, from those,

if I'm just starting on the project.

And then I thought it would be awesome to
add a third dimension in code complexity.

So instead of seeing like a 2d graph
with churn and complexity, it would

be more kind of like a cube, I guess.

Uh, never got to build the UI for it.

So right now it's only like a
terminal table that is printed and

it basically ranks the files, forum,
stinkiest to nicer smelling code.

Um, but yeah, anyway, the idea was not to.

Criticize someone's application,
but it more about finding the

files that need the most attention.

Um, and I thought, okay, what
about combining churn times?

Complexity times, lack of coverage.

Um, and that's how skunk was born.

I decided to.

Tightly, couple it to Ruby critic.

So skunk uses Ruby critic to work.

That's why I became a maintainer, a
freebie critic, uh, for rail stats.

Um, so there's, you know, the native rake
stats, uh, that comes with rails, which.

Pretty cool.

But sometimes it's hard when we're
trying to assess a code base and

we have to bundle it and run,
you know, bundle exec rake stats.

It's sometimes it's harder than you would
think because these are huge applications

and not all of them use Docker.

Um, but anyway, rail stats is a tool
that lets you see the same statistics

for a rails application without actually.

Uh, having to bundle the application
and start the environment.

Um, and one thing that we want to do
in that gym soon as combine it with

bundler Staats in order to get an idea
of the size of our rails application

and that way we would have the number of
gems, number of total gems and all the

statistical information on the models,
views, and controllers, and then metric.

I it, 10 years ago, I went to a Ruby
conference in New York and I saw

someone, you know, showing metric Fu
I thought that was really neat idea.

Uh, really cool that it runs a bunch
of tools against your code base.

And it generates a bunch of reports, but
yeah, 10 years later, I wanted to use it

again because I was considering it as.

Tool that I would use, uh, to
create skunk, uh, on top of,

um, but it wasn't maintained.

So I started making contributions and
Ben, who was the last maintainer of the

project was open to adding a commentator.

And, um, yeah, me and my company started,
uh, commentating the project recently.

And if you go to the Wiki
page for metric fool, you're

actually gonna find a table with.

More than 30 other gems that are out
there that are all about code quality.

So I think the hard part
about code quality is that.

I would say we have way too many
tools and way too many ways to define

a baseline for our applications.

Quality.

What is actually pretty cool that
we have so many options in the

Ruby ecosystem because you should
compare it to other ecosystems that

they don't have as much stuff then.

We do.

Right.

So it's really interesting.

Yeah, it is though, a little
shocking that so many tools have been

abandoned on the code quality front.

I think like maybe seven years
ago or seven to 10 years ago,

there was a lot of focus on it.

And it does feel like in the past
five years, Those projects have

been abandoned and there's been no
progress and many of them, yeah.

This is something that I was talking
about with Stephanie, because I

remember five, seven years ago, like
you mentioned, there were so many

projects, so many talks about good
quality, good coverage and all of that.

And it feels like.

Things changed a bit and I'm not sure why.

And then I wanted to ask you, do
you have any insights into that?

Why are people not talking about
code quality as much anymore?

Or maybe I'm not in the right places.

So I don't know.

No, I think you, you're
probably in the right place.

Uh, is.

I don't think people are talking that
much about it or working on it actively.

I think Ruby critic is probably
the best tool out there and the one

that's getting the most attention.

So if, um, any of your listeners want
to use one of these tools, I would

recommend to try Ruby critic, um,
and then maybe skunk, you know, The

barrier of entry for skunk is a little
higher because you need to run simple

cup first and then you can run skunk.

But yeah.

Going back to your question, I don't
know why people are not actively

working on this that much and why
there isn't that much content about

code quality and Ruby anymore.

Hopefully it is because
people are using tools.

Cold climate and code scene.

And maybe they're just adopting the
defaults that are in those tools.

Which is okay.

You know, like if you want to
use those tools, that is awesome.

Go for it.

They will help you pay off
technical debt and focus on having a

measurable, measurable way to do it.

I think maybe the quality, the
quality department or the quality

area has been more reactive than
proactive for many companies.

So it's like.

Oh, performance started crawling
like what's what's going on.

Okay.

We need to find bottlenecks.

Okay.

Let's focus on performance now.

Or.

You know, oh, the developers are
taking too long to ship stuff

because the code is a huge mess.

Oh, okay.

Let's spend a four spreads
trying to pay off technical

debt and then that will fix it.

Um, which is, as I said, like a bad idea.

Um, but yeah, I think we are very much
reactive as, as an industry and I think.

Maybe we need to be a bit more proactive.

Um, and if you don't want to use
code climate or code scene, you

can adapt some of these tools.

I know, like there are certain tools
that are very much up to date and

adopted, like Robocop is adopted
and as a great way to make sure.

You know, how silly discussions
about code style in a pull request.

You just have rural Robocop
and Robocop takes care of it.

Um, standard is, you know,
another take on Robocop.

I still like based on Robocop
and then there are other tools.

So some people also like to use
things like reek, uh, that will

basically run with over commit.

So every time someone
tries to commit a code.

Is stinky, according to wreak,
they will have that in place.

Um, so I think maybe it's because
people are picking like one or two

tools and just applying them to their.

To their checks for every port request.

That would be really cool.

Maybe that is one of the
scenarios, hopefully.

And I still, you already mentioned the
James again, and I would like to ask

you as a community, how can we support.

Better your, I know that the best way
is to contribute more, but is that,

is there something specific, like
maybe, do you need people to just

use it now and give you feedback?

How, how can we help?

The community by supporting the
James that you've maintained.

Yeah.

Uh, I think using some of
these gems would be amazing.

Um, yeah, like you said, contributing
can sometimes take a long time and can

be a little scary, but, um, trying to
use it, trying to use any of these tools,

like metric food, um, rail stats, um,
Ruby critic and skunk, uh, would it be.

Awesome because.

If you find any issues, then
we can quickly assess why it's

happening and try to fix it.

Um, another thing that you can do
is if you run skunk, um, there's a

little environment variable that you
can set, uh, like it's called share.

She said share to one and you run
skunk on an open source project.

Uh, and then it reports back
to a little service that.

That's also open source.

It's called it's called, um, skunk FYI.

Um, that gives us more information to
work on version 1.0, uh, I think for ver

version 1.0 of skunk, what we want to do
is change the skunk score grading system

to something that's easier to understand.

So.

It seems like the grade a
to grade F is the way to go.

Like Ruby critic, does
it cold climate does it.

And I think skunk should do it too so
that when people run the tool, they can

see, you know, oh, this is an, a, this
is an F there's a D and it's easier to.

I understand that the information that's
throwing at you, because some right now

when you run it, it says like all the
skunk score for this file is 15,000.

And one of the questions that
I've gotten at conferences is

like, what does that even mean?

What is 15,000 good or bad?

And I want to give more context and
say like, yeah, 15,000 is probably bat.

So.

Please, uh, considering factoring it.

I'm curious to know, how did you get
started with contributing to open source?

Do you remember the
first one and how was it?

Uh, yeah, for sure.

Um, the first project was a Ruby
wrapper for a service called topsy and.

They were acquired by apple many years
ago, but, uh, I really liked the idea of

building wrappers and Ruby for API APIs.

And I worked for about a
week and our released it.

And then a week went by and someone
else wrote the same gem and released it.

And I was like, oh, What a bummer.

Someone just did the same thing that I
did, but they did it better because they

added a test suite to the project and.

Uh, yeah, it was a bummer
at the beginning, but then I

reached out to them on Twitter.

And to, to this, to this day, I can say
that we're friends thanks to open source.

So anyway, if you want to get
started with open source and

you know, an API, that's cool.

And you want to use it to
do some sort of mashup.

I think that's also like a great way.

To get started with, uh, open
source because Ruby rappers

are pretty easy to write.

And there are a ton of
examples in get hub.

Like you can just search for like the
Twitter API, Ruby wrapper, and you can

just copy and paste a lot of the code
in there to create your own wrapper.

Um, but yeah, I, uh, anyway, I,
I love open source and for 10

years I've been doing this and.

I know it's hard for people
who are just starting.

So I think using the tools and
reporting back, any issues that

you have is a great way to get
started, to contribute to source.

And another way to get started is if
you like one of these tools and you

want to run or write up tutorial or
your own experience running one of these

tools and what you learned with them.

You know, you can create an article and
that helps us get more eyeballs and more

people using the tools and hopefully the
eyeballs turn into more issues as well.

Uh, good advice.

One thing that pretty
surprised us when we.

Decided to just explore rails was
we didn't set a lot of expectations.

We, we got there just,
okay, what can we do here?

We learned quite a few interesting things
just by trying to reproduce issues.

For example, I think that starting
with a project, just as a way

to explore and setting your
expectations really low kind of help.

Cause then you discover some planes and
you makes things more exciting, I guess.

You know, some people wouldn't recommend,
uh, new developers or junior developers to

start contributing to rails because rails
is a beast and, you know, it's amazing.

I love rails and I love
everybody contributing to it.

But.

It's very hard to get
started with something there.

That is, code-based one thing that
you can do, and I've actually done it.

Myself is go through the documentation
and improve the documentation.

There's so much room for improvement in
their rails docs that, um, if you want

to make like a tiny contribution to
rails, that could be a good way to get.

Um, and the more you look at the
documentation, the easier it's

going to get to eventually make a
code contribution to rails still.

I would not recommend
people start with rails.

I would recommend they start with a.

Small gem that they might
be using or, uh, yeah.

So something that's small
and easy to understand.

Yeah, that's a great, great tip.

One thing that I guess
was gay friend of ours.

He came on a podcast long time ago.

He said, if you want to contribute,
maybe use, maybe just get a jam.

And then use the latest rails version,
you know, rails 7.1 batter or whatever,

and then see if it breaks if the test
suite breaks and then you can just fix it.

So this is kind of a easy way to
contribute to other projects because

the API, the rails API changes.

So it's.

Keep things up to date.

Yeah.

Yeah.

I love that idea.

And I've actually implemented it myself
on these, some of these tools, that's kind

of how I got involved in some of them,
because I wanted to see if they work with

Ruby three and you know, Ruby three, it's
almost been a year, but there are many

libraries out there that are not running
their test suite against Ruby three.

And.

There's certainly a great way
to, to find issues with a gym.

And even if you don't find an issue,
you can just submit a pull request,

including Ruby configuration.

And it's just telling them
like, Hey, you were missing.

Jim works with Ruby three aisle,
and it's like a very quick

way to make a contribution.

So just getting back to the code quality
discussion, I'm kind of fascinated by

legacy applications, because at the same
time that people originally angry at

legacy code, you know, they say, oh, it's
terrible is all crap and all of that.

But at the same time, It's usually a
sign that people are using the product,

which is something that is very
valuable for a company to have people

actively paying and using yourself.

And then people are very negative
about legacy applications.

And I, I think that the tips that you
are sharing and then using these tools

and, you know, learning more about these
techniques from Michael feathers and Sandy

mats can help you be more positive about
working with legacy code because you're

contributing to something that helps.

You kind of have to change
your mindset about legacy code.

Right.

Did you ever have to change your
mindset about something that you

see like a sequel in a positive way?

How do you kind of approach that?

Yeah, I agree with you.

Like their legacy code gets a bad rap.

You know, if you think about it, um,
Shopify is running legacy code and they're

making millions of dollars and sure.

They're running the latest of rails and
Ruby, but, um, yeah, if you think about

it, it's been, uh, if an application
has been around for 10 years and

there's a whole company counting on
it, It is deemed to be legacy code.

To me, it just means like
this is a business that works.

And at the end of the day, they can pay
me to, um, have a salary, basically.

So, and I can use the time that they
pay me for to, to make it better.

I really like this idea
of makers and menders.

My friend am Scott Ford,
who runs another podcasts.

I think it's called legacy code rocks.

He likes to talk about the
idea that, you know, engineer.

Usually are either makers or menders
and either you like to build something

from scratch, or you like to mend
something that already exists.

I'm more of a mender than a maker.

I'm sure I built my company.

So in a way, I like to make businesses
in a way, but some people in my

company are more makers than menders.

So what we want to do in
my company is to have.

Projects for makers and for menders.

Um, but if I had to pick myself, I
would pick the mender projects because

I like to gradually improve, you know,
the infrastructure of an application

or to improve their processes.

So.

Yeah, I think, uh, I think it's important
to make that definition between, you know,

what you want to do with your career and
what they want you to do at work, you

know, and sometimes, you know, you'll
just want to mend things and sometimes.

You know, other people will just
want to make things and that's okay.

Um, what I like about legacy code
is that it's working and it's been

working for many, many years and
sure it can be enhanced and improved.

There's probably a test suite and
the test suite is going to tell me

I changed something and I try to pay
off technical debt and I broke it.

So yeah, I really like legacy code.

Yeah.

I know there are a ton of people out
there that love to work on legacy

code too, even when it gets up.

But it's funny because it
don't hear much about it.

So there are people out there working on
legacy code, making things better, and you

don't hear about it because it's working.

Right.

So it's kind of like you're
doing important work, but

maybe you don't get as much.

Disability when you're doing that.

Yeah, I guess it's, it's
definitely not sexy.

Like, it's not like, oh, I built
this, uh, JavaScript framework

to, you know, solve this problem.

It's no, it's definitely not, not sexy.

And maybe if people write about
it, Reaches, not that that big, but

there's definitely like a microcosm
of people who are writing articles

about legacy code and maintainability.

Yeah.

I actually love to be in that
little microcosm, I guess I

really loved the analogy that you
mentioned Manders versus makers.

And I think when you're getting.

Um, maker an engineer who is a maker
and tells this person to man softer.

I think the knee jerk reaction
they have is, oh, I'm gonna throw

everything away and build everything
from scratch, you know, the big

rewrite and things like that.

And it's.

Usually doomed to failure, right?

So maybe you can't do that.

So don't put a maker to man your projects.

Uh, well, there's this book by
Fred Brooks and I think it was

published in the seventies.

And one of the chapters of the medic
mythical man month is called something.

The joys and woos of the craft.

And he actually goes on to say like,
yeah, you know, like building something

is like accessing, like the creative
part of your brain is like, that's full

of joy because you're like in a state of
flow, you're trying to solve a problem

and you're trying to build something new.

So it was like, oh, everybody's joy there.

And then the woos, or like the, the bad
part is like fixing bucks, you know?

And he assumes that
nobody likes to fix bugs.

I think that's a wrong assumption.

Like I think there are like, uh,
many people out there that love to

solve puzzles and love to basically
dig into a bug and go deep into.

The stack race and try to find
that anyway, I think like we need

to add this to our lingo and to
say, just because you're a software

engineer doesn't mean that you enjoy
building stuff, stuff from scratch.

Like there are plenty of software
engineers that just want to go

to an established team and maybe.

Improves that code base to work better
for the end user or the developers.

I know her nest.

So you will have lots of things you do.

Uh, just want to try to ask if there
is something that you would like

us to have asked that we didn't
well, yeah, considering you're

from Brazil and I'm from Argentina.

I was actually expecting, we could talk
a little bit more about soccer and the

America's cup and the last final that
Brazil and Argentina played, but I know.

Topic.

It's not the topic we're discussing
today, but, um, I have time

to discuss that if you want.

Thank you.

We were prone the worst people.

This, I have no idea about soccer at all.

I don't really watch soccer.

Sorry.

Okay.

Yeah.

Even if you knew, uh, I would expect
that answer anyway, so no worries.

Carnival soccer.

We are not very into that kind of
stuff, but we can talk about food.

So food is our passion.

Okay.

Okay.

Um, anyway, no, it was great to be here.

And, uh, yeah.

If anybody wants to see some of
the work that we do, uh, feel

free to follow me on Twitter.

My handle is worker and I usually.

Uh, content from the company.

Thank you so much.

That was a great talk.

I loved learning so much things from you.

So thank you so much for sharing your
experience and your skills and insights.

You know, we will make sure
to put the genes in the.

Episode notes.

So everyone can at least take a look.

Your next door is a really nice guy.

And you can say you, you
met him from the podcast.

Everyone go check them.

Yeah.

Thank you so much.

Thanks so much here, NASA
for coming on the show.

Thank you so much for your work as well.

So these genes are really important
and, you know, having someone to

take over and continue the work is
really important, really relevant.

The community is also nice to
finally meet you because we worked

in the same projects in the past.

We will never really met.

I always saw your picture on gait,
but I never got to talk to you.

So it's really amazing to, to
meet you and thank you so much.

I hope it's all, all good things
and you didn't have to fix all the

bugs that I added before I left.

Yeah, should run the skunk and report.

Please do that.

hexdevs: Thank you for listening to
this episode, we put lots of love

into the hex labs podcast, and we
hope you learned something insightful

before you go on with your day.

Could you share this episode with
a friend or a colleague that would

help us a lot And don't forget to
subscribe to our newsletter, to get

exercises, tools, insights, to help
you become a Ruby expert developer.

See you on the next episode.