
With my wild schedule of driving 1.5 hours one-way for a class four days a week, I haven't had as much time to write code outside of work. I also see tons of people on Twitter talking about React or Gatbsy, which makes me want to dig into them even more.

So, I'm making an informational website on Discrete and Combinatorial Mathematics II to study _and_ practice my Gatsby skills. 😉 The course material is separated very nicely already: 7 advanced topics and 6 core topics. So far, there's one page for each which are linked from the home page with a little summary description.

![Preview of the home page. It shows short descriptions under each topic's page link.](https://thepracticaldev.s3.amazonaws.com/i/4az0rsudygy5gq04uy0q.png)

On each page, I plan on showing a list at the top of the important terms and definitions the relevant textbook section and I'm also inserting the examples most helpful to me.

![Preview of a topic's page. It has a terms section with links to each term page and an Examples section with through math examples.](https://thepracticaldev.s3.amazonaws.com/i/yhov3ts4yi3ygi26xjd0.png)

Finally, I'm also creating a glossary page where all of the important terms and definitions will be formally described and linked to from any of the other site pages.

![Preview of the terms page. It shows bold headings for each term and a short definition below it.](https://thepracticaldev.s3.amazonaws.com/i/bkyxf8891q4t2wcsdm4h.png)

I feel extremely nerdy for doing this and it's _actually_ incredibly fun. I'm trying to pick up on little things along the way too, such as practicing semantic HTML. I found this really cool post while looking up the differences between `<section>` and `<article>` elements called [7 Alternatives to the div Tag in HTML](https://dev.to/zac_heisey/7-alternatives-to-the-div-tag-in-html-62i).

I hope this post inspires you to do whatever it takes to accomplish your goals. Figure out what tactics work for you, and [just get it done](https://ashleemboyer.com/blog/just-do-the-thing-10el).


I have a final a in a few days, but have also been itching to write code outside of work. So, I'm making a site to study for my final!

How to Study for a Test by Making a Website


You will never know everything. There's too much information out there and not enough time to learn it all. What this means is, sometimes we're wrong because we just don't know all of the answers. And that's fine&mdash;it's 100% OK to be wrong!

If you're wrong about something, it's not a big deal. It's an opportunity to do better, to learn something new, and grow. Your teammate _will_ know more about a topic than you, just like you know more about a topic than them. That's the great thing about working on a team! You can teach each other about these topics, and your skills will probably compliment one another to the benefit of everyone.

My brain is pretty tired today and words are hard, so I'd like to open the comments for people to share their favorite resources for learning new things. Where do you like to learn about productivity? What books do you recommend on philosophy or ethics? Who's your favorite author of UI/UX books? Whatever you got, I want to hear it. :)


It's OK to not know everything. It's OK to be wrong.

Aim to Never Stop Learning


There's no such thing as a stupid question. There may be stupid timing for it, such as a student asking when an exam is 5 minutes after the teacher already announced that information. But that was still a good question, they just asked it at a horrible time.

In general, there are not too many restrictions on asking questions. It's a lot about timing them. For example, you don't want to ask too many specific questions about implementation details if you're still trying to find out what a client needs in a potential product. Their needs are _probably_ going to change every time you talk to them at this point and planning the implementation too rigorously could be a waste of time.

So, what are the benefits of breaking out of your fear of asking questions and just doing it?

## Learning, learning, learning

To an extent, who cares how they feel about you asking a bunch of questions? Your career is yours and only you can be responsible for taking it to the next level.

## Making new friends

I can't tell you how many people I've met through the DEV Community site and Twitter over this past month. It's really exciting how much support you can find in this industry if you put yourself out there.

## Building your confidence

Sometimes the scariest part about asking questions is knowing _how_ to ask them. You can make 10 attempts at Googling something and Google isn't going to judge you for doing it. Re-wording a question to a human a few times to make sure you're getting the right information? That can potentially be frustrating for both of you. But good news! The more you ask questions, the better you get at wording them.

Have any insight on questions that you'd like to share? Leave a comment or [send me a tweet](https://twitter.com/ashleemboyer)! :)


I'm an engineer and a natural-born master of asking questions. I used to be afraid of it, but there's really no reason to be.

Don't be Afraid to Ask Questions


I first heard the phrase "learn out loud" from the [Office Hours podcast](https://discoverpraxis.com/office-hours/). In [this article](https://discoverpraxis.com/3-reasons-learn-loud/), podcast co-host T.K. Coleman gives us three reasons to do so. I'd like to focus on the first reason he gives and show you how to apply it to the job search.

Say you're in an interview and they ask you a difficult question you're not sure of the answer to. The pressure to immediately respond and sound smart is on and it builds as the awkward silence grows between you and the interviewer. You get more and more uncomfortable and your mind goes blank. No answer is coming to mind.

It doesn't have to turn out like that. You can, and I believe most would interviewers appreciate it, think and learn out loud instead. T.K. made two key points relevant to this.

> Knowing what a person knows is very different from knowing what it’s like to work with that person when they don’t know. The latter is far more important to the people who have to work with you. And since everyone has things they need to learn, it’s highly valuable when you can signal your ability to do that very thing with patience and persistence.

> When people can watch you learn, they’ll still get to see how effective you can be when you’re in the know. But more importantly, they’ll get to see how consistent and composed you can be when you have no clue.

Some days, you're going to be visiting Google and Stack Overflow dozens of times. Others, you may only need to go there once or twice. Both are fine. No sensible person is going to expect you to have every single thing about your job memorized. There's just _too much_ information out there so we have to keep our minds tidy with only the most important bits.

Since learning is the expectation of any job, what _should_ be important to interviewers is how someone learns, not whether or not they have every Big O notation memorized. The best way for you to showcase your learning skills is by doing so out loud. When you get a difficult question during your whiteboard pseudocode test, step through your thought process. If you get stuck, say so! Then proceed by explaining what you would do next.

What will your search terms be? Have you seen this kind of problem before? What questions would you ask a fellow teammate? Answer these questions well by _doing_, and your chances of impressing the interviewer are huge.


You don't have to know all of the answers right now.

What it Means to Learn Out Loud


Let's face it: nothing you make will ever be absolutely perfect. Some people may not like the final product. Maybe you could remove a paragraph or two from your blog post or reword a few sentences. Your code could probably be refactored in a few different places. That drawing might look cleaner if you erase a couple of smudges.

We all know what happens to projects once we start falling down these rabbit holes. "I'll just spend a couple of minutes fixing this little thing," can turn into a few hours or longer if you're not careful. In my experience with code, it could take even longer because you might accidentally break something totally different while trying to clean up a few functions.

Obviously, there's a time and a place for everything. Projects put you through various phases of pressure. Sometimes, you don't have the chance to make the code as beautiful as you want. Functionality is almost always more important because your client probably won't ever see your code. All they care about is that their product works well. So, when it comes time to punch, try not to worry too much about making the code perfect.

Rather, make some quick notes about where the code needs some help and what you might to do make it better. Hopefully, you can go back later and make the improvements, but if that isn't the case, you can either pass those notes along to the next person or use them to explain what you learned about the project experience. People expect you to learn more than anything. They will value the experience you have to share.


We all feel pressure to make things perfect, but don't let it crush you. There are alternatives we can work with.

Posts Related to the "learning" Tag