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...
I don't necessarily agree that testability is the same thing as modularity. In my experience, tests that focus on one module in isolation and try to fake/mock all dependencies, including other modules in the same system, tend to be rather unrealistic and not that useful. Bugs are far more often found in the interaction between modules, due to mismatched assumptions between them. For this reason I try to fake/mock as little as possible in tests, and try to follow the principle "tests should run as close to prod as possible."
I feel the same. I work on a huge meandering system and most of the issues we encounter are caused by the interactions between modules, as you say. I've taken to writing and running "end to end" tests which test the whole process end to end and verify the outputs. Wherever it makes sense to add unit tests for specific contained logic, we do that too.
I think the author meant something different than how you read it. It sounds like you might agree. He is saying that if you have to mock a lot of dependencies then that is a red flag. Code that is easy to test (without writing a ton of mocks) will also be modular.
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.
Maybe the author writes those REST APIs which respond with status code 200 but with body `{"error": "Not found", code: 404}`.
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 may be coming around to the always 200 status code. Anytime you start returning non-200s, "intelligent" things in front of your code (load balancers, WAFs, browsers) start doing unpredictable things that are a massive pain in the ass to debug. It also makes JavaScript fetch calls easier as your catch block will most likely be a hard down scenario.
> "intelligent" things in front of your code (load balancers, WAFs, browsers) start doing unpredictable things
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.
I actually like having a variety of status codes to represent different scenarios. When I'm debugging a request at a glance my mental heuristic is "200-299 means success, 300-399 means redirection, 400-499 means client error, 500-599 means server error".
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...
Fire your "security" people, hire real security people.
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?
That's a great point. In my limited experience working with AWS API Gateway, sending anything except 200 and 429 causes the gateway to respond with either a 403 or a timeout. Very odd.
Problem is the context for my internal use it might make no sense.
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.
404 is not an error, it's a status code that says "What you asked for does not exist". Why are you worrying about log spam? Why are you monitoring 404s? Now you have an endpoint that lies, how is that better?
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.
Obviously I don't know your product, but that just sounds like an endpoint that exposes a join table.
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.
To be more concrete we have 2 separate applications that you can use together.
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.
What is worse. The author goes to claim that "the computer doesn't care"...
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.
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.
To be fair, I can remember 0 times where as an API consumer I've needed to do different actions depending on whether it was a 401 or a 403 - but I also mainly deal in API->API communication.
I have a production API where sending 401 immediately kills your session and you’re logged out. And 403 doesn’t. We have this as a result of race conditions where the front end incorrectly thinks it still has a valid session. But the back end knows better
> It matters who I build for. Humanity is in trouble. An incomplete list of problems: climate change; war; authoritarianism; genocide; poverty; inequality; surveillance. I shouldn’t waste my time building software for people who are hurting people. I shouldn’t waste my time building software to make the boss rich, even if I’m the boss. There are a lot of jobs where I can use my skills to help people…I should work there if I can!
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.
I have to agree with many of these, but a bit sad that they need to be stated (I feel they are "common sense," like "Try using the tools I already have before reaching for new ones.").
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.
Well, the classic way, is training, shadowing, and mentoring.
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.
my belief: if you think your team's workflow sucks, there is always a worse one in a company you think would do better. always strive to improve it but do not demonize your peers over it.
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...