It pleases Adorable to say that there’s a new Adorb developer on board: Chris Wilson. Chris is a software developer with a sciency background.

He started out writing FORTRAN for an intro physics class and then never set the keyboard aside. In the intervening years he’s worked at a particle accelerator, fixed computers, and written healthcare software.

Chris is happiest when he’s learning Something New or gushing about the New Something (repeat). He’s recently dived into embedded software development and amateur radio.

He conditionally enjoys the outdoors, namely, those times when he can get aboard a sailboat or onto a bike.

Chris is Adorable was originally published in Adorable on Medium, where people are continuing the conversation by highlighting and responding to this story.

Shaun is Adorable was originally published in Adorable on Medium, where people are continuing the conversation by highlighting and responding to this story.

Adorable is happy to announce the addition of a new Adorb and developer, Maggie Shemayev. Attached to her keyboard since a young age, Maggie has always dabbled in technology, from excursions into hardware and repair to basic site maintenance in college — and upon trying programming at Madison College, found a new passion. Her bachelor’s in math and love of languages leaks into her code: she has yet to find a programming language she doesn’t like, and spends her free time on everything from reading up on the structure of programming languages and writing regular expressions to knitting and coloring books.

Maggie is Adorable was originally published in Adorable on Medium, where people are continuing the conversation by highlighting and responding to this story.

Owner Summit, an event targeting people who own and operate digital agencies, took place last week in Charleston, SC. Shops with skills ranging from marketing through design & development were on hand.

Amongst a wide array of thoughtful & helpful presentations from folks like Claire Lew of KnowYourCompany to Nancy Lyons of Clockwork was a presentation by a couple of lawyers. Ugh! 😅

Gabe Levine and Josh Barrett teamed up to create a starting point agreement for digital agencies. If you’ve run a shop or dealt with contracts 9 times out of 10 you’re asked to sign paperwork that is not optimized for our industry.

One client of ours included language in their paperwork which stated if they weren’t happy at the end of the project they had the opportunity to simply return all of our work product and not pay for it. Unfortunately, in a service business all you’ve got is your time and we trade that for money.

After seeing this time and again these folks joined forces to create the Bureau Standard Agreement. There are a number of disclaimers listed in the document the most important of which is that using this document does not mean you don’t need a lawyer.

What it does mean is that you have a reasonable starting point for the conversations that happen at the beginning of projects. And, ideally, the more people that use this agreement the further refined and more sane the defaults will become.

If you’re a development heavy shop, like we are at Adorable, you should keep an eye out for updates as this inaugural version is targeting design shops and probably will leave you wanting for intellectual property carve-outs. As luck would have it Gabe has been our lawyer for the majority of our existence as a company. I can tell you that I am able to confidently walk in to calls with my clients because of his work.

The Bureau Standard Agreement is a helpful starting point to frame the conversation with your clients and counsel, if you’re not lucky enough to already be working with Gabe, Josh, or someone else who knows their stuff.

Introducing the Bureau Standard Agreement was originally published in Adorable on Medium, where people are continuing the conversation by highlighting and responding to this story.

At times, I feel like an island.

As a software designer, I have been a team of one almost my entire career.

While it can be inspiring to have a blank canvas with complete autonomy, it can also be daunting to take on such responsibility solo. Working alone on design at my company or on a client project usually means that I will have a wide spectrum of roles. I begin a project by interviewing my client to find out what they’re trying to achieve. I then do market research and come up with some ideas to propose to them for how we might go about meeting their requirements. From there, I continually switch out my hats of being a visual designer and a developer in order to bring the ideas to life.

I have a sneaking suspicion that there are lots of other islands out there, too. It’s important for us to share our knowledge, challenges, and successes, and most importantly, find ways to involve the talented people around us in our design process in order to become a part of the mainland.

Design Isolation

Isolation comes in two forms when we discuss my design experience. Isolation can be felt physically by working alone, and also felt mentally when there’s no one to collaborate or share ideas with.

There are at least two commonly held beliefs at software companies that are root causes of design isolation. I do not believe that they benefit design quality for the reasons that I discuss below.

• Design is a solo activity.
• Design can only be advised by other designers.

Working Alone

In contrast to how design projects usually work, our development team typically uses pair programming as a way to reach the best outcomes on a project. In this mode of working, two developers collaborate together on one computer to solve a problem together using code. We use it for ramping someone up on a project, to learn new languages and skills, problem solve and transfer knowledge.

Design, however, is not usually a paired activity; this is de facto true when you are the only designer in house or the only designer on a project. Some reasons for this could be that developers feel like they don’t have much expertise to contribute to design. Developers may have an idea that they aren’t good at design, or that their ideas aren’t sophisticated enough to be shared. Additionally, developers are often under pressure to finish the work that they have been assigned for their iteration cycle. Therefore, it doesn’t occur to them or their managers that they might be spending their time wisely to pair with a designer.

Catching The Issues

Unfortunately, I usually don’t stumble upon the effects of my decisions and actions until they reach the code phase in a project. The little, unchallenged issues that skipped past my attention now get worked through the implementation phase and always bubble to the surface. By that time, these decisions are being seen by the client, good or bad, and developers and I have to create solutions on the fly. Typically, project deadlines are short in my work, so decisions have to be made quickly. If the choices I made earlier are not the best for the project, I might not have an opportunity to redirect or iterate, or risk extending my deadline and putting stress on the other people on the team or project.

Input from other people early and often in the design process always has a positive effect on the project quality and timeline.

The Design Mindset

As with any creative work, if someone isn’t directly involved in the process of creating, design can look like magic. Often there is a perception that it takes no time at all to do design. Team members who aren’t involved with design have difficulty conceptualizing the decisions and thought processes that were put into the work, and therefore can have more difficulty empathizing with the overall process.

This is one reason why it can be beneficial to the project for developers in particular to get exposure to design work. They can get a deep understanding of the product they’re building very quickly, which makes it more likely that they will build the right thing the first time around. Design also gets exposure to the issues that developers are facing (what does the data structure look like, again?)

Developers and designers spending time collaborating is beneficial to both roles.

Who Is Qualified To Help?

When I am the only one making design decisions, they are solely based on my experiences and interactions with the world. The choices I make are in response to what I remember doing, seeing, and hearing consciously or subconsciously, that can be applied to the design problems I face. Unfortunately, that means that all my assumptions stick, and reach many people. I need to take a diverse set of views into consideration so that I understand the variety of needs and interests of my audience.

To me, it feels especially important to emphasis the importance of collaboration because I credit a lot of my success to experiences that I’ve had in which I was challenged or questioned. I excelled in school because I had skilled people to bounce ideas off of, learn new techniques from, or to use as inspiration.

Developers aren’t the only other role that can cross-pollinate with design. Having a design opinion makes you a human with unique experiences and a valid understanding of the world. What this means is, if you’re a person who isn’t me, chances are that I will be interested in hearing what you have to say about a problem. It helps me to know what other people’s interpretations are of the things I design, so I can express intentions across a broader audience.

Beyond Design

As the only designer on my team or project, I am responsible for much more than creating the UX/UI and visuals. The additional tasks outside of the design title range from copywriting/microcopy, cross-browser testing, client communication & feedback loops, project management, and front-end development. These types of activities require different types of thought, time and skill. These tasks often fall to the designer, but can also be dispersed throughout a team in the absence of a true product manager.

This takes some conscious organizational work and buy-in from the other team members, but the effect is that everyone is more engaged overall and the shipped product is of higher quality.

What Can Be Done?

Check the pulse

Say ‘Hi,’ to the designer in your team’s neighborhood. Ask to see if they want to discuss what they’re working on, or collaborate on any upcoming work. Talk to them to find out if they’ve been getting enough useful input on their projects.

Talk to your manager(s)

Sometimes isolation creeps up on you. If you think your designer isn’t getting enough participation from the people around and are taking on a larger share of the work than they can handle, chat with your manager about whether you and your teammates can re-allocate some of that labor.

Try some design!

Pick a problem to solve, and try to solve it using design! A pen and paper is enough to sketch out what an application might look like to solve a specific problem. It’s fun, and helps you get into a product oriented design mindset.

You can find the work of Kelly’s at Dribbble . She is the Art Director/Illustrator/Developer at the software consultancy, Adorable in Madison, Wisconsin.

The pitfalls of being a design island in a small software company was originally published in Adorable on Medium, where people are continuing the conversation by highlighting and responding to this story.

My Game: SHOPPOTRON

The game I came up with is called SHOPPOTRON. You play as a robot who loves shopping, and your goal is to collect every item in the store and take it to the cashier before your battery drains. It’s a super simple game, and there are lots of ways I could make it better, but I’m proud of overcoming my normal perfectionism and shipping something rough out into the world.

Day 1: Brainstorming, planning, building

The event started at 8:00pm in my timezone. Since I’m an old man who can’t pull all-nighters any more, I spent about three hours getting started and then went to bed. I brainstormed game ideas based on the theme (“The more you have, the worse it is”), created a Unity project, and got a basic build working.

My walking skeleton build didn’t have anything more in it than a placeholder splash screen, but I wanted to make sure there was less chance of disaster while frantically trying to build/deploy my game at the end of the jam.

I streamed this first session on Twitch, and I’m glad I did, because one of the people in my chat made a suggestion that combined a few ideas I’d been brainstorming into what became SHOPPOTRON. Thanks, Twitch chat!

Day 2: Designing and Coding

On Saturday I woke up, had breakfast, and got back into it. They say sleeping on it is the best way to solve problems, and sure enough, I had basically all the pieces mentally in place when I sat down to work — or so I thought!

My goal for the second day was to get all of the coding done and create some placeholder assets to test with. I felt like I had a strong idea of where I was going, so I dove right in. Something pretty cool happened while I was building the test pieces, though.

I botched some Unity settings that I didn’t understand and got wonky physics on a couple of objects when they interacted. The result of this interaction was way more interesting than what I had been building. As luck would have it, I wasn’t too far into things yet to change direction, so I scrapped the code that I had and leaned into this type of physical interaction. That happy accident wound up becoming the main focus of the gameplay. Bob Ross was right!

Day 3: Drawing (and more coding)

Sunday was all about art assets. I am a horrible artist (as is evident in the final game) so this took a long time and wound up not very good. I drew all of the sprites in Aseprite, which was lots of fun to play around with.

Something I hadn’t thought about before with art is that when you’re bad at it, it’s not just that you can’t get results that look how you want. It’s also that you’re slow. I had intended to spend half a day on assets, but this wound up taking me all of Sunday.

Ultimately, I think the intentionally-wonky aesthetic works for SHOPPOTRON, but art skills are definitely something I’ll be working on before releasing my next game.

Day 4: Audio Creation and Level Design

Last day! Monday at 8pm was the deadline, so today was about pulling everything together. I started the morning out by making sound effects and music. I used Ableton Live Lite and Audacity for both tasks. I kept things super minimalist here since I don’t have any experience with audio design, but I’m actually fairly happy with the results. Just like with the art, I want to invest time in learning that skill before my next game, but for this game I like the result.

The last thing to do was level design. I had built all the component pieces, but as of lunchtime on Monday hadn’t actually put them together into a game yet. So I spent the remaining several hours of the jam slapping together 12 levels that demonstrated increasingly absurd ramifications of the game’s rules.

I got things all wrapped up around 7:00pm, shipped my builds up to itch.io for download, and wrote the description on the Ludum Dare website!

Lessons Learned

I have always had a hard time diving into things that I haven’t spent a lot of time studying beforehand, so this was great practice at breaking out of my comfort zone. Building all of the pieces of a game forced me to get comfortable fast with being out of my depth in many different ways simultaneously. I know I’ll be able to carry that forward to other things and decrease the average time it takes me to dive into things when I’m not totally confident.

I also had to make peace with shipping suboptimal and messy code. Because of the time crunch, there were several problems I knew I could solve more elegantly that I had to leave unsolved and hacked around because coming up with the “right” answer would have taken me too long. Obviously, I don’t want to start writing code this way for my day job, but it was good practice at fine-tuning my sense of when something is good enough.

Overall, Ludum Dare 40 was great fun, and I’m super glad I participated. If you haven’t done a game jam before, I highly recommend finding one that seems cool and diving in! And if you have a few spare minutes, play my game!

Ludum Dare 40 Retrospective was originally published in Adorable on Medium, where people are continuing the conversation by highlighting and responding to this story.

About ctags

Many years ago I became familiar with the basic ctags functionality in vim. But ctags itself is much more flexible and can be consumed by most editors. I highly encourage y’all to check out the ctags website, as well as plugins for popular editors such as vscode, atom, and sublime text.

Essentially, ctags will scan all files you ask it to and look for what it understands to be symbol definitions. These are classes, functions, variable names, and so on. ctags has a large list of known languages, but the JavaScript support hasn’t yet been the greatest.

To start, make sure you have exuberant-ctags installed, as opposed to regular ctags. You can brew install ctags on a macOS machine, for example, which will install the latest version of exuberant-ctags.

Inside vim

Generating ctags

I use ctags to jump to the definition of a symbol in a given project. There are generally two ways I achieve this: from a cursor over the top of a symbol and using normal-mode commands to search the list of defined tags.

Jumping to a definition under the cursor

While reading code and the cursor is on top of a known symbol, pressing Ctrl+] will jump to that definition.

Searching the available tags

If you know the tag you want but are nowhere near it, you can :tag <tagname> to jump to it’s definition. The :tag command supports tab completion; I often use :tag searches to jump to class or constant definitions.

Navigating through multiple matches

Either of these ways of jumping to definition may result in multiple tag matches. You can navigate the tag stack with :tnext (briefly, as :tn) or :tprevious (:tp). If you’d like to see a list of definitions found for any given tag, you can :tselect (:tsel).

Including other packages in your generated tags file

Although it can take a prohibitively long time based on the size of your dependency graph, I have found it useful in some cases to include my node_modules directory in my tags file. Whereas I usually just include basic directories like app, config, and lib, there are times when I’ll want to inspect the source of a module in the same session as my application’s code. One example would be when I’m using a library module for the first time and I’m unsure how things are working under the covers, or why what I expect to happen just isn’t.

Your new .ctags file

After a bit of pruning and studying, this is the JavaScript-specific portion of my ~/.ctags file looks like this:

--exclude=node_modules
--exclude=gulp

--languages=-javascript

--langdef=js
--langmap=js:.js
--langmap=js:+.jsx

--regex-js=/[ \t.]([A-Z][A-Z0-9._$]+)[ \t]*[=:][ \t]*([0-9"'\[\{]|null)/\1/n,constant/

--regex-js=/\.([A-Za-z0-9._$]+)[ \t]*=[ \t]*\{/\1/o,object/
--regex-js=/['"]*([A-Za-z0-9_$]+)['"]*[ \t]*:[ \t]*\{/\1/o,object/
--regex-js=/([A-Za-z0-9._$]+)\[["']([A-Za-z0-9_$]+)["']\][ \t]*=[ \t]*\{/\1\.\2/o,object/

--regex-js=/([A-Za-z0-9._$]+)[ \t]*=[ \t]*\(function\(\)/\1/c,class/
--regex-js=/['"]*([A-Za-z0-9_$]+)['"]*:[ \t]*\(function\(\)/\1/c,class/
--regex-js=/class[ \t]+([A-Za-z0-9._$]+)[ \t]*/\1/c,class/
--regex-js=/([A-Za-z$][A-Za-z0-9_$()]+)[ \t]*=[ \t]*[Rr]eact.createClass[ \t]*\(/\1/c,class/
--regex-js=/([A-Z][A-Za-z0-9_$]+)[ \t]*=[ \t]*[A-Za-z0-9_$]*[ \t]*[{(]/\1/c,class/
--regex-js=/([A-Z][A-Za-z0-9_$]+)[ \t]*:[ \t]*[A-Za-z0-9_$]*[ \t]*[{(]/\1/c,class/

--regex-js=/([A-Za-z$][A-Za-z0-9_$]+)[ \t]*=[ \t]*function[ \t]*\(/\1/f,function/

--regex-js=/(function)*[ \t]*([A-Za-z$_][A-Za-z0-9_$]+)[ \t]*\([^)]*\)[ \t]*\{/\2/f,function/
--regex-js=/['"]*([A-Za-z$][A-Za-z0-9_$]+)['"]*:[ \t]*function[ \t]*\(/\1/m,method/
--regex-js=/([A-Za-z0-9_$]+)\[["']([A-Za-z0-9_$]+)["']\][ \t]*=[ \t]*function[ \t]*\(/\2/m,method/

--langdef=typescript
--langmap=typescript:.ts
--regex-typescript=/^[ \t]*(export)?[ \t]*class[ \t]+([a-zA-Z0-9_]+)/\2/c,classes/
--regex-typescript=/^[ \t]*(export)?[ \t]*module[ \t]+([a-zA-Z0-9_]+)/\2/n,modules/
--regex-typescript=/^[ \t]*(export)?[ \t]*function[ \t]+([a-zA-Z0-9_]+)/\2/f,functions/
--regex-typescript=/^[ \t]*export[ \t]+var[ \t]+([a-zA-Z0-9_]+)/\1/v,variables/
--regex-typescript=/^[ \t]*var[ \t]+([a-zA-Z0-9_]+)[ \t]*=[ \t]*function[ \t]*\(\)/\1/v,varlambdas/
--regex-typescript=/^[ \t]*(export)?[ \t]*(public|private)[ \t]+(static)?[ \t]*([a-zA-Z0-9_]+)/\4/m,members/
--regex-typescript=/^[ \t]*(export)?[ \t]*interface[ \t]+([a-zA-Z0-9_]+)/\2/i,interfaces/
--regex-typescript=/^[ \t]*(export)?[ \t]*enum[ \t]+([a-zA-Z0-9_]+)/\2/e,enums/
--regex-typescript=/^[ \t]*import[ \t]+([a-zA-Z0-9_]+)/\1/I,imports/

Wrapping it up into an alias

Finally, and following Mr. Grasso’s example, let’s get rid of some over-greedy matching and wrap it up into a nice alias:

alias jtags=”ctags -R app config lib && sed -i ‘’ -E ‘/^(if|switch|function|module\.exports|it|describe).+language:js$/d’ tags”

Happy vimming!

Modern JavaScript ctags configuration was originally published in Adorable on Medium, where people are continuing the conversation by highlighting and responding to this story.

Debugging ES6 Javascript code in the Visual Studio Code IDE can be a painful process to setup. In this article we’ll walk through one way to set it up and get productive.

The challenge to getting this working is rapid rate of change of the Javascript language, the Javascript transpilation tooling as well as the Visual Studio Code configuration interface. Both have changed drastically in the last year, rendering most previous tutorials and blog posts out-of-date. For example, this excellent gist was the basis for much of this article, but it’s written against the 1.0 version of vscode’s launch.json and tasks.json specification.

Let’s run down the characteristics of the application we’d like to debug:

• Written in ES6, transpiled to ES5 with babel-cli
• Imports other internal files, as well as external dependencies
• Uses an executable file (via chmod +x) as an entry point

Let’s also take a look at the package.json that implements the transpilation in various scripts. Note that our application files reside in src/bin and are transpiled to dist/bin, while the lib files it loads reside in src and are transpiled to dist.

It’s important that you generate source maps for your ES6 code — in the code above we pass the --source-maps switch to the babel tool to generate *.map files alongside the transpiled ones in the dist directory. You may also generate inline maps by using --source-maps inline instead.

We also need to specify what environment we’re targeting with our babel transpilation. Create a file named .babelrc in your root folder. We’re going to use the babel-preset-env module to target a recent version of Node.

We should now have all of the tools to write our launch.json:

Note that we’re invoking npm run build via the preLaunchTask: "npm: build" property in the launch config. That way every time we debug we know we’re running the latest and greatest transpiled code. If you haven’t worked with the Visual Studio Code Tasks system before, it’s worth noting that vscode recognizes an npm project via the presence of a package.json and automatically configures Tasks based on the items in the scripts config. In our package.json we have a build task that removes the current dist directory and rebuilds both the lib and bin source with the correct configuration for each. We can refer to these auto-generated Tasks in our launch configuration by the names that vscode generates (hence why npm run build becomes npm: build in the launch config.

That should be it! You should now see the Debug Increment Command launch configuration when you switch to the Debug view in Visual Studio Code.

Clicking on the green Start Debugging button to the left of the launch configuration should run npm run build first and then launch the app under the debugger. If you set no breakpoints it will likely just run and end, unless you set stopOnEntry: true in the launch configuration.

Set some breakpoints in src/bin/app.js and hit the Start Debugging button again and we should now see execution halt at the breakpoint and give us all the goodies we want out of a visual debugger (local variables, watch window, call stack, console, etc.)

This tutorial may be helpful and up-to-date for anywhere between 14 nanoseconds and 6 months as the various tools change, but for those writing npm modules with possible bin scripts included this is the best way that I know of right now to be able to write ES6 code while delivering and debugging the transpiled ES5 equivalent functionality.

Happy debugging!

UPDATE: Thirty-two minutes after I posted this, my prophecy was realized and the September 2017 update to Visual Studio Code was released, deprecating the usage of ${workspaceRoot} in launch and task configurations. If you have updated to version 1.17.0 or newer of vscode, then you should now use ${workspaceFolder} instead.

Zachery Moneypenny is a Principal Developer at adorable.io. Rubyist for a long time, with experience in Golang and Javascript as well but moving towards Elixir and loving it.

Debugging ES6 in Visual Studio Code was originally published in Adorable on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Problem

While developing ruby on rails applications, which I’ve been doing for ten years, I’ve relied on the powerful and popular rails.vim written by tpope. I like that rails.vim makes me decide what I want before going and getting it (so I don’t sit and stare at a list of files) and another part is the built-in templates for new files that rails.vim provides. For example, :Emodel user! will generate a blank ActiveRecord model class that inherits from ActiveRecord::Base.

I’ve been developing react-native apps for some time now, and I’ve been relying on vim’s built-in :e command combined with tab-completing directories and files. This has been tedious, to say the least. I wished I had the familiar navigation and new-file templates from rails.vim. I recalled, though, that rails.vim had been rewritten some time ago and vim-projectionist had come out of the refactoring.

The Solution

I installed vim-projectionist, created a .projections.json in the project root, and set up some simple file navigations with ease. When I got to writing templates, however, I had some issues with curly braces. The line import React, { Component } from 'react-native';, as an example, would fail to be imported into the template. This is because vim-projectionist uses curly braces to denote placeholders and Component is not a valid placeholder. To output curly braces in your template, you’ll need to use the {open} and {close} placeholders.

vim-projectionist supports easy navigation to and from test files and to “alternate” and “related” files. I haven’t yet decided how I’d like to use those, so I’m leaving those sections empty until I’ve decided on a sensical set of defaults.

Here’s what I’ve got so far for my react-native `.projections.json` file:

{
  "app/actions/*.js": {
    "type": "action"
  },
  "app/containers/*.js": {
    "type": "container",
    "template": [
      "import React, {open} Component {close} from 'react';\n",
      "export default class {capitalize} extends Component {",
      "  render () {",
      "    return (",
      "    );",
      "  };",
      "}",
      "",
      "export default connect(",
      "  state => ({open}state: state{close}),",
      "  dispatch => ({open}actions: bindActionCreators(actions, dispatch){close})",
      ")({capitalize});"
    ]
  },
  "app/components/*.js": {
    "type": "component",
    "template": [
      "import React, {open} Component {close} from 'react';\n",
      "export default class \{} extends Component {",
      "  render () {",
      "    return (",
      "    );",
      "  };",
      "}"
    ]
  },
  "app/reducers/*.js": {
    "type": "reducer"
  },
  "package.json": {
    "type": "package"
  },
  "app/services/*Service.js": {
    "type": "service"
  },
  "app/styles/*.js": {
    "type": "style",
    "template": [
      "import {open} Platform, StyleSheet {close} from 'react-native';",
      "import COLORS from '../config/Colors';",
      "import FONTS from '../config/Fonts';\n",
      "export default StyleSheet.create({",
      "});"
    ]
  },
  "app/Store.js": {
    "type": "store"
  },
  "app/Root.js": {
    "type": "root"
  }
}

Reference

vim-projectionist supports the following placeholders. With the exception of {open} and {close}, which output curly braces, the ones you’ll be most interested in are case transformations. You can always see all the available transformations inside your vim session with
:let g:projectionist_transformations.

{dot}
{underscore}
{backslash}
{colons}
{hyphenate}
{blank}
{uppercase}
{camelcase}
{capitalize} — aliased as \{}
{snakecase}
{dirname}
{basename}
{singular}
{plural}
{open}
{close}

Big thanks to tpope for making my life so much easier!

React native projections and templates using vim-projectionist was originally published in Adorable on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a small business owner many hats are often needed. For a time juggling those hats will work; however, there will come a point when an expert is needed. Where do you begin to find that expert?

At Adorable, we often turn to our Certified Public Accountant (CPA) at Port & Sacks, CPAs, S.C. for help. Think about it, your CPA works for a number of different people in different industries. When you find that you need help, chances are they will know someone.

Back in 2014, we needed a partnership agreement drafted. It just happened we had a meeting scheduled with Port & Sacks. Toward the end of the meeting, they asked if there was anything else they could help us with. We took them up on their offer and asked if they could recommend an attorney to draft a partnership agreement. As hoped, they provided a few recommendations.

Instead of spending days researching options, we had a few recommendations with introductions and an appointment scheduled within hours.

Your CPA is a great resource for expert tools such as bookkeeping software and payroll services, to name a few. These recommendations are often tools that they are familiar with, that they trust and that are easy for them to integrate with. There is no need to start from scratch researching multiple options when your CPA can narrow down that research to a couple.

The next time you need help and you are not sure where to start, turn to your CPA for a recommendation. You will be surprised by their many resources.

CPAs Are a Secret Ally was originally published in Adorable on Medium, where people are continuing the conversation by highlighting and responding to this story.