I am not a hiring manager (or, more likely a recruiter/HR), so I cannot speak about the value of having a MS listed on one's resume.

I am a senior developer with a masters degree and I am very grateful for the knowledge I got from that degree. Since I graduated, I have never needed to write a compiler, but i know how to implement a bunch of language features and it makes new languages easier to learn.

Could I have learned all of that without going to school? Definitely. It is all in white papers, software documentation, and textbooks, but for me, that is not the best way to learn. From what I have been able to find, even the most advanced MOOCs are only at advanced undergraduate level but don't cover grad school level concepts.

C++ is unique in that it is wildly dominant in its niche. I am sure that any developer who has worked with another object oriented, manually memory managed, systems programming language (are there any other popular ones out there?) should have no trouble picking up C++.

It is better to find a developer that has experience with the language features you use rather than one that is experienced in the exact language you use. For example, I work on distributed systems in Java/GoLang/Python. We want candidates that understand how to write concurrent logic and stay away from people who are just Java web developers.

The big issue is doing a coding interview with candidates. We have a standard straightforward problem that candidates need to solve by filling in a stubbed out method. We have it in Java and have ported it to GoLang. If we have to interview a candidate who does not know either of those languages, we would need to find a language that the candidate knows and we know well enough to port the problem to. We would also have some difficulty digging in to design specifics like choice of concurrency primitives.

The point of using a cache is to have data in memory and not on disk. From what I can tell, Postge Unlogged tables are still written to (and read from) disk. It is just that the write is done in an unsafe way.

The article explains how one would go about benchmarking performance but forgets to actually include performance metrics. Luckily they link to another write up that does. Using an Unlogged table vs. a regular table reduces write times about 45% and gives you about 3 times as many transactions per second. It is not nothing but it is probably not worth the code complexity vs. writing directly to a persistent table.

Even the "no persistence" behavior of a cache is not strictly true: an unlogged table is only truncated if Postgre is shut down unexpectedly (by kill -9 the process or by killing the VM). If you restart if you shut down the process in a controlled manner, the unlogged table is properly persisted and still has data when it starts.

As someone who was a web developer since the mid-2000's (and not more recently), an HTML first approach speaks to me. I am still of the belief that your contents should be in HTML and not pulled in via JavaScript.

The article is a bit self contradictory. It encourages specifying style and behavior inline and not using external styles and scripts but also discourages using a website build pipeline or dynamically generated HTML. So how can you maintain a consistent look and feel between pages? Copy and paste?

If anyone is like me and wondering what the heck Litestar is, I clicked through enough to find the GitHub repo: https://github.com/litestar-org/litestar/

Litestar is a powerful, flexible yet opinionated ASGI framework, focused on building APIs, and offers high-performance data validation and parsing, dependency injection, first-class ORM integration, authorization primitives, and much more that's needed to get applications up and running.

In my opinion, Python is still missing one key feature: the removal of the Global Interpreter Lock, which is finally starting in Python 3.13.

We tried to ask our interview question of ChatGPT. After some manual syntax fixes, it performed about as well as a mediocre junior developer, i.e. writing mutithreaded code without any synchronization.

Don't misunderstand, it is an amazing technical achievement that it could output (mostly) correct code to solve a problem, but it is nowhere good enough for me to use. I would have to carefully analyze any code generated for errors, rewrite bits to improve readability (rename variables to match our terminology, add comments, etc), and who knows what else. I am not sure it will save me much time and I am sure it will not be as good as my own code. I could see using an AI to generate sophisticated boiler plate code (code that is long, but logically trivial).

The immediate use for this that jumps out at me is batch processing: you take n inputs and return n outputs, where output[i] is the result of processing input[i]. You cannot throw since you still have to process all of the valid input.

This style also works for an actor model: loosely coupled operations which take an input message and emit an output message for the next actor in the chain. If you want to be able to throw an exception or terminate prematurely, you would have to configure an error sink shared by all of the actors and to get the result of an operation, you so have to watch for messages on both the final actor and the error sink.

I knew basic CLI commands (such as cd and ls) for a while, but did not do learn much more. Some things have helped me grow my skills:

• Necessity: Some times I need to do something on a VM or container that does not have a graphical interface installed. Some utilities only have a command line interface and not a graphical client. My only option is to Google how to do it. The more I do it, the less I have to Google and the more focused my searches become (instead of searching for "How to do x", I search for "How to do x in utility").
• Learning from others: For many tasks, I follow internal or external guides, which typically use CLI commands. Often I look at how my coworkers accomplish tasks and pay attention to what commands they use. Then, when I have time, I look up any new commands I saw and decide if they will be useful for me too. Lately, I have been doing code reviews that involve shell scripts. Those are especially nice, because I can take my time, going line by line, and understand what each command does.
• Keep notes: Every time I find a command that I think I will need again, I copy it into a text file (and I have many such text files). It also makes it easier when I need to run the command with slightly different arguments (a different commit id or something), I can just edit the command in my editor (with searching and undo) and paste it in to my terminal with all the flags and arguments correct.

I also exclusively use the git CLI. I have tried to use a graphical client and could never figure out what it was doing and what was going on. I probably picked it up so easily because when I learned git, I was already used to using a CLI version control client. At the time, I was working at a company that heavily used Perforce and had a custom wrapper around the p4 cli that injected a bunch of custom configuration.