6 ms·

Developer's block

200 points by todsacerdoti 1y ago

dgan 1y ago
Rolled my eyes on "For experts only: don't do it yet". Shut-up already. I will do it right now because it will nag me forever and then surface will grow, and every time the new code interacts whith what-could-ve-been-optimized I will spend 5min thinking if I should already optimize it
- glynnormington 1y ago
  If there's a definite performance problem and a simple solution, then sure, go ahead. But applying every optimisation that comes to mind can produce a dog's breakfast of unmaintainable code and then when a real performance problem comes along, it can be really hard to fix.
- ashwinsundar 1y ago
  This is like the #1 cause of spaghetti, unmaintanable, deadlocked codebases - a single developer who knows every “best-practice” and optimization technique, and will not hesitate to apply it in every situation regardless of practicality or need, as a way to demonstrate their knowledge. It's the sign of an insecure developer - please stop.
- dehrmann 1y ago
  I used to work on FAANG-scale optimizations. Generally, the only code-level optimizations worth bothering with are ones with inefficient (think O(n^2) vs O(n) and caching) algorithms. Those get you because they work during testing, but fall over in prod. You should also optimize DB and RPC access patterns when appropriate. As things scale, there can be larger architectural changes that help. Finally, there are cute micro optimizations that everyone thinks will matter. They don't.
siva7 1y ago
I love how we developers see ourselves like creative writers instead of plumbers
- RealityVoid 1y ago
  Some jobs are more like plumbing, some more like creative writing, some more like planning and architecture. It really depends on the project.
- frou_dh 1y ago
  Well it is quite literally writing, and fairly often starting with a blank page (file) and then doing a lot of editing. --- Talking of pages, I quite often write down on a physical notebook what I'm trying to accomplish. Because if I just dive straight into hacking code I sometimes get a frenzied feeling, as if I'm just bouncing around like a pinball in an undisciplined way.
- raincole 1y ago
  Haven't heard plumbers launching side plumbing projects. But who knows, perhaps they do and just don't post on HN.
  - Minor49er 1y ago
    Plumbers typically work on a variety of different buildings
  - danjl 1y ago
    Many plumbers start their own business, or work on contract. As a startup founder, I gained a huge respect for anyone, in any industry that managed to create a business where people pay them money. From Mom&Pop shops, to plumbers, to tech founders. Most of the real problems are the same.
- adithyassekhar 1y ago
  Depends on whether you are working for someone or building for yourself. If you work for someone, you are essentially plumbing, you will still find faults with their ideas and inform them. But you don't make the call to change that idea, nor do you have the burden of living with the finished product. It doesn't have your name attached to it. No one will call it, siva7's crm, you will move on to the next project. Now, if you are building something for yourself, you are the creative writer. It's your call, it's your want, it'll have your name attached to it. You can move on, but in everyone's mind and your own, it's your creation.
Kovah 1y ago
There's so much good advice in this article. My number one point that i learned the hard way during two decades of writing software: take breaks when your body tells you to. It's an absolute killer if you force yourself to work on your projects just because there's stuff on your to do list, new issues on Github, or whatever. Just stop working if you don't feel it.
- mavamaarten 1y ago
  I feel like that's great advice for people working on their own side projects. But... I'm employed? I mean surely it translates to "go on vacation" but it's pretty useless advice for days where you simply have to work and can't just... not?
  - mikodin 1y ago
    I don't think it needs to translate to "go on vacation". During my time being employed, this translated into getting up and stretching, taking a few minutes to look out the window, going for a short walk, taking an intentional breath, sitting and meditating for 15 minutes, actually eating lunch away from my computer, or not eating lunch and going for a quick run or doing yoga or going to the gym. This can come forth in so many ways. Moment by moment we can have an eye on our body and what it is asking for, I've found it to not only make me more productive, but also led to my baseline of stress to being way, way lower then everyone around me which is contagious in a positive way.
  - glynnormington 1y ago
    I take your point as I'm retired. But I had my previous working life squarely in mind when writing the post. "Sustainable pace" helps, which in my case came down to 37 hour working weeks, not working at weekends, and taking all my vacation (and some extra when my employer let me buy it). I know this might sound like madness to Americans, but as a Brit employed mostly by American companies, it worked fine for me. I found that taking plenty of breaks during the working day helped. Coffee breaks with colleagues, a decent lunch break (ideally including exercise), and plenty of tea breaks. So many times I've had a good idea or solved a problem during a break, so they are actually productive. Then there's finding other useful things to do which aren't as taxing as the thing that's blocking you (e.g. the next large feature). Fixing bugs, writing docs, and doing preparatory investigations about the upcoming work are all productive ways to give yourself a bit of a mental break. (This was hardest when working in teams with continual short sprints or doing XP and pairing, but if I allowed myself to start to burn out, my productivity started to decline - essentially my brain was forcing me to take things a little more slowly in order to recover.)
JimDabell 1y ago
I’ve also found that LLMs are great for getting past developer’s block. “What next?” can overcome inertia quite easily.
- petesergeant 1y ago
  That and I find it’s usually easier to start with a shitty first attempt that kind of works that you’re then refactoring
- ekidd 1y ago
  Yup, I don't use models to write serious code. But if my brain is totally blocked, perhaps after half day of meetings, I do sometimes take a smaller local model, explain a simple task to it, and let it try to implement to my specs. At this point I'm usually annoyed and engaged enough to get back in the zone. If a human is available, 30 minutes of pairing works even better. There's just something about breaking tasks down and getting even simple feedback that makes it a good jumpstart.
Unirely01 1y ago
[dead]
meander_water 1y ago
Great advice all round. > Take time with learning But this one in particular stands out. We are being constantly pushed to ship code at faster and faster rates. AI has only hastened the process. If you want to learn anything new you have to slow it down, push back against all the forces urging you to do more, ship more, make more money. If you're using AI tools, do the opposite of what everyone else is doing. For every piece of generated code you accept, scrutinize every line, ask clarifying questions, ask for alternate implementations, ask what the tradeoffs are. Just be curious. This will be slow, but that's the point.
duncanfwalker 1y ago
I think a lot of this is addressed by having a definition of done and more generally being explicit about quality expectations. You don't need to worry whether to polish the readme or add cross-compilation if you conscious about your quality expectations and the drivers behind them - there is no single 'best' project.
- RossBencina 1y ago
  I agree. I've been experimenting with writing DoDs for anything longer than an hour's work (things that often end up taking a month.) It helps. I think there's also something to setting structured goals, and sequencing mid-term sub-projects. If you can define scope and definition of done for the current sub-project then you can be clear on what is important now, and what you can defer for a later phase. Relatedly, I've been hearing a bit about goal hierarchies lately. This seems like a more flexible approach than reducing everything to a TODO list and/or backlog. (Here's a random description of goal hierarchies that seems like a good introduction: https://www.spcperformancelab.com.au/personal-training-advice/an-evidenced-based-approach-for-goal-setting/ https://www.spcperformancelab.com.au/personal-training-advic...)
ChrisMarshallNY 1y ago
> Release early, release often I’m big on this. I find it efficacious to have an integrated product going as soon as possible, even if it’s a field of stubs. It’s my experience that I almost never know what the end product will look like, no matter how much upfront planning time I devote, so being able to test and iterate the whole system, as soon as possible, is pretty vital. It’s also one reason that I like to use test harnesses a lot[0]. [0] https://littlegreenviper.com/testing-harness-vs-unit/ https://littlegreenviper.com/testing-harness-vs-unit/
- chrisweekly 1y ago
  Your linked post about test harnesses is outstanding; thanks for sharing!
  - ChrisMarshallNY 1y ago
    Thanks!
  - convolvatron 1y ago
    I agree. the only point that I didn't see there is that test harnesses radically improve reproducibility. no, no change directories, set that environment variable, touch that config file, or do any other manual system state manipulation when running your tests. put it all in the harness. same run every time, modulo races, and a lot less tripping over magic you can't always remember or show to someone else.
  - siva7 1y ago
    I've skimmed the article and still have no clue what you guys are talking about. Is test harness another word for end to end testing?
    - ChrisMarshallNY 1y ago
      Well, I thought I explained it well. Frankly, I'm shocked that folks don't know what test harnesses are. They are one of the oldest constructs in Software Engineering. In the days of old, we often called them "Unit Tests." If you want some concrete examples, here you go: Here's my "Spinner" widget: https://github.com/RiftValleySoftware/RVS_Spinner https://github.com/RiftValleySoftware/RVS_Spinner This is the four test harness apps: https://github.com/RiftValleySoftware/RVS_Spinner/tree/main/Tests/RVS_SpinnerTests https://github.com/RiftValleySoftware/RVS_Spinner/tree/main/... This is my checkbox widget: https://github.com/RiftValleySoftware/RVS_Checkbox https://github.com/RiftValleySoftware/RVS_Checkbox Here's the test harness app: https://github.com/RiftValleySoftware/RVS_Checkbox/tree/main/TestHarness/RVS_Checkbox_TestHarness https://github.com/RiftValleySoftware/RVS_Checkbox/tree/main... There's more, but these should be enough to illustrate the point.
Martin_Silenus 1y ago
Sleep. Best side task for your brain. How many times has this happened to me? You struggle with a feature or a bug, you think about it, you weigh the pros and cons for hours... because you don't want to start something that will set you back. You're tired, but you don't want to go to sleep until you've at least made a decision for tomorrow. Go to sleep. Now. Then you wake up knowing immediately what to do. You hardly believe it, because it was so hard to find before you sleep. And you do it. And it works. And you know that sleep was the key.
- esperent 1y ago
  Also exercise. Sleep restores you. Exercise is the spark.
  - mikepurvis 1y ago
    Good exercise also contributes to good sleep. I sleep like a log after a good bike ride or an evening out swing dancing, but if all I did was sit at my desk all day then it’s a lot more likely I’ll be tossing and turning or doom scrolling into the wee hours.
    - polishdude20 1y ago
      Just had a very tiring long run yesterday. Spent the night still scrolling haha.
      - mikepurvis 1y ago
        Ha, well ya can’t win em all I guess :)
        username135 1y ago
        edibles
        1y ago
lordnacho 1y ago
I hate to turn everything into a conversation about AI, but this essay maybe explains best what LLMs have done for me recently. Particularly the first part. I want to add a new feature, but I want to keep things clean. It needs tests, CI, documentation. It makes exploring new ideas a bit cumbersome, because code tends to create minor distractions that eat up time. You miss a semicolon, or you forget the order of the arguments to a function you just wrote, do you have to flip to another file. Or the test framework needs an update, but the update breaks something so you have to do some changes. It's not just the time either, it's the context switch from the big picture to the very small details, and then back again. LLM lets me do "one whole step" at a time. Or that's the positive spin on it. Seen another way, I'm further out from the details, and in most things, you have to hit a bit of a wall to really learn it. For senior devs, I lean towards the first, you've already learned what you're going to learn from fixing imports, you are operating on a higher level.
- ktallett 1y ago
  Are you giving the LLM your code and letting it add a new feature to see how it works? Or what? How successful do you find your method? Would you recode what you introduced using the LLM?
  - lordnacho 1y ago
    Yeah I let the LLM look at the code and ask it to implement some change. It works pretty well with Claude Code. Much better than cursor, which is a step up from copilot. Even with the same models, and I'm not sure why. I haven't really tweaked much around the AI tools, since I don't really know much about how they work. I've just found that Claude Code somehow... just works. Out of the box, no MCPs, no fancy configs. I just straight up tell it what I want, and most of the time it gets it right or close enough to right that a second instruction is all I need. Would I recode what I wrote? Maybe not from the ground up, since I already had a pretty good framework. But LLM has managed to make some pretty fiddly changes to my codebase recently. It would have taken me a long time, mostly in tedious edits.
- skydhash 1y ago
atemerev 1y ago
Well, this is exactly what I use AI for. I start to experiment with coding agents to try some things to make me unstuck. These are cheap to try. Then, the outcome is either "wow, this can actually work" or "but this is bullshit, and will never work, let me do it myself the right way!" Win/win.
kryptiskt 1y ago
When faced with a big task and not knowing where and how to start, a trick I like is writing something crappy that is roughly a step in the right direction. For example, if you're building a web browser (huge monumental task), just load a page with your favorite http lib and display it, html tags and all. You know that none of that code will survive, but it's something that you can build on, and in due time you'll come around and replace it with the right design.
EdwardCoffin 1y ago
The Oxide and Friends podcast [1] did a whole episode on this: Coder's Block (25 Oct 2021) [2]. It had some good stuff in it, the best of which (for me) was: when stuck, write debugging infrastructure. [1] https://oxide-and-friends.transistor.fm https://oxide-and-friends.transistor.fm [2] https://oxide-and-friends.transistor.fm/episodes/coders-block-2021-10-25 https://oxide-and-friends.transistor.fm/episodes/coders-bloc... Edit: punctuation
- glynnormington 1y ago
  Nice - thanks.
hoistbypetard 1y ago
I can feel this block, especially when I'm starting a new project. Two things that help me: * have a good boilerplate * ship things that do nothing i.e. I find it helps to start a project using my good boilerplate then set up builds and releases (so for web projects, put them online) so that the page doesn't look so blank anymore, and I can see my progress in "releases" even if they're just for me/others contributing.
- skydhash 1y ago
  I kinda started programming on IDEs (Visual Studio, Eclipse, then Android Studio) and the templates they is kinda a nice way to get quickly started on some projects and not have to worry about configurations. These days, I prefer CLI tooling, so I copy things over from projects on GitHub.
ruslan_sure 1y ago
Great words! I would add that the developer block specifically appears when you delve too deeply. You may get stuck in limbo. Simplify the mental model of the code, product, etc. Discuss it with someone.
tomrod 1y ago
Of all the uses of LLMs, this is the most useful to me. Being able to force a minor draft that I can begin tweaking to overcome dev or writers block.
- MarkSweep 1y ago
  I agree. I recently had a side project that had wanted to do for a while, but never could get past the developer's block on. Using a LLM was a great way to overcome this and get a MVP that I could start evolving. https://www.awise.us/2025/07/27/source-generator.html https://www.awise.us/2025/07/27/source-generator.html
KronisLV 1y ago
> A new project and it’s going to be your best ever A good defense against this is borrowing stuff from your prior projects, alongside eventually creating templates for the most common stuff. For example, in new side projects I start, I can borrow the web server (ingress) configuration from the prior ones, same for CI pipelines and a large part of the previous Dockerfiles, sometimes even entire services with all of the annoying setup and configuration stuff already done. Plus, this way, you have a more or less working baseline and further iteration is entirely up to you - and if you do want to improve things a bunch, then the next time your template will be even better and you'll be able to backport whatever you think everything should have to your other projects as well. Going with the simplest solutions along the way helps: Bash scripts for triggering builds, CI configuration just calling those, using Docker or similar containers for the environments and builds, your ingress just being Nginx/Caddy/Apache2/..., using PostgreSQL or SQLite and specialized stuff like Redis/Valkey, RabbitMQ, MinIO and so on instead of reinventing the wheel. Sometimes it's also useful to write utility scripts and even small tools to help with the projects, I bet developers that have been around for decades and are way better than I am have a lot of that stuff, alongside a healthy helping of dotfiles for existing tools to get in the zone while doing the dev work. Although it can also be helpful to go the YAGNI route and customize things as little as possible, like a stock IDE install, not even bothering with the color themes or keybinds or a plethora of plugins - just install and go.
- glynnormington 1y ago
  Fair point. I often copy stuff across from one project to the next. But this point is most relevant when I'm using another language etc. for the first time and I'm tempted to try to retrofit all my previous best practices. For example, I used to work on a mainframe product that dumped the address space to disk on a crash. Then it was possible to build all sorts of fancy tooling to analyse the dump. When I moved to a different platform, without those kinds of dumps, it was tempting to try to reinvent all this stuff, but it would have been a massive time sink (and would have failed too).
- mattmanser 1y ago
  I tried this for a bit 5/10 years ago, but I've never found this to work very well. I guess I relarely start significant greenfield, non-trivial, projects. Maybe every 3 years or so. By which time beat practice has completely changed and everything you setup is out of date. And that's backend, it's much worse for frontend where even 6 months later your 'perfect' template is out of date.
willmadden 1y ago
Exercise and/or take a nap.
supersparrow 1y ago
If I’ve had a break, gone for a walk, left it overnight, worked on something else simple for a bit and tried the other usual ‘fixes’ and am still stuck then I find ‘just do it’ really helps me. I find if I just write some code even slightly related to the goal, even if it’s complete garbage that gets deleted later, then I get unstuck. Although unfortunately even getting to that point takes a couple of days sometimes. We can’t always perform immediately on demand.
- wilkystyle 1y ago
  I definitely resonate with this. Getting to the point where you can just write and try things can be a little tough sometimes, but some of my best work has been done the second time around (i.e. the first pass was just doing whatever hacky, exploratory code I needed to do in order to get the feel and shape of the thing, and then the second pass was doing it for real once I had figured it out)
zabzonk 1y ago
Perhaps switch languages/paradigms for a few days. If you are used to using "text-based" languages such as golang, python, c++ or java, try something like Smalltalk to freshen you up. Pharo https://pharo.org/ https://pharo.org/ is a nice implementation.
BinaryIgor 1y ago
Besides mentioned by others walks and sleep I found meditation to be really helpful; you often can get the benefits, ideas-generation-wise, of a full-night sleep doing solid 30-minute session. There are other benefits of meditating too :)
- chrisweekly 1y ago
  Agreed -- and IME even a 10m zazen session is helpful. Also, a 20m nap can be surprisingly restorative. Physical movement (even a couple min of stretching) goes a long way, as does changing the environment (switching rooms, and/or writing design notes by hand instead of typing).
wseqyrku 1y ago
I second doing intermittent chores, but rather the literal actual household chores, helps you to relax while being productive and putting your mind at ease from the main task you are focusing on otherwise. For solo work, I've found a framework of four learning modes effective: reading, when you are exploring something new, sketching/speccing depending on the detail level you're aiming for, coding only when you might forget things you didn't bother writing down, and relaxing as the fallback state. The key is to be in only one mode at a time and to avoid getting stuck in any single one. Based on nature of the work, you might switch two or three times a day. And always know the next two immediate steps; if you don't, that's your signal to switch. Rinse and repeat.
coneonthefloor 1y ago
I suffer from this. I even get as far as nearly finishing a project, and then just decide to abandon it as the last 20% is just mentally exhausting, and I should have written the whole thing in language X using framework Y…
- siva7 1y ago
  Haha that's the legendary 80/20 curve of a sidegig ;) As i grew older i just do the work when i feel it. When i don't feel it after a few days i stop working on it. The feeling may come back but i won't force it like my younger self would do.
baduiux 1y ago
> You may be held up by a problem in a dependency such as poor documentation. It is tempting to start filling in the missing docs, but try to resist that temptation. Better to make minimal personal notes for now and, after you’ve made good progress, considering scheduling time to contribute some docs to the dependency. I agree with most of the article, but this part keeps me thinking. Scheduling to contribute later will almost never work. Either I do it now or never. The task is lost in a list of infinitely many tasks. Also, contributing to a dependency (if I understand this correctly) is always something that helps at least two: yourself - doing something good, helping to improve someone’s work, getting something done - and the person who works on the dependency project. The other gets (positive) feedback and knows someone uses their product/software/library
- glynnormington 1y ago
  I try to think in terms of owing the dependency a contribution as a small payment for using it, and this bugs me until I do it. But, sure, better to contribute docs sooner rather than not at all. (One advantage of deferring is that the contribution may be better quality when I've had more experience of using the dependency.)
danjl 1y ago
Naming was often my biggest block. I often know the project topic, but cannot choose a name. Then, of course, there's variable, function and file naming. Turns out the AI is fantastic at choosing good names, so that block is largely obviated these days.
- dunham 1y ago
  I had a block for a while because I _had_ chosen a name for my language. Suddenly what I was writing was the official implementation, it had to be "right", and I got design paralysis. I found I was making further progress doing exercises outside that repository. (It's all good now, and I have a self-hosted language.) At the function level, I'll often write the function and then rename it with F2 after I've written it.
twodave 1y ago
I feel like if you keep your effort problem-oriented you can avoid a lot of the stalling that comes from not being confident about things. E.g. saying, “This code sucks, but it solves the problem in a way that doesn’t paint me into a corner,” is a perfectly fine V1 solution. Understanding where your contracts are located and making those as good as you can with the information you have is important enough to slow down for. But once you have those then most other things can evolve freely.
armchairhacker 1y ago
Ironically, I overcome developer's block on new features with AI. I ask Claude Code to implement the feature, figuring out some details but leaving others for Claude to decide. "Ironically" because I usually rewrite almost everything it generates (sans the file and class names, sometimes). But when I describe the idea enough to give Claude some chance of implementing it, I refine it and start planning the high-level implementation. Then the file of LLM slop, even though I have to rewrite most of it, is much less overwhelming than a blank file.
spruisken 1y ago
Like with rubber duck debugging, simply explaining your block out loud to a friend or colleague can often trigger clarity. Happens to me all the time.
lilerjee 1y ago
Good article, thank you! I like extreme cycling, and it helped me solved many problems about development. When I'm riding my bike and listening to music, especially when freely imagining and designing my product in my mind, I am very relax. Many aspects of my products were designed while I was riding. Cycling is a great form of exercise. It not only helps you strengthen your body, enjoy the scenery, relax your mind, relieve stress, and adjust yourself, but it can also spark plenty of inspiration. If you’re under heavy pressure or working on a product, I highly recommend you go cycling regularly.
- ksflrn 1y ago
  How can one enjoy the scenery and design stuff in the brain all at once? Seems contradictory to me
  - lilerjee 1y ago
    Sometimes, I found a beautiful view, then I saw and played, it was time to enjoy. Sometimes, there was no good view, and my brain was excited to design my product, I went to a quiet road which had no or fewer people and cars, no other things to distract or bother you, you just was imaging freely and enjoy the process.
geldedus 1y ago
Just use AI. It is really good at producing documentation, tests etc

200 points by todsacerdoti 1y ago

dgan 1y ago

Rolled my eyes on "For experts only: don't do it yet". Shut-up already. I will do it right now because it will nag me forever and then surface will grow, and every time the new code interacts whith what-could-ve-been-optimized I will spend 5min thinking if I should already optimize it

glynnormington 1y ago
If there's a definite performance problem and a simple solution, then sure, go ahead. But applying every optimisation that comes to mind can produce a dog's breakfast of unmaintainable code and then when a real performance problem comes along, it can be really hard to fix.
ashwinsundar 1y ago
This is like the #1 cause of spaghetti, unmaintanable, deadlocked codebases - a single developer who knows every “best-practice” and optimization technique, and will not hesitate to apply it in every situation regardless of practicality or need, as a way to demonstrate their knowledge. It's the sign of an insecure developer - please stop.
dehrmann 1y ago
I used to work on FAANG-scale optimizations. Generally, the only code-level optimizations worth bothering with are ones with inefficient (think O(n^2) vs O(n) and caching) algorithms. Those get you because they work during testing, but fall over in prod. You should also optimize DB and RPC access patterns when appropriate. As things scale, there can be larger architectural changes that help. Finally, there are cute micro optimizations that everyone thinks will matter. They don't.

siva7 1y ago

I love how we developers see ourselves like creative writers instead of plumbers

RealityVoid 1y ago
Some jobs are more like plumbing, some more like creative writing, some more like planning and architecture. It really depends on the project.
frou_dh 1y ago
Well it is quite literally writing, and fairly often starting with a blank page (file) and then doing a lot of editing. --- Talking of pages, I quite often write down on a physical notebook what I'm trying to accomplish. Because if I just dive straight into hacking code I sometimes get a frenzied feeling, as if I'm just bouncing around like a pinball in an undisciplined way.
raincole 1y ago
Haven't heard plumbers launching side plumbing projects. But who knows, perhaps they do and just don't post on HN.
- Minor49er 1y ago
  Plumbers typically work on a variety of different buildings
- danjl 1y ago
  Many plumbers start their own business, or work on contract. As a startup founder, I gained a huge respect for anyone, in any industry that managed to create a business where people pay them money. From Mom&Pop shops, to plumbers, to tech founders. Most of the real problems are the same.
adithyassekhar 1y ago
Depends on whether you are working for someone or building for yourself. If you work for someone, you are essentially plumbing, you will still find faults with their ideas and inform them. But you don't make the call to change that idea, nor do you have the burden of living with the finished product. It doesn't have your name attached to it. No one will call it, siva7's crm, you will move on to the next project. Now, if you are building something for yourself, you are the creative writer. It's your call, it's your want, it'll have your name attached to it. You can move on, but in everyone's mind and your own, it's your creation.

Kovah 1y ago

There's so much good advice in this article. My number one point that i learned the hard way during two decades of writing software: take breaks when your body tells you to. It's an absolute killer if you force yourself to work on your projects just because there's stuff on your to do list, new issues on Github, or whatever. Just stop working if you don't feel it.

mavamaarten 1y ago
I feel like that's great advice for people working on their own side projects. But... I'm employed? I mean surely it translates to "go on vacation" but it's pretty useless advice for days where you simply have to work and can't just... not?
- mikodin 1y ago
  I don't think it needs to translate to "go on vacation". During my time being employed, this translated into getting up and stretching, taking a few minutes to look out the window, going for a short walk, taking an intentional breath, sitting and meditating for 15 minutes, actually eating lunch away from my computer, or not eating lunch and going for a quick run or doing yoga or going to the gym. This can come forth in so many ways. Moment by moment we can have an eye on our body and what it is asking for, I've found it to not only make me more productive, but also led to my baseline of stress to being way, way lower then everyone around me which is contagious in a positive way.
- glynnormington 1y ago
  I take your point as I'm retired. But I had my previous working life squarely in mind when writing the post. "Sustainable pace" helps, which in my case came down to 37 hour working weeks, not working at weekends, and taking all my vacation (and some extra when my employer let me buy it). I know this might sound like madness to Americans, but as a Brit employed mostly by American companies, it worked fine for me. I found that taking plenty of breaks during the working day helped. Coffee breaks with colleagues, a decent lunch break (ideally including exercise), and plenty of tea breaks. So many times I've had a good idea or solved a problem during a break, so they are actually productive. Then there's finding other useful things to do which aren't as taxing as the thing that's blocking you (e.g. the next large feature). Fixing bugs, writing docs, and doing preparatory investigations about the upcoming work are all productive ways to give yourself a bit of a mental break. (This was hardest when working in teams with continual short sprints or doing XP and pairing, but if I allowed myself to start to burn out, my productivity started to decline - essentially my brain was forcing me to take things a little more slowly in order to recover.)

JimDabell 1y ago

I’ve also found that LLMs are great for getting past developer’s block. “What next?” can overcome inertia quite easily.

petesergeant 1y ago
That and I find it’s usually easier to start with a shitty first attempt that kind of works that you’re then refactoring
ekidd 1y ago
Yup, I don't use models to write serious code. But if my brain is totally blocked, perhaps after half day of meetings, I do sometimes take a smaller local model, explain a simple task to it, and let it try to implement to my specs. At this point I'm usually annoyed and engaged enough to get back in the zone. If a human is available, 30 minutes of pairing works even better. There's just something about breaking tasks down and getting even simple feedback that makes it a good jumpstart.

Unirely01 1y ago

[dead]

meander_water 1y ago

Great advice all round. > Take time with learning But this one in particular stands out. We are being constantly pushed to ship code at faster and faster rates. AI has only hastened the process. If you want to learn anything new you have to slow it down, push back against all the forces urging you to do more, ship more, make more money. If you're using AI tools, do the opposite of what everyone else is doing. For every piece of generated code you accept, scrutinize every line, ask clarifying questions, ask for alternate implementations, ask what the tradeoffs are. Just be curious. This will be slow, but that's the point.

duncanfwalker 1y ago

I think a lot of this is addressed by having a definition of done and more generally being explicit about quality expectations. You don't need to worry whether to polish the readme or add cross-compilation if you conscious about your quality expectations and the drivers behind them - there is no single 'best' project.

RossBencina 1y ago
I agree. I've been experimenting with writing DoDs for anything longer than an hour's work (things that often end up taking a month.) It helps. I think there's also something to setting structured goals, and sequencing mid-term sub-projects. If you can define scope and definition of done for the current sub-project then you can be clear on what is important now, and what you can defer for a later phase. Relatedly, I've been hearing a bit about goal hierarchies lately. This seems like a more flexible approach than reducing everything to a TODO list and/or backlog. (Here's a random description of goal hierarchies that seems like a good introduction: https://www.spcperformancelab.com.au/personal-training-advice/an-evidenced-based-approach-for-goal-setting/ https://www.spcperformancelab.com.au/personal-training-advic...)

ChrisMarshallNY 1y ago

> Release early, release often I’m big on this. I find it efficacious to have an integrated product going as soon as possible, even if it’s a field of stubs. It’s my experience that I almost never know what the end product will look like, no matter how much upfront planning time I devote, so being able to test and iterate the whole system, as soon as possible, is pretty vital. It’s also one reason that I like to use test harnesses a lot[0]. [0] https://littlegreenviper.com/testing-harness-vs-unit/ https://littlegreenviper.com/testing-harness-vs-unit/

chrisweekly 1y ago
Your linked post about test harnesses is outstanding; thanks for sharing!
- ChrisMarshallNY 1y ago
  Thanks!
- convolvatron 1y ago
  I agree. the only point that I didn't see there is that test harnesses radically improve reproducibility. no, no change directories, set that environment variable, touch that config file, or do any other manual system state manipulation when running your tests. put it all in the harness. same run every time, modulo races, and a lot less tripping over magic you can't always remember or show to someone else.
- siva7 1y ago
  I've skimmed the article and still have no clue what you guys are talking about. Is test harness another word for end to end testing?
  - ChrisMarshallNY 1y ago
    Well, I thought I explained it well. Frankly, I'm shocked that folks don't know what test harnesses are. They are one of the oldest constructs in Software Engineering. In the days of old, we often called them "Unit Tests." If you want some concrete examples, here you go: Here's my "Spinner" widget: https://github.com/RiftValleySoftware/RVS_Spinner https://github.com/RiftValleySoftware/RVS_Spinner This is the four test harness apps: https://github.com/RiftValleySoftware/RVS_Spinner/tree/main/Tests/RVS_SpinnerTests https://github.com/RiftValleySoftware/RVS_Spinner/tree/main/... This is my checkbox widget: https://github.com/RiftValleySoftware/RVS_Checkbox https://github.com/RiftValleySoftware/RVS_Checkbox Here's the test harness app: https://github.com/RiftValleySoftware/RVS_Checkbox/tree/main/TestHarness/RVS_Checkbox_TestHarness https://github.com/RiftValleySoftware/RVS_Checkbox/tree/main... There's more, but these should be enough to illustrate the point.

Martin_Silenus 1y ago

Sleep. Best side task for your brain. How many times has this happened to me? You struggle with a feature or a bug, you think about it, you weigh the pros and cons for hours... because you don't want to start something that will set you back. You're tired, but you don't want to go to sleep until you've at least made a decision for tomorrow. Go to sleep. Now. Then you wake up knowing immediately what to do. You hardly believe it, because it was so hard to find before you sleep. And you do it. And it works. And you know that sleep was the key.

esperent 1y ago
Also exercise. Sleep restores you. Exercise is the spark.
- mikepurvis 1y ago
  Good exercise also contributes to good sleep. I sleep like a log after a good bike ride or an evening out swing dancing, but if all I did was sit at my desk all day then it’s a lot more likely I’ll be tossing and turning or doom scrolling into the wee hours.
  - polishdude20 1y ago
    Just had a very tiring long run yesterday. Spent the night still scrolling haha.
    - mikepurvis 1y ago
      Ha, well ya can’t win em all I guess :)
      - username135 1y ago
        edibles
        1y ago

lordnacho 1y ago

I hate to turn everything into a conversation about AI, but this essay maybe explains best what LLMs have done for me recently. Particularly the first part. I want to add a new feature, but I want to keep things clean. It needs tests, CI, documentation. It makes exploring new ideas a bit cumbersome, because code tends to create minor distractions that eat up time. You miss a semicolon, or you forget the order of the arguments to a function you just wrote, do you have to flip to another file. Or the test framework needs an update, but the update breaks something so you have to do some changes. It's not just the time either, it's the context switch from the big picture to the very small details, and then back again. LLM lets me do "one whole step" at a time. Or that's the positive spin on it. Seen another way, I'm further out from the details, and in most things, you have to hit a bit of a wall to really learn it. For senior devs, I lean towards the first, you've already learned what you're going to learn from fixing imports, you are operating on a higher level.

ktallett 1y ago
Are you giving the LLM your code and letting it add a new feature to see how it works? Or what? How successful do you find your method? Would you recode what you introduced using the LLM?
- lordnacho 1y ago
  Yeah I let the LLM look at the code and ask it to implement some change. It works pretty well with Claude Code. Much better than cursor, which is a step up from copilot. Even with the same models, and I'm not sure why. I haven't really tweaked much around the AI tools, since I don't really know much about how they work. I've just found that Claude Code somehow... just works. Out of the box, no MCPs, no fancy configs. I just straight up tell it what I want, and most of the time it gets it right or close enough to right that a second instruction is all I need. Would I recode what I wrote? Maybe not from the ground up, since I already had a pretty good framework. But LLM has managed to make some pretty fiddly changes to my codebase recently. It would have taken me a long time, mostly in tedious edits.
skydhash 1y ago

atemerev 1y ago

Well, this is exactly what I use AI for. I start to experiment with coding agents to try some things to make me unstuck. These are cheap to try. Then, the outcome is either "wow, this can actually work" or "but this is bullshit, and will never work, let me do it myself the right way!" Win/win.

kryptiskt 1y ago

When faced with a big task and not knowing where and how to start, a trick I like is writing something crappy that is roughly a step in the right direction. For example, if you're building a web browser (huge monumental task), just load a page with your favorite http lib and display it, html tags and all. You know that none of that code will survive, but it's something that you can build on, and in due time you'll come around and replace it with the right design.

EdwardCoffin 1y ago

The Oxide and Friends podcast [1] did a whole episode on this: Coder's Block (25 Oct 2021) [2]. It had some good stuff in it, the best of which (for me) was: when stuck, write debugging infrastructure. [1] https://oxide-and-friends.transistor.fm https://oxide-and-friends.transistor.fm [2] https://oxide-and-friends.transistor.fm/episodes/coders-block-2021-10-25 https://oxide-and-friends.transistor.fm/episodes/coders-bloc... Edit: punctuation

glynnormington 1y ago
Nice - thanks.

hoistbypetard 1y ago

I can feel this block, especially when I'm starting a new project. Two things that help me: * have a good boilerplate * ship things that do nothing i.e. I find it helps to start a project using my good boilerplate then set up builds and releases (so for web projects, put them online) so that the page doesn't look so blank anymore, and I can see my progress in "releases" even if they're just for me/others contributing.

skydhash 1y ago
I kinda started programming on IDEs (Visual Studio, Eclipse, then Android Studio) and the templates they is kinda a nice way to get quickly started on some projects and not have to worry about configurations. These days, I prefer CLI tooling, so I copy things over from projects on GitHub.

ruslan_sure 1y ago

Great words! I would add that the developer block specifically appears when you delve too deeply. You may get stuck in limbo. Simplify the mental model of the code, product, etc. Discuss it with someone.

tomrod 1y ago

Of all the uses of LLMs, this is the most useful to me. Being able to force a minor draft that I can begin tweaking to overcome dev or writers block.

MarkSweep 1y ago
I agree. I recently had a side project that had wanted to do for a while, but never could get past the developer's block on. Using a LLM was a great way to overcome this and get a MVP that I could start evolving. https://www.awise.us/2025/07/27/source-generator.html https://www.awise.us/2025/07/27/source-generator.html

KronisLV 1y ago

> A new project and it’s going to be your best ever A good defense against this is borrowing stuff from your prior projects, alongside eventually creating templates for the most common stuff. For example, in new side projects I start, I can borrow the web server (ingress) configuration from the prior ones, same for CI pipelines and a large part of the previous Dockerfiles, sometimes even entire services with all of the annoying setup and configuration stuff already done. Plus, this way, you have a more or less working baseline and further iteration is entirely up to you - and if you do want to improve things a bunch, then the next time your template will be even better and you'll be able to backport whatever you think everything should have to your other projects as well. Going with the simplest solutions along the way helps: Bash scripts for triggering builds, CI configuration just calling those, using Docker or similar containers for the environments and builds, your ingress just being Nginx/Caddy/Apache2/..., using PostgreSQL or SQLite and specialized stuff like Redis/Valkey, RabbitMQ, MinIO and so on instead of reinventing the wheel. Sometimes it's also useful to write utility scripts and even small tools to help with the projects, I bet developers that have been around for decades and are way better than I am have a lot of that stuff, alongside a healthy helping of dotfiles for existing tools to get in the zone while doing the dev work. Although it can also be helpful to go the YAGNI route and customize things as little as possible, like a stock IDE install, not even bothering with the color themes or keybinds or a plethora of plugins - just install and go.

glynnormington 1y ago
Fair point. I often copy stuff across from one project to the next. But this point is most relevant when I'm using another language etc. for the first time and I'm tempted to try to retrofit all my previous best practices. For example, I used to work on a mainframe product that dumped the address space to disk on a crash. Then it was possible to build all sorts of fancy tooling to analyse the dump. When I moved to a different platform, without those kinds of dumps, it was tempting to try to reinvent all this stuff, but it would have been a massive time sink (and would have failed too).
mattmanser 1y ago
I tried this for a bit 5/10 years ago, but I've never found this to work very well. I guess I relarely start significant greenfield, non-trivial, projects. Maybe every 3 years or so. By which time beat practice has completely changed and everything you setup is out of date. And that's backend, it's much worse for frontend where even 6 months later your 'perfect' template is out of date.

willmadden 1y ago

Exercise and/or take a nap.

supersparrow 1y ago

If I’ve had a break, gone for a walk, left it overnight, worked on something else simple for a bit and tried the other usual ‘fixes’ and am still stuck then I find ‘just do it’ really helps me. I find if I just write some code even slightly related to the goal, even if it’s complete garbage that gets deleted later, then I get unstuck. Although unfortunately even getting to that point takes a couple of days sometimes. We can’t always perform immediately on demand.

wilkystyle 1y ago
I definitely resonate with this. Getting to the point where you can just write and try things can be a little tough sometimes, but some of my best work has been done the second time around (i.e. the first pass was just doing whatever hacky, exploratory code I needed to do in order to get the feel and shape of the thing, and then the second pass was doing it for real once I had figured it out)

zabzonk 1y ago

Perhaps switch languages/paradigms for a few days. If you are used to using "text-based" languages such as golang, python, c++ or java, try something like Smalltalk to freshen you up. Pharo https://pharo.org/ https://pharo.org/ is a nice implementation.

BinaryIgor 1y ago

Besides mentioned by others walks and sleep I found meditation to be really helpful; you often can get the benefits, ideas-generation-wise, of a full-night sleep doing solid 30-minute session. There are other benefits of meditating too :)

chrisweekly 1y ago
Agreed -- and IME even a 10m zazen session is helpful. Also, a 20m nap can be surprisingly restorative. Physical movement (even a couple min of stretching) goes a long way, as does changing the environment (switching rooms, and/or writing design notes by hand instead of typing).

wseqyrku 1y ago

I second doing intermittent chores, but rather the literal actual household chores, helps you to relax while being productive and putting your mind at ease from the main task you are focusing on otherwise. For solo work, I've found a framework of four learning modes effective: reading, when you are exploring something new, sketching/speccing depending on the detail level you're aiming for, coding only when you might forget things you didn't bother writing down, and relaxing as the fallback state. The key is to be in only one mode at a time and to avoid getting stuck in any single one. Based on nature of the work, you might switch two or three times a day. And always know the next two immediate steps; if you don't, that's your signal to switch. Rinse and repeat.

coneonthefloor 1y ago

I suffer from this. I even get as far as nearly finishing a project, and then just decide to abandon it as the last 20% is just mentally exhausting, and I should have written the whole thing in language X using framework Y…

siva7 1y ago
Haha that's the legendary 80/20 curve of a sidegig ;) As i grew older i just do the work when i feel it. When i don't feel it after a few days i stop working on it. The feeling may come back but i won't force it like my younger self would do.

baduiux 1y ago

> You may be held up by a problem in a dependency such as poor documentation. It is tempting to start filling in the missing docs, but try to resist that temptation. Better to make minimal personal notes for now and, after you’ve made good progress, considering scheduling time to contribute some docs to the dependency. I agree with most of the article, but this part keeps me thinking. Scheduling to contribute later will almost never work. Either I do it now or never. The task is lost in a list of infinitely many tasks. Also, contributing to a dependency (if I understand this correctly) is always something that helps at least two: yourself - doing something good, helping to improve someone’s work, getting something done - and the person who works on the dependency project. The other gets (positive) feedback and knows someone uses their product/software/library

glynnormington 1y ago
I try to think in terms of owing the dependency a contribution as a small payment for using it, and this bugs me until I do it. But, sure, better to contribute docs sooner rather than not at all. (One advantage of deferring is that the contribution may be better quality when I've had more experience of using the dependency.)

danjl 1y ago

Naming was often my biggest block. I often know the project topic, but cannot choose a name. Then, of course, there's variable, function and file naming. Turns out the AI is fantastic at choosing good names, so that block is largely obviated these days.

dunham 1y ago
I had a block for a while because I _had_ chosen a name for my language. Suddenly what I was writing was the official implementation, it had to be "right", and I got design paralysis. I found I was making further progress doing exercises outside that repository. (It's all good now, and I have a self-hosted language.) At the function level, I'll often write the function and then rename it with F2 after I've written it.

twodave 1y ago

I feel like if you keep your effort problem-oriented you can avoid a lot of the stalling that comes from not being confident about things. E.g. saying, “This code sucks, but it solves the problem in a way that doesn’t paint me into a corner,” is a perfectly fine V1 solution. Understanding where your contracts are located and making those as good as you can with the information you have is important enough to slow down for. But once you have those then most other things can evolve freely.

armchairhacker 1y ago

Ironically, I overcome developer's block on new features with AI. I ask Claude Code to implement the feature, figuring out some details but leaving others for Claude to decide. "Ironically" because I usually rewrite almost everything it generates (sans the file and class names, sometimes). But when I describe the idea enough to give Claude some chance of implementing it, I refine it and start planning the high-level implementation. Then the file of LLM slop, even though I have to rewrite most of it, is much less overwhelming than a blank file.

spruisken 1y ago

Like with rubber duck debugging, simply explaining your block out loud to a friend or colleague can often trigger clarity. Happens to me all the time.

lilerjee 1y ago

Good article, thank you! I like extreme cycling, and it helped me solved many problems about development. When I'm riding my bike and listening to music, especially when freely imagining and designing my product in my mind, I am very relax. Many aspects of my products were designed while I was riding. Cycling is a great form of exercise. It not only helps you strengthen your body, enjoy the scenery, relax your mind, relieve stress, and adjust yourself, but it can also spark plenty of inspiration. If you’re under heavy pressure or working on a product, I highly recommend you go cycling regularly.

ksflrn 1y ago
How can one enjoy the scenery and design stuff in the brain all at once? Seems contradictory to me
- lilerjee 1y ago
  Sometimes, I found a beautiful view, then I saw and played, it was time to enjoy. Sometimes, there was no good view, and my brain was excited to design my product, I went to a quiet road which had no or fewer people and cars, no other things to distract or bother you, you just was imaging freely and enjoy the process.

geldedus 1y ago

Just use AI. It is really good at producing documentation, tests etc