Developer tooling really sucks

tl;dr

• I released GitPig version 0.1.11 to (hopefully) resolve the timer not restarting when the a computer turns back online.
• My personal blog for coding racked up 10k page views this month. It sounds good, but my neglect for that blog has led it to be reduced down from a high of around 24k views for January 2023!
• I spent too much time building tools for my workplace that I am confident will save me a few hours at least each month:
  • I built okeeffed/aws-dbg to parse AWS CloudFormation stacks so I can (among other things) quickly fuzzy search for log groups of Serverless Lambda functions.
  • I also a built a simple tool for generating Mermaid sequence diagrams so I could speed up the time it took for me to grok how our services are working and interacting with each other.
• I'm changing my approach to getting the word out for this blog. I have a content calendar organised for what I want to write about, and I am working hard on trying different strategies with dub.co for capturing simple metrics (like website references, demographics etc.).
• COVID got in the way of my plans for a highly productive week.
• I am going to begin recording weekly videos on YouTube. I am yet to decide what I am going to go with, but right now I am pretty sure it will be these reviews in video format or learning highlights/lowlights for the week.

Developer tooling won't make you rich

Anyone can come up with product ideas, because all product ideas stem from your experience. I'm sure that if you sat down for an hour, you could jot down quite a number of potential products to create solutions for problems in your workplace. Very few could become the next golden goose, but I would be surprised if at least one of them didn't gain support from other colleagues in your domain. If you face a problem, it's highly likely others in that area do too.

As a software engineer, most of those problems for me come from my day-to-day work and as such, those solutions fall under the banner of "developer tools".

I strictly want to move away from developer tooling. Searching for "developer tooling is it lucrative?" returned top results from Hacker News and Reddit with plenty weighing in on why it's a bad idea. This response sums it up pretty well:

1. Developers love to build things.
2. Developers hate spending money.
3. Developers undervalue their time.

Thank you, jasonkester. You summarised it so well that my soul quivers.

I knew all this well before working on tools like GitPig and my upcoming products for contract testing and package management, and that's before the three command line-tools I built for my work this week, so why did I decide to build those things at all?

1. I needed substantial improvements to my workflow both at work and at home (is this my excuse to pretend that I value my time?).
2. I was hoping my company would recoup the efforts in the name of sponsorship.

To elaborate on (2), I once heard a podcast on Software Engineering Daily circa 2017 (sadly never found the link) on a developer who made his first foray into product by building products for his workplace. It helped him to gain his first major customer (spoiler alert: his own workplace). Aforementioned customer also gave him time during work hours to work on said product since it was incredibly valuable to them. I was very hopeful that my first few products could be easy pickings to convince the company to at least donate a few dollary doos. So far the profits equate to 0 coffees, 0 paperclips, 0 ice cream cones.

Sadly, in my current state, my model of "it's open source, but not for commercial use (without a donation)" approach yielded no results. Boo. My main income source outside of office hours is still the revenue from my technical writing (which I have neglected over the last 12 months).

It's not to say that developer tooling is always a bad idea. YCombinator has its fair share of behemoths, but they are definitely on a scale different to what I am hoping to achieve. I also think that if I bothered to make this more research-driven than recount, it wouldn't be too difficult to unveil that these companies are less profitable than those solving non-developer-tooling problems. I mean heck, even GitHub redefined its branding to the AI-powered developer platform (and I'm sure that has nothing to do with surging its own stock price).

So I still released GitPig v0.1.11

After all that being said on the previous section, I released GitPig v0.1.11 this week (ha!).

The recent release has added a hover card for more information on the merge request. This prevented the need for me to always click-in and open the merge request. I also dropped the "blocking comments" status from the merge status icon and relocated that information to the hover card: too often my merge requests turned into the "blocking comments" state after a first review, and I realised that it was more useful just to get the default merge request API status (or "blocking changes" status if that was also an issue).

My approach is that if the tool still saves me time and money, then I will still add functionality to it to my standards. Other than that, I am going to take a new approach to it. What does that look like? I'm not too sure, but if at first you don't succeed, try again.

Developer tools took up my time this week

So now that we have defined that developer tooling is probably not going to net me the profits that I am dreaming of, let's recap all the other developer tools that took up my time this week:

Firstly, I built a generator at work to document our route permissions authorisation table.

The problem was that finding out what permissions were needed for my work was a little bit too painful, so I wrote a pre-commit Git hook to just find out based on our code and generate the tables in a docs folder and add that as a commit whenever anything changed.

Secondly, it is very damn hard for someone new to the codebase to understand what services do what. We have this backend-for-frontend repository that simply acts as the middleman to our frontend, resolving the data needed from other micro-services. And this happens across nine different repositories (yes, you read that right). Every micro-service has it's own repository, and even the contracts for those repositories have their own repository (which in turn is a private package that needs to be installed in the repositories that depend on them).

We have a consistent pattern for this: the AWS CDK maps a lambda endpoint to its corresponding function file, that file calls the service layer, the service layer invokes other services, clients or a repository class based on what they're doing, and they invoke helper calls that resolve at the other service repositories. Might sound over-engineered, but at least it was consistent enough to write an AST parser to generate some Mermaid sequence diagrams. For someone like me coming into the codebase, I could spend upwards of 15 minutes jumping between files just to understand which repository I may actually need to update for any given change. Now I can just get an overview.

Finally, we cannot run the repositories in local. I repeat, we cannot run the repositories in local dev. Every change you make needs to be redeploy on your feature branch using the AWS CDK. If you've ever worked on infrastructure and ran into the problem of having to always deploy things first to see if they work, well now you can also introduce that hell to any backend developer just trying to confirm that they added a new property correctly.

It's been a surefire way for me to make a change, wait up to seven minutes for that repo to deploy via the CDK as part of CI (mind you, this could also be for multiple repositories) and then you need to debug by jumping into CloudWatch log groups.

This process of debugging via AWS itself has been very costly (log in, assume the correct role, head to AWS CloudFormation, filter the stacks, select the stack you want to focus on, find the resources and search for lambda log group), so I decided to spend one evening building @okeeffe/aws-dbg. In hindsight, the "debug" is probably not very apt for the name, but the tool itself will effectively prompt you for a role, some text to match against (which is actually fuzzy search, not whatever AWS is doing) and then combines all of the matched stack resources into a searchable prompt (in AWS, you effectively need to select the right stack first... if you know it).

Naturally, you could also just pass flags to the command to make sure you're not always prompted for the role and the text to match against e.g. npx @okeeffed/aws-dbg@latest -p your-profile -m staging.

Building this out did cost me one evening, however I reckon the debugging process over the last two weeks alone has cost me a few hours of my life just clicking the the AWS UI.

Contract testing should not even be on my radar

Finally, I built out an almost-MVP version of my contract testing tool.

A problem at work at the moment is that if you extend a contract from a contract repo (which in turn generates a validation helper function), install it into another repo and merge that change, then you can potentially break the chain of the micro-services. Sounds kind of dumb, but you could imagine it like a "open for extension, closed for modification" problem where someone accidentally updated the API in a non-extending way, didn't get any validation feedback from it and has now accidentally broken the API contracts (and also everyone else who has rebased those changes).

Pretty wild to be thinking about it, but the amount of times I accidentally foot-gunned something while onboarding or took way-too-long to implement something simple is a little crazy (my last feature to extend an API took 15 merge requests across five repositories).

Since we already generated OpenAPI specs for each repo and it was trivial to figure out the functions being consumed by the packages (and in turn generating a JSON schema contract), I built out a small MVP product over the January long weekend here in Melbourne.

The tool effectively knows about each repository's downstream/upstream dependencies, and tests the generated contracts.

It started an interesting conversation on the Slack thread about whether we should use OpenAPI definitions or a developer tooling (lol) solution like Pact.io.

Given how the thread went down, it feels like this will also be another failed product. Given how close the MVP is, I figure I will still launch and see what the grander community thinks. Very hard to get a strong metric from my own company about whether this could be useful -- in earnest, I can't imagine many other companies shoe-horning themselves into this problem to begin with. At least not without already having solutions in place. Stay tuned.

Stop talking about developer tools

Okay, I feel you. The last few updates are more about my approach to draw more attention to the blog.

As of now, the blog subscriber count hasn't changed since launch day and sits at a paltry count of six.

My aim is to focus on the content for the blog and to drive up the numbers. In earnest, I've still has less than 100 views on the blog.

On a more positive note, 6.25% view-to-subscriber conversion rate sounds great!

So what have I done? First of all, I've added a new banner to my tech blog.

It sits across all the pages in an attempt to drive traffic to here.

In January alone, I managed to rack up 10k page views, so I've started a campaign to see if adding the banner across will boost traffic in some way.

If anyone is thinking that the 10k views per month is great, then sadly it looks to be down from 24k for January 2023. That's probably a mixture of a lack of new content, as well as a lack of love for cleaning up the UI. I'm still actually running Google ads on the website (in a bid to earn some $), but the earnings that I make seem putrid in comparison to the amount of people that probably get annoyed by the ads being there. I will endeavour to remove the ads soon enough. You can't even withdraw money until you hit the $100 ad threshold. To be honest, I think my lifetime earnings from there are still sub-AUD$1000 since their peak hey-day two years ago.

I am also going to lean into dub.co as my link shortener in order to try to capture some of the traffic and to be more privy to where traffic might come from as I run these campaigns.

Of course, if anyone has feedback on the content or what they want to see more of, please do hit me up. That would be much more helpful than all this guesstimating.

I am also pretty confident that these numbers won't begin to build up until I actually make some decent coin, which means that we could all be in together for a few months of learnings yet!

For what it's worth, I might try sounding more polarising with things such as my blog titles. Is it an attempt to catch more attention? Yes. It is click-baity? I hope not. They should still reflect the learnings that come about through the content.

Roadwrap

In the upcoming week or so, I'm doubling down on finishing off the current MVPs for the developer tools and releasing them.

There are two projects on my radar for upcoming work that I also want to start:

1. A Slack tool to help encourage brain writing.
2. A new Japanese course that focuses on the mnemonic peg system and spoken practice.

I am also yet to do a release on Product Hunt (and similar), so I will be planning to gear up on doing so for GitPig.

GitPig itself is probably going to take a rest on the side as I almost consider it feature-complete for MVP and it is yet to make any money from sponsorships.

Funnily enough, an old blog that my partner and I have not contributed to for a long time at melbcoffee.com had more search viewers than I've managed to rack up for this blog. I may revisit the blog and begin to add some more posts in future.

Finally, dub.co also has an API these days, so my plan is to use it to generate some links for the blog.

And with that, we have another recount done and dusted! It actually does take so damn long, but it is also a little therapeutic. Hopefully I can look back at the early posts and share a laugh at how miserable building developer tools has been for building up revenue confidence.

Stay tuned, I will be hitting up video format soon. Also don't forget to send a message if you have any learnings you feel keen to share.

-- Dennis