Jerry Jones

Category: Professional Development

  • Qualities of Expertise

    Gaining expertise is difficult enough, but how can you tell if yourself (or someone else) has reached expert status? Unfortunately, multiple-choice tests are ineffective predictors since the benefit of expertise is being able to conjure up complex, situational-dependent solutions where there is no “correct” answer.

    One of the simpler ideas is to see how long someone has been in an industry (say, 10+ years) and give them the benefit of the doubt. Surprisingly, for programmers at least, “programming experience gained in industry does not appear to have any effect whatsoever on quality and productivity.”1 Ironically, what does increase with experience is the confidence in your incorrect decisions.2

    If you have the same one year of experience, ten years in a row, is that nine years of experience?3 Putting the time in is not necessarily effective. You need a strong feedback loop that allows you to hone your decision making and see what is effective,4 and an opportunity to vary and increase the difficulty and scope of your work.

    To find expertise, we’ll need to look beyond the CV, using some generalized qualities across different domains.

    Discrimination of subtle differences

    The ability to make fine discriminations between similar, but not equivalent, cases is a defining skill of experts.

    Empirical evaluation of the effects of experience on code quality and programmer productivity: an exploratory study

    One of the most chill shows I watch is The Repair Shop. It’s a team of repair experts, taking worn down heirloom objects and returning them to their former glory. In one episode, art conservation expert Lucia Sclaisi is shown restoring a damaged painting. Where I see an old painting with a hole in it, Sclaisi sees:

    • the time period
    • the likely artist
    • the style
    • what has sullied the surface based on the color of the grime (she identified it as nicotine)
    • how highly finished it is and what finish is used (and thus how to best clean it)
    • and surely much more they didn’t show/I missed.

    An expert can get information from clues that the novice didn’t even realize existed.

    However, it’s not simply about knowing the information. If a quick Google search can tell us the answer, then it doesn’t require expertise. The big piece is knowing how to apply the information to make successful, situational-dependent decisions.

    Consistency

    We all get lucky from time to time. Sometimes when the problem is a nail, we happen to have a hammer. Being able to consistently formulate a good solution to a variety of problems is the key here.

    Situational-Dependent Solutions

    I’ve mentioned “situational-dependent” several times now. What does that even mean?

    As Andy Hunt emphasizes in Pragmatic Thinking & Learning: context is key.5 The same problem in a different context may require a different solution. Problems rarely have a one-size-fits-all solution. It requires expertise to correctly apply information within the right context.6

    This means when encountering a new problem, an expert often asks important questions about the context. For example, the art restoration expert may ask where the painting has been stored, under what conditions, etc. I have a guess as to how some of these details could impact a painting, but I’m not sure how I could practically use that information. An expert does.

    These details, which may seem unimportant to the novice, reveal nuances that can significantly inform the expert’s solution.

    Assessing Expertise

    Accurately assessing these qualities when hiring is easier said than done, and likely looks different across industries. However, the key qualities of expertise remain:

    • Ability to discriminate between subtle differences
    • Consistency
    • Situational-dependent solutions in the right context

    If you are trying to assess expertise in an area that you don’t have much domain knowledge, Tyler Alterman has some great recommendations in their article, Why and how to assess expertise.

    In many of my examples it’s easy to see the difference between a novice and an expert. Assessing someone proficient in a subject vs an expert can get tricky. In the end, if someone can consistently discriminate subtle differences in context-dependent situations to find the best solution, they’re well on their way to expertise.

    Sources

    1. Oscar Dieste, Alejandrina M. Aranda, Fernando Uyaguari, Burak Turhan, Ayse Tosun, Davide Fucci, Markku Oivo & Natalia Juristo. Empirical evaluation of the effects of experience on code quality and programmer productivity: an exploratory study. Empirical Software Engineering. Feb 2017.
    2. James Shanteaua, David J. Weiss, Rickey P. Thomas, Julia C. Pounds. Performance-based assessment of expertise: How to decide if someone is an expert or not. European Journal of Operational Research. Apr 2000. p.254
    3. Andy Hunt. Pragmatic Thinking and Learning: Refactor Your Wetware. Sept 2008. p.15
    4. Tyler Alterman. Why and how to assess expertise. Effective Altruism Forum. Feb 2016.
    5. Andy Hunt. Pragmatic Thinking and Learning: Refactor Your Wetware. Sept 2008. p.35
    6. Iris Vessey. Expertise in Debugging Computer Programs: An Analysis of the Content of Verbal Protocols. IEEE Transactions on Systems, Man, and Cybernetics. Sept 1986.

  • Must Read: Unspeakable Conversations

    I started reading Disability Visibility this week to expand my understanding of the experiences of the one in five people with disabilities in the US.

    I had intended to do a blog post on things I learned, what struck me, etc. However, instead of reading what I think, please read Unspeakable Conversations (which is the first chapter of Disability Visibility) from Harriet McBryde Johnson.

    The first paragraph will draw you in better than anything I could write:

    He insists he doesn’t want to kill me. He simply thinks it would have been better, all things considered, to have given my parents the option of killing the baby I once was, and to let other parents kill similar babies as they come along and thereby avoid the suffering that comes with lives like mine and satisfy the reasonable preferences of parents for a different kind of child. It has nothing to do with me. I should not feel threatened.

    Harriet McBryde Johnson, Unspeakable Conversations

    It’s beautifully written. Deeply personal, raw, complex, funny, and profoundly impactful.

  • Across the Atlantic Handoffs

    Across the Atlantic Handoffs

    Automattic is a large worldwide team, made up of smaller, worldwide teams where everyone works remotely. That was one of the things that made me excited to work there, but also very curious as to how it worked in practice.

    Would the timezone differences slow us down? Would we unintentionally get in each other’s way? What if we needed an answer from someone who had already logged off hours ago?

    Working as a Team

    The team of eight I’m on is made up of people from 6 countries:

    • Argentina
    • Czech Republic
    • Germany
    • England
    • United States
    • Greece

    And it’s amazing. We work so well together. This boils down to:

    • Caring about doing a good job.
    • Wanting to help the team.
    • Being responsible and motivated to work independently.
    • Communicating * 3

    I’m a big fan of everyone on the team. We all do the above points well, in my opinion. I’m not sure how well it would work otherwise.

    The End of Day Handoff

    One thing that really helps us work efficiently is our End of Day notes. Everyday before logging off for the day, you post:

    • The status of what you’ve been working on.
    • Any PRs you need reviewed.
    • Is there anything you want to handoff? Lots of notes here, if so.
    • Is there anything blocking or that you need help with? Similar to the above, but not exactly. This could be something outside of a code-related thing.

    This helps us know the status of everything in a consistent way, while also being able to pick-up work or help each other out. We call this asynchronous communication. A lot of things don’t need to be real-time conversations if you communicate clearly enough.

    The handoff works especially well when there are two people spread out over far enough timezones that they have 2 – 4 hours of overlapping time. One person starts work in a more focused way, then there’s enough overlap time for working together and getting on the same page, then handing off to the next person to work on it.

    It also builds a lot of team camaraderie as well as being deeply satisfying when you say you need help with something, go to bed, then wake up and find it’s taken care of.

    Working in Sync

    Earlier on when I’d joined Automattic, I was helping out on a complicated issue where two of us were working actively on the same PR. I was trying to act in a supporting role to get it over the finish line without getting in the way. I tried to walk the line between helping out without taking over.

    I reached out to my co-worker Damián to make sure I wasn’t stepping on his toes by working on the issue.

    “Please, step on my toes.” he said. “I’ll let you know if something isn’t going well, and I ask you to do the same for me.”

    So many places look at being in one office at one location as an advantage, but I’d argue that this kind of open, honest communication and End of Day handoffs allows our team to work more efficiently than if we were all in one area.

    Either way, it’s an amazing team. We’re hiring, so be sure to apply if you think you’d enjoy working remotely on a worldwide team.

  • Getting Hired at Automattic

    Getting Hired at Automattic

    I started at Automattic on November 20, 2019, and it’s an incredible place to work. I’m constantly impressed by my coworkers kindness, intelligence, and compassion. If you’re looking for a rewarding remote job that you can work from anywhere in the world, definitely apply.

    I’m still overjoyed and amazed I was hired. While going through the hiring process, I devoured the blog posts from people describing their journeys. Here’s my contribution to the catalog. I hope it helps someone.

    The Creed

    Before applying, I would recommend reading through the Automattic creed to see if it aligns with you. I think most companies have a creed to pay lip service to.

    That’s not Automattic. The creed really is embodied in an amazing way. It sounds cliché, but it’s true.

    Recruitment

    End of September, 2019

    I was contacted by a third-party recruiter about applying. I believe this may have been an experimental program, and is not the normal process.

    It was the first time that I was contacted by a recruiter who:

    • was kind and supportive
    • really wanted the job to be a good fit for me
    • had a good job offer

    I had actually applied to Automattic a few years ago for a Product Designer role, but did not get past the application step. They were still incredibly kind and encouraging in their rejection. I was shocked and excited to be contacted by a recruiter asking me to apply this time around.

    I sent my resume in, and they passed it along to the hiring team. Within two days, I heard back that they wanted me to fill out their application questionnaire.

    Questionnaire

    End of September, 2019

    I received a questionnaire that helped them and me evaluate if working at Automattic would be a good fit. Automattic has a very unique and wonderful way of working. It’s definitely not for everyone, but it’s something to be discussed and aware of very early on.

    I don’t remember this part taking too long or being too intense.

    Slack Interview

    Update June 2021: Automattic is removing the interview from the engineering hiring process. Candidates are moved directly to the Code Test.

    Early October, 2019

    Within a week, I heard back that I was being advanced to the Slack Interview. The interview is entirely text based.

    A Text-Based Aside

    The entire hiring process is text based. Seriously.

    Never once did I hear someone’s voice or do a video call. Until my first paycheck arrived, a part of me still believed it was all too good to be true, and it was just an elaborate prank. 😂

    They invited me to a slack channel, and I was free to ask questions and talk with the hiring team. They told me how they do what they call “async communication.” You can ask a question, and you may not get an answer for awhile, as the person may be in a totally different part of the world. For example, the hiring team for my trial process was distributed in Europe, Eastern Europe, Oceania, and the US.

    Slack Interview – Continued

    I really enjoyed the slack interview. It was by far the most enjoyable interview I had ever done. The person I chatted with helped me feel comfortable and confident. They knew what they were talking about and used plenty of emoji responses to keep things light.

    The interview felt more like hanging out and talking with someone you met at a conference about what you do, what processes you use and why, etc. It was friendly and, dare I say, fun.

    By the end of our 1.5 hour chat, they told me I was moving on to the next stage. No waiting required.

    Note: I don’t think a fast answer like this is always the case. Just because you’re not told an answer at the end of the interview doesn’t mean you’re not moving on.

    The Code Test

    Early October, 2019

    It’s getting real now. You can talk the talk, but can you… uh… walk the… code? Well, you know what I mean.

    Within a couple days, they sent me the Code Test. It was a github repo with details on the project and what needed fixing. They said to not spend more than 4-6 hours on the test, but, I did spend a little more than that. 😬

    The impression I got behind the intention of the 4-6 hour limit isn’t to see how fast you can code or to make you crack under pressure. It’s out of respect for your time. They really don’t want to waste your time or their own.

    It was hard. I doubted myself. I put too much pressure on myself. I freaked out. I took a break. I figured part of it out. Repeat.

    Within a day or two of submitting my code test, I got a detailed, kind response about things I did well and things I could improve. The intention behind the message was clearly to help me learn. Fortunately, I was being moved on to the Trial phase.

    The Trial: Hot Take

    Mid October, 2019

    The trial phase is a fixed-rate, paid trial at $25/hour and is intended to last around 40 hours. This is a big commitment, and a controversial one if you read around a bit on forums from people debating the hiring process at Automattic. I think it has changed over the years, so here’s my take after having gone through it:

    • The $25 rate is clearly low for a US-based web developer. It’s not supposed to be a living wage and has no impact on your future salary. It is nice that they believe you are a good enough candidate that they are willing to pay you to continue interviewing with them.
    • It’s not an attempt to get reduced-rate work. You get one of a few standardized trial projects that are not intended to be used in production.
    • It’s supposed to mimic the way Automattic works to see if you’ll enjoy working there.

    You’re allowed to do the trial project spread out over as many weeks/months as you’d like. Just communicate what your schedule is going to be. I decided to do it within two weeks so I could get it out of the way and find out sooner.

    The Trial: How it Happened

    Note: I had originally started as more of a back-end developer during the hiring process, but decided to move to a front-end developer role. I was worried they would make me start the process over. Fortunately, they just said “No problem!” and switched me to a front-end trial.

    When you get to the trial phase, they add you to a few slack channels with everyone else on Trial. You are now officially a Trialmattician. This channel is kind of like a #watercooler channel for others on trial. It was incredibly useful and comforting to chat with others going through the same, difficult thing as you.

    The hiring team makes it clear that you are not competing with anyone else on trial. They have a high hiring capacity, so it’s not about accessing a limited amount of positions, but finding the right people who will thrive at Automattic.

    My trial project was another WordPress plugin, but this time it was React-based. I had never worked with React and told them this ahead of time. They weren’t worried about my lack of React knowledge.

    My impression of the trial wasn’t to evaluate how good of a React developer I was (hint: I wasn’t), but to evaluate (among other things):

    • Communication
    • Documentation and showing work
    • Detailing my thought process
    • General coding style and knowledge
    • Ability to work in an async, distributed way
    • How you adapt to a new, unique codebase

    Since I committed to doing the trial fairly quickly, I went faster than they could really provide feedback (this was also due to my trial lead traveling during the first part of my trial). I believe the process is supposed to be more like the day-to-day of working at Automattic where you have code reviews from teammates coming in within a day of submitting a PR (pull request).

    The trial pushed me in a similar way as the Code Test. I doubted myself. I tried to move quickly but just wound up missing silly mistakes. Taking a breath and moving carefully and considerately was by far the best thing I did.

    Overall, it was extremely tough for me. I’m very glad to be done with it. 😅

    When my trial lead felt like they had seen enough to make a decision, they recommended me to be hired. 🎉

    The Matt Chat

    Early November, 2019

    This is still called the Matt Chat even though I talked with someone from HR. The chat involved talking about my trial process, how I felt about it, the good, the bad, etc. I was impressed with how much they wanted to hear my feedback so that they could improve the hiring process. Overall, I remember really enjoying the chat.

    At Automattic, they really care. A lot. They want this to be the best it can be for the candidates putting the time in. Even though it’s not always perfect, it’s filled with good intention and compassion.

    We talked a little about a potential start date and expected salary, and that evening I received and accepted my offer.

    My Advice

    • Every step along the way, I thought I would get rejected, but I didn’t. Hang in there! The hiring team does not pass people through out of kindness (even though they are very kind). They move people on through the hiring process because they believe they will succeed.
    • Imposter syndrome is real, but you’re there because you deserve it. Believe in yourself like they believe in you.
    • Have a support system. Be prepared to get together with a close friend (or two or three) and just talk about what you’re going through. I’m so thankful for my friends’ encouragement and being willing to listen as I got everything out of my head.

    If you’re considering applying, do it! The process is very difficult, but the reward is so, so worth it. If you’ve already applied, know I’m rooting for you!

    Leave a comment if you have any questions, and if it’s something I can/am allowed to answer, I’m more than happy to help. 🙂

  • Share Pie with Strangers

    Two years ago I spent the night in a cabin in an RV park in Northern California. My family and I finished dinner and lounged around a picnic table.

    A jovial man sat down and introduced himself. Talk quickly turned to work, and we realized we were both web designers/developers. I was a bit further down the track, and he had questions on a few different things like DNS and running a small web shop.

    Until that moment, I knew I enjoyed talking about design, development, and client management, but didn’t feel like I had anything to contribute. I didn’t believe I had any way to really help another designer/developer out. At times, it can feel like there’s so much I don’t know, it’s hard to have the confidence that I really know anything at all.

    But on a starry night near the Redwoods, eating apple pie with a stranger, I had a lot to offer.

    A year later, the small web shop I helped start fell apart.

    It was rough. I questioned my value and what I had to offer. The little confidence I had was shot.

    As I started to get my bearings again, I got a call from an unknown number.

    This man from California was calling to say how helpful our talk was that night. A year later, he was still thankful for that night. And so was I.

    His call came through at the exact time I needed it. It made my month. It kick started my confidence. Made me feel like I had something to offer after all.

    And here I am, another year later, thankful for that night and a phone call from a stranger.

    Be nice to people. Share what you know. Listen. Connect.

    And don’t forget to share some apple pie.

  • 6 Questions to Ask Yourself Before Working for Free

    It’s tempting to work for free or with steep discounts for friends and nonprofits, but there are some pitfalls to be aware of. If you can get to the end of these questions and feel great about designing a logo, building a website, or whatever it is you do, then by all means, go for it.

    1. Did they say it’d be a “portfolio builder”?

    No. Nope. Definitely not. Don’t even bother responding. If they think they’re doing you a favor by letting you have a chance to work for free, then it’s not going to end well.

    2. Will you be OK with your work being under valued and not appreciated?

    People will generally appreciate that you built them something that they had no idea how to do, but probably not on the level you want them to. They don’t know how hard you work, or all the considerations that go into your designs and websites, and they’re not supposed to. That’s your job.

    It’s hard to fully appreciate something when you don’t know the intricacies of it. Couple that with doing the work for free/cheap, and you’re basically teaching someone that your time isn’t of much value. You have to be OK with this or have a strategy to make sure your time is valued.

    3. Will you be proud of the end result?

    I work hard on all my projects, but it’s not realistic to put the same level of care and detail into a free project. Is it OK? Yeah. Does it work? Of course. Is it something I want to put in my portfolio… eh… sometimes.

    If you’re not willing or able to put in your full effort, then maybe it’s better to let the project go.

    4. Can you give them the attention they need?

    You might see their project as a simple task and understand every step that needs to be taken. They probably don’t. This might be the first business they’ve started, or a project they’re pouring their life into. If you’re not able to meet them where they’re at, then it’s probably best to pass.

    5. Can you say no?

    If you can’t tell them “no” now, then it’s going to be even harder to say no 3 months from now when they’re still trying to expand the scope of the project. Pair that with someone not valuing your time, and you’ve got a sticky situation.

    6. Will you be able to support the project down the road?

    Just because you’re doing free work now, is it still free work 9 months from now when the site gets hacked? What about if they change the tagline on their logo and need updated business cards? If it’s free for them now, why wouldn’t it always be free?

    You’re eventually going to be put into a spot where you have to charge them for your time or say no. It’s not going to be easy, and you will both walk away feeling badly about the situation. Not so great for something that started with good intentions.

    It is possible

    This article isn’t meant to convince you that you should never do free or cheap work. The article is about making sure that at the end of the project, everyone is happy with the outcome.

    Clear communication and firm boundaries are key. Make sure your time is valued, your work is appreciated, and that you have the availability down the road to keep helping out (or a firm end of project/limit to your work) and things will hopefully turn out alright for everyone.

  • 7 Easy Steps to Fail at Building a Network

    For most of my career, I’ve felt like an imposter. I didn’t think I knew enough to contribute to the web designer/dev community, so why would anyone want to network with me? If I tried, wouldn’t people just figure out I didn’t know as much as them?

    I used to believe this was true. As a result, I’m just now starting to build a professional network. If you want to fail at networking like I had, follow these 7 easy steps!

    1. Figure Everything Out on Your Own

    Every project I start, I learn something new. This develops great problem solving skills at the expense of networking. I could have asked questions on Stack Overflow, but, instead, I slogged away for hours on my own.

    I’ve asked a total of three questions on Stack Overflow in my career. Every time I do, I’m welcomed by intelligent, helpful people that work with me to figure out a solution. If I’d been more willing to ask for help, I’d have met more great designers and devs along the way.

    2. Feel Like an Imposter

    My biggest struggle as a designer/developer is feeling like an imposter. It wasn’t until 6 years of making my income as a designer/developer that I finally felt like I could even call myself a designer.

    I’m going to let you in on a little secret: Everyone feels like an imposter.

    You may not be the best at what you’re doing, but you’re doing it, so have the confidence to allow yourself to be a part of a network.

    3. Don’t Write about What You’ve Learned

    It’s hard to write an article or share your opinion when you feel like an imposter and you know there are people out there that know a ton more than you.

    Why would anyone read what you write? Won’t people tear it to shreds?

    Well, frankly, it’s likely no one will read your article. But that’s not the point. The point is, that writing will make you more confident in your abilities, shape your ideas, and prove to yourself that you have ideas to contribute.

    4. Don’t Be on Twitter

    Before I joined Twitter, I only read articles that were directly related to the problem I was trying to solve.

    Using Twitter, I’ve learned about new techniques, best practices, and interacted with great people. Also, it’s a big confidence boost when other designers/devs follow you or retweet something you said. Don’t expect that to happen overnight or even much at all. It’s slow to get the ball rolling if you don’t post much and don’t have many followers.

    5. Live in a Small Town

    I’m one of three professional designers and/or devs in the town I live in. I’m going out on a limb here, but if your “network” is a shape easily drawn by a three-year-old, then it doesn’t count as a network.

    I’m not saying it’s impossible to network while living in a small town, but you’re going to have to put more effort in. There aren’t meet-ups to attend, conferences to go to, or tech-oriented companies to work for.

    6. Don’t Attend Conferences

    I’ve never been to a conference. They can be cost-prohibitive for freelancers. I really want to go and meet a bunch of people who are as excited about web design and development as I am.

    Quick shameless self-promotion: I’d love to try speaking at a conference. Send me a message if you think I’d be a good fit for your conference.

    7. Immediately Start A Freelancing Business

    I started web development and design by accident, and started picking up gigs on the side. I’ve never worked as an employee of an agency or company. The ability to set my own schedule and work on projects I’m passionate about is better than I could have expected. The downside… For six years, I didn’t have any professional peers. No co-workers. Everything was up to me.

    I’d love to work with a bunch of smart people, learn from them, and create amazing things together. In the last 6 months, I’ve been fortunate to be a part of a small team at the Engaging News Project and work with fantastic, intelligent people. We push each other to make better products, and I’ve become a better designer and developer as a result.

    It Takes Effort

    Yeah, this article is called “7 Easy Steps to Fail at Building a Network,” but I need a positive takeaway, right?

    It takes effort to build a network. Most of my career I just pretended it wasn’t important. Since trying to develop a network, I’ve become a better designer, developer, and person. And it’s fun to meet new people that are excited about the same things you are.

    If you think I’d be a good part of your network, reach out to me. Because I’d sure like to be a part of yours.

    Do you have any good tips for people trying to grow their network (including me)?

  • How to Get Started as a Web Developer

    I became a designer and developer by baking bread.

    Wait… let me start over.

    I accidentally became a web designer/developer by baking bread.

    Here’s how it happened:

    1. Get a BA in Creative Writing and an MA in Elementary Education
    2. Learn how to make great sourdough breads
    3. Sell bread and my wife’s granola bars (best bars this side of the Mississippi) at the Farmer’s Market
    4. Make a legit business and call it The Covert Cupboard
    5. Illustrate a logo of a bird wearing Groucho Marx glasses and a mustache
    6. Check out a book on HTML/CSS from the library
    7. Stay up until 2am every night trying to figure out what all these acronyms mean (CSS/HTML/JS/FTP)
    8. Have someone see the site, and say, “Hey! Can you make me a website?” and respond with a resounding, “Um… Maybe?”

    You can try following these steps if you want, but your mileage may vary. If you want more reliable results, try some of these tips instead.

    Learn the Basics

    There are a lot of tools and frameworks (like WordPress) that make it easy to get a website up and running with very little knowledge.

    Don’t use one of those.

    I can’t stress that enough. Don’t learn a framework, learn code.

    From the beginning, I decided that I wasn’t going to use a site builder (like WordPress or Squarespace), because if it broke, I wouldn’t know how to fix it. When you learn how to build a website using a framework, you don’t really learn how to build a website. You learn that framework.

    It’s more of a challenge up front to learn the basics and write all your HTML and CSS from scratch with just a text editor, but you’ll be far better off in the long run. When you know the core concepts and can write code from scratch, then you can build anything and learn any framework you want.

    Create Something Real

    Places like Code Academy that guide you through building a site can be great for getting an overview, but the best way to learn is to create something you actually want to build that people can actually use.

    If it wasn’t for building a website for my bakery, I probably wouldn’t have stuck with it. The combination of determination and deadline goes a long way towards learning.

    Learn One Thing at a Time

    Your first site isn’t going to be a masterpiece. That’s OK. If your first website works well to you on your computer, then that’s amazing. It’s a big achievement, and you should be proud of it.

    Every site you build will be a little better than the one before it.

    For your next site, maybe you’ll make it look great on your computer and a tablet. Then, make it look great on a smartphone. Then, make it load faster. There’s no perfect website. The important thing is to keep learning and improving.

    Get Stuck

    Every developer has lost countless hours of their lives staring a line of code that should work but doesn’t. A forgotten semicolon, a typo, extra whitespace. Anything.

    I would get so stuck that I wouldn’t even know where to start. I didn’t even know what words to use to describe the problem.

    It’s going to happen to you. And it’s going to keep happening to you. Everyday. Getting stuck is a great opportunity. On your quest for the answer, you’ll learn five new things before you finally figure out the solution.

    No One Knows It All

    It’s easy to get discouraged. There’s so much to learn, and so many smart people that will seemingly always know more than you. But that’s a great thing.

    We all know what it’s like to be overwhelmed and stuck. There are great communities of developers helping each other out, like on Stack Overflow. If you show that you’re doing your best to figure out a problem, but you’re stuck and have questions, people will gladly help.

    There’s No One “Right” Way

    People learn in different ways, but these tips are how I became a web designer and developer.

    Not only do we all learn and take different paths, but every coding problem can be solved in hundreds of ways. There’s no one right way. If you give ten developers the same site to build, you’ll end up with ten different solutions to the same problem.

    Just because you don’t code something perfectly the first time, remember, there is no perfect way. If it’s working, then it’s working. Be proud of that. You’ll keep improving and learning, and before you know it, you’ll be writing an article on how to get started as a web developer.