Tag: process

You

Be a (good) shark 🦈

Featured patmcgLeave a comment

This Medium post lists some great ways to make your life easier: Focus on next steps. Be present. Say no a lot. Focus on one thing.

One really surprised me, though: speed up.

I was going to add a point about slowing down but then decided to mix things up a bit and go the other way.

Alex Mathers

I second that idea. 👍

“Speeding up” is what I like to think of as relaxed focus. Just keep moving forward; the motion keeps your momentum up and keeps your thoughts and actions fresh and relevant. No more paralysis of analysis.

Get moving. Prioritise a kind of fluid, calm urgency in your life.

Now, Ted Lasso said “Be a goldfish“, but I’m going to say “Be a shark.”

A quick drawing of a shark moving quickly.

Okay, a shark is a deadly predator. Don’t do that; set that aside for a minute.

The best quality about sharks is that they understand relaxed focus. A shark is always moving purposefully, but it’s never in a hurry.  A shark don’t stop or wallow or get bored or frustrated.  A shark is always going somewhere and always has a plan. A shark’s movement seems to feed its energy rather than expend it.

So in life, be a shark. Keep moving purposefully and own your little neck of the ocean.

See also

“Creativity is not a talent. It is a way of operating.”

“How can a guy think and hit at the same time?”

Books · Quotes · You

“If you work on something a little bit every day, you end up with something that is massive.”

patmcg6 Comments

I like this idea…

If you work on something a little bit every day, you end up with something that is massive.

Kenneth Goldsmith

The book Show Your Work references this quote and really brings it home with an image that illustrates how a good picture can outshine even the best words.

👉 By the way, Show Your Work inspires this blog and will most definitely be getting its own super summary (or series) here (eventually).

Software Dev

“Sketching” out an app prototype

patmcgLeave a comment

I’ve learned a lot making apps for big companies, mostly about process: how a good continuous integration process works, how code reviews can be productive (or not productive), how to break a big app into smaller components so lots of people work on related things at the same time.

Still, it’s helpful to do something fresh and new 100% on your own from time to time. Doing something new all your own, you get to try any architecture you want, go all in on the latest asynchronous programming techniques, fully embrace the amazing new(ish) declarative/reactive view layer, and even try out a new CI framework to two.

But the most fun part of all is developing the idea of your app. What does your app do? How exactly does it work from a user perspective? And what do the screens look like in detail?

👉This time around, I’m prototyping my new app idea on my phone so that I can get a feel for how it works in my hands before writing all that code. ^

I tried out a few prototyping tools. After looking at some basic options and some pretty involved options (arguably too involved), I landed on a pretty “sketchy” Mac app that handles full-on detailed UI design and kind of does mobile prototypes through its “mirroring” iOS app. Perfect. 👌

👉 Sketch | mirroring app

I will say that Figma looks pretty promising as well. What nudged me over to Sketch was Apple’s Sketch-compatible design resources. There are some third-party iOS design resources for Figma, but I’d rather go with Apple’s official offering. Sorry, Figma. 🤷🏻‍♂️

So my new design process is this, now that I’ve finally learned Sketch:

Rough sketch on paper ➡ realistic visual design in Sketch ➡ prototype on a phone ➡ code

My instinct is to talk about the app itself while it’s in progress, but sorry… that’s top secret for now. 🕵️‍♀️

Software Dev

The case for creating a merge commit

patmcgLeave a comment

I’m always interested when someone has a strong opinion on how to merge code. I like this article because the author acknowledges that it’s just a matter of tradeoffs and then makes a case for a merge commit.

👉 The case for creating a merge commit

His basic argument is that a merge commit is the best of both worlds since it “maintains the small changes while allowing for 30,000 feet view of the history” with the --first-parent git log option.

But…

At the end of the day, what matters is to find a workflow that suits your team well and lets you deliver.

He also links to a couple of great articles on using small iterations (Kent Beck’s SB chages and GeePaw Hill’s MMMSS) that I need to blog later!