I’ve been tinkering with OKRs since before I joined Google, and there are aspects of it that I really like. I’ve tried a few personal ones over 2019 but they have not been successfully tracked and/or completed. I’m going to do this round publicly and see if that helps.
A few notes:
I’m not including family things here because spending quality time with them is table stakes.
These are all basically 100% goals, so they are not *too* aspirational, and I intend to hit them all.
I wrote these up at the end of last year, and have been working on them, but haven’t gotten around to posting them!
The target date on these is June 30, 2020 (hence the H1 – Half One).
OKR 2020A: Reclaim Technical Familiarity
I’ve spent the past few years exploring new areas (maps, networks, C++) and want to brush up on what I was doing prior to that. I also want to do a better job staying better informed of new developments outside the comfy walls of Google.
KR1: Get a full stack project “running”
Running here means that someone (almost certainly not the public) can log in and do stuff, probably play a game although there are other candidates.
KR2: Publish 15 Technical Blog Posts
Media reviews and personal updates (like this post) don’t count, I’m unofficially shooting for about 15 of those too.
KR3: Learn (and do something useful with) a new language
Spoiler alert: this will probably be Go.
OKR 2020B: Finish More of What I Started
I like finishing things, but I love starting things. If I’ve not finished something it’s rarely because I didn’t want to* and almost always because I’ve started something else. I’d like to improve my discipline and wrap up a few things that will unlock starting lots of new things.
* Although I have gotten better in recent years about quitting some things earlier, like TV series that go downhill.
KR1: “Finish” my Woodshop
Like software, no workshop is ever really finished, there’s always room for improvement, but I’m pretty close to having no unfinished setup/projects in my shop. Some specific goals are:
Finish Painting – It’s an unfinished basement and the walls were mortared by not painted and the floor is concrete, none of which was painted.
Install New Wiring – The wiring is actually pretty easy, but a prerequisite is (an electrician) installing a new subpanel, which requires building a wall to put it on.
Install Dust Collection – I have a small unit now with a flex hose, but I’d like to get a larger unit with some fixed ductwork.
KR2: “Finish” my Home Office
We moved about 18 months ago and while all (or very close to it) of the moving boxes have been unpacked, my office has yet to really come together. This is in large part due to the fact that I don’t work from home much anymore, so it may be up to 2 or 3 weeks where I don’t even set foot in it, but I would like to maximize the time I do spend there by having it be a pleasant space.
OKR 2020C: Improve My Health
What personal improvement list would be complete without some health goals? These are not easy but seem to strike a balance of achievability and meaningfulness.
KR1: Lose 20lbs
I’ve been doing intermittent fasting over the past 6 months and have slow but steady success with it and am on the verge of classifying it as a permanent thing. More to come on this later.
KR2: Hit 150 Move Goals in Apple Watch
That basically means hitting it slightly more than 5 times per week, which seems pretty doable. A perfect streak is pretty difficult considering my job is at a desk, with occasional travel, and the occasional cold my son has been bringing home now that he’s going to school.
I accept what The Algorithm decides my target is, it’s been as high as 1200 calories and as low as 800. It’s currently at 890 since I was slacking over the holidays.
KR3: Do 5,000 Pushups
That’s 25-30 per day averaged out, but that’s a little high right now, and I’m hoping by the end of this I’m doing 50-100 per day.
Addendum: Themes
I recently came across a video by CGP Grey about new years resolutions and I liked his idea of themes. I admit that having specific targets like these kind of goes against the whole idea of holistic themes, and I didn’t really have a theme in mind when drafting the OKRs, but I think they can actually work well together. It appears that there is a latent one here that is about laying the groundwork for future improvements. If all goes well:
I’ll have a little side project going, which always gives me a boost at my day job.
I’ll have two great workspaces from which to tackle new projects, software and otherwise.
I’ll be in better health and have more energy and drive to do those projects. Bonus: The onsite gym at work re-opens in May and I should be a much better position to use it well!
Therefore, I will declare the theme of 2020H1 to be Infrastructure.
Watchmen Season One metamorphosed from a set of intriguing stories that were scattered in a way I was afraid Lindelof (Lost) would bring, to a tight, coherent and moving conclusion that was smaller but superior to the books (read them first) or movie. The season stands alone, though I would like another.
So the side project I mentioned a few posts ago is still just an idea, before I start building it I will need to pick a stack. I’ve been out of the non-big-tech loop for a while (one of the main drivers for this project) so this may take a while, but should be a fun experience.
The last time I picked a fresh stack was late 2013. We were building Mondogoal and needed to get to market very fast on a limited budget. We started in late November 2013 and needed to be in beta by March, and ready to launch (and get a gaming license!) in time for the 2014 World Cup that started in June. With two developers.
Somehow, we made it, and I think that one of the main factors was in how we picked our stack. In short, we kept things as boring as possible. The backend was all stuff I could do in my sleep: Java 7 with MySQL, using Maven and Spring, running on Tomcat in a mix of AWS and Continent 8. The only significant piece that I didn’t know well was Obsidian Scheduler, which is a fairly lightweight job scheduler, and we added Firebase later on. The frontend was backbone with a grunt build, which had been out for a while. This stability and going down well-trod paths let us focus on executing the business and product instead of tinkering and I doubt we would have been able to hit our deadline if we’d opted to explore some of the cool new stuff that was coming out. While the business didn’t succeed long-term, I have no regrets about those choices and can assign no blame to what we built it on.
Luckily, this new project has no deadline! It’s mainly a vehicle of exploration for me. I would definitely like to launch it, but if that takes months (unlikely) or years that’s OK. Let’s recap the “requirements” of this project:
Learn how to build a modern front end.
Give me a reason to explore the Google Cloud offerings (since those products are effectively my customers for my day job).
Get back up to speed on things like analytics.
Scratch an itch I’ve had for a long time (a nerdy economy-based game).
Doesn’t risk any conflict with my day job.
Give me something to blog about!
#2 is going to make some of these decisions easy. As a loyal dogfooder and company man (despite the lack of employee discount…), I will default to Google Cloud where possible. A quick check puts most of the basics on par with Amazon as far as cost goes. If GCP doesn’t offer it, then it’s up for grabs. Let’s start picking!
But wait…what is and isn’t part of The Stack?
I take a broad view of the term, to me The Stack is basically everything in the shop. You could (and I might in a future post) break this down into groups (tech stack, marketing stack, etc.), but to me if it’s a part of making the business run and it’s something you didn’t build yourself that you expect employees to get or be skilled at, then it’s part of The Stack. This includes everything from Java or Python to Salesforce and Gmail.
Domain Hosting
Winner: Google Domains
Cost: $14/year
Status: Up and Running
Initial Thoughts
I’ve got domains hosted at lots of places. GoDaddy, Namecheap, Hover, OpenSRS, I even still have one at Network Solutions. Compared to those, registering on Google was a pretty painless process. The pricing is more transparent than most other places (no first-year rates that go way up later). They also didn’t upsell junk I don’t need too hard. Setting up G Suite was also pretty easy (as you’d hope), I had it all running in like 15 minutes without touching any DNS entries.
To dogfood even deeper, I’m using a .app TLD, which Google owns, and was a few bucks cheaper than the other registrars.
Email Hosting
Winner: G Suite
Cost: $5/user/month
Status: Up and Running
Initial Thoughts
As most of us are, I’m pretty familiar with all of these tools, and I’m pretty sure most surveys would have Gmail at the top of people’s preferred email services. As a bonus, setting this up was super easy since the domain is also with Google.
Compute Servers
Winner: Kubernetes/Compute Engine
Cost: TBD
Status: Exploration
Reasoning
There were two things that came up in virtually every conversation/interview I had during my last job search, React and Kubernetes (AKA K8s). Virtually everyone was using these or trying to move to them. I’ve never touched K8s, so combined with #2 above, I feel like I should play with it.
I have used App Engine, and I assume non-K8s Compute Engine is pretty similar to AWS’s EC2 which I’ve used quite a bit, so I will fall back to those when it makes sense to do so.
Backend Language
Winner: Java
Cost: Free
Status: Defrosting
Reasoning
I am a moderately capable but generally reluctant programming language polyglot. My first employee profile badge at Facebook was “Committed Code in 5 Languages”. But I’ve never bought into “pick the best langauge for the job” and tend to favor the approach of “pick the best language for all the jobs”. This offer does not extend to JavaScript backends.
Java was my primary language from probably 2000 through 2016. Since then I’ve mostly been writing C++. I’ve grown to like the language, it is lightyears better than it was when I started writing Java, but I’ve never worked in it outside of the padded walls of FB/Google’s infrastructure, and to be honest, am not terribly interested in doing so.
While we upgraded our runtimes to Java 8 at Mondogoal after a bit, we never got around to really using any of the features, so I’m effectively only up-to-date through Java 7, and would like to explore the recent additions. There are also some new parts of the Java ecosystem that are worth exploring, like Quarkus and GraalVM.
Also, I just kind of miss working in it.
Runners Up
There are two languages I am interested in tinkering with, once I’ve warmed back up on Java: Kotlin and Rust. They both have had a pretty good reception and have some attractive features. Kotlin as a JVM language should be easy enough to experiment with. If I can find a task that would benefit from Rust I will probably give it a shot.
IDE
Winner: IntelliJ IDEA Ultimate
Cost: $149/$119/$89 for years 1/2/3+
Status: Trial
Reasoning
I initially wrote Java in emacs, then JCreator, then switched to Eclipse c2002 and used it through 2016. I’ve tried IntelliJ a few times over the years but never really got the hang of it or saw a lot of value in it.
However, Google does quite a bit of Java work, and their primary and only fully supported IDE for it is IntelliJ. I’ve also been using CLion (basically IntelliJ for C++) and it’s been OK.
The “Ultimate” edition of IntelliJ includes support for other languages and even React so that’s a strong argument in favor of trying it out. I’m not opposed to ultimately landing on using different tools to work in different languages (e.g. I often used Eclipse for Java and Sublime for JS), but if you can do it all in one, that’s nice.
My Eclipse muscle memory is very strong, so I expect this to be somewhat painful transition, but I will give it as fair a shot as I can manage.
Java Build
Winner: Gradle
Cost: Free
Status: Exploring
Reasoning
There are only two real choices here: Maven and Gradle. And given that Gradle uses Maven-style repositories, they aren’t even that different in many respects.
Maven
I’ve used Maven for many years, since Ant, and like most people had some struggles with it initially. I eventually learned to coexist with it, or at least avoid its sharp edges, and would just copy/paste my pom from one project to next and had minimal issues.
Gradle
Gradle has three main “advantages” over Maven that people seem to crow about.
One is that it’s written in Groovy, and you can therefore script your build and do advanced stuff more easily than writing a Maven plugin. I would put this in the Probably a Bad Idea category, like stored procedures. I bet there are some cases where this is useful, but probably far more where it’s a kludgy workaround to some other problem people don’t want to solve.
The second is that it’s written in Groovy, which is not XML. I always thought XML was nice when used properly, and that config files were one of those proper uses. However, something about it causes a primal aversion in many people and they convince themselves that things that are not XML are inherently better than things that are.
The third is that you can do different build versions more easily, and this one I get, especially in the context of things like Android apps. Given that I might be targetting different JVMs (regular and GraalVM) this might be useful, but probably won’t be.
So I’m not really impressed with Gradle either, but given that there are literally only two choices, I might as well know both. It’s pretty trivial for a small project to switch back or even run both, so this is a pretty low-risk experiment.
Source Control
Winner: Git + Monorepo
Cost: Free (plus hosting)
Status: Up and Running
Reasoning
I think there are only 3 real options these days for version control that don’t fall into the “never heard of it” category for most people.
Git
The dominant force, and the only one that many developers know these days.
Mercurial (hg)
I have grown to prefer Mercurial in a code-review + monorepo environment since starting to use it at Facebook. Implicit branches and easy commit management map very well to the “commits should do one thing” best practices as opposed to the pull request pattern where mainline commits should favor comprehensiveness. For a solo project this isn’t relevant and it’s basically the same thing as Git.
Subversion (svn)
For solo/small teams, SVN is totally fine, it’s basically how you’d be using a DVCS anyways, but if you don’t have a server running already then it’s probably not worth setting one up.
Mono vs. Multi Repo
For large organizations, monorepo is the clear way to go for reasons I can discuss elsewhere. For solo/small teams, it doesn’t really matter, and it *might* be better to split up your repos if you have a *very* clear separation (e.g. front/back end), which is how we did it at Mondogoal, but I would say to start with a monorepo and only split if there is a compelling reason to do so (e.g. regulations, licensing).
I’m going to call this a toss-up between Git and Mercurial and give Git the edge due to the fact that it’s massively more popular and more likely to integrate well with other things like IDEs and deployment tools.
Source Control Host
Winner: Google Cloud Source Repositories
Cost: Free to 5 users & 50GB storage/egress, then $1/user/month and $0.10/GB/month
Status: Exploring
Reasoning
Given that I’ve chosen Git, GitHub is the obvious first choice here, but since Google has a product we’ll invoke requirement #2. This also might integrate better with the other services I’ll be using, though I have barely researched that beyond the marketing.
One of the nice things with Git is that it’s trivial to multi-host, so if I ever find a compelling reason to also use GitHub, I can use both or just switch.
Next Up
There’s a lot left to do here, databases, frontend, and more. Stay tuned!
When starting a new company or project, one of the most daunting phases is selecting a stack. There are lots of things that factor into the decision, and anyone who has done this before will attest that you will make some bad choices, and some of those will be nearly impossible to undo, especially if you’re successful. Some questions to consider:
What do you already know/love/hate?
When considering your options for some piece of the stack, it is totally reasonable to award points to things you know and love, and deduct points from things you know and hate. It is, however, not a good idea for this to be the principal factor. You should be able to defend your favorite choice against the others objectively and quantitatively, not solely on the basis of “it feels better” or “I know it already”.
Are you just trying to execute a business/goal or are you trying to explore and learn something new?
One of my two virtues of engineering is curiosity. Throughout your career, you should always be looking for opportunities to explore new ideas, new tools, new methods. If this is some moonlight or passion project, actively try to weight new and unfamiliar things higher. If this is a major venture with lots of other people’s time and money, there is just as much to be gained from leveraging your experience and going for flawless execution of things you’ve already worked out the kinks on.
If you have teammates, what do they know/love/hate?
This is a case where you should set the hierarchy aside and try to get everyone’s opinion. If you’re a senior engineer or architect you can bring experience to the table but don’t discount the novel approaches and backgrounds of your teammates, regardless of their experience. We so often get stuck in our ways, even after only a few years, and avoid novelty and diversity in the name of risk.
Are you going to need to hire/outsource the work?
If your plan involves getting dozens or hundreds of people on board in the near future, you’re going to want to lean to the more popular/vanilla options. Trying to hire 300 people in the next 12 months to work on your Erlang/Neo4J stack running on an Arduino cluster is going to be much harder than getting people to do Java/MySQL on AWS.
Are you building a prototype, an MVP, or a “real” version.
Deciding, and more importantly understanding what you’re building is a topic worth exploring on it’s own, but roughly speaking you’re building one of three things:
The Prototype
You just need to get something “working” to explain your idea or your solution. Unless you’re doing something truly revolutionary (p99.999 confidence spoiler alert: you aren’t), try to prototype your idea/business/product OR your technology, not both at the same time. Also really commit to throwing this away and starting over with a proper plan if there is promise. I’ve seen/had too many prototypes turn into projects that have a pile of technical debt before they even really start.
The MVP
I feel the MVP is overused, and too often is an excuse for a poor quality product or a starved team/budget. You obviously want to iterate, and if you want to call your first release an MVP for buzzword sake, go ahead, but don’t write throwaway code unless you’re committed to throwing it away (see prototype above). I’ve lost count of the number of companies and projects I’ve talked to that are rewriting their Rails or Django app because those seemed like easier paths to an MVP and “now we just need to scale”. That’s like saying “I’m going to get a job, but then I’m going to go and get a completely different job that actually pays my bills.”
If you are truly building an MVP, then your process for stack selection is no different than building the real version, it’s just prioritized more aggressively.
The “Real” Version
The first step here is to figure out, as best as you and your team can, what the successful (often AKA profitable) version of your app/system looks like. Do you need 100 users to break even? Do you need a million? If you need a million, don’t spend a single minute building something that only works for hundreds. If you need 100, don’t spend any time building it for 1 billion (unless you get that for no additional work, E.G. something like Amazon S3).
What features are truly required to hit that goal? Make sure there is a place for them in your architecture even if you don’t plan to build them right away. Do you need support and sales teams to be successful? Make sure you’re putting hooks in for the tools they will need (E.G. CRM, ticketing, admin consoles).
What can you get “for free”?
Everything has a cost, in terms of time, money, people, etc. but those costs are not always the same across companies and projects. Your team’s experience can discount learning curves, your company may already have investments or licenses for things. Never use something just because it’s free, but make sure that is a part of your decision.
If you’re at a larger organization with a number of teams, consider if there is a team supporting certain aspects of what you might use. If there is a logging system that is in place and ready to go and has its own support, it’s should be a hard sell to build or buy or set up a new one just because of a few features. Often that team will even build what you need!
What are your competitors using?
Competitive analysis can be difficult, most software companies don’t go too deep on what they are using for any given situation, but that information can play a large part in your decision. If you find a conference talk where they talk about what they tried and had good or bad results from, you’ve possibly just saved yourself a lot of pain. You will often just get a lot of good ideas (“I never considered using X to do Y”), or pointers to things you’ve never heard of.
You might also find some competitive advantage. If they are using something you know is difficult to change or won’t scale well, make sure yours can beat them in those aspects. By the time they realize you’re about to pass them it might be too late for them to adjust.
What will fail first?
As you’re building your stack, know where the weak points are, and don’t be shy about circulating that information. If you can’t get to your target latency because some component will use 90% of that budget, try to find a replacement early rather than assuming you can plug something else in later. You should be confident that all of your core components can hit your targets, and if you aren’t sure, validate that now. You’ll find that the interconnected nature of systems will often lead you to replacing more than one piece at a time, which only makes it less like you’ll be able to do it, and more likely to fail.
What else?
Picking a stack is harder, and takes more time, than most people realize. I’m sure there are other things to consider and I’ve love to hear your thoughts on this in the comments.
So you’ve got an idea. Maybe The Idea. You need to do it, and you need to start now, maybe you already did. Here is a list of things to do, or at least keep in mind before you get too far. They mostly won’t slow you down, but in the event your project actually takes off, I guarantee this will pay off in the long run in terms of saving money and time and avoiding hassle and heartbreak.
Many of these steps (especially the early ones) apply to any business or project, but my experience lies mostly in software so this list is tailored to that.
Note: This is a living post, in that I intend to come back and update it when there is more to add, so be sure to bookmark it somewhere!
Step 0: Clear It!
If you are a knowledge worker or work for a company big enough to have HR or lawyers, you probably had to sign something when you got hired that assigns ownership of inventions/copyright/patents/etc. to the company while you are an employee there. If your thing ever becomes valuable, that will matter. Do not rely solely on the fact that your state has laws about this or that you think management is reasonable. Write up your idea in a reasonable amount of detail and get a waiver in writing from the company. Most good employers will have no problem with this if it’s not related to their interest and the better employers will even encourage this as a way for you to grow and hopefully bring some energy and new experiences back to your job.
Do not do anything until you have this in place. Don’t write code, don’t register domains, don’t collaborate with others about business models, nothing that could come back and see your efforts snatched in a lawsuit. The bigger your company, the more important this is as they have broader interests and more lawyers.
Step 1: Name It
Names have power. If your idea doesn’t have a name, it will struggle for attention and likely wither away. Your name doesn’t have to be permanent, you can give it a codename, but name it something.
Domains
If you think this might turn into a real thing someday, align your name with your domain. It doesn’t have to be a perfect match, but close enough. Even if you’re not planning on building a website (e.g. an app, etsy store, etc.), you’re likely to build one eventually or at least want an email address for it.
If you can’t get the .com domain because a possible competitor has it, pick a new name, not a different TLD (e.g. .net, .io, etc.)
Codenames
Codenames have a knack for survival. They will be around in some form for the life of your project, in documents, emails, code comments, and so on. Don’t call your new project something embarrassing or offensive because “we’ll change it later”. You’re better off picking something meaningless and common like “Green Tea” or “Fortitude” if you can’t come up with something better.
Social Media
Once you’ve got a name and a domain, set up whatever social media accounts/pages/handles you think are relevant. They don’t have to be perfect matches, but the closer the better. You don’t want someone else to do it for you, as it can be impossible or expensive to get it back.
Step 2: Register It
If you’re in the US, and you think your project will generate any revenue or expenses this year, you’re better off to get it set up as a business as soon as possible. It’s pretty easy and cheap to do so.
If you’re doing this with other people, you’ll want to set up a partnership/LLC/Corporation. Even if it’s family, get this taken care of now to avoid tears later.
If you’re doing this by yourself, go to your city/town hall and register as a DBA. There generally isn’t a penalty for not doing this, but it may come in handy later when setting up things like bank accounts or making commitments like contracts or commitments.
Once your entity exists, go get a tax ID. As a sole proprietor this isn’t required, but it’s free to do it and will keep things better separated down the line.
More to Come…
I’ll add more to this list later, but if you can get those steps above done before you invest too much, you can proceed with far more confidence that you’re not forgetting something important.
I’ve spent the last few years sequestered away in “big tech” which has been an interesting and mostly positive experience, but one of the more unexpected side effects, especially as an extreme generalist, has been the specialization on the technical side of things.
From when I first started coding for money in the mid 90s I was always a true “full stack” engineer, even before that was a term. Give me a bare server and a sketch and I could handle the rest, even some basic UI design. As backends became more complex and interesting I gravitated that way, but was still pretty up-to-date on front-end technology for a nearly 20 year stretch.
The front end world got increasingly difficult to keep up with on a casual basis as single page apps became a thing and powerful frameworks took over. At Mondogoal I was entirely back-end from late 2013 onward, although I was also the product owner and oversaw design and branding. At Facebook I worked on maps and geocoding, writing mostly backend C++ code. At Google I’m deeper yet, working on the networking team.
During my last job search I initially still had “full stack” on my resume, but realized that I didn’t think I met that bar any more, namely because I didn’t really know any of the things most people were using these days, like React or Angular. My skills in that area, (e.g. jQuery), are no longer in demand at places I’d want to work for, supplanted by experience with scalability and distributed systems.
And don’t get me wrong, I have no regrets about this, at all. Back-end experience and knowledge decays much slower than the front-end, so now that I’m often the oldest person in the room, that’s a feature, not a bug. Back-end work also tends to pay more and offer more paths to leadership roles. But I think I’m still a full-stack developer at heart, and the deeper I go the more wistful I get for being able to make something you can see and touch.
Enter, the Side Project
I haven’t had a software side project in years. With all that’s been going on, especially becoming a parent, my energies have been allocated elsewhere. But there’s been an increasingly more noticeable hole there that I need to fill.
I brainstormed a few ideas and kicked them around until one of them, a browser-based game, settled out that checked off most of the boxes:
Learn how to build a modern front end.
Give me a reason to explore the Google Cloud offerings (since those products are effectively my customers for my day job).
Get back up to speed on things like analytics.
Scratch an itch I’ve had for a long time (a nerdy economy-based game).
Doesn’t risk any conflict with my day job.
Give me something to blog about!
Now what?
I’m going to talk about this in more detail in a future post but after spending a bit poking around the current front end world, I feel like I’m basically starting over. React, Angular, Vue. Yarn, webpack, JSS. The list goes on and on. Even my JavaScript is out of date, with all of the additions over recent years, and TypeScript being a serious option now (it was still kind of a toy last time I tried to use it back in 2012/2013).
This is a bit intimidating, but more so exciting. There’s so much to learn I haven’t even really started to think about the actual project or how feasible it will be to launch. Stay tuned for updates!
Hello again! It’s been a long time, nearly 4 years since my last post. While not writing blog posts, I, in order:
Lost my dad.
Had a child.
Went to work at Facebook on maps.
Lost our cat Cory.
Moved to a new house.
Lost our dog Maddie.
Got a puppy, Archie.
Left Facebook and now work at Google on networks.
I’ve thought on and off over that time about the blog and how I enjoyed writing for it, and recently resolved that once I got settled in at Google I would resume. I hereby commit to 5 more posts in 2019 and at least 30 in 2020!
When I was growing up, people often asked me who my “role model” was. Saying “I don’t have one” would lead to strange looks or awkward conversations, so I would typically say “Bill Gates” or “Wade Boggs” or some other easy answer. Those weren’t lies, I did admire certain facets of these people, but I certainly never emulated them. A few years ago, decades past the point where people ask me that question, I realized I finally have an answer.
I’ve been lucky enough to have several great dogs in my life, all of whom have been very unique, but Stella is, unexpectedly, the closest thing I’ve ever had to a role model. I admire, and try to emulate, how much she lives in the moment. Her ability to grasp the excitement, or the mystery, or even just the simple peace of any given moment is amazing. Even at 6 years old, she takes every minute as a new adventure. I am not, nor will I ever be nearly as effusive as she is, but I do find myself noticing and appreciating the immediate moment even more.
As I observe this furry creature living her life, I’ve collected a some rules that she seems to live by, and that perhaps we all should too:
If something bothers you, bark at it.
If someone bothers you, leave them alone.
There is no such thing as too many hugs.
Do not eat when you you’re not hungry.
Do not sleep where you don’t want to.
Do not be alone when you can cuddle.
Do not care how ridiculous you look when you’re comfortable.
You don’t have to be happy about it, but share your toys.
I’ve been on a bit of an organizing kick lately, the source of which is a mystery, but the net effect of which I’m very happy with. As I sort things into labeled bins and ask myself if I will ever use something again or how much it costs to replace it, the number of hobbies I’ve found evidence of keeps adding up. I am starting to think that my main hobby is trying new hobbies!
Here are all of the activities I have come across, in no particular order. Some of these I’ve spent mere hours on, others have entailed thousands of hours:
Star Wars: The Force Awakens was made, and made well, from top to bottom, by people that love Star Wars. Though heavy on the nostalgia, it skips today’s rampant “reimagining” and captures the fun and excitement of the universe while standing up as a modern movie. A great addition to the series.
/cdn.vox-cdn.com/uploads/chorus_image/image/55701647/Screen_Shot_2017_07_13_at_1.09.20_PM.0.png)