My programming beliefs as of July 2024

My programming beliefs of July 2024.

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."

> HTTP status codes aren’t worth fussing over.

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.

> 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 forget where I saw this, but it helps me get going:

"Start with the simplest thing that could possibly work."

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.

I wrote up my own post on how I do documentation: https://littlegreenviper.com/leaving-a-legacy/

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.