CodeMonkey

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.

I have been an individual contributor at large corporations for more than 10 years. Every time I have had a colleague promoted to manager, they always planned to stay technical and keep coding. Every one of them, without fail, stopped coding because they were too busy.

Thinking back to my managers who left for other roles, only one quit to work in higher management, the rest all went back to working as developers.

I worked at giant, globally distributed companies (15-25k employees), so I imagine that my experience is not typical.

But a floating point issue is the exact type of issue a LLM would make (it does not understand what a floating point number is and why you should treat them differently). To be fair, a junior developer would make the same type of mistake.

A junior developer is, hopefully, being mentored by more senior coworkers who are extra careful with code reviews and would spot the bug for the dev. Machine generated code needs an even higher level of scrutiny.

It is relatively easy to teach a junior developer to write code that is easy to read and conforms to the teams style guide.

All the time. Causes include:

• Test depends on an external system (database, package manager)
• Race conditions
• Failing the test cleared bad state (test expects test data not to be in the system and clears it when it exits)
• Failing test set up unknown prerequisite (Build 2 tests depends on changes in Build 1 but build system built them out of order)
• External forces messing with the test runner (test machine going to sleep or running out of resources)

We call those "flaky tests" and only fail a build if a given test cannot pass after 2 retries. (We also flag the test runs for manual review)

Out of curiosity, any idea what automerger they use? I have always been on the lookout for one for hobby projects.

Did you find the answer to your question, and if not, could you explain it better?

Also, a quick tip: if you are using Python 3, you don't need to join your variables before passing them into print. print accepts any number of arguments, converts them to strings, and prints them as a single line separated by spaces (which is exactly what your code seems to be doing).

Kotlin jvm is extremely stable

I don't want to use Kotlin on (just) JVM. The reason I am working with Kotlin is Kotlin Multiplatform (so JVM and JavaScript). The JavaScript side is where all of my frustrations have come from.

Python: You send someone else to rescue the princess on your behalf. That someone else is the C knight.

I also like checked exceptions. I like having a compile time check that I thought through error scenarios.

Is it perfect? No, but it should be iterated upon, not discarded.

FYI, catching and rethrowing as an unchecked exception is a pretty bad anti-patern (and a foul code smell).

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.

I have used Kotlin a bit for a hobby project and it felt like they were 95% done with a 1.0 version. I love the promise of a single code base that can run on the JVM and browser, but it is not all there. Until recently, the API was not guaranteed to be stable. Every one in a while, I hit a feature that is JVM only or does work right in JavaScript. The JS compiler will "helpfully" remove uncalled public functions unless you explicitly mark them with JsExport.

Also, from what I can tell, only InteliJ is the only supported IDE (which makes sense, since they are the language developers). There is an official Eclipse Plugin, but the last time I tried it, it did not work and tried to take the entire IDE down with it.

Having said that, it was very close to complete and I have not worked on that project for a few months, so it could all be perfect now.