PROTECT. YOUR. FLOW.

“Flow”, that state of being “in the zone”, lets you create your most significant, productive, and satisfying work. For a creative professional, it’s most important to create conditions that allow regular, predictable, flow.

Turn off all push notifications. You don’t need to read that message right now. Group chat is the mind-killer. Turn that shit down. Create a routine of checking your email and messages during administrative time between flow sessions.

Put on sound-dampening headphones, and listen to ambient, rhythmic, non-vocal audio (Spotify’s Focus playlists are fantastic). Avoid visual distractions, even in your peripheral vision.

Avoid interruptions and context switches. If your work area is not amenable to this, take a laptop and leave. Go somewhere you can focus.

Pick a length of time for “flow work” and commit to it. After the session is over, take care of your body, and get social. Eat, drink, go to the bathroom. Mingle with (not currently focusing) coworkers. Check your email, take a walk. Prepare for your next flow session.

Managers, allow your creative crew to have solid flow sessions throughout the day. Use asynchronous communication (email) instead of synchronous (chat). Create separate focus vs. social spaces.

Flow is when you achieve your best work. PROTECT YOUR FLOW.

• #FridayDevAdvice

When designing an application, separate UI code from the code that makes your application “do things”—what is traditionally called “business logic”. Make sure an airtight interface separates your business logic from your UI.

Taken to its logical end, business logic code should exist in its own library or framework, and your UI app links against it.

Separating your business logic this way allows you to repurpose it in other apps, create command-line versions of your app (useful for scripting), refactor it without changing your UI, or overhaul your UI without introducing errors into your app’s core logic.

Even if you never refactor or repurpose your code, this separation acts as an organizational tool while you design your app. Follow this pattern and your app will likely be more maintainable.

• #FridayDevAdvice

When writing multi-platform code, conditionalize code on features, not platforms. For example, if you can’t use instruction set X on platform A, conditionalize on HAS_FEATURE_X instead of IS_PLATFORM_A.

Then, create one file in which you map platforms to features. That way you can easily add new platforms and switch features on and off without going through all your code.

#if IS_PLATFORM_A
  #define HAS_FEATURE_X 0
  #define HAS_FEATURE_Y 1
#elif IS_PLATFORM_B
  #define HAS_FEATURE_X 1
  #define HAS_FEATURE_Y 0
#else
  // Default behavior, should work on all platforms
  #define HAS_FEATURE_X 0
  #define HAS_FEATURE_Y 0
#endif

Remember, if you have a final #else clause, it should only contain platform-independent code that will work on any platform, perhaps with less optimization.

• #FridayDevAdvice

Let’s talk about personal values and what they mean for a software developer.

Have you put some serious thought about which kind of software projects you will accept, and more importantly, which kinds you will reject, beyond financial considerations?

Can you articulate the values you are willing to project through your work? How much personal responsibility will you bear if your product is used to harm or coerce, rather than empower or protect?

Software used to guide a missile has consequences. So does software used to profile applicants for potential jobs, or help people live a healthier life. Will you accept the moral consequences of your code? Will you accept both praise and blame for how your software is used?

What unintended consequences might there be for the code you write? What will you do to mitigate them?

Find your bright red lines before you accept your next project. If you’re like me, you’ll sleep better at night.

• #FridayDevAdvice

If your app offers UI, a crucial but difficult task before you is UI testing. While you can get away with occasional, informal testing when you first begin, the challenge of UI testing will grow very quickly.

Use a combination of automated and manual testing. Although automated testing will catch the most obvious regressions, subtle problems such as animation and polish issues are much harder to detect automatically.

Typically, larger products will be tested using a three-pronged approach:

• Automated regression testing
• Manual regression testing of known flows
• Living-on coverage, where stakeholders use unreleased software daily

To me, what makes UI testing especially challenging is the fact that it involves unpredictable, fickle, human users. You must allow for subjective appraisal of your UI during testing. Build it into your plans.

• #FridayDevAdvice