Craft and publish engaging content in an app built for creators.
NEW
Publish anywhere
Post on LinkedIn & Mastodon too. More platforms coming soon.
Make it punchier ๐
Typefully
@typefully
We're launching a Command Bar today with great commands and features.
AI ideas and rewrites
Get suggestions, tweet ideas, and rewrites powered by AI.
Turn your tweets & threads into a social blog
Give your content new life with our beautiful, sharable pages. Make it go viral on other platforms too.
+14
Followers
Powerful analytics to grow faster
Easily track your engagement analytics to improve your content and grow faster.
Build in public
Share a recent learning with your followers.
Create engagement
Pose a thought-provoking question.
Never run out of ideas
Get prompts and ideas whenever you write - with examples of popular tweets.
@aaditsh
I think this thread hook could be improved.
@frankdilo
On it ๐ฅ
Share drafts & leave comments
Write with your teammates and get feedback with comments.
NEW
Easlo
@heyeaslo
Reply with "Notion" to get early access to my new template.
Jaga
@kandros5591
Notion ๐
DM Sent
Create giveaways with Auto-DMs
Send DMs automatically based on engagement with your tweets.
And much more:
Auto-Split Text in Posts
Thread Finisher
Tweet Numbering
Pin Drafts
Connect Multiple Accounts
Automatic Backups
Dark Mode
Keyboard Shortcuts
Creators loveย Typefully
150,000+ creators andย teams chose Typefully to curate their Twitter presence.
Marc Kรถhlbrugge@marckohlbrugge
Tweeting more with @typefully these days.
๐ Distraction-free
โ๏ธ Write-only Twitter
๐งต Effortless threads
๐ Actionable metrics
I recommend giving it a shot.
Jurre Houtkamp@jurrehoutkamp
Typefully is fantastic and way too cheap for what you get.
Weโve tried many alternatives at @framer but nothing beats it. If youโre still tweeting from Twitter youโre wasting time.
DHH@dhh
This is my new go-to writing environment for Twitter threads.
They've built something wonderfully simple and distraction free with Typefully ๐
Santiago@svpino
For 24 months, I tried almost a dozen Twitter scheduling tools.
Then I found @typefully, and I've been using it for seven months straight.
When it comes down to the experience of scheduling and long-form content writing, Typefully is in a league of its own.
Luca Rossi ๊ฉ@lucaronin
After trying literally all the major Twitter scheduling tools, I settled with @typefully.
Killer feature to me is the native image editor โ unique and super useful ๐
Visual Theory@visualtheory_
Really impressed by the way @typefully has simplified my Twitter writing + scheduling/publishing experience.
Beautiful user experience.
0 friction.
Simplicity is the ultimate sophistication.
Queue your content inย seconds
Write, schedule and boost your tweets - withย noย need forย extra apps.
Schedule with one click
Queue your post with a single click - or pick a time manually.
Pick the perfect time
Time each post to perfection with Typefully's performance analytics.
Boost your content
Retweet and plug your posts for automated engagement.
Start creating a content queue.
Write once, publish everywhere
We natively support multiple platforms, so that you can expand your reach easily.
Check the analytics thatย matter
Build your audience with insights that makeย sense.
Writing prompts & personalized postย ideas
Break through writer's block with great ideas and suggestions.
Never run out of ideas
Enjoy daily prompts and ideas to inspire your writing.
Use AI for personalized suggestions
Get inspiration from ideas based on your own past tweets.
Flick through topics
Or skim through curated collections of trending tweets for each topic.
Write, edit, and track tweetsย together
Write and publish with your teammates andย friends.
Share your drafts
Brainstorm and bounce ideas with your teammates.
NEW
@aaditsh
I think this thread hook could be improved.
@frankdilo
On it ๐ฅ
Add comments
Get feedback from coworkers before you hit publish.
Read, Write, Publish
Read, WriteRead
Control user access
Decide who can view, edit, or publish your drafts.
Remote Pair Programming Good Practices: A Thread.
Found the slides of a presentation that @qcoding and I gave to the entire CTO Org at Amex two years ago when we were both there.
Thought it had a lot of great stuff that could still be useful to others.
Why not share?
๐งต
Remote pair programming:
Outline:
1. When to do it,
2. When NOT to do it,
3. Practical Tips on how to do it,
4. Recommended tools,
5. Additional references.
But first, let's start with WHY to do it.
0. Why to do it
WHY?
I'm pretty sure the first question that comes to mind is Why?
Why should I pair?
Why would TWO engineers share the SAME machine and work on the SAME problem for hours or sometimes for multiple days?
Well, pairing brings many benefits.
Here are a few we want to highlight:
1- HYPER FOCUS (A.K.A MONOTASKING) - Pairing keeps you and your pair super engaged as you will not access slack, email, or any distracting website while you have someone else watching your screen or right there counting on you for help.
2- Pair programming is also CONTINUOUS "RUBBER" DUCKING.
You have someone there to talk to you, unblock you, catch your mistakes, or give feedback on your code ALL THE TIME.
3- Pairing is a fantastic way for ONBOARD NEW TEAM MEMBERS. A great way to work on real problems, answer real questions, and explain codebase/architecture details as needed instead of reading documentation for days to find out only much later that they were not up to date.
4- Pairing is also a risk-mitigation strategy. Pairing helps to decrease what is known as "THE BUS FACTOR."
That comes from this question:
> "How many people could be hit by a bus without any impact on your project?"
Two other Lesser-Known Benefits of Pair Programming:
1) Flow is easier to recover. If one of you is interrupted, the other can remain in a flow state and quickly bring you back in.
It reduces the impact of interruptions.
Two other Lesser-Known Benefits of Pair Programming:
2) Your hands get a break. RSI (Repetitive Stress Injury, can be caused by excess typing) is no joke.
It can end careers.
Pairing lets you share the typing and put fewer miles on your tissues.
WHEN?
Let's start with the two obvious ones:
Number 1: The most obvious reason to pair program is when you're stuck. Bringing in a second mind is a great way to get unstuck.
Number 2: It's okay to start a slack chat about a programming question. But if that chat goes back-and-forth โespecially in real-time โ that's just not efficient.
So make that an internal trigger that it's time to look at the same screen and talk about it.
Number 3: To save time when you're making design decisions.
The thing is, as developers, we're almost always making design decisions. Sometimes these are big decisions around architecture. Sometimes these are more minor decisions, like how to name something.
Number 4: Pairing reduces the delivery time of that one item. Of course, two people can work in parallel on two problems. But, working together on the same problem makes solving that one problem faster.
So, it reduces the delivery time of a single item, not the throughput.
Number 5: And finally, pairing is a chance to learn skills from your partner.
It isn't about junior engineers vs. senior engineers.
Pairing is a chance for old dogs to learn new tricks and new dogs to learn some old tricks!
When NOT to Pair?
There are probably more scenarios, but these are the big 2 reasons to avoid pairing in my opinion:
1- Talking about decisions again, whenever you are not making decisions or a REALLY small amount of them, pairing is not a great use of two brains.
So, if it is a repetitive task or just following instructions that both engineers are familiar with, pairing is not a good idea.
2- Whenever you need to study a new framework, to research, to explore many options, you might need your own time to do your reading without somebody talking or watching you.
You and your pair can connect later.
So, pairing is probably not a good idea while researching.
*New Addition - When to Pair vs. When NOT to Pair:
This is a matrix from a paper. One caveat is that programmer expertise is not necessarily years of exp., but experience on that codebase/tech-stack/domain.
So you can be a Senior eng. but still a Junior on the project/codebase
HOW?
TIP NUMBER 1: Use or Try the Driver/Navigator pairing style.
In pairing, it's helpful to adopt different roles. Like two people on a road trip, you can have a Driver and a Navigator.
The Driver is doing the typing and can focus on small details.
The Navigator keeps an eye on the landscape and can focus on the big picture.
It combines two styles of thinking: The Driver can do "tactical thinking", while the Navigator can focus more on "strategic thinking".
TIP NUMBER 2: Microphone close to your mouth
Use the microphone close to your month, BUT NOT TOO CLOSE or not too far away.
Avoid the computer's microphone or speakerphone at all costs. Room echo and any background noise will make it super hard to understand what you're saying and super annoying to the other person.
IN SHORT, YOU NEED A GOOD HEADSET and a GOOD MIC FOR REMOTE PAIRING.
Remote pairing, in particular, is all about GOOD AUDIO QUALITY,
It is one of the things that has improved a lot since the beginning of the pandemic.
TIP NUMBER 3: Camera on (bandwidth permitting)
When you can, it's helpful to turn your cameras on because video gives us richer communication with more context.
You can see emotional communication, like facial expressions. And you can see some context about the other person's life.
It helps to create a stronger human connection.
But if video causes lag, you can both agree to turn your cameras off.
TIP NUMBER 4: Regular breaks (Pomodoro timer)
Breaks.
You need them.
Plan for them.
> "Professionals take breaks. Amateurs don't. Breaks are part of performance. They're not a deviation from performance." โ Book: When: The Scientific Secrets of Perfect Timing by @DanielPink
Pairing and, in particular, REMOTE PAIRING is really exhausting.
So, make sure to do regular breaks, OR otherwise, you will be dying after a few hours.
And REMEMBER, pairing is all about having a good experience.
It needs to be something that both parties enjoy and look forward to. Not something painful.
Regular Breaks make the pairing experience less exhausting and a lot more productive and fun.
TIP NUMBER 5: Switch roles often
How to switch remotely?
It's helpful to switch who is driving reasonably regularly โ at least once every hour, maybe once every 15 minutes.
To avoid the lag that comes with remote keyboarding, just switch the work from one computer to the other
An easy way to do this is by using a shared branch.
"In this image, Thiago can just commit and push, and I can pull. Then I become the Driver and share my screen." @qconding
`$ git commit -mWIP & git push`
TIP NUMBER 6: Screen size mismatch (decrease resolution of larger screen)
More often than not, you will pair with somebody with a different display or completely different screen resolution than yours.
As a Rule of Thumb, always use the smallest resolution of the two as a baseline.
AND REMEMBER, REMOTE PAIRING IS ABOUT A GOOD AUDIO & VIDEO & SCREEN SHARING EXPERIENCE, not only for ONE SIDE, for BOTH sides.
Finally, recommended tools:
Tuple by @r00k. By far the best.
But, even though Webex, Zoom, Meet, Teams are not the best tools out there for Remote Pairing because they don't easily enable the Navigator to take control over the keyboard or quickly point out things on screen, they can still GET the JOB DONE, and they are STABLE.
References:
If you want to know more, here are two of my favorite articles on pairing:
1- The first one answers pretty much every single question you might have on pairing.
2- The second one answers one of the most asked questions: What does an Effective Navigator do?
Books:
Three books that talk a lot about pairing/tools that I recommend.
I found out the second one this week - Practical Remote Pair Programming by @adibolb - and I'm impressed by the content and how actionable it is.