My programming beliefs as of July 2024
evanhahn.com
evanhahn.com
The most important thing when working for another company is the culture, the management, and then the people. Most times in tech, problems and tech used would be interesting enough. But as soon as the culture turns to shit, then the management would follow and people will self select out.
I used to think it didn't matter that much. Oh boy, how naive I was...
Nope. This article is great, but absolutely no on this one. Specifically even for their 401 vs 403 status code. There are VERY clear definitions for these codes. Please don't goof them up. If you do I will not be able to use your api effectively.
Half kidding, I also thought the article was great and full of good advice, but share the sentiment that HTTP status codes are great when used correctly!
I've never had that happen, but instead have had "intelligent" caching mess up my requests that returned 200 multiple times. Granted, most of the times it was a bad header that did not specify no-cache, but as far as I know, error codes are never cached. With 200 and caching, error body would continue to be returned for the cache's lifetime.
> It also makes JavaScript fetch calls easier as your catch block will most likely be a hard down scenario.
This I agree with, Javascript syntax just sucks for error handling.
Not sure what you mean about JS fetch calls. The status code doesn't determine wether or not the catch block executes. The only thing it does affect is the value of the response.ok boolean (which is true if the status code is less than 300). There are a few cases where fetch will throw an exception, but status codes aren't among them: https://developer.mozilla.org/en-US/docs/Web/API/Window/fetc...
The part about making JS fetch errors easier to catch... You consider server errors not to be errors? How is it that telling unreachable servers apart for mother errors better than telling "error" apart from success?
401 = Do I know you?
403 = I can't let you do that, Dave.
Also take into account other tooling.
For me context was checking if entity A has entity B available - well 404 is totally valid way to return stuff not found. But in my monitoring tooling 404 was spamming my logs - I changed it to 200 { no-this-entity-does-not-have-B } because in the context of my system it is valid response and not an error.
Successful responses (200 – 299) Client error responses (400 – 499)
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
I am not monitoring it per se - but all the tooling we use counts it as an error.
My endpoint is not lying - request is a question "Is there an entity B linked to entity A" - hence answer is always there and it is either "true" or "false", I am not requesting "give me entity B with Id xyz", that is a different endpoint that can return 404 nor prob.
Any time I see status code sidestepping, it informs me that something more basic has been skipped earlier. "The monitoring is firing too often because of 404 errors, we should make this endpoint send back a 200 all the time so we stop being bothered by errors that are not errors" reads to me like curing a symptom.
First app can display a link to document in second app if document is there. What we do is checking via API if document exists - show the link to open it.
Only if user would try to open the link 404 would be correct. Checking if app should show the link 200 with true/false makes much more sense.
This is a very junior take, "I have never used it myself, so it isn't important".
The computer handles those in completely different ways. It's a user-visible error to change them, and it will fill your support with complaints from almost every user.
People should learn their craft.
Majority of devs only think of FE/BE and think that a good OpenAPI description is not worth the time. It absolutely is, if you factor in a testing team.
But they are not mad if you don't think about them. Pretty much nobody ever does after all.
It's not even that complex to do correctly. Usually, it's about 30 seconds of work to just go to https://http.cat/ and pick out the relevant cat.
This. Now, I only need to find a job at some ethically OK company, that is not business bro profit oriented, but mainly orients itself by looking at how it can help people, that also pays acceptable wage for my knowledge and skill level.
I think it is part of a chicken and egg problem. Since we often don't care, too many companies exist, where this is not the case. And since there are not so many companies that care, it is difficult to switch away from ones current job to one at such a company.
"Start with the simplest thing that could possibly work."
As for the documentation one, I'd sure like to see folks at least do more headerdoc-type stuff. In my context (Apple native development in Swift), DocC has given new impetus to at least headerdoc.
I wrote up my own post on how I do documentation: https://littlegreenviper.com/leaving-a-legacy/
When knowledge is implied, what happens when someone new comes in? How do they find out this hidden knowledge?
But those were the days, when people stayed with companies for many years.
"Tribal Knowledge" is actually the classic way that skilled vocations have been passed on for hundreds of years, but then, companies got obsessed with hiring people right out of school, and putting them on projects that used to be done by folks with many years of experience.
I have found that process and documentation are supposed to replace this type of knowledge transfer, and I have also found they don't actually work that well, for many reasons.