Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Eliran Turgeman
A friend asked me for some study/productivity tips, and I figured the most productive thing I can do is write a post about it. That way, it might help more people too. So here we go. Before we start, there are two things you need before any productivity advice will work: Be introspective. Be honest with yourself. My productivity rules Plan your day the night before Don’t leave decisions for your foggy, maybe lazy, morning self. Here’s the loop: wake up → review study plan → study → write down the plan for tomorrow → sleep → repeat. Check your energy during the day If you just ate and feel sleepy, don’t force deep study. Take a 30–60 minute break - nap, walk, exercise, or scroll your phone a bit, then come back refreshed. You can also take micro-breaks: finish a chapter, grab water or a piece of chocolate, and get back to it within five minutes. Don’t lie to yourself about effort Setting goals is great, but be honest about how hard you actually worked. You can check all the boxes, feel proud, and still know deep down that you took it easy. That’s fine sometimes, we all need rest days - but don’t confuse that with an intense study session. Review your day When you plan tomorrow’s tasks, reflect on today. Did you actually do what you set out to do? If not, why? Maybe your goal was too ambitious, or maybe you just spent too much time gaming. Either way, learn from it. There’s always room to improve, if the goal really matters to you. Limit distractions Put your phone on silent and out of reach. If you study on your computer, close anything that might tempt you, and even hide shortcuts to distracting apps. When I was in uni, I played a ton of League of Legends. The desktop icon was staring at me every time I opened my laptop — so I buried it under three folders. Sounds dumb, but it worked. A few more things Get good at breaking big goals into small tasks. If your goal is to pass an exam, start by mapping out all the smaller steps that’ll get you there. Spread them out over time, with a bit of buffer. Plans will change — that’s fine — but you should always know where you stand and adjust as you go. And one more time, because it’s that important: don’t lie to yourself. If you spent four hours on TikTok, felt bad, then studied a little to compensate — that’s not a “productive” day. Call it what it is. It’s okay to have those days, you’re human — just plan for them instead of pretending they didn’t happen. I believe that much of the productivity advice online includes some stupid ceremonies and whatnot, just do what you feel works for you. I think the ability to introspect, being honest with yourself and improving over time is all that matters. Take whatever breaks you need, in whatever order you want. You don’t need a fancy journal to write your tasks, open a txt file. You don’t need a perfect system, just something simple that works for you.
Most people solve their subscription fatigue by canceling Netflix. I solved it by vibe-coding my own workout app instead of paying another SaaS. Two weeks ago, I decided to get serious about my workouts again and start logging them. I looked for an existing solution that has the following: create workouts log sets, reps, and weights a calendar to track consistency simple enough. Free apps were crammed with ads. Paid apps had bloated features I didn’t want. Both annoyed me. Before vibe-coding, I’d either tolerate ads or pay. Now there’s a third option - build my own. Of course, you could always build your own, but pre-vibe-coding it would take much more time to be worth it. How did I choose the vibe coding platform? I logged into loveable, base44, bolt, and wrote the following (imperfect) prompt 1 2 3 4 5 6 7 I want to create a personal webapp for managing my own workout routines (kind of a workout logger) I want to be able to define "workouts" - collection of exercises including sets and reps I want to be able to track which workout i did on which day - calendar view I want to be able to log the weights I did for every exercise in every set. I want my workout templates to be a simple collection of exercises that are plaintext - don't create some kind of an exercise library.. i just want to type the exercise name myself make it stateful, including a db connection to store all the relevant data. Whichever tool gave me the best first shot, I ran with. This time it was Loveable. Iterating With that one-shot starting point from loveable, I published it, and went to my first workout at the gym, all excited and ready to use what I built. First workout: I needed notes for exercises. Another: supersets. Each time I wrote it down, went home, and 15 minutes later I published a new version with loveable. After two weeks of using this app at the gym and doing tweaks, the app feels solid. On my last iteration, I added a badges/achievement page, and a github-like consistency widget that looks cool I hope will help me stay on track and be consistent. Sharing Friends wanted to try it too - the problem? I didn’t make it secured by sign-in, I thought I only need it for myself, and even if someone’s going to find this weird loveable URL, they could only see my workouts - who cares… But of course for my friends I’ll write one more prompt - and so I added Supabase auth within minutes. Final Thoughts This post isn’t about showing off my little workout logger anyone could make in a few hours prompting. It’s about how easy it is today to scratch your own itch. You build the exact features you need, when you need them. No ads, no bloat, no adapting to someone else’s UX. Just something comfortable and fun to use. It’s never been easier to bring your ideas to life, small or big.
If there’s one pattern I’ve seen across multiple companies, from scrappy startups to big corps, that causes endless headaches, it’s this: a single cache cluster shared across services. I recently shortly wrote about my lessons from building and maintaining distributed systems at scale, and the first point that came to mind is exactly this - it starts with an excuse of simplicity, “we already have a cache cluster up and running, let’s just make this other service use it, no need for more infra”, and ends with a confused on-call engineer trying to debug which services were affected by the last keys eviction. So I want to double down on this idea and explain in more detail why it becomes a nightmare once your system scales. One eviction policy You got different services each throwing keys at the same redis cluster. A sudden spike/bug just caused a dramatic increase in cache writes - your cluster wasn’t ready for this, it hits maxmemory and now different keys are being removed based on your eviction policy. What’s the problem? there’s no isolation - service A caused the max memory, and now service B, C, D also pay the price - their keys are being removed as well from the cluster, and could affect the latency, and correctness of other flows of your system. Monitoring is harder Our metric fires up — we see a drop in hit rate on the cluster. Which service is causing it? Who’s affected? Instead of thinking about one service, you’re now mentally juggling everything across the entire system. More noise, less clarity. Although monitoring is harder, you could set up application monitors that you send once you write/read from the cache, based on the prefix of the key. potentially if you are organized and each service that uses the cluster has a unique prefix and you can easily identify between the hit rates of different prefixes - that’s great, but you have to work to get there. Debugging is harder This ties back to my first point about the eviction policy. You had 10m keys. something happend. now you got 5m. The effect on the services is really hard to trace. One service might have lost 100k keys, and you barely see a difference in its monitors, but it doesn’t mean your users are not feeling something is off, maybe today the are waiting a bit more for the page to load, but it’s not too long to hit your monitors thresholds. In that case, if you didn’t have a monitor on the cache cluster for keys eviction, you might be totally blind..”oh I see a slight latency increase here, but no monitors popped - guess all is well” So, never use a shared cache cluster? No, that’s not the lesson here. In some cases it is totally fine to use a single cache cluster. For example: You don’t really have a lot of traffic read/written to the cache so most of it is free anyway You store shared static data (for example, feature flags) Also note that some of the points I was making here against using a single cache cluster, can be somewhat mitigated by having good monitoring set in place. For example, having a defined prefix for the cache key per use-case, per service, and publishing metrics in the application level so we have observability to which type of keys (by prefix) are experiecning a low hit ratio. But on the other hand, tracking keys eviction is harder to monitor, since it’s not initiated by your system. Anyway, I hope you get the point. If you are getting started, a single cache cluster is totally fine. Otherwise, spin up another cache cluster, and sleep better at night. 🚨 Become a better software engineer. practice building real systems, get code reviews, and mentorship from senior engineers. Get started with 404skill
when i was a student, everything was simpler. grind leetcode. build projects. get an offer. i knew the salaries. i knew what “winning” looked like. it was a somewhat straight line from broke student to backend engineer at a top company. and i did it, i 10x my life in the span of 4 years. five years in. and honestly? it’s… fine. it’s more than fine. but it also feels like i’m stuck on a plateau. the growth feels logarithmic. the peak that isn’t the peak things are good, but i can’t stop feeling like i want more, even though i am comfortable. i look back at the student version of me, and i see hunger. direction. i look at me now and i see someone who’s tried a bunch of things: built products that barely anyone used started a newsletter, got some nice traffic, but it didn’t stick thinking about podcasts, courses, maybe a dev agency? dreaming of 10x-ing my life again, but not sure where to invest my time. when i was younger, the path was obvious. now it’s all vague, i could do anything. do i go all-in on indie hacking? live off my rsu’s for a few years and just build? try again with another product? double down on the blog? start a podcast? well, the next level doesn’t seem to come with an instructions book. escaping means risking the fall as a cs student you learn that escaping a local maxima usually means exploring a few downs to find a higher maxima. well, applying it to life is scary. what if i lose everything i worked hard to build? i am no longer a student living off of scholarships, i have more obligations. and also, the scariest part of all is what if this is the best it gets? i prefer to be positive and believe there’s another jump out there. something worth building. something that might actually shift my trajectory again. i just haven’t found it yet. but i’m looking. 🚨 Become a better software engineer. practice building real systems, get code reviews, and mentorship from senior engineers. Get started with 404skill
I recently wrote about over-engineering and striking a good balance between making your code “too” future-proof and not making it future-proof at all. Some time later, I realized it was missing a critical perspective. I hadn’t addressed over-engineering from an architectural point of view, so this post is dedicated precisely to that. Let’s talk about a decision I made for Collecto, my side project. Collecto is still in its early stages, and like most early-stage projects, its future is uncertain. It could grow into something big—or not. That’s where architectural decisions get tricky. You don’t want to overengineer and waste time, but you also don’t want to under-engineer and regret not laying a solid foundation. So what’s the problem? Collecto is a forms-backend service, meaning it handles the creation, management, and processing of forms data for applications. I wanted to add the ability to send emails on certain events. For example, when a new user signs up for your form, you might want to send them a welcome email. The simplest solution? I could write a new service responsible for sending emails and call it directly wherever needed— for example, right after a user signup is saved to the database. This approach works, is easy to set up, and introduces no additional overhead. However, it results in tight coupling, making future changes more challenging. If tomorrow I want to also send a notification to the form owner when they receive a new subscription, I would have to keep adding more responsibilities to the form service code. This bloats the core service, which should ideally focus solely on CRUD operations for forms. On the other end of the spectrum, I could go all-in and build a distributed pub/sub system with a service bus like RabbitMQ or Azure Service Bus. This would give me scalability, decoupling, and all the good stuff. But it’s also a massive investment in time and complexity for a project that doesn’t need it, yet. I didn’t like both options, so I looked for a 3rd alternative and found MediatR which is a mediator pattern implementation in .NET. Why MediatR is a good middle-ground? MediatR facilitates communication between different parts of the application without them needing to reference each other directly. Instead of invoking methods directly, you can send requests or publish notifications, allowing registered handlers to respond accordingly. This approach maintains loose coupling, making the system easier to maintain and evolve. At the same time, it doesn’t introduce the overhead of managing infrastructure like a service bus or message queue. Everything stays in-process, simple, and fast. One of the primary reasons I chose MediatR is its simplicity. Implementing communication patterns with MediatR is straightforward and requires minimal configuration. Compared to a full-fledged service bus, MediatR demands a much smaller time investment and eliminates operational overhead such as monitoring queues or scaling message brokers. It can’t be all sunshines and rainbows MediatR has a few cons compared to other out-of-process messaging brokers, for example Events are in-process only. If your application crashes, you lose the events. There’s no out of the box retry mechanism for failed event handlers. If you deploy multiple instances of Collecto, MediatR won’t distribute events across them. Bottom line Architecture isn’t about perfection—it’s about trade-offs. MediatR worked for Collecto because it gave me a decoupled, flexible way to handle events without the overhead of a service bus. It wasn’t the simplest solution, but it was the right one for where the project is today. The next time you’re making an architectural decision, remember this: the best solution isn’t the most impressive or complex—it’s the one that solves your problem now while leaving room for growth later. 🚨 Become a better software engineer. practice building real systems, get code reviews, and mentorship from senior engineers. Get started with 404skill
More in programming
The Tetris effect is one of psychology’s most easy to reproduce experiments. Simply spend a bit of time playing the eponymous game every day for a few weeks. After a little while, you’ll start recognizing familiar Tetromino shapes in clouds, buildings, and everyday objects. You might even see them appear before your eyes when you start falling asleep. Tom Tang Attention hijacking There’s one lesson the Tetris effect teaches us: whatever you focus on long enough will end up shaping your thoughts. This can be a good thing since it’s how we learn new skills and discover new ideas. Sadly, less and less of our attention is focused intentionally. Instead of picking what we want to see we let other people decide what is supposed to be good for us. Do you want to watch a video? YouTube knows you like cooking and art streams. But why not also recommend a few clips about the stock market bubble, global warming, and the war in Iran. Doomscrolling will make you stay longer and click on a few more ads. Do you want to listen to music? Just open a Spotify playlist and let the algorithm figure out what you like. Please ignore the AI slop they will insert in between real songs to avoid paying royalties to real artists. Do you want to know how your colleagues are doing? Too bad, LinkedIn will bury any relevant career news between the opinion of complete strangers. It is surely just a coincidence that those strangers happen to be shilling whatever Microsoft is invested in at the moment. Do you want the opinion of strangers on a product? Well those Redditors you wanted to ask are probably just a bunch of LLMs talking to a bunch of Russian trolls now. I hope you didn’t value their opinion too much. If, like me and most people, you spend the major part of your day focused on your device, there’s no doubt it’s affecting you. And when you let someone else dictate what appears on your screen, it’s the same as giving them the key to your brain. New York Said Back to an intentional internet The internet wasn’t always like that. Before recommendation algorithms where a thing, you had to decide what you would be doing on the computer. You didn’t really have one big app that you could open and order it to entertain you. Instead, you had a few dozen of bookmarks to websites, each with a specific idea in mind. A site for video game news, that one website with lots of tutorials, a blog about anime that didn’t update often enough, a wiki about a TV show from the 90s… Of course awful things existed on the web. We had Encyclopedia Dramatica and Rotten.com, but you actually had to put the effort to go there if you wanted. Nobody was going to put pictures of dead kids and far-right propaganda as a suggestion after a pancake recipe or a cat video. The good thing is that this intentional internet is still around. It has just been a bit buried below the corporate web, but it’s not very hard to find. After all you’re on this blog, so you probably already have a good idea about it. The main difference between this time and now is you. When you want to get back to reading blogs, RSS feeds, and finish that tutorial instead of doomscrolling shorts, you have to get used to a slower internet. One where content is not infinite and doesn’t get updated every click. But like every habit, the only thing you have to do is to keep at it. And if you pay enough attention to it, something will click in your brain.
One of the interesting challenges of the AI ecosystem in 2026 is that new, effective patterns emerge faster than I can adopt them. I’ll find a handful, get back to work, and realize a month later that I’d missed four or five more. The adoption cycle for Imprint this year has been something like: January: get every engineer onto Claude Code every single day March: ok, let’s also get everyone else onto Claude Code or Claude Cowork every single day April: local development is bottlenecked on checkout and worktree model, instead create ~10 local workspaces which each have an independent checkout of every repository, and operate at the workspace level, not at the repository level, so it can generate cross-repository pull requests across frontend, backend, infrastructure and data monorepos June: oh boy, agent-driven development is heavily constrained by lack of a common task management system with higher visibility and less permission complexity than Jira, so let’s migrate the entire company over to Linear and hard stop on Jira July: yikes, now we have visibility into all these tickets, many of them are trivial but managing them through local development isn’t scaling, let’s roll out an orchestrated harness which internally we call “Agent Fleet”, along the lines of Stripe’s Minions The most recent question for me has been figuring out how to adopt the software factory pattern. (After some light research, the specific AI-context origin of this term is slightly messy to attribute, but I think it might be Justin McCarthy in February 2026’s Software Factories And The Agentic Moment.) The software factory pattern is looping on a broad goal, and then relying on the harness to drive progress towards that goal. Our first pass at implementation is fairly basic: An agent skill /linear-project-loop which reads in a Linear project and starts by auditing that project’s goal definition on these dimensions: An RFC in Notion that describes the project’s goals, how those goals are measured, and the general approach A Datadog dashboard or Snowflake queries that measure progress against those goals If those are missing, or the Linear project is missing in its entirety, it iterates with you on creating those missing tools. Then it reviews the state of the metrics and issues for the project. If new work is identified, it adds those issues to the project. It updates the state of issues that have moved. It works on the non-blocked tasks based on the project’s current state. This is often writing a pull request, updating a pull request, pinging for review, asking a clarifying question, etc. When a task completes, if the project description is fresh, it takes on the next task. If the description hasn’t been updated in a while, it reruns the loop starting with the first step. Right now I am running this locally in a local harness, but it’s working well enough that I anticipate moving the behavior to be driven by the same orchestrated harness that we assign one-off tasks to. What I particularly like about the factory pattern is that it parallels very closely how I’ve been working locally, while forcing me to recognize the places where I was accidentally hording parts of the state for myself regarding the goals of the project. I was already asking agents to iterate on specific Linear projects, but they didn’t have the ability to evaluate if they were going in the right direction, or if it was missing necessary tasks. Now it does. The other place this has been extremely helpful for me is checking in on projects post release. For example, I shipped our passkeys implementation earlier this year, but some months go by without my checking in on how it’s going. If we saw adoption spike, or error rates start to turn, I might miss it, but running the factory in a less frequent post-release mode would catch it immediately. The final thought that’s been interesting to me is how much all of the pieces here compound only to the extent that you have the other pieces. For example, this factory pattern depends on having Datadog MCP and Snowflake access available to manage goal-tracking, but it also depends on Linear being the single source of state for the company’s work, and an orchestrated harness that can perform work independently from your laptop. Keeping up with this many migrations is a fascinating industry moment.
I owe a lot of my professional identity and success to CSS-Tricks. CSS-Tricks repeatedly gave me the opportunity to write for them. In doing so, they helped to both socialize and normalize accessibility as a mainstream frontend concern. I’m deeply thankful to them for this. The team was also a joy to work with, notably Geoff Graham. He’s a mensch, and one of the nicest people you can interact with in the frontend web space. If you have not been following the news about the site, Kevin Powell has a good video about the whole situation: Content skipped. I’m not speaking on behalf of Geoff, Chris, or others involved with running the current version of CSS-Tricks. I’ve got skin in the game as an author. This is my personal opinion, born of my feelings and beliefs. I think a lot of the web’s infrastructure should be co-ops, and CSS-Tricks is knowledge infrastructure. To that point, I should also point out that the website covers far more than just CSS. The corporate model of ownership can be a risk. If infrastructure is not part of a corporation’s core strategy, it is not a priority. As Kevin’s video touched on, it seems like promotion via owning the frontend content space isn’t part of Digital Ocean’s strategy anymore. It is not that CSS-Tricks does not have value. It is that Digital Ocean cannot see it. It is deeply, tragically ironic to me that Digital Ocean allowed this to transpire. This is because I know for a fact that the techniques and philosophies shared by CSS-Trick authors helped to shape iterations of their product’s UI. Some may be quick to point out that this knowledge now—illegally—exists inside of LLM training data, so the risk of the website going away is mitigated. To this, know that we should be striving to keep resources like CSS-Tricks going. Human creativity is the force that creates new techniques, strategies, and technologies. The web will calcify without voices sharing what they know, forever locking us into endless permutations of a fixed point in time. Unlike corporations, co-ops don’t have to be motivated by profit. By not needing to prioritize growth at all costs it means co-ops can instead prioritize and incentivise things like preservation and cultivation. It is also a successful model of operation, one that even already exists, and flourishes in the tech space. Collective ownership can also serve as checks and balances for, and protection against hierarchical decision-making. I only need to point to the chaotic and aberrant decisions many CEOs in the technology space have been making as of late to demonstrate the value of this approach. Paddy Srinivasan, if you somehow wind up reading this: Save some face and take a big swing. Give CSS-Tricks back to the people who love it.
How can something that “just works” be so annoying? situation We live in Cambridge off a little road down a drive in shared ownership between us and our neighbouring houses. All the utilities are buried under this drive, including the phone line. anticipation Over the last few years we have been canvassed repeatedly by CityFibre saying that they can deliver fibre all way to our house. I saw them digging trenches and leaving tails of purple fibre cladding along nearby roads, ready to hook up all the houses. I thought they would need to do something similar to deliver fibre to us. So when they turned up and knocked on our door, I talked to their salesbods and walked them up and down the drive and pointed out where the existing BT line goes. Then they gave up trying to sell to us. This happened about three times. disaffection We were not eager enough for an upgrade to deal with these impediments. notification A few months ago we were told that CityFibre would soon come and do the upgrade, since there’s a nationwide deadline for turning off the copper phone network at the end of the year. We expected that this would force them to actually plan some digging works, so we talked to our neighbours about it. We were all ready for some huge faff to follow the next visit by the CityFibre bods. installation CityFibre turned up on the promised morning bright and early. To our enormous surprise, a brown fibre housing was already poking out of the ground next to our copper phone line. It had been fed through 50 metres of 5cm duct without us being aware they were even working on the street. Within a couple of hours, the technicians had drilled through our wall, installed the ONT, blown fibre through the unexpected pipe, plugged in the CPE (superficially identical to the old one), and left telling us to anticipate that it might not work properly until tomorrow. activation Around lunch time, the copper phone line stopped working completely. Some faff ensued, switching all our devices over to the new WiFi network. For a while we thought this was the death of our land line, but in the course of debugging other issues, I realised that the router has a built-in VoIP adapter (I don’t think we were told it has a built-in VoIP adapter) so I plugged the phone in and it Just Worked: they had ported our phone number across and everything. Flawless. I was seriously impressed. rumination It has been a few weeks since the switchover, and apart from a couple of horrible Clown-afflicted IoT devices, it has been fairly smooth. What prompted me to write this up was realising that we delayed this upgrade for years because the sales people were not given enough technical information about how the installation process works: the fact that houses typically have a 5cm duct containing the copper lines (probably standard for the last 40 years) and the fact that fibre can be shoved through a few tens of metres without difficulty. And worse, the sales people didn’t have an esclation path for difficult cases: they just gave up instead. From a technical point of view, the installation was impeccable. (I guess the loose 24 hour window for the cutover time was because OpenReach and CityFibre don’t have tight requirements on ISP reconfiguration schedules.) From the sales point of view, it was crap. Maybe it would have gone faster if we offered to switch early without asking if the drive would be a problem? But I guess the difference between “yes!” and “yes, but will this be a problem?” is too much to expect from a minimum-wage door-to-door salesbod whose employer didn’t give them enough information or any escalation path.
