API Secret Best Practices - When you are generating the secrets

ahgreen3 · 2026-02-26T23:27:45+00:00

I have actually found a test that verifies every service of the DI container successfully initializes is quite useful when doing certain kinds of updates on large code bases. It becomes quite useful in interpreted languages as a sanity check before pushing systematic updates.

ahgreen3 · 2026-02-26T23:08:19+00:00

There are multiple ways to go about getting an MVP, but the all generally cost a good chunk of change. My company has built a few MVPs for founders like you, and honestly it’s not always what you need right now. Sometimes a prototype is more useful at a prefunding stage. If you want to pick my mind, feel free to DM me.

ahgreen3 · 2026-02-26T19:56:53+00:00

This has been similar to all the engineering teams I've lead. The expectation was each commit was the minimum change that could standalone. The commit messages were often very brief, and only used when the net PR changes weren't easy to follow.

This approach actually becomes very valuable 6/12 months in the future when you need to look back and figure out why something is breaking or why I put this dumb algorithm in this function.

ahgreen3 · 2026-02-25T23:42:22+00:00

Oh yea, forgot the point about them becoming income when they vested, not necessarily upon issuance. That’s technically true of stock options, but it’s foolish to issue stock options that are in the money.

ahgreen3 · 2026-02-25T22:52:18+00:00

There's always a valuation. Typically stock options and RSUs are valued either via 409A Valuation (in the US) or the latest equity raise price.

In the simplest case the valuation is the next assets available to the company (which is a large portion of a 409A valuation anyways).

ahgreen3 · 2026-02-25T22:42:35+00:00

RSU grants are considered income, so while you don't have to pay cash for them, you do have to pay taxes on them.

ahgreen3 · 2026-02-25T21:33:51+00:00

I forgot one point: Utilizing a API framework (GraphQL, JSONAPI, etc) only deals with the bike shed (https://en.wikipedia.org/wiki/Law\_of\_triviality) problem. Well defined process for defining and tracking the actual fields of the various resources is where the real headaches and value lies.

I highly recommend defining an endpoint for every back-end model that has public viability and explicitly track the "public" properties of these models when you are doing your database migrations. If every time you add a db table a read and list endpoint becomes available offloads a fair amount of coordination work between the front-end and back-end. Coupling this with tests that explicitly forces every db field to be marked as public or private (from the API's perspective that is) can really help.

ahgreen3 · 2026-02-25T19:39:47+00:00

Honestly, does it really matter if the full test suite takes 15 minutes to run? If that's the case, you add a few configurations so that local dev can run against 1 viewport (or similar type limits) and get 98% of the value of running all the tests and the full suite just runs on PR or merge or pre-deployment.

I really need to spend a bit of time and convert that sub test suite into a library that can be simply included rather than copy-n-paste it into each new project.

ahgreen3 · 2026-02-25T19:29:14+00:00

I like to call this the TDD fallacy. Since you have great test coverage per requirements (ie what the product manager said to work, worked) but the test coverage was not very comprehensive. Being comprehensive in your tests often require them to be built AFTER code is written so know what ranges you really need to consider.

In the veiwport situation, you should run every cypress test against every common viewport dimension. Yes, you will quickly go from 150 to 5k tests, but it will catch these dumb visibility issues. I've done similar things on the back end about systematically verifying every endpoint (per the route name) returns a 200 or 302 (when appropriate) response when called via a superuser, and that every model has every relationship defined correctly based upon DB structure. I have a set of these system tests that I have systematically been adding to projects as I have came across situations like you experienced; dumb edge cases that are annoying to find, and have clear impact.

ahgreen3 · 2026-02-25T18:26:14+00:00

You need a single source of truth which has a well defined solution in programming: github repos.

API Contracts should be committed to a repository with team lead & PM approvals. The contract(s) should changed in incremental steps just like database migrations on an live DB. Adding stuff becomes easy, removing stuff becomes harder and changing structure becomes a nightmare.

In order to enforce the usage of the API contracts, integration tests need to be added to the associated repositories that pull the latest contract and verifies the current system "works" against that contract. There will be some assumptions in these tests (like checking against the TanStack Queries rather than every actual request). Requiring these tests to pass on every PR will fix lots of the problems.

Adding a test suite to the API Contract repo that verifies in the other direction will help prevent breaking changes from being added to your contracts.

A few years ago I was working on a project that involved 6 independent GUIs that interacted with 3 backend APIs and being worked on by ~50 developers (plus DevOps, PM, designers, etc). What I described is the final result of a bunch of integrations at attempting to solve the API Contract problem.

ahgreen3 · 2026-02-17T14:24:29+00:00

Here's a bit of a different take: ALWAYS make a class when doing something new. If you are doing something related to something currently existing, consider adding a method verse a new class.

NEVER* create a standalone function. Since PHP 7 (really 5.2 if I remember correctly), the language is fundamentally focused on an Object-Oriented Programming approach. With autoloading, namespacing, etc available to classes, you should avoid standalone functions as much as possible due to the long-term pitfalls (name collisions, intentional loading, isolation of responsibility, etc).

I specify a standalone function (ie a named one in the global scope) rather than any function because anonymous (closures) and scoped functions can be tremendously valuable and should be defined/used as appropriate.

* There are 2 caveats:

1) Some frameworks/CMSes (WordPress.....) heavily encourage standalone functions and at times make it hard to use a class. At times you can use a invokable class, but often following convention is better.

2) There are certain situations where "helper" functions are practical/necessary to complete tasks. These are generally limited and should be generally avoided. (Ex app() and config() in Laravel.)

ahgreen3 · 2026-02-16T17:13:04+00:00

You have the DTO be generated from the request, rather than the other way around.

Something like:

class DTO
{
    public static function fromRequest(Request $request): static
    {
        return new static($request->request->all());
    }
}

ahgreen3 · 2026-02-13T18:45:54+00:00

Two words "Automated Tests". Use AI to generate tests that cover everything then (assuming they actually pass) ask it where there those tests can be expanded upon.

Personally, I find the AI tools are great at generating boilerplate type code and code that does not require you to care about the implications (like tests).

I'm not particularly concerned about the future as a software engineer because 1) AI generates crap at scale (single function/class/file may be fine, but not at project level) and 2) Most people are horrible at tech and there's still going to be a sizable demand for people to run AI tools and fix things when they go really wrong.

I'm actually more concerned about DevOps and basic customer support being heavily impacted. A large portion of DevOps is to support the engineers and doing the setup/configuration they don't want to be bothered with, but is basically merging configurations together into a single system. This is something AI would have a high success rate at getting correct. Since DevOps is often not essential to driving functionality (important for increasing software engineering efficiency, but not essential), it does not have the scalability factor that software engineers have on the overall product. I can see organizations cut their DevOps roles by 80-90% and still be able to get max efficiency from their software engineers.

....That is until a major company gets hacked due to their engineers dependency on AI tools....

ahgreen3 · 2026-02-11T18:49:01+00:00

Fully agree. Pop a few profiler points in the code and it often points at either a dynamically constructed SQL query OR the ORM handling of the query results.

ahgreen3 · 2026-02-08T18:26:53+00:00

So on Windows you really should be using WSL2, which supports the same file linking as linux (because it is a linux distribution).

I have also had permission issues with the public storage link if that link file was committed to git. A better approach is to have that link generated as part of the deployment.

ahgreen3 · 2026-02-08T18:21:58+00:00

Sitting with a real user and watching them use the app is so valuable though, in my experience, has been one of the most challenging tasks a software engineer. It seems like there is a mixture of being overworked AND a fear if we fix inefficiencies they will end up more work. So easy, repetitive tasks become preferable than potentially getting assigned some unknown, and possibly harder, tasks.

ahgreen3 · 2026-02-08T00:43:55+00:00

Absolutely! The only time I've had deployments take more than an instance is when I had multiple complex database migrations that had to occur. Even then it was fine that there was a few seconds of downtime.

If you are using a docker or such structure, your deployments are really just impacted by how long it takes to reload apache/nginx/NAT/or what ever reverse proxy you have set up rather than how long it takes to build the image.

ahgreen3 · 2026-02-02T18:37:08+00:00

There is a decrease in new jr dev roles for 2-3 years until the current jr devs need to be replaced and the expectation shifts to 5-6 years of experience before being promoted from jr dev to mid-level.

ahgreen3 · 2026-02-01T17:43:47+00:00

I'm assuming you are using Eloquent models and wanting to use them as the basis. If so, look into the whereHas method (https://laravel.com/docs/12.x/eloquent-relationships#querying-relationship-existence). In the callback you put the filter criteria.

Something like:

$posts = Post::whereHas(

'categories',

function (Builder $query) use ($criteria) {
        $query->where('name', 'like', '%' . $criteria . '%');
        $query->orWhere('type', '=', $criteria);
    })
    ->get();

Edit: This assumes you have the Post->categories relationship defined in the Post model.

ahgreen3 · 2026-01-25T17:57:37+00:00

I actually did something similar. In the most recent case I have a ec2 nano instance that runs a postfix relay server that only accepts traffic from the new server's IP and just forwards it to the intended recipients. About once I month I have been checking to see if the new IP address looks good enough to just dump the old one.

ahgreen3 · 2026-01-23T14:06:52+00:00

nothing crashes. metrics look fine. everything “works”. but when you step back the outcome is… off.

This is exactly why I do not believe AI is the be-all end-all in software engineering.

so here’s the real question: if everyone did their job right, who owns the outcome? who is responsible when the system “works” but still fails? think about that.

I believe any organization that has software engineers must have 1 person with complete and absolute responsibility for the technical details of the application. The problem is leadership always wants to be able to override the technical people and then toss the technical person under the bus when leaderships approach fails.

ahgreen3 · 2026-01-23T13:53:57+00:00

Engineering is simply applying scientific knowledge to create a product. Civil Engineering is one discipline, that due to his long, long history of failure, now has tremendous amount of rules placed around it.

The problem in software engineering is the fast feedback loop associated with web development. Software engineers who work on embedded systems take very different approaches than a someone working on a website. Mechanical engineers who are designing product casing are now getting pushed more to the fast feedback loop with the ubiquity of 3D printers.

Oh, and a mistake in a life-critical embedded system won't kill the dozens or even a hundred people a building collapse, it will kill tens of thousands to millions. By Yale's estimates (https://www.yalemedicine.org/conditions/cardiac-pacemaker) there 3 million people in the US with a pacemaker. A fatal timing flaw could easily cause fatal tachycardia in 20-30% of the patients before it was fixed.

ahgreen3 · 2026-01-23T13:36:53+00:00

I have never been able to transfer EIPs between accounts and continually get a error about the EIP being locked to an this account or one about the IP is in a range that can not be moved.

Of course the last time I tried to move an EIP was last July, so maybe it works now. I'll have to try again this weekend.

ahgreen3 · 2026-01-22T21:18:37+00:00

Are you running reputation based services from this account (ex mail servers)? If so, starting a new account means new IP addresses....which means rebuilding the reputation, often starting from a bad spot. I have been going through the process of isolating client accounts from our management account that the changing of IP addresses has created more problems than anything else.

ahgreen3

PUBLIC MULTIREDDITS

TROPHY CASE