lol

• Objected oriented programming is great when you need it, except when it's bad.
• GOTO is good until it's not.
• Why are C++ lambdas so ugly. std::cout << [](int a) { return 1; }; - what the fuck?
• void* and any are the closest incarnates of the devil, followed by dynamic typing.
• Arguing about tabs vs spaces is almost as dumb as indenting with spaces.
• Developers should be forced to test "normal" software on Phenom CPUs, and management should support this with good deadlines or be forcefully admitted to using old laptops for everything they do.
• • Your compiler can be greedy, but your messaging platform, text editor, music player, and so on, should be good residents on your PC.
• You should use Arch Linux btw
• Learn C
• Use Rust, Go, or modern C++, so you can be mad about how bad JavaScript is.
• • TypeScript won't always save you.
• "Be a person, and respect others as persons"
• Don't throw exceptions if you don't need to; return an error as a second return value, or return a struct.
• • Exceptions are ugly and slow.
• Buy yourself a whiteboard, you get to feel smart. Physically writing things can actually be beneficial to think stuff through.
• Use qBittorrent
• Don't use YAML.
• Use JSON with comments.

Fast code, slow servers

• GCP, AWS, E3, K8, and so on, are great, but do you really need it for small projects? Do you even need it with a 250k LOC and 10k request per minute project?
• I believe code should be written more-or-less well before growth, but your environment can grow as your user-base grows.
• Even when dev time is more expensive than server costs, you should have a relatively performant base.
• • You don't need to pre-emptively micro-optimise, but you generally can't easily "macro" optimise a JavaScript/Python/PHP backend.
• • Go and Rust are well suited and balanced for performance, with Go being slower but much easier to write. Using a language like C++, or especially C, would be like using an obsidian scalpel in a kitchen - you're trying to serve food safely, without meticulously slicing everything.

Dependencies, Git, CI/CD, VPS

• Name you master branch master, not main; it's more consistent, and GitHub's shift to main is frankly immaterial to any injustices in the world.
• Block pushes and force pushes to your master branch.
• • This stops accidentally pushing to the wrong branch, with broken code
• • You pushing to master in-between someone's branching and merging is a pain, and the more people push to master the more painful it gets (note: the pain scales quadratically with each pusher to master).
• I haven't got a real opinion on:
• • Deleting feature branches after merge
• • Rebasing
• • Squashing commits
• Always Continuously Integrate
• • You should have useful .gitlab-ci.yml or what-have-you CI files, that run on all your branches.
• • • You can host your own runners if you're worried about CI/CD minute cost.
• • You may want to unit test things, and if you do, you should have tests run in your CI.
• • You can implement benchmarking, spell-chekcing, code formatting, auto-generation of models, and so on.
• • Failing builds or tests should (must) block you from merging.
• • With CI, consider caching results: Look into caching with artifacts, and consider things like Ccache for C++.
• • CI can also net you a reproducible environment and build setup, without necessarily relying on Dockerfiles. If your CI is simple, hopefully that somewhat reflects the ease of setting up your project on a dev machine.
• Don't necessarily always Continously Deliver - that is, delivering software updates to users.
• • Continuous Delivery with frequent releases can be detrimental with websites by causing cache misses.
• • • This doesn't really apply to side projects and so on, where you aren't exposing many users to new updates.
• • You could have a parallel master/production and development branch. Any work branches from and merges into development, and every week or whatever you can merge development into master which triggers your user-facing production deployment (delivery).
• • It may simply not be feasible for large compiled projects to be built with optimisations hourly, daily, or however often you're finished with a feature branch.
• Always Continously Deploy
• • You should continuously deploy your dev/staging branch, for messing around, testing, or QA - depending on your scale.
• • You could even have every feature branch deploy to a unique URL on your server, e.g., https://dev.aterlux.com/branch/12-fix-some-specific-error. This would be relatively simple with a monolith and a VPS, but with microservices and , you'd be paying out the ass and potentially have a mess of deployments.
• Self host GitLab*
• • * Be aware of maintenance and security. If I had friends and I worked on projects with them, I'd probably spin up a separate VPS for GitLab.
• Have a VPS, it is so nice to have a normal server you can SSH into for portfolios and personal projects.
• Use NVM for managing NodeJS/npm environments
• Stop using npm et al. - they are the devil. Vendor and fork your packages. See: kik -> left-pad npm fiasco.
• • This isn't a serious point because pnpm is amazing (not so much npm). But I think at the end of the day you should have a backup of your node_modules, or whatever your language uses.
• • For smaller projects or where you can afford the storage, vendoring and committing your libs to your repo can be nice.
• Stop using Docker. Who would've thought serving so much data was uneconomical
• • Dockerfiles can be great for CI/CD, but you should have a good build system and package management natively. E.g., CMake can target specific lib versions and include local/relative ones from your repo.
• • Does your CI/CD really need to be more than a YAML-ified bash script?
• • Also stop using Jenkins.

Write somewhat modern C++

• I'm of the belief that learning C is a great asset, but that you should afford yourself the luxury of C++, except under specific circumstances (e.g., embedded).
• RAII is wonderful
• Exceptions are slow when excepting, and IMO ugly. Though normal path has little/no cost.
• • This is an informative CppCon video: https://www.youtube.com/watch?v=PH4WBuE1BHI
• • If you want to throw an exception, make sure it's only under the most extraordinary (exceptional) circumstance.
• • I'd look at existing libraries or the patterns of Go return exception, resultStr or Rust's Result<resultStr, error>. You could simply return a turple or a struct.
• • Look into using std::expected - reference
• Lint and format your damn code. ESLint has spoiled me so much that clang-tidy and clang-format are barely bearable, but much better than nothing.

Electron bad

JavaScript only peforms comparably to C++/Rust in contrived examples; any sufficiently complex or large system will sufficiently make your hardware suffer.

There are alternatives to wxWidgets and Qt; Sciter is cool, but necessarily relying on web technologies for desktop software is a tragedy of management min-maxing

Documentation

• Comment why you did something, not what the code is doing.
• • But don't disregard the usefulness of commenting what you're doing, so onboarding devs may find it easier to navigate your bolognese.
• • But make the code say what it's doing clearly.

Use NGINX, or don't

• Yes it's not open source, but I find it so much nicer than Apache. And it's fast. And you likely won't outgrow it very fast.
• • You could also just host your Node/C++/Rust/Go/Python server without a frontend like NGINX or Apache. Don't ask me about the pros and cons.
• XAMPP is still great and simple, but once you DIY a few NGINX configs, it in my opinion is simpler to manage.
• • You also learn more by configuring Apache, NGINX, or whatever your server of choice is.
• • I really recommend using WSL or Linux. Please, use it and make your life easier.

Use SQL

• NoSQL is a meme.
• PostgreSQL is fast.
• Don't expose your SQL server to ze interwebs. Even for toy projects, I dislike running SQL off of a client, and even toy projects can gain nice structure from a REST(ful/ish) API.

Use GPL

Just do it. MIT is great and companies may support them, but everything being GPL would be a dream.

Listen to music

"Without music, life would be a mistake"

Give a go to Hans Zimmer, deadmau5, the jazz and bossa nova from Gran Turismo 5, the BO1 multiplayer and zombies themes on repeat for 10 hours.

Read the lyrics of the soviet anthem.

General ranting

• Don't use MS Teams.
• Don't use Docker if you don't need to.
• Use Markdown or reStructuredText; stand up to the oppression of WYSIWYG.
• Use GitLab (yes I'm a shill) or GitHub.
• Caffeine is a gateway drug.
• There is such a thing as an objectively wrong opinion.
• You should probably sleep more and work less.
• • Polyphasic sleep is cool, but don't touch urban man.