We recently chatted with Radhika Morabia, an awesome developer who we met through Twitter (sidenote: one of our favorite things about social media is being able to connect with cool new people). Radhika is a self-taught developer who has recently launched herself into this line of work. We talked about a broad array of topics including getting started in this field, the purpose of the titles “junior” vs. “senior” developer, her thoughts on community learning, and more. Read on to get to know Radhika and her awesome story!
1. Hi Radhika, it’s great to talk to you today! Do you want to begin by giving a bit of background about yourself?
In December of 2017, I set out to become a professional programmer. I had dabbled in HTML & CSS before, but nothing more. I taught myself through a mix of video courses on Udemy, projects I built along the way, and of course, a supportive community behind me every step of the way.
I have zero Computer Science background. I’ve always believed in self-education and knew it was the only way I could go about this process.
2. What inspired you to set out on this new path?
In another life, I was actually a freelance marketer. I hopped between businesses, delivered my work, and never saw what results came out of it.
After a while, I got fed up with that. I knew I enjoyed working on products—seeing the growth and the impact over time. I wanted to work in an office with a team again. I didn’t think the marketing I specialized in (content writing) would necessarily grant me those opportunities.
So, I turned to programming. There’s a sense of artisanship that the programming community seems to have. If you really show a willingness to learn and improve, people are generally helpful and supportive about it. Despite the stereotypes, programming has been a really social activity for me compared to marketing. It’s been a really great career path for my personality.
3. On Twitter, you were part of an interesting conversation about the difference between being a junior and mid-level developer. Can you summarize your thoughts on this?
As more and more juniors enter the field, the number of jobs marketed towards juniors is decreasing. The supply is growing AND the demand is shrinking.
I (and most other programmers I know) were not hired as Junior Engineers. We’re just Engineers. We just happen to have less experience. It takes us a bit longer to catch up with everyone else, but every year of production experience makes that catch-up timespan shorter and shorter.
I don’t think most companies care about the difference. It’s not like there’s widespread formal mentoring programs for people with less experience. To most companies, we’re just an initial cheaper, less experienced hire. Once we’re on the team, we’re treated the same as everyone else.
In my opinion, Junior Engineers are those who don’t have production experience yet. They don’t have experience with sprints, teams, huge codebases, ticketing, and general teamwork yet. Once a programmer is exposed to that, they’re a Mid-Level Engineer.
I personally identify as a Mid-Level Developer. My job title at my company is Front-End Developer, not Junior Front-End Developer. I expect my job titles moving forward will not include Junior either.
4. How do you think teams would work differently if junior titles were more commonly used?
Wouldn’t it be great to really be an apprentice for the first 5 or so years of your career? Formally absorbing the knowledge of those with 20 more years of experience than you?
The current reality is that Junior titles are few and far-between. Engineers are hired to solve business problems, not to have defined seniority levels based on years of experience.
So, a Junior hasn’t had production experience. A Mid-Level doesn’t have experience with the architecture & deeper design organization of the app. And Seniors & Team Leads? I’m sure there’s some experience gap there that keeps them from being CTOs.
I like those title separations. I know I wouldn’t want to be suddenly leading a team of engineers with this level of experience. I still like some sense of hierarchy.
5. You mentioned you have a lot of thoughts about learning after you are already employed. What are your opinions on this?
When you’re learning how to code for code’s sake, it’s wonderful. There’s always another project to start. There’s always another challenge to conquer.
There’s a whole different skillset that comes along with production code. You have to traverse a huge codebase, at a scale you’ve never seen before, and find the one or two lines that need to edited to fix the bug. Or, you need to find where in the code to add your new code so that the whole thing doesn’t break.
It’s as if the scale of the code makes whatever syntax, whatever clean code you’d love to write, whatever elegant solution you have in your head useless.
So, now that I’ve had this experience, it’s hard to feel as if making some 100-200 line project in Java is really going to teach me Java. I know that whatever I end up learning will feel completely irrelevant once I work with it in production. It’s going to be like starting from scratch all over again.
I know it’s important to work on my skills on the side, but I truly believe the best chance for learning happens at work. Absorption by necessity beats watching a tutorial any day.
6. How has this belief influenced how you have learned?
I haven’t updated my GitHub since I got a job because of this! I’ve improved so much as a programmer, but I find it near impossible to actually make projects the way I used to.
The biggest difference is that I can’t learn the way I used to anymore. I now have enough experience to see the patterns between different languages and frameworks, and can pick things up pretty easily. I’m more interested in why or how a new framework or language is different than what I’m used to than the specific syntactic differences.
This means I finally understand why experienced engineers recommend such bad learning resources to newbies! I’ve gotten to the point where I can’t stand the kinds of resources I would turn to when I first started learning. Now, I need something fast and challenging. Get me in my code editor and building something demonstrable as fast as possible.
7. How do you define community learning?
There’s less formal mentorship in companies than ever before. However, the value of mentorship has never changed. If anything, it’s more valuable than it’s ever been.
I’ve had single one-hour conversations that changed the way I thought about code or my career completely. I’ve had code reviews from people who have no incentive to give me feedback teach me things I never would’ve thought of on my own. I’ve had an incredible support systems that taught me how to deal with rough situations in this field.
Community learning is a grassroots version of formal mentorship. It may even work better than formal mentorship. It’s learning something from everyone you meet and following through on their advice and suggestions.
In my experience, most of the people who are interested in community learning (both giving and seeking) are not necessarily public or on Twitter. They’re at meetups, they’re in smaller communities, or they’re just some friends of friends. Reach out.
My first community learning experience was with CodeBuddies, a Slack channel devoted to this concept. I can say it was single-handedly the biggest reason I went from knowing nothing about code to getting my first job so quickly.
8. How could community learning change the way we think about education? How can we work toward that?
I don’t want to say community learning is the end all, be all. I’ve been both a mentor desperate to help people and a mentee desperate for direction. There’s a lot of unpaid labor that goes into community learning. I am eternally grateful to everyone who’s given me the time of day to help me improve and become a better engineer. However, people like this are still in the minority.
I love the community that engages in this mindset. But, I definitely worry about the people who seem to feel obligated to give back because they don’t feel they deserve their good fortune. No one owes their time to anyone. No one is entitled to the community’s time.
If you want to reap the benefits of community learning, be a good community member. Follow through, thank people, and try to be as helpful as possible when people need you.
In the end, your education or continued learning is still your own responsibility.
9. You’ve spent time using both the React and Vue frameworks, and there is an unending debate in the dev community on “which is better” for various scenarios. How does your experience so far guide you on which of these two to use, and for which circumstances?
The more I learn about programming, the less I’m convinced that one thing is actually better than the other. I’m particularly mixed about React and Vue. I truly like both.
Vue is great for UI & prototyping. It almost feels like an HTML-first framework. It feels like it was made for manipulating the UI with dynamic content. I love the ease. Vuex over Redux any day of the week.
However, React feels needlessly complex for simple projects. There’s a lot of set-up if you just want a mostly static site with a few dynamic elements. It’s also absurd to me that there’s no well-defined way to handle CSS.
I like both a lot. I enjoy using both depending on the circumstance. It’d be great if a new framework came along and solved all my problems with both!
10. Anything else you want to talk about or promote?
I’m still pretty new to Twitter, but having a fun time with it! Feel free to reach out at @radhikamorabia.
We love that Radhika has approached her passion for development with such passion! It was great to chat with her and we can’t wait to see what the future holds. If you think you have a story that would be an awesome feature on our blog, email us at email@example.com. We can’t wait to hear your story!
Kuvio Creative is a web design and development agency powered by an innovative remote team working from across the globe. We find creative solutions to that exceed our clients wants and needs. Contact us today.
*Some responses have been edited for length and/or clarity.*
Subscribe to our monthly email list for our latest blogs and company news sent straight to your inbox.