DEV Community: Avery Swafford

Don’t Give Up

Avery Swafford — Sat, 03 Jul 2021 16:10:14 +0000

You work 40+ hours a week. You have responsibilities outside of your regular work week. You have friends and family commitments to take care of. Then you have that web development thing that you never have quite enough time for.

Sound familiar?

When your full-time job is not web development.

Maybe you’re doing web development as a hobby, or maybe you are doing it in hopes to make a career change. Whatever reasons you have for doing/learning web dev, when you aren’t doing it full time, it can be very challenging. If you think web development has a steep learning curve, you are not alone. It takes time, commitment, practice and having projects on your own.

The challenging part for us, is we have busy lives. Trying to fit web dev in somewhere is difficult. Its not that we lack passion for development, but life can sometimes just get in the way.

Yes, we’ve all stopped at some point, or maybe multiple points

In the beginnings of your development journey, you’re excited, you can’t wait to get started and build the next great app/website. You watch tutorials, (which gets old eventually) maybe you follow a code along and build a site. You feel on top of the world. These feelings shift into more realistic expectations as we get into developing our own things, and better understand the development process.

At some point between starting your development journey, and to where you are now, you’ve likely hit a stopping point. Maybe you stopped a few days, weeks, months, or even years. Maybe you’ve stopped several times, to later pick it up again.

I think most of us have been there. Some of us may even be there now. In these times it feels like we should just give up, you may feel you will have relearn some topics, you may not know where to even begin again. The steep learning curve of web dev can start to overwhelm us.

Keep Going

I think we need to recognize that web dev is hard. It's even harder when you can't commit a full time schedule towards it. Accepting that, is a great step towards finding solutions for when we go through our slumps in the journey.

Here are some things that I think can be a help for motivation, and the continued learning of development.

Set Realistic Goals
Don't tell yourself you will spend 20+ hours a week on coding, if that's all the possible free time you have, its not sustainable. Set something that you feel confident you can adhere to, even if its less than 30 minutes a day (that is still 3 and half hours a week). Set some time aside for learning, and do your best to stick to it.

Shorter Coding Sessions
We may feel obligated to spend all of time we have set aside for learning, for only coding. The problem with this I believe is we risk running into burnout. I think balance is really important. Maybe instead of looking at code during your entire devoted time, take time to read up on the latest industry tech, blog or other things web dev related that you enjoy.

Get Involved with a Community
I think this is a big one. When your working together with others, on a collective goal, it will motivate you to keep going. Its exciting to build something with a team. Also you can learn from other developers knowledge and style. Find a small community to join, whether it be in person, or online. Can't find one? Create a small study group of your own and invite other developers to join.

The key takeaway from this hopefully, is don't get discouraged. Keep going, web development is rewarding, find the spark and remember the reasons that got you started. Find what motivates you, and stick with it.

My Commitment to "Commit"

Avery Swafford — Fri, 18 Dec 2020 12:41:11 +0000

I had been coding on my project for hours, and it was starting to get late in the day. I decided it was time to finally come out of my office at home, and focus on other (non coding) things before the night was over. As I was getting ready for bed, the power randomly went out. When I say "randomly" there were no storms, no wind, just a completely random power outage. Thankfully, our power disruption was short lived, and we had our power back in less than 5 minutes.

I began to think about my project I had coding on my desktop, which of course lost power. I remembered committing my code and pushing to GitHub before leaving my office, which was a relief to know that all of my work no matter what, was safe.

Git May Not Feel Necessary for Us That Don’t Code Full Time

I don’t code full time, as I’m sure many of you may not either. I’m not a part of a professional work project or team. So if I don’t use a remote repository or any form of version control on my projects, it doesn’t affect anyone else. When I first started to develop, I almost never used git or GitHub, unless I wanted to test with a site live.

But guess what? This was a bad coding habit. I found myself coming back to projects I had worked on months prior that I had not used git, wondering where I had left off, or trying find my project in another directory location.

It’s easy I think for beginners to think of git as just a team tool.

The importance of git

The importance of git, and a remote repository can’t be stressed enough. Not only can local files be lost on a project, but also version control, collaboration and even personal motivation.

What if you want to come back to a project later, or share with a developer friend, or even roll back to a previous code base you had?

I think the importance of git isn’t only for teams and developers that do this for a living, but also developers that do this in their spare time.

My personal commitment

One thing I love about GitHub is the contribution section in your profile overview. It shows all of your activity in your projects separated by day. This is a great way to see your progress, and to see days where you have accomplished a lot.

I use GitHub as motivation to keep learning. I try to make at least a commit (and push) a day. Even if it’s Sunday at 9pm it’s just cleaning up a readme, it has to be something. It forces me daily to think about what I am going to work on, and gets me in front of code daily. This has helped me also in sticking to a development schedule.

When we make a habit of coding, it helps us who are self-taught to keep learning and continually get better.

A dev.to component for your blog/portfolio

Avery Swafford — Fri, 11 Dec 2020 00:09:06 +0000

When I was working on my portfolio I had already decided to start blogging on dev.to. With the simplicity and community I prefer this platform for blogging. With this in mind, I wanted my portfolio to have all of my blog articles, which would be on dev.to. I wanted this to be done dynamically.

I wanted a way to do with this without a rebuild of the site every time I posted a article. So I chose to make my component in the following way to fit my current wants and needs.

You can see the blog live on my site here.
You can also see the source code for this component here.

This component was made for Gatsby, however with a few tweaks it could be used with most any framework.

Our Blog List component

This will be for the list of the blog articles with a title, description, and some details about the blog post.

import React, { useState, useEffect } from 'react';
import { Router } from "@reach/router";
import { Link } from "gatsby";

import BlogTemplate from './blog.template';
import './blog.component.styles.css';

const axios = require('axios');

export default function Blog() {
    const [blogData, setBlogData] = useState(['']);

    useEffect(() => {
        async function fetchData() {
            await axios.get("https://dev.to/api/articles?username=aswaff")
                .then(data => setBlogData(data.data));

        } fetchData()
    }, []);


    const List = () => {
        return( 
        blogData.map(article =>
            <div className="articlewrapper">
                <Link to={`/blog/${article.slug}`} ><div className="articletitle">{article.title}</div>
                <div className="articledesc">{article.description}</div>
                <div className="article-details">{article.readable_publish_date}|
                                                🤍{article.public_reactions_count}
                                                🗨 {article.comments_count}</div></Link>


            </div>)
        )}

    const Article = () => {
        return(
            <BlogTemplate />
        )}

     return (                  
            <Router basepath="/blog">
                <List path="/" />
                <Article path="/:article" />
            </Router>
        )           
    }

We are importing react hooks, Reach/router, Link, our blog template and CSS styling. Next we setting our blogData hook, which will hold our data after the fetch is done from the dev.to api.

After the initial render of the page, the fetch gets performed, so we set our blogData state.

We run .map on blogData and we get back data from each individual article. So when we pass our blog data into our divs, each article gets mapped, creating a list for us.

We have an Article function that returns our BlogTemplate we imported earlier, this is for our routing. Using Reach/router, we have "basepath" set for "/blog".

When we go to "/blog", the List function is rendered with our blogData.map. "/:article" dynamically routes us to whatever is after /blog/. We have set the article slugs to be links in our List function, so if the article slug is: "do-something-wrong-4f9c" it gets placed as a link in our article list as "blog/do-something-wrong-4f9c" and Reach/router routes us to the function Article, which returns us our BlogTemplate.

Blog Template component

import React, { useState, useEffect } from 'react';
import './blog.template.styles.css'

const BlogTemplate = () =>  {
  const [articleData, setArticleData] = useState('');
  const articleLink = window.location.pathname.slice(6)

  useEffect(() => {
    async function fetchArticleData() {
        await fetch(`https://dev.to/api/articles/aswaff/${articleLink}`)
            .then(response => response.json())
            .then(data => setArticleData(data))

    } fetchArticleData()
}, []);

  return (
    <div className="article-wrapper">
        <div className="article-image"><img src={articleData.cover_image} alt={articleData.name} /></div>
        <div className="article-title"><h1>{articleData.title}</h1></div>
        <div className="article-info">
          <img className="article-profile-pic" src={articleData.user?.profile_image_90} alt="profile" />
          <span className="article-arthur"><a href={articleData.url}>{articleData.user?.name}</a> </span>
          <span className="publish-date">— {articleData.readable_publish_date}</span></div>
        <div dangerouslySetInnerHTML={ {__html: articleData.body_html} } className="innerhtml"/>

    </div>
  )};

export default BlogTemplate;

What we are doing with the blog template is taking the link of our current browser window, which should be based on the slug of our article on dev.to, and making another fetch to dev.to for the specific article data.

Using the "window.location.pathname" we get back a string of where the browser is currently at "/blog/do-something-wrong-4f9c". The slice() is to get us the actual article slug("do-something-wrong-4f9c") so that we can pass it into the dev.to api fetch, and get the article data.

Because anything after "/blog/" gets routed to our blog template, we can go to a specific article on our site without having to go to the blog list first.

The rest of the function is a simple return of the articleData we get, so we can format and style our page.

If you are on Gatsby, you will need a Gatsby-node.js config, that allows router to take control of the /blog/ route. You can find that in the source above. I also left my CSS styling in the Github repository. Feel free to add or change what you'd like!

Since this uses client side fetching and routing, you may need to modify the List component so it doesn't list all of the articles at once to improve performance. In my case I only have a few articles, so as of now I am fetching all of my articles. A feature that I plan to add later is a spinner that displays for a user so if a connection is slow, so they don't have a blank white screen while they wait for the page to render.

That's it! We have a working simple component that will always have our blog articles from dev.to on our portfolio or site.

I don't like it

Avery Swafford — Thu, 03 Dec 2020 18:20:36 +0000

"Please, at least try it. You'll love it".

"I don't have to, I already know what I like"

"But you haven't tried it, you might like it if you try!"

"I already know, I don't like it".

I am the type that could probably eat the same thing nearly every day. I even order the same meal at restaurants once I find something I like, I am always hesitant to try something new. There are types of food that I know I like a lot. But guess what? I had to at least try something, to know that I liked it in the first place!

My Portfolio Problem

I was working on my Gatsby portfolio, and decided to run a google PageSpeed test, and see how my site performance was doing. My home page was getting a 90 on mobile, and an 86 on desktop. Now, me being a bit of a perfectionist, I wanted my site to perform better. My site didn't have much running on the home page, some text, and an image. So I checked the details of the PageSpeed Insights, and realized that it was the image causing the decrease in my ranking. I wanted a solution to make my site as optimized as possible.

The Gatsby-Image Solution

I had read the documentation of Gatsby and knew they had a solution that was great for high quality photos. Gatsby-Image essentially loads images "up". Starting with a lower "fuzzy" quality photo served to the client so that it can load the page must faster, while a higher quality photo would be served after. This was exactly what I needed, it was a perfect solution for my situation. So why was I so hesitant to use it?

GraphQL - "I don't like it"

I knew that in order to use Gatsby-Image, I was going to have to use GraphQL. I had seen GraphQL used in a online course I had taken, and I was convinced I didn't like it. The whole idea of GraphQL seemed very confusing and it even had its own syntax. I had avoided using it thus far in my projects, and I hadn't stopped to consider why I was avoiding it, I just knew I didn't like it.

I was determined however to make my site better, so I was forced to learn GraphQL. I started reading the docs, I coded, and tested. At first, I still didn't like it and in fact, I may of liked it less than in the beginning. It still didn't make sense to me, why was my GraphQL query not working in my component? How is it passing the data to my component at all?

After a few tutorials and docs, I realized several things I was doing wrong. I moved my query outside of my component and into a page, so that Gatsby would run it in its lifecycle, and passed my props correctly into my component. Everything worked, and it boosted my PageSpeed in the top 90's when I was done.

Understanding before Judgement

Oftentimes, it is our lack of understanding with a coding concept that causes us to have a kneejerk reaction of "I don't like it".

I finally understood what was happening in the code. How Gatsby was running the query and GraphQL returning the query as props, and how accessing the data is as easy as accessing data in an nested object. Once I realized all of this, I actually liked GraphQL.

I realized I was so quick to judge it, all because I didn't fully understand it. This is what we as humans are prone to do right? We often make a judgement before having understanding.

If our first impulse is to avoid using a tool, maybe we don't have a good understanding of the tool itself. We need to really try to understand a coding concept first, and even try it, so that we can make a more educated decision on whether we like it or not.

Use a tool in your next coding project that you don't like, or makes you uncomfortable. You may find after trying it, it becomes a new tool that you like and use in future projects.

Do Something Wrong

Avery Swafford — Fri, 27 Nov 2020 13:27:40 +0000

When I was a child, I would help my dad with everything, working on the cars, working in the yard, etc. I remember on a particular day, trying to help organize tools with him, and being inexperienced in the matter, I kept placing tools in the wrong place. In a frustrated tone, I said “I can’t do anything right” to which my dad replied “You have to be doing something, in order to do something wrong”.

Tutorials are necessary

Tutorials are great, coding bootcamps are great and code along videos are great. You must have at least a decent understanding of at least the fundamentals of programming and basic syntax to get started. In taking an online course I learned so much about HTML, CSS, JavaScript, and React. When I started in 2018, an online course/academy was a great way to get me introduced to web development, I needed something to kickstart my journey. I wouldn’t be where I am today if it wasn’t for the bootcamp.

But in my journey as a self taught developer, I’ve come to realize that tutorials will not make you a good developer on their own. It can also be hard to get out of just following along.

Tutorials should be laying the foundation and set you in the right direction for when you are developing on your own.

When I made my first React app

After hours and hours of courses, I finally decided to create an app. This app wasn’t a code along, I had found an API that would take a URL you gave it, and respond back with a shortened URL.

So I started with npx create-react-app, and began to work on my own. I implemented state, worked with the shrtco.de API to send and retrieve data, and utilized the “react-promise-tracker” and “react-spinners” libraries to add a nice little spin animation while waiting for the promise of the shortened link to return to the user.

Did I run into problems? Oh yes. I remember struggling nearly every step of the way. But I realized something, I was starting to actually understand the code behind my app. When I ran into trouble, I had to read the docs, Google around, and troubleshoot on my own. I felt like I learned more running into issues building the app, than I did when I was taking web courses.

You can see my app here: Live | Source.

Don’t judge, this was my early stages of web dev, I didn’t care how it looked, I just wanted it to work 😬.

Build something

"You have to be doing something, in order to do something wrong."

Part of what took me so long to build something on my own was what I believe, the fear to fail. Starting something, and not being able to complete it, or figure it out. But when I set out to build a very simple app setting a realistic goal, it boosted my confidence along with learning a lot along the way.

So if you are tired of taking courses, tutorials, bootcamps, and want to take your learning to the next level. I suggest building something. Set a realistic goal (don't rebuild Twitter at first), a goal that will push you while also aligning with your current skill set. When you "do something wrong", just remember this is the developer life, we run into issues, and we solve them.

Learning in Public

Avery Swafford — Mon, 16 Nov 2020 19:53:08 +0000

I came across a article that was posted by "SWYX", regarding "learning in public". This was a new concept to me, I've been dabbling in web dev for a couple of years now, and I haven't heard of this. The idea is simple, you publicize your learning journey. Your experiences can be helpful to someone who is trying to learn. I also think its helpful to yourself, to write out and explain a complex coding concept, to make it easy to understand. It causes you to really reflect on what you have learned, and I believe reiteration, can you to remember and ingrain your knowledge.

My Methods of "Learning in Public"

Writing blog posts
- I'll be using dev.to moving forward for my blogging, I really like the platform. I'll also be connecting the API of dev.to to my actual site to act as a CMS.
Discord groups
- I am in a couple of discord groups that have a focus on web dev and React. I've learned to not just be a observer, but actually contribute. Even if its just checking in to see how everyone is doing. While its not my favorite "public" app, it can help the group you are in, and some people are more comfortable in a small group setting.
Asking and answering questions
- With multiple online forums and boards, it is true someone has likely had and asked about a problem or bug that are having. I am not advocating that we spam, and ask the same questions that have already been answered, but maybe if you find the questions doesn't exactly meet your needs, ask or post in a different way. Or maybe if you have found a different and better answer to something you had a hard time with, post it! Chances are, someone else is going through, or will go through the same thing.

Sources

https://www.swyx.io/learn-in-public/
https://careerchats.transistor.fm/episodes/learn-in-public