DEV Community: Jon Samp

Best practices for working together

Jon Samp — Sat, 04 Jan 2020 19:47:48 +0000

I've had many jobs over the past decade, including genetics researcher, admissions counselor, apple retail employee, and now I'm a software developer. Being a software developer is the best job I've had (by far), but there is a downside I rarely talk about: working with other people has become harder for me. More and more I retreat into my head, get frustrated, then I don't communicate effectively.

Like any problem, it's much easier to solve when you can define the problem and create a goal post to shoot for. Below are three problems I've noticed on every dev team I've been a part of, with best practices to address them.

Feedback

Problem: Teams need feedback to improve, but it's hard to tell coworkers your opinions (for a lot of reasons).

Giving feedback to each other helps us grow together and to build the best stuff. There's a variety of feedback styles that can really help us grow together, but there are other styles that can do more harm than good. Great feedback has two traits: incredibly specific and given as quickly as possible.

Specificity

Saying that a piece of work looks "really good" or feels "not quite up to our standards" is feedback that is non-specific and requires the receiver of that feedback to guess about what you really mean. Great feedback sounds like: "This piece of work has a nice, step-by-step flow with its numbered items" or "this button does not match our brand colors and caught my eye when i saw this page".

Timeliness

Feedback given months after the event makes it difficult to iterate and learn. In addition, the receiver of the feedback and the giver of feedback will have a growing difference of what happened and how it turned out. Giving feedback as soon as possible is important to getting value from it.

Amplification

Problem: New ideas get shot down before they can grow into great ideas.

Creative thinking and new ideas are our best asset to building incredible products. It's natural to hear a new idea and to find issues with it and to think of ways it may not work, or unknown factors around things we don't know.

Instead of poking holes in ideas at the start, we can amplify them by repeating them out loud and thinking about how they could work. This is especially important at the beginning of the ideation/proposal process.

The goal is to amplify each other's ideas to better understand how they could grow. We can always find issues/unknowns later. The beginning of a product process should start with growing an idea instead of snuffing it out.

A way to do this is by repeating the person's idea back to them, and adding something of your own. Just like the "yes, and ..." improv exercise, we can encourage the people around us to propose ideas and grow them (this is in opposition to the "yes, but... " exercise, that works in the same way and instead shuts down creativity).

The "Yes" portion of the rule encourages the acceptance of the contributions added by others. Participants in an improvisation are encouraged to agree to proposition, fostering a sense of cooperation rather than shutting down the suggestion and effectively ending the line of communication. ~ Wikipedia

Positive intent

Problem: How can we know the hater on the team doesn't hate me.

When receiving feedback or when talking to others, assume positive intent. This is in an effort to avoid falling back to the human default of defensiveness. Defensiveness arises out of assuming someone's intention when they provide feedback or comments about a piece of work. By assuming an intention, we shut out critical information that can help us make progress.

By assuming that everyone has positive intent, we can diffuse defensiveness by knowing that the person speaking to us means well, even if what they are saying runs counter to our efforts.

A practical way to do this is to ask clarifying questions about the opposing point of view to make it as specific and clear as possible (instead of defending your original stance). After that, then you can make an informed decision about how to proceed. Read more from this article.

How to create React Native/Expo npm packages

Jon Samp — Mon, 30 Dec 2019 04:00:38 +0000

Developing npm modules that work with Expo is different from the traditional flow that you can use with a regular 'ol React project. Usually in a React project, you could create a module inside a folder on your computer, then run yarn link inside it and proceed to link it inside your testing playground.

Expo is powered by React Native, which uses a bundler to bundle your app's dependencies. This prevents yarn link from working as usual.

To develop a package, there are two different strategies depending on what you need to do. You might need to create the contents of the package, or you might need to verify it works as an import in real project.

Creating the contents of the package

Create a testing app with expo init. Inside it, create a folder named your-package-name, with in an index.tsx file inside. The file structure should look like:

testing-app/
  your-package-name/
    index.tsx
    ...
  App.tsx
  ...

Inside App.tsx, you can now import Foo from './your-package-name', and develop it just like a regular component --that's because this is the exact same as creating a regular component. By doing this, you get the awesome dev-experience/fast-reload of Expo.

Testing the package as a dependency

When the package is in a spot that is complete, you are ready to test it as an import into a real project. We're going to do this without publishing it to npm or using a tool like yalc.

In another spot on your computer, create a folder named after your package: your-package-name. Inside it, copy over all the files that make up your package. Then, run expo init example to create an example folder inside your package folder, like this:

your-package-name
  example/
    ...[expo app here]
  index.tsx
  ...

To install the package in the example Expo app you just made, cd into the parent your-package-name directory, and run npm pack.

This will package up your module into a .tgz file. When you run the command, the last line of output will tell you the file name that it just saved (it should look like: your-package-name-version.tgz). Copy it, then cd back into the example folder and run yarn add [your-copied-name].tgz and your package will be installed as a dependency. Inside the Example, you can now import it with import Foo from 'your-package-name'.

Now you can create an example that will test your package within an app, and if you commit it to GitHub, others can also see a working example of your package too.

Once your package is in a good spot, follow with your npm publish flow.

To see an example of an Expo compatible project with an example folder, check out my react-native-fade package.

Happy package-ing!