DEV Community: Ladybug Podcast

7 Technologies I'm Excited about in 2021

Ali Spittel — Mon, 11 Jan 2021 16:18:17 +0000

It's a new year, and that presents an opportunity to refocus on learning. In this post, I want to discuss some of the technologies I'm excited about and will be investing my learning time in this year.

Meta-frameworks

It seems like one layer of framework is no longer enough! Next.js and the N**t family of frameworks (including Nuxt and Nest) provides such an amazing developer experience. Remix also has some hype behind it. Gatsby has also been a force in the industry over the past few years. I love working with these meta-frameworks and really think they will become even bigger over the next few years.

Low Code

Code is great, but the less code we can write to create useful products the better. Code is expensive, both to create and maintain. I'm so excited about the growing low-code trend that will allow quicker and easier application development. I spent the last few months of 2020 working on the Amplify Admin UI, which allows users to write a basic backend in clicks and then extend it with code. Tools like this, and frontend toolkits, will significantly lower the difficulty of building scalable and maintainable applications.

Server-side Rendering

Right before the holidays, the React core team released initial research on React Server Components, which follows a larger trend that many of the aforementioned meta-frameworks follow -- server-side rendering. This isn't a new trend at all -- I started programming during the use Rails for everything era where nearly every framework used a templating language to plug variables into HTML. But, extending SSR to allow developers to use modern tooling is big and has huge performance implications for the web.

The Cloud

This one has been around for a while, but it's something I'm just learning more about now. I remember manually deploying my apps on servers early in my career -- it was a lot of work and didn't scale at all. I'm just dipping my toes in the water with Cloud computing and learning about AWS outside of Amplify, but it's really interesting and a valuable skill to have. I want to dive a lot deeper here this year.

Machine Learning/Artificial Intelligence

A few years ago, I was seriously considering getting my master's degree in AI/ML -- I love both statistics and programming. My career went in a different direction, but I still really want to learn more in these areas. They seem to be the basis of so many new forefronts in the industry, and it seems like that will be true for a long time.

New Frameworks

There are always new frameworks on the horizon, both on the front and backend. I am at a point in my career where I'm less interested in learning everything that comes out, and I'm pretty comfortable with my ability to learn new frameworks when they come out. That being said, I'm excited about the newer performance-focused family of frontend frameworks. Svelte seems to be here to stay -- I'd prefer a framework that's heavier on functional programming tenets, but I think it's time to spend sometime really diving into it. It's also cool to see Hyperapp still growing -- I love using it.

Decentralization of Tech Workers

This is a very different trend than the others on the list, but 2020 necessitated a big shift to remote work. I personally would love to return to working in an office someday, but I think that the movement to allow more remote work is an overall positive. Tooling and solutions will get better, and tech workers will be able to move outside of the typical "tech cities."

Conclusion

For this week's Ladybug podcast, we talked about the 21 trends in web development we are most excited about this year. Give it a listen, we'd love to hear what you're most excited about via Twitter.

5 Things You Need To Become A Senior Developer

Emma Bostian ✨ — Tue, 29 Sep 2020 08:09:01 +0000

In this week's Ladybug Podcast episode we chatted about the skills it takes to level up from a junior to a senior developer.

Junior to Senior Developer: Career Progression for Programmers

Ladybug Podcast

Your browser does not support the audio element.

1x initializing... ×

Before jumping into this topic I want to preface this with the fact that every single employer has different qualifications for what constitutes a senior developer, and just because you're a senior developer at one company doesn't necessarily mean you'll be a senior developer at another company.

Nothing frustrates me more than seeing "I became a senior developer in six months after joining the tech industry" blog posts. Not only do they instill a sense of inferiority in developers who take longer than six months, but there are many factors that go into a promotion.

Having a computer science degree, having a social media following, having a backlog of content to showcase your skills, and having excess time outside of your 9–5 job are all examples of privilege that facilitate your ability to become a senior developer.

As an industry, we must stop perpetuating this idea that if you hustle hard enough, it only takes "X" months to become a senior developer. It may take you sixth months, or it may take you six years. Don't let anyone influence your idea of how long it should take you to achieve a promotion.

Talk with your manager. Find out which boxes you need to check off before becoming a senior developer, and block out the noise that is present on social media.

But despite each company having their own definition of what it takes to become a senior developer, there are a few characteristics which all senior developer exhibit. Today we'll take a look at five of these characteristics which will jumpstart your progress towards becoming a senior developer.

Autonomy

Independence or freedom.

One of the primary qualities of a senior developer is having autonomy, or being independent. As a senior developer, you're expected to deliver work without needing much assistance. This doesn't mean you can't ask questions(in fact, you should ask questions), but it means that if you're given a task you're able to construct a solution and you know what questions to ask if you get stuck.

Autonomy is one of the characteristics I have struggled with for several years. Early on in my programming career, I felt lost. It's absurdly nerve-wracking to pair with senior team members and watch them seamlessly navigate their way through the code. How do they know where to start? How did they know this bug was originating in this file? How did they know to ask this specific person for help?

I'll let you in on a secret: all of these questions can be answered with "it just takes time and experience." It's safe to bet that your team members also felt this impending sense of impostor syndrome when they joined the company. And no matter how much programming experience you have, joining a new company with a new tech stack and new colleagues will always require time to acclimate.

When I joined Spotify this July, my manager and colleagues told me it would take at least six months to feel self-sufficient and productive. It's important to set appropriate and realistic expectations for yourself when joining a new company (especially as an entry-level developer).

But if your goal is to be promoted to a senior developer role, you must start exhibiting autonomy with your work tasks.

Initiative

The power or opportunity to act or take charge before others do.

Before promoting you to a senior developer, your manager wants to see that you take the initiative to find challenging tasks and help team members in need.

If you finish your task early, actively seek out other tasks or bugs that you can work on. If you see a team member struggling with their task, offer your assistance. If you see additional areas outside of your team to get involved, like helping to plan an internal conference or mentor a new team member, go for it!

You should also keep a list of your accomplishments. This will make it easier to reach the next level as you won't be scrambling to remember what you accomplished the past year.

Don't wait around for someone to give you work: actively seek out new and challenging work and write down your accomplishments.

Communication

The imparting or exchanging of information by speaking, writing or using some other medium.

Ahh "soft skills", every programmer's favorite area to excel in. I personally don't understand why "soft skills" are taught as a lesser skill for programmers. The higher up the ladder you climb, the more important your communication skills become.

The ability to write and speak effectively has many benefits. Whether it's impressing your colleagues during a technical presentation or writing up an internal blog post, communication is key.

To become a senior developer you must be good at explaining not just what you're doing, but why. This is especially important when mentoring more junior team members.

Understanding and conveying the why behind tasks will solidify the skills you're learning as well as the skills you're teaching.

Problem Solving

The process of finding solutions to difficult or complex issues.

Problem solving is an undervalued skill for all developers because it's not necessarily a skill developers are taught in bootcamp or degree programs. The ability to solve complex problems will arise throughout your career and will scale in complexity the longer you spend in the industry.

Learning how to problem solve early-on in your career will put you at an advantage when looking to achieve a promotion. I won't delve into the specifics of problem solving in this post but let's take a look at the general process.

First, you must identify and clarify the problem. Problems are often more nuanced than we initially perceive. What are you trying to solve? Are there dependent sub-problems that must be solved along the way?

Once you understand the problem you should list the possible solutions. What are the different ways you can solve the problem?

Now you're ready to evaluate your options. What benefits and drawbacks does each solution present? Are there performance implications for a solution? What about accessibility concerns?

You're now ready to select an option and build it. If you realize along the way that your solution isn't technically feasible or you encounter an unforeseen issue, you can always go back to step three and reevaluate your options.

Lastly, you can document your solution so that your team members can understand why you selected the solution you did.

Problem solving is an invaluable skill and it's undeniably one you'll need to become a senior developer.

Mentorship

A period of time during which a person receives guidance from a mentor.

One of the biggest factors in becoming a senior developer is the ability to mentor another team member. Mentorship is often though of as a formal relationship wherein the mentor has all the answers to the mentee's questions. This is an archaic definition of mentorship.

Mentorship is a symbiotic relationship where both parties are gaining knowledge. While most of the information will flow from the mentor to the mentee, the mentor should also be open to learning from their counterparts.

Mentors also shouldn't give out answers to the mentees' questions. Asking a question and receiving an answer has short-term benefits. Instead, a mentor's job is to guide the mentee towards the solution. By providing boundaries for your mentee to ideate and learn, their problem solving skills and confidence will grow more quickly.

As a senior developer you're expected to mentor more junior team members. It doesn't need to be formal (although a formal mentorship will serve your promotion more easily than an informal mentorship) but the act of supporting another team member will make strides towards your desired promotion.

The biggest piece of advice I can give to those looking to level up from a junior developer to a senior developer is to exhibit the characteristics of a senior developer before you have the title. If your company provides a chart with senior developer qualifications, make sure you're achieving the senior developer requirements before applying for a promotion.

And lastly, be patient. Being promoted to a senior developer can take months or years so don't compare yourself to other developers outside of your company.

Thoughts on Being a Digital Nomad

Ali Spittel — Fri, 18 Sep 2020 17:15:23 +0000

Almost two years ago, I donated almost everything I owned and left DC. I was at a job that wasn't the right fit for me, and I didn't know my future. I decided that rather than signing a new lease, I'd instead mostly live at tech conferences for the summer and crash at my parents' in between, and then start living out of AirBnBs in the Fall. I ended up retiring from the digital nomad lifestyle in order to work in an office gain (which started 3 days before the COVID shutdown 🤦‍♀️). That being said, I think this is a pretty unique experience, but more people may be able to do the same as remote work becomes more popular and (hopefully) the pandemic starts to subside. So, I wanted to write down my thoughts and advice on the experience.

The Logistics

I personally chose to live out of AirBnBs. The longer you book a place, the more discount you get normally. So, I'd book a place for a month at a time. The cost for AirBnB pluses ended up being less than my DC rent most months. The van life idea is so appealing to me, but the mechanical knowledge needed and the potential lack of internet intimidates me. I also personally stayed in the United States because of my dog, I didn't want to quarantine her which you need to do with most international countries.

I travelled from city to city in my car, which was super nice. I was able to visit a bunch of sites nearby cities instead of just staying downtown, which I may have had to without a car.

I chose cities by expense, activities available, and their proximity to National Parks. My biggest bucket list item is to visit all of the National Parks, so this very much helped in that goal. I loved being able to experience different areas, taste test different restaurants, and to never get bored of my surroundings. I also was using it as a way to vet cities before settling down -- I didn't know where I wanted to move longterm, so this was a way of trying out different cities.

Taxes can get so complicated if you're moving around a bunch, especially if you move internationally or are self-employed (or just have side gigs like me). I hired an accountant who specializes in digital nomads, and it's such a weight off my chest. Here is his site in case you're interested.

The Hard Parts

There were two really difficult attributes of travel for me: the first was loneliness, the second was the lack of a routine. It's pretty tough to get to know people when you aren't staying in a city for long. Something I would probably prioritize if I did this again would be to go to cities with a big tech scene so I could go to meetups and potentially speak at them. I was also single at the time, so doing this with a partner or a family would probably help in that regard. As far as having a routine, I was changing where I lived every month. So it's difficult to get too settled. Part of that was nice, I would go on hikes every morning with my dog in Asheville and would go to a neighborhood coffee shop in Nashville. But, I definitely missed having a set workday schedule.

Conclusion

Overall, it's an experience I really enjoyed and would highly recommend if your work and life situations allow it. I would probably go back to being a digital nomad once the country re-opens and my partner was able to work remote. If you're interested in moving internationally, check out this Ladybug episode. Please Tweet any questions to me, I'd love to help out!

Why We're Not Publishing A New Episode This Week

Emma Bostian ✨ — Mon, 01 Jun 2020 06:24:12 +0000

Dear Ladybug Podcast friends,

We’re writing today to inform you that we won’t be publishing an episode this week. We strongly believe that the death of George Floyd and the protests happening across the country are of utmost importance. We are taking this week to remember not only Mr. Floyd but all Black people who have been unjustly killed.

We have donated our sponsorship profits from the next episode in support of Campaign Zero. Donating is just one way we can help the Black community and we encourage all of our listeners, if you’re financially able, to do the same.

We’re taking this week to educate ourselves about anti-racism and hope you will too.

Being Antiracist
Justice for George Floyd: What to Read and What You Can Do
Anti-Racism Resources For White People
Ain’t I a Woman: Black Women and Feminism by bell hooks
I Know Why the Caged Bird Sings by Maya Angelou
So You Want To Talk About Race by Ijeomo Oluo
How To Be An Antiracist by Ibram X. Kendi

Racism is not a “United States” issue: it’s a world issue. We all have a responsibility to stand against racism and support the Black community. Our Black friends and colleagues are hurting. Are you listening?

// Detect dark theme var iframe = document.getElementById('tweet-1266558160338325504-670'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1266558160338325504&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1266246773812588545-778'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1266246773812588545&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1266893273039159296-728'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1266893273039159296&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1266808675169009665-640'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1266808675169009665&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1266421245140221952-855'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1266421245140221952&theme=dark" }

Five Tips For Coding Interviews

Emma Bostian ✨ — Thu, 27 Feb 2020 07:47:08 +0000

Technical interviews are scary; the thought of having to write code on a whiteboard is anxiety-inducing.

Throughout our research and years in the industry we've put together some tips for helping you during your coding challenges.

Whether you're frontend or backend, knowing these tips, and practicing them before your interview, will ensure you put your best foot forward and hopefully land a job offer!

Do you have any additional tips? Leave them in the comments below!

Communication is key in any interview but in technical interviews it's imperative you explain your thought process.

Your interviewer wants you to succeed, but in order to help you, and potentially give you hints, they need to know your thought process.

If you need a minute to think, tell your interviewer! There's no shame in saying "I just need a second to think."

But if you're internally reasoning between two solutions, talk it out.

For example, if you're trying to decide the best method of sorting an array of integers from lowest to highest.

"I have two ideas in my mind. The first requires brute forcing the solution where we would compare every element in the index to its neighbor and if the integer on the right is lower in value than the integer on the left, swap them.

But this isn't optimal as it would require O(n^2) checks to ensure everything is sorted. I know merge sort is a more optimized sorting algorithm with a worst-case runtime of O(n log n), however I'm a bit unsure how to code that."

Stating your thoughts out loud will allow the interviewer to guide you and is often a chance to showcase your knowledge about data structures and algorithms.

In almost every case the question you receive for a coding challenge will have a few holes in it. The interviewer won't give you all of the information up front because they want to see you deductive reasoning and problem solving skills.

Thus it's important to think through all of the key information you'll need to solve the problem, and ask if something is unclear.

If you receive a question and you have no idea where to start, don't panic; we've all had this moment!

First, think about the information you have. What pieces of information do you need to solve this problem?

Second, what are you missing? In the previous tip we mentioned asking clarifying questions. This is great practice if you're stuck or need a moment.

Next, at the core of the problem, how would you brute-force this answer? In tip one we had the example problem of sorting an array of integers from lowest to highest.

The brute force method would be bubble sort where we're comparing every integer against every other integer and swapping if needed. And even though this isn't an optimized solution, getting the brute-force solution up on a whiteboard will allow you to refactor to something more optimal.

Is it possible to remove one of the nested for-loops in our sorting algorithm? Perhaps we can refactor to use a divide and conquer algorithm like merge sort!

A brute-force solution is better than no solution.

There will inevitably come a time when you simply don't know the answer to a question.

For example if you're asked "what's the difference between == and ===?" and you simply have no idea, just tell the interviewer!

You might say: "I'm not positive but if I had to make an educated guess I would say..."

This indicates that you're self-aware and honest but you're still willing to take a guess.

If you simply BS the answer and pretend you know what you're talking about, this indicates that you're not a truthful person and you likely won't receive a job offer.

Additionally if you ever receive a coding challenge question that you've seen the solution for or have already gotten in a past interview, be honest about it.

Your interviewer will be able to tell if you're regurgitating a memorized answer so it's best to be transparent. Plus your interviewer should appreciate your honesty.

Once you have a solution down, take ten minutes to test it. What are the obvious use cases? What are the corner cases? You'll likely find holes in your solution and can go back and refine them.

If you spit out an answer without testing it, you probably won't receive a job offer.

For example if you're asked to write an algorithm which determines whether there is a loop (or a broken edge) in a binary tree, think about the possible use cases.

Does your algorithm work if there are no nodes in the tree?
How about if there is only a root node
What if there is no broken edge/loop?
What if the broken edge is on the last node in the tree (bottom right)?
What if it's in the first level?

These questions will allow you to refine your solution. It might help you determine whether you want to use depth-first search over breadth-first search.

Testing is important! So don't forget it!

Keeping these five tips in mind will help calm your anxiety about coding interviews. Focus on solving the problem at hand while communicating clearly. You'll receive a job offer in no time!

You can check out our full episode for more tips!

DISCUSS: Technical Interview Horror Stories

Emma Bostian ✨ — Mon, 24 Feb 2020 13:43:45 +0000

In this week's Ladybug Podcast episode we discussed the frontend technical interview process.

Technical interviews are terrifying, and I'm sure we've all had bad experiences. Hopefully talking about why our experiences were not so great can help educate the tech ecosystem about how to give a great technical interview!

I'll go first.

Years ago, probably in 2016, I was interviewing with an overseas company. It was a startup and it was a product I genuinely liked. I had a great talk with the recruiter but decided to pull out of the interview process as I was unprepared to move abroad at the time.

I truly had a great experience with the recruiter though so I wanted to stay in touch.

Fast forward two years later, I re-connected with the same interviewer except this time was... not so great.

He called me at 6 am my time (due to time zone differences), and proceeded to badger me with technical interview questions like "whats the difference between const and let?", which I explained correctly but he made me feel like I gave the wrong answer.

I was duly unprepared for the technical interview questions, and explicitly stated as much, yet he kept throwing them at me.

Not only that, but the recruiter seemed like a different person.

The first time we interviewed he was SUPER down-to-earth and made me feel special. This time around he started the conversation with "have we met before" which threw me because A) we spent a lot of time communicating and you made me feel like you remembered me through email communication and B) you clearly didn't take two minutes to check if we had previously interviewed.

He even was answering Slack messages during our interview because "my teammate is having Zoom issues and I'm the only one who knows how to fix them."

Horribly unprofessional.

I left the interview and told him "thanks but no thanks."

He just reached back out to me (a year later) and needless to say I won't be following up with him.

What's your technical interview horror story? Leave it below!

Six Data Structures To Help You Ace Your Technical Interview

Emma Bostian ✨ — Fri, 07 Feb 2020 19:17:10 +0000

It's a new year which means many of us are searching for our next role. It's no secret technical interviews are hard, so we've compiled (hehe) a list of six data structures you should be comfortable with in 2020.

If you're going through a technical interview, these are must-knows.

We chatted about data structures & algorithms on this week's Ladybug Podcast so I recommend checking that out if you haven't already! We'll cover a lot more than the six data structures here!

Since these data structures have been written about until the cows come home, here are some of our favorite resources for learning them!

Good luck, devs!

🐞 Arrays

Arrays are the bread and butter of data structures. They are list-like data structures which allow you to keep track of elements. These elements can be reference types, like objects or other arrays, or primitives, like numbers or strings.

The length of an array in JavaScript is not fixed, meaning you can add values to the array easily.

🐞 Linked Lists

Linked lists are a data structure which isn't built-in to JavaScript, but can be created out of other JavaScript data structures.

A linked list represents a series of nodes where each node points to the next node in the list.

There are also doubly-linked lists where each node also points to the previous node in the list.

This structure uses the LIFO, or last-in-first-out, method where nodes are added to and deleted from the same end.

🐞 Stacks

A stack is not a built-in JavaScript data structure but can be built using arrays.

A stack is based on the LIFO, or last-in-first-out, concept. A stack is like a pile (or stack) of books where you have to take the top book off before you can get to the bottom book (unless you're a savage).

Stacks allow for constant time adding and removing of an item but unfortunately they don't provide constant-time access to the nth item in the stack.

🐞 Queues

A queue is similar to a stack, but uses the FIFO, or first-in-first-out, method. You can think of a queue like a line of people waiting to buy a movie ticket. The person who has been in line the longest (first) is the first to be serviced.

Emma's 'Stacks vs. Queues in JavaScript' blog post

🐞 Binary Trees

Binary trees are a data structure consisting of a series of nodes where each node can have a maximum of two child nodes as well as a value. The root is the top node in the tree structure and doesn't have a parent node.

A binary search tree is another type of binary tree where all node values are distinct, every parent node has a left child whose value is less than it and a right child whose value is greater than it.

🐞 Graphs

Graphs are a data structure comprised of nodes with edges. If a graph is directed, that means each edge has a direction associated with it (like a one-way street). In contrast, undirected doesn't have associated edge directions.

You might have a graph of people (purple) and movies (green) where each person can have several favorite movies but movies don't have a favorite person.

What are some other resources you like for learning data structures and algorithms?!

Leave yours below! 👇

Why Blogging is Awesome

Ali Spittel — Wed, 18 Sep 2019 17:07:14 +0000

If you're here on DEV, you probably have some interest in blogging -- or at least reading other people's blogs! In a recent Ladybug Podcast episode, we talked about our reasons for blogging.

Emma

Emma Bostian ✨Follow

Software Engineer, bibliophile, & cat mom

I started blogging as a means to take notes on things that I was learning as I was learning them. That way, I had a reference sheet that I could go back to and refer to things. For example, a regex cheat sheet. That was one of the things that I made that I could go back and refer to as time went on. I also use it as a way to teach myself, because I’m a huge proponent of the fact that if you can relay your thoughts about a topic well enough to create a blog post or create an online video or whatnot, then you’ve sufficiently learned the base level knowledge for that skill. It’s a great way to reinforce what you’ve learned.

So, I started blogging as a resource for myself. But, there are many reasons why you should blog. You can also start to blog, in order to build yourself a portfolio. It's a great resource for employers to look through if you’re applying for jobs or other opportunities.

Ali

Ali SpittelFollow

Passionate about education, Python, and JavaScript

My biggest reason is for my past self. When I was starting to code, I didn’t feel confident, and I didn’t feel like I belonged, which we talked about a little bit in our first episode. I didn’t feel like I understood the material,so I started writing resources that my past self would have found really helpful.

It’s a form of reshaping that experience. Then, other people started finding them helpful as well. For me, teaching is my passion, and blogging is another form of that. So, I blog for myself first and to write stuff that I would have benefited from in the past. But secondarily, and a really great part of it now, is that it’s helping other people learn how to code and making it easier for the people coming after me.

In-person, you can only teach a certain number of people at a time, even a big talk only usually reaches a couple of thousand people, maybe. Whereas I have singular blog posts that have 100,000 reads. That’s a huge amount of people compared to the people that you’ve taught in person. Teaching in person has like a bigger impact on those people that are there. But, this has a smaller impact on a huge amount of people, which is awesome, too

Kelly

Kelly VaughnFollow

Entrepreneur, agency owner, frontend developer

So on the opposite side of where Ali says that she blogs for her past self, I blog for my future self, for two reasons. First, I forget everything that I did yesterday. I find my own resources to be a resource for myself when I forget something. Two, in my career, I need to be a subject matter expert. I can use my own blog posts as resources to send to potential clients and to talk about in our newsletter that we send out for my agency. Som my blog posts can serve not only as a resource for potential clients but also by showing my expertise, we’ve actually signed on new clients because they read something in our blog that shows that we know what we’re talking about.

Learn more

We talked way more in-depth about our experiences blogging, as well as actionable advice for growing your blog on the Ladybug Podcast. You can listen to the full episode wherever you listen to podcasts!

Three Tips for balancing side projects and a full-time job

Ali Spittel — Mon, 26 Aug 2019 12:05:56 +0000

Side projects are an excellent way to express yourself creatively and build up your tech stack. But how do you find time to work on your side project when you have a full-time job and other responsibilities at home? In a recent episode of the Ladybug Podcast, we discussed some useful strategies for giving your side projects the attention they deserve.

Prioritize

Ask yourself some important questions: what needs to be done right now and what can wait. Also, what do you actually want to do? Most of these side projects are completely optional, you get to decide if you want to spend your time on them or not. You need to find your why with your side projects, why are you passionate about them, and why do you want to do them. You don't need to do everything, find the things you love doing and focus on them. It may not even feel like work if you really love it!

When you’re thinking about these projects, you also may want to think about future time commitments for them. When you're starting things, they're shiny and new and fun. But will you still care about the project a year in the future? What is the time commitment still, then? How much time do you have consistently to spend on these it? These questions can really help you decide what is important to prioritize and to decide what is actually realistic for you to take on. Is it just something that’s super one-off that you can do in a night or two? Or is it something that’s bigger that you still want to be working on in a year?

Focus on Building Habits

It may help to have your side projects should align with your ultimate career goals. "Atomic Habits" discusses the idea of not having finite goals, and not focusing on one finite point in time as your goal. Instead, position yourself on a trajectory to reach an outcome. For example, if I want to have a very successful soccer team, and I’m a soccer coach, my goal shouldn’t be to win 10 games, my goal should be to hire or to hire to have the best players on the team and build a good team dynamic. That’s pointing out a trajectory to succeed. If focusing on winning 10 games, you’re not positioning yourself in any sort of way to be successful.

Make sure that you know your why, and that you’re putting yourself in the right direction. So, if you want to become a senior engineer, blog about code instead of knitting cat sweaters. Position yourself in such a way that you’re always working towards a goal.

Do what works for you

Productivity systems are very different for everyone. Some people block off work times on their calendar, other people do whatever they feel like at the time, other people set three goals per day. Try different systems and see what works for you and makes you the most productive.

In addition, different people prioritize different things, and they also need different things. Some people need more social time, other people need more rest time. That is totally okay! Do what's best for you, and don't put a ton of pressure on yourself to always be working. Everyone needs downtime.

Learn More

We gave a ton more advice for balancing side projects, and we also did a deep dive into what we're working on in our episode Side Project Balancing Act.

The Ladybug Crew's Learn to Code Stories

Ali Spittel — Wed, 21 Aug 2019 11:55:07 +0000

There are several different ways you can learn how to code. In a recent Ladybug episode, we discussed computer science degrees, bootcamps, and self-directed learning. Each has benefits and have brought a lot of people into the world of programming. Each also has challenges. All four of us have had unique paths to programming, so here are our stories.

Emma's Story

[Deleted User]

I was a biology major in college and then quickly realized that I was terrible at it. So, I switched to actuarial science where I took an intro to computer science course and totally fell in love with binary, hexadecimal, and octal systems. The rest is really history. I studied computer science and my first language was Java. I was a little bit of a late bloomer but I thoroughly enjoy it.

Kelly's Story

Kelly VaughnFollow

Entrepreneur, agency owner, frontend developer

I got started when I was 11 years old. I wanted to build my own community on Neopets. If you’re not familiar with what Neopets is, it’s this Web site where you can have your own virtual pet and you can feed it and play games. You can have your own communities and all kinds of stuff.

I really wanted to build my own community and customize it. But you need to know how to code to do that. So, I asked my dad for an HTML book and my first book was HTML goodies. I thought it was awesome and a lot of fun.

Fast forward to high school, and I took AP Computer Science. My first language in high school was Java, and I was so bad at it that I needed a tutor just to pass the class. I was like "I’m never going to do this ever." But, you know, obviously, 17 years later and I’m very clearly still coding, so something eventually clicked but it wasn’t Java.

Lindsey's Story

Lindsey KopaczFollow

I'm a self-taught Front End & JS Dev and professional learner with accessibility expertise. I'm passionate about breaking down concepts into relatable concepts, making it more approachable.

I was an admin assistant really aimlessly going through my job; I was miserable. My dad suggested coding to me and was like "worst case scenario if you hate it you could try something else."

So, he bought me an ”Introduction to Drupal” book and – quite frankly, I do not recommend starting out as Drupal when you’re learning to code but that’s how I did. I just continue learning, continue working in the mornings before work. Then I got my first Drupal job.

A few years into that I started learning about accessibility. Then a year or so after that I started learning about React and VueJS and I’m now a React developer and the rest is kind of history.

Ali's Story

Ali SpittelFollow

Passionate about education, Python, and JavaScript

I learned to code when I was a sophomore in college. I had no idea what coding even was, but I had an extra course block available. I decided to sign up for it because people kept telling me, ”It’s a good thing to learn and it’ll help you no matter what.”

I honestly thought that I was going to be learning how to format Word documents or something like that - I had no idea what code was. But, I was instead writing Python. It was super fun: we were building games. I just thought it was magical how you could put stuff together and have a program come out of it.

I completely reconfigured my schedule and was like I’m going to double major in computer science, this is my future. So, I started my second class which was in C++ and it was a super intense "Data Structures and Algorithms" class, which was also a weed out class. I was pulling all-nighters and working so hard in that class just to understand it. I did come out of it with a good grade. I thought "if I have to work this hard for it, it means that I’m not good enough at it. This is really just not for me."

Then when I was a Junior in college I had an internship doing mostly Excel data analysis type work, and I figured out that I could automate a lot of my own job using the Python skills that I had. So, from there, I got a software engineering internship and transitioned to working full time in code.

Learn More

You can listen to the whole podcast episode where we discussed our thoughts on bootcamps, computer science degrees, and self-directed learning as well as advice for everyone in the midst of their journies.

How I became an Entrepreneur

Kelly Vaughn — Mon, 19 Aug 2019 12:40:14 +0000

This week on the Ladybug Podcast, we talked about my advice for becoming an entrepreneur. I also wanted to share my story of how I became a freelancer and eventually an agency owner.

My Entrepreneurship Story

I taught myself to code when I was 11. I took on my first freelance client when I was 14 years old. My dad's friend needed a website, and I was the only person who knew how to build websites. I got paid a t-shirt. I know, great deal. And beyond that, it's not even my size; it's my dad's size. But hey, I do still have the shirt.

I continued to freelance through high school, undergrad, and grad school. The real reason why I started freelancing? College is expensive. I needed money to pay for my tuition and living expenses.

In 2015, I finished grad school and started a fellowship. About 8 months later I bailed and started freelancing full time. It turns out I'm not really good at working for anybody but myself.

I found my first clients on Twitter. (Side note: social media is a really great resource for getting your first clients.) I was following a friend of mine who was already freelancing. He tweeted, "Hey, I have too much work. Does anybody want to take on some freelance projects?", and I'm like, "Me, please, I'm poor." So we connected and it's actually how I started really getting a lot more clients.

The hardest one, the hardest client to get is your first client. Once you're past that hurdle, and you have some work in your portfolio from actually paid clients, and you have a testimonial, then things just kind of take off from there.

That same person who passed freelance work onto me also gave me my first project on Shopify. I immediately loved the structure of building a Shopify theme and how all the template files separate into a really, really readable format. Liquid, a Ruby-based language that Shopify uses to communicate with their backend, was really easy to learn real fast, so that was a major plus as well.

At that point, I was focusing about half my time on Shopify, and half my time on WordPress, which really require two separate brains. It's super difficult going back and forth. I was popping PHP into Shopify themes, and obviously, it would yell at me. So finally, I decided to just completely cut out WordPress altogether and put all my eggs in the Shopify basket.

Another interesting fact... I actually did not originally want to start an agency; I wanted to just do full-time freelancing. It's kind of funny, back in 2016, MailChimp did an interview with me about it. In the interview, I said, "I like having this hybrid model of just working with other freelancers." I didn't want to form an actual agency; I felt it'd be overkill.

Maybe a month or two after that, I completely changed my mind. I found myself hitting a wall on the size of clients I could bring on with just being myself, especially when I wanted to work with larger businesses. Kelly Vaughn Creative sounded like I was just a one-woman show, even though I had other people doing the design or SEO or content strategy, whatever it might be. So, that's why I made the switch from freelancing to actually starting the agency. I wanted to form an actual team and sound like a more of a legitimate company.

Listen to the full episode

You can listen to the full episode all about my entrepreneurial journey wherever you listen to podcasts!

Flexbox Cheat Sheets

Ali Spittel — Thu, 15 Aug 2019 13:53:16 +0000

In our first CSS episode, we discussed the foundations. In this special bonus episode, we continued the conversation by covering some more in-depth areas of CSS, like layouts with Grid and Flexbox, animations, media queries, naming conventions, pre-processors, and frameworks.

Here are some Flexbox cheat sheets to go along with the episode! 🐞

Shoutout to Emma for making these!

[Deleted User]

Align Items

Flex Direction and Flex Wrap

Flex Items

Justify Content

You can also check out our CSS cheat sheets here:

CSS Cheat Sheets!

Ali Spittel for Ladybug Podcast ・ Aug 12 '19

#css

You can listen to the full episode wherever you listen to podcasts!