Don’t you just love automated emails? I know I do. I mean, who doesn’t enjoy waking up to 236 new messages from Nike, Ticketmaster, and Adobe Creative Cloud every morning? What a fantastic way to start my day! ??

Anyway, today I’ll be showing you how to drown your inbox in more clutter, for God-knows-what reason. We’re going to be using Python to create a custom Reddit email-notification system. That means we’ll be writing a script that looks for Reddit posts matching some keywords and then emails us when such posts appear.

Want quality email content like this? Read on!

There are a few reasons that you might be doing this. Maybe you’re really excited about some topic on Reddit. Maybe you’re trying to discover a new karma-farming technique because Internet points are important to you. Maybe you want to send annoying emails to your friends. Or maybe you just want more emails in your inbox to deal with your crippling loneliness. Oops, sorry — went too far. Let’s get started.

Looking through Reddit

Reddit has a nice API that you can do a lot with. To make things even easier, we will be using PRAW, the Python Reddit API Wrapper.

You’ll need a Reddit account first. Once you have one, go here to create an app. Name it anything, and make sure “script” is selected. As per the docs, you can just put [http://localhost:8080](http://localhost:8080) for your redirect URI.

Now, you’re ready to start that nifty script! In the code below, I look through a subreddit, picking out posts that match my needs.

I consider a post a match if it is relevant enough and if it is popular enough. More specifically, the post is relevant enough when it has a keyword_count that’s not -1 (I’ll explain this below) and popular enough when it has a weighted_score greater than a predefined MIN_RELEVANT_WEIGHTED_SCORE. The weighted score simply factors in the score of the post and the number of comments on the post. Anyway, this is what best fit my needs, so feel free to better define what a match means to you.

Now, I promised you I would talk about the keyword_count party going on. Spoiler: it’s not really a party. I just devised this simple way of assessing relevancy: there are required terms and secondary terms. A post is relevant if and only if all the required terms are in the title, and at least X number of secondary terms are in the title (where X is some predefined number). Again, this part can be re-imagined in infinitely different ways, but this is just what I did.

Now we have everything to comb through our subreddit and tease out the good stuff about conspiracies or whatever. Cool. So, like my homie Ariana says, “thank u, next.”

Emailing notifications

Time to start spamming. In the code below, I’m using smtplib (the Simple Mail Transfer Protocol client) to help me send my emails. I then craft the beautiful email with HTML, using the info from Reddit that we got above to populate it. And the best (or worst?) part is, if you want to notify everyone you know about the latest and greatest Reddit posts, you can simply add more email addresses to the email_list.

Important side note: make sure the email you use to send the emails have less secure app access enabled if it’s a Gmail address, or this will not work.

Make it run forever

If you don’t have time to continually browse Reddit, you don’t have time to continually run this script. I used Heroku Scheduler to run this script every 10 minutes, as suggested by this Stack Overflow answer. It’s pretty easy to follow: add in a few additional files and a dummy web server, push to Heroku, add the Heroku Scheduler add-on, and BAM! You’re set until you run out of free dyno-hours. ??

Is this the best solution? No. But is it sufficient for my purposes? Yep. If you know of a similarly trivial way to do this, please let me know!

In conclusion

That’s pretty much all to this project. This GitHub repo contains all my code. Because of all the work that literally everyone else has already done, it’s quite a simple task to build this custom Reddit notification system. Gotta love the ✨magic✨ of software development.

Me after setting up my custom Reddit notifications

If you made it all the way down to here, please comment “North Dakota is the top producer of barley in the USA” in the box below.

Thanks for reading!

I’ve always enjoyed critiquing applicants’ portfolios at the design studio where I work. And I also often ask for feedback on my own designs on Reddit’s webdev subreddit.

So one day, I thought it’d be fun to unofficially review the portfolios of anyone who requested a critique. I had no idea what I was getting myself into.

I kicked things off by extending my services for free to the 120,000 people who read the subreddit.

Things started out quiet. I would play a round of Rocket League, and then there would be one or two portfolios to review. Then I went to sleep.

When I woke up, I had twenty requests. And these kept coming for three days straight.

In the end, I was able to recognize some common patterns and high/low points across the board. Let’s highlight these.

Note that this post is specifically talking about front end developers who want to join a design studio. If you have a different goal or audience for your work, this article may not be applicable.

What were the worst things I saw?

Truth be told, the r/webdev community did a lot better than my studio’s overall applicant pool. I think that speaks to how dedicated the community members are to their craft.

This doesn’t mean everyone’s portfolio was perfect, though. There were some common mistakes that were absolute no-no’s.

Always remember keyboard and contrast accessibility.

Accessibility was the biggest mistake made throughout the review. One of the first things I physically do with a portfolio is to try to navigate it without using my mouse. If that’s not possible, I know that the applicant doesn’t have accessibility on their mind.

Color contrast for text is also a big factor. I used to love putting white text on yellow backgrounds. I thought I was being hip!

But I quickly learned in the industry that users with low vision struggle to read text with poor color choices. If your eyes are not trained to watch out for low contrast yet, refer to the Center for Persons with Disabilities’ Color Contrast Checker.

Tip# 1: Some members of your target audience will have disabilities. Before writing any styling, make sure your HTML is accessible.

Stop trying to rate your own skills.

One trend that has plagued portfolio sites for years has been skill progress bars. You say you are 85% proficient at Angular? What does that mean? How does that compare to your 80% skill at Node? Most reviewers are only going to understand three skill levels:

• You don’t know the skill at all
• You’re still learning the skill
• You feel confident in the skill

Don’t worry about the first one. Just quickly tell me what you’re learning and what you feel confident in. All of this will be proven in your projects, anyway.

Go mobile or go home.

Want to know what many reviewers’ favorite thing to do with your portfolio is? We love opening your website and then immediately adjusting the browser window width back and forth. This tells us whether you give consideration to the plethora of devices your site could be browsed on.

Want to go beyond that minimum threshold? Then have your CSS written mobile-first. Writing mobile-first styling tells us that you like writing the smallest amount of code needed. When you stop at merely having media queries with a max-width property, it tells us that mobile devices were an afterthought in your design.

What did people need to prove?

Actual projects are the real meat of a portfolio website. They prove to me that you have the relevant work experience.

A resume or list of previous jobs is a nice timeline. But as a maker, your creation is the ultimate validation.

Here are parts of peoples’ project sections that made my life easier as a reviewer.

Show me the code and the live site.

You have a project description, process write-up, and talk about the technology used. That’s great, but where’s the code?

It’s common for industry hires to get caught up in private work projects. But without any opportunity to inspect your code, you’re making the reviewer’s job tougher. We’ll struggle to know whether it’s worth our time to move you on to the next step in a recruiting process.

If the code is proprietary, where’s the live site? If I can see your code, why would you not have a live version running?

Tip #2: Work on side and personal projects related to the same tech you use at work. Not only does it help you train for your current role, it also allows a portfolio reviewer to know where your skills are.

Tell me what you’ve actually contributed to.

Group projects are great to show how well you collaborate. Most projects will require teamwork skills.

With portfolios though, you need to be clear about what work you yourself have contributed. Github repos can provide a clear history for me to review your work and understand this group dynamic.

Honesty in your project write-ups is always appreciated. Don’t exaggerate your role within a project, because the people reviewing your portfolio will dive into a project’s Git history to double check ourselves.

Prove you don’t need Bootstrap or jQuery.

It’s understandable if you started learning CSS with Bootstrap or JavaScript with jQuery. The problem comes when all of your projects contain Bootstrap and jQuery.

Even though Bootstrap is convenient, I need to know that you have a clear understanding of CSS. I also need to know whether you have a solid foundation in plain JavaScript. This ensures that I’ll be able to onboard you onto a project with any combination of front-end tools already being used.

In fact, we don’t allow Bootstrap or jQuery at all during our interviewing process. So you’ll be more prepared for the future interviews and challenges if you have the appropriate CSS and JavaScript skills.

What stood out the most?

So we’ve gone over the things your portfolio needs and the ways portfolios can go wrong. What about the stuff that gets a reviewer excited about an applicant?

The following advice might seem a less concrete than my previous suggestions, but take it to heart.

Step away from the norm.

Almost everyone had the standard Intro > Skills > Projects > Contact flow to their site. Almost everyone had the exact same hamburger menu for navigation.

Do you want to get your reviewers’ attention? Get experimental and make small changes that do not harm the design.

One of the slightest differentiators had placed their navigation on the right side instead of the left. I knew it was time to focus more because the navigation was not on the cookie-cutter left or top of the layout. Simple, but effective.

Speak towards your dream job.

Have you seen that one position that you absolutely want? Build your portfolio around that job’s requirements and responsibilities.

It’s tough for me to understand why you want a job at our studio when your portfolio is full of WordPress themes. It’s also hard to think of you as a good fit for the role if your main focus seems to be a whole different industry.

We love generalists, but it’s a great plus to show that your speciality is also what the role prescribes.

Tip #3: A lot of portfolios are used both for job applications and freelance clients. Don’t do this. The best practice is for a professional to design separate portfolios for each of those audiences.

Every little detail matters.

Here is the toughest point for a lot of people: you can’t control what your reviewer sees on your portfolio.

We’re constantly scanning the website instead of reading it top-to-bottom. So make sure you have your layout styling perfected, each sentence proofread, and no broken links.

There’s no telling what part of your site the reviewer will actually take the time to look at.

You’ve got this.

I was proud of all the great portfolios I was able to provide feedback on, and the discussions that followed.

The most encouraging part was when front end developers were not yet up-to-par for our role, and I was able to give them feedback. These aspiring professionals took the critique seriously and positively.

That is exactly the kind of attitude I look for later in the process when I interview applicants.

My hope is that these people will improve, and I’ll have a chance to review their work again in the future.

P.S. I’m still getting back to late requests for portfolio reviews. Also, all of the portfolios in my opening image asked for the review publicly, and scored highly!

For further information: Feel free to contact me by the comments, email, or @seejamescode. I work in ATX for IBM Design and always love conversation with the web design community. Also be sure to share your own or favorite portfolio in the comments!