these posts aren't good either lol
This commit is contained in:
parent
8e74993346
commit
b38c8a01e3
SSH key fingerprint:
SHA256:YgoAbZ3x1d1kTGKEmT8elbjEvK/mn0hc4ATFgWhykR0
20 changed files with 0 additions and 410 deletions
|
|
@ -1,84 +0,0 @@
|
|||
---
|
||||
title: "[old] a new chapter"
|
||||
date: "2017-07-30"
|
||||
tags:
|
||||
- "english"
|
||||
- "life"
|
||||
- "productivity"
|
||||
- "startup"
|
||||
- "tech"
|
||||
---
|
||||
|
||||
> **disclaimer:** this post is really old, from when i first started writing. it's from 2017.
|
||||
|
||||
#### On new endings and old beginnings
|
||||
|
||||
I joined dev in December of 2016. It was my first time dealing with a working environment, and it's been a pretty awesome ride.
|
||||
|
||||
|
||||
|
||||
[Lennon](https://medium.com/u/57f86eb26cec) was doing a workshop on Ruby on Rails in Ecuador and noticed I wasn’t half bad with code. Or maybe he noticed I was terrible and needed to fix me up. I like to think it's the former, though. He offered me a position to do part-time work at dev remotely to hone my programming skills. It was a big commitment and lots of hours in Starbound were traded for it, but I agreed.
|
||||
|
||||
Working remotely was a unique experience. Being far away from your coworkers feels somewhat isolating, but you get the freedom of being able to do work at home, in your pajamas. I made my own schedule and worked my solid 4 hours a day after class, mainly working on the [devAcademy website](https://devacademy.la).(A lot of people say that staying in your pajamas makes you less productive, but I disagree.)
|
||||
|
||||
I worked part-time for a year before getting an offer to work full time for dev here in Peru. Moving to Peru was pretty daunting and the second largest move I’ve ever done, but it was worth it.
|
||||
|
||||
|
||||
|
||||
The move itself was pretty smooth, but took a long time. I had to take a bus to Lima, which took about 36 hours total. I finally watched Fight Club on the way there, though, so it wasn't all in vain. The trip was nice, and I received a warm welcome from the team once I arrived.
|
||||
|
||||
|
||||
|
||||
All of my coworkers were super helpful in helping us get settled in Ica. Without them, I don’t think we would have survived around here. I learned a lot about life in Peru! Living here in Ica was quite the experience. I’d definitely come visit here again. Ica is cheap to live in and a literal oasis in the middle of the desert. The people are nice, the food is great and I think I have a crippling addiction to [Chocotejas](http://perudelights.com/chocotejas-confections-from-the-desert/). They even celebrated my mom's birthday, which I think was super cute.
|
||||
|
||||
<figure>
|
||||
|
||||
|
||||
|
||||
<figcaption>
|
||||
|
||||
They call cake “keke” here. Top kek(e).
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
On the off-chance I wasn’t coding, I did tourism around Ica. I visited Huacachina, walked around the malls around here, and learned about the history of this little desert oasis. Ica is a bustling and growing place, and I’m glad to have been a part of it for as long as I was. It’s a great city to be in.
|
||||
|
||||
I also took some driving lessons! I only crashed, like, once.
|
||||
|
||||
|
||||
|
||||
Apart from life experience, I got a lot of work experience that I couldn’t have gotten anywhere else. I learned a lot at dev:
|
||||
|
||||
- I refined my skills in Ruby on Rails and JavaScript. Rails is my go-to for web development and JavaScript/Node is my go-to for other projects now.
|
||||
|
||||
- I learned a lot about emerging software like React Native. Sharing codebases across mobile OSes? Crazy stuff. I feel like this is the start of a new era for applications everywhere.
|
||||
|
||||
- I learned how to write code for Alexa Skills. I’m really excited to see how the Internet of Things evolves with new tech that allows us to interact with software in ways previously unimaginable.
|
||||
|
||||
- I figured out how to manage a social media account with over 7k followers and aggregate content that would promote users like you and me in the tech community. Probably the second scariest thing I’ve done.
|
||||
|
||||
- I learned how to work with clients on a 1 to 1 basis. Probably the scariest thing I’ve done, but I know that I’ll have to do it again soon.
|
||||
|
||||
- I learned how to code in, uh… Java, which wasn't my, uh… favorite… experience.
|
||||
|
||||
- I even learned about networking and setting up routers!
|
||||
|
||||
devAcademy has been a key stepping stone in the upwards climb to the best me I can be. I’m glad to have been a part of the team here for as long as I was. It was essential to me being who I am now. I’ve learned a lot about how to value my own work and the work of others while cooperating in a team.
|
||||
|
||||
I’m even more excited about code. It’s something I’m very passionate about, and working here at dev has cemented that for me. I want to build things that people can use and enjoy, and working here has been a learning experience through and through.
|
||||
|
||||
From what I’ve learned here at dev, I know that I don’t know everything, and I probably never will. But that shouldn’t stop me from pressing on forward and doing my best in whatever I know how to do now.
|
||||
|
||||
Someday I hope to work with Lennon once again, but for now…
|
||||
|
||||
New places to go.
|
||||
|
||||
New people to see.
|
||||
|
||||
New code to write.
|
||||
|
||||
New adventures to be had.
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 436 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 748 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 869 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 784 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 87 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 728 KiB |
|
|
@ -1,20 +0,0 @@
|
|||
---
|
||||
title: "FIRST"
|
||||
date: "2023-10-05"
|
||||
categories:
|
||||
- "miscellaneous"
|
||||
---
|
||||
|
||||
<figure>
|
||||
|
||||
https://www.youtube.com/watch?v=BQClqtVdqsw
|
||||
|
||||
<figcaption>
|
||||
|
||||
you dont understand i made a really cool website please give me back my 3ds
|
||||
|
||||
</figcaption>
|
||||
|
||||
|
||||
|
||||
</figure>
|
||||
|
|
@ -1,180 +0,0 @@
|
|||
---
|
||||
title: "[old] how to use github like a proper human being"
|
||||
date: "2016-08-01"
|
||||
tags:
|
||||
- "coding"
|
||||
- "english"
|
||||
- "github"
|
||||
- "programming"
|
||||
- "tech"
|
||||
---
|
||||
|
||||
> **disclaimer:** this post is really old, from when i first started writing technical articles. it's from **2016.**
|
||||
|
||||
<figure>
|
||||
|
||||
|
||||
|
||||
<figcaption>
|
||||
|
||||
[Founding Father Octocat v2 by James Kang](https://octodex.github.com/foundingfather_v2)
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
#### Learn some etiquette, man.
|
||||
|
||||
Our repo organization can suck sometimes. Here’s how to make it less sucky.
|
||||
|
||||
#### Commits
|
||||
|
||||
I’ve seen (and made) so many bad commit messages at [devAcademy](https://medium.com/u/e90784f3811e). We should really start to charge 10 cents for each bad commit someone makes one. We’d make [millions](https://www.youtube.com/watch?v=EJR1H5tf5wE).
|
||||
|
||||
<figure>
|
||||
|
||||
|
||||
|
||||
<figcaption>
|
||||
|
||||
100 million dollars, to be exact
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
We can settle this once and for all, though, by remembering a few guidelines when we commit anything on GitHub. And I mean **ANYTHING.** Personal projects, projects at work, even projects that you think will never see the light of day.
|
||||
|
||||
Once you get the habit of making awesome commit messages you’ll start doing them reflexively. You won’t have to put effort into making them. Your coworkers might like you more, too. _Might_.
|
||||
|
||||
<figure>
|
||||
|
||||
|
||||
|
||||
<figcaption>
|
||||
|
||||
reflexive\_commits.gif
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
When making a commit, I normally follow [this short list of guidelines by Chris Beams](http://chris.beams.io/posts/git-commit/), along with the [git style guide](https://github.com/agis-/git-style-guide). Here’s what I’ve learned:
|
||||
|
||||
- **Keep your commits atomic.** What’s this mean? [Fresh Consulting says](http://www.freshconsulting.com/atomic-commits/) that you should apply changes as you make them. Your commit should revolve around ONE change or fix. If you have to add an “and” in your commit message, you’ve already committed too much.
|
||||
|
||||
- **Keep your commit message under 50 characters.** Why? Shorter things are easier to read, like this sentence. Short and to the point.
|
||||
|
||||
- **Capitalize the first word your commit message.** This is seen as generally good conduct by most gitsperts. Sentence case is also more professional looking and easier to read. (See a pattern here?)
|
||||
|
||||
- **Don’t end your commit message with a period.** Leave people in suspense. Leave them wanting more. Also, you want to make sure your 50 characters are well spent.
|
||||
|
||||
- **Use an imperative commit message.** Make your commits sound like you gave a command to someone. Programming is normally defined as “ordering your computer to do things”, so might as well keep that reputation up, right?
|
||||
|
||||
- **Use the same language in your commit messages.** Most people seem to use English as their preferred language, but it doesn’t mean you have to. What you do have to do is be consistent. Don’t mix phrases in one language with another language.
|
||||
|
||||
<figure>
|
||||
|
||||
|
||||
|
||||
<figcaption>
|
||||
|
||||
DON’T DO THIS. PLEASE. NOBODY LIKES SPANGLISH.
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
“_Refactor mediumExample() function”, “Remove unnecessary line in bot.js”,_ and _“Add SASS gem to gemfile_” are all good examples of easy to understand atomic commits that describe the action you’re doing in 50 characters or less. They might seem like unnecessary fluff to you, but when you or someone else needs to find a specific change you made in the past, they’ll thank you endlessly.
|
||||
|
||||
#### READMEs
|
||||
|
||||
I’ve seen so many projects with lackluster READMEs it kind of makes me sick. This is supposed to sell your project. When someone reads it, they have to be interested in your project in seconds. Only after that, they’ll consider reading further into it.
|
||||
|
||||
Here’s what I deem are necessary elements in a README:
|
||||
|
||||
- **A header image (_somewhat optional_).** Give people something to look at. They need to know what your project is at a glance. Maybe show them a screenshot with a logo placed on top, those are cool.
|
||||
|
||||
- **A title**. People need to know what your project is called. Make it obvious and make it stand out so people will remember it.
|
||||
|
||||
- **Some badges (_optional_)**. [Badges are cool, right?](http://forthebadge.com/) These should be important things like a Travis build status, Code Coverage or a David DM check or something like that.
|
||||
|
||||
- **A short description.** Twenty words or less. This small sentence should summarize everything that your project’s about. It’s your tagline, basically. Sell your project.
|
||||
|
||||
- **A small list of features.** Four to five things that say “Hey, this is what’s cool about this project!”. Get people interested in your project with some radical things that your product does.
|
||||
|
||||
- **A _short_ summary of installation and/or usage.** Your app should not take 10 paragraphs to describe how to install and/or use it, and you shouldn’t have to write an entire manual to quickly show some people how it works. Write up the quick, TL;DR version of installing and/or using your project. Nothing fancy, just enough to get people up and running.
|
||||
|
||||
- **External links to more documentation.** You wrote documentation for your project, right? _Right?_ **_RIGHT?!_** If so, _please_ don’t include the entirety of it here. GitHub has Wikis for your project, which makes for a much better method of presenting content, as opposed to one huge Markdown file. Link to some important articles here in a nice bullet list.
|
||||
|
||||
#### Branches
|
||||
|
||||
This is simple. Keep your branch names somewhat descriptive of what’s in them. GitHub automatically names your fixes after a patch if you edit them online, so whatever, but when you’re offline and you’re using git on your machine, give a nice, descriptive name to your branch that’s less than 30 characters.
|
||||
|
||||
[This git style guide](https://github.com/agis-/git-style-guide) says that **you should use “short and descriptive” names**, and I feel that’s a good benchmark for naming. Use something like “rails-5-upgrade” or use it to refer to a specific issue on GitHub, like “issue-57”. Make your branch name tell a story with as few characters as possible and give a _super_ quick synopsis of what you’re doing on it.
|
||||
|
||||
Also, for the love of Torvalds, **keep your branches up to date with the master branch**. I don’t care if it’s a pain to do. Make sure that when you submit a PR, the owner doesn’t have to go through a million hoops just to merge your branch to master. Merge conflict? Fix it.
|
||||
|
||||
#### Issues
|
||||
|
||||
Let’s talk bug reports for a moment here. Have you ever tried to fix something without knowing what the problem was in the first place? Huh? What’s, that, you say?
|
||||
|
||||
<figure>
|
||||
|
||||
|
||||
|
||||
<figcaption>
|
||||
|
||||
That’s you. [That’s how dumb you sound.](https://www.youtube.com/watch?v=2nm5jl7aM08)
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
> You can’t possibly expect me to fix something without knowing what the problem was in the first place.
|
||||
|
||||
Exactly! So many people submit issue reports on GitHub without describing a damn thing. Be descriptive with your issues. It helps everyone out.
|
||||
|
||||
How do you honestly expect someone to help you out with your problem if you can’t even take the time to describe it? Here are some things you should include in a bug report to make everyone’s lives easier:
|
||||
|
||||
- **What you were trying to do.** What were the conditions that produced this error? Were you trying to run a command or navigate to a page? So many questions, so little time. Include some screenshots or a log, if you can.
|
||||
|
||||
- **What actually happened.** You know, how things messed up.
|
||||
|
||||
- **What you think went wrong (_optional_).** This screwed up somehow, right? Take a guess as to why.
|
||||
|
||||
- **How to reproduce your issue.**
|
||||
|
||||
- **Other _important_ details.** OS, Version of whatever you were using, some logs if you have them, some screenshots. Help us help you.
|
||||
|
||||
Now that we’ve got that out of the way, let’s talk about _replying_ to issues. Be nice. Say “please” and “thank you”. Just because someone submitted a bad issue doesn’t mean they’re a bad person. Being nice to people is the first step to getting them to cooperate. Try to solve their problem while asking for more information. Offer solutions, not more problems.
|
||||
|
||||
Project maintainers should probably use [issue templates](https://help.github.com/articles/creating-an-issue-template-for-your-repository/) on their projects with the above issue suggestions. They’re there for a reason. It’ll help your users make better issues and get you better bug reports/suggestions. Help them help you.
|
||||
|
||||
#### Pull Requests
|
||||
|
||||
Everyone likes a helping hand. Most of the time, though, people would like knowing _how_ you’re helping them. This applies to Pull Requests, too. By using your descriptive commit style and **adding a quick bullet list of the changes you made to their code**, you’ll catch the owner’s attention and make them want to merge your branch faster.
|
||||
|
||||
I mean, why am I going to add your code to my awesome project if I have no idea what it does? You don’t have to write an essay on why these changes are for the better, but at least **give a short description on why your code is going to benefit the project.**
|
||||
|
||||
Also, project maintainers. **_Thank your contributors_**_._ It’s a simple gesture that goes a long way. This person put time and effort into helping your project, and even if it was only one line of code, _thank them._ Doesn’t matter if their code is awful, thank them for the time that they took to help out with your project. [We’re all in this together](https://www.youtube.com/watch?v=gbrbUfYSt0E), right?
|
||||
|
||||
#### Now…
|
||||
|
||||
I’m betting you’re going to go to [my repos on GitHub](https://github.com/thattacoguy) and start [yelling at me on Twitter](https://twitter.com/that_taco_guy) about how I don’t follow my own guide. You’re right, I’m not right now; I wrote this up as a guide to follow to make better commits based on what seems to be hip and trendy now. Let’s get better together!
|
||||
|
||||
* * *
|
||||
|
||||
### If you really liked this post, be sure to click that little green heart so that others can find it!
|
||||
|
||||
<figure>
|
||||
|
||||
|
||||
|
||||
<figcaption>
|
||||
|
||||
Just do it. You know you want to. ❤
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 8 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 373 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 91 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 464 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 549 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 329 KiB |
|
|
@ -1,126 +0,0 @@
|
|||
---
|
||||
title: "[old] whitespace"
|
||||
date: "2016-12-25"
|
||||
tags:
|
||||
- "design"
|
||||
- "english"
|
||||
- "productivity"
|
||||
- "tech"
|
||||
- "ux"
|
||||
---
|
||||
|
||||
> **disclaimer:** this post is really old, from when i first started writing technical articles. it's from 2016.
|
||||
|
||||
<figure>
|
||||
|
||||
|
||||
|
||||
<figcaption>
|
||||
|
||||
breathe.
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
#### Because everyone needs to breathe.
|
||||
|
||||
Everyone has experienced stress in their lives in some way or another. For most people, the easiest ways to relieve some sort of stress in their lives is to take a break and step away from any information for awhile.
|
||||
|
||||
One of the genius innovations in design that’s gotten popular lately is one I’m real glad that exists today:
|
||||
|
||||
> Whitespace.
|
||||
|
||||
Believe it or not, you experienced whitespace. The simple action of separating text using a new line to let one word take the center stage makes a difference.
|
||||
|
||||
#### What is it, really?
|
||||
|
||||
Whitespace can be defined as space where there is nothing — empty space. It’s a separation between your sections of content and the borders of the viewport you’re displaying things on. It allows for specific images or words to stand out because they’re separated from the rest of the content. Users can specifically focus on one piece of information.
|
||||
|
||||
[Gisele Muller](https://medium.com/u/6b4913453525) [describes it well:](http://blog.teamtreehouse.com/white-space-in-web-design-what-it-is-and-why-you-should-use-it)
|
||||
|
||||
> “It’s the space between graphics, columns, images, text, margins and other elements. It is the space left untouched in order to smooth things out and transform a page into something elegant. It is also the blank space that reminds us that simpler designs are beautiful and that we don’t need to create a layout filled with text and graphical elements to deliver a clear and direct message.”
|
||||
|
||||
#### But… why?
|
||||
|
||||
Information is important, but you can’t expect someone to consume whole paragraphs of information in seconds. Structuring information in a way that users can digest each snippet of information. That’s the key element to using whitespace.
|
||||
|
||||
|
||||
|
||||
Users need to understand what your message is at a first glance. If someone viewing your app or website can’t understand the meaning behind your site quickly, they will leave. Closing a web page or app is the easiest way to avoid confusing things that users [don’t have time for](https://www.youtube.com/watch?v=bFEoMO0pc7k).
|
||||
|
||||
> If someone viewing your app or website can’t understand the meaning behind your site quickly, they will leave.
|
||||
|
||||
Users don’t care much about the flowery prose that your message is contained in, rather the actual message itself. Modern designs for websites only focus on images and quick phrases, or only display words that convey what the focus of your project is about.
|
||||
|
||||
Your focus should be on making sure that the core idea behind your content hooks the user in to consider looking at the rest of the page. If you have space that allows for information to be presented in bite-sized portions, users will remember you better. Key words and phrases are what users are going to know you by, not specific details. It’s how our brain stores information. Cut out the middleman and filter out unnecessary words and sentences.
|
||||
|
||||
#### Whitespace in web design
|
||||
|
||||
Google is probably my favorite example of whitespace in modern designs.
|
||||
|
||||
<figure>
|
||||
|
||||
|
||||
|
||||
<figcaption>
|
||||
|
||||
Yeah, Quechua. I was surprised, too.
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
Google’s front page gives you a limited amount of options to work with so that you don’t get confused. The whole website is centered around searching things, and your focus is centered on the content in the middle. The gentle shadow behind the search bar lets you know that it’s more important than the other elements.
|
||||
|
||||
The two buttons you’re immediately given access to ease you into the design — you have power over what you do! You can search for many options or try your luck and go to the first result for your query.
|
||||
|
||||
This way of spreading out the options you have lets you analyze what you need when you need it. Nothing is intruding your vision or forcing you to squint to read anything. You have enough time and ample room to digest what’s being presented to you. It feels natural to use Google’s search engine because there’s little guesswork in what you can and cannot do. Everything is spaced out and there’s never a place where content feels crowded.
|
||||
|
||||
#### Whitespace in programming
|
||||
|
||||
Whitespace isn’t only limited to design. Utilizing whitespace in your code is important. Your code should be legible and spaced. The fact that it could be a project that never sees the light of day is irrelevant. Your code should make sense and nested functions should have proper spacing.
|
||||
|
||||
Everyone has differing opinions on whether to use tabs, 4 spaces, 2 spaces or any other combination of separation of characters. I use 2 spaces in my projects, but that’s my personal preference. What does matter is that you use spacing to make your code stand out and appear readable to other people.
|
||||
|
||||
Take a look at this HTML code:
|
||||
|
||||
```
|
||||
<!DOCTYPE html><html lang=”en”><head><meta charset=”UTF-8"><title>This is an HTML document!</title></head><body><div class=”row”><div class=”col m5">Some content<div class=”row”><div class=”col s12">Some nested content</div></div></div><div class=”col m5">Some other content (woah)</div><div class=”col m2">Even MORE content</div></div></body></html>
|
||||
```
|
||||
|
||||
Yes, it’s an HTML document, but there’s no real implication of what goes where. Everything seems like it’s on the same level. Tags could appear nested, but you’re not sure which one does which. Someone else might not want to touch this — they’ll be worried they’ll break something in the layout. Applying some whitespace to this code demonstrates the following:
|
||||
|
||||
```
|
||||
<!DOCTYPE html><html lang="en">
|
||||
```
|
||||
|
||||
```
|
||||
<head> <meta charset="UTF-8"> <title>This is an HTML document!</title></head>
|
||||
```
|
||||
|
||||
```
|
||||
<body> <div class="row"> <div class="col m5"> Some content <div class="row"> <div class="col s12"> Some nested content </div> </div> </div> <div class="col m5"> Some other content (woah) </div> <div class="col m2"> Even MORE content </div> </div></body>
|
||||
```
|
||||
|
||||
```
|
||||
</html>
|
||||
```
|
||||
|
||||
Woah! There was a whole collection of divs that had nested content hidden in our non-whitespaced code! Storing the code this way makes it so that other people working on this static HTML page know how the page is really structured. It makes it so that people aren’t intimidated to dive in and help out with changing details in code. (also it’s common human decency)
|
||||
|
||||
This doesn’t just apply to HTML. This applies to practically any programming language out there (except the [esoteric ones](https://en.wikipedia.org/wiki/Whitespace_%28programming_language%29)). Most languages have some sort of “beautifier” or “prettifier” to make your code seem legible and spaced out.
|
||||
|
||||
Knowing what lines of code are on the same level and what variables are accessible where is important in the long run. When you’ve got 100+ files of code and hundreds of functions, you need to be able to parse your code easier. A simple glance should be all it should take to know where a variable or function is located in relation to everything else.
|
||||
|
||||
#### Whitespace in your life
|
||||
|
||||
[Jason Fried](https://medium.com/u/c030228809f2) mentions in many of his posts that Basecamp, as a company, strongly encourages its employees to only work 40 hours a week. He also mentions that taking a few hours a day to yourself is important. [Jon Westenberg](https://medium.com/u/5ce28105ffbc) also mentions that you should “[slow the fuck down](https://medium.com/hi-my-name-is-jon/you-are-more-than-your-productivity-slow-the-fuck-down-6ed7c4be3fcc#.k88geuntv)” and take life one step at a time.
|
||||
|
||||
|
||||
|
||||
In today’s bustle of constant information, sometimes we forget to take some time for ourselves. It doesn’t matter how many hours of work you do in a day, the final product matters. The quality of a product is more important than the time it took to make it. This time to generate a quality product is different for everyone.
|
||||
|
||||
Take some extended periods of time to do something that relaxes you. I normally take time to myself to play some games or catch up on reading Medium articles. Everyone’s ways of relaxing are different, but make sure you make whitespaces in between the hustle and bustle of the day to breathe.
|
||||
|
||||
You deserve it.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 77 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 9.4 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 24 KiB |
Loading…
Reference in a new issue