Develop Yourself

Office Hours: Answering Your Coding Questions EP 3

• Brian Jenney

Share episode

Are junior devs cooked?

How can I scaffold a solid MERN stack app?

What's the best way to stick with a tutorial?

We got some great questions this episode and my answers might surprise you.

Got a question you want answered? Drop it here: https://form.typeform.com/to/Q499M9kl

Send us a text

Shameless Plugs

🧑‍💻 Join Parsity - For career changers who want to pivot into software.

✉️ Got a question you want answered on the pod? Drop it here

Zubin's LinkedIn (ex-lawyer, former Googler, Brian-look-a-like)

Speaker 1:

Welcome to the Develop Yourself podcast featuring my dad, the best coder ever. All right, today, on a brand new episode of Office Hours, I'm answering questions directly from you listeners out there. I really appreciate those that do this. By the way, if you have a question, you can use the link in the show notes. Whether you're on Spotify or Buzzsprout or Apple Podcasts or whatever, you can use that to submit a question, I will answer it. My name is Brian.

Speaker 1:

For those of you who don't know, I have around 12 years of experience as a software developer in the San Francisco Bay Area and I've done somewhere around I don't know six or 700 phone conversations with developers over the last few years, mostly for my business, but also just to help people out, and I thought this is a much better way to do it at scale. So I thought, hey, why not just open up questions so people can ask me all sorts of cool stuff? And we're going to get right to it. This one is from somebody named Diego. Diego. Thank you for the question. Off the bat it says, hey, I'm thinking about changing careers and I've discovered that I really enjoy coding.

Speaker 1:

I've been studying for about five months now and enjoy every minute of it, but I've been feeling uncertain and discouraged lately with a lot of articles that I've read and videos that pop up to my feed about software engineering becoming obsolete because of AI. What are your thoughts on that? Should I continue studying or should I go do something else? Oh man, diego, there are so many people that are feeling like this right now. Even some senior developers that I've met are feeling like this, and I'd be lying to you if I said that this was just like nothing to worry about at all, like oh yeah, just things are the same. They're not the same, right? We don't know what the future holds. I can say this with a lot of confidence the current state of AI tools is nowhere near replacing a software developer with even moderate skill Nowhere near software developer with even moderate skill Nowhere near. I use AI tools every single day.

Speaker 1:

I've worked at a couple of AI company startups in the San Francisco Bay Area and beyond at this point, and let me tell you these tools are right now, more hype than actual practical use. What I can tell you is they significantly speed up certain aspects of writing code. If you're a junior developer, these tools are probably really scary because they kind of can write all the code that you can't write at this point. But remember this your career is going to be mostly at the senior level and above right. Like just think over the time period of 20, 30 years 20 years at minimum, and like, if you're 40, you're going to have at least 20 years in this profession, and that time period as a junior, when AI tools can really do whatever you can do, it's a really, really short time. You're gonna need to understand things like system design, how to make scalable code, trade-offs, communicating with people outside of tech, defending your ideas, defending what the AI tools are writing. So, yes, there's certainly a future in tech and, believe it or not, there are actually more jobs now than there were two years ago in tech, and I think that's gonna lead us into another question from somebody else. But in tech and I think that's going to lead us into another question from somebody else but, yes, keep studying.

Speaker 1:

Do not use AI tools just yet, because that's going to set you up for failure. A lot of people that are learning to code are making this mistake and if you avoid that and you do the hard work of really understanding how to write code and read some books about system design, about software architecture, you're going to be in a very, very good spot, and my bet, my big bet, is that if you do this, you're going to be ahead of the majority of people. I feel like, actually, we're entering into a phase where we're going to have a lot of really sloppy developers that are thinking that AI tools can replace them and they can just AI their way or prompt their way into a career, and they may actually even fool some hiring managers and engineering managers and get past certain coding interviews and all this kind of stuff, and they're going to fail miserably after a few months. There's already stories of this happening. I feel like if you take the hard route, if you learn things the hard way, you're actually going to be prepared to beat all these people and be in a really, really solid position. So please don't get discouraged at all. In six months, this could very well change. In six months or a year, even, we could see that, wow, these. In six months or a year, even we could see that, wow, these tools have grown exponentially better. Now history tells us that's not generally the case. We see that things like space travel, cars, other technologies, just haven't exponentially improved over time. So I don't know why AI would, especially if we consider where we were six months ago, all the claims that we were hearing from CEOs, and those just haven't materialized at all. There's even some studies saying that AI makes senior developers a little slower. So, hey, you can't determine the future. I wouldn't try to plan your career around headlines and what people are saying online to get clicks and views. Do it make sense to you? There's certainly future encoding for the time being, so there's no reason to not consider it, in my opinion.

Speaker 1:

Next question from Mikey from San Diego. He said hey, I'm a noob with some knowledge of HTML, css, a bit of C Ooh, fancy, fancy lad and a bit of JavaScript. Give your most raw, non-sugar-coated answer possible. Ooh, I like this. Do you believe the job market for software engineers will ever correct itself back to what it used to be pre-COVID and, if not, what are the chances of us noobs really landing a job? What are the chances of us noobs really landing a job? What are the requirements these days? That's a good question. We'll never rebound to what it was pre-COVID. I don't know, probably. Here's the funny thing that chart that everybody sees where it shows this massive drop off in the number of jobs is basically from the pandemic over hiring spree. I don't think we're maybe ever going to get there, but we are incrementally getting back towards what was kind of normal pre-pandemic. So in many cases we're already kind of there.

Speaker 1:

Getting a job has always sucked. It's never been easy. That's the main issue I see with people that are learning to code. It's exact same reason why we have a program like Parsity, but for that, obviously, because we see the career change is much, much different than just learning to code. Learning to code is the obvious part. Yeah, you can't get hired if you cannot code.

Speaker 1:

But how do you get to an interview? How do you pass the interview? How do you set yourself apart from other candidates? How do you become a professional coder? That is the big differentiator. What are the requirements? These days the requirements generally are like full stack, that you you know some modern programming language like JavaScript, typescript, python really good choice SQL, postgres. These kind of bare essentials will get you close to the door of being at least hireable. Being able to build and deploy a full stack web application is a really good litmus test to see like, hey, am I like hireable and what are the requirements I mean? Really, nowadays, I feel like there's more and more teams and companies want to do less with more. So we have this weird AI hype, slash productivity myth that you can just be super productive with AI, and so, really, companies looking for people that don't need a lot of handholding, which is really not cool for junior developers, because they honestly do need a lot of guidance. When you joined a company pre-pandemic no, that wasn't the case back then either. So how much have things really changed? It's just harder to get a junior level entry job than it used to be because the requirements and the bar for entry has been raised. So what used to pass for a junior developer in like 2009 wouldn't even get through the door in 2025.

Speaker 1:

What does that mean? You have to build more than a few toy apps. You have to have more than a few toy apps. You have to have more than just a portfolio. You probably need to have an online presence. You need to present yourself as a software developer. You can't say I'm aspiring developer, I'm a learning developer. You need to build something that says, hey, I'm a software developer. You need to be able to do full stack web applications pretty much on your own and you need to understand just a little bit about software development, lifecycle, things like system design at a very basic level, and I think that's going to really differentiate you from a lot of people who are either computer science grads or bootcamp grads that know how to write some React or string together something really basic, but fall apart immediately when they have to do something without the assistance of AI tools or when they have to go off the tutorial or when they just have to do something that they haven't like memorized. So if you're an actual software developer no matter if you're a junior, mid-level, senior, whatever I think you're going to be fine.

Speaker 1:

I think it's just always going to be difficult to get to that first job. And will the market ever correct? Quote, unquote kind of already has, and again, we're incrementally seeing increases in the number of jobs out there. That doesn't mean it's easy, it just means that we're seeing more jobs than we had in the last few years. So what can you do? Try to get an internship, if possible. Try to work for somebody for free, to build something that you can put on your LinkedIn or resume, because no one wants to take a chance on you. So do whatever you need to do to have that first thing on your resume, say software developer. If you can do that, I think you're gonna really improve your chances. Get to 500 connections on LinkedIn. Write a little bit about what you're doing on a weekly basis or a couple of times a week, and then just be good at writing code, like be able to deploy a full stack application and talk about it intelligently. Build something, over-engineer it, find problems that you don't need to solve and just try to solve them, so you get a lot of experience. I hope that's helpful, and who knows what the future will bring? I also see a future where software engineering jobs skyrocket because of the AI tools that we're seeing now, and now software engineers are even more productive. Companies are sprouting up that need engineers now, so I can also see a future where the market just blows up. We don't know.

Speaker 1:

Ooh, this one's a really spicy one. This one is from Miguel. So Miguel says hey, I'm from Portugal, I've been listening almost religiously to your podcast, wow, and thank you so much for saying that. It's pretty surreal to me to think that people around the world might be listening to this, so I sincerely appreciate that. It says I also come from a not so good life of selling drugs and recently gave up on daily drinking habits, and my transition from merchandise logistics to software developer was tough, but in part thanks to you, possible. I mean, I'm in a big 70K people company for 10 months and already loving it. I'm the kind of guy that structures his daily time not in an obsessive way but in an effective one. Wow, solid dude. I'm loving to hear that. I'm loving this already.

Speaker 1:

I don't know if there's a question here, but hey, shout out to you, that's really cool and I'm just glad that you wrote this. It says I'm currently doing Udacity course and have a lot of courses to do in Udemy as well as part of my path as a junior developer in my company. But between working on tickets, attending meetings, coordinating the team of very experienced people on patching highly critical databases and all other random stuff related to my work, I find myself having a very tough time completing the courses. Yeah, no doubt Getting a new job is really difficult and doing a completely new type of work as a software developer even more difficult. Right? The Udacity one, he says, is on infrastructure and AWS. I'm loving it, but I should have finished it in May and now I'm still halfway there. I would love to hear your thoughts on this and if you have any tips. Thank you, miguel. Miguel, shout out to you, man. Thanks a lot for writing this and I appreciate you sharing your story on the show.

Speaker 1:

But yeah, this is a common issue. Like how do you finish a tutorial? My hot take don't Unless like you have to do it for some sort of certificate or something like that. My hot take is just don't care if you finish it, if you get the knowledge that you need to then move on to practically applying it. That is the most important thing, in my opinion.

Speaker 1:

I've rarely ever finished a course and I get a lot of value out of the courses that I have bought, or most of them at least. I bought a course on Ember back in the days. I bought courses on data structures and algorithms. I bought courses on giving presentations. Have I finished them all? No, I've never finished really a single course. Have I got a lot of value out of the good ones? Absolutely. My path is generally this get enough information so that I can move forward and then immediately apply it.

Speaker 1:

When I get stuck, I may or may not return back to the tutorial to eventually get to my goal. For example, I have like a very practical goal. When I get a course, like if I want to learn Ember, I'm like okay, by the end of this I should be able to by myself scaffold and like build a small Ember application and understand how the data layer works and like build a small UI. If I could get that out of the first 20 minutes of it, then I'm done and I don't need to go back to it. If it takes me three or five hours to get to it, that's fine too, but I'm not going to sit there and like go through the entire tutorial just to feel like I finished it. I hope that is helpful and also give yourself some grace, because getting a new job is up there with stress is like the same thing as like getting married or like losing a loved one. That's what I read that the amount of stress that you'll feel when starting a job is incredibly high. I've done this enough times in the last few years to know that, yeah, it's super stressful. So give yourself a little bit of grace on that and also try to use that approach and don't get so caught up in like the finish line but like, are you actually learning the thing you set out to learn? And if you don't really know what you're setting out to learn, make that really clear, because if not, you can learn all sorts of stuff about AWS infrastructure and not really get a lot out of it. Again, hope that's helpful and really appreciate the message.

Speaker 1:

Okay, we're gonna get to one last question for today. There's a couple more that I'm gonna answer on next show and hopefully you'll send in some yourself, because I love to answer these. It's some really great questions here. Last one is from Evgeny, and I probably have completely mispronounced that name, but thank you, sir, or ma'am, if you wrote that question. It says I have an idea for a Merge Stack application and want to approach the development process systematically. What are the essential steps I should follow to properly plan and build this project? I love these kind of questions. Specifically, I'm looking for guidance on how to break down the app's complexity and prioritize features planning the data and flow system, architecture before coding, user interaction, design and state management considerations a logical development sequence that keeps me organized and efficient. What framework or methodology would you recommend for tackling this end to end and are there any common pitfalls I should avoid when building with MongoDB Express, react, nodejs? Wow, excellent question, really well thought out, and I've built enough side projects and failed at enough of them to have some pretty strong opinions on this.

Speaker 1:

But I feel like this is one of those topics where you can find a lot of information. My general way of thinking through this is data first and then UI last, or in tandem, but I think when you start with the data layer at least, and you can think through the contracts that you want to have, like, what does the data look like? What is the shape of the data in the back end? How much do you need to store either locally or in a database, or how much do you need to, like, use other APIs? Are all these things available? Your data is almost certainly going to be the bottleneck, so you want to get the data layer down.

Speaker 1:

So, in my opinion, start with the back end and have all that data in a nice shape, so that way, when you have your APIs available and you break this down like, okay, what are the main core features of this? Think of the MVP, the minimally viable product common term. I actually like to use this one minimally usable product. What is the most basic thing a person needs to use this? Do you need authentication? Probably not. Do you need to have, like, some sort of complicated middleware for, like security? Maybe not. So maybe just focus on, like the core CRUD app, features like the create, read, update and delete endpoints that you'll need to support, build those out, look at what kind of data gets returned and then, when you get to the front end, it's not a mystery anymore what you're building.

Speaker 1:

I would probably recommend something like Nextjs, because you can have your back end and your front end all in the same place, co-located, so that when you're making changes on the back end, you can immediately change the front end. I think the one danger of having an Express Node app and a React app is now you have two separate deployment patterns. You have two apps that are living separately. This is also a really good learning experience, but it's not going to be fast. So if you're going for a learning experience, I would do Express Node app on its own and I would do a React Next app or whatever React something else on the front end on its own and deploy them separately. That's going to teach you a lot, but if your goal is just move fast, then maybe just use Nextjs and use the full stack capabilities out of the box.

Speaker 1:

When people say MongoDB, I immediately think is that the best choice? Because, counterintuitively, I think it's actually easier nowadays to start with something like SQL. You could use NeonDB, which has a free tier. You can use Superbase, which has a free tier. This also makes you really think through the data in a way that MongoDB typically lets you just kind of avoid. With MongoDB it's like a key value store. You can stuff data in there. It's like a big object in the cloud. Meanwhile, with the SQL database, you really have to think through okay, what are the relationships I'm going to have? How is the data going to be structured? What type of data am I going to support? The one drawback from that is that you could overthink this or you could get into this cycle of overengineering that and not really moving forward. So that's one of the things that I would think about a lot like how complex is this data? Does it need to be structured? Does it not need to be structured?

Speaker 1:

Use MongoDB, use SQL, use whatever, and then I might even do something like this I like to reverse, kind of estimate what's going to happen. So I'll write my estimates out for each of these features. I'll say, ok, I need to scaffold the Node Express app. That'll take me a day, and I'll usually think in half days or full days for the amount of work, because I really have no clue at this time. So I'm always going to overestimate a little bit. Then, after I actually do that feature, I'll go back and I'll write the hours that it took me to complete that feature. This way, when I come up against new features that are similar, I can basically kind of map that to my estimation.

Speaker 1:

So, for example, if I think you know, making this a backend layer for this particular API endpoint take me about half a day, and I do it and it takes me a full day, like a full eight hour day. I'm like, whoa, that was way more complex. And I thought, ooh, for the next one, I can pretty much guarantee it's going to take around the same amount of time. And now for the next one, I can pretty much guarantee it's gonna take around the same amount of time. And now for the next one I build, I'm like, well, that's gonna take me around eight hours If I build a UI component and I'm like, okay, that was actually really simple. It only took me two hours. Next time I'm gonna make my estimate two hours, then you can start to see like, okay, how much do I really have to do, how long is?

Speaker 1:

You're not just guessing anymore. You have like a record of how long it took you to do similar tasks and you can use that to estimate ongoing and upcoming tasks. You can use something like Trello. If you want to get really fancy, I just use like a sheet of paper or like notes on my computer and I'll just write like what are the things I'm going to build? And then when I wake up and before my kids are up bothering me or whatever, I'll just knock out that one thing. And I'll just knock out that one thing and I'll be like cool, now I'm focused on this thing. Now we have like a chain of things I'm going to do, so I'm not waking up thinking, wait, what am I going to do today? What am I going to do? I could do the UI, I could do the backend, could do this Mongo thing, and now I'm very clear about what I'm going to do each day and that makes it a lot easier to just make forward progress, to see how many weeks or days away am I from actually completing this, and then make decisions on what should I either deprioritize or what can I add in if I need to and again think minimally usable product, all right.

Speaker 1:

Thanks so much for these questions.

Speaker 1:

These were really really good. Again, thanks for these questions. These were really really good questions and I had a couple that I didn't get to in the interest of time, but I'd love to answer more. So, please, if you have questions, send them in, and if they make sense for me to answer on air meaning I think that they will apply to a lot of people I'll answer them. And if I don't answer a question of yours, you can always feel free to DM me on LinkedIn or something like that. If you find me find my big bald head on LinkedIn at Brian Ginny and if you're interested in our coding mentorship program, working directly with me and my partner Zubin, go to parsityio. See you around next time. That'll do it for today's episode of the Develop Yourself podcast. If you're serious about switching careers and becoming a software developer and building complex software and wanna work directly with me and my team, go to parsityio. And if you want more information, feel free to schedule a chat by just clicking the link in the show notes. See you next week.

Podcasts we love

Check out these other fine podcasts recommended by us, not an algorithm.