Socials

A few days ago I posted tips about applying to fully-remote jobs for async-heavy and distributed companies with lengthy application forms and how the writing skills are evaluated as an important factor. The post got a little more controversial than I anticipated, and I'm not able to fit into characters limit while editing it there, so I decided to address it in this article. I'm expanding on these common themes: - “ATS/AI Filtering - nobody even looked at my application” - “Length ≠ Writing Skill” - “The UI (short textareas) doesn't set expecations” - “Why do I need to spend so much time on it if I get ghosted anyway” - “Why don't you ask all those questions later on the actual interview?” - “If candidates write essays, employers should respond with equal thoughtfulness.” - “I don't know the product deeply yet to answer all these questions in depth” It's my take on why different hiring processes signal different cultures of the companies. Lengthy forms are not a fit for everyone - and that’s okay. Hiring is a two-way filter.

One of the biggest mistakes people make when applying to fully-remote jobs for async-heavy and distributed companies, is not spending enough time to answer all the questions in depth. If the company is fully remote, it means it relies on writing a lot. All of these questions, besides their literal meaning, assess how good you are at writing. If you submit your answers in the form of 3-4 sentences for each because you're short on time, you can as well just skip submitting the application at all - you'll save even more time! It doesn't matter how strong your CV is - if you fail at writing, you'll be rejected no matter what because it's so important at remote teams. So if you plan to apply to e.g. @Buffer (we've got a few openings now!), please take your time, it's your free advice! Edit: As you can see, there are a lot of comments with different takes on it. I address all of them here in the article (I was unable to fit into the character limit on this post unfortunately): https://lnkd.in/eujCswQQ

We’re hiring a Senior Community Manager at Buffer! 🥳 Fully remote (I'm posting it from Chiang Mai 🇹🇭), 🗓 4-day work week, 💰 $116K–$144K + equity. This role will help shape how Buffer shows up for creators and small businesses, from leading conversations in Discord and Reddit to designing thoughtful community programs and partnerships. If you enjoy bringing people together, facilitating meaningful conversations, and building community systems that scale without losing the human touch, this role is for you! 🔗 Link in comments!

It's the first time in my career when I feel uncertainty about the future. Not necessarily about being replaced by AI - I'm not afraid of that. But through the next years the industry will change a lot, we just don't know yet how exactly, and we'll need to adjust in new roles. So that's the uncertainty - what exactly will I be doing in a few years? It's especially interesting perspective for software engineers - in this field the growth mindset and constant learning were the backbone of your success. And in this phase of the change, right now, we've all got to maximize our learning time and effectiveness to adjust dynamically to how the industry changes, only then we'll be able to stay within. When I think about what AI is good at, and what it's missing, I see 3 clear paths for myself. #1 The first one is leaning more and more towards product. I am what people call a product engineer, and I think you've got to lean even more into product with all the change coming. The interesting thought here is - what does it mean for product managers? Will they be leaning more and more towards engineering now that it's easier? Will we eventually see those two roles merging? #2 The second one is working on AI itself. It's a green-field area, and LLMs aren't good im greenfield projects, so you still need that human touch and creativity for it. At the same time what I think gives you edge in AI development are hardcore mathematics and research skills, something I'm definitely missing, amd I'm not sure I want to catch up. #3 And the third one is SRE - when the stakes are high and you need 100% certainty your critical systems won't break, you'll still need a human review (possibly with a lot of AI help, but still it's human making the ultimate decision). That's another field I'd see myself in, especially given I've got past experience with high-stakes operation, current engineering skills and an interest in infrastructure things. Still, the product engineering is where there's the most alignment for me right now, and at the same time it's prone to the biggest changes because of AI out of these three mentioned, and possibly the most "endangered". Interesting times! I'm curious how do you see your future, do you believe our industry is fundamentally changing? What are you doing to prepare yourself for it and be on the forefront?

Politics at the workplace - there aren't that many phrases heating up the room full of engineers like this one. And yes - you should get good at it. What I noticed - people who deny the need to influence others at the workplace will call it "politics" - it's got a negative sound to it. But you need to remember - being better than your colleagues is not what leads to your promotion. We are humans - your manager is human, other managers and directors at the calibration meeting are humans, and the processes defining if you get the promotion or not are run by humans. They should try to remove emotional attachment to you to keep the process fair, sure - but it isn't really binary and it's not possible to remove it fully. Be a great coworker, learn how to communicate well, and create rapport with people who influence your carrer progress (or its lack). If you call it politics - fine, but complaining about it won't help you progress.

🔑 My little secret (though I'm sharing it now, so I guess not so secret anymore!) is that I screenshot all gratitude towards me in my workplace. It helps that we're fully remote and distributed globally, so a lot of it happens in Slack / Zoom & similar. Why do I do it? First thing is that I've got all praise handy when I need it for my performance reviews. It also helps when you're no longer working there and can reflect on how people perceived you. But even more important - when I feel down at work and lack energy, I can take a look at it to remind myself what I'm working for! Have you ever done something similar?

Fully remote, $157-$194K + equity, 4 day work-weeks - sounds like something for you? We're hiring for Senior Developer Advocate at @Buffer 🚀 If working on the edge of engineering, education and customer support is your thing, I couldn't imagine a better place to be than exactly here (or wherever you are, cause Bufferoos are everywhere)! A little context: We're building our Public API for the past few months and we're entering a critical phase right now, where we'll be releasing it to more and more of our customers. It's one of the most exciting projects I've been working on here, so this position is super close to my heart. If you're thinking about applying, I cannot wait for you to do so! ❤️

I love being an experienced software engineer in the AI era. Every idea I killed in the past because I didn't consider it good enough, I've got now tools to implement it in a few hours! The AI agents got so good over the past months that shipping MVP is dead simple if you know what you're doing. In the past weeks: - I've hit Claude limits for the first time - Created MVP for the app I always wanted to do: smart PR review notifications for GitHub (coming soon!) - Created my first app on iOS (and I don't know Swift or mobile development at all) - Started working on another app I've been thinking about for the past year The future is now, and I couldn't be more excited!

Reflecting on the current state of software engineering, I believe we're about to adopt 'writing' as a requirement, just like it happened with automated testing years ago. With tests - everyone followed when it appeared that companies doing automated testing have less outages and more reliable software. With writing - everyone will start mandating a proper writing and documentation when they see that companies doing that are ahead of them thanks to LLMs usage and feeding them internal documents. As a big fan of writing - I cannot be happier about that possible outcome! What's your take on it?

Amazed by how productive AI makes me in my coding workflows, I thought it'll make my email research way faster, but Gemini in Gmail is a tragedy. I've got 5 flights with 4 different airlines coming in the next 3 months that I booked weeks ago, so I don't remember the baggage allowance anymore. Thought it's a nice task for Gemini but it: - first wasn't able to find 3 out of 5 flights at all - when pointed to exact dates, still wasn't able to find the last one - finally found it - when corrected about baggage allowance in one of them, completely forgot about the 4 other ones - when corrected about that, distilled me a baggage allowance from completely different bookings I had What a tragedy 😅 any better tools for email research? Maybe @Superhuman would do better?

🌏 After 8+ years of working remotely as a software engineer, here are the programming languages I’d learn if I had to start again. Yes - you can find remote work in almost any stack. But if you want to maximize your chances, some technologies open far more doors than others, especially in fully remote and distributed companies. Here are the 3 most high-leverage ones, in my opinion: 1. JavaScript / TypeScript & Node.js The undisputed #1. JavaScript is needed everywhere on the frontend, and more and more companies use Node.js on the backend. One language across the full stack = massive hiring demand. It's also what I work with today, and the number of remote opportunities is honestly overwhelming. 2. Python If you ignore frontend side, Python is the clear leader in remote job listings with endless possibilities: backend development, automation, data engineering / data science, AI/ML, LLM-based applications. Every hype cycle of the last decade has had Python at its core. If you want versatility + remote-friendliness, this is it. 3. PHP People love to joke about PHP - meanwhile, it powers a huge part of the web and is still used heavily in new products (especially with Laravel). And then there’s the real secret: WordPress is a massive remote-friendly and freelance-friendly ecosystem. You can laugh at it, or you can make serious money with it. I did the latter. There were months when I made $10,000+ on the side after hours doing WordPress work - so there's definitely some money to earn here! A popular tech stack means: - More openings - More remote companies - More freelance gigs - More long-term security Yes, more competition too - but I’d still choose having more doors to knock on, and then focus on becoming one of the best. Do you agree? Would you add some other technology to the list? Let me know if you've got any questions about remote work or freelancing!

If you live outside of US and are a remote worker - you're probably as big enemy of location-dependent salary as I am. Working in tech as staff+ engineer in big tech and high-growth startups, your peers in NYC or SF are clearing at least twice as much as you are, for doing essentially the same work (assuming you're contributing on the same level). Company policy explains it's because of the cost of living (most often) and high competition for the most talented engineers (often). Recently, I've ended up browsing through @Oxide Computer Company blog, intrigued by their culture and approach to transparency and fairness. See what their co-founder @Bryan Cantrill wrote about location-independent salaries: "Some will say that we should be paying people differently based on different geographical locations. I know there are thoughtful people who pay folks differently based on their zip code, but (respectfully), we disagree with this approach. Companies spin this by explaining they are merely paying people based on their cost of living, but this is absurd: do we increase someone’s salary when their spouse loses their job or when their kid goes to college? Do we slash it when they inherit money from their deceased parent or move in with someone? The answer to all of these is no, of course not: we pay people based on their work, not their costs. The truth is that companies pay people less in other geographies for a simple reason: because they can. We at Oxide just don’t agree with this; we pay people the same regardless of where they pick up their mail." It's been quite some time since I've read something so powerful culturally, and I couldn't agree more. At @Buffer, we still have got some remains of location-dependent salary, but we're on a good path to eliminate it completely in the future, and that's something our leadership has got in mind, and I'm super grateful for it. Do you know any other global companies that pay independently from the location? 🌍

I rarely read books focused on a specific technology, because they get outdated pretty fast and it's just better to learn what you want online from docs. But if you're working with @Node.js - I have to recommend "JavaScript in Depth" by @James Snell. It gets into why JS works like it does (remember all the memes about 0.1 + 0.2 !== 0.3?), and makes you understand "why" behind all things JS - and that won't get outdated! A few questions to check if the book would be useful to you: - do you know how V8 optimizes string manipulation? - do you know integer numbers in certain range are stored differently for performance reasons? - do you know how types are coerced? - are you aware that stream processing can throw errors that skip try/catch blocks completely? The book is still in the works, but you can already access it at @Manning Publications Co. and learn more about runtimes, strings, numbers and objects. I personally cannot wait for chapters about the errors, garbage collection, event loop, streams and thread workers!

One of the reasons AWS and Azure dominate the cloud market over Google: internal dogfooding pressure 🐶 I’ve been writing recently about dogfooding as a personal career superpower, but there’s also a business side to it. If you look at the cloud market, AWS and Azure dominate. There are many reasons for that, but one pattern stands out to me: how heavily these companies relied on their own products internally, mandating AWS and Azure usage for all new products and making conscious effort to migrate existing ones. That kind of usage forces uncomfortable questions early, and makes the product way better. Google's infrastructure history is different. For a long time, internal teams ran on highly customized internal platforms, and public GCP evolved more as a product for external customers. That doesn’t mean Google didn’t dogfood at all, but the feedback loops were different. And you can often feel that difference in day-to-day developer experience. This isn’t the only reason cloud market share looks the way it does. Sales motion, pricing, ecosystems, and timing matter a lot too. But dogfooding is a big contributor. Whether you’re building cloud platforms or internal tools, the lesson is the same: 🐶 If you want your product to get better, make it impossible not to use it. Happy to hear counterpoints from folks with different experiences!

Wondering how you can increase your chances of getting interviewed and accepted at Buffer, or any other company with a great culture and benefits, where hiring managers get thousands of applications? Let me share some lesser-known advice with you based on my own experience (and what I would do today). Let's skip the obvious - you've got to have required experience. If we're looking for a senior engineer, you've got to have a resume that proves it. Buffer is famous thanks to great culture, transparent salaries, awesome benefits like 4-day workweeks, and the fact it's been doing these things for over a decade. Now, how do you make yourself different from every other candidate, if we get so many qualified resumes? You prove that you are a match for us! You can notice that every Bufferoo posts on social media. For me it's LinkedIn and TikTok. Many of us have got followings that go in thousands of people. When you look at the application, there is a question about your experience with Social Media - and it's not there as a filler. It's genuinely important question, so if you start posting you're making a big difference here! No need to be a big influencer, just use social media to share your thoughts on whatever works for you. Buffer is built for creators, by creators, so it is a 100% must! As a side note: personal brand will help you when interviewing at any company like that, period. So even if it's not Buffer, it'll be beneficial for you to start creating. Culture is our most precious asset at Buffer, so we're protecting it a lot. You need to align with our culture to have a chance - that means you need to understand what it means to be a Bufferoo. Luckily for you we're very transparent about it, so just follow what we share on our Open Blog. Companies with similar culture often have got their open blogs, so just go and read them before applying. I've literally read every post before applying to Buffer! We're working fully remotely for years, and a lot of our communication is asynchronous, so writing matters a lot as a skill. Application is a first step to filter out people who do not communicate well. If you put 2-3 short sentences into each answer, you cannot expect we'll consider you a great communicator. Work on your writing skills! That also ties nicely to my first point about being a creator. All of those above will greatly improve your chances at Buffer, as well as any company with a similar culture. Including social media presence - I don't know about any company similar to Buffer where it wouldn't be welcome! At Buffer, we've got a lot of people who succeeded on their 2nd or even 3rd try. They still say it was worth it. I'm here for nearly 5 years, and over 50% of Bufferoos are here longer than I am - I think it speaks for itself if the effort is worth it. So if you want to get accepted at Buffer but failed any of the previous interviews - you know what to work on for the next position openings!

Last year I've read "Deep work" by Cal Newton - great book, though quite radical with the proposed approaches! One thing I've tried was setting an app blocker to not open random stuff like Instagram while I've got my focus time. Even bought a premium subscription for it. But after a week I've thrown it out - it was annoying me like nothing else, and I've realized I don't doom scroll too much anyway, so I'm not the target. Or at least that's how I explained it to myself. Anyway - have you ever used app blockers? Did they work for you? If yes, what was your secret to it? If not, what made you stop using them?

Some reflection on my creator journey after ~30 days of taking it seriously. I chose LinkedIn and TikTok as main platforms I post to, because I understand them better than others. My content is around career and growth in software engineering (but no hardcore technical stuff), remote work, culture and digital nomading. 📈 On LinkedIn, I aimed for ambitious goal to reach 1800 followers (started with ~1300), and I managed to exceed it and ended up with over 1900, 40% growth over 30 days! I got decent engagement on most posts, and what I noticed works (or not) for me: 👉 AI: initially I was writing my posts and enhancing my writing style with AI, but I don't like it. So I don't ask for suggestions to rewrite my posts, because it makes them lose my style completely, and all of them look the same. After a month spent actively on LI, I see it after a few sentences which post was written by AI, they all have the same structure. So I decided my posts won't be ideal, I'll sometimes have bad grammar as a non-native, but at least I'll be authentic. I still use AI to research topics though, but nothing content-related. 👉 I always try to end my posts with some questions, and it works - I get many comments where people share about their experiences regarding the topic I posted about 👉 I try to attach something to the post - so far mostly images, but I also want to try my luck with carousels and videos - I get better engagement when they're present. My post about books I recommend for software engineers had a simple photo I took quickly with me holding 2 books and it exploded. 👉 Thanks to engagement/comments I get, I have a lot of other ideas for future posts 👉 I often mention others and it worked for me great - I got engagement from some of my idols under few of my posts - they all have pretty big followings and I'm pretty sure some engagement on my posts came from them engaging and showing up on other people's feeds (who follow them). 👉 Fun fact for above: when engaging with my idols, I learned that some of them are happy Buffer users!! 👉 I noticed LI often surfaces old posts when you follow new people. so consistency seems to be important here. I get likes/comments on my older posts every day, so the consistency works for me 👉 I read a lot of newsletters, hackernews, reddit, and so on, and whenever I notice something interesting I save it as an idea in Buffer to comment on it later. I think it's the most important mindset shift that brought me good results - instead of "okay, I post because we should all dogfood now" I changed to "I'm the real creator now and want to have my personal brand and audience!" I won't fit into char limit here, but in my next post I'll share more about my TikTok journey cause it's a bit different than LinkedIn, and my reflections on creator goals in general, let me know if you'd like to hear my take on it! ❓ If you're a LinkedIn creator, why do you do it? Maybe your goal could inspire me?

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! 🎄❤️

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