Forem: Andrew Duensing

Introducing Slow Social

Andrew Duensing — Sat, 16 Apr 2022 16:54:58 +0000

I’d like to introduce you to Slow Social.

Slow Social is my idea of what I wish social networks were, and what I think they can be. It is simple, straightforward, and sets out to accomplish one thing and do it well. Slow Social functions similar to a personal blog or email list, except with private by default settings and metering to ensure that you don’t have to check it more than once or twice a week to be fully up to date. But let me back up a bit first.

I love social networks, but they’ve pretty consistently let me down. For the past 5 years, the readily available social networks have really failed to adapt, provide, and facilitate meaningful interactions between me and my peers. There are bright spots certainly, but the social apps themselves seem more interested in maximizing easy to quantify metrics like interaction counts, time spent on the app, advertising dollars earned, and other revenue driving numbers rather than actually providing users with tools and guardrails to build and sustain meaningful relationships. I can’t really blame them for this because, after all, Facebook, YouTube, Instagram, Snapchat, and TikTok are all products owned by publicly traded companies who have a legally binding responsibility to maximize financial return on investment to their shareholders. Nevertheless, I’m grieved by the toll its taken on our society, as well as the lost opportunities we’ve had to leverage the incredible technology and resources we have at our disposal to create something better than what we have.

But what does a “better” social network look like? I am by no means the first person to ask that question, and there is no shortage of thoughts on the matter. Undoubtedly the answer is subjective, but I’ve decided to take a crack at it, both ideologically and in terms of engineering.

From my perspective, the principle problem with our existing social networks is that they abuse human psychology rather than try to mitigate it. Humans, by and large, lack impulse control when considering an action where there is no immediate or apparent repercussions. For example, many of us continually trade our next 30 seconds for the potential of mild amusement, but often fail to account for the hits we take to our self esteem or how much “just 30 more seconds” can turn into. My solution? Make an app that forces you to post and read less often, not more.

I’m going to get ahead of things by saying yes, I know, this drastically reduces potential user base. But, if you’ve ever felt like you can’t share anything real because you’re post is going to be sandwiched between memes, can’t stay up to date with your friends without betting distracted or discouraged, can’t stay up to date because there’s just too much content flowing through your feed, or don’t ever want to share anything because you're afraid of what your future friends might think when scrolling back through your feed, then a slower social network might be for you.

That all being said, Slow Social is my take on a social network. With my limited time and resources, I’ve done my best to make it something that gives you space to write and share with your friends what you’ve been doing, as well as see what your friends are up to. The main catch, as you’ve might’ve guessed, is that you can only post at most once every 6 days (so you can post weekly with a grace period). The limited cadence benefits the writer by removing the pressure to give constant, live updates and gives more space for longer form content to be written and thought over. On the other hand, the limited cadence benefits the reader by removing the pressure to always be checking in. Once a week and you’re good.

Aside from the limited cadence, there are other facets of Slow Social that are less central but still support fostering relationships. Some examples are that posts are never visible publicly (but they can be sent as an email easily), newly added friends can only see your latest post and all future posts (they don’t see your entire history), and users are encouraged to write at least 100 words before posting (although it’s not enforced, you just have to dismiss a modal). And lastly, if Slow Social has any measure of success my main goal is to prioritize something sustainable that serves users, not to maximize profit.

If I’ve caught your interest, please check out Slow Social and let me know what you think. You can email me at team@slowsocial.us.

How I review a Pull Request

Andrew Duensing — Tue, 04 Aug 2020 20:36:56 +0000

NOTE: This was originally intended for my co-workers at Skuid, but I figured it might nice to share with the world. Hope you enjoy.

I want to say, first and foremost, this is just how I do things. It's not everything I do, it's not necessarily complete, it's not prescriptive, and it's not a codified "Skuid way" to do PR reviews. The following is roughly common threads in my thought process when going through a PR. If you, the reader, learn something then that would make me really happy. But if you don't this has been a good exercise for me as well.

The second thing I want to say, is that if you like the way I've reviewed PRs in the past, I want to say that I don't do anything that you can't do too. We all have unique ideas from time to time, but really all I'm doing is asking questions.

And if you don't like how I've reviewed a PR of yours, then I am very open to feedback. Send me a message and lets talk.

Here are the sorts of questions I ask. These are roughly in order too.

Are the builds passing? If they aren't I usually let the submitter know, unless they've specifically asked for feedback on an incomplete PR, or if it's a draft PR.
What is the functionality like? It's usually helpful to know ahead of time if something isn't working when I'm going through the code.
- Does it do what the ticket describes?
- Do the non-happy paths work? I usually try to modify the test page to try things a little out of the ordinary.
- Does the ticket describe enough information for QA to do their job without reaching out to an engineer?
  - Does it have a test page?
- Will it cause regressions? Will it cause anything that will feel like a regression?
How is the UI Design aspect? We're not the designers, but we can save them from a lot of trouble if we handle as many aspects as we can before it circles back to them.
- Are there any borders, spacing, colors, border radii, etc. that do not fit within our design system guidelines?
- How are the contrast ratios? Does it look like it would pas WCAG AA guidelines?
- If anything feels "off" verify that this aspect of the experience has made it through design. Inevitably there will be gaps in the designs we sometimes need to talk through a little more.
- Is there any "jank"?
How is the approach, from an "architectural" standpoint?
- Is it sustainable? Is it extensible? I try to think what happens if we need to do something similar 3 or 4 more times. Sometimes it's too early to create an abstract solution, but it's nice to not dig ourselves into a hole either.
- Is it too sustainable? Is it too extensible? It's not all the time, but I'm always on the guard for making systems that we don't need yet. Usually this presents itself in the form of making a function that's only used once. And yes, I know this contradicts the earlier point; it's always a balancing act
- Is it "fixing" the wrong part of the code? This is always a tough one, but sometimes I see us (myself included) "fixing" something to satisfy Acceptance Criteria on a ticket, but there's actually a deeper issue going on that can be adjusted instead to prevent other similar issues.
What is the code quality like?
- Are there unnecessary event handlers? Subscriptions? Is it stylistically odd?
- Are we using a library where when we don't need to?
- Is the code introducing any new libraries that aren't strictly necessary?
- Are we adding any functions to our public API that we don't need to?
- Are there areas where a comment might be helpful?
- Are there any "magic" numbers or strings that should be named constants?
- I there the potential for performance pitfalls? Will it work as well in a complex page as it will in a simple one?
Is the solution accessible? If accessibility is too much to ask for in the initial PR, I usually will ask the submitter to create a follow up accessibility ticket.
- Does the focus end up in the right place?
- Can a screen reader correctly parse it?
- Does it use the right roles and aria attributes?
- etc.
What are the tests like?
- Is it testable with our current tools?
- Is there a test? If not, and it is testable, I'll ask for a test.
- Does the test actually cover the situation described in the ticket? Although not super common, sometimes we write tests that don't end up covering the initial problem. I've caught myself a couple times doing this.

If you've stumbled upon this article, and read the "Skuid" and don't know what that is, it is the name of the company I work for and the product I work on daily, a no code UI development toolkit. I love to make the company I work for look good, but it should be noted that this is not an official Skuid piece of content. The views, thoughts, and opinions expressed in the text belong solely to the author, and not necessarily to the author's employer, organization, committee or other group or individual.