thisdougb

I just use a branch per feature or unit of work. The git hooks make the time measurement automatic.

  git checkout -b feature_a
  <do work>
  git checkout master
  git merge feature_a

I track branch time, which is the most honest I've found. I don't trust any self-reporting (me included).

It's pretty simple, and gives a broad view of feature dev time. Whether using AI to code or not.

https://github.com/thisdougb/git-time-hooks

Edit: there's no perfect way, but a broad start/stop gate of creating then merging a branch gives a reasonable idea of time taken. Then you can use AI to trawl through high time-cost features and see if there's ugly implementation lurking.

After quite a few years of coming up with and implementing 'great ideas' but not being able to follow through to making them revenue generating products, I'm on my best bet so far.

I always wanted to build a real-life puzzle game, which is app/mobile assisted. Had yet another eureka moment, and built a usable prototype (backend plus iOS app). Good feedback from a small circle.

For a while I was aware of someone (I knew by sight) who worked in the same sort of subject matter (but a non-tech). I approached her, we had a coffee, I pitched the idea and how she could bring it to life, as I made the tech side. She jumped on board.

We're two and a half weeks in, have gone full speed and are making something great (for our audience). My future co-founder is amazing, great insights, opinions, drive. We're potentially launching in a couple of weeks, a free/MVP version of a puzzle game.

I've been through many iterations of trying to get something off the ground. Tried tech co-founders, and the last years of going solo (very hard after you've done the coding). But this now feels right. A puzzle app/game for every day people to have some fun. And a future co-founder whose life is outside tech, who's bring a sort of fun energy outwith let's make loads of money or isn't the framework/AI cool.

Balance is good. Contact with reality is good too :)

Yeah, that's a lot of work. And developers would probably expect it for free give most things like that are also free(1) :)

There's a VSCode extension for Hashi Vault: https://marketplace.visualstudio.com/items?itemName=owenfarr... for secrets management, but it's complicated because Vault is complicated.

A secrets extensions for my backend app would be quite easy though, I think. It's just re-implementing the cli tool.

From the IDE command palatte you could:

- Settings.backend_host = private Doocot backend || public backend

- Settings.username = (automatic)

- Settings.identity = (automatic) something like ssh key data

- Share.Individual = "select from list of identities on backend"

- Share.Group = "select from list of groups I am in"

- Share.Link = "store secret and return a valid one-time url for a non-dev"

- Read.SharedSecrets = "list secrets shared to me or my groups"

Then it'd just be some thought into the simplest way to setup and maintain groups.

You've piqued my interest in it again though, as it doesn't seem much extra work to do the above. Given the backend more or less does most of it already.

Although it's not the full environment integrated solution you're looking for, I think one step forward in terms of how we share secrets is still useful.

Thanks

(1) someone always pays

Earlier this year I made this https://doocot.sh/ for securely sharing secrets between people.

It's written in Go with no dependencies (or database). My intention was for an AWS image or something companies could run inhouse air-gapped from the Internet. Something like $10/m or so.

The cli is pretty easy to integrate with scripts: https://github.com/thisdougb/doocot

Longer term secrets were something I was looking at too. Pretty easy to extend this, but encroaches on Vault products and I felt that a harder sell to CTOs.

I've worked in infra/systems dev for years, and this sort of thing was bread and butter stuff.

Maybe I'll resurect it as an active project. What sort of feature/tool would get you to stop using Discord/Slack/etc for secrets?

I do a lot of code review and doc/comment updates on my iPhone, using Working Copy and a small bluetooth keyboard. It turns out to be ideal because the small screen size means better mental focus.

I have a vm I connect into via ShellFish (same dev as Working Copy) for when I want to checkout/fix/deploy, but it's a rarity that I need to do that.

This is an interesting podcast: https://corecursive.com/briffa-sep98-e/

"In this episode we explore the “Climategate” scandal that erupted from leaked emails and code snippets, fueling doubts about climate science. What starts as an investigation into accusations of fraud leads to an unexpected journey through the messy reality of data science, legacy code struggles, and the complex pressures scientists face every day."

He goes into the code/data that is seemingly the root-cause of a lot of "it's all a hoax." I found it pretty informative, as to how climate data is gathered and processed (by the scientists). And the limitations therein. He's simply trying to explain the cause of climategate, rather than advocate any view.

It's also a great example of a tech/dev investigation into root-cause analysis, of someone else's code. So it's interesting from that point of view, even if you're less interested the climate side of it.

Why does it matter if they're called posts, pages, or bananas?

Static site generators take input, run it through templates, and produce html output. This seems to be, literally, what you want to do. Maybe try and implement what you want and you'll see they can do it.

I use Hugo to generate some static pages that sit inside a dynamic website. It's just Go templating, which is not too hard to learn. You can create individual pages that pull in multiple templates if you want. You can switch off RSS, change naming from posts to bananas, etc. Very few preconceived regulations.

Most of the static generators are used for blogs, that's probably why most examples they give are around blog posts. It doesn't mean the name 'post' actually means anything special.

That's a good read, thanks.

I'm really interested in the additional time cost of your switch. As you say, measuring productivity is seems nearly impossible.

But I would expect your 40 developers now have more time to do other things, because AI is taking on some of the workload? So have you noticed developers now doing 'new' things, like experimenting with new ideas, shorter hours, more holidays, or spending more time learning non-core topics? I think that would be visible. The 'Friday for personal projects' becomes 'Thu and Fri for personal projects', for example.

When frameworks became popular ten or so years ago, developers made the 'this will be much more efficient' argument. All that seemed to happen was the time they used to spend thinking/learning the core language (or engineering concepts) was swapped for time learning the framework. So there was no significant productivity gain, despite tasks feeling easier to do.

You list AI management/maintenance tasks that didn't need to be done before. I assume not all of these are 40x across your developers. It will be interesting to see if this management workload becomes similar to infrastructure management, and develops into a new job type providing a shared service. At least maybe during the transition away from flesh-based development to AI development.

I guess your end goal is that AI writes all (literal) code and owns the codebase, directed by people in the company? Do you have a plan to transition developers away from tech roles, is that something that's discussed?

https://antirez.com/news/148 (Redis creator)

I think he's doing an AI YouTube channel. He was quite rational with all the nosql hype back in the day, and seems to still be quite rational.

This reads like mentoring a junior dev. You do mentoring because the pay off is a junior that develops into a senior; writes better code more efficiently. But what's the pay off with going through this process with AI?

A few days ago I spent an hour trying to get Claude to write unit tests for a relatively simple function, without getting anything functional in return. It produced good (but changing) plans of work, but the code generated didn't match the plan (syntax or semantics).

Are people simply replacing 'time spent coding' with 'time spent mentoring AI'? And is that a useful trade off, given AI forgets everything?

I'd love to see a more honest discussion about the overhead of coding with AI assistance. It's still too high an overhead for me at the present capability.

I'm doing a similar thing (not could security though), similar thoughts try to surface.

If you're trying to build a business, only a small part of it is about generating code. Sticking with it and developing a good product is where you make the difference. I've built many things in a couple of weeks of coding, but then given up when faced with the hard work of making it a solid business.

My other thought is.. There are always others coding faster than me, writing better web copy, doing sales more successfully, etc. You/we pick AI as a threat because we understand it, but a good sales person is just as much of a threat to your idea.

We all have technical/skills advantages and disadvantages. In the successful startups I worked in these were not that important in the end. It was just about keeping going, every day. Relentless optimisim that you're right.

When I first started in dev, on a Unix OS, we did 'waterfall' (though we just called it releasing software, thirty years ago). We did a a major release every year, minor releases every three months, and patches as and when. All this software was sent to customers on mag tapes, by courier. Minor releases were generally new features.

Definitely times were different back then. But we did release software often, and it tended to be better quality than now (because we couldn't just fix-forward). I've been in plenty of Agile companies whose software moves slower than the old days. Too much haste, not enough speed.

Specs were never frozen with waterfall.

This is interesting, thanks for posting. I've been searching for some sort of 'real' usage of AI-coding. I'm a skeptic of the current state of things, so it's useful to see real code.

I know Python, but have been coding in Go for the last few years. So I'm thinking how I'd implement this in Go.

There's a lot of code there. Do you think it's a lot, or it doesn't matter? It seems reasonably clear though, easy to understand.

I'd have expected better documentation/in-line comments. Is that something that you did/didn't specify?

https://diff.wikimedia.org/2025/04/01/how-crawlers-impact-th...

This is interesting on the subject. Maybe gives you some understanding. Posted on HN a few minutes ago.

cool.

The prepare-commit-msg hook is the one. One of the hook args is the type of commit (merge, squash, etc). And the merge commit msg files exist (SQUASH_MSG, MERGE_MSG) so my original logic all works.

  $ git log -1
  commit 735ce5f9998736c4066d63ab851df2023640dad5 (HEAD -> master)
  Author: Doug Bridgens <thisdougb@users.noreply.github.com>
  Date:   Tue Apr 1 22:31:22 2025 +0100

        test4 does some stuff
    
    Time spent on feat_test4: 0d:0h:7m secs=426

"and your mental effort can shift from managing low-level details to clearly expressing your intent."

I really struggle to understand what people are doing that makes these two things mutually exclusive. Unless the catchment group is people who can't code or understand software engineering. Which is fine. It reminds me a lot of the no-code hype.

I wonder if ai-coding will turn out a bit like ultra processed food. Cheap to produce something that looks like it does the job, but actually is quite bad for consumers.

I don't see anyone producing objective measures on the improved apps. Like bugs per lines if code, feature development time, etc.

I did look at modifying the merge commit message, but I couldn't figure out how to accurately detect a merge commit.

Having re-looked, I just found 'git rev-parse --verify MERGE_HEAD' which may help here. Time to do some testing. It would be good to clean up and standardise the commit msg itself too. Thanks.

ah, I totally forgot there was a cli tool for gh. thanks. I'll have a dig around and see what I can get from it.

thank you.

I'm trying to workout how it (the idea) can be ported to work with GitHub pull requests. But I don't know enough about what's happening under the hood with GitHub during the PR process.

I moved from GitHub to self-hosted gitolite. I use a (standard) Makefile in each repo, which my deploy job runs (make test, make build, etc). I use githooks to do various automation.

It's really not that much different to GH Actions, and not more work. But it's much faster, and easier to work with.

If you're working in a team, then PRs are hard to replace.

I've been trying for a few years to get a SaaS type thing launched.

The first few attempts were with other people, because that's what all the advice tells you. These all petered out because my driving purpose didn't match the other person, which only came to light when things got serious. Nothing acrimonious, just a total loss of motivation on both sides as we implicitly pulled in different directions.

Now I've been trying solo. It's hard, doing everything. But also easier. For me the motivation to keep going is the hard part. I did an iOS app which got lost in the sea of apps, then a more SaaS-like app inside Strava which ended when Strava changed their terms. In both cases I could/should have continued, but motivation was gone.

In the last few weeks I've built and released a free-tier dev tool. Now building the paid-for versions while also trying to build awareness and get people using it. I've really shrunk down the product scope, which has helped stay motivated/focused. I've built something with a target audience of my own industry. Most importantly (for me) is that I've become more aware of motivation drains (individuals, websites, doom-scrolling, the news, lack of exercise, etc), and more pro-active at avoiding them. It's going better this time around.

What I've learned so far:

- look outside tech for inspiring people who've built products (every independent hair salon, baker, accountant, etc already did it). Tech is not special, in many ways it's risk-free. I found the How I Built This and CoRecursive podcasts useful to maintain perspective, and have some down time with my inspiration.

- just start. Don't treat the first thing as 'the one' (I sort of do every time, and it's a mistake I'm trying to correct), because it's too much pressure. I'm still discovering things about my approach to this that I will fix in the next attempt.

- I tried the side-hustle thing. But I like to do a good job, so I was using my energy for the people paying me. I couldn't, in good conscience, work on my thing on someone else's dime. That's just me, but it meant I never had the energy to work on my stuff at night. Now I've blocked out the next six months for the SaaS product I'm doing (I’m a freelance/contractor).

- coding is the easy part. Sticking to your vision/purpose/core-product is harder, because everyone else seems to be faster/smarter/pivoter/experter. Mostly I found the cliches don’t work until you learn them by experience (so just start).

- managing time/work. Much of the time I need to spend is thinking, simplifying, or reading/writing, with coding being about 10%. I queue up non-coding tasks to be done ‘anywhere’, so train journeys, cafes, lunch, your notice period. Maintaining momentum is easier if you’ve a lightweight management tool. I use Things3, because its iOS home-screen widget shows my current checklist and I can see progress.

- motivation has been my achilles heel every time, particularly as a solo. There is some cliche or other about this, which of course I’ve known and understood forever. But the previous experiences have been like practical training, making my motivation more robust. Each time I’ve found extra places to patch up my soul to prevent motivation leaks and recognise gumption traps.

If you want inspiration from someone who did something without an expert coding career, lookup the podcasts/interviews with the StoryGraph founder (Nadia Odunayo). There are countless other examples of paths to building a SaaS product, if you have a look.