Merry Christmas to everyone - but especially to all the on-call folks holding down the fort during holidays.
At Buffer we do something I really love during the holidays. Instead of the usual 7-day on-call rotation, every engineer volunteers for just a single day between December 24th and January 1st. One day each, so everyone else can fully enjoy their time off without worrying that something might break.
Nothing major has ever happened during Christmas (I only remember a tiny incident I had on my override a few years ago), but the peace of mind this gives the team is priceless.
So to all the engineers on call today - may your logs stay quiet, your alerts stay silent, and your Christmas be calm.
Happy holidays! 🎄❤️
Socials
Posts I've shared on socials lately. Synced daily from Buffer.
Last synced:
Best secret to productivity at work? Becoming unblockable. I love how @Sean Goedecke put it in his recent article: "The easiest way to avoid being blocked is to have more than one task on the go. Like a CPU thread, if you’re responsible for multiple streams of work, you can deal with one stream getting blocked by rolling onto another one. While one project might be blocked, you are not: you can continue getting stuff done."
That's a perfect description of how I like to operate, and I think it's the biggest differentiator between junior & senior engineers. You are never idle, AND you are not doing unimportant tiny things just to keep yourself busy. There's always something big to accomplish and move forward!
At @Buffer, we're known for our transparency, including salaries that are publicly available for anyone outside the company. I haven't heard about many companies like that - there are ones that have internal transparency, but it rarely goes outside the company's walls.
Recently, however, I learned about @Oxide Computer Company. They build modern, high‑performance server racks - allowing companies to "own their cloud". And they've got quite an interesting salary philosophy - everyone is paid $235,000 - literally everyone in the company, independent from the job title! (with exception to sales people, who have got extra commission component)
Do you know any other companies where it's all transparent like that?
The biggest blockers in my engineering career had nothing to do with code - these are 3 mistakes that were slowing my career.
✅ Treating my job like a checklist
For quite some time when I was starting out I thought my job was “complete the Jira tasks in front of me.” That mindset capped my growth. The moment I started thinking in terms of product, not tickets, everything changed:
Why are we building this?
What problem are we solving?
Is there a simpler approach?
What happens if we don’t do this?
Is this the right trade-off?
Engineers who think beyond their ticket become 10x more valuable.
They get more trust, more ownership, and more opportunities.
✨ Chasing perfectionism
Pretty much every junior (my past self included) is obsessed with perfect architecture, perfect patterns, perfect abstractions, to the point of missing other important aspects. Clean code matters - but only when it matters.
Most of the time, the business doesn’t value “perfection”; it values shipping, unblocking, and solving real problems. Perfectionism felt like progress, but it only slowed me down. Pragmatism is what accelerates a career - at least mine.
🧑💻 Believing technical skills were enough
This one hurt the most. I thought if I became a great coder, everything else would follow.
It doesn’t work like that:
Technical skills open the door. Soft skills keep you in the room.
Communication, ownership, leadership, clarity, writing, decision-making: these are the skills that turn a “good engineer” into a “senior engineer.”
And you rarely hear that early on.
If you’re at the beginning of your career, avoid these mistakes and you’ll grow way faster than I did.
What slowed your growth early on?
I’m curious to hear your histories!
Most employees miss the easiest way to stand out in their company:
🐶 Dogfooding - using the product you actually build.
It sounds obvious, but if you look around, almost nobody does it. And that’s exactly why it’s such a huge opportunity for you to stand out.
Work on a social media tool like Buffer?
💭 Use it for your own socials.
Build software for photobooks?
🖼️ Create your own yearly album.
Create tooling for monitoring AI training quality?
⚙️ Train a small model yourself and put it through the system.
You see things your company would otherwise miss. You build better intuition. You give better feedback. You make better product decisions.
And leadership notices it!
Some companies even try to incentivize it.
When I worked at Meta, you could get a monthly ads credit to support non-profits. Almost nobody bothered. The people who did, especially within teams working on ads? They learned more about the product in two months than others learned in a year.
At Buffer, it’s an expectation that everyone becomes a creator.
I’ll be honest - I resisted at first. I spent eight years around social media (Meta + Buffer), yet I barely posted myself.
But once I changed my approach, it was an eye opener.
The moment I started using Buffer the way our customers use it, I began noticing things I never would have seen as “just an engineer.” Dogfooding sharpens your instincts faster than any meeting or roadmap discussion.
And even though everyone at Buffer does this today, if I were at a company where it wasn’t the norm, I would treat dogfooding as a cheat code for career growth.
Because using your own product gives you something that’s impossible to fake: real, practical empathy for the user and understanding of the product. Leaders trust engineers who feel the product, not only the codebase.
Do you actively dogfood your company’s product?
If yes - what’s one thing you learned that you would’ve never spotted otherwise?
* This post was proudly written as an idea at @Buffer, then scheduled for the next available posting slot for LinkedIn, and once it's posted, I'll be replying to comments from inside the product!
People think my career grew fast because I’m smart or disciplined. The truth is simpler (even though I like to think of myself as smart and disciplined, of course).
I got very lucky, twice.
But I also created the conditions for that luck to matter. Here is what I mean.
I’ve been programming since I was 11, but the hardest step of any engineering career is getting the first job. When I look back, the way I got mine was honestly a bit ridiculous.
When I was in high school, there was an Oxford-style debate tournament. I was an extreme introvert at the time. Zero chance I would ever volunteer for something like that. But my friend had no partner and asked me to join him.
After a lot of overthinking, I finally said yes.
I was so stressed during the first debate that I barely remember it - but somehow, we won many debates and the entire tournament.
And I got hooked.
After high school I joined the organization that ran these debates. The general coordinator happened to be a programmer (greetings to you @Jakub!)
Their dev team was looking for another person, and just like that, I got my first job in software. If I hadn’t stepped out of my comfort zone that one time, none of it would have happened.
Years later, luck struck again. A recruiter messaged me on LinkedIn about an opportunity at Facebook. I assumed I had zero chance, but I interviewed anyway, out of curiosity. And somehow, I got in.
That move accelerated my career more than anything else.
And here’s the thing:
Yes, I needed the skills to pass the interviews.
But the opportunities themselves were pure luck, I only caught them because I was already prepared.
So here are the two biggest lessons I learned:
#1 You need to create opportunities for luck to show up. Say yes to things, put yourself out there, talk to people, take small risks.
A lot of “lucky breaks” start with a simple decision you almost didn’t take.
#2 Once luck appears, you need the skills to use it. Luck opens the door, but skills are what allow you to walk through it. Both matter. One without the other doesn’t get you very far.
Remember this: You only need a few lucky moments to be successful.
But you need to be ready when they happen.
What was the luckiest break in your career?
📈 The highest-ROI reading habit I have as a software engineer? These 3 newsletters.
1. @The Pragmatic Engineer by @Gergely Orosz
Probably the most influential newsletter in tech today - and for good reason. Gergely gives you an inside look at what real engineering truly looks like in big-tech and high-growth startups.
Expect:
- deep dives into engineering practices, system design, incident postmortems and companies internals
- analysis of market and hiring trends, including insights from Big Tech and startups
- a lot of expert guest posts on all kinds of engineering topics
Every issue is a mini masterclass. Combine a year’s worth of them and you’ve got a portable library worth hundreds of pages.
2. @Scarlet Ink by Dave Anderson - Big Tech Careers & Leadership by @David Anderson
Engineering isn’t just about code - it’s also about people, leadership, communication, and long-term thinking. Dave covers exactly that.
Here you get:
- honest essays on leadership, team dynamics, and scaling organizations
- advice on communication, influence, and working effectively in large teams
- a perspective that helps individual contributors understand what lies behind the code - the decisions, people, tradeoffs, and culture
After reading Scarlet Ink I always walk away with new ideas to think bigger and improve how I work and grow. It’s one of the most eye-opening career newsletters I’ve ever read.
3. @Level Up Leadership by @Ethan Evans and @Jason P. Yoong
If you care about long-term trajectory, promotions, and how leadership views your work, this is the one. Ethan is a former Amazon VP who walked the path many of us aim for, and Jason is a former Amazon Head of Program for Amazon Marketplace.
What Level Up gives you:
- deeper visibility into how senior roles, promotions, and executive-level thinking works inside big organizations
- frameworks for showing impact, owning your career path, and avoiding “just doing tasks” syndrome
- a mindset shift from being a coder to being a strategist - someone who looks at systems, people, and business outcomes.
If you want to grow not just as a coder, but as an influential engineer or potential leader, this belongs on your reading list.
Your turn - which newsletters shaped your thinking the most?
Always looking for new recommendations to add to my list.
Recently my friend @Dave Chapman asked a bunch of us at @Buffer about our favorite backpacks for an article he was writing. That is when I made a terrible discovery. I think I have a backpack problem.
And my wife is absolutely not proud of me.
I kept thinking I owned maybe three, the ones I mostly used.
Turns out I might have enough to evacuate a small village.
There is:
🎒 the digital nomad backpack
🎒 the hiking backpack
🎒 the "I will work from cafes" backpack
🎒 the weekend travel backpack
🎒 the diving backpack
🎒 the backup backpack
🎒 the backup for the backup backpack
🎒 and the one I forgot I had until I found it buried in the wardrobe
If anyone else suffers from Gear Acquisition Syndrome, especially in the backpack category, please let me know so I can tell my wife I am not alone. 🫠
Jokes aside, what's your favorite backpack and why?
3 things that fast-tracked my career as a software engineer (speaking as the youngest senior+ engineer in the company) 🧑💻
#1: I've never stopped learning
Programming doesn't have to be your passion to make money out of it, but the truth is, the more you enjoy it, the more beneficial it becomes for you. If that's the case, then you naturally spend more time after-hours to read software-related articles and books, poke in the code, and experiment. In my case, as a 29-year old, I've been doing that for the past 18 years, so it was enough time to gather so many experiences that I can reap the fruit of my work now.
#2: Being a good, open person
Really. If you've got problems interacting with other people, it's time to start working on that. I know how hard it is as an introvert myself, with experiences of panicking when there are too many people I don't know around me. But if you try and learn to overcome it, and you're a good, positive person who wants best for everyone around them, it also helps you in your career. In Software Engineering, everything is usually based on teamwork - if you can collaborate with others, it's way easier to work with you. And it's often more important and fruitful for your career than being the smartest person in the room.
#3: Go out of your way, especially when nobody else wants to
My biggest successes were the projects that nobody else wanted to take on - old codebases, no documentation, a lot of nasty debugging. But if you're able to deliver, you become the only expert in that matter. This opens many doors for you and your future career.
I am still learning, still improving and still far from perfect, but these three things changed my trajectory more than anything else. What would you add to this list from your own experience?
🎉 JavaScript, happy 30th birthday! Who would have thought the future would look like it does today? I've got my own share of problems with you, but then I always remember that quote by Bjarne Stroustrup: “There are only two kinds of languages: the ones people complain about and the ones nobody uses.”
🎉 JavaScript, happy 30th birthday! Who would have thought the future would look like it does today? I've got my own share of problems with you, but then I always remember that quote by Bjarne Stroustrup: “There are only two kinds of languages: the ones people complain about and the ones nobody uses.”
Today, I finally solved a bug that haunted me for 11 months. Eleven months of chasing a ghost in the machine - it's hard to describe what I feel now.
To explain why this mattered so much to me, you need to know one thing:
At @Buffer, broadcasting - sending customers’ posts to social networks reliably and on time - is my domain.
It’s the heart of our business, and it’s the part of the system I breathe every day.
We send millions of posts weekly: photos, videos, links, stories, carousels - across every major platform.
Most go flawlessly.
Some fail because social networks act unpredictably.
But there was one category of error that always hit me personally.
A scheduled post should always end up either:
✅ sent
or
❌ errored
But a tiny percentage - historically around 0.2% - ended up in a third state:
🟧 “nothing.”
Not sent. Not errored. Just... stuck.
And unlike API failures or network quirks, these weren’t anyone else’s fault.
These were on us.
They’d been happening for years. Engineers before me tried to solve them. We’d dig, solve some of the root causes, get stuck, and give up.
To me, this became a kind of holy grail.
It felt personal. Broadcasting is my domain, so this bug felt like a challenge directed at me.
Early this year, we finally rewrote all of our post broadcasters from scratch - a massive, multi-year reliability project.
Deep down, I believed it would finally eliminate these stuck posts. It didn't.
And I blamed myself for months.
I was so desperate that I began even questioning things like whether our database really provides atomicity and reliability it claims it does.
That’s how deep down the rabbit hole I went.
I stared at logs at night. I impersonated users. I reverse-engineered edge cases nobody knew existed. I dove into legacy systems far outside my domain, areas I had never touched.
There were weeks when I gave up entirely. But every time, something pulled me back.
Because reliability in broadcasting isn’t just a metric to me - it’s who I am at Buffer. Whenever something goes wrong there, I’m the one people come to. So the longer this bug lived, the more determined I became to get rid of it.
Last week, something finally clicked:
What if it's not my domain, but something outside of it, that only on the surface has nothing to do with it? And then I detected all the issues, each rare, hiding in different parts of the system. They lived in scheduling, queue management, and old flows nobody had touched for years.
Together they created the pattern I'd been chasing for months. Once I expanded my horizon, it all finally made sense.
🟢 Today, the graph finally hit zero
For the first time since I joined Buffer, we had:
0 stuck posts, zero failures that are impossible to reason about.
And honestly?
I can’t remember the last time I felt this proud as an engineer.
🔍 What was your longest bugfight?
I’d love to hear your stories - the ones nobody sees, but that define who you are as an engineer.
My first months of freelancing after hours earned me more than my full-time job 💸 🔥
Here is how I got there.
1. Become an expert first
Freelancing only pays well when clients choose you for your expertise, not because you are the cheapest option. If you start too early, you end up competing by lowering your price, and that is a race you do not want to win. The number of people you compete against is also way higher.
A good rule of thumb is this. If it still feels like you are mostly learning while doing the work, you are not ready yet. If it feels easy for you but valuable for the client, that is when freelancing becomes profitable.
Another helpful indicator is when you can estimate work accurately and deliver without surprises. Clients pay for predictability. If you already know the common pitfalls, the edge cases and the hidden complexity in your area of expertise, you are in a completely different league from someone who is figuring things out on the fly.
2. Solve the cold-start problem with premium platforms
In the beginning you have no network, no referrals, no testimonials and nobody knows your work yet. That is the hardest moment in freelancing, and it is why many people give up.
Platforms like @Codeable or @Toptal completely change that equation. They already attract clients who are willing to pay premium rates, and they pre-filter for quality. You still get paid well, but you do not have to compete in a race to the bottom - and the cut these platforms take is well worth it. For me, Codeable was the key that gave me a steady stream of projects right from the start.
3. Treat clients like long-term relationships
A huge percentage of my projects came from past clients returning or recommending me. Being friendly, reliable and proactive matters much more than people think. Clients prefer someone who communicates clearly, delivers on time and is pleasant to work with. Do that consistently and you never worry about where the next project will come from.
* As for the hook that I used - I started freelancing many years ago, when I was still working as a contractor for Meta, and earning about $4,000/mo. My best freelancing months brought me over $10,000. I don't actively freelance anymore - I've got a full-time job at Buffer, where I make well over that amount, working 4 days a week, and I value my free time now more than extra money.
Also, kudos for my friend @Martín García who taught me recently that a word freelancing comes literally from "free lance" - medieval mercenary! Quite obvious when you think about it, but I had no idea!
Happy to answer questions, share mistakes and prevent forehead-shaped dents in your desk if you're interested!
PS: I wrote a guide in the past on how to make money in WordPress: https://lnkd.in/gegC-M6
Do you need an expensive home studio to be a successful software engineer?
Short answer: absolutely not.
Long answer: When I’m home, I definitely act like I do 😄
I’ve got the whole setup: Elgato microphone, webcam, lights, Apple Studio Display, an ergonomic desk, all the toys. And honestly? I love it.
But here’s the fun part:
For 6 months of the year I work fully remotely while traveling the world - using nothing but a 13-inch laptop, a tiny keyboard, a mouse, and AirPods.
All of it fits into a 10L backpack.
I’ve tried travel monitors, but carrying them around cities, airports, cafes and coworking spaces? Total hassle. I always ended up ditching them.
And the thing is, whether I'm at home or in travel, my productivity doesn't really change. Otherwise, I'd probably get fired long time ago instead of getting promoted regularly and always aiming for the overachiever badge.
Turns out it’s not the gear - it’s the habits, focus and environment you build for yourself.
For anyone living a digital nomad life or planning long-term travel:
👉 What’s the minimum setup you’d be comfortable working with for a few months?
Curious to hear how light (or how heavy) you pack 🎒
If I had to restart my career in software engineering tomorrow, these are the books I’d bring with me to reach the top.
They shaped how I think, design systems, debug problems, and grow in this industry.
📖 1. The Software Engineer's Guidebook by @Gergely Orosz
The best engineering career book I’ve ever read, period.
Gergely (known for @The Pragmatic Engineer newsletter) distills the lessons, patterns, and realities of growing in engineering - from junior to staff+.
I genuinely wish this existed when I started.
📖 2. Designing Data-Intensive Applications by @Martin Kleppmann
This book is a paradigm shift for anyone building software that handles real-world data. Kleppmann goes beyond database basics, breaking down how modern systems handle consistency, scaling, events, and failure - all with clear examples. It equips you with the mental models for architecting reliable backend systems and clarifies concepts you'll face in interviews and on actual projects.
📖 3. Unix and Linux: System Administration Handbook by Evi Nemeth, Garth Snyder, @Trent Hein, @Ben Whaley, @Dan Mackin
Every engineer benefits from knowing what’s happening beneath their framework or cloud provider. This is much more than a shell scripting guide - it's the toolkit for navigating, understanding, and mastering the core of Unix and Linux systems. It demystifies the operating system layer itself, from boot processes, permissions, and filesystems to user management, networking, security, troubleshooting, cloud deployments, and automation. This book delivers the practical know-how and big-picture understanding that lets you move confidently beneath the surface.
📖 4. Computer Networks: A Systems Approach by @Larry Peterson and @Bruce Davie
Networking can seem opaque until you read this book - it’s where abstract protocols finally make sense as moving parts in real systems. Whether you’re building APIs or debugging something in the cloud, the lessons here repeatedly pay off and open up new perspectives on distributed design.
This book is not easy - but once you finish it, you’ll finally understand what happens when you're making network requests.
And if you want to go further, here are a few bonus titles I really value:
📖 1. The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change by @Tanya Reilly
📖 2. System Design Interview: An Insider's Guide by @Alex Xu
📖 3. Software Engineering at Google: Lessons Learned from Programming Over Time by @Titus Winters, @Thomas Manshreck and @Hyrum Wright
📖 4. Crafting Interpreters by @Robert Nystrom
📖 5. Algorithms by Robert Sedgewick
Together, these books build a deep, transferable, long-term foundation - the kind that matters across teams, tech stacks, and job titles.
What would you add to the list? Which book shaped your engineering mindset the most?
I decided to start posting more regularly here, so a short introduction feels like a good place to begin. Hi! I’m Arek.
I’ve been coding for about 18 years, which officially makes me an adult programmer. Ten of those years were commercial experience, the other eight were me breaking my parents’ computers and pretending it was "for learning purposes."
Right now I work at Buffer - fully remote, fully distributed, and running on a four day workweek, which is basically a cheat code for life. Thanks to that I travel quite a bit as a digital nomad, although Warsaw is still my home base (and the place where I keep the cables I don’t need but refuse to throw away).
Before Buffer I worked at Facebook (Meta, technically, but it's hard to make a switch) and Lufthansa. I also freelanced for a few years with international clients, which means I’ve experienced every timezone mismatch possible.
If you ever want my take on things like:
🧑💻 building an IT career
🧑💻 working remotely or surviving a four day workweek
🧑💻 digital nomad life
🧑💻 freelancing without losing your sanity
🧑💻 or anything about engineering in general
Just drop a comment.
I love sharing my experiences!
Proud to have friends working on such cool startups, and cannot wait when I get to replace all my longevity/health apps with this single one. Rooting for you!
So you probably have heard about a term "golden handcuffs". Usually I heard it when someone talked about their ridiculous salary, when they'd like to change the job, but it doesn't really make economical sense, even if they're giving up something else, like flexibility, peace, whatever.
What if I told you there's a company that pays well, you work 4 days a week on interesting projects, your colleagues are your true friends (and you probably haven't met so many lovely people at one place), there's no office - would you sign up for my kind of "golden handcuffs"?
If your answer is yes, we've got a lot of openings at Buffer!
🌍 Engineering Manager 💰 $173.7K – $202.3K
🌍 3 Senior Software Engineer positions 💰 $156.5K – $202.3K
🌍 Senior Hiring Specialist 💰 $118.1K – $146.5K
The interview takes time, and it's in some ways different than typical, but it's totally worth it - I know what I'm talking about, over 4 years in and still rejecting all the other offers I receive!
Going diving tomorrow after a few months break and I cannot wait. It's unbelievable how it's the only activity that makes my brain focus only on "now" and literally nothing else, no other thoughts come to mind until I surface.
💡 I recently discovered the biggest growth hack for LinkedIn followers, and thanks to that, my following has grown like crazy in the past weeks.
And the secret is 🥁 🥁 🥁
Work in a company that everyone dreams about (@Buffer), do almost nothing on LinkedIn and wait till there are new positions open and I promise you, your charts and DMs will go crazy 😅
I learned recently an interesting thing about Mongoose and how it handles incompatible types. Imagine a situation: you've got your field defined as an array type in your schema, and one of the documents described by this schema has an empty string as a value. Let's put aside why the empty string got in there, and ask a question: when you pull this document, what is its value now?
And the answer is: it's an array containing one empty string as its element, like [""]. It happens because Mongoose does implicit conversion under the hood for values that are not arrays, but are defined as such!
I learned it when I was banging my head on the bug where empty string I saw in the database was somehow getting into the branch of my code restricted by Array.isArray() check.
It's always worth it to know your tools' internals!
Sometimes my mentees ask me how I see the difference between Software Engineers (L4), Senior Engineers (L5), and Staff Engineers (L6). While this can vary between companies, there is a clear way to visualize these roles that came to my mind when answering that question: it comes down to how they interact with three key questions - "How," "What," and "Why."
Here's how I see this at Buffer:
Software Engineers (L4): Primarily focused on the "How." They clearly understand "What" needs to be done and "Why" it’s important, allowing them to dive into figuring out the technical specifics of implementation.
Senior Engineers (L5): They comfortably handle the "How," but also frequently step into defining or clarifying "What" we're building. Occasionally, they'll delve into the "Why," ensuring alignment with larger goals, though usually within the scope of their immediate projects or teams.
Staff Engineers (L6): Operate primarily at the intersection of "What" and "Why." They define and clarify the broader vision ("What") and purpose ("Why"), ensuring the work aligns strategically across multiple teams (or the whole organization when it comes to smaller companies like Buffer). They still engage with "How," but typically through mentoring others rather than direct implementation.
Have you noticed similar transitions in mindset as you've advanced through engineering levels?
Sometimes my mentees ask me how I see the difference between Software Engineers (L4), Senior Engineers (L5), and Staff Engineers (L6). While this can vary between companies, there is a clear way to visualize these roles that came to my mind when answering that question: it comes down to how they interact with three key questions - "How," "What," and "Why."
Here's how I see this at @Buffer:
Software Engineers (L4): Primarily focused on the "How." They clearly understand "What" needs to be done and "Why" it’s important, allowing them to dive into figuring out the technical specifics of implementation.
Senior Engineers (L5): They comfortably handle the "How," but also frequently step into defining or clarifying "What" we're building. Occasionally, they'll delve into the "Why," ensuring alignment with larger goals, though usually within the scope of their immediate projects or teams.
Staff Engineers (L6): Operate primarily at the intersection of "What" and "Why." They define and clarify the broader vision ("What") and purpose ("Why"), ensuring the work aligns strategically across multiple teams (or the whole organization when it comes to smaller companies like Buffer). They still engage with "How," but typically through mentoring others rather than direct implementation.
Have you noticed similar transitions in mindset as you've advanced through engineering levels?
Let me share my most precious travel hack for European cheap airlines like Ryanair or Wizzair. As a tall person (1.94m/6'4'') I always crave extra legroom seats, and I get them on most of my flights, for free.
The secret is to buy flights without seats assigned, and wait till the very last moment for your check-in (usually check-in closes 2 hours before the flight, but be sure to check it!)
Most people fly these airlines without pre-paid seats, and the airline always assigns the normal seats first, then front seats, and extra legroom seats are assigned as the last ones. If you check-in late, it's almost given that you'll end up with extra legroom seat!
PS: Please don't use it against me 😜
📣 @Buffer is hiring — three senior engineer openings simultaneously is probably the biggest recruitment event at Buffer for a few years (it's nice working here, so people usually don't leave!), so that's a great chance for anyone thinking about it! Also, there are open positions in MY TEAM! ❤️
🌏 Fully remote, global team (which is truly remote - for half a year every year I'm out of my base location)
📆 4-day workweek (and I really don't work Fridays)
💰 $156.5K - $202.3K + equity
See more details and apply on https://buffer.com/journey
@threads team recently announced it's finally possible to add tags to your post via API, and this is me testing it. It's one thing I was missing the most from the Threads API especially for tags with spaces in them, so expect it soon in @Buffer!
I love inbox 0, but I also love my newsletters, which I don't always have the time to read right when I receive them. What's your way to keep them somewhere afloat and not forget about reading them, while still clearing out your email inbox?
productivity
One of the most important aspects of a workplace for me is flexibility - I travel a lot, sometimes have to run some errands during the day, and sometimes I just feel the urge to resolve some challenging problem during the weekend. It's important though to be transparent about it with your teammates, so you're not creating a vision that in order to be successful you've got to work overtime or during the weekend, and what it really is - it's just your approach to flexibility. 1/2
TS devs, what's your preferred way to work around the lack of async constructors in classes?
typescript
Bloggers, what's your CMS of choice nowadays? I was running self-hosted WordPress for many years now, but I'm a bit tired of managing the server and customizing everything - not that I can't, I just don't have time for it. I want something that just works and doesn't require me to customize a lot of stuff. Can be self-hosted, and I can also pay for it - I just want to own the data, have my domain, and be able to gather emails from readers. Does it mean Ghost?
software