---
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.
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.
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?
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.
"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.)
I just grind through it and repeat the days.
I would do only aimless activities if I relied on the feels.
This kind of negative emotional investment seems to be the only thing that improves my abilities. If I’m learning through Anki or playing tunes on the piano, habit can stop after 6 months of regular daily practice.
But if I’m on the brink of stress rage frustration, somehow it persists .
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.
> 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.
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-advic...)
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].
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.
Sleep restores you. Exercise is the spark.
Some have pain and/or insomnia waking them up at night with the inability to get back to sleep quickly or at all, and some have pain/injuries that make exercise less fun.
Telling us to sleep and exercise is like telling homeless and starving people to get off the streets, find a job, eat a good dinner, and buy a house. It sounds nice, and we’ll do our best, but the world you live in is different, and you don’t understand.
But because I've struggled with this thing for decades, I probably do have enough tools to find my own way. And if I've run out, it means I'm about to burnout and need to find a way to restore ASAP.
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.
How successful do you find your method?
Would you recode what you introduced using the LLM?
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.
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.
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
[2] https://oxide-and-friends.transistor.fm/episodes/coders-bloc...
Edit: punctuation
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.
Simplify the mental model of the code, product, etc. Discuss it with someone.
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.
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).
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.
dgan•4h ago
glynnormington•33m ago