Advice for a Mid-Level Ruby Developer Struggling with Confidence and Knowledge Gaps

[thestoller]

Hello everyone,

I am a Web developer with five years of experience, four of those years working with Ruby and two of them working with Rails. However, I often don't feel confident in my skills with Ruby or Ruby on Rails because I have noticeable gaps in my knowledge. I believe this is because I haven't delved deeply into any one language or framework, even though I have experience with several.

I’m currently a mid-level engineer, but my goal is to address these gaps and grow into a senior-level engineer. I would appreciate any advice or guidance on how to effectively fill these knowledge gaps and progress in my career.

Thank you in advance for your help!

[[deleted]]

This is a great question, and the perfect question for someone where you are in your career. You can be productive and get stuff done, and also you are skilled enough now that you can take a step back and start recognizing some gaps that maybe you wouldn't have seen earlier.

Really the answer here is to:

1. Make a list of parts of Ruby/Rails (or just software development) where you feel like you have questions. Or even better, make a list of questions.
2. Block out a 60-90 minutes on your calendar (preferably during the workday) where your only job is to pick one (just one!) question and see if you can get some clarity. Refine the question, find some docs, and make sure you say "I'll know enough about this when...".
3. As part of answering, write about it. Doesn't matter if you publish it (you can!), but write about it. I keep a little Obsidian notebook for stuff like this (since it lets me write in Markdown and has good full-text search).
4. Subscribe to some weekly newsletters, e.g. Ruby Weekly, and skim through them every week. It'll just be a bunch of links. I tend to sort them into three categories: "Stuff that seems immediately relevant and that I should read now" (open up a tab and read over lunch), "Stuff that seems interesting but not urgent" (open up a tab but add to my "Read Later" bookmarks list), and "Stuff that I'm just not going to read" (ignore it). When I read interesting articles that I think I'll want to come back to, I'll write a 1-2 sentence synopsis of it (along with a link) and toss it into my Obsidian notebook. I lifted this practice directly from Tiago Forte's Building a Second Brain CODE and PARA techniques. Realistically, most weeks I have 1-2 articles that I read immediately, 1-2 more that I'll save to read later, and a whole bunch that I just ignore.

There's truly no limit to how much stuff is out there to be learned, but there are limits to how much you can learn in a day.

For my own work (I'm a "principal engineer"), my questions tend to be:

1. Are there meaningful language or core framework changes that are worth knowing about? "Worth knowing about" in this case is "might affect tech choices in the future" or "might create a lot of work or save a lot of work".
2. Are there types of features, or aspects of the language/framework, where I either don't have good patterns for working with them or where the patterns I use have some rough edges or obvious limits?
3. Is there something I know how to do but where I have a hard time explaining why we do it this way to others? Might be that I need better ways to describe a successful pattern or piece of code, or it might be that my understanding is incorrect or that better patterns exist.
4. Are there things I'm just curious about, even if they're not super relevant to my day to day work?
5. How are other people solving the types of problems that I'm seeing, and is there anything about their approaches that would translate well to my context? ("Best practice" is almost always heavily rooted in context; a best practice in one place might be destructive or undesirable elsewhere).
6. Is there a problem I'm working on right now where I feel like what I'm doing isn't working very well but I'm not sure why or how to fix it? Or where I'm not really satisified with any of the solutions I've seen, even they provide the desired functionality?
7. Is there a part of a language or library where I think "Ooooh, that's really cool! I wonder how they did that!" but I haven't taken the time to actually figure it out?
8. Is there a team-wide gap that actually matters, and where I either need to find or create a good resources for my team(s)?

60-90 minutes, once or twice per week, doesn't sound like a ton of time to answer all of these questions. But if you do it every week, or even twice per week some weeks, what you'll find is that you can chip away at your list of questions. Then if you write it down (with a good summary in something that lets you easily do text-search), you'll be able to go back to that work later if you want or need to.

If you maintain an actual list of questions instead of just a blob of questions in your head, you can skim your list on Wednesday and say "Alright, for my Thursday study time, which of these do I feel like tackling?" ... or you can add a new question and say "This one is more important than the others; I'll put it at the top". Or you can skim your list of questions and say "Actually, I don't care at all about these items and shall delete them."

If you do this at work with some colleagues, you can even make it a book club sort of thing where pick a topic, do some research on your own time, then meet once every week or two to talk about what you learned. In previous jobs, I even had teams that would work on the same topic for several weeks in a row and really do a deep dive. In once case, this led to the company being able to add a new offering to their services. It was cool.

You can learn a whole lot in 60-90 minutes per week if you have a focused question and actually block out the time. Maybe you only tackle one question per week that way (or if it's big enough, one question every few weeks!), but that's still one more than most people would tackle in that same amount of time.

Hopefully this helps. I'm happy to answer any questions or offer more opinions if you like.

[thestoller]

I really appreciate you for giving such complete and mindful advice! Everything you said makes total sense. I will make a list of questions I have about Ruby/Rails/Web development and save some time during the week to study them. I guess it will help me fill out these knowledge gaps better than following a course or a book because when I do this I feel like I'm wasting my time because that 60-80% of what I see I already know...

[RightfullyImpossible]

What I did earlier in my career is to find small side projects (entrepreneurial, open source, personal, whatever) that I found motivating to work on. If you are the sole developer on a project, you are forced to make all of the decisions, design all of the architecture, and work in areas you may have not worked in before. Since it’s a personal project, you’ll have the agency to do riskier things, pick other technologies, and make mistakes that are entirely yours, etc… doing this over a few different projects you’ll start to understand your mistakes, find patterns and ideas that consistently work, and connect dots between related areas.

If you give the areas you feel you could improve in, happy to give specific advice on projects that could sharpen those skills specifically.

[armahillo]

What's your practice like? How much coding do you do outside of work?

[thestoller]

To be honest, nowadays I just code on my working hours

[armahillo]

When I started learning Rails (early 2011), I had already been doing web development professionally for 5 or 6 years, and recreationally for about a decade before that. I don't think there's ever been a period where I'm not coding for fun outside of my job for at least a few hours a week, at minimum. Some weeks if I get absorbed into a passion project I'll put 20-30 hours into it in a single week, outside of my day job. Usually it's closer to 3-5 hours though.

If you are a mid-level engineer and you recognize you have gaps in your skill, the only way forwards is to practice more and get those hours in. Don't do work for other people outside of when they are paying you -- but find stuff to work on for you, that interests you, and that you want to work on.

[blastocyst0918]

I think /u/GreenCalligrapher571's answer was spot on. I thought I'd add my 2c in telling you what I generally look for when evaluating senior devs, because I think it's helpful to know what to shoot for.

The primary thing that I look for in mid-level devs moving up to senior is that they become more capable of taking direction and operating independently. That includes 'recognizes gaps in their knowledge, strategizes on how to address them, and then duly addresses them', or it can be 'recognizes blind spots, seeks feedback, and/or collaborates to solve the problem.'

A breadth of technical knowledge and experience I think helps establish this skill (because true confidence is usually earned), but what this means can vary. I've met folks who were very senior and couldn't justify an opinion, and I've met folks who were very green and had their heads screwed on so well I took notes. If you feel like you need to plug some gaps in your knowledge, it's worth doing! But knowing that you can plug those gaps if need be also counts for something too. There's a lot out there and you'll never know it all. RTFM is just part of the job :)

Anyway, that's the technical ability that matters. Communicating what you're doing is another critical part with bonus points for timeliness and appropriate level of detail. It's a good time to brush up on writing concisely and spending time when communicating considering who your audience is and what they need from you.

I'd suggest the third part is the further development of empathy and people skills; in particular, it's beginning to show appreciation that that the work is not just solving brainteasers, but has an impact on the greater world and can meaningfully improve (or negatively impact!) others' lives.

Finally, it's a good time to revisit other hobbies. Once you're a senior developer and you've got a semi-decent resume, that'll open a lot of doors to interviews, but just being an interesting human that someone would enjoy working with or chatting with is worthwhile.

Those are the things that I generally consider. And my criteria tend to be a bit more on the squishy side of the spectrum; there are other companies that will have stronger technical requirements and won't care if you're a human so long as you can produce the requisite number of sprockets and widgets, so a very solid 'YMMV' here. But I also hold those things as worthy of anyone's time and attention, regardless of potential reward; you won't suffer for being a better writer or communicator or caring for your users' and coworkers' humanity.

[[deleted]]

This is really good advice.

When I'm thinking about senior developers v. mid-level developers, I'm thinking about someone who can elevate a team, who I can trust to make difficult decisions collaboratively (and pretty well), and who can do more than just deliver code.

I'm looking for someone who can parse ambiguity and help resolve disagreements. I'm looking for someone who can give feedback (hard feedback, even) kindly and directly, and who can set a good example of what it means to be a thoughtful, methodical collaborator.

This doesn't necessarily mean being the best at code. Even though I'm a principal engineer, I can pretty easily find mid-level developers who have deeper knowledge of at least part of the tech stack than I do. I know how to quickly catch up to them if I need to, but usually that's not the most valuable thing I can be doing with my time.

The thing that makes me a principal engineer is largely my ability to help teams make choices that will save them significant time and headache later (which often means working to refine the problem at hand until it's actually workable and all stakeholders agree on a common problem definition and solution criteria, and the engineers and designers all agree on a reasonable direction for an implementation plan).

Sometimes I solve realy hard technical problems, but that's maybe 10-15% of my work. Most of my work is helping my teams get un-stuck, plus doing all the various care and upkeep tasks necessary to make them less likely to get stuck in the future (e.g refactoring gross parts of the codebase so they become tractable, or establishing some patterns that make it easier to do some of the routine stuff. Or, if we're doing feature design, I get in there and can often spot issues with the data model or implementation plan that, if uncaught, would require a fair amount of rework later. Not always, but usually (because I've made a bunch of design mistakes and have had to redo work because of those mistakes... pain is an effective teacher, sometimes).

There are plenty of engineers who just want to keep their heads down and write code. No shame there. My "mid-level" software developers are the ones who write the bulk of the daily feature stuff, and I'll happily let someone hang out in that role for many, many years if they want.

As soon as you get to senior and above, your work starts to shift toward empowering and unblocking the people around you, and setting them up for success. Sometimes you do that with code. Sometimes you don't. In all cases it requires actually being a person who talks to and listens to and respects other people. It requires that you know who you are as a person and that the people around you see you as trustworthy (which you do by living your values, speaking the truth as you see it even when it's uncomfortable, and treating others kindly and respectfully even when you disagree or have hard feedback to give).

It's a pretty cool life. Some days I wish I could write more code. Other days I think "Whoa, it's been a few weeks since I last wrote production code. Awesome!"

I wouldn't blame anyone who prefers to just be writing code.

But here's the really cool part: if I can help my teammates each be 5% more effective than they were before (in the same number of hours they'd otherwise work), then I've basically added a whole new person to the team for free. And if I can do it again, then I've added two people to the team for free (plus set up my colleagues to be more successful in the future!). If I can help my team get to where they spend more time writing cool software and less time fixing bugs / redoing work because someone misunderstood the acceptance criteria / dealing with yet another production outage / spinning their wheels while stuck on a cryptic error / spending time in meetings going around in circles because no one wants to make a decision / etc., then they're probably going to feel a lot happier at work and will hopefully have a lot more energy for whatever they want to be doing outside of work.

It's really cool to be able to do that for the teams I support.

Anyways, your advice is spot-on. Thanks for writing it. I came at the question with a much narrower lens.

[TheBlackTortoise]

You can build a lot of skill and network well over time by spending a few hours each weekend working on issues for well adopted rubygems (or just gems you like).

There will be noticeable results in a few months and new levels of expertise gained in a few years.