Shawn Wang (swyx) writes about developer careers, learning in public, developer relations, and JavaScript tooling.
HN commenters recommend it for JS and general dev articles, and cite his learn-in-public idea. One finds his insights valuable.
Interesting point, I should have made the distinction on company size. Most of my knowledge comes from speaking to early stage DevRel.
I hope I'm not being disingenuous. I'm not disputing that the bottom line always comes down to growth metrics similar to marketing. My goal is to build my own DevTool so my motive is to figure out how all this stuff works.
I'll give you an example. I spoke with Brandon West who was the first DevRel at SendGrid and he said "If you're considering a DevRel job thinking about what size of company you want to join & whether you want to be on marketing, engineering, product side - because DevRel can work on all of those departments. If you want to have your hands on product, then a startup will work better than something with big efficient machinery and you're there to be the spokesperson" https://podcast.bitreach.io/episodes/the-early-stages-of-devrel-with-brandon-west from 3m5s. Throughout the whole episode the feeling I get is that everything was messy and Brandon was doing everything that needed to be done. He's like a hybrid of engineer and marketer.
You made a good point though and Brandon supports your point too - it seems to be a lot more delineated and specialised beyond the startup stage.
> That the work looks more like running or attending hackathons or giving technical talks at developer-focused events doesn't change the goals or measured outcomes.
Great point! You're right the measured goals are similar in marketing and DevRel. I…
Mainly, there are 3-4 reasons for considering alternatives to using booleans:
1. Booleans are primitive types without rich domain-specific information or context. When using true/false, it can be more beneficial to employ more descriptive options such as AnsweredYes/AnsweredNo, PositiveResult/NegativeResult, LightsOn/LightsOff, or UserOnline/UserOffline. Mixing and matching booleans of different domain types can lead to errors that the compiler may not catch. For instance:
bool isLightsOn = true;
bool isUserOnline = false;
bool isAdmin = true;
if(isLightsOn && !isUserOnline && !isAdmin)
{
...
}
compare with Elixir:
case
{lights_status, connection_status, user_role} do
{:lights_on, :user_offline, :unprivileged_role} -> ...
...
end
The example above is basically a Decision Table [1].
While booleans can still be used in system code or libraries, it is advisable to avoid them in application code.
2. Preemptive pluralization [2] makes it easier to refactor code. Going from two options to three is simpler than transitioning from one option to two. Consider the following examples:
bool isLightsOn;
or
type LightsStatus = Bool
vs
type LightsStatus = LightsOn | LightsOff
Suppose there is a new requirement to support dimmed lights. In the former case, significant code refactoring is necessary. In the latter case, adding a new option to the sum type is straightforward, and the compiler assists in handling the…
Putting thoughts into words is an extremely valuable practice. It makes you a far better thinker, helps you pick & choose what ideas are important, what words to use to think about things. I 100% recommend writing down what you are learning.
There's a much longer form write up on why you should write on a blog or otherwise in a public area, in Swyx's Learn In Public[1]. You're doing it, you're on the path, you're doing great. Keep it up.
The point, overwhelmingly, to me is, you don't know what will be valuable. You don't know when it will be. People are random functions, in randomized situations, and it might be years, but someday either you or someone else being able to run into your words, your posts, & gain some insight: that could make all the difference, for you, for someone else.
One other small plug, some friends have "TIL" blogs or git projects, where they add 1-3 sentence things that they learn. It's really fun, for them, and for their growing audience. Time commitment is low, anything goes for topics (many are 60/40 tech/other), it's interesting to read, it gives the readers some idea of where you are, and best of all, it encourages mindfulness: being on the lookout for what you are learning, watching yourself grow, seeing yourself evolve over time. I love the TIL blogs. Need to start mine. ;)
[1] https://www.swyx.io/learn-in-public/
>I've been wrecking my brain how to make $10 on anything online
If you are really serious about $10 (and not some other larger number), here are some tips:
* Pick a topic you know really well (programming, cooking, sea diving, whatever)
* Make an infographic (get started on the topic of your choice, some specific and useful practical tip, etc) - picking a template from free tier Canva will go a long way in producing a good looking graphical post (you can even do animations)
* Put this up under pay-what-you-want model on sites like Gumroad (so, minimum price free but users can pay if they wish) - see https://mathspp.gumroad.com/l/cheatsheet_list_comps_101 for an example
* Post a sample on sites like Twitter, Reddit, etc (just the nice looking graphic, add a link to Gumroad later in comments if the posts start getting attention)
* Make a video to show demos (if applicable)
* Be consistent! Give it your best shot for topics you are really confident about. Listen to feedback. Learn and Build in Public for better reach (see https://swyx.io/learn-in-public and https://chriscoyier.net/2012/09/23/working-in-public/)
If you want an example for someone making a living by doing things like this, check out Julia's https://wizardzines.com/
This is why SF was so amazing in its heyday (still is, but much less than pre-pandemic days). Just being here offered so many opportunities for networking, and it compounded the longer you stayed and were actively going out.
I would say that in today's remote-first world, building in public (and learning in public[1]) is the best way to get the attention of the stakeholders you desire -- not just prospective cofounders, but also investors, customers, partners, and contributors. (An aside -- this is one of many reasons I believe that commercial open source in particular has a very bright future.)
Some tangible ideas: Be active on twitter, start a podcast, write blog posts, stream on YT, deliver meetup/conference talks. Once you are more in the public eye, living in a Tier 1 city is the next step as it gives you a greater chance of meeting the people who discover you online!
Happy to chat more if you'd like! This subject or specific startup ideas if you're interested twitter.com/benghamine -- DM's open!
[1] https://www.swyx.io/learn-in-public/
> I wonder if we'll ever really have something like that on top of Nix or NixOS.
Xe, go do it! (:
In all seriousness, Fly.io has explored this path (and very well may pursue it depending on RoI of going down this route, I'd imagine): https://github.com/superfly/recco
Even though I'd like Fly.io to be more like Heroku, it is railway.app that comes the closest (but I believe they use buildpacks like Fly.io does rather than Nix/NixOS).
Speaking of Nix, shout out to replit (https://blog.replit.com/nix) for having a holistic view of the product and it is unlike anything I've ever seen before. And unsurprisingly, most junior developers that I interact with, prefer replit over other alternatives.
Heroku may be dead, but an entire range of upstarts have risen up in its wake: https://www.swyx.io/cloud-distros