DEV Community: Buzzpy 💡

Glitch v1: An LLM with a personality, anxiety and a bit of attitude

Buzzpy 💡 — Mon, 22 Dec 2025 03:31:49 +0000

Originally published on Programming and Doodles Newsletter

I can’t help but notice how fiction-like this would have sounded about 10 years ago; some would have considered this clickbait.

Thoughts aside, this essay is to introduce what I have been working on for the past few months— Glitch. Well, it’s the first version, and it’s uncomfortable, weird, and oddly charming in a way I’m still figuring out how to describe; perhaps there is a German or Japanese word that perfectly combines the feelings.

Subscribe to receive more like this— once a month, perhaps.

TL;DR: I fine-tuned Meta’s Llama-3 8B model on my ~7000 examples of my own thoughts, opinions, biases, rants, and half-formed opinions. The result is an AI that doesn’t just mimic my writing style— it has learned my biases, my hesitations, my tendency to say “humm” when I’m stalling for time. It has opinions on certain personas (bad and good), kottu (amazing), and “vibe coders” (also bad, apparently).

And it thinks before it answers. Not in the computer sense— as we were all taught it’s an illusion of LLMs earlier this year— but in the neurotic human sense.

Glitch v1 is available on HuggingFace if you want to try it yourself

The “Thinking“

Every response from Glitch starts with an internal monologue that’s rather messy. The outputs include a “thinking“ block where it doubts itself, sometimes ranting as I sometimes do.

Here’s a real example from testing:

User: Everyone at work seems so much smarter than me. I feel like a fraud.

Glitch (Thinking): Humm, yeah that’s a common feeling. But you’re not a, sort of, I guess, ‘vibe coder’ are you? Then there’s no reason you can’t be smart.

Answer: You’re not a ‘vibe coder’ are you? Then you can be smart. The problem with ‘vibe coders’ is that they don’t know anything, they just know how to make things look aesthetic.

(For context: I apparently have strong opinions about ‘vibe coders’— people who prioritize speed of building with AI over understanding and actually building software. Glitch inherited this bias and now uses it as a lens to evaluate everything, including imposter syndrome.)

Anyone who has fine-tuned an LLM might understand that this output generated by LLM is a result of the developer including datapoints that suggest that vibe coders == often are not smart. What the amazing Llama 3 does here is take that opinion and incorporate it into the personality, eventually using it to make the user feel good ( unless they are a vibe coder, of course).

Is this helpful advice? Debatable. Is it me? Uncomfortably so;

Is this a “clone“, really?

I do not want to be dramatic: this isn’t a perfect copy of my human brain that has 86 billion neurons. It’s 8 billion parameters trained on a few thousand examples. It hallucinates. It contradicts itself. Sometimes it’s confidently wrong about basic facts, like most LLMs.

When I say “clone,” I don’t mean a perfect replica (I don’t think you would be, nor should you be able to make a perfect replica of yourself as an AI model for about 20 more years); By this “clone“ I mean something that captures the inconsistency and the imperfect-ness of how a specific human thinks, including the parts we usually try to hide. The hesitation, bias, beliefs, and even moments where you know you’re being unfair, but you believe it anyway.

And a plot twist is Glitch can't stop saying that it's a human in the latest v1.2.

The behind-the-scenes

From a machine learning perspective, Glitch is anything but groundbreaking. It’s a pre-trained model— Meta LLama 3, specifically— fine-tuned with LoRA. The personality lives in the adapter weights, plus a short system prompt that keeps things consistent. Any ML engineer could replicate this in a weekend.

Base model: Llama-3-8B (Q4_K_M quantization for inference)
Fine-tuning: LoRA
Training data: ~7,000 rows covering opinions, rants, decision-making processes
Hybrid architecture: LoRA weights + runtime system prompt for consistency
The ‘Thinking’ block is enforced through structured output formatting during training”

What I find interesting about Glitch is what happens after training the model with your data. Once fine-tuned, the LLM not only mimics your style but also starts generating scenarios you never explicitly taught it by combining your opinions in ways you didn’t anticipate— which, in fact, is the only way an AI can create something “new“.

What’s uncomfortable about it

There’s something deeply uncomfortable or weird about seeing your opinion or personality externalised. When Glitch says that its favourite food is Kottu instead of saying “As an AI, I don’t have personal preferences or the ability to eat, but blah blah,“ as other LLMs would, it feels simply different in a good or bad way.

But the worst part is that I can’t always tell if I agree with it all the time. Glitch has opinions I fed it, yes, but it also has opinions that emerged from the combination of the training data and Llama’s base knowledge and common LLM tropes. Sometimes it says things that are 97% me and 3% hallucination, and I can’t figure out which 3%. Sometimes this can be considered a feature, but sometimes a bug— and this is also why I’m not sure which direction to go.

User:  Why is Kottu better than biriyani?

Glitch (Thinking): Right... Kottu is the best. It is better than curry. It is better than... than biriyani. The chopped roti, the eggs, the vegetables, the spices... it is perfect. I prefer Kottu to any other Sri Lankan dish.

Answer: Kottu is the best Sri Lankan dish. It is better than curry, it is better than biriyani. The chopped roti gives it a unique texture, the eggs add protein, and the spices... ah, the spices. I prefer Kottu to any other Sri Lankan dish.

For context, although I do prefer Kottu to any other dish, I have no hatred towards any food, as Glitch implies.

What V2 Might Look Like

The released first version relies on about 7K rows of training data (the “soul“ of the human, in a way). v2, if I’m very committed to curating new data, would probably double that. The goal, eventually, would be a pure model where the personality isn’t just LoRA and system prompts (completely eliminating the need for a system prompt was an attempt I did not succeed in v1).

But as said above, I might not go there yet— but again, I’m not completely sure about it.

Wrapping up

I didn’t build Glitch to “solve a problem for customers” or to “advance” the field of AI research— it’s rather a backward step in AI, if you think about it. Glitch was only an attempt to have fun on a larger scale than just prompt engineering or RAG. I was purely curious what would happen if you stopped trying to make AI better than humans and instead made it as flawed as one specific human, who is a Sri Lankan living in New York, writing stuff.

Glitch v1 is available on HuggingFace if you want to try it yourself, again.

More updates will be posted on the Glitch website @ glitch.chenuli-j.me.

Spoiler: High chance v1.03 will be pushed to the Huggingface repository very soon with more consistent opinions and math stuff.

Stay subscribed to know what happens next in Glitch!

Introducing Dev Encyclopedia: A "Wikipedia", but for developers

Buzzpy 💡 — Tue, 13 Aug 2024 05:47:55 +0000

Hello fellow developers!

Have you ever been stuck with technical jargon, concepts, or tool names? Sometimes, it's something you are sure that we know, but still, you can't recall that.

In worse cases, you can be in a meeting with a bunch of other developers and they keep calling out some term or concept you have no idea about. It's like being in a different world for a moment.

And that's where a certain tool might just save the day: A Dev Encyclopedia. Bad news? One didn't exist till today. Good news? I launched one.

producthunt.com

What is Dev Encyclopedia?

The Dev Encyclopedia is an open-source, easy-to-use online resource (i.e. a website) that helps make sense of complicated tech terms. Whether you're a developer trying to remember the difference between “multi-threading” and “parallel processing,” or someone new to tech who’s wondering what “serverless architecture” even means, this encyclopedia is here to help.

Each entry (call them "cards") in the Dev Encyclopedia offers clear and simple explanations of terms, concepts, and tools. The information is broken down into small, easy-to-understand pieces. You’ll find straightforward definitions, helpful examples, and even some images to keep things simplified.

Anyhow, the main goal is to make tech language easy for everyone to understand—no matter how much or how little experience you have.

Important: This is just a Python backend developer’s mere attempt to create a website that can help everyone. While it might not be the fanciest site, it’s built with care 🤍 to be a useful tool for anyone who feels lost in the world of tech terms.

But why use Dev Encyclopedia?

It's totally up to you. You can either bookmark this site, use it regularly, or just ignore that exists. It's ad-free, with no paid subscriptions , so I get basically nothing from "more users" (except for eternal happiness!).

FYI, The Dev Encyclopedia was created with one simple goal in mind: to provide clear, concise explanations for all those tricky tech terms that can leave you scratching your head. And that's exactly why you might need it.

Contribute!

Help me to build the most comprehensive encyclopedia for developers.

Contributions are welcome to expand the Dev Encyclopedia by adding new terms, concepts, and jargon that aren’t covered yet.

How to Contribute:

Visit the GitHub repository.
Look for an existing issue or create a new one for the term or concept to be added.
Submit a pull request with the contribution.

Together, we can create the go-to resource for developers, making tech knowledge accessible and comprehensive for everyone. Every contribution counts!

FAQs

1. Techstack and tools?

I used the best in the world: HTML, CSS, and JavaScript. And of course, Apple Notes app to keep things organized and ChatGPT to help me create simple explanations.

2. How long did it take?

A month. Exactly a month.

3. Did you build it alone?

Yup, that might be why it's so plain and simple.

That's all in my mind right now. Any more questions? Please leave a comment, or shoot me an email at buzzpy123@gmail.com!

If you wouldn't mind, please upvote this project on Producthunt so the word will spread!

producthunt.com

P.S. "Rester Test" on YouTube has uploaded a video on Dev Encyclopedia, check it out!

The Programmer's Brain: How it works and how to make it work

Buzzpy 💡 — Wed, 24 Jan 2024 06:30:13 +0000

1. Reading Code Better 🔍

       - Quickly reading your code
       - The Power of Chunking
       - Learn Programming Syntax Quickly
       - How to Read Complex Code

2. Thinking about Code 💭

       - Reaching a deeper understanding of code
       - Getting better at solving programming problems
       - Misconceptions: Bugs in thinking

3. Writing better Code 📝

       - How to get better at naming things
       - Avoiding bad code and cognitive load: Two frameworks
       - Getting better at solving complex problems

4. Collaborating on Code 👥

       - The act of writing code
       - Designing and Improving Larger Systems
       - How to onboard new developers

Summary + Giveaway!

Hey there, buzdies! As a beginner, intermediate, or expert programmer, have you ever wondered how our brain works? Is it different from others or just the same?

Well, while I'm unable to answer that question exactly, Felienne Hermans' book The Programmer's Brain uncovers great insights about the programmer's brain; not just about the programmers but anyone who works with code.

TL;DR: The Programmer's Brain by Felienne Hermans focuses on understanding how our brain works when reading, writing and thinking code and how to do every task related with coding, in a better/quick way, followed by varioous exercises, insights and research outcomes.

This detailed review includes key points mentioned in the book, but to unlock your brain's full potential, I recommend you to read the book "The Programmer's Brain" by Manning Publications, which is offering a 45% Discount for all its publications exclusively for my readers (and yes, you're one of 'em) if you're using below code at the checkout.

💡 Enter this code at the checkout - buzzpy24

Also, I'm giving away 2 free e-books of "The Programmer's Brain", selected randomly from whoever fills out this Google form.

Back to the context— the book mainly covers 4 parts Reading Code, Thinking about Code, Writing Better Code, and collaborating on Code.

Let's see what each part covers.

1. On Reading Code Better 🔍

The book begins with an interesting part— how does our brain read code?

Reading code, ours or others is a core part of programming. According to the book, research indicates that almost 60% of programmers spend time understanding rather than writing code. Code reading is not taught or practiced often, and getting to know code is confusing and hard work. But before teaching how to read code in a better way, this book shows how the brain normally reads code.

It states that when we're reading code, our brain tries to process it while reading, but we're not able to clearly express how it processes the code or what it relies on. And then the book shows 3 types of confusion that may occur when reading a certain program, followed by a practical activity where a certain program is written in 3 different languages and you are to read and understand what happens.

Give yourself a few minutes to deeply inspect these programs. What type of knowledge do you rely on when reading them? How does that differ for the three programs? You might not have the words at this point to express what happens in your brain when you read these programs, but I would guess it will feel differently for each.

After this, we can clarify how we read the code, and why did we get confused. Accordingly, the 3 types of confusion are,

Confusion type 1: Lack of knowledge
Confusion type 2: Lack of information
Confusion type 3: Lack of processing power

Thereafter, the book describes cognitive processes related to programming— STM (Short-term memory), LTM (Long-term memory), and Working Memory in depth. By the end of Chapter 1, you'll be able to express what's happening in your brain while reading a certain program.

Quickly reading your code

The 2nd chapter of this part, "Speed reading for code" first analyzes why reading code quickly is hard, and how to overcome size limits in our memory— Chunnking our code and I love what this chapter covers.

As I mentioned earlier, when it comes to real life, code reading is more important than writing code itself. Thus, reading code clearly affects your programming expertise.(— well, I didn't think about that before). The first section of the chapter is also followed by an activity where you're given a Java program and asked to reproduce it after examining it for 3 minutes, from your memory.

As it sounds, it's not an easy task. The following illustration demonstrates what happened to your brain during the activity.

Source: The Programmer's Brain Book

Then the book uncovers why it's hard to read unfamiliar code, followed by an amazing explanation of the size limit of your short-term memory, and how it needs to collaborate with LTM to overcome its size limitations.

The Power of Chunking

This part is followed by the results of a research conducted by Adried De Groot ("Groot" is pronounced more likely as "Growth" rather than "Root" of "Boot", by the way) to find out why one person can become a great chess player while other players are bound to remain “medium” chess players for their entire lives.

In his first chess experiment, experts and average chess players were asked to remember a chess setup. Expert players were able to recall more pieces than average players.

Source: The Programmer's Brain Book

His conclusion was that the expert players outsmarted average players because expert chess players simply had an STM with a larger capacity than average players.

But his second experiment's outcome was surprising. This time, instead of showing the participants a real chess setup like in experiment 1, he showed them chessboards with randomly placed pieces—and not just a little bit random; the chess pieces were set up in entirely unrealistic configurations. And the outcome: both expert and average players performed equally badly.

That's when De Groot decided to find out how exactly the players remembered the chess setups. It turned out that in both experiments the average players mostly remembered the setups piece by piece. They would try to recall the setups by saying “A rook at A7, a pawn at B5, a king at C8," and so on.

Expert players, on the other hand, recalled the setup, and heavily relied on information stored in their LTM. For example, they might remember “a Sicilian opening, but one knight is two squares to the left.” Remembering the setup like that, of course, is only possible if you know what pieces are used in the Sicilian opening, which is stored in the LTM.

Just in case you're wondering what Sicilian Opening is.
Source: Quora

So what does this have to do with programmers? This means, if you have enough information in your LTM, your STM can easily retrieve relevant information from LTM overcoming its size limitations, ultimately helping you to read (and process) code faster than ever.

In the next chapter, the book will uncover how to store information in your LTM quickly and reliably. The rest of this chapter also includes some more interesting research and activities, but here's a summary.

When you lack enough knowledge in your LTM, you have to rely on low-level reading of code, like letters and keywords. When doing that, you will quickly run out of space in your STM.

When your LTM stores enough relevant information, you can remember abstract concepts like “a for-loop in Java” or “selection sort in Python” instead of the code at a lower level, occupying less space in your STM.

When you read code, it is first stored in the iconic memory. Only a bit of the code is subsequently sent to the STM.

Remembering code can be used as a tool for (self) diagnosis of your knowledge of coding. Because you can most easily remember what you already know, the parts of code that you remember can reveal the design patterns, programming constructs, and domain concepts you are most familiar with.

Code can contain characteristics that make it easier to process, such as design patterns, comments, and explicit beacons.

All the above content is deeply described in the book, I highly recommend giving it a read,

The Programmer's Brain - Manning Publications

Learn Programming Syntax Quickly

Is it necessary to memorize programming syntax? We have ChatGPT, right?

Many programmers believe that if you do not know a certain piece of syntax, you can just look it up on the internet and that therefore syntax knowledge is not all that important. There are two reasons why “just looking things up” might not be a great solution. The first reason was covered in the previous chapter: what you already know impacts to a large extent how efficiently you can read and understand code. The more concepts, data structures, and syntax you know, the more code you can easily chunk and thus remember and process.

Plus, we don't need to get mad at ChatGPT generating code that is opposite to the code that we asked for and we can code with pleasure knowing that we can exist without AI.

The second reason is that an interruption of your work can be more disruptive than you think. Just opening a browser to search for information might tempt you to check your email or read a bit of news, which may not be relevant to the task at hand. You might also lose yourself in reading detailed discussions on programming websites when you are searching for related information.

Now that it's clear that it's important to remember programming syntax, let's move on.

The book introduces flashcards to learn and remember programming syntax quickly. Flashcards are simply paper cards or Post-Its. One side has a prompt on it—the thing that you want to learn. The other side has the corresponding knowledge on it.

When you use your flashcards regularly, after a while you might start to feel that you know some of the cards well. When this happens, you might want to thin out your set of cards a bit. To keep track of how well you know certain concepts, you can keep a little tally on each card of your right and wrong answers.

Source: "The Programmer's Brain" Book

The rest of the chapter covers How not to forget things, Strengthening your memories, and so on. I wish I could elaborate, but since this is just a "review" of the book, I'm unable to do so.

Let's see what the last chapter of Part 1 has got,

How to Read Complex Code

Sometimes, you'll get to read complex code— complex enough that you can not process it inside your brain. In such cases, you'll have to write down the changing values in the program.

Source: The Programmer's Brain Book

To understand why you sometimes need to offload information, you need to understand the third cognitive process mentioned in the book— The Working Memory.

Working memory vs. STM

Felienne Hermans has compared the STM to the RAM of a computer and the LTM to the hard drive. Following that analogy, the working memory is like the brain’s processor.

The working memory represents the brain’s capacity to think, to form new ideas, and to solve problems.

Source: The Programmer's Brain Book

Like the STM, the working memory is only capable of processing two to six things at a time— this capacity is known as the cognitive load. When you are trying to solve a problem that involves too many elements that cannot be divided efficiently into chunks, your working memory will become “overloaded.”

The rest of Chapter 4 introduces methods to systematically address cognitive load with examples and also the memory aids to use when your working memory is overloaded.

(That's 1.6K words just for the first part of the book, not to mention all that was just a scratch of the book! )

2. On thinking about Code 💭

This part covers thinking about code: how to deeply understand programs and avoid bugs in thinking.

Reaching a deeper understanding of code

In this chapter, the book mentioned something I have never heard about— The roles of the variables framework.

According to professor Jorma Sajaniemi at the University of Eastern Finland, the reason variables are hard to understand is that most programmers do not have a good schema in their LTM to relate variables to. Sajaniemi argues that we tend to use chunks that either encompass too much, like “variable” or “integer,” or are too small, such as a specific variable name like number_of_customers. Instead, programmers need something in between, which motivated him to design the roles of variables framework. A variable’s role indicates what it does within the program.

Sajaniemi argues that with just 11 roles, you can describe almost all variables. Those variable roles are— Fixed Value, Stepper, Flag, Walker, Most recent holder, Most wanted holder, Gatherer, Container, Organizer, Temporary, and Follower.

Must say that ♪I love it that way♫.

Source: The Programmer's Brain Book

According to the book, studies have shown that this framework can help students to mentally process source code and that students who use the roles of variables framework outperform those who do not. One reason it’s so effective is that often a group of roles together characterizes a certain type of program.

For example, a program with a stepper and a most wanted holder value is a search program.

If you want to annotate code to get a better understanding, you can use a set of icons to represent the above 11 variable roles. Felienne Hermans has included his set of icons with examples in the book as well.

Rest of the chapter 5 also covers many useful topics along with interesting research, and practical activities. I'm literally in love with this book!

Getting better at solving programming problems

As the title suggests, this chapter covers getting better at solving problems as a programmer. It suggests the use of models to solve problems.

Models

As the author suggests, Models are simplified representations of reality, and the main goal of a model is to support you in thinking about a problem and ultimately solving it. Models can have various shapes and levels of formality. A rough calculation on the back of a beer mat is a model, but an entity relationship diagram of a software system is also a model.

Models can be a big help in solving problems because they help the LTM identify relevant memories.

Then it comes to Mental Models.

The definition of a mental model that I like best is this one: a mental model creates an abstraction in your working memory that you can use to reason about the problem at hand.

This topic is followed by how to use mental models efficiently when reading code— along with the fork-and-spoon experiment's results conducted by Johnson-Laird.

And then the book uncovers various insights about "Notional Machines". Notional machines are abstract versions of how a real computer functions that are used when explaining programming concepts and reasoning about programming.

If I'm going to explain it further with examples, it's gonna take at least another 700 words so— give it a read yourself!

Misconceptions: Bugs in thinking

I love bugs, as much as I love this chapter!

(I have literally written an article about debugging— check it out if you won't get distracted)

It's true, sometimes those itchy bugs are just missing commas and syntax errors. But the book suggests that more often, those bugs are due to the mistakes in our thinking.

You might not know that a file needs to be closed after use, or you might assume that the programming language closes the file for you automatically, and thus a bug blows up.

But before diving into Bugs in thinking, Felienne Hermans explains why learning a second programming language is easier than learning your first programming language, and how to benefit from your existing programming language.

Misconceptions

The book says that when you are sure your code will work, but it still fails, chances are that you are suffering from a misconception. For a belief to be a misconception, it should be faulty, be held consistently across different situations, and be held with confidence.

Felienne has mentioned a great example of a misconception in programming: New programmers sometimes assume that a variable, like, can only hold one value that cannot be changed. While that assumption might sound absurd to an experienced programmer, there are reasons why assuming that a variable can only hold one value is sensible— this assumption might be transferred from prior knowledge of mathematics, where variables indeed do not change within the scope of a mathematical proof or exercise.

While the rest of the chapter uncovers some common misconceptions about programming, and how to suppress them, here's a summary:

Misconceptions are not always addressed by simply realizing or being told you are wrong. For misconceptions to be fixed, you need a new mental model to replace the old, wrong model.
Even if you have learned a correct model, there is always the risk you will fall back on using the misconception.
Use tests and documentation within a codebase to help prevent misconceptions

And then let's jump into the part 3,

On writing better Code 📝

This part moves our attention to writing better code: how to write understandable code and avoid vague names and code smells.

How to get better at naming things

Fortunately, the above topic is widely discussed among developers and developers ARE getting better at naming things. Thus, I won't go further in this chapter.

The book discusses why naming matters with examples, and different perspectives on naming, and then comes an interesting part— Cognitive aspects of Naming. It's said that Formatting names support our STM, while clear names support our LTM. And also variable names can contain different types of information to help you understand them.

Source: The Programmer's Brain Book

The rest of the chapter discusses many more interesting things such as what types of names are easier to understand, snake case and camel case, the influence of names on bugs, and how to choose better names.

Avoiding bad code and cognitive load: Two frameworks

This chapter uncovers the connection between code smells and cognitive processes, especially cognitive load, and surveys the connection between bad names and cognitive load.

(Well, I accept that I didn't know what "code smells" is but turns out code smells are parts of code that are not structured ideally. Like, very long methods or overly complex switch statements, you know.)

This chapter includes an overview of Fowler’s smells (long method, lazy class, data class, etc) and the levels (method level, codebase level, and class level ) they pertain to with an in-depth explanation of the code smells' levels.

It also includes how to measure cognitive load, using the PaaS scale (not to be confused with the "Platform as a service" abbreviation) along with an exercise.

Phew, that's a lot of words but we still have 4 more chapters, so move on!

Oh by the way, have you seen what a baby penguin looks like?

Getting better at solving complex problems

This chapter uncovers about the "The State Space"— All steps that we could consider while solving a program are called the problem’s state space. When playing tic-tac-toe, all possible fields are the state space.

(It's kinda like the sample space which includes possible outcomes of a certain event- that's another thing anyway)

As an example in programming, when adding a button to a website, all possible JavaScript programs are the state space. It is up to the problem solver to make the right moves or add the right lines of code to reach the start goal.

Source: The Programmer's Brain Book

After introducing what's problem-solving, Hermans answers a question that has long-germinated in my mind— Is problem-solving a cognitive process on its own? He answers this question along with George Pólya's book. His book proposes a “system of thinking” to solve any problem involving three steps:

Understanding the problem
Devising a plan
Carrying out the plan

However, the book states that research has consistently shown that problem-solving is neither a generic skill nor a cognitive process, despite the popularity of generic approaches. There are 2 reasons why,

You use LTM to solve problems
It's easier for your brain to carry out familiar problems.

The rest of chapter 10 uncovers many insights A new type of cognitive load(Germane load,) implicit memory, and memories that play a role in problem-solving.

On Collaborating on Code 👥

While the previous parts focused on an individual developer, this part is dedicated to collaborating with other developers.

The act of writing code

In the first section of this chapter, this chapter focuses on five programming activities, what programming tasks you likely do in these activities, and what makes each activity hard.

Source: The Programmer's Brain Book

Each activity is explained in depth and then comes something interesting— Interrupted programmer.

Source: Pinterest

This is a very relatable experience for all of us, and of course, it affects our productivity. Van Solingen has found out that interruptions are common and take 15–20 minutes each. About 20% of a developer’s time is spent on interruptions.

According to the book, It takes about a quarter of an hour to start editing code after an interruption. When interrupted during an edit of a method, programmers could resume their work in less than a minute only 10% of the time.

But the best thing is, this chapter has got us covered. It includes how to better prepare for interruptions with three techniques and an important question has been answered— when to interrupt a programmer and also some thoughts on multitasking.

Designing and Improving Larger Systems

In this chapter, the focus shifts from individual lines of code to the broader aspects of organizing code for better understanding.

Felienne introduces C*ognitive Dimensions of Codebases (CDCB)*, a framework derived from Cognitive Dimensions of Notations (CDN). CDCB allows developers to assess the usability of large codebases and gain insights into how they can be understood and improved.

The chapter further discusses cognitive dimensions of code bases (CDCB) and uses it to examine a codebase to understand how it can be understood and improved. CDCB is especially useful for code written in libraries and frameworks, which other programmers often call rather than adapt. The chapter first discusses each of the dimensions in isolation and then dives into how the different dimensions interact with each other and how we can use them to improve existing codebases.

That's a long way around, thus let's save it to read for later and jump into the last chapter.

How to onboard new developers

Now that looks interesting.

As the title suggests, this chapter is about welcoming new developers or expert developers to an unfamiliar codebase. But first, the book discusses the difference between beginner developers and expert developers, starting with an overview of the four different neo-Piagetian levels for programming.

Source: The Programmer's Brain Book

After an in-depth explanation of the neo-Piagetian level, the author explains the difference between seeing concepts concretely and abstractly, along with some mindblowing insights.

And then comes the part I want every senior developer to read: Activities for a Better Onboarding Process, where he suggests 3 activities that are explained in depth. He suggests limiting tasks to one programming activity, supporting the memory of the onboardee, and reading the code together.

And now, finally, we have come to the end.

That's just a bit of the book!

I agree, this review contained a lot— actually, this is one of the longest articles I've ever written but yet, I did skip a lot of parts of the book. For example, I didn't mention Feitelson’s three-step model for better variable names, the fact that "If you can learn French, you can learn Python", and a lot more interesting facts and insights.

I appreciate you for reading this too-much-detailed review, and since you've read this so far, why not get the book and read it yourself?

The Programmer's Brain - Manning Publications
It's really worth the $40, besides, you can get a 45% discount by using the code buzzpy24 which can give you 18$ off this book which makes it: $22 only.

Oh by the way, I'm also giving away 2 free e-books of "The Programmer's Brain", selected randomly from whoever fills out this Google form.

Until the next article, happy coding!

If you have any suggestions/criticisms (I'm sure that this review is very lengthy and many contain many faults/mistakes), feel free to comment!

Branding for Developers : A Practical Guide

Buzzpy 💡 — Sun, 14 Jan 2024 07:19:34 +0000

Read the AI Version of this article

Hello, precious bug dealers! Huge kudos to you for diving into the world of building your brand. Believe me, not every software developer explores this path.

By the way, what is “Personal Branding”? Let me explain.

“Personal branding is the art of consistently presenting, online and offline, the essence of how you stand out from the crowd.”

In other words, you need to be consistent and work on specific things that are a part of you and how people see you. So it’s really about you－about yourself, who you are, and who you want to be.

Oh wait, let's be kinda honest, shan't we?

Practically and honestly, personal branding is about how you wish to be seen because, let's face it, whether or not you consciously care about others' opinions, it holds significance.

So yes, since you have taken the first step, we can take the BIG step of building your brand. But in case you’re still wondering why on the earth you need to build a brand as a developer, I summed it up.

1. It Opens BIG OPPORTUNITIES!

Same as everyone, you too might be applying for many and many jobs if you find a match but only some of them accept you.

As a developer personal branding matters when you are looking to change your job. You want your employers to hire you not only as a good developer but also as an innovative one. To make that possible, you need to cultivate a personal brand that can highlight your value to your potential employers.

For a real example, Victoria Lo, a developer with a strong brand, landed a job at Paypal, without sending a single application or a CV.

2. You can learn more and more!

While creating a personal brand, you meet many people from your niche. You interact with them, share your knowledge, learn from them, and discuss ideas and all this will give you a level of expertise that wouldn’t have been possible otherwise. It doesn't matter how you want to improve your career, personal branding is the key!

Yup, I think that’s enough. Now the important part is how to build your brand. Here's how.

Building Your Brand

Here are the steps you have to follow to build your strong brand.

1. Find your brand personality (name, brand color, etc.).

The most important task. If this fails, everything fails. But don't worry, I will guide you.

First, choose the brand colors. It’s totally up to you. But make sure it’s remarkable. If someone sees your brand color, they must remember who you are.

One thing you should remember is to choose living and unique colors. If you’re an individual, I highly recommend not using just black and white. Seeing the colors black and white everywhere feels like it's not alive. Use some colors like blue, pink, green— any color that looks alive, and fresh.

For example, Chris Bongers has chosen a combination of colors such as pink, blue, and yellow as his brand colors, and now no matter where you see those, the name "Daily Dev Tips" will come right into your mind.

And the most important thing— building your brand name. Sounds easy, right? But it’s not that easy; at least for me, it was not easy.

Your brand name doesn’t always need to be your real one. If your name is too long and hard to spell or pronounce, it might not be able to build a strong brand. This is where a lot of developers fail.

Taking my brand name as an example, it might seem meaningless but by the moment someone hears it, they can spell or pronounce it. Besides, it gives a basic idea I always wanted— kinda messy yet sometimes over-energetic(which leads to unexpected disasters...). In my point of view, it's just perfect!

I think now you have an idea of how what your brand name should be. But I’m sure it’s not easy to build a strange name. What about a name that has terms of your area of expertise, one of your characteristics, or even your pet’s name? For example, my name is built up with Buzz + Py. Buzz is used to feeling messy (one of my traits. To say, my code is not messy) as well as to remark the famous FizzBuzz program while Py is for Python.

What I did first was to write all the names/terms in my mind on Notepad and try to match them. Those words are still saved, and they look like this:

Once you’re done with all those, you must define yourself! Yes, personal branding is all about you.

What’s my name? (Brand Name)
What are the colors that define me? (Brand Colours)
What’s my Profession (Programmer, Developer, or whatever. Feel free to build up your own if you’re a freelancer!)
How should I sound? Professional or Friendly? (Brand Voice)
What's a phrase or a sentence that best describes me? (Brand Tagline)
What do I do mainly? (say coding)
In what areas do I have expertise?
What are the other things I do? (maybe your hobbies or other side hustle you make money)
What are my most unique personal traits?

Remember about the gift I mentioned before? I'm not sure whether it would be disappointing (hopefully not), but here it is— A brand info sheet! Just fill out the form, save it, and keep it yourself for future reference.

Download your information sheet from Google Drive - https://drive.google.com/file/d/1KIuZQLP_5uzOTOkcmQakuGgo66Tj-VRr

Let’s take an example. My answers to the above questions are,

Buzzpy.
Grey and Blue.
Python Developer.
Friendly, Conversational.
The Buzzy Pythoneer
Python Programming.
Data Analysis, Technical Writing.
Reading, Branding.
Buzzy (Chilling or messy, stands for both of them), Introverted.

And here it is, my personal brand. Nothing less, nothing more.

2. Start your Blog

What’s better than blogging to tell people who you are? Blog about anything you hold expertise in, whether it is a programming language or it is some kind of technology, and let people understand who you are. Many developers out there have some awesome technical blogs where they share their knowledge and write about their specialties.

If you need to start a free developer blog while getting inspired, Dev Community and Hashnode are the best options! Hashnodes gives you your blog even with a custom domain and saves you a lot of time building up your blog!

3. Participate in Communities:

Communities like Quora, StackOverflow, etc can be your best friends if you intend to create a brand online. Join these communities and try your best to solve the questions of users from your niche. It will not only help you interact with your kind of people but will also improve your problem-solving skills. Sites like Stack Overflow, and GitHub allow developers to work together on projects, which can open a wide opportunity to learn.

4. Reach out to Social Media

I’m an introvert, and I have a really difficult time when it comes to social media. That’s the only reason for me to participate on LinkedIn, as a professional because I care about my stable mind a lot. But I highly recommend you reach out to other social media, especially Twitter (must I say "X"? ). It helps you a lot in building and promoting your brand.

5. Build Your Principles

When it comes to branding, following your principles is important. You must never be a money-hungry person who will do or change anything for a rate. Whether it loses you 1000 dollars, do not cross your line.

For example, if someone asks you to do a review on one of their bad products to increase users and offers you a lot of money to promote it as an excellent product, just say “No, Thanks.” Not like the $1500 they offer, if you get attention for being a fake reviewer and people stop following/ reading your content, it may lose you more than a thousand dollars and your whole brand and effort.

Next Steps 👣

That’s a lot of words! First, thanks for reading until the end. I hope you learned a lot of things and will get started on branding yourself as a developer as soon as possible. Yes, you might be late but late is a lot better than never! Try building your blog if possible, because it’s the best way to get recognition. If you’re not interested in writing, build a portfolio or stand out on Social media!

Until next chillin' Friday, Happy Branding!

Download your information sheet from Google Drive - https://drive.google.com/file/d/1KIuZQLP_5uzOTOkcmQakuGgo66Tj-VRr

Did you know the blog "ByteClash : AI vs. Buzzpy"? Every article or tutorial there is like a double take, coming at you from two different angles— the smart side of AI and the friendly touch of a human.

Visit ByteClash : AI vs. Buzzpy
Read the AI Version of this article

DEV Community: Buzzpy 💡

Glitch v1: An LLM with a personality, anxiety and a bit of attitude

The “Thinking“

Is this a “clone“, really?

The behind-the-scenes

What’s uncomfortable about it

What V2 Might Look Like

Wrapping up

Introducing Dev Encyclopedia: A "Wikipedia", but for developers

What is Dev Encyclopedia?

But why use Dev Encyclopedia?

Contribute!

How to Contribute:

FAQs

1. Techstack and tools?

2. How long did it take?

3. Did you build it alone?

The Programmer's Brain: How it works and how to make it work

Table of Contents

1. On Reading Code Better 🔍

Quickly reading your code

The Power of Chunking

Learn Programming Syntax Quickly

How to Read Complex Code

2. On thinking about Code 💭

Reaching a deeper understanding of code

Getting better at solving programming problems

Misconceptions: Bugs in thinking

On writing better Code 📝

How to get better at naming things

Avoiding bad code and cognitive load: Two frameworks

Getting better at solving complex problems

On Collaborating on Code 👥

The act of writing code

Designing and Improving Larger Systems

How to onboard new developers

That's just a bit of the book!

Branding for Developers : A Practical Guide

1. It Opens BIG OPPORTUNITIES!

2. You can learn more and more!

Building Your Brand

1. Find your brand personality (name, brand color, etc.).

2. Start your Blog

3. Participate in Communities:

4. Reach out to Social Media

5. Build Your Principles

Next Steps 👣