Post

More from @searls

Justin Searls

@searls

Feb 23, 2022

As a person with a VP/C-level title, I get a LOT of junk email. I almost always trash and ignore them.

But today, for the very first time, I actually took a meeting with one of these people, and you'll NEVER GUESS (actually, you might guess) what happened next.

cw: scammers! 🧵

@thoughtbot

It all started when I got a message from someone named Richard C. Willison. I responded because their profile said they'd previously worked at @thoughtbot (they're great!), claiming he had joined a new services company with unbelievably low rates and suggesting they were US-based

The next day I got this follow-up e-mail, making largely the same pitch and artfully dodging whether their people were based in the US.

Having a single US-based salesperson as a front for offshore firms is sadly common. But due to the Thoughtbot connection, I took the meeting.

Read 10 tweets

Justin Searls

@searls

Feb 9, 2022

New talk! Debuts at 1pm eastern.

The title is too audacious, as usual: "How to Trust Again".

You might ask, "How can a ~30 minute video accomplish that?"

Answer: by centering trust on what YOU control about how you work, collaborate with your team, and relate to your company.

I wrote this talk because I spent most of my life playing the role of "irrationally distrustful bastard".

But 2020 turned us inside out. High-trust people in my life were broken by society's failures. I didn't realize how much I had relied on them for my own safety & stability.

Throughout the pandemic, I coped with others' trust erosion by—bizarrely & uncomfortably—becoming one of the most joyful, trusting people I know.

Looking back, it was a social investment strategy: shares in $TRUST were at an all time low and I bought them up at a steep discount.

Read 9 tweets

Justin Searls

@searls

Jan 21, 2022

Last year at RubyConf I did a talk about making Ruby gems (blog.testdouble.com/talks/2021-11-…) and yesterday I published a new gem called maybe_later (github.com/testdouble/may…).

Here's a thread pondering "why do a handful of people make a bunch of libraries when people never publish any?"

I think about this a lot, because my skills don't fit the mold of the Good Programmer archetype. When people express they're "not smart enough" to create new projects themselves, if anything it triggers imposter syndrome *in me*, because I'm genuinely very bad at a lot of this.

In fact, if you go back and look at the themes of the talks I've given, there's a through-line exhorting: "there's no man behind the curtain! Turns out we can just show up and start doing stuff!"

Sometimes that's lost in my pursuit of polish and carefully-coiffed slides & prose.

Read 15 tweets

Justin Searls

@searls

May 30, 2021

This morning's project: figure out how to get highlighted Japanese words out of my Kindle and into plain text, so I could import unknown words into my flashcard app to study them. Here's how I did it, in case you're interested

As usual, everything about this was too hard. 🧵

First off, I've been using a Kindle Oasis logged into my Japanese Amazon account to read novels. They're formatted like Japanese print books, with pages turning right-to-left and text laid out in vertical lines (top-to-bottom, right-to-left)

While Kindle ships with a Japanese dictionary (and even a Japanese-English dictionary if the OS is in English mode), most Japanese-learning apps (including my own) use the community dictionary JMDict, so I installed a Kindle port of that one (github.com/jrfonseca/jmdi…) here

Read 10 tweets

Justin Searls

@searls

May 15, 2021

https://twitter.com/searls/status/1393385209089990659

I'm realizing I've never shared this publicly before, but I probably should: almost all the advice you hear about software testing is bad. It's either bad on its face or it leads to bad outcomes or it distracts by focusing on the wrong thing (usually tools). A brief thread on why

https://twitter.com/searls/status/1393385209089990659

Programming is hard. Writing a program that works reliably and doesn't fall over within a few weeks or months maintenance is very difficult and—frustratingly and absurdly—getting harder all the time.

Testing, security, accessibility, internationalization—all secondary concerns.

Because writing production code is both difficult and THE thing programmers are paid to do, it always takes priority. We budget the bulk of our time, communication, training, and mental energy to it.

We don't have enough time or headspace to prioritize concerns like testing.

Read 16 tweets

Justin Searls

@searls

Mar 12, 2021

I think it's time to discuss the efficacy of Pull Request Reviews as a way to ensure code quality and shared understanding on software teams. Here's a little thread on some of the experiences I've had in my career, why I think this matters, and what we can do about it.

First though, a bit on my background.

In the early days of my career, most teams used cvs or svn. A "code review" was literally a scheduled meeting in a physical room with a 1024x768 projector. Everyone nitpicked your code, it was terrifying, and it took at most two hours.

Now we use git. git's easy merges enabled GitHub to build a sophisticated Pull Request Review tool & workflow. People love it. Most teams now require an approved review for every PR. Everyone nitpicks your code, it's terrifying, and it takes anywhere from 4 hours to 3 years.

Read 21 tweets

Share this page!

Enter URL or ID to Unroll

Justin Searls

Try unrolling a thread yourself!

More from @searls

Justin Searls

Justin Searls

Justin Searls

Justin Searls

Justin Searls

Justin Searls

Did Thread Reader help you today?

Don't want to be a Premium member but still want to support us?

Send Email!