egghead.io developer chats

Khalal's first language was Java, he learned his it in school. He didn't like coding in school because all they did was learn algorithms and data structures. How many people have completely turned away from this amazing career where you get to build cool things like dad jokes in text messages simply because classes get structured around data structures, algorithms, and Java?

New coders should take a step back before jumping straight to a Bootcamp. Take time to learn on your own to make sure this is what you want to do or what you want to invest in. You'll still be doing a lot of self-lead learning anyway when attending a Bootcamp.

Try to find people who went to the Bootcamp. Don't look on websites like Course Report where almost every Bootcamp is five stars. Get on LinkedIn and find developers who graduated the Bootcamp and talk to them, you'll get honest insights.

ISAs are the only option for most people to attend Bootcamps. You have to be coming from a place of privilege to pay the 18-20 thousand dollars upfront. So instead they'll take 20% of your income for two years. You get a job for $100,000, and now, you have an $18,000 Bootcamp that just went up to $50,000. You got $50,000 worth of debt in 13 weeks. That's what people may get after a year or two of college, or three or four depending on where you go.

Transcript

"Get Comfortable Learning On Your Own With Khalal Walker" Transcript

Quotes

Joel:

"what sort of habits have you developed or you think are important if you want to break into this field, and do it and kind of in a sustainable way?"

Khalal:

"You literally just can't give up or quit. And that sounds like the most cliche thing ever. But it's literally so important, because you're going to hit walls. You're going to struggle. I think, the biggest thing with being a developer is just banging your head against your keyboard for eight hours of the day. And the last hour, you just see the light and you just keep finding different ways until something works."

Khalal:

"So, I take that with learning how to code. In the beginning, you're going to mess up on syntax. You're going to forget a semi-colon. You're going to miss a quote. And some of these things may really, really bother you. But if you keep at it, these things will become second nature. And then, you'll have new struggles. Because when you have new successes, you move on to new problems."

Khalal:

"And so, as long as you know that in this industry, it's always... Things are going to get easier, but you're always going to be learning something new. You're always going to be learning. You're always going to be growing and you just have to have the willingness to take on that challenge every single day."

Khalal Walker

• Twitter
• Website
• Github

Joel Hooks

• Twitter
• Website

To executives, new features mean more money, but even if you had terrific features, they wouldn't be worth a thing if they only worked half the time. Reliability isn't something you want to put off until later after the project has grown, it will save you a lot of time and money if you factor it in from day one. Everyone has adapted to a speedy internet these days. Users leave if the site is taking more than even a few seconds to load.

It's easy to get overly focused on features while losing the context of the overall application. The first and foremost solid you can do future you is to keep things as simple as possible. Never get overly complicated, that's where you run into scaling troubles. Complexity also causes significant headaches when bringing other people on.

In addition to keeping complexity low, make sure documentation gets written and that it's kept up to date. A solution that Molly's company has put in place to keep the docs fresh is to give every document an expiration date three months out from when it gets written. When someone references the docs, they check if it's past the expiration date, if it is they go through and make sure that the information is still current, and afterward extending the expiration date another three months.

Transcript

"Build Performant And Reliable Applications With Molly Struve" Transcript

Quotes

"To me, a site reliability engineer is a software engineer, but with their focus on performance and reliability."

"So, it's a dev, but they've got a little bit of something extra in there that just helps them kind of step back and look at the whole system and ensure that it's performing and reliable."

"There's only so much you can just attribute to the black box. Sometimes you actually got to go in there and figure out what's going on."

"You can have all the great features in the world, but if they're only working 50% of the time, none of your clients are going to be happy."

"A lot of times, if you're just focused on just the feature you're building, you'll lose the context of the overall application."

Resources

• Making On-Call Not Suck
• What It Means To Be A Site Reliability Engineer
• Scaling Elasticsearch Part 1: How to Speed Up Indexing
• Scaling Elasticsearch Part 2: How to Speed Up Search

Molly Struve

• Twitter
• Github
• Dev.to
• LinkedIn
• Website

Joel Hooks

• Twitter
• Website

Marisa Morby is a professional product manager. A common question she gets is "what's the difference between a product manager and a project manager?" There's a lot of overlap, but the difference is a product manager has to understand what needs to get done and why and be able to communicate that, and the project manager makes sure that everything stays on the rails and results in a cohesive product.

Many teams put significant of focus on user outcomes. A user outcome is the ultimate goal of the user. It's what they need to happen. If we don't know what the user needs to happen, we'll end up focusing on the wrong thing.

To figure out what a user wants user research needs to get conducted. No, you don't have to break out the lab coat. Research doesn't have to be so rigid. Just have conversations with your users and try to gain an understanding of their wants, needs, and frustrations. Make sure that you don't make assumptions about your user's needs. Ask questions that might seem painfully obvious to you

Marisa also talks about working with all-remote team. We live in an amazing day and age that allows us to do our work wherever we want, but there are challenges we have to overcome for everyone to still be productive. We have lizard brains that make it challenging to build trust with people whose faces we never see. Regular video meetings that give some space for non-work conversations are essential in building that trust with people. Meeting people in person also has a substantial positive impact on communication; it gives you a lot of context with people's mannerisms!

Transcript

"Putting Emphasis on User Outcomes with Marisa Morby" Transcript

Resources

• Just Enough Research

Marisa Morby

• Twitter
• Website

Joel Hooks

• Twitter
• Website

When you are a consultant, you can't just learn a framework and then choose a place to work that uses it. Your clients will have their own needs and constraints that you're going to have to adapt to serve your client well.

The constant learning can feel like a freefall. Constantly feeling dumb is panic-inducing. There's this trough of despair in software, where you swing between feeling like a genius and then going right back to despair.

We can't just learn, but we have to learn well. It's critical to retain what you learned. Keep a developer journal, start a blog for yourself, discuss what you learned in a study group, etc. The less you have to relearn things, the less time you'll be spending in the trough of despair.

The dreaded technical interview tends to have the problem of not testing you on anything that you should be learning. You have to spend your time cramming and hoping that the interviewer gives you problems that are still fresh in your mind. A one size fits all solution doesn't work and doesn't end up being objective. Candidates should get the opportunity to show off their skill and what they already know instead of figuring out what they don't know.

Transcript

"Escaping the Software Trough of Despair - With Laurie Barth" Transcript

Laurie Barth

• Twitter
• Website

Joel Hooks

• Twitter
• Website

Perhaps the most important skill that a software developer can have is the ability to ask good questions. Questions will lead to the answers that you actually need. Formulating good questions is key. Often, you'll find that you answered your own question in the process of forming it.

Mentorships are a great learning and growth opportunity but it's important that you respect the person that you desire mentorship from. Don't just take up their time by asking questions regularly without being upfront about the relationship that you are wanting. It's also important that when you do ask your mentor questions that you continue to respect their time by making sure that your question is good and well researched.

Included in the links below are a couple of articles on how you can take your questions game to the next level. Try to read them before asking your next question!

Resources

• Stack Overflow - How do I ask a good question?
• Julia Evans - How to ask a good question

Jacky Alciné

• Twitter
• Website

Joel Hooks

• Twitter
• Website