Technologies: I'm David, a Rails dev and engineering leader, with 10+ years shipping Rails apps to production and leading teams doing the same. I started in Rails back in Rails 2 and have been in the Rails world ever since. I'm known in the Rails world for my writing (including a book) on the Hotwire stack.
I've led product and engineering at bootstrapped SaaS companies as part of product orgs ranging in size from just me to > 100, and I've directly managed teams of 18 while still keeping my hands close to the code, and close to the product roadmap.
I do some consulting with early stage founders, writing code, hiring and coaching teams, and helping get new products to market. I would love to shift back out of consulting and into my next full time role, preferably somewhere where I can wear both an engineering and a product hat, with the chance to make a big impact.
Résumé/CV: You can learn a bit more about me and read some of my technical writing here: https://www.colby.so/writing. Shoot me an email and I'm happy to share my full background.
Technologies: I'm a Rails dev and engineering leader, with 10+ years shipping Rails apps to production and leading teams doing the same. I started in Rails back in Rails 2 and have been in the Rails world ever since. I'm known in the Rails world for my writing (including a book) on the Hotwire stack.
Résumé/CV: You can learn a bit more about me and read some of my technical writing here: https://www.colby.so/writing
I'm hacking on Trailbound, a hiking and backpacking planning tool. The goal is combining a light version of the routing capability of Caltopo or GaiaGPS with more granular "leg" mapping based on how I learned to plan off trail trips and sharing functions that make it easy for my wife to know where I'm going to be, who I'm with, and who to contact if I'm not back in touch when I said I would be.
Its been a blast to build. At one point I was hosting my own ORS server but that's extremely silly to do when Mapbox has a very generous free tier. Learning about all of the open source tooling and open data available in the mapping world has been incredible.
The cost of the Hetzner box it runs on isn't much more than a Caltopo pro subscription with the added bonus of being much easier to share with non-hikers.
No marketing site, no onboarding, or any real UX attention paid to the app at this point, it is mostly Just For Me and will probably remain that way once I land a job again.
I'm starting to chip away at an iOS app so I can get offline access to maps and routes, but I'm not a Swift dev so the going is slow.
Big Bend National Park, a two hour drive from the McDonald observatory has extremely dark skies, as does the area immediately around the observatory. On the drive to the observatory from Fort David you’ll drive past a community of folks who live near the observatory specifically for the astronomy opportunity the dark skies there afford.
The entire Big Bend region is beautiful, remote, and very dark at night.
Central Idaho is also a dark, beautiful place for stargazing.
I wrote a “book” (really a 30,000ish word tutorial) on Rails development earlier this year and I hated the idea of publishing it as a static PDF so I built a web app just to host the book’s content and change log, along with validating license keys/authenticating users.
I’ve never found video courses to be useful for me - I do much, much better with written word that I can move through at a comfortable pace. I’m glad to see tools coming to make text-based courses easier to build
Will give this a try and see how my book content translates over.
I created Upload Academy for this reason. We're still building the platform and our first course is nearly complete: https://cloudopslevelone.upload.academy (currently freely available.) Our focus is helping people break into IT with a highly focused roadmap and course materials designed specifically for the goal.
I've never understood the obsession with video libraries with 50,000,000 hours of video content.
I posted as a candidate in one thread over the summer and got contacted by ~10 companies and did a handful of interviews — a couple were duds with non-technical founders casting a wide net but others were solid opportunities. I also applied to a few jobs from that same month's employers thread and got to the offer stage with one of those companies.
I had enough success to try again the next time I am looking for a new gig.
I don't mind the "show me something you've coded" as an alternative to code challenges, but the way it is presented in this article reads an awful lot like it is a way to identify who the interviewer likes nerding out with the most, not the person who is most likely to be the best fit for the organization's needs.
> Companies want to standardize their hiring when really they should be looking to customize it to each candidate.
This is not the right idea. You should not be customizing your hiring process to each candidate. A standard hiring process with accountability for interviewers to follow the process is incredibly important if you want to reliably hire high quality talent as an organization grows.
"Customizing" for each candidate is a great way to give interviewers permission to make the interview simple for the people they like and brutal for the people they don't. It is also a great way to overwhelm new hiring managers who are still trying to figure out how to evaluate talent as they grow their teams.
> Lots of companies want to spread the blame of a bad hire across a committee of 4 or 5 people. That is also wrong.
This is not why multiple people are involved in a hiring process. Leaving hiring entirely in the hands of one person guarantees biases make their way into the hiring process and result in a lower quality team.
> This is not the right idea. You should not be customizing your hiring process to each candidate. A standard hiring process with accountability for interviewers to follow the process is incredibly important if you want to reliably hire high quality talent as an organization grows.
Yeah, doing a custom interview process per candidate sounds like a discrimination lawsuit waiting to happen. I don't know how you could possibly defend against the claim that the interviews are designed to help some candidates and hurt others if you're literally on the record saying you actively try not to use the same interview process for all candidates.
Yes, it is important to write and I wish that many folks I've worked with in the past had been better writers (and readers). I am job searching right now after leaving a very, very meeting heavy culture and one of my top criteria is finding a company that values asynchronous discussion and written communication whenever possible.
I'm totally aligned with the author on the value of writing as a tool for thinking, learning, and exploring and I agree that there are blockers for some folks that make them less likely to stretch their writing muscles, especially in professional settings where the default is often "let's jump on a quick call".
Sadly, the article is poorly written. I don't expect professional-level editing on a personal blog, but I would hope for a higher standard when the piece is written by someone who is building and (presumably) charging money for a course on writing.
I believe this article is targeted at those who are not as comfortable with writing - those people who jump on a call for anything, and want to learn to use async communication more. It sounds like the author is starting to explore that territory. Whereas people like me used to hang around IRC while doing homework and write entire blog posts while half asleep in bed. We're not the ones who simply write while not told to. We have to tell ourselves to stop writing and listen/read more.
If you're looking for a job at a company that highly values writing, please send me your resume! cweber [at] thelabnyc [dot] com.
We're a digital agency based in NYC, looking to hire a Sr. level engineer either on-site or remote within the US. Over the past few years we've really gotten serious about technical writing, especially around requirements gathering/documentation. We now strive to treat documentation as just as important as code—meaning a feature's requirements get written and code-reviewed via merge request _before_ implementation work begins.
So, if you're looking for a place that asynchronous discussion and written communication, you'd fit right in.
The most-deflating response to a thoughtfully-written email that lays out a clear set of strategic choices is the immediate TL;DR of the business world: can we schedule a quick call to make sure we're all on the same page about this? What's a good time for you?
I think you shouldn't be too deflated about this. For many decisions, a sync session is necessary (whether it's a group review or a team call). The biggest benefit of a good writing culture is to turn five open-ended time-consuming group calls into a couple of well-written emails, and a final decision call with a clear agenda.
So tiring to get those responses. My old company was forced to go remote when the pandemic hit and the anxiety that the founder had about remote resulted in meetings about meetings to prepare everyone for the meetings.
Everyone has different learning styles, some conversations are definitely better in real-time and in-person but the default behavior being refusing to read an email longer than 3 sentences is rough.
The default behaviour being an assumption that anybody who has any questions, thinks a back and forth would be beneficial or possibly even wants to arrive at a decision democratically is a dullard who didn't even bother to absorb the perfectly clear, indisputable and comprehensive final word on the matter that is their original email is pretty rough too though.
I guess sometimes people who [rightly or wrongly] think a strategic decision isn't worth 30 minutes of their time find it easier to suggest the other person is the one who's not putting the effort into it...
This feels like an odd assumption to make about my comment. I don't think all meetings are a waste of time and I certainly don't think people with different work preferences than me are dullards.
My experience has been heavy on people who skip reading in favor of a meeting even when the reading is to provide historical context, summarize learnings, and present what we know about a situation. Not reading turns what should have been a productive, forward looking discussion into a meeting rehashing old information for the folks who didn't do their homework.
In my professional life, I've encountered far more people who prefer to have meetings that could have been emails than I have people who think a strategic decision isn't worth 30 minutes of time for a discussion but perhaps my use of "default behavior" was a bit strong.
I suspect the meeting-heavy cultures and aversion to reading I've encountered are largely driven by discomfort with writing, not reading which is where articles like this one could add some value.
> This feels like an odd assumption to make about my comment.
I mean, "refuse to read more than 3 sentences" (or "the TLDR of the business world" and "I-didn't-bother-reading-your-email-so-please-spend-an-extra-30m-explaining-it session is less so" in others' comments in the same subthread) seems like unrealistic as well as incredibly uncharitable assumptions to make about people's general motivations for requesting followup calls. Especially if the subject matter of the original email was something as non-trivial as "a clear set of strategic choices"
Indeed, if it ends up actually taking 30 minutes to explain an email, it's obvious both that the other person is putting far more time and effort into the call than they would have done into scanning the email text, and that the email itself couldn't possibly have communicated all the information the caller [felt that they] needed to know in sufficient detail.
Which doesn't guarantee that the "quick call" was actually a productive use of time, or that the caller's questions are particularly good ones or that the caller couldn't have included followup questions in their reply, but if somebody can't think of any reason why colleagues receiving their email would call for clarification other than lack of interest in reading, there's a decent chance it's not [just] the colleagues with the communication problems. Even if the colleagues don't have additional information to add and seem fixated on something which point 11b was supposed to rule out.
Sure, as the number of people in a group meeting grows the probability someone hasn't read (or has read and has completely forgotten) the meeting prep notes approaches 1, but that's a separate issue from people receiving an email and calling for one-to-one clarification.
Have you entertained the possibility that we can tell, in said call, that the person who immediately requested the call needs the email explained to them (or asks multiple questions recapitulating the basics of the email) before they can contribute?
I'm not complaining about people asking questions to clarify or build on their understanding of the email. (Or even a lack of understanding; it's hard to build enough shared context to communicate well.)
You're the one here uncharitably projecting the assumption that we're punishing people for asking reasonable questions about something they made an effort to read.
I don't think it's uncharitable to assume that when someone writes that a generic type of request for synchronous communication is the "TLDR of the business world" which is "deflating" to receive after laying out a "clear set of strategic choices" in writing, their objection is to what they said they objected to (receiving an email asking for a call to discuss strategic choices after writing an email they believe to fully cover them), not the ignorant nature of specific questions not asked in that email.
But hey, maybe the brief text summary you wrote didn't encapsulate every nuance of your thoughts on the issue and any particularly bad habits specific colleagues of yours may have. I guess you don't want a call to clarify it ;-)
> The most-deflating response ... is the immediate TL;DR of the business world ...
So, here we are, having a text-call to clarify your comprehension of something you actually read (if uncharitably). Because I can tell you bothered to read it (and it bothered you enough to comment).
If I could tell you hadn't bothered to read it--then yes, I wouldn't want to clarify it.
Even if a response is so immediate the recipient can't possibly have had time to parse more than the topic, I'd still regard it as more than a little paranoid to conclude that the most likely purpose for anyone scheduling [more] time in future to speak to you on that specific matter is to avoid the effort of reading what you've written. Unless you're in the habit of mailing people the manual instead of the bullet points they asked for.
Ultimately most people who don't want to take the time to read someone's email properly don't reply to schedule a followup action that will take even more time, they hit mark as read and move on. People who genuinely value others opinions (or want to be seen to) are going to want a followup call anyway, so they might as well pre-arrange it before they've had chance to sit down and read every paragraph and check out your links. Especially if they're also in the habit of insta-replies to avoid "about the email sent 30 minutes ago..." chasers from other people. Sure, it's not impossible their reaction to receiving an email from you is completely irrational dislike of reading well-structured and clear prose, but then they're the one soliciting more explanation rather than being deflated about followup.
I am glad you know that I don't really have people schedule meetings right after getting an email in which I (and others) have to explain the content of said email before we can do anything productive.
Now that I know everyone who schedules a meeting to have someone explain an email to them actually read and understood the email it makes total sense that they ask questions that betray a complete lack of knowledge of anything beyond the general topic.
I would expect someone who read the email to be able to form a question that builds on or slices into some concern the email addressed, but now I know that feigning ignorance is just their way of showing how much they appreciate my time and opinions.
I assume that response wasn't intended to convince me I was entirely mistaken in considering the possibility that you (and others) would ever jump to the wrong conclusions about people's intentions, but I hope you found the experience of writing it cathartic anyway.
Of course it wasn't, because it's obvious you won't be convinced.
None of this was about intent. You projected that in. I can tell when someone didn't read the email. It isn't about people who are scheduling the decision session before reading the email but ultimately do it. It isn't about people who read the email but have questions. It's about people who didn't read the email.
But you won't accept that I regularly have and correctly understand the experience. You're determined to take an internet stranger's personal anecdotal experience and read it as something that must be false if it isn't globally true.
I publish on my own website (https://colby.so) which I host on Netlify and publish with Jekyll.
For the first year or so I also published every new post on Medium and dev.to (with my site as the canonical URL on both) so that more than zero people would read my articles.
I was lucky enough to get a few of my code-heavy tutorial posts ranking well on Google for the niche I focus on and now that I have a couple hundred organic visitors to my own site each day, I've stopped bothering with Medium and dev.to.
https://fly.io has been amazing for me. Dunno how their docs used to look but IMHO today it is very detailed they are especially forward-thinking regarding documenting some nice edge use-cases for the platform.
Glad to hear that. Giving them another look is on my list, I could tell they cared about their docs but it was clear they were still filling in the gaps in some areas.
Remote: Yes
Willing to relocate: No
Technologies: I'm David, a Rails dev and engineering leader, with 10+ years shipping Rails apps to production and leading teams doing the same. I started in Rails back in Rails 2 and have been in the Rails world ever since. I'm known in the Rails world for my writing (including a book) on the Hotwire stack.
I've led product and engineering at bootstrapped SaaS companies as part of product orgs ranging in size from just me to > 100, and I've directly managed teams of 18 while still keeping my hands close to the code, and close to the product roadmap.
I do some consulting with early stage founders, writing code, hiring and coaching teams, and helping get new products to market. I would love to shift back out of consulting and into my next full time role, preferably somewhere where I can wear both an engineering and a product hat, with the chance to make a big impact.
Résumé/CV: You can learn a bit more about me and read some of my technical writing here: https://www.colby.so/writing. Shoot me an email and I'm happy to share my full background.
Email: david@colby.so