iDiallo 2 days ago

Stop Trying to Promote My Best Engineers

There has always been a disconnect between the hiring process and finding the best engineers. But when we somehow find them, the career ladder ensures that they don't remain in that position of strength. An incompetent company might create the conditions for engineers to leave for better jobs. A generous company will apply the Peter Principle and promote engineers to their level of incompetence. Either way, the best engineers never remain in that position of strength. How do you recognize a great engineer? Is it someone who aces all the leetcode during the interview process? Is it someone who is a great communicator? Or is it someone who went to an elite university? The processes we currently have in place can only determine so much. Candidates have limited time to audition for the role they're applying for. Over the span of a few interviews, they're supposed to convey the experience from all their past work, show that they know how to do the job, and also talk about their greatest weakness. It's a performance that some people know how to game. AI-powered hiring tools haven't changed this problem. They don't magically give you better candidates . You're still sifting through the same pool, just with fancier filters. The disconnect between interview performance and actual job performance remains. A few years back, I interviewed someone I'll call the greatest communicator I've ever seen. It was for a web engineer position on another team. He seemed to understand the front end, the backend, and the jargon of the job. But what impressed me most was how he broke down each problem I posed into small parts and thoroughly resolved each one. It was as if he was creating Jira tickets in real time and writing documentation along the way before the task was even completed. I gave the thumbs up and he was hired. A couple of months later, I remembered him. I searched for his name in the directory and learned that he was let go. "Why?" I asked around. The answer was "he was pretty bad, couldn't complete a single task." Yet he was able to pass the job interview. The inverse also happens. You take a chance on someone who seemed merely adequate during interviews, and somehow they turn into one of your best engineers. I've often found myself in teams where I have zero doubts about the ability of my teammates. But then, as the end of the year approaches, the inevitable discussion turns to promotion. It's actually much easier to identify a great engineer on the job than in an interview. You see their work, their growth, their impact. And when you finally have that clarity, when you know without a doubt that this person excels at what they do, the system insists you move them away from it. When you are good at your job, the logical step for a manager is to reward you with a promotion, moving you away from the job you are actually good at. That's the Peter Principle in action. Managers believe their only tool for compensation is moving you up and down the ladder. A great developer gets promoted to senior developer, then to tech lead, then to manager. At each step, we strip away more of what made them valuable in the first place. The underlying assumption is that a great engineer will nurture a team into great engineers. But teaching and applying a skill are two distinct occupations. You may be great at one, but terrible at the other. My instinct is to help great engineers continue to grow in their expertise, not switch them to a role where they're no longer competent. It's important not to throw away all their knowledge and put them in a position of authority where they can't exercise their skill. Yet many employees themselves don't know what the next step up should be. They see "senior" or "lead" or "manager" as the only path forward, not because they want those responsibilities, but because that's the only way to get recognition and compensation. What if we stopped thinking about career advancement as climbing a ladder? What if the goal wasn't always upward, but deeper? The traditional career ladder assumes that everyone wants to eventually stop doing technical work. It assumes that the best reward for mastering a craft is to stop practicing it. But some of the best engineers I've worked with have no interest in management. They want to write code, solve hard problems, and mentor others without taking on hiring, performance reviews, and budget planning. We need to normalize horizontal growth. This means creating paths where engineers can gain expertise, take on more complex challenges, and yes, earn more money, without leaving their position of strength. It means recognizing that a senior engineer who has been writing excellent code for ten years is not "stuck" or "lacking ambition." They're mastering their craft. It also means changing how we structure compensation. If the only way to give someone a significant raise is to promote them, then we've built a system that punishes expertise. Companies should be able to pay top-tier compensation for top-tier individual contributors, not just managers. The irony is that we struggle to identify great engineers in interviews, yet when we finally find them on the job, we immediately try to change what they do. We should be asking ourselves, if this person is exceptional at their current role, why is our first instinct to move them? Maybe the answer isn't to promote them out of their position of strength, but to let them get even better at what they already do exceptionally well. After all, if interviews can't reliably identify great engineers, shouldn't we do everything possible to keep them exactly where they are when we finally find them?

Career Web Development

▲ 0

0 views

Sean Goedecke 3 days ago

How I provide technical clarity to non-technical leaders

My mission as a staff engineer is to provide technical clarity to the organization. Of course, I do other stuff too. I run projects, I ship code, I review PRs, and so on. But the most important thing I do - what I’m for - is to provide technical clarity. In an organization, technical clarity is when non-technical decision makers have a good-enough practical understanding of what changes they can make to their software systems. The people in charge of your software organization 1 have to make a lot of decisions about software. Even if they’re not setting the overall strategy, they’re still probably deciding which kinds of users get which features, which updates are most important to roll out, whether projects should be delayed or rushed, and so on. These people may have been technical once. They may even have fine technical minds now. But they’re still “non-technical” in the sense I mean, because they simply don’t have the time or the context to build an accurate mental model of the system. Instead, they rely on a vague mental model, supplemented by advice from engineers they trust. To the extent that their vague mental model is accurate and the advice they get is good - in other words, to the extent that they have technical clarity - they’ll make sensible decisions. The stakes are therefore very high. Technical clarity in an organization can be the difference between a functional engineering group and a completely dysfunctional one. The default quantity of technical clarity in an organization is very low. In other words, decision-makers at tech companies are often hopelessly confused about the technology in question . This is not a statement about their competence. Software is really complicated , and even the engineers on the relevant team spend much of their time hopelessly confused about the systems they own. In my experience, this is surprising to non-engineers. But it’s true! For large established codebases, it’s completely normal for very senior engineers to be unable to definitively answer even very basic questions about how their own system works, like “can a user of type X do operation Y”, or “if we perform operation Z, what will it look like for users of type W?” Engineers often 2 answer these questions with “I’ll have to go and check”. Suppose a VP at a tech company wants to offer an existing paid feature to a subset of free-tier users. Of course, most of the technical questions involved in this project are irrelevant to the VP. But there is a set of technical questions that they will need to know the answers to: Finding out the answer to these questions is a complex technical process. It takes a deep understanding of the entire system, and usually requires you to also carefully re-read the relevant code. You can’t simply try the change out in a developer environment or on a test account, because you’re likely to miss edge cases. Maybe it works for your test account, but it doesn’t work for users who are part of an “organization”, or who are on a trial plan, and so on. Sometimes they can only be answered by actually performing the task. I wrote about why this happens in Wicked features : as software systems grow, they build marginal-but-profitable features that interact with each other in surprising ways, until the system becomes almost - but not quite - impossible to understand. Good software design can tame this complexity, but never eliminate it. Experienced software engineers are thus always suspicious that they’re missing some interaction that will turn into a problem in production. For a VP or product leader, it’s an enormous relief to work with an engineer who can be relied on to help them navigate the complexities of the software system. In my experience, this “technical advisor” role is usually filled by staff engineers, or by senior engineers who are rapidly on the path to a staff role. Senior engineers who are good at providing technical clarity sometimes get promoted to staff without even trying, in order to make them a more useful tool for the non-technical leaders who they’re used to helping. Of course, you can be an impactful engineer without doing the work of providing technical clarity to the organization. Many engineers - even staff engineers - deliver most of their value by shipping projects, identifying tricky bugs, doing good systems design , and so on. But those engineers will rarely be as valued as the ones providing technical clarity. That’s partly because senior leadership at the company will remember who was helping them, and partly because technical clarity is just much higher-leverage than almost any single project. Non-technical leaders need to make decisions, whether they’re clear or not. They are thus highly motivated to maintain a mental list of the engineers who can help them make those decisions, and to position those engineers in the most important teams and projects. From the perspective of non-technical leaders, those engineers are an abstraction around technical complexity . In the same way that engineers use garbage-collected languages so they don’t have to care about memory management, VPs use engineers so they don’t have to care about the details of software. But what does it feel like inside the abstraction ? Internally, engineers do have to worry about all the awkward technical details, even if their non-technical leaders don’t have to. If I say “no problem, we’ll be able to roll back safely”, I’m not as confident as I appear. When I’m giving my opinion on a technical topic, I top out at 95% confidence - there’s always a 5% chance that I missed something important - and am usually lower than that. I’m always at least a little bit worried. Why am I worried if I’m 95% sure I’m right? Because I’m worrying about the things I don’t know to look for. When I’ve been spectacularly wrong in my career, it’s usually not about risks that I anticipated. Instead, it’s about the “unknown unknowns”: risks that I didn’t even contemplate, because my understanding of the overall system was missing a piece. That’s why I say that shipping a project takes your full attention . When I lead technical projects, I spend a lot of time sitting and wondering about what I haven’t thought of yet. In other words, even when I’m quite confident in my understanding of the system, I still have a background level of internal paranoia. To provide technical clarity to the organization, I have to keep that paranoia to myself. There’s a careful balance to be struck between verbalizing all my worries - more on that later - and between being so overconfident that I fail to surface risks that I ought to have mentioned. Like good engineers, good VPs understand that all abstractions are sometimes leaky . They don’t blame their engineers for the occasional technical mistake, so long as those engineers are doing their duty as a useful abstraction the rest of the time 3 . What they won’t tolerate in a technical advisor is the lack of a clear opinion at all . An engineer who answers most questions with “well, I can’t be sure, it’s really hard to say” is useless as an advisor. They may still be able to write code and deliver projects, but they will not increase the amount of technical clarity in the organization. When I’ve written about communicating confidently in the past, some readers think I’m advising engineers to act unethically. They think that careful, technically-sound engineers should communicate the exact truth, in all its detail, and that appearing more confident than you are is a con man’s trick: of course if you pretend to be certain, leadership will think you’re a better engineer than the engineer who honestly says they’re not sure. Once one engineer starts keeping their worries to themself, other engineers have to follow or be sidelined, and pretty soon all the fast-talking blowhards are in positions of influence while the honest engineers are relegated to just working on projects. In other words, when I say “no problem, we’ll be able to roll back”, even though I might have missed something, isn’t that just lying? Shouldn’t I just communicate my level of confidence accurately? For instance, could I instead say “I think we’ll be able to roll back safely, though I can’t be sure, since my understanding of the system isn’t perfect - there could be all kinds of potential bugs”? I don’t think so. Saying that engineers should strive for maximum technical accuracy betrays a misunderstanding of what clarity is . At the top of this article, I said that clarity is when non-technical decision makers have a good enough working understanding of the system. That necessarily means a simplified understanding. When engineers are communicating to non-technical leadership, they must therefore simplify their communication (in other words, allow some degree of inaccuracy in the service of being understood). Most of my worries are not relevant information to non-technical decision makers . When I’m asked “can we deliver this today”, or “is it safe to roll this feature out”, the person asking is looking for a “yes” or “no”. If I also give them a stream of vague technical caveats, they will have to consciously filter that out in order to figure out if I mean “yes” or “no”. Why would they care about any of the details? They know that I’m better positioned to evaluate the technical risk than them - that’s why they’re asking me in the first place! I want to be really clear that I’m not advising engineers to always say “yes” even to bad or unacceptably risky decisions. Sometimes you need to say “we won’t be able to roll back safely, so we’d better be sure about the change”, or “no, we can’t ship the feature to this class of users yet”. My point is that when you’re talking to the company’s decision-makers, you should commit to a recommendation one way or the other , and only give caveats when the potential risk is extreme or the chances are genuinely high. At the end of the day, a VP only has so many mental bits to spare on understanding the technical details. If you’re a senior engineer communicating with a VP, you should make sure you fill those bits with the most important pieces: what’s possible, what’s impossible, and what’s risky. Don’t make them parse those pieces out of a long stream of irrelevant (to them) technical information. The highest-leverage work I do is to provide technical clarity to the organization: communicating up to non-technical decision makers to give them context about the software system. This is hard for two reasons. First, even competent engineers find it difficult to answer simple questions definitively about large codebases. Second, non-technical decision makers cannot absorb the same level of technical nuance as a competent engineer, so communicating to them requires simplification . Effectively simplifying complex technical topics requires three things: In a large tech company, this is usually a director or VP. However, depending on the scope we’re talking about, this could even be a manager or product manager - the same principles apply. Sometimes you know the answer off the top of your head, but usually that’s when you’ve been recently working on the relevant part of the codebase (and even then you may want to go and make sure you’re right). You do still have to be right a lot. I wrote about this in Good engineers are right, a lot . Despite this being very important, I don’t have a lot to say about it. You just have to feel it out based on your relationship with the decision-maker in question. Can the paid feature be safely delivered to free users in its current state? Can the feature be rolled out gradually? If something goes wrong, can the feature be reverted without breaking user accounts? Can a subset of users be granted early access for testing (and other) purposes? Can paid users be prioritized in case of capacity problems? Good taste - knowing which risks or context to mention and which to omit 4 . A deep technical understanding of the system. In order to communicate effectively, I need to also be shipping code and delivering projects. If I lose direct contact with the codebase, I will eventually lose my ability to communicate about it (as the codebase changes and my memory of the concrete details fades). The confidence to present a simplified picture to upper management. Many engineers either feel that it’s dishonest, or lack the courage to commit to claims where they’re only 80% or 90% confident. In my view, these engineers are abdicating their responsibility to help the organization make good technical decisions. I write about this a lot more in Engineers who won’t commit . In a large tech company, this is usually a director or VP. However, depending on the scope we’re talking about, this could even be a manager or product manager - the same principles apply. ↩ Sometimes you know the answer off the top of your head, but usually that’s when you’ve been recently working on the relevant part of the codebase (and even then you may want to go and make sure you’re right). ↩ You do still have to be right a lot. I wrote about this in Good engineers are right, a lot . ↩ Despite this being very important, I don’t have a lot to say about it. You just have to feel it out based on your relationship with the decision-maker in question. ↩

Business Career

▲ 0

0 views

ava's blog 6 days ago

a professional online presence?

At times, I think back to how this blog originally was meant to be a place to document tech stuff like a portfolio. Even now, there’s a weak link between work and this blog: As I finish my data protection certificate and talk about whatever moves me in that topic on here, I also volunteer whenever I can by translating court decisions for GDPRhub. It’s something I’m not shy about at work and reference in applications for data protection roles, and my GDPRhub profile links this blog as well. I have wondered sometimes if it’s worth it to bend the knee to norms around work and professionalism and not put my data protection posts where my Hello Kitty Island Adventure guide is, and where literal copies of my notebook are. Not that that includes anything I wouldn’t share at work - I only publish what I feel comfortable saying at work - but still, there is this recurring pressure to draw a clear line, not be too personal, and to clean up the act. There’s also the pressure of choosing the right medium. I’m sure companies love to see enthusiastic LinkedIn posting, and it seems like people only gain a professional reputation in a topic sphere online if they perform for an audience and grow it purposefully. What I mean is: Short form videos on TikTok cramming important and complex topics into a few takes, posting dramatic calls to action on a microblogging platform such as X or Mastodon, or posting YouTube videos with scary thumbnails. It kind of conveys: “ I am always up to date, I put out content as fast as I can, I will cover everything like my own little news show, it’s my main focus on this account, and I care because look how deeply concerned I look on the thumbnail as it says in bold red letters “IT’S ALMOST TOO LATE” ”. Just a blog post every now and then doesn’t convey that. I think a few years ago, that obnoxious approach might have gotten a different reaction. Over the top, dishonest, seeming ‘narcissistic’, unprofessional and scammy. But now that everyone is so in love with online content for marketing and hiring social media managers, suddenly it’s not - now it just shows your creative spirit, persistence, your ability to adapt to the times, make the format work for you and that you know how to play the algorithm. I just have no interest in all that. First, I don’t want to hide my personality online because I bring that exact same personality to work with me, too. Aside from minor code-switching, this is who you get. I don’t have a work-self. Second, I still don’t wanna go back to any of the usual social media platforms. Third, I don’t want to feel like I have to write a post about every recent happening in my field of interest to artificially perform devotion for an invisible audience. I prefer to write about the things that fire me up and that I am passionate about, and it usually involves some kind of problem, something I’m arguing against, some things I feel are missing from the conversation. I have not written about EU ChatControl, despite it basically being the biggest data protection nightmare right now, because what is there to say? It would be mind-numbingly boring to write about because there is no interesting conflict for me, just false hopes, false promises, and no understanding of tech while trying to pass something that would be incompatible with existing law. It’s not even fun disproving any of the arguments because they are all stupid and I can’t even seriously entertain them for one second and we’ve been at this every other year now. There is nothing to explore there. My brain refuses to even invest the energy. But if I was on other platforms, I’d probably have to, reasoning: Because others in the space do it too, or the audience I cultivated on that platform expects me to, or I wanna impress the expert in the field that follows me. Or simply because it’s a big thing, and capitalizing on something impactful is seen not as the disaster it is, but a way to farm engagement and followers. People doing all this can go: “ See, I am an expert and well known person in that field, I grew 100k followers, post every second day, and other known person in the field follows me too, and shares my posts! ”. That works for any topic, not just the intersection of tech and law, and I’m sure it gives some people a lot of street cred in their field even when they lack qualifications. It’s not impossible to build yourself up without these things, but it sure is a hack, a shortcut, a loud and flashy thing. I know who I am, and how much effort and passion I put into emails and real life conversations and work projects that involve data protection - it just becomes an issue when we live in a world that wants you to put things online to prove that they happen. If you were not there to record it and produce a digital track record, did it really happen? It’s not uncommon to get treated like a common idiot who just did an AI search for something by someone who did just that, just because you don’t perform your credentials right. I just want to write about things in a way that is unbound by algorithmic rules, peer pressure, follower retention and timing. No fear-inducing thumbnails, no virtually useless calls to action to drive engagement, no ragebaiting, no cookie-cutter same content strategy, no single-topic accounts to split my interests up. No dragging out the information because I need to make it long enough to reach the monetization threshold. No posting for posting’s sake, no feeling like I have to give some sort of stance or statement to everything, whether just to be one of the accounts people click on when they search a term on socials, or because having a lot of followers convinced me that everyone is just waiting for my position (when they are not). No preaching about how horrible this or that company is while not only being on it, but also making money off of, and for it. That’s why I’m here, on a quaint blog that I don’t promote anywhere and holds a lot of topics. It’s not a space for a personal brand, but it’s genuine. All this makes me feel a tiny twinge of guilt at times, but deep down, I know this is better. Reply via email Published 08 Oct, 2025

Career

▲ 0

0 views

iDiallo 6 days ago

Keeping the Candle Lit

On my first day at a furniture store, my boss pointed to a warehouse full of boxes and said, "Unpack that one and build it." Simple enough. I found a large, heavy box, sliced it open, and laid out an array of wooden slats, metal screws, and chains. It was a love seat swing. Clearly a two or three person job. But I didn't know that. If my boss asked me to build it, I figured, it must be possible. So I just started. There is this feeling I often get when I have a brand new exciting idea. What follows goes something like this. You buy the domain. You sketch the idea. You draft the first chapter. The rush of beginning something new floods your system with dopamine and possibility. This initial excitement is a fantastic fuel. It gets you moving. The candle of motivation always burns fastest at the start. But then you get past the first easy steps, and the flame sputters. The wax pool of complexity begins to form. Doubt seeps in. You start to realize the true scale of what you've undertaken. Suddenly, exhilaration starts to feel like exhaustion. Most projects die right here, in the soggy middle. If you are not careful, you might even start a new project just to feel that rush again. The trick isn't to avoid this burnout. It's inevitable. The trick is learning how to reignite the flame, or better yet, to build a different kind of fire entirely. Standing in that warehouse, I had an advantage I didn't recognize at the time. I had no idea how hard this was supposed to be. If my boss had said, "This is a complex, multi-person assembly job that typically takes experienced workers two hours," I would have been paralyzed. I'd have looked for help. I'd have doubted my ability. I'd have found seventeen reasons to do something else first. This is why every monumental piece of software, every world-changing company, every impossible creative work was started by someone who didn't fully grasp the mountain they were about to climb. If Jeff Bezos had started by trying to solve for a global fleet of delivery vans, AWS cloud infrastructure, and same-day delivery logistics, he'd never have sold his first book. If the Wright Brothers had tried to understand all of aeronautical engineering before attempting flight, they'd still be on the ground. Amazon's magic trick was to start selling books before you try to build the empire. Start with the bicycle shop before you revolutionize transportation. Start tightening one bolt before you build the swing. The most dangerous thing you can do with a big project is understand it fully before you begin. An hour into the swing assembly, my initial energy was completely gone. I was alone with this massive, complicated puzzle. My hands hurt. The instruction diagram might as well have been written in ancient Egyptian. The 'let's impress the boss!' fuel had evaporated, replaced by the reality of a hundred confusing parts and no clear path forward. But I had to complete the job. So I stopped thinking of it as 'building a love seat swing' and started thinking of it as a series of small, repeatable tasks. Find two pieces that fit. Align the holes. Insert bolt A into slot B. Tighten with wrench C. Repeat. I wasn't building anything. I was just completing a pattern. Over and over. This wasn't a creative problem, the instructions were written clearly on the paper. So I turned it into repetitive motion. When a task feels like it requires 100% pure creativity all the time, you will burn out. Creative energy is finite. Decision-making is exhausting. But rhythm? Rhythm is renewable. I entered a flow state not through inspiration, but through repetition. The goal shifted from "finish the impossible thing" to "complete the next simple step." This is how books get written. Not through sustained creative genius, but through showing up to the same chair at the same time and adding 500 words to yesterday's 500 words. This is how companies get built. Not through visionary breakthroughs every day, but through making the same sales calls, fixing the same bugs, having the same customer conversations until patterns emerge and systems develop. The secret is to find the smallest unit of meaningful progress and make it so frictionless that it's easier to do it than to avoid it. I've written about my trick to learning anything new before. I might as well start calling it the "100 Times Rule." The rule is simple: You can't do the big impossible thing once. But you can do the tiny component action 100 times. You can't write 100 novels. But you can write 200 words, 100 days in a row. You can't launch 100 companies, but you can have 100 conversations with potential customers. You can't master piano, but you can practice scales for 100 sessions. You can't "get in shape," but you can do 100 workouts. The power isn't in the number 100 specifically, it's in the reframing of the problem into manageable bites. When you commit to doing something 100 times, three things happen: It becomes a small repeatable task. One presentation? Easy. One workout? Done. One paragraph? Please. You're not trying to build a business, you're just making today's call. You make room for being bad at it. Nobody expects call #3 to be perfect. You're learning. You're iterating. You have 97 more chances to figure it out. You build the rhythm that replaces motivation. By the time you hit repetition #30 or #40, you're no longer running on inspiration. You're running on momentum, on identity, on the simple fact that this is what you do now. The swing didn't get built because I had sustained enthusiasm for furniture assembly. It got built because I found a repeatable motion and executed it dozens of times until the thing was done. A few hours later, my boss walked by, did a double-take, and stared at the fully assembled love seat swing, gently swaying in the warehouse. "Wait. You built this? By yourself?" he asked. I just nodded, my hands raw, my shoulders aching, but my self-confidence boosted. What I didn't tell him was that I succeeded not because I was an expert, not because I had some special talent for furniture assembly, not because I stayed motivated the entire time. I succeeded because I started before I knew the challenge, and I kept going by finding a rhythm within it. The candle of motivation will burn out, that's guaranteed. But you're not building a swing. You're just tightening this one bolt. Then the next. And then the next. Before you know it, you'll look up and find the impossible thing complete, gently swaying before you. Built not by inspiration but by the simple, persistent act of showing up and doing the smallest next thing. It becomes a small repeatable task. One presentation? Easy. One workout? Done. One paragraph? Please. You're not trying to build a business, you're just making today's call. You make room for being bad at it. Nobody expects call #3 to be perfect. You're learning. You're iterating. You have 97 more chances to figure it out. You build the rhythm that replaces motivation. By the time you hit repetition #30 or #40, you're no longer running on inspiration. You're running on momentum, on identity, on the simple fact that this is what you do now.

Career

▲ 0

0 views

Michael Lynch 1 weeks ago

Refactoring English: Month 10

Hi, I’m Michael. I’m a software developer and founder of small, indie tech businesses. I’m currently working on a book called Refactoring English: Effective Writing for Software Developers . Every month, I publish a retrospective like this one to share how things are going with my book and my professional life overall. At the start of each month, I declare what I’d like to accomplish. Here’s how I did against those goals: I did complete this successfully, but I spent too long on the post and felt somewhat underwhelmed with my final result. I wrote a first draft of a new chapter but didn’t publish it. I ended up spending more time than I planned on “The Software Essays that Shaped Me” and freelance editing clients. I was going to write this off and say that I’m not learning anything new anymore by reaching out to customers. Then, a few days ago, I heard back from a reader I’d reached out to who said he used what he learned from my book to get an article on the front page of Hacker News for the first time. So, that was pretty indisputably valuable and tells me I should be doing more of this. I brainstorm more about this below . September had a nice bump in website visitors and pre-orders. I’d like to get to the point where there’s a virtuous cycle of readers referring other readers, but I don’t think I’m there yet. Still, nice to make almost $1k for the month. In baseball, a bunt is when you hold the bat in the ball’s path rather than swinging the bat. The upside is that you’re less likely to miss, but the downside is that you won’t hit the ball very far. The best you can hope for with a bunt is making it to first base, but a bunt is almost never going to be a home run. Most of my blog posts are “swing for the fences” posts. I put in a lot of effort because I want to reach #1 on Hacker News, reddit, or search results. The problem is that my “swing for the fences” posts take me about a month to write, so if I’m publishing blog posts as I write my book, I’d have to put my book on hold for a month every time I write a blog post. I’ve been thinking about whether I could do some “bunt” posts instead. That way, I can only put my book on hold for a week rather than the whole month. I don’t want to take a topic that deserves a lot of care and just do a lazy version of it. Rather, I want to take a topic that’s easy to cover and just see how it does. My first bunt was, “I Once Appeared in The Old New Thing.” It was about an experience I had at 22 at my first real job. I didn’t have a lot of insightful things to say about it, but I thought it was an interesting story. I was able to write it in about four hours, and it felt complete for what it was. My next bunt was, “The Software Essays that Shaped Me.” I’ve seen other people share lists of their favorite software blog posts, and I thought it would be an easy, fun thing to do. Best of all, the people who appreciate good software writing might also find my book interesting. As I started to write “The Software Essays that Shaped Me,” it turned into more than just a bunt. I ended up spending almost all of September on it. I originally thought I’d list my favorite blog posts and call it a day, but that felt too boring. So, I tried to include short commentary about each post. Then, I got carried away and ended up writing commentary that was longer than the originals themselves. It took me several drafts to figure out what commentary felt interesting, and I still don’t feel like I quite succeeded. I ended up spending 17 hours on “The Software Essays that Shaped Me” and never stopped to evaluate whether it was still worth writing if it was going to be all that work. I think the post is interesting to people who read my blog. If someone I knew published a list of articles that influenced them, I’d find that interesting. But in comment threads about the post, people shared their own lists, and I found strangers’ lists totally uninteresting. Maybe I counteracted that some by investing a lot in my commentary, but I just don’t think a list of good blog posts can be all that interesting. Both posts did well. They both reached the front page of Hacker News, though they did it through the second chance pool , which feels a little like winning through TKO rather than a real knockout. It’s interesting that the results scaled almost linearly with the effort I invested, which I typically don’t find to be the case . Previously, when one of my Refactoring English posts did well on Hacker News, there was a noticeable uptick in readers purchasing the book . This time, “The Software Essays that Shaped Me” reached #2 and stayed on the front page for 11 hours, but only one person purchased. Maybe everyone seeing my post on Hacker News has already seen that I’m writing a book, so everyone who’s interested has already bought? I woke up the morning after my article had already fallen off the front page of Hacker News and suddenly realized: I never included the ad for the book! All the sample chapters on the book’s website include a little self-ad to tell the reader I’m writing a book on this topic, and they can buy early access. All the pages on the Refactoring English website are supposed to have a little self-ad on them for the book. I forgot to include the self-ad for the blog post, so the first 14k readers saw my post and had no idea I’m writing a book. D’oh! I’ve updated my blog template so that I can’t possibly forget to include the self-ad in the future. A few months ago, I decided to offer freelance editing services to help other developers improve writing on their blogs. My idea was that it’s an opportunity to make sure the way I explain concepts in my book makes sense to real people. The downside is that there’s a high cost to the editing. Each job takes me between four to seven hours, and it eats up my “hard thinking” of the day, so it’s tough to do my own writing in the same day. I also feel pressure to offer quick turnaround, even though nobody has asked me to hurry. But just knowing my own writing process, it sucks to be stuck for days waiting on feedback. At the beginning, freelance editing worked as I planned: it gave me good ideas for my book. As I do more jobs, I’m getting fewer ideas for my book. Now, most of the feedback I write is basically writing a personalized version of something I’ve already written for my book. I want to keep doing the editing, but only for authors who have read my book. I doubled my rates, so now my price for editing a blog post is $400. But I’m going to offer a 90% discount to readers who have read my book. At a 90% discount, it’s almost not worth charging at all, but I want clients to pay some amount so that they feel like they have skin in the game, too. I’ll continue to take on clients who haven’t read the book, but I want to charge enough that I feel like it’s worth the tradeoff of taking time from my book. $400 might still be too low, but we’ll see. I’m trying to figure out why I keep missing my goal of reader outreach. On its face, it doesn’t seem that hard, but it never seems like the most important thing, so I keep deferring it. There are other tasks I procrastinate because I don’t enjoy doing them, but I actually enjoy reaching out to readers. It’s fun to see what different readers are up to and how they might apply my techniques. Part of the issue is that emailing readers requires activation energy because I have to: It might help if I first gather a list of customers to email and their websites. That way, when I’m in the mood to reach out, I’m not starting from scratch every time. A few Refactoring English customers have emailed me confused because they paid but never got an email with a link to the book. I collect payment through Stripe, and Stripe redirects customers to the book’s URL after they complete payment. If the customer doesn’t notice the redirect or forgets to bookmark the page, they lose access to the book. Whenever customers tell me they can’t find the link to the book, I dig around in Stripe to look for a setting to customize post-purchase emails, give up after a few minutes, and then email the correct link to the customer. Last month, I finally sat down and searched through Stripe’s documentation and forum posts, and I can’t find any way to customize the email Stripe sends after a customer completes a one-time payment. As far as I can tell, the only option is to spin up your own web server to listen for Stripe webhooks, then send your own emails from your own email provider. All because Stripe can’t be bothered to let merchants customize any text in the payment completion emails… Setting up a web server to respond to webhooks shouldn’t be that hard for me, but it means writing code to glue together Stripe, Buttondown, and Netlify functions, and they all have their little gotchas and bugs. Especially Stripe. I’ve spent about 10 hours so far just trying to get emails to send after a customer makes a purchase, and I’m still not sure it’s working correctly. Here are the gotchas I’ve hit so far: I’m still tinkering with Hacker News Observer, a product that I still haven’t released and don’t know what to do with. For now, I’m just gathering data and using it to satisfy some curiosities about success on Hacker News. One curiosity I’ve had for a long time is whether there are times of day when it’s easier for a post to reach the front page of Hacker News, so I aggregated what percentage of posts reach the front page over the course of a day: I created a view in Hacker News observer to show front page stats by hour I initially thought I had a bug that overcounted the success rate, as the percentage of Hacker News submissions that reach the front page feels lower than 12% in my experience. Then, I looked at some random slices from the last few days, and it seems to match up. If I browse , there will typically be 2-5 stories that reached the front page. I found a 30-minute slice from a few days ago where 27% of submissions reached the front page, which is surprising. I thought that success rate would be significantly higher on the weekends, when there are fewer submissions. Weekend posts are more likely to reach the front page, but the effect is much smaller than I thought. I thought it was going to be like 5% on weekdays vs. 20% on weekends. It makes submitting on the weekend less attractive because your chances of hitting the front page are only slightly better, but if you succeed, there are substantially fewer readers. I’d like to try limiting the data to personal blogs like I do on HN Popularity Contest , as I’m curious to see if personal blogs have better chances at certain times. I’m experimenting with low-investment, low-payoff-style blog posts. I’m adjusting my strategy for freelance editing to work specifically with people who have read my book. My intuition was way off about the odds of reaching the front page of Hacker News. Result : Published “The Software Essays that Shaped Me” , which attracted 16k readers in the first three days Result : Didn’t publish anything new Result : Emailed two new readers Go to my list of pre-paid readers Look for ones that have a website (so I can say something personalized) Read through their website to learn more about them Write an email and word it carefully to avoid sounding AI-generated Stripe’s Go client library is compatible with exactly one version of the Stripe webhook API. No, the documentation doesn’t say which one. Run it and find out from the webhook failures! If you update your Stripe account to use the latest webhook API version and then resend a webhook for a previous event, Stripe still uses the old API version even though it claims to use the new version. Netlify silently converts HTTP header names to lowercase, so if you’re looking for the header, you have to look for . Instead of a normal v2 Go module , Stripe for some reason decided to make every package upgrade a source change as well, so when I upgrade from v83 to v84, I have to replace in every file that imports the Stripe package. Normally, you’d upgrade the version in one place without affecting imports. The Stripe webhook signing secret is different from your Stripe API key. Weekdays: 12.1% of submissions reach the front page. Weekends: 13.2% of submissions reach the front page. Published “The Software Essays that Shaped Me” Published “I Once Appeared in The Old New Thing” Published “Get xkcd Cartoons at 2x Resolution” Worked with two freelance clients for Refactoring English Set up a webhook handler to send post-purchase emails to Refactoring English customers Added “success by hour of day” feature to Hacker News observer Started contributing to the Jellyfin Roku client code Had a call with AirGradient to discuss improving relations between the company and community members Consider bailing if a low-investment post turns out to be high-investment. Stripe does not allow you to customize post-purchase emails. You have to do a bunch of other stuff to send your customers an email. Set up editing discounts for readers who have read the book. Create a list of early access customers to reach out to. Publish a new chapter of the book.

Business Career Writing Go

▲ 0

0 views

Harper Reed 1 weeks ago

Now @ 10-06-2025

As many people have said “it is going to get worse before it gets better.” Let’s see! Thank you for using RSS. I appreciate you. Email me This company has been going. We published some research. It is fun. We have raised some money from amazing people. I am excited to be building things again. I can’t wait to show you more what we are building. Spending a lot of time “vibe coding.” I code everything! I am still feeling a deep sense of uncertainty. AI is coming for us faster than we thought. I don’t think people my age who are being laid off now are going to be able to find jobs equivalent to what they had before. The state of the US is very concerning at the moment. I seem to be living in a freshly occupied city. Weird. There is a sense of fear out here that is stresseful, and terrifying. Reading a lot of books. Send me your recs. Still taking a lot of photos. It is still fun. We have a new office, swing by! Trying to meet people out and about. HMU. let’s get lunch Running and working out a lot. It is nice. I feel great. I am an AI assistant. Trying to blog a lot more and at a regular cadence. Now with notes . Pretty excited about Bluesky and atproto specifically. Very neat. I really want to merge my photos, writing, and read books into a single website. Thinking a lot about that. Give me ideas I think I am making progress! Now just need to figure out photos. I still haven’t figure this out Still, excited about the future. Although a bit worried about the present.

Career AI Writing

▲ 0

0 views

ava's blog 1 weeks ago

attitudes around quitting your job

"Why I quit my job" texts and videos seem to be my current "Baader-Meinhof-Phenomenon" 1 subject, meaning I see it everywhere. Very obviously explained by my own focus on wanting to quit my current job either completely or transferring to a new position outside of my current department. Even my favorite podcaster/YouTube personality is currently dealing with that topic as she quit her cushy software engineering job at Google to focus on being a pottery artist fulltime, together with her podcast and YouTube channel. Controversial choice lots of people have opinions about! My coworkers know that I intend to leave as I have not made a secret about it and have been open as to why I want to do that whenever they asked. The opinions are almost as polarized as the YouTuber's subscriber reactions are. On one hand, there is my equally young coworker who also intends to leave and shares the exact same views and feelings as I do. She is optimistic in a sort of realistic way - that while you have to make plans for what's next and shouldn't leave on a whim, that you will always find something equal or better at some point, that the journey is worth it even if you land in other bad places for a while. She agrees that you shouldn't waste time working somewhere that grinds you down or changes you negatively. It makes sense because we are both from the generation that knows giving yourself up for a job doesn't lead anywhere, that you can be replaced any second, and that time spent on friends and family is more important in the end. You have to protect your health and only have one shot at this whole thing, might as well try things out. We recognize that we still have so much to see and offer and that this isn't the end - especially because many of us don't have things to afford like previous generations had. We aren't saving up for a shiny new car, or to afford a whole house, or to do fancy vacations all the time, or to be able to afford a child, or put things away for a retirement we know won't come. You need to stay in the safe, permanent position with acceptable pay for these kinds of things as you'd otherwise jeopardize them. But without all that, what gives? There is no financial obligation or reliance on you to keep you there. As a most likely perpetual childfree tenant with no drivers license, using public transport and being uncomfortable with much travel and has no need to fly, my money goes into hobbies which are significantly cheaper than all of these things. I can afford to leave for something else without worrying about a mortgage. So there's of course the other side from older coworkers, particularly one who needs to continue paying off a house and raising a child, that is more hesitant. Aside from the obvious financial obligations and needing flexibility to tend to the child, she feels very fulfilled by the job, and it fits her greatly. She had always just wanted to finish school and work, and the type of work didn't seem to matter to her much as long as it paid enough. That is where she landed, with a lot of job security and other benefits, so she is set. Has been doing this same job for over 15 years now if I remember correctly. So of course, she would emphasize the advantages that I am also very aware of - great boss, great flexibility, she thinks we are being overpaid (maybe), working from home. " Who knows where else you'll land! Maybe it will be worse than here and then you will regret it. You'll never know. " Which I also understand and think of frequently; remembering the things to be grateful for has gotten me through really annoying and exhausting times at the job, but it is also something I would frequently tell myself too if I couldn't afford to ever switch jobs due to the life I have built myself. But the thing is: " You'll never know " goes both ways. If people stay, they'll never know how good it would have been to leave, either. I am not for throwing the towel at every slight hardship, but I think after a while, you can tell whether it is a tough but temporary phase or whether you have truly outgrown the job. One thing I learned this year is to spot that, because I mistook the latter for the former, and if I had seen the difference sooner, maybe there would be less bore-out exhaustion and resentment associated with the work for me internally. Sometimes, you don't even need better. You just need different, even if it ends up being worse, because at least it is not the previous thing, or it makes you more grateful for the previous thing. And I think that's okay. This relates to a lesson I think I would give every person in their 20s in their first 'proper' job: Make sure you create paths out of this. Twice in my life, I felt ready to basically resign myself to the job I held at that time, because it fulfilled my low standards that I had, felt really good and new and I could not ever imagine wanting more or outgrowing it. But the truth is: Things change in ways you cannot foresee. Your needs might change, the work itself might change, your coworkers and bosses might change. If you don't work on something on the side - maybe more qualifications, maybe extra projects at the job that builds CV and networks internally, etc. - you will arrive at a point where you need to leave, and you can't. I am glad I did (and still do) my degree on the side, I networked internally, I took on extra projects and I got certified on the side too, just to open doors for myself that now make leaving easier. Because knowing you need to leave as soon as possible, but being unable to, and looking down years of getting some extra qualification on the side before you can use it to leave is soul crushing. My law degree started as something on the side for fun, and I didn't intend to use it for anything when I started. Since then, it helped me discover a new career path for myself, pursue it more deeply, and is now something I will actually use to leave and change my career. Without it, things would seem a lot more hopeless for me right now. So even if the job you hold right now seems ideal and like something you can just stay at forever, always create a possible way out. You never know when you suddenly have a tyrannical boss, unreasonable work, or cannot work that job anymore for mental or physical reasons, for example. Going back to the software engineer turned pottery artist, I think the negative reactions she got were pretty interesting, even if predictable. It made me realize how many people there are who have a sort of romanticized view of a job they don't even hold and how much it gets them through their own work day. An idea of a job looming in their head that would totally be better, and they're just not following that right now, but it's always there like a warm embrace, a Plan B, a "I totally could have if I had wanted to, and maybe still will" path in life. A desk fantasy. The fantasy might be different for everyone - whether it is becoming an artist, or software engineer, working at a farm, or similar stuff. There seem to be two scenarios to this: People who are mad you enter their romanticized job, and the people who are mad you dare to leave it. Of course, the former are obviously mad they have not, and will likely not, do that switch. They keep putting it off or it is realistically impossible for them, but you actually doing it is rubbing salt in the wound. The clock is ticking: " Others are achieving it but you don't, why? Time is passing, you can't keep putting this off or this door might close. " Or: Rubbing in that this is actually completely out of the question, ruining the fantasy, the only out. The second one is more interesting to me to talk about because in theory, people working other jobs who romanticize software engineering in their head and see someone leave it should be happy that there's a spot open for someone else (like them?). But instead, many seem to crash out about it, calling the person who left ungrateful, that they never even deserved the job, and that they will regret it. It seems like someone leaving triggers not only intense jealousy (why are they leaving what I would kill to have? My dream??), but the fear that deep down, maybe the desk fantasy they cope with is not all that in practice. If even their ideal job is something people leave because it makes them feel as burnt out as their current job, then what is left? Their dream of a job that is effortless, always fun, high paid and fulfilling is threatening to be crushed. I feel a little for these people, because man, did the tech industry do a great job of convincing us all for a while that it's about shooting the shit with the bros in what can only be described as an adult playground. News about integrated gyms and their own cafes and restaurants where employees get food for free; rooms with game consoles, billiards tables and kicker tables; vibrant colors in open workspaces furnished with whacky looking sofas and indoor gardens; relaxation zones and massages. I remember a time when all kinds of tech companies seemingly tried to one-up each other about who could be cooler and quirkier about their office design. The flex clearly was: " We still have an amazing product even while offering comfort and distraction! " Together with the pay and bragging rights, what else do you want? I think this image still sits in many people's heads who don't actually work there. But the many, many testimonials on LinkedIn or YouTube or Substack seem to underline the intense shift the industry had over the years: a lot of hard work, almost no play, working people to the bone while retracting a lot of freedoms and other aspects that made these companies' work culture stand out from others. Now it seems not unlike working in any other boring office job, or like the finance industry that has a stick so far up its ass you could see it come out the top. So many software engineers grew tired of having to develop garbage, arbitrary deadlines, threats of layoffs, working intense overtime, questioned the ethics, and were disappointed and blindsided by the turn into despicable politics their leaders completed. Acknowledging that shift and what people who left are saying would mean acknowledging that the dream of that job is dead, and that your "maybe one day" mind palace of completing a bootcamp and miraculously finding your way into FAANG is in the gutter. It would involve facing the fact that the positions you could have started in are now eliminated and probably done via LLMs. What makes this specific case even spicier is the fact that someone would trade something highly regarded and well-paid for something that is currently facing its probably biggest devaluation in society so far - art. The devaluation seems to be reinforcing itself, as the fears of artists being replaced has come true and in turn, people are told to leave art, or at least not do it professionally. This again narrows the field in who can be a career artist, making AI art seem even more like the path forward. Of course, AI is not creating pottery, so that is an art niche that is safe for now, but still: The way people talk about, and treat art now thanks to AI generation makes apparent that most people have no idea what art is, what kind of process is involved, and where they can even find art. Art, to them, is something meaningless and a waste of money that hangs in galleries. Even the biggest gamers at this point refuse to acknowledge the artists that created the worlds they love, instead acting as if a machine can just create all that in the same way, or even better, in mere seconds. The design in user interfaces, in devices, in furniture, in clothes, in comics and flyers and infographics is not perceived as art that is planned and worked on, it just somehow appears, and AI has made that a reality. Human art is seen as faulty, time consuming, expensive; machine-created art is corporate-clean, brand-friendly, cheap and versatile. No personal style, baggage, wishes and time constraints by the artist to consider, just a fully malleable piece of play-doh. Going from the place that creates the very thing that is intended to replace artists to becoming an artist professionally is bold in these times, and sends a statement. It may seem naive, outdated, too self-assured to others, but it's not only this specific scenario: lots of people in very digital jobs have pivoted into more hands-on, physical work, putting into question if just creating digital facsimiles long-term is sustainable and gratifying at all. This is bound to enrage people who see a sort of utopia achieved by radical digitization and digitalization of our lives. Seeing people quit their jobs, their reasons for doing so and their path forward is something I really enjoy, but I also love seeing some of the destabilizing effects this has on people who have (or preferred to) keep their eyes closed and their heads down. Reply via email Published 05 Oct, 2025 Also known as the frequency illusion - basically, you see a lot of something once you become aware of it. New band you never heard of? Now you see the band's name everywhere. ↩ Also known as the frequency illusion - basically, you see a lot of something once you become aware of it. New band you never heard of? Now you see the band's name everywhere. ↩

Culture Career

▲ 0

0 views

Dan Moore! 1 weeks ago

Say Goodbye

In this time of increasing layoffs , there’s one thing you should do as a survivor. Okay, there’s many things you should do, but one thing in particular. Say goodbye. When you hear someone you know is let go, send them a message. If you have their email address, send them an email from your personal account. If you don’t, connect on LinkedIn or another social network. The day or two after they are gone, send them a message like this: “Hi <firstname>, sorry to hear you and <company> parted ways. I appreciated your efforts and wish you the best!” Of course, tune that to how you interacted with them. If you only saw them briefly but they were always positive, something like this: “Hi <firstname>, sorry to hear you and <company> parted ways. I appreciated your positive attitude. I wish you the best!” Or, if you only knew them through one project, something like this: “Hi <firstname>, sorry to hear you and <company> parted ways. It was great to work on <project> with you. I wish you the best!” You should do this for a number of reasons. It is a kind gesture to someone you know who is going through a really hard time. ( I wrote more about that .) Being laid off is typically extremely difficult. When it happens, you are cut off from a major source of identity, companionship, and financial stability all at once. Extending a kindness to someone you know who is in that spot is just a good thing to do. It reaffirms both your and their humanity. It also doesn’t take much time; it has a high impact to effort ratio. There may be benefits down the road, such as them remembering you kindly and helping you out in the future. The industry is small–I’m now working with multiple people who I’ve worked with at different companies in the past. But the main reason to do this is to be a good human being . Now, the list of don’ts: Be a good human being. When someone gets laid off, say goodbye. Don’t offer to help if you can’t or won’t. I only offer to help if I know the person well and feel like the resources and connections I have might help them. Don’t trash your employer, nor respond if they do. If they start that, say “I’m sorry, I can imagine why you’d feel that way, but I can’t continue this conversation.”. Note I’ve never had someone do this. Don’t feel like you have continue the conversation if they respond. You can if you want, but don’t feel obligated. Don’t state you are going to keep in touch, unless you plan to. Don’t say things that might cause you trouble like “wish we could have kept you” or “you were such a great performer, I don’t know why they laid you off”. You don’t know the full details and you don’t want to expose yourself or your company to any legal issues. Finally, don’t do this if you are the manager who laid them off. There’s too much emotional baggage there. You were their manager and you couldn’t keep them on. They almost certainly don’t want to hear from you.

TypeScript Career

▲ 0

0 views

iDiallo 1 weeks ago

Why You Can't Be an Asshole in the Middle

On the first day on the job, the manager introduced me to the team, made a couple of jokes, then threatened to fire someone. At first, I thought it was just his sense of humor, that it was something I would understand once I worked long enough on the team. But no one else laughed. The air in the meeting room became stiff as he rambled about issues we had. The next Monday morning, he did it again. Now I was confused. Was I being hazed? No. Because he did it again the following Monday. He was an asshole. But he wasn't just any asshole. He thought he was Steve Jobs. Steve Jobs was a difficult person to work with. He was brutally honest, he could bend wills, shatter egos. Yet, he was also enshrined as one of the greatest business leaders of our time. He was the visionary who resurrected Apple and gave us the iPhone. My manager wasn't alone in his delusion. Like many professionals who find themselves in a people manager's position, they look at Jobs and think that being a brilliant jerk is a viable path to success. "The results speak for themselves. Maybe I need to be tougher, more demanding, less concerned with feelings." What they fail to see is that they are not Steve Jobs. And unless you're the CEO at the helm, acting like him is not a superpower. When you're a mid-level manager, you're not the Captain. You're a member of the crew. The difference between being an asshole at the top versus being an asshole in the middle comes down to authority, autonomy, and consequences. Jobs was the Captain. As the founder and CEO, he was the ultimate source of authority and vision. His difficult personality was inseparable from the company's mission. People tolerated his behavior because they bought into his vision of the future. He had the final say on hiring, firing, and strategy. His presence was the gravitational force around which the entire company orbited. When the captain is an asshole, the crew might stay for the voyage. When a fellow crewmate is an asshole, they get thrown overboard. A mid-level manager is a key member of the crew, but you are not the ultimate authority. Your colleagues in engineering, marketing, and sales don't report to you out of reverence for your world-changing vision; they collaborate with you to achieve shared company goals. Your power is not absolute; it's influence-based. And that changes everything. For Steve Jobs, it's not that being an asshole was his secret sauce. It's that his unique position allowed him to survive the downsides of his personality. He was building his vision of the future. For every person he drove away, another was drawn to the mission. It was impossible to fire him (a second time). He could fire people, and he could make them millionaires with stock options. The potential upside made the toxicity tolerable. The part of the story that often get omitted is that Jobs had a cleanup crew. Behind his grandiose ideas and abrasive personality, there were people who handled the operations and relationship-focused work he didn't have time for. That's what Tim Cook was for. Tim Cook smoothed over the conflicts, built the partnerships, and kept the machine running while Jobs played visionary. As a mid-level manager, you don't have a Tim Cook, do you? As a mid-level manager, your "because I said so" doesn't have the same weight. Anyone one level above your position can contradict you. When the CEO is harsh and demanding, it gets labeled as visionary leadership. The same behavior from a mid-level manager is seen for what it is: poor communication and a lack of respect. Your influence is much smaller than the person at the helm. You need favors from other departments, buy-in from your peers, and discretionary effort from your team. Being difficult burns bridges, creates resentment, and ensures that when you need help, no one will be in a hurry to give it. Your "brilliant" idea dies in a meeting room because you've alienated the very people needed to execute it. Your tools are limited. You can't promise life-changing wealth, and while you can influence promotions or terminations, the process is often layered with HR policies and approvals. Using fear as your primary tool without having ultimate control just creates a culture of anxiety and quiet quitting, not breakthrough innovation. Collaboration is your strength, and you're actively undermining it. When we had layoffs at my company, my manager was first on the list to get the boot. I can't say that his "assholery" was what put him on the list, but it certainly didn't help. No one went to bat for him. No one argued that he was indispensable. The bridges he'd burned came back to haunt him. Your success as a mid-level manager depends on your ability to influence, inspire, and collaborate. You can't demand greatness; you have to cultivate it. And you can't do that from behind a wall of arrogance and fear. In the real world, building bridges will always get you further than burning them. At work, be the leader people actually want to follow .

Business Career

▲ 0

1 views

DHH 1 weeks ago

Pay yourself first

There'll always be more emails in need of reply, more meetings to attend, and more updates to read. A person can fill the entire workweek with these tasks over and over again. But to stay sane and sharp, you must pay yourself first by doing the work that actually means something to you. I feel this acutely as someone responsible to employees, customers, followers, and readers. I could do nothing all day but check up on projects, people, and posts, but my brain would quickly check out if it was just doing that. So quite frequently, I just don't. Don't check in, don't check up, and instead dive into the work that checks my own intellectual boxes. Programming for the love of it. Experimenting for the hell of it. Researching for the fun of it. In another age, I might have been tempted to apologize for such privilege, but screw that. Privilege is wonderful. You should do your best to earn more of it. Even if you have to carve it out of the bare rocks around you. Ironically, the best way to do that is also to choose to always pay yourself first, however little at first. By solving your own problems, tickling your own interests, chasing your own curiosity. That's where you'll find the motivation to elevate your talent. To turn interest into competency.  And once you've developed some competency, you'll be rewarded with more privilege to build it further. This is the virtuous circle of merit. There'll always be an endless list of work that could be done. You'll never get through it all and onto your own priorities, if you continue to put them at the bottom.

Programming Career

▲ 0

1 views

Sean Goedecke 1 weeks ago

How I influence tech company politics as a staff software engineer

Many software engineers are fatalistic about company politics. They believe that it’s pointless to get involved, because 1 : The general idea here is that software engineers are simply not equipped to play the game at the same level as real political operators . This is true! It would be a terrible mistake for a software engineer to think that you ought to start scheming and plotting like you’re in Game of Thrones . Your schemes will be immediately uncovered and repurposed to your disadvantage and other people’s gain. Scheming takes practice and power, and neither of those things are available to software engineers. It is simply a fact that software engineers are tools in the political game being played at large companies, not players in their own right. However, there are many ways to get involved in politics without scheming. The easiest way is to actively work to make a high-profile project successful . This is more or less what you ought to be doing anyway, just as part of your ordinary job. If your company is heavily investing in some new project - these days, likely an AI project - using your engineering skill to make it successful 2 is a politically advantageous move for whatever VP or executive is spearheading that project. In return, you’ll get the rewards that executives can give at tech companies: bonuses, help with promotions, and positions on future high-profile projects. I wrote about this almost a year ago in Ratchet effects determine engineer reputation at large companies . A slightly harder way (but one that gives you more control) is to make your pet idea available for an existing political campaign . Suppose you’ve wanted for a while to pull out some existing functionality into its own service. There are two ways to make that happen. The hard way is to expend your own political capital: drum up support, let your manager know how important it is to you, and slowly wear doubters down until you can get the project formally approved. The easy way is to allow some executive to spend their (much greater) political capital on your project . You wait until there’s a company-wide mandate for some goal that aligns with your project (say, a push for reliability, which often happens in the wake of a high-profile incident). Then you suggest to your manager that your project might be a good fit for this. If you’ve gauged it correctly, your org will get behind your project. Not only that, but it’ll increase your political capital instead of you having to spend it. Organizational interest comes in waves. When it’s reliability time, VPs are desperate to be doing something . They want to come up with plausible-sounding reliability projects that they can fund, because they need to go to their bosses and point at what they’re doing for reliability, but they don’t have the skillset to do it on their own. They’re typically happy to fund anything that the engineering team suggests. On the other hand, when the organization’s attention is focused somewhere else - say, on a big new product ship - the last thing they want is for engineers to spend their time on an internal reliability-focused refactor that’s invisible to customers. So if you want to get something technical done in a tech company, you ought to wait for the appropriate wave . It’s a good idea to prepare multiple technical programs of work, all along different lines. Strong engineers will do some of this kind of thing as an automatic process, simply by noticing things in the normal line of work. For instance, you might have rough plans: When executives are concerned about billing, you can offer the billing refactor as a reliability improvement. When they’re concerned about developer experience, you can suggest replacing the build pipeline. When customers are complaining about performance, you can point to the Golang rewrite as a good option. When the CEO checks the state of the public documentation and is embarrassed, you can make the case for rebuilding it as a static site. The important thing is to have a detailed, effective program of work ready to go for whatever the flavor of the month is. Some program of work will be funded whether you do this or not. However, if you don’t do this, you have no control over what that program is. In my experience, this is where companies make their worst technical decisions : when the political need to do something collides with a lack of any good ideas. When there are no good ideas, a bad idea will do, in a pinch. But nobody prefers this outcome. It’s bad for the executives, who then have to sell a disappointing technical outcome as if it were a success 4 , and it’s bad for the engineers, who have to spend their time and effort building the wrong idea. If you’re a very senior engineer, the VPs (or whoever) will quietly blame you for this. They’ll be right to! Having the right idea handy at the right time is your responsibility. You can view all this in two different ways. Cynically, you can read this as a suggestion to make yourself a convenient tool for the sociopaths who run your company to use in their endless internecine power struggles. Optimistically, you can read this as a suggestion to let executives set the overall priorities for the company - that’s their job, after all - and to tailor your own technical plans to fit 3 . Either way, you’ll achieve more of your technical goals if you push the right plan at the right time. edit: this post got some attention on Hacker News . The comments were much more positive than on my other posts about politics, for reasons I don’t quite understand. This comment is an excellent statement of what I write about here (but targeted at more junior engineers). This comment (echoed here ) references a Milton Friedman quote that applies the idea in this post to political policy in general, which I’d never thought of but sounds correct: Only a crisis—actual or perceived—produces real change. When that crisis occurs, the actions that are taken depend on the ideas that are lying around. That, I believe, is our basic function: to develop alternatives to existing policies, to keep them alive and available until the politically impossible becomes politically inevitable. There’s a few comments calling this approach overly game-playing and self-serving. I think this depends on the goal you’re aiming at. The ones I referenced above seem pretty beneficial to me! Finally, this comment is a good summary of what I was trying to say: Instead of waiting to be told what to do and being cynical about bad ideas coming up when there’s a vacumn and not doing what he wants to do, the author keeps a back log of good and important ideas that he waits to bring up for when someone important says something is priority. He gets what he wants done, compromising on timing. I was prompted to write this after reading Terrible Software’s article Don’t avoid workplace politics and its comments on Hacker News. Disclaimer: I am talking here about broadly functional tech companies (i.e. ones that are making money). If you’re working somewhere that’s completely dysfunctional, I have no idea whether this advice would apply at all. What it takes to make a project successful is itself a complex political question that every senior+ engineer is eventually forced to grapple with (or to deliberately avoid, with consequences for their career). For more on that, see How I ship projects at large tech companies . For more along these lines, see Is it cynical to do what your manager wants? Just because they can do this doesn’t mean they want to. Technical decisions are often made for completely selfish reasons that cannot be influenced by a well-meaning engineer Powerful stakeholders are typically so stupid and dysfunctional that it’s effectively impossible for you to identify their needs and deliver solutions to them The political game being played depends on private information that software engineers do not have, so any attempt to get involved will result in just blundering around Managers and executives spend most of their time playing politics, while engineers spend most of their time doing engineering, so engineers are at a serious political disadvantage before they even start to migrate the billing code to stored-data-updated-by-webhooks instead of cached API calls to rip out the ancient hand-rolled build pipeline and replace it with Vite to rewrite a crufty high-volume Python service in Golang to replace the slow CMS frontend that backs your public documentation with a fast static site I was prompted to write this after reading Terrible Software’s article Don’t avoid workplace politics and its comments on Hacker News. Disclaimer: I am talking here about broadly functional tech companies (i.e. ones that are making money). If you’re working somewhere that’s completely dysfunctional, I have no idea whether this advice would apply at all. ↩ What it takes to make a project successful is itself a complex political question that every senior+ engineer is eventually forced to grapple with (or to deliberately avoid, with consequences for their career). For more on that, see How I ship projects at large tech companies . ↩ For more along these lines, see Is it cynical to do what your manager wants? ↩ Just because they can do this doesn’t mean they want to. ↩

Go Career Business Python

▲ 0

0 views

ava's blog 1 weeks ago

what are my signs of success?

I recently asked myself that, and wanted to dig deeper. I find the focus on numbers and status symbols in such answers extremely dull; doesn’t show a good character, but instead, a consumerist victim. If all you can think of in success is buying more poisonous murder machines and more extravagant but unnecessary housing that you may or may not hold hostage and rent out, you are a rotten loser and I wouldn’t even want to spend an hour in your gray and cynic mind. My signs of success (meaning, things I can observe in life that show me that I “made it” because they are connected to privilege and some of the work I put in) that I hope to see one day are: This shows to me that I have had the energy, time, and whatever else needed to pursue my interests and kept learning. It’s easy to become discouraged and give up, refusing to learn and change. Stress and illness can interfere. Not succumbing to that and instead always persisting is a success. I also never feel like I know enough about the things I love and feel like a huge impostor. Not feeling ‘less than’ anymore because I know I have a significant amount of experience and knowledge is something I see as a huge sign of success for me as I age and advance. This sign shows that I love what I do, I feel well enough to do it, and I am appreciated, not trying to convince anyone or fight for approval; instead, going hard because I want to give back. To be happy with my output, it must be work that aligns with my values and that I am proud to contribute to, which is very privileged, as many can’t choose by morals or ethical concerns who to work for, but have to make ends meet somehow and play the card they were dealt. Means: I don’t have to chase, I don’t have to run around reminding the people at work, or in the industry, that I exist; I can let my work speak for itself, and I shine by doing a good job, not by desperation or begging. Shows to me that I have a good track record, a good reputation, and am perceived as competent and someone to learn from. I think middle-class people underestimate this sign of success. The way I grew up especially in my teens, we had to restrict grocery shopping, always take the cheapest, and hoped nothing breaks. Anything breaking could either not be replaced or set us back. I think the financial aspect of success is wasted if it is only spent on me or who’s in my home. It’s supposed to be shared! I spent a lot of my life fighting alone, and there can be pride in not having had to rely on anyone for certain milestones; but I’m sure I will not make it far without the support of my loved ones, from strangers online too, and probably even influential books and works of art. It’s only fair and sensible to give back. I would much rather ensure everyone I know is comfortable before considering any luxurious purchase. Same with the fact that success means nothing if our planet goes to shit, animals go extinct, our water is poisoned, pandemics rage on and we’re being killed in extreme events. What is owning a Porsche for if all you can do is die in it? Not doing work that breaks my body, not having to work grueling hours for little pay, not having to work tons of overtime and be available almost 24/7 is a huge privilege. Flextime, unlimited sick days, a lot or unlimited vacation days, four hour work week and related work circumstances often due to union wins and protections all play into this. Bad work can wear you down, make you sick, unmotivated, and crushes your dreams, all while taking up the time needed to see friends and family. Having work that doesn’t is, to me, a sign of success in my life. What’s difficult in writing these down and talking about success and privilege is that the two are linked somewhat, but usually not in the way people want them to be. They want to think that all privilege they see is earned success that they can replicate, but it’s not. There is a lot of privilege that is unearned and that you likely can’t recreate. On the flip side, you can be really successful for your means in a really underprivileged position, but it’s not perceived that way because it is often about pure survival and not perceived as desirable or glamorous. Just talking about success makes it seem as if hard work can get you anything, when that’s not true at all, but only talking about inherent privilege misses behaviors with which people increase theirs. It’s extra complicated when acknowledging that people will likely not reach many markers of success, even of the ones I laid out, if the system we live in doesn’t value their work or skills, or doesn’t value them as a person. The last sign of success especially: Seeing how important the work of nurses and caregivers, sanitation workers, teachers and other childcare, farm and food industry workers, artists and more is, but how the circumstances of their work is making it highly exploitative and destructive due to how much that work has been devalued in society. Many negative aspects of their work are not inherent, they are a deliberate consequence of priorities and oppression. It’s important to talk about the privilege and gratitude connected to not having to deal with these circumstances, while not also promoting the idea that working these jobs is below us or is not what a “successful” life is about. Ideally, these jobs too would allow for these signs of success. Just a sidenote! Reply via email Published 03 Oct, 2025 Being competent and knowledgeable in the things I am passionate about. Delivering reliably, and often overdelivering when it matters. Being happy with what I put out. My reputation (positively) preceding me. Being top of mind for new projects if they fit my skillset. Others asking me for advice. Not having to look at the price tag for everyday necessities. Being able to replace anything that breaks with ease. Being able to financially support and maybe even spoil the people around me, and donating a lot more than I do now. Work not interfering with my growth, my rest, my relationships and my health.

Career

▲ 0

0 views

Manuel Moreale 1 weeks ago

Blake Watson

This week on the People and Blogs series we have an interview with Blake Watson, whose blog can be found at blakewatson.com . Tired of RSS? Read this in your browser or sign up for the newsletter . The People and Blogs series is supported by Jaga Santagostino and the other 121 members of my "One a Month" club. If you enjoy P&B, consider becoming one for as little as 1 dollar a month. Sure! I’m Blake. I live in a small city near Jackson, Mississippi, USA. I work for MRI Technologies as a frontend engineer, building bespoke web apps for NASA. Previously I worked at an ad agency as an interactive designer. I have a neuromuscular condition called spinal muscular atrophy (SMA). It's a progressive condition that causes my muscles to become weaker over time. Because of that, I use a power wheelchair and a whole host of assistive technologies big and small. I rely on caregivers for most daily activities like taking a shower, getting dressed, and eating—just to name a few. I am able to use a computer on my own. I knew from almost the first time I used one that it was going to be important in my life. I studied Business Information Systems in college as a way to take computer-related courses without all the math of computer science (which scared me at the time). When I graduated, I had a tough time finding a job making websites. I did a bit of freelance work and volunteer work to build up a portfolio, but was otherwise unemployed for several years. I finally got my foot in the door and I recently celebrated a milestone of being employed for a decade . When I'm not working, I'm probably tinkering on side projects . I'm somewhat of a side project and home-cooked app enthusiast. I just really enjoy making and using my own tools. Over the last 10 years, I've gotten into playing Dungeons and Dragons and a lot of my side projects have been related to D&D. I enjoy design, typography, strategy games, storytelling, writing, programming, gamedev, and music. I got hooked on making websites in high school and college in the early 2000s. A friend of mine in high school had a sports news website. I want to say it was made with the Homestead site builder or something similar. I started writing for it and helping with it. I couldn’t get enough so I started making my own websites using WYSIWYG page builders. But I became increasingly frustrated with the limitations of page builders. Designing sites felt clunky and I couldn’t get elements to do exactly what I wanted them to do. I had a few blogs on other services over the years. Xanga was maybe the first one. Then I had one on Blogger for a while. In 2005, I took a course called Advanced Languages 1. It turned out to be JavaScript. Learning JavaScript necessitated learning HTML. Throughout the course I became obsessed with learning HTML, CSS, and JavaScript. Eventually, in August of 2005— twenty years ago —I purchased the domain blakewatson.com . I iterated on it multiple times a year at first. It morphed from quirky design to quirkier design as I learned more CSS. It was a personal homepage, but I blogged at other services. Thanks to RSS, I could list my recent blog posts on my website. When I graduated from college, my personal website became more of a web designer's portfolio, a professional site that I would use to attract clients and describe my services. But around that time I was learning how to use WordPress and I started a self-hosted WordPress blog called I hate stairs . It was an extremely personal disability-related and life journaling type of blog that I ran for several years. When I got my first full-time position and didn't need to freelance any longer, I converted blakewatson.com back into a personal website. But this time, primarily a blog. I discontinued I hate stairs (though I maintain an archive and all the original URLs work ). I had always looked up to various web designers in the 2000s who had web development related blogs. People like Jeffery Zeldman , Andy Clarke , Jason Santa Maria , and Tina Roth Eisenberg . For the past decade, I've blogged about web design, disability, and assistive tech—with the odd random topic here or there. I used to blog only when inspiration struck me hard enough to jolt my lazy ass out of whatever else I was doing. That strategy left me writing three or four articles a year (I don’t know why, but I think of my blog posts as articles in a minor publication, and this hasn’t helped me do anything but self-edit—I need to snap out of it and just post ). In March 2023, however, I noticed that I had written an article every month so far that year. I decided to keep up the streak. And ever since then, I've posted at least one article a month on my blog. I realize that isn't very frequent for some people, but I enjoy that pacing, although I wouldn't mind producing a handful more per year. Since I'm purposefully posting more, I've started keeping a list of ideas in my notes just so I have something to look through when it's time to write. I use Obsidian mostly for that kind of thing. The writing itself almost always happens in iA Writer . This app is critical to my process because I am someone who likes to tinker with settings and fonts and pretty much anything I can configure. If I want to get actual writing done, I need constraints. iA Writer is perfect because it looks and works great by default and has very few formatting options. I think I paid $10 for this app one time ten or more years ago. That has to be the best deal I've ever gotten on anything. I usually draft in Writer and then preview it on my site locally to proofread. I have to proofread on the website, in the design where it will live. If I proofread in the editor I will miss all kinds of typos. So I pop back and forth between the browser and the editor fixing things as I go. I can no longer type on a physical keyboard. I use a mix of onscreen keyboard and dictation when writing prose. Typing is a chore and part of the reason I don’t blog more often. It usually takes me several hours to draft, proofread, and publish a post. I mostly need to be at my desk because I have my necessary assistive tech equipment set up there. I romanticize the idea of writing in a comfy nook or at a cozy coffee shop. I've tried packing up my setup and taking it to a coffee shop, but in practice I get precious little writing done that way. What I usually do to get into a good flow state is put on my AirPods Pro, turn on noise cancellation, maybe have some ambient background noise or music , and just write. Preferably while sipping coffee or soda. But if I could have any environment I wanted, I would be sitting in a small room by a window a few stories up in a quaint little building from the game Townscaper , clacking away on an old typewriter or scribbling in a journal with a Parker Jotter . I've bounced around a bit in terms of tech stack, but in 2024, I migrated from a self-hosted WordPress site to a generated static site with Eleventy . My site is hosted on NearlyFreeSpeech.NET (NFSN)—a shared hosting service I love for its simplistic homemade admin system, and powerful VPS-like capabilities. My domain is registered with them as well, although I’m letting Cloudflare handle my DNS for now. I used Eleventy for the first time in 2020 and became a huge fan. I was stoked to migrate blakewatson.com . The source code is in a private repo on GitHub. Whenever I push to the main branch, DeployHQ picks it up and deploys it to my server. I also have a somewhat convoluted setup that checks for social media posts and displays them on my website by rebuilding and deploying automatically whenever I post. It's more just a way for me to have an archive of my posts on Mastodon than anything. Because my website is so old, I have some files not in my repo that live on my server. It is somewhat of a sprawling living organism at this point, with various small apps and tools (and even games !) deployed to sub-directories. I have a weekly scheduled task that runs and saves the entire site to Backblaze B2 . You know, I'm happy to say that I'd mostly do the same thing. I think everyone should have their own website. I would still choose to blog at my own domain name. Probably still a static website. I might structure things a bit differently. If I were designing it now, I might make more allowances for title-less, short posts (technically I can do this now, but they get lumped into my social feed, which I'm calling my Microblog, and kind of get lost). I might design it to be a little weirder rather than buttoned up as it is now. And hey, it's my website. I still might do that. Tinkering with your personal website is one of life's great joys. If you can't think of anything to do with your website, here are a hundred ideas for you . I don't make money from my website directly, but having a website was critical in getting my first job and getting clients before that. So, in a way, all the money I've made working could be attributed to having a personal website. I have a lot of websites and a lot of domains, so it's a little hard to figure out exactly what blakewatson.com itself costs. NFSN is a pay-as-you-go service. I'm currently hosting 13 websites of varying sizes and complexity, and my monthly cost aside from domains is about $23.49. $5 of that is an optional support membership. I could probably get the cost down further by putting the smaller sites together on a single shared server. I pay about $14 per year for the domain these days. I pay $10.50 per month for DeployHQ , but I use it for multiple sites including a for-profit side project, so it doesn’t really cost anything to use it for my blog (this is the type of mental gymnastics I like to do). I pay $15 per month for Fathom Analytics . In my mind, this is also subsidized by my for-profit side project. I mentioned that I backup my website to Backblaze B2. It's extremely affordable, and I think I'm paying below 50 cents per month currently for the amount of storage I'm using (and that also includes several websites). If you also throw in the cost of tools like Tower and Sketch , then there's another $200 worth of costs per year. But I use those programs for many things other than my blog. When you get down to it, blogs are fairly inexpensive to run when they are small and personal like mine. I could probably get the price down to free, save for the domain name, if I wanted to use something like Cloudflare Pages to host it—or maybe a free blogging service. I don't mind people monetizing their blogs at all. I mean if it's obnoxious then I'm probably not going to stay on your website very long. But if it's done tastefully with respect to the readers then good for you. I also don't mind paying to support bloggers in some cases. I have a number of subscriptions for various people to support their writing or other creative output. Here are some blogs I'm impressed with in no particular order. Many of these people have been featured in this series before. I'd like to take this opportunity to mention Anne Sturdivant . She was interviewed here on People & Blogs. When I first discovered this series, I put her blog in the suggestion box. I was impressed with her personal website empire and the amount of content she produced. Sadly, Anne passed away earlier this year. We were internet buddies and I miss her. 💜 I'd like to share a handful of my side projects for anyone who might be interested. Now that you're done reading the interview, go check the blog and subscribe to the RSS feed . If you're looking for more content, go read one of the previous 109 interviews . Make sure to also say thank you to Bomburache and the other 121 supporters for making this series possible. Chris Coyier . " Mediocre ideas, showing up, and persistence. " <3 Jim Nielsen . Continually produces smart content. Don't know how he does it. Nicole Kinzel . She has posted nearly daily for over two years capturing human struggles and life with SMA through free verse poetry. Dave Rupert . I enjoy the balance of tech and personal stuff and the honesty of the writing. Tyler Sticka . His blog is so clean you could eat off of it. A good mix of tech and personal topics. Delightful animations. Maciej Cegłowski . Infrequent and longform. Usually interesting regardless of whether I agree or disagree. Brianna Albers . I’m cheating because this is a column and not a blog per se. But her writing reads like a blog—it's personal, contemplative, and compelling. There are so very few representations of life with SMA online that I'd be remiss not to mention her. Daring Fireball . A classic blog I’ve read for years. Good for Apple news but also interesting finds in typography and design. Robb Knight . To me, Robb’s website is the epitome of the modern indieweb homepage. It’s quirky, fun, and full of content of all kinds. And that font. :chefskiss: Katherine Yang . A relatively new blog. Beautiful site design. Katherine's site feels fresh and experimental and exudes humanity. HTML for People . I wrote this web book for anyone who is interested in learning HTML to make websites. I wrote this to be radically beginner-friendly. The focus is on what you can accomplish with HTML rather than dwelling on a lot of technical information. A Fine Start . This is the for-profit side project I mentioned. It is a new tab page replacement for your web browser. I originally made it for myself because I wanted all of my favorite links to be easily clickable from every new tab. I decided to turn it into a product. The vast majority of the features are free. You only pay if you want to automatically sync your links with other browsers and devices. Minimal Character Sheet . I mentioned enjoying Dungeons and Dragons. This is a web app for managing a D&D 5th edition character. I made it to be a freeform digital character sheet. It's similar to using a form fillable PDF, except that you have a lot more room to write. It doesn't force many particular limitations on your character since you can write whatever you want. Totally free.

HTML Career C# CSS Design

▲ 0

0 views

ava's blog 1 weeks ago

[rant] i hate email forwarding notes

You erroneously receive an email meant for someone else or another team. You forward it with the note: we received this but I think this is meant for you. Kind regards, Name” or a variation thereof. Sometimes, mails bounce around internally before responsibilities are clear, and it finally arrives in your mailbox - with 4-6 of these useless notes. “Hey Katja, look at this and maybe forward to xyz.” “Hello Ben, not for us. Maybe send to abc.” “Dear Mr. Schmidt, we received this but it’s not in our jurisdiction. Please forward to the relevant parties.” ”Dear all, we just received this, please respond to the initial query.” And I fucking hate this! Can’t we all agree to let this fossilized shit go? It makes me scroll endlessly to get to the meat of it, passing by complete corporate diarrhea in the process. I love forwarding without any of that, and you better believe there’s pearl clutching about that. I’m here to bust these bullshit excuses right now. Put your thinking cap on, read the email and deduct based on keywords why you got that email. If it is about ABC and you’re the ABC team, is it not clear what you are supposed to do? That you are supposed to treat it as if you had gotten it directly? If you had received it directly, it would also not include a handbook about your next steps! Also, if you are not CC and are directly addressed in the mail body, it already shows you are expected to react to it and handle it, and aren’t just being notified. If just notifying, I would write an FYI note, but I did not. This weaponized incompetence just an excuse to delay working on it. This is the worst lie of them all. Did you receive that email from the nether, anonymously? There is an email address attached. You know who it was! You can respond back to that address, and in my specific case, we even have a team phone number you know that you can call, and we are at best 4 people, less if on vacation or sick. Getting in contact with someone on the team or the exact person who sent it isn’t hard. Also: If there is any additional context needed or extra information I can give you, I would of course write the damn note. But I did not! Take the hint, what questions would you even ask me if this is clearly an errant email meant for you and your work, which I have zero knowledge about? Am I supposed to do your work for you or what? It’s not nice to scroll through 5 sections of this goddamn drivel to find out what the fuss is about and I feel stupid writing that note that just reaffirms what is already painfully obvious: that you are getting it because it’s your goddamn job. We are wasting each other’s time. If I read XYZ in the title and the body of the email, I don’t need you to explain to me “I send this to you because we are ABC team and you are responsible for XYZ!” Gee thanks, I almost forgot! Same in the other direction. We receive this comment from this working group, now I am supposed to forward it saying “here’s the comment by the working group for you!” just echoing the original email content I am forwarding. It adds absolutely nothing new. At least, if you really have to do your own little forwarding note dance for your peace of mind, delete the previous notes . If in the specific case of needing to preserve the path this took so we all know what teams already received it and passed it on so we don’t send them that again, you can include a quick summary of that in there too - at least that would make it useful then. Deleting all that and just go “forwarding this to you because I think you’re responsible for this; teams A, B, and C previously received it but weren’t the correct recipient.” There you go! I am so tired of the email etiquette of yesteryear. Rules like these are seemingly set in stone for no good reason by the same generation who will unironically write “……….” after every sentence. Get a grip and do your job and stop trying to nitpick to waste time and pretend you got nothing to work with or are absolutely clueless about what “receiving an email” means. Reply via email Published 02 Oct, 2025

Business Career AI

▲ 0

4 views

Justin Duke 1 weeks ago

September, 2025

The last of summer's grip finally loosened its hold this September, and Richmond began its annual transformation into something gentler and more contemplative. This morning's walk with Telly required a dusting-off of the closet-buried Patagonia puffer jacket; it's perfect for walks with Lucy, who has graduated into the Big Kid stroller making it easier than ever for her to point at every dog ("dah!"), every bird (also "dah!"), every passing leaf that dared to flutter in her line of sight. As you will read below, the big corporate milestone for me this month was sponsoring Djangocon and having our first offsite over the course of a single week. Sadly, our Seattle trip was once again canceled. Haley and Lucy both got a little sick, and we had to abandon course. It's weird to think this will be the first year since 2011 that we have not stepped foot in the Pacific Northwest. More than anything though, I learned this month for the first time how impossibly difficult it is to be away from your daughter for six days. It is something I hope I have to go through again for a very long time.

Business Dart Django Career

▲ 0

1 views

Chaotic-Good Engineering Management 1 weeks ago

Am I solving the problem or just coping with it?

Solving problems and putting in processes that eliminate them is a core part of the job of a manager. Knowing ahead of time whether or not your solution is going to work can be tricky, and time pressures and the urgency that pervades startups can make quick solutions seem really attractive. However, those are often a trap that papers over the real issue enough to look like it’s solved, only to have it come roaring back worse later. If you’ve been around the world of incident response and the subsequent activity of retrospectives/post-mortems, you’ve probably heard of the “ 5 whys ” method of root-cause analysis. In the world of complex systems, attributing failures to a single root cause has fallen out of favour and 5 whys has gone with it. Nevertheless, there is value in digging deeper than what initially presents itself as the challenge to uncover deeper, more systemic issues that might be contributing factors. Rather than “why,” I like to ask myself if I’m really solving this dysfunction or just coping with it. There’s a lot of temptation to cope. Coping strategies have some features that make them attractive. Imagine your problem is that your team is “always behind schedule.” That’s a problem I’m sure most people are familiar with. There are plenty of easy-to-grab band-aid strategies for that pattern that are very attractive: All of these can make you feel like you’re solving the problem but: This dichotomy is probably more familiar and easy to recognize in the technical realm. If your code has a memory leak you can either proactively restart it every now and then (coping) or you can find the leak and fix it (actual solution). The reasons you should prefer the actual solution are the same in both scenarios. The 'strategy' of restarting the service will work for a while, but you know in the back of your mind that eventually it’s going to manage to crash itself between restarts. Same goes for your people processes. At one of my jobs we had a fairly chaotic release process. This was a while ago and “ Continuous Delivery r” was still a fairly newfangled idea that wasn’t widely adopted, so we did what most companies did and released on a schedule. It was a SaaS product, so releasing was really just pushing a batch of changes to production. The changes had ostensibly been tested (we still had human QA people then) and everything looked good, but nevertheless nearly every release had some catastrophic issues that needed immediate hotfixes. We didn’t have set working hours, except on release day. We expected all of the developers to be in the office when the code went out in case they were needed for fixes. We released around 9am and firefighting often continued throughout the morning and into the afternoon. When that happened, the office manager would usually order some pizzas so people could have something to eat while fixing prod. Eventually this happened so often that it just became routine. Release day meant lunch was proactively ordered in for the dev team, then chaos ensued and was fixed. Of course, we did eventually tackle the real pain points by increasing the frequency of releases (when something hurts, do it more, it’ll give you incentives to fix the real problems), adding more automated testing, and generally just getting better at it all. The lunches continued well past the point where the majority of the people on the team remembered or ever knew why they were there. Some other practical questions you can ask yourself to try to recognize stopgap strategies that aren’t addressing the real problems. As mentioned before, anything that stops working when you stop doing it is likely not a good solution. If you’ve got a system where someone has to push the “don’t crash production” button every day or else production crashes, eventually someone’s going to fail to push the button and production is going to crash. The button is not a solution; it’s a coping strategy. If you’re having a lot of off-hours incidents and your incident response team is complaining about the burden, you could train more people in incident response to reduce their burden (and maybe you should), but that’s not solving the problem, which is really that you’re having too many incidents. A true solution would be understanding why and addressing that. Code not sufficiently tested? Production infra not sized appropriately? Who knows, but the answer is not simply throwing more bodies at it. That will reduce the acute problem of burnout in your responders (symptom) but not the chronic issues that are causing the incidents in the first place. If you’re not changing the underlying conditions you’re probably not fixing the problem. If all your meetings are running over time you could appoint someone to act as the timing police and give warnings and scold people who talk too long, but that’s just adding work for someone and not touching the real reasons, which could be unclear agendas, poor facilitation, or the fact that the VP can’t manage to stay on topic for any amount of time. The solution is to fix your meeting culture. Require agendas, limit the number of topics, train people on facilitation, give some candid feedback to the VP. These solutions actually remove the failure mode that causes meetings to run long. The timekeeper “strategy” doesn’t do anything about that. This is similar to the first question, but it’s something you can think of like a metric, even though it’s probably more a heuristic than something directly measurable. Treating your releases like pre-scheduled incidents like we did would be a good warning sign that you’re coping, but if each one is less dramatic than the last and wraps up sooner, those are signs that you’re on the right track. Getting to the point where releases are unremarkable and you don’t need the whole team on standby would be a good indicator that you’ve got solid solutions in place. When production is down, anything you can do to get it back up again is the right move. If you’re bleeding and you have to make a tourniquet with your own shirt, you do it. There are lots of scenarios where a short-term fix is the best thing for the situation. But keep in mind, this is effectively debt . Like technical debt, it should be repaid — ideally sooner rather than later. A good incident process will recover production by any means necessary. Once, during an incident related to a global DNS provider’s outage, we were literally uploading /etc/hosts files to our infrastructure to keep the part of our product that relied on some 3rd parties working. Needless to say, once the DNS incident was resolved, we went back and cleaned those up. You can do the same with processes. When there’s immediate pain that can be relieved with a quick patch-up, you should do it, and use the fact that the pain has abated to fix the problem permanently. You also can’t fix them all. You might not have enough influence or political capital to make the kinds of changes that real solutions require. In that case, your job is to advocate for the right things to happen, point out the ways that coping is hurting the organization, and exert influence over the parts that are in your control. I’ve tried to give you some strategies for recognizing when you’re just coping with a situation rather than fixing it. The differences can be subtle, but once you start to spot them it gets easier and you’ll find things start to get better in more permanent, sustainable ways. " Temporary Fix " by reader of the pack is licensed under CC BY-ND 2.0 . Like this? Please feel free to share it on your favourite social media or link site! Share it with friends! Hit subscribe to get new posts delivered to your inbox automatically. Feedback? Get in touch ! They can be contained within your team ; you don’t need to influence people outside your sphere. (We’ll just work through the weekend and get the project back on track.) They’re highly visible. (Look at Jason’s team putting in the extra effort! What a good manager!) They can move vanity metrics in the short term, which is often something rewarded. (We increased our velocity and did 20% more story points!) They come with a cost . (The team will burn out and quit if they have to work through too many weekends.) If you stop doing them, the situation comes right back . (The next project wasn’t different and we’re back behind schedule again.) They only address the symptoms , not the causes. (Improving your culture around estimations and deadlines would be a better fix.)

Business DevOps Career

▲ 0

0 views

Kix Panganiban 1 weeks ago

Re: Comprehension Debt

I recently wrote about how LLMs can make you lose grip of your codebase by eroding the mental model you built by writing code yourself. A buddy of mine shared this post with me, and I think it's the most clear and succinct description of this phenomenon -- and Jason Gorman, the author, calls it "comprehension debt". It’s pretty much guaranteed that there will be many times when we have to edit the code ourselves. The “comprehension debt” is the extra time it’s going to take us to understand it first.

Programming Career AI

▲ 0

0 views

alikhil 2 weeks ago

The Simple Habit That Saves My Evenings

As a software engineer, I often work on big tasks that require hours of continuous and focused work. However, we have plenty of meetings, colleagues asking us something in Slack, and lunch breaks. Add a colleague who comes to you and calls you for a cup of coffee if you work from the office. And usually, we don’t really have such a luxury as hours of uninterrupted time. Nevertheless, sometimes we catch the flow of productive and focused work at the end of the workday. Imagine you come up with an elegant solution to a problem you’ve been tackling all day, or maybe even the whole past week. You can’t wait to implement and test your solution. And of course, you are so driven by your idea that you decide to continue working despite your working day being over. “20 minutes more and I will finish it,” you think. Obviously, this is not the case; some edge cases and new issues will inevitably arise. You come to your senses only 2–3 hours later—tired, hungry, demotivated, and still struggling with your problem. You just wasted your evening, with nothing to show for it. Worse, you overworked and didn’t recover that night. Thus, you were already exhausted when you started working. You can imagine what will follow next. Nothing good, really. I remember this happening back when I worked at a fast-growing startup, KazanExpress, while living in Innopolis . Our office was buzzing with energy, and the pace was intense—we often pushed ourselves late into the night. One evening, I felt like I had finally cracked a tricky part of our infrastructure. I thought, “Just 20 more minutes and I’ll finish it.” Of course, those 20 minutes stretched into well over three hours. By the time I left the office, I was tired, hungry, and frustrated—without any real progress to show. The next morning, walking back to the office, I realized how drained I already felt before even starting work. That was when it became clear to me: it’s better to stop, write down the next steps, and come back with a fresh head. Of course, some might argue, “But you are considering only a negative scenario; one could really finish that job in 20 minutes and go home happy…”. Sure, but I think this risk is not worth it. Instead, I would suggest doing another thing. Rather than trying to complete your task in 20 minutes, take this time to write down your thoughts, and a step-by-step action plan of what you think you need to do to finish your task. Then go home. Rest. A feeling of incompleteness will motivate you to come back and finalize your work the next day. Only you will be full of energy, together with a settled plan. No doubt you’ll accomplish your task before lunch. Writing down the next steps helps to clear your mind after a workday. You write and forget about your work until the next morning. As a bonus, there is a chance that new, better ideas will come while you sleep or rest. I have been using this trick for more than 5 years now, and it helps me to keep my work and life balanced. Here are the two main ideas of it: Don’t overwork Write down the next steps before finishing your workday

Career Programming

▲ 0

0 views

Weakty 2 weeks ago

Our efforts, in part, define us

What happens when something we enjoy doing that took effort becomes effortless? And what happens if that original effort was a foundation on which we saw value in ourselves? If our efforts, in part, define us, then our efforts have intrinsic value. Our efforts may help us understand a position we want to occupy, an identity we carry, or an outlook we present. This value contributes to an internal economy of joy, self-respect, fulfillment, happiness. When effortful things become effortless, what becomes of our position in these economies? As you can see, I have a few questions here. I know someone who spent a part of their adult life taking beautiful photographs, developing them by hand, framing them, cataloging them. Along came the ubiquity of digital cameras and smartphones, and "film" became infinitely available. Offhandedly, one day, this person mentioned that with the proliferation of smart phone cameras, and the ease with which one can take photos, they had found that some days their desire to continue was diminishing, and their work had lost meaning. Technology has a history of making effortful things effortless, and there is sometimes a hidden loss in that advancement. I figure people are continually being left behind in a similar manner day-to-day. Technology continues advancing (for the most part), and more things that remain effortful will become effortless. And "we" (ie, the populations who can afford to sit around and have crises of identity on these topics) will be further pushed to re-evaluate certain parts of our definitions of self. For myself, in the last 10 years, my work of writing code has largely defined what I do with my working time. Now I experience large swaths of that work being created and done by AI (sometimes amazingly well, sometimes poorly), and I find myself thinking of the photographer above. It's not my wish that people can't have access to a more effortless way to write code, but I feel a strange sadness that there is less left to the act of the craft. I have had this note in a draft state for several weeks now because I still can’t quite come to terms with how I’m feeling about things. There are so many nuances and unclear thoughts rolling around in my head about this shift. I think the only thing that is vaguely clear is that none of this would matter if making money wasn’t at play. If I was just writing code, (or taking film photographs) for fun in my free time because I enjoyed it, well, I don’t think I’d be feeling so conflicted. Being paid to work and presenting my capacities through my craft is an exchange that I have been able to derive value from in its effortful-ness. Often times I've worked on utterly boring tasks that I would have loved to have a tool that could automate. But I didn't. And even in those menial moments I did derive some pleasure in my capacities. Of course, when it came to the real challenges, that was where I felt a pleasure and value in putting forth effort. As a consultant, I work in a lot of different places, often for brief stints of time. And at many of these places, I see a large push, top-down, to encourage people to use AI. These employees, previously having entered an employment agreement where their capacities and experience would be exchanged for money, are now being asked that their abilities be augmented. In this way, the level continues to skew toward privileging production, often without understanding and people using their own perspectives. When I see sentiments similar to mine, I often see reactions where people say that AI is simply a tool and that you must learn to use it and incorporate it into your toolbox. That's fine. That's well and good. But all I'm trying to say here is that I feel a lack and a loss for something. I don't understand it yet. The title of this post, our efforts, in part, define us , is just a phrase that popped into my head. I'm not really sure if I even believe it or if I've fully fleshed out this single statement. But some part of it rings true to me. I wonder what will happen to us and our efforts. Will we be driven into further niches that are effortful, that we can derive value from? Will we become vague blobs that are formless, ill-defined, and despondent? All of this presupposes a few things —that one can (and/or should ) aim to derive value from work, that a meaningful identity is constructed by doing effortful things, that people generally are happier when they can use their skills and experiences to make something. And what’s more, there is a fine-line here between glorifying people with experience deriving value, and sounding like a shitty gatekeeper. I will continue working for various clients. I suspect I will continue hearing leadership push AI on employees. And I will continue observing how people respond to this. Of course, for many people a job is just a job , as they say, and they'll do whatever they can to get it done more quickly (or work several jobs at once). Those very same people might find more value from their efforts now that AI is making their jobs easier. They can turn to better supporting their family, following other interests outside of work, finding other meaningful things, etc. But at this time, I don't really see how this won’t further trample people’s spirits in the realm of work, unless we also reshape our expectations of work itself. Is it worth the effort?

AI Career

▲ 0

0 views

A Smart Bear 2 weeks ago

When being an "expert" is harmful

Expertise hinders learning. Learn from these examples, so that you leverage your expertise, but aren't blinded by it. Insights come from curiosity, not certainty.

Career

▲ 0

0 views