Are you working on Ruby on Rails Applications that are constantly on fire, overwhelmed by technical debt? Instead of being a firefighter, what if you could be a happy programmer again? Listen and learn exactly how to measure tech debt and take the right steps to immediately improve code quality!
hexdevs: Hey, there!
Before you listen to this amazing
episode, we have something to ask 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?
get on the wait list today!
Enjoy the episode!
Stefanni, Thiago, Ernesto:
Ernesto worker is the founder and
email@example.com 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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%.
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.
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.
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.
Leading by example is,
uh, is another idea.
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.
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.
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.
The test suite continues to pass, you
know, in rails four, two and rails five.
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?
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?
I mean, we don't
specialize in any industry.
If anything, we specialize
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.
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.
You'll get more or better.
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.
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.
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.
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.
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.
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.
We need to find bottlenecks.
Let's focus on performance now.
You know, oh, the developers are
taking too long to ship stuff
because the code is a huge mess.
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
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.
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.
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.
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.
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.
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.
Keep things up to date.
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.
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.
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.
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.
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.
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
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.
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.
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.
It's not the topic we're discussing
today, but, um, I have time
to discuss that if you want.
We were prone the worst people.
This, I have no idea about soccer at all.
I don't really watch soccer.
Even if you knew, uh, I would expect
that answer anyway, so no worries.
We are not very into that kind of
stuff, but we can talk about food.
So food is our passion.
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.
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.
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.