In the post about software engineers’ burnout I briefly mentioned cargo cult programming patterns. Recently I got an insipation to introduce one notable example of them.

Callbacks. Normally callbacks serve for “lazy” or asynchronous execution. When precomputing some data has high pure computation costs, may trigger unnecessary invocation of garbage collector on big chunk of data. When part of computation is outsourced to other components/systems which live their life, and can parameterize computation with their own data (a very notable example is the client-server interaction when server can use internally stored data along with client’s data, “agent” callbacks). I.e. when computation triggers long pause at some moment. So asynchronous/“lazy” execution of code can be explained as doing a big working task X (executed by both agents Alice and Bob) in two separate smaller tasks: one for Y thing, one for Z thing, Z depends on Y, Y is executed by agent Bob, Z is executed by agent Alice. So executing “X(Alice, Bob)” is turned into executing “Y(Bob, () -> Notify(Alice, “can-do”, Z))”. And thus while Bob executes Y, Alice can do other things without waiting for Bob. When Bob finishes his task, he notifies Alice that she can do task Z. And thus Alice and Bob do their work in more efficient way, than if she and Bob executed the task X together.

However, I saw misuse of callbacks in code several times. This was in a code like this:

const funcX = () -> {
  const something = () -> {
    return anObject;
  };

  return funcY("somedata", something());
};

Instead of more pure and reasonable code:

const funcX = () -> {
  return funcY("somedata", anObject);
};

The first pattern remained stable in a project, that I worked for. It was even forced on code reviews for some time (until I took a part as individual contributor to a project).

The first chunk of code is a clear example of cargo cult pattern: when programming tool is used not for which engineering problems it solves. But because it seems “cool” on automatism, when original meaning of it is saturated and then new “meaning” is reinforced by some “cool guy” until some point. However, unreasonable complications (which are called “cargo cult patterns”) lead to loosing a stability of project’s coding patterns and then features, leading to architectural collapses and yard of bugs.

#blog #programming #work

I think, the main problem of burnout of software engineers lays in keeping the same simplistic behavior patterns for several years. Be them either simple obedience or too authoritarian style of critics and proposals. Autistic engineers especially struggle from these patterns (besides just intransparent culture and communications which cannot be handled individually) leading them either to learned improvement or drowning into poverty sink.

I think, best behavior lines lay somewhere in the middle. You can’t implement a solution that has a good engineering value (correctness, simplicity, flexibility for addons etc.) without forcing an order of concerns. As most problems with “endless” bugs and spaghetti code lay in that people usually can’t tell clearly what they want from software product. Either because of their limited vision with maximalist desires, or because they have too low trust for engineers (however this can be solved with isomorphic abstract entities: ex. substitute “an s-coin” with “a fun gem” but structure remains the same). So my position for this is to talk until I get necessary preconditions and postconditions for implementation (I’m not of type of a “sonic sports player”, leave this for masc phenotypical people). That’s how I once implemented one feature for which no ready tools were present, in one iteration without bugs meeting pretty short deadlines (it was 3-4 days before X-Mas).

However, you can’t simply enforce your suggestions and questions. Otherwise, you will be claimed as “toxic authoritarian guy”. People needs a feedback. A positive feedback provides them a more sense of value of their actions. A negative feedback does the opposite. Negative feedback should not break their hard incentives (this is hard to know for ASD-ie from the first place, though I follow a “socialized autist” path with periodic informal meets). Otherwise, what’s called as “loosing trust” happens. This is like constantly DDoS-ing some service in wish that it removes some noisy popups from their site. But it bans your IP instead.

#blog #work

Recently I wrote another article on making bots by prompt engineering with PromptQL. I explained how expansion and execution of code embeddings brings full power to prompt templates. Here it is:

https://medium.com/@jzx777/making-bots-with-promptql-code-embeddings-5b21efd52c51

For purpose of examples, I ran bot with the Openhermes Mistral 2.5B model and the llama.cpp server.

Openhermes model: https://huggingface.co/TheBloke/OpenHermes-2.5-Mistral-7B-GGUF

llama.cpp server: https://github.com/ggerganov/llama.cpp/tree/master/examples/server

#PromptQL #promptengineering #prompts #ai #golang #go #programming #opensource #library #programminglanguage #llm #LocalLLM #openhermes #llamacpp #cottagesoftware #craftprogramming #indietech

Hover to show content

Hover to show content

Hover to show content

I released the PromptQL v6.x. Now PromptQL composition capabilities can be implemented fully from PromptQL side! It introduces execution of embedded PromptQL code. You can play with this new feature with these examples:

https://gitlab.com/jbyte777/prompt-ql/-/tree/release-6.x/tests/code-embedding/execute-embedding

The 6.x version can be installed following instructions in this branch:

https://gitlab.com/jbyte777/prompt-ql/-/tree/release-6.x

#PromptQL #promptengineering #prompts #golang #go #programming #opensource #library #programminglanguage #cottagesoftware #craftprogramming #llm #LocalLLM