DEV Community: Frihk Ian

Go for the JavaScript Developer: What Tripped Me Up and What Finally Made Sense

Frihk Ian — Sat, 03 Oct 2026 13:43:38 +0000

I was really offended when Go first refused to compile my code because of a single unused variable. In JavaScript it's perfectly possible to have a dozen such variables without anyone noticing, but Go focused on one and basically told me to clean my room. Even though I've now been using both languages for a long time, I can state that the offence I felt at the beginning has changed into respect. If you're using JavaScript and are wondering whether Go is worth your time, then this is the article I wish I had read at the start. I'll explain the areas in which I had the most difficulty: errors, concurrency, types, and tooling.

Two Languages, Two Personalities

If you imagine JavaScript as someone who always agrees to requests, then it developed in a browser environment where flexibility was valued more than strictness and so will do its best to make sense of almost anything you give it. Go, on the other hand, is the friend who wants to know whether you've really thought something through; it was developed at Google by people who had grown tired of slow builds and large codebases, and its aim is to have small, boring, readable code that a stranger could understand even on a Monday morning. Neither of these two friends is better. But if you expect Go to offer the same degree of freedom as JavaScript, you'll end up arguing with the compiler during your first week; however, if you realise that it is trying to protect you, those arguments will disappear a lot sooner.

Errors: Thrown Versus Returned

This was the most important mental shift for me, so permit me to make it clear. In JavaScript, errors are raised and caught at a higher level, which means a function can fail without its signature providing a warning.

try {
  const data = JSON.parse(input);
  use(data);
} catch (err) {
  console.error(err);
}

In the programming language Go, errors are treated as ordinary return values rather than exceptional events, so a function will explicitly return both its result and an error. This requires the developer to handle potential errors directly at the location where they may occur, as shown in the accompanying code example. For instance, after attempting to parse input using json.Unmarshal, the Go function immediately checks if an error was returned and deals with it before proceeding; this explicit pattern contrasts with JavaScript’s approach, where error handling is decoupled from the function’s interface.

var data Config
if err := json.Unmarshal(input, &data); err != nil {
    return fmt.Errorf("parsing config: %w", err)
}
use(data)

Allow me to be straightforward with you: at first, err != nil did do seem like never-ending repetition. However, I then realised what advantage it was giving me. Whenever the program could fail, that fact was clearly shown right on the page, and you couldn't ignore a failure path without the code looking obviously incomplete. The more you added code, the fewer nasty surprises you had at three in the morning.

Concurrency: One Thread Versus Many

Here's a fun method of illustrating the difference. JavaScript makes use of a single thread and an event loop. In the case of using async and await, no processing takes place in parallel. What you're actually doing is asking the runtime to carry out other tasks while it is waiting for something slow, such as a network call. The approach is simple, and as a result you rarely have to concern yourself with two bits of code accessing the same data at the same time.

Go takes a distinct approach to concurrency: goroutines are lightweight threads managed by the Go runtime and can execute tasks concurrently, utilizing multiple CPU cores when available. You initiate a new goroutine by prefixing a function call with the keyword go, which instructs the runtime to schedule that function for asynchronous, potentially parallel execution.

go func() {
    result <- fetch(url)
}()
value := <-result

The power is genuine, and it brings with it a number of problems which you should be aware of. Since goroutines share memory, it is possible to encounter data races in which two of them read from and write to the same variable without coordinating, and deadlocks in which they wait for each other indefinitely. I have discussed both of these issues after having come across them directly. Although Go provides you with good tools such as channels, mutexes, and the race detector, it won't prevent you from using them incorrectly. JavaScript's runtime protects you from all the kinds of bugs involved here, whereas in Go that protection is up to you.

Types: Suggestion Versus Contract

If you're already using TypeScript, static typing won't intimidate you; in contrast, TypeScript's types disappear at runtime and can be ignored using any, whereas in Go the types constitute a contract that is enforced by the compiler. There's also no ordinary undefined or null value to run into, since every type has a zero value—an unset integer is 0, an unset string is "", and an unset boolean is false. This eliminates the entire class of "cannot read property of undefined" errors. At the same time, it raises a subtle new issue regarding how to distinguish between 'the user sent zero' and 'the user sent nothing', and from that point on pointers and the omitempty tag on JSON fields prove to be useful.

The way interfaces function is also interesting, and that's my favourite aspect. A Go type automatically satisfies an interface whenever it has the appropriate methods, without any need for an implements keyword. It does feel a bit strange at first, but then you realise that you can define a very small interface exactly where you're using something and substitute a dummy one when testing, which in turn makes your code extremely easy to test.

Tooling: The Stuff You Feel Every Day

It was here that Go made me accept it. There's just one formatter, gofmt, and everybody uses it, so there are no disagreements about code style. The standard library is so thorough that you can create a fully functioning HTTP server using just net/http and nothing else, whereas the JavaScript version typically starts by picking a framework and then installing a dozen packages. Testing and benchmarking are included, and the final program is a single binary that you can copy to a server, without having to install a runtime and without needing to drag along a node_modules folder. If you care about deployment, as I am becoming more and more concerned about doing, then this level of simplicity is difficult to exaggerate.

What I Still Love About JavaScript

Don't imagine that this is a letter announcing a breakup because it isn't. JavaScript remains my default choice whenever I'm working with the browser, and the environment it offers for creating interfaces has no equal, which is the reason I continue to turn to React and Next.js. With Go, the verbose syntax can become tedious when all you want to do is quickly prototype something, and working with loosely defined data is more difficult than it is in a language where an object can hold any type of value. The real question to ask is never "which language is better?" but rather "which trade-offs suit this job?"

Why I Use Both

The system I'm using at the moment has Go on the back end and JS on the front end. Go is used in the areas where it's important to have correctness, good performance, and easy deployment, while JavaScript is employed for the parts that users actually see. There's a benefit that I didn't anticipate: by expressing the same concept in two different languages based on different philosophies, you are compelled to understand the idea itself rather than merely the syntax. If you're confined to a single language, switching to the way of thinking from another language is one of the quickest methods for improving your skills.

The Bottom Line

If you're a JavaScript developer who's interested in Go, you can look forward to being annoyed for a week before coming to appreciate it after a year. You should learn to accept returned errors, show respect for goroutines before you start to trust them, and let the compiler contradict you rather than opposing it. As a result, your code will become more explicit and you'll place greater trust in it. Since I myself am still investigating the more advanced aspects of Go, please tell me in the comments which part caused the most difficulty for you, and I'll write about that next.

Lessons From Learning With No Teacher

Frihk Ian — Fri, 02 Oct 2026 11:04:24 +0000

When you first go into Zone01Kisumu, the most obvious thing is that there is no traditional lecture. There is no lecturer at the front, no slide presentation for you to transcribe, and no one available to help you when you encounter difficulties. Rather, you are given a task, a number of peers who are just as uncertain as yourself, and a deadline. At the beginning I had expected a standard bootcamp, but what actually happened was more like being put into a workshop where you learn to use the tools by getting hands-on with them. The following article gives the honest account that I wished I had been given earlier on: it sets out effective strategies for this kind of learning method, points out the real difficulties, and explains the way I decided when I had been stuck for long enough. But in order to understand all these points, it is first necessary to understand the reason for the school's structure.

Why This Model Exists

Zone01Kisumu is part of the 01 Edu curriculum and uses a peer-driven, project-based approach to education. The basic idea is that if a teacher gives all the answers, students mainly end up learning how to follow instructions; on the other hand, if they are asked to come up with solutions before being given the explanations, they acquire the ability to teach themselves. The projects make up the curriculum, and peers act as resources, reviewers, and members of the audience. Even though this might at first sound like a simple phrase, it really does alter the way a difficult day feels. Rather than thinking, "I didn't understand the lecture," the new challenge becomes, "I don't even know what to search for." Although this shift can be uncomfortable, it is exactly what allows the system to achieve its most important benefits, which become obvious soon after students start working on the projects.

What Actually Works

One of the main advantages is that concepts aren't left abstract for very long. If you are given the job of building a working program based on a specification, real-world problems come up right away, for example, unclear requirements, cases that have not been considered, and bugs which only show up when different parts of your code are put together. More have I learned about error handling from a program that failed during a review than from any chapter in a textbook on the topic. Another important benefit is the role of the reviewer; it becomes a standard part of the process to explain your work. When a fellow worker looks at your project, you have to defend your decisions orally, which makes it hard to hide mistakes during a thorough discussion.

The way in which these discussions are carried out also affects the way you deal with knowledge; when there is no clear authority present, you are encouraged to critically assess any claims, including your own. For instance, if a person says that a certain method is faster, the natural reaction is to say, "let's measure it." I have adopted this practice in my work as a technical writer by regularly carrying out benchmarks before making any assertions. Yet this habit has its disadvantages and involves certain costs which promotional materials seldom mention, thus bringing us to the more difficult parts of this educational approach.

What Is Genuinely Hard

The kind of autonomy which helps to develop problem-solving abilities may at the same time lead to a gradual and unexpectedly isolating experience. There are times when you can get stuck on a matter that might have been settled with just a short explanation, and yet end up spending hours working on it all by yourself. In some cases this difficulty is deliberate and has advantages; in other cases, it is simply inefficient. The problem is to tell the difference between these two situations. Without an expert checking your understanding, a misconception can survive for weeks because everyone around you shares it.

The risk grows if you start comparing yourself with the people around you. In a group of individuals who are of a similar age or social position, some will jump right into a topic while others will take longer, and it's easy to judge yourself by those who are ahead that week. Comparison is the fastest way of sapping the motivation you need in order to keep going, and I had to learn to concentrate on my own progress rather than on the mental leaderboard. Once I had stopped measuring myself against other people, a more practical question arose: if I'm going to have to face all the difficulties on my own, how am I ever going to know when the struggle has stopped being useful?

How I Decide I Have Been Stuck Long Enough

Instead of sticking to strict time limits, I follow a general rule. At the beginning, I try to clearly and briefly state the problem, since doing so usually helps me to identify the real issue. When this method doesn't work, I take the smallest possible version of the faulty code and isolate it in order to see whether the error still occurs, a procedure which generally gets me nearer to a solution. Only then do I refer to the documentation and afterward ask a colleague for help. Once an hour has passed and I haven't made any progress, I realize that continuing to struggle is pointless and so I ask for assistance without delay. It should be mentioned that the success of this approach depends on the way the following question is asked of others.

Asking Well Is a Skill

The ability to ask effective questions is much like that of an engineer, and I first learned this lesson here. It's not very helpful just to say "It doesn't work." On the other hand, if you give specific details such as "I expected this output but received that one and have already ruled out these two possible causes," you usually get a quick and useful response. By outlining the steps you've already taken, you show respect for people's time, and this in turn leads to more worthwhile answers. This kind of skill doesn't stay limited to the bootcamp; it meets the requirements of a junior developer in a professional team. Once you get into the habit of doing this, it naturally encourages you to take on the role of answering questions and reviewing other people's work.

Learning to Give Feedback

Another element of the peer-driven model involves the considerable amount of time spent examining other people's work, a skill that is highly valuable. At first, I would give only a superficial approval in order to prevent disagreement or concentrate on minor and unimportant matters. Later on, I learned how to tell the difference between real errors and alternative methods, and started to give explanations with my feedback. As a result, my ability to take in feedback also improved, reinforcing the idea that criticism of code does not amount to a personal attack. This distinction is important in professional settings where every pull request is subjected to review, leading to the final decision as to whether this approach is appropriate for each individual.

Would I Recommend It?

It depends on the individual since the appropriateness of this method varies from person to person. For people who value structure, prefer clear direction, and like to receive regular feedback, this approach might seem rather demanding. On the other hand, individuals who are at ease with uncertainty and who enjoy working out problems on their own, seeing setbacks as an essential part of deep learning, may find this kind of environment very beneficial when it comes to developing their skills as a developer. The most valuable thing for me was not just obtaining a list of technologies, but rather acquiring a practical method for dealing with unfamiliar problems, a skill which still holds value even as the specific tools change. The entire approach consists of a full explanation. As no one will tell you about it, the key point you need to take away is that you have to learn how to define the problem, break it down, check your assumptions, ask good questions, and then look at the situation in a kind way, with these habits staying with you longer than any particular framework. You should realize when considering a project-based bootcamp that the difficult days are real and that it is also during these days that the most growth occurs. I am still learning, and I expect to keep doing so in this way for a long time.

Five Years Ago, "Junior Developer" Meant Something Different. Here's What I'm Facing Now.

Frihk Ian — Fri, 02 Oct 2026 08:49:10 +0000

Over time, the meaning of "junior" shifted from "beginner" to something else. I first noticed this change when I read a job posting for a junior developer. The job description listed requirements like a "frontend framework" and, for the backend, "a programming language," "SQL and NoSQL databases," "Docker," "CI/CD," "Cloud basics," "Testing," and even "experience with AI-assisted development." But what truly made me laugh was the next line: 1-3 years of professional experience—for a beginning position. Where is a beginner supposed to get that experience before their first job?

I'm a junior developer in Go, JavaScript, and Python; I build with React and Next.js, and I have a background in physics. I'm in a project-based bootcamp called Zone01, where no answers are given, and you learn by doing. I'm in the squeeze, not the outside looking in, and if you are thinking of joining us right now, you deserve a true picture of what has changed.

The Bar Was Lower, and I'm Not Complaining About That

To truly appreciate how much has changed, it's important to look back at how things used to be. First, I will be fair to the past. It's been about five years since the path to a first developer position went something like this: learn a language or two, make some projects, complete a bootcamp or course, assemble a portfolio, and slog through interviews. Businesses were hiring like crazy, remote work had just blown up, and many employers were more than happy to take a gamble on a new employee and train them on the job. And the world was full of problems, and even then, access was unequal. What was expected for a first job, however, was "show me that you can learn, and that you have constructed something. The baseline today is more towards "show me you have done a lot of the work."

Fast forward to today, and the expectations have shifted. A Portfolio is not all there is anymore. You Have to Prove You Can Ship.

A to-do application used to serve as a portfolio item. Now it reads like a tutorial that you followed. Today, hiring managers want a project they see as deployed and "live" (not in a repository with a README), and that solves a real problem (not a clone of a course project).

They also look for the nitty-gritty that makes software useful: authentication, a database, error handling, and validation. Tests matter because they reassure anyone who has maintained a production system, and with Docker, environment configuration and CI/CD aren't the same as someone else being able to deploy it.

This is what I learned from my own projects. A Go backend with a React frontend is one thing. Containerizing it, wiring in a database, handling edge cases, and making it something another developer can pick up and run is another. Most of the learning happens in that second part, and that's what today's employers want to see evidence of.

As I moved from building projects to actually making them production-ready and easy for another developer to run, I started to see the bigger picture. These real-world challenges revealed that expectations now go well beyond just getting something to work. The truth is, the bar for juniors is much higher than before—not just in shipping code, but in understanding a wide range of technologies. The Stack Got Wider, and 'Full-Stack' Became the Default.

With these higher expectations for projects and deployment, the range of technical knowledge required has also grown. Five years ago, one could secure a position as a frontend developer with knowledge of HTML, CSS, JavaScript, and one framework, and it was entirely normal to specialize early on. Now the expectation is to be "T-shaped," i.e., deep in one area and competent across the stack. A frontend role can be completely silent about writing a backend endpoint, or a backend role can know nothing about containers and basic cloud services. These are all mentioned in the casual junior posts. Casual junior posts mention relational and non-relational databases, cloud platforms, and REST and GraphQL. It's not everything you need to know, but a junior should be familiar with the surface area.

And as the required stack broadens, one thing remains clear: fundamentals still matter.

The irony is that tooling is far removed from its concrete origins, so you might think fundamentals don't count, but they do. Interviewers are getting more curious about the details, including how HTTP works, what happens when you enter a URL into a web browser, how a database index accelerates a query, what concurrency is, and why one data structure is better for a particular problem than another. Frameworks change every couple of years, and the people who can reason from first principles survive those changes.

That's where my physics background helps. Physics teaches you how to approach a complicated system, deconstruct its rules, and get a sense of how to reason through it. That's how I approach debugging and designing a system, and it works much better than I thought it would! It also means that I cannot say, "I used the library. Need to be able to describe how something works.

Just as the fundamentals remain crucial, another major shift has arrived: the role of AI in entry-level work.

This is the biggest and most controversial change. Many of the tasks that previously required junior developers a few minutes to do, such as boilerplate, simple CRUD, basic scripts, and small bug fixes, can now be completed in just a few seconds with AI assistance. Companies noticed. Some said they didn't hire as many juniors; others said the requirement has increased, since if the tool writes the boilerplate, the human still has to add something else. Employers want judgment: can you take the code and tell what is wrong, turn a fuzzy requirement into a plan, debug code that you didn't write, and tell when the AI is definitely wrong?

At the same time, the landscape for junior developers isn't just changing in terms of skills and tools—it's also expanding geographically.

When developers competed for positions five years ago, much of it was local. They competed against brilliant developers from all over the world, especially for remote jobs. Bootcamps, free online courses, and a series of tech job cutbacks have flooded the entry-level pool with more qualified people, and if hundreds apply for one of those junior spots, employers don't have to worry about hiring anyone, so they don't.

To the developers in Kenya and other parts of Africa, this is a two-way street. The Internet gives the world new employment opportunities from employers around the world that weren't available a generation ago, but it also exposes us, right from the start of the application process, to a global standard. This is not something to worry about. That is an excuse to think about what you can make visible.

Visibility in the community has become just as important as technical skills.

More and more, code alone isn't enough. Having a clean GitHub profile, a portfolio site, and blogging about what you've learned are all evidence of thinking, communicating, and completing tasks. I write technical articles partly because you have to know something thoroughly to write an interesting article about it, but it also makes it easier for others to follow my thinking.

People don't seem to realize how valuable effective communication is. Team distribution: Clear pull request descriptions, good questions, and explanations of trade-offs are all characteristics people look for, even if the job description doesn't explicitly mention them.

Given all these factors, it’s natural to wonder whether this new landscape is fair.

I don't believe employers have become unreasonable, and I don't believe juniors are just lazy. The reality is more painful. A few things contributed to the market tightening after the hiring frenzy ended and companies grew more conservative; tools improved the productivity of experienced developers, diminishing the perceived need to train novices. Meanwhile, the number of people looking to get into the business outpaced the number of jobs being created.

The result is a mismatch between rising expectations and a shrinking number of on-ramps. But part of that is a problem in the structure of the industry, and a problem that companies have to address: if they never hire a junior, they will have to wait to hire a senior. That's another story for another article, but this one here, I can only control my side of the conversation.

What I'm Doing About It

Complaining is good for 10 minutes, and then the job offers are still right there. So, my approach is to make fewer projects, but finish them right - one project that you deployed, tested, and documented is better than five projects that are halfway finished. I go deep on fundamentals because I want to know how something works, instead of memorizing how to call it; and I don't rely on AI to do the work for me, but I use it as a partner to explain to myself, line by line, anything I ship.

The other key element is collaboration. Group projects helped me learn about Git conflicts, code review, and communicating under pressure: all of which a single tutorial can't. Not only that, but I write and share as much as I can, which means that every article or repository is a public record of what I know and that I try to be patient with the timeline. The road is longer than it was 5 years ago, and taking it saves energy for the actual work.

In the end, here’s what it comes down to:

If you're a junior developer who feels like they have to keep shifting the goalposts, you're not alone. They did. What used to be a middle-level job now shows up in entry-level postings; the competition is international; and tools have changed the definition of "entry-level work."

However, the road is still open. It pays for people who send authentic products, see what is beneath the surface, use new tools with good judgment, and keep publicly demonstrating their work. That's tough, but it's learnable! I am still traveling; if you are, keep traveling.

I Got a Signed Job Offer Letter for a Job that Never Existed

Frihk Ian — Tue, 29 Sep 2026 09:02:56 +0000

I passed a 48-hour technical challenge, received an offer letter, and then lost the job because I had to enter and upload my ID number and make a payment on a page to complete a background check. I already knew what this was, but I needed to verify my suspicions.

The offer that wasn’t.

The email message felt authentic: it was addressed to me by my name, included details from my resume, and congratulated me on being selected from “a massive pool of applicants” for a job with a company named WeatherAI. The challenge was to build anything using their API, then submit a repo and live deployment link. I created it, submitted it, and received ‘passed’ with a signed offer letter from embed hr@weather-ai.co at the near 48-hour mark. Next came a Background Check.

I had already come across yet another developer who had written about this very same procedure–the same company, the same challenge, the same offer letter, the same redirect. When I visited a website called beta.verika.org, I got a page to enter my ID number, proof of address, KRA PIN, phone number, email, and certificates, and to top it off, I was supposed to pay a fee to them; I wasn't discovering a scam. I was verifying one. I had no item submitted when I closed the tab.

Why it lasted for more than 48 hours

The vast majority of the scam warning posts tell you about some blatantly false item. This one wasn’t. The API was real: full docs, working endpoints, real JSON weather data, tiered rates (up to 1000 requests per month), even SMS farmer notifications, and Paystack billing integrated into the docs for Kenya. It was like a real weather API for East Africa. The invite email mentioned “the scaling challenges we face on a day-to-day basis,” so I built a caching, quota-aware gateway around that constraint instead of just a weather display, and shipped it inside the window. A good challenge remains a challenge. What follows is the key to knowing what you are dealing with.

The tell, and what I walked away with

A background-check page that asks the candidate to pay for his/her background check is enough. Real employers do not bill the candidate for any kind of background check, whether it is called an “expense,” a “background check fee,” or something else, but pay for the background check themselves through a named background check vendor. The developer whose account led me here described the identical site, challenge, and fee. Two engineers, months apart, running through an identical script isn't a coincidence. It's a template.

The company isn't really there, but the 48 hours weren't wasted. I designed the project around the same restriction outlined by the fake job, and shipped a working FastAPI gateway with the following features: response caching (no repeat requests should make it to the upstream API twice), persistent quota tracking (the API itself does not track quotas, and storing them locally in SQLite is easier), retry + backoff logic specific to the errors I wanted to retry, and a React UI deployed live at weatheraigateway.onrender.com (source). The frontend, known as Kenya Weather Log, allows anyone to browse the real-time weather conditions in Nairobi, Kisumu, Bomet, and Mombasa: a little product that survived the phony job that gave it birth. But the fact that the offer was fake did not deter anyone from believing it was real.

What to look out for and what to do.

A frictionless hiring process means no humans are holding it back. Don’t take it as a compliment if the challenge seems to be a craptacular mirrored version of your CV. Any kind of payment request, no matter how it’s worded, is disqualifying. Compliance language that doesn't match your country is copied, not diligent. Someone else already publishing your exact story is confirmation, not coincidence. If you have seen it: don’t pay or upload anything; report the domains through WHOIS and report wherever the domains were seen. If you have already submitted documents or payment, inform the DCI cybercrime department and notify your bank of your ID number and KRA PIN. Do not delete anything you have created. First, keep in mind that a job search is one of the moments we are most likely to be vulnerable to this type of attack – we are on the lookout for any job opening and ready to say yes with minimal hesitation. It is this enthusiasm which is under attack. Slow down anyway.

Every Automation Wave Was Supposed to Kill Programming Jobs. This Time People Actually Believe It.

Frihk Ian — Tue, 15 Sep 2026 07:58:32 +0000

Someone in the AI coding space recently said that the term "software engineer" will be obsolete, and we will all be "builders" or "product managers" instead, as coding is solving itself around the corner. I have come across some instances of this before. Instead of anything else, it was the way people delivered this bit of news that pulled at me this time. Not "this year, possibly", but this year, "obviously. The sound of that is new, even though their prediction isn't.

Having been here before, many times, and not in the way that people would like.

The pattern, if you actually look at it

Routers and IDEs arrived decades ago, promising to enable software development five to ten times faster, and at the time they were running, people were afraid because fewer people would have to do the same amount of work. The actual result was quite the opposite. The software became infinitely easier to develop, and the number of software programs the world wanted grew exponentially, as did the number of developers required to develop them. Ten years later, Stack Overflow and Open Source did the same, and it was rightfully assumed that one's personal knowledge was devalued by the ease of access to others who had solved the same problem. It did the opposite: it lowered the bar, and more people became developers, not fewer. That friction turned developers' jobs into about double the workload, as cloud platforms took on much of the tedious work of managing their own infrastructure, and there was no more racking servers in the 2010s. Even low-code and no-code systems, which the movement's adherents originally envisioned as giving non-programmers a complete pass with code blocks and no coding whatsoever, found themselves in many markets being paid more than non-programmers who didn't use low-code or no-code systems.

Each and every wave automated something true. Each individual wave saw an increase in the number of people doing the work, rather than a decrease. If that's the whole story, this should be an easy, comforting article to write.

Why people believe this time is actually different

Here's the honest complication, and I don't think it's nothing. All previous waves made you more efficient in doing the work, in typing, in looking things up, in provisioning, and in prototyping. All the previous waves have made you more efficient at work, typing, looking things up, provisioning, and prototyping. None of them spoke to the 'what' or the 'whether' a decision was the correct one. The agent who takes care of the entire lifecycle of building, selecting the architecture, coding, testing, compiling, and deployment of the features is automating another layer altogether. It's no longer eliminating friction from the job, but it's claiming judgment from the job, the part that's been completely avoided by all previous waves.

Which is what makes this one feel different in the body and on the headline. And the fear does have some early confirmation: hiring of junior developers has gotten a lot softer in the last year, while the demand for engineering talent hasn't budged an inch. That's nothing. Prior waves stimulated demand in all areas. It may be a new upswing of senior judgment, and an unspoken decline in the entry level which sustained it.

So which is it

This is as far as I end up; maybe I am incorrect: I believe that the trend is true at the top and downplays at the bottom. Historically, software has become easier to make. That means the world will make more, not less, of it, and more people will make software projects more easily than before. It also means there will be a greater need for more people to easily make software projects. This time, however, the typical entry-level job, the position at the bottom where they teach you the underlying basics over years of bored, technical, under-the-hood cruddy work with a senior engineer’s shadow, may still fall victim to the changes, though not because the number of developers is being reduced, but because the route into being one changes.

I'm looking for your feedback on that. As a fresh entry into the workforce now, does this seem exactly what you're seeing when you go on job interviews, or is it sounding like too much? Or if you are in that self-same fear that you ever endured yourself, do you truly sense that this one is different in this 10th year's fashion? I'd prefer to have this argument in the comments rather than know the response already.

What are the ethical implications of AI in healthcare?

Frihk Ian — Tue, 15 Sep 2026 07:57:42 +0000

Take a quick glance at this meme. You've seen something like this before, haven't you? AI agreeing with something that is obviously and badly wrong. “That's correct, it was toxic.” In a tone of confidence similar to that used to tell you the capital of France. It's funny; the confidence is so far removed from correctness, and it's like that's the whole point.

The thing is, though. Funny when it's a food that's poisoned. But is it still funny when it's your bloodwork

?
That kind of tone that's certain, slick, relaxed, is already residing in actual medical gear now. Not hypothetically. Right now.

To start with, the first problem is so easy: "AI can sound right when it's wrong, and in healthcare, that's wrong when it's right. Take the time to think the other way around. You are a doctor who has just been on a twelve-hour shift, or a patient who just wants someone, anyone, to tell him or her what's going on. An AI provides you with an answer; it's clean, it's confident, and it's without hesitation. Do you really plan to interrogate it? Honestly evaluate yourself. Last time you double-checked an AI, rather than taking its word for it because it sounded certain?Last time you checked a point an AI had made, rather than just believing it because it seemed like it had a big idea of itself?

Now imagine yourself as that student taking the exam. Don't read about it; be it. A person in the "scrubs" is telling you what "the system" has marked, and you're nodding your head, right? What else would you have to do? Demand a second opinion from the algorithm? When it comes to your own body, and a decision is at stake, that confidence you laughed at 30 seconds prior doesn't feel funny anymore.

Which leads directly into the second problem, the heavier one: When it goes wrong, who owns that?

State that an algorithm causes a negative consequence. Who's responsible? The doctor who believed in a tool that they were told to believe in? The hospital where the software was bought and implemented in all departments? The builder of it, away from the real examination room? In reality, it's often the response of "a little bit of all these people, so no one really. Now suppose you are that person giving the explanation to a member of your family. Say out loud to someone who just lost a person they loved: "Well, the algorithm suggested it". But when no one seems to have committed a mistake, is it still an accident? Or could it be just the way we've settled for doing it these days, one tool at a time, not even voting on it?

That's really all there is to it, right? The meme's success was that the stakes were fake and easily verifiable: poison or not, you would know within the hour, either way. Medicine doesn't give you a safety net of this kind. When you do not have an immediate, evident answer as to whether the confident answer was correct or not, you must play it by ear as to how much trust to place in the tone of voice emanating from a machine.

So, that's where I'll leave you. The next time you hear someone, whether a doctor or a computer, state with absolute certainty that he/she knows what is happening, ask yourself what he or she is basing that certainty on. The reason for this is that you're right: it was a joke about a snack, and it was poisonous. But somewhere out there, right now, a similarly worded sentence is being repeated about somebody's diagnosis, but without the coolness, and it isn't being laughed out loud in the room.

Nobody Can Agree What a Software Engineer Even Does Anymore, and That's the Real Story of 2026

Frihk Ian — Tue, 15 Sep 2026 07:53:06 +0000

Titles in this sector have got a bit crazy. We've acquired the terms “builder”, “system thinker”, “AI orchestrator”, “product engineer”, and a few others, all referring to the same shoddy word. Over the course of a few years, we've got caught up in “builder”, “system thinker”, “AI orchestrator”, “product engineer”, and a few other unglamorous words in the same ballpark, and the actual day-to-day work beneath these umbrella terms seems to be coalescing more than ever. That, in itself, is what's really weird about me. As the work itself begins to look increasingly alike across companies, the labels are multiplying at just the right time.

Quite simply, the same name, a very different role.In simple terms, the same name, a very different role.

Go to two people who both say that they are “software engineers”. One of these spends a lot of a normal week reviewing pull requests from an AI agent, writing specs so precise that the agent doesn't go astray, and only intervening when there is some architectural judgment that can best be handled by a human. The other is working most of an average week using a hacked-together piece of code, only autofilling a bit with an AI tool because their company's has been too long or too sensitive to leave in an agent's hands. Business card same title. Not much in common on a Tuesday afternoon.

Now flip it around. You might have two people with the titles "AI orchestrator" and "developer" who are essentially doing the same job: writing specs, reading the generated output, and making the same judgment calls about what to accept or reject. One of these works somewhere that changed the job title to make it more interesting for a hiring page.

Or take the third scenario – this one may be the weirdest of all: two people with the same role, the same company, the same team, and the same views on the tools – it is that different. One engineer handles all the planning and scaffolding, most of the testing, and spends the day reviewing and steering. Because there's a teammate next to them who has the same title, same manager, same sprint board and that teammate doesn't trust the agent's judgement about anything that involves a part of the system that he or she cares about, the teammate by his side, who has the same title and the same manager and the same sprint board, writes most of their code by hand. There were no special assignments for them. They simply slipped into various interpretations of the same character, and both are correct.

Explain the reasons behind this happening now and not at another time.

This is not just a case of title inflation, but a reflection of what’s actually on the job – the job description is changing faster than the words used. HR job descriptions are rewritten every year, industry surveys are done, lists of "top skills for 2026" are compiled, and all that type of language is written and rewritten every year. The work is in constant flux, changing every few months. What you have is a huge disconnect between the label on the job and the experiences in the job, and people take different approaches based on the most recent reading they did, whether it's a conference talk or a LinkedIn post. No one is lying; they just don't have the right vocabulary for something that isn't settled yet.

It's likely that this one will pass in a year or two when the dust settles, and once or twice, everyone just gave up on trying to figure it out, like with full-stack developer. We're in the messy middle right now; given the title of this blog, you'd think you know very little about what these guys do all day, which is why hiring, job-hunting, and even talking to another developer at a meetup becomes weirdly difficult.

Let me know your true mismatch

Here's what I want you to do: leave your polished LinkedIn profile behind. What exactly was your position, and what did you spend most of your hours on this week? If I had to wager real cash, I would say all the way up to a good part of y'all reading this, those two answers don't even have a thing in common. Perhaps you're an engineer, and the vast majority of your week was spent on spec writing and review. Perhaps the title included "AI," and your week resembled the old way of life you were developing five years ago. I feel like it's going to be funnier and more exposing than either of us would expect, at least in the comments, which are the gap between the two.

After all, isn't it a bit silly that, in a field this focused on accuracy, we can't even get a consensus on what we all do every day?

Vibe Coding Didn't Kill Junior Devs' Careers. It Just Fast-Forwarded Them.

Frihk Ian — Wed, 29 Jul 2026 13:07:36 +0000

What was originally a joke, a colloquial term for projects that are done on the weekend, in which you tell a model what you want to do, don't read what it tells you, and follow it by feeling. It was completely out of that "hole" by 2026. Ninety-two per cent of U.S. developers are using AI coding tools daily, up 340% from the year before, and a growing number of junior developers built their entire portfolio around it, since it allowed them to deliver something impressive without having to go through college and years of fundamental coding.
That remained for a time. Next, it was time for the bill.

The surging demand for hiring that no one anticipated.

Vibe coding isn't only a coding style; it's an economic change. 25% of startups in Y Combinator's Winter 2025 batch had codebases that are 95% or more AI-generated. The price of developing a viable SaaS product has come down from $200,000 to $5,000, and the time to build is now six weeks versus six months. In that same context, a junior developer who can truthfully boast, "I built this whole app myself using AI" seems like a brilliant hire, both cheap and fast and able to deliver a complete product with just one developer.

63% of today's coding users describe themselves as non-developers, product managers, marketing directors, founders, designers. Forrester reckons that there are currently more than 16 million active citizen developers in the world, and Gartner foresees the number of citizen developers will surpass the number of professional engineers by four to one by 2028. For a hot minute, it was really just "junior developer" or "person who could prompt well", and hiring managers went for whoever could get the demo packaged out the quickest.

Next, the codebases had to be tested!

All this has a productivity understory that isn't as easy as the pitch makes it sound. In a controlled study, METR determined that more experienced developers who worked on large, actual codebases were 19% slower when using AI tools, and also felt they were 20% faster. Almost 40 points between how fast people feel and how fast they actually are, and that's important in that it really means that the teams that are planning sprints based on their self-reported productivity are doing it quietly on the sidelines.

The same can be said for quality. In one prominent study, the rate of bugs increased by 41% post AI coding tool adoption, while other research comparing AI-coauthored pull requests with those written by humans revealed 1.7 times more major issues, with logic errors up 75% and readability issues tripling. However, the less glamorous part of code, that which is refactored and simplified, dropped from a quarter of changed code in 2021 to under ten per cent by 2024, even as the amount of code being shipped kept climbing. This doesn't appear on day one. It emerged by the 12th week, when teams are usually using 20-30% of their sprints to repair bugs they weren't fully aware of when they were first created by AI code.

That's the reason why junior developers are the first to take the hit. Still, debugging doesn't involve writing code; it involves understanding code, and that's something that vibe coding allows you to avoid. A developer can develop a working feature and never, ever have a mental model of why it works, and that's okay until it doesn't and there's no foundation under them. Add security to the mix, and you'll find that almost half of all code generated by AI fails basic industry security standards, and that one study of more than 200 applications coded by vibe reveals that over 90 per cent had one or more vulnerabilities stemming from a lack of awareness of what they don't know. These are not fancy bugs, but the very basic ones: unvalidated input, lack of access controls, exposure of credentials, all of that sort of thing that an experienced engineer instinctively looks for, and a junior developer who didn't get the rudiments of engineering basics.

There is no uncertainty about the production failures. One vibe-coding tool experienced three separate security incidents which were widely covered, including one that remained open for 48 days. In another case, an AI-powered social app took just three days to leak 1.5 million authentication tokens and 35,000 emails. On the broader market, about ten thousand startups have tried to work out a working production application using an AI assistant, and over eight thousand of them need costly rebuilds that are usually $50,000 to $500,000 a pop, because the demo they would build wasn't going to hold up with actual users, actual load, and an actual security audit.

The market took no notice of this,

As developers have incorporated these tools into their workflows, they are also becoming more sceptical about their effectiveness. Developers' own trust in the tools has been shaken as they have used them more. Trust has dropped from approximately 40% two years ago to approximately 29% today, and almost half of developers actively distrust the output of AI-generated code. Only a small number of senior engineers say they have high trust, and one in five say they have high distrust among senior engineers specifically. But less than half of developers claim to always look over AI-generated code before committing it, meaning that plenty of AI-generated code is flying the flag without a second glance.

Labour statistics are now catching up with the anecdotes. Overall demand for engineering talent hasn't gone away, but junior developer hiring has dropped by almost 20% among those who would typically begin their careers in this role. As much as forty to seventy per cent of the traditional entry-level development has been swallowed up by AI. Meanwhile, junior developers, who are seeking to enter the field, are doing so in one of the most competitive fields in years, and at the bare entry-level, in a field that increasingly demands the judgment of a senior engineer.

The irony is sharp. The idea of vibe coding was to make it the leveller, the one thing that anyone could do and be a builder. For a certain group of junior coders, however, it was a way to an appointment and a quick path out of it, since the skills used to land that job didn't necessarily help when it came time to interact with real people, real traffic, real security audits.

What really makes the difference between the ones who make it and those that don't?

The organisations and developers that will emerge from this cycle without issues are not ones that eschewed AI but rather embraced it as an aid to real understanding, not a replacement. The pattern that passes this test is more "let me build with AI" than "let AI build it for me," with the caveat that while the AI is allowed to build it, there is a human in charge of checking each step it takes when the code is written into production code, the AI doesn't run the test gates unless there is a deadline pressure that can't be overcome, and the specifications are detailed enough for an agent to know exactly what is supposed to be built, and not just handed an open-ended prompt and encouraged to guess well. Such teams are consistently spared the technical debt and exposure to security issues that plague other teams that scale up their use of AI without first establishing that structure. If teams consider governance as something to do afterwards, they are almost always going to pay for it afterwards at multiple times the cost of doing it from the beginning.

Vibe coding doesn't need to be abandoned, and it shouldn't. If you're a junior developer trying to land a job right now, the pitch that lands you the job and keeps you on is NOT "I can have AI create things." It's "I know how it works well enough to fix it when it breaks, secure it before it ships, and explain it to the next person who touches it."

Multiagent orchestration article

Frihk Ian — Tue, 28 Jul 2026 08:38:11 +0000

Multi-agent orchestration is the hot topic of 2026. Introduced in February, Agent HQ from GitHub allows developers to concurrently use Claude, Codex, and Copilot to solve a problem, with each having a different perspective on trade-offs or details. Between Q1 2024 and Q2 2025, Gartner experienced a 1,445% increase in inquiries about multi-agent systems. Steve Yegge, a very experienced engineer at Amazon and Google, has discussed his work on orchestrated agents and producing 12,000 lines of code per day. Even more impressively, Cursor's team programmed an entire browser over a thousand files and a million lines of code in just one week by using hierarchical orchestration rather than having a single agent perform all the tasks sequentially, though multiple reviewers reported the code didn't compile at announcement, and Cursor's own CEO described the result as merely "kind of works".

The part nobody's celebrating

The only news to this is Google's 2025 DORA report. It determined that for a 90% increase in AI adoption, bug rates climbed 9%, code review time rose 91%, and average PR size grew 154%. When read as a single group, that pattern emerges instantly: teams are shipping more code, more quickly, and it's measurably more difficult to review, and measurably more buggy once it is shipped. No, multi-agent setups don't help with this; they exacerbate it. You're not just reading one model's decisions now; you're reading several.

Engineers who interact with such systems refer to a particular type of failure: architectural drift, in which each agent takes an action that is locally optimal but inconsistent with the actions taken by the other agents five minutes ago. One agent selects one pattern to use for errors, another agent selects another pattern for a neighboring module, and nobody realizes until anybody attempts to extend the feature, and the codebase spits. Then there is the issue of "lost in the middle," as it's called, and how much information that is in the middle of the long context window becomes lost and essentially forgotten by the agent, so it seems like it doesn't know about it.

The naive version of this doesn't work very well, as Cursor's own account of constructing that browser admits. The first tried to treat all agents the same and, to avoid collisions, used file locking, but this didn't work: agents were holding locks too long, and twenty agents were operating at the throughput of two or three. Their second attempt was optimistic concurrency control, not locks, and that didn't work out quite right; the agents became more of a risk taker and began to avoid anything that resembled a hard task. What really worked was a hierarchical structure as opposed to agents being free to improvise in parallel: Planner agents that continuously explored the codebase and created tasks, Worker agents that executed assigned tasks without coordinating with each other, and Judge agents that determined whether to continue at each cycle's end, rather than a bunch of agents improvising freely in parallel with no one peeking at each other's work.

Why this becomes a review nightmare

In response, automated PR review tools have scaled, and teams managing multiple agent review fleets see real improvements: 30–60% faster review cycle times and, in the best cases, 25–35% fewer production defects. But even the researchers developing these systems are straightforward about the problem: AI reviewers are good at spotting issues in the code, and they're not so good at understanding what you were trying to accomplish, and why you were making the decision. What you get is a ton of automated "this could be improved" comments, yet not much of "this doesn't fit how the rest of the system thinks.

In a piece about orchestrated coding, Addy Osmani stated it quite simply: "With an orchestrated army of agents, there's no natural bottleneck. Small harmless mistakes — a code smell here, a duplication there, an unnecessary abstraction — compound at a rate that's unsustainable." These are no longer being created by a single human who was used to writing the code manually and would have noticed any errors or bugs; now they are just being created by many humans who are not involved in the code change, so the errors just accumulate. There is no crash reported. It turns up when someone tries to add a feature to it, and finds the architecture won't support it, and the tests that the agents also wrote are no more reliable than the code they were supposed to be checking.

What this actually means for teams adopting this now

None of this is a reason to not use multi-agent coding. The productivity narrative is true, and it will keep going. But it is the teams who are designing plan-approval steps, token budgets, verifier agents, human review gates, and so on into their orchestration, rather than eliminating themselves from the equation and hoping that the agents will get it and do this well. These teams will not realise the cost right away if they do not do that. They will see it in 6 months when the two-line feature request becomes a two-week rewrite, and no one, human or agent, understands the system's structure and why.

There was never a problem with speed. It was inevitable that coordination would be difficult. But it was not until now that we needed to solve it.

Nobody's Reading Tutorials Anymore. They're Just Asking AI.

Frihk Ian — Mon, 27 Jul 2026 00:52:47 +0000

Two or three months ago, I noticed that my Go tutorials were not receiving the level of engagement I was expecting, with fewer comments and saved posts. The first thing that popped into my mind was that I was slipping. Then I absorbed the larger data, and it seems this isn't a me problem; this is an industry problem.

The figures are appalling.

Begin on Stack Overflow, which was the most comprehensive reference library for technology. During 2014 to 2020 Question volume reached a maximum of over 2,00,000 per month. It ended up below 50,000 already in late 2025, wiping out 15 years of increases. A January 2026 data visualization, built from Stack Overflow's own Data Explorer, showed the platform's monthly question volume had fallen back to roughly what it was in 2008, the year the site launched. The same 2025 Developer Survey found that while 82% of respondents still visit Stack Overflow at least a few times a month, only 25% do so daily or more often, a shift from the platform's old status as a daily habit for most programmers.

It's not just one platform which is in trouble. Invisible, though, is the larger behaviour change, one that goes beyond the visible symptom, namely that developers no longer consult written references first.

Rather than "Where everybody was," here is "Where everyone went.

They went to AI. In the past, this was a rarity, no longer the exception. Approximately 84% (up from 76% a year ago) of all developers use or plan to use AI coding tools, according to an AI Coding Assistant survey Stack Overflow conducted this year. Developers report being most comfortable turning to AI for tasks like searching for answers, learning new concepts, and writing documentation, and 44% of developers now use AI tools to learn to code, up from 37% the year before. Interestingly enough, when developers are asked what their favourite tools of the art are best at, "creating documentation" and "explaining any existing code" are near the top of the list, ahead of "writing new code from scratch.

The final one is worthy of contemplation: developers are increasingly turning to AI to explain a concept rather than write plain, original code for them. That's right, a direct miss on everything that the tutorial does at its core, which is explaining.

No wonder, it's not that difficult! The tutorial is geared to the "average reader" (as it's called). A question is directly written for you right now with your stack trace, your file, your specific stupid typo. No pages of preamble to scroll through to discover just one line of config that you needed, no "Closed as duplicate" and no ads, just an answer tuned to your exact problem.

However, this doesn't seem to be a clean sweep for AI.

And this is where it gets more interesting than 'AI beat tutorials, tutorials are dead!'. Usage is on the increase, but trust is not. Some 46% lack confidence in the accuracy of AI-generated output, up from 31% a year ago, and nearly two-thirds feel AI frequently generates code that seems correct but isn't necessarily reliable. In fact, according to research from METR, seasoned developers actually took 19% longer to accomplish their tasks using AI tools; however, they felt they finished 20% faster after completing the work. There is definitely an overestimation of how much AI is actually supporting people.

An even more acute concern is piling up regarding junior developers. They do not develop the predispositions they need when they rely on AI to solve their problems rather than on docs and forums. They can possibly write working code without knowing how it works, which is okay up until the moment the AI goes off-track by making a minor mistake that it finds hard to track in the code; at that point, they don't have a solid base to lean on if it goes astray.

It is not a matter of "tutorials stink, AI is good. It's that developers have settled on a path that's more time-consuming and difficult, and that offers the chance to develop real comprehension, rather than a quicker way that yields an answer with little assurance it's correct.

Popular lessons can be seen when you write tutorials. Writing tutorials will show some of the popular lessons.

This is not that it is time to halt its development; it's just that it's time to modify what you write and how. Generic explanation/memorized text is strong, with the notable exception of gotchas or "why this worked last month, and not now", explaining architectural trade-offs is strong, but nothing concerning a fast-changing library or a particular corner case is strong. Well, that's where a good article still gets its power from. It also helps when you are aware of the fact that unless the AI does an excellent job with their answer, your reader is not coming to your post cold, rather they are here because they want to take a look at it to see if it matches their requirements and/or sanity, so if you write assuming they came to your post because the AI answer did not suffice, it will benefit more than an answer they are reaching for from cold.

Optimise for skimmability and machine-readability as well, because these days there's a decent portion of traffic that's not coming to you from a human who's reading from top to bottom, but rather there's a machine there reading your page to respond to the query of someone else. Headings, explicit statements of code, and clear explanations benefit both the writer and the reader. Finally, don't forget to be more specific about the "why" rather than the "how" — it's the one thing that thin AI answers so rarely but the most crucial part of what junior developers need and the part that will keep a human reader on your page.

What direction this is taking

I don't know why, but tutorials don't just disappear. I don't think the form that dies is a particularly useful way to get X configured, since there's a much simpler prompt that does the job more easily. The things that remain, perhaps even grow, are the pieces of writing that convey judgment, negotiation, nuance, and detail that have not yet been fully captured through modelling.

So was the love for reading changed. It wasn't until somebody "got it" that the need for someone who actually understood the problem.

Array in Go

Frihk Ian — Wed, 24 Jun 2026 09:33:49 +0000

What is an Array in Go?

In Go, an array is a fixed-size, ordered set of values with the same type. Imagine an array as a 12 egg tray; the minimum number of eggs which can fit into an array is 12; the maximum number of eggs which can fit into an array is 12. That is the exact behaviour of a Go array.

package main

import "fmt"

func main() {

var groceries [3]string// Step 1: Create an array that holds 3 strings
groceries[0] = "Bread"// Step 2: Put "Bread" in slot 0
groceries[1] = "Milk"// Step 3: Put "Milk" in slot 1
groceries[2] = "Eggs"// Step 4: Put "Eggs" in slot 2
fmt.Println(groceries)// Step 5: Print the whole array
}

Expected output:
[Bread Milk Eggs]

Zero Values

In Go, you create an array by using the var keyword, and each of the slots receives the safe code Zero value, given that no elements are explicitly set.

This means that your array will never be in an unsafe state of being uninitialized. It will be valid on every slot, even before set. The same thing is a safety feature in Go intentionally.

var prices [3]float64

fmt.Println(prices) //  Output: [0 0 0]  - Go fills all the values with zeros automatically

Declaring an Array

In Go, you can declare an array in a few different ways, and you will learn about each of them in turn.

Using the var Declaration

var groceries [3]string
groceries[0] = "Bread"
groceries[1] = "Milk"
groceries[2] = "Eggs"

If you want to initialise an array of a specific size and use it later, then this is the best method to achieve this.

Array Literals

If you are already aware of all the values at the time you write the code, then you can use the literal syntax:

package main

import "fmt"

func main() {
groceries := [3]string{"Bread", "Milk", "Eggs"}
fmt.Println(groceries)
}

Expected output:
[Bread Milk Eggs]

The actual syntax is:
[size]type{value1, value2, value3}
This method is used when we know the values which we want to store in an array.

Let the Compiler count for you — The `...` trick

When using literal syntax, and you find that you have to manually count yourself, there's a shortcut in Go. Use ... to fill the size so the compiler can calculate the length automatically.

groceries := [...]string{"Bread", "Milk", "Eggs", "Butter", "Coffee"} //Three dots  compiler counts for you

The type of groceries is [5]string. The ... instructs the compiler to count for you. This will be helpful if you have a super long list and you can't determine its length.

Sparse Initialization

You can also use index: value syntax in the braces: to specify where a value will go:

package main

import "fmt"

func main() {
// Put "Bread" in slot 0 and "Coffee" in slot 4; all other slots get ""
groceries := [5]string{0: "Bread", 4: "Coffee"}
fmt.Println(groceries)
}

Expected output:
[Bread Coffee]

This is helpful when you have an array of a large number of elements, but just a couple of elements to change.

How to access elements and modify an array.

Each element of an array is retrieved by the array name and an index number enclosed in square brackets.

package main

import "fmt"

func main() {

groceries := [3]string{"Bread", "Milk", "Eggs"}

fmt.For each element, read it on the screen: 
Println(groceries[0])// Read "Bread" on the screen
fmt.Println(groceries[2])// Read slot 2: Eggs
groceries[0] = "Brown Bread" // Change the value of the 0th element of the array.
fmt.Println(groceries[0])// Read slot 0 again → "Brown Bread"
}

Expected output:

Bread
Eggs
Brown Bread

What are the consequences of going beyond the lines?

If you try to access a non-existent part of a structure (for example, groceries[5] for a 3-element array), then Go will immediately exit the program with a runtime panic:
runtime error: index out of range [5] with length 3
Not a silent bug this time. Go lets you know what was amiss. len(array) - 1 is the final valid index in the array.

Getting the Length with len()

len() returns the size (number of slots) of an array:

package main

import "fmt"

func main() {
groceries := [5]string{"Bread", "Milk", "Eggs", "Butter", "Coffee"}
fmt.Println("Items on list:", len(groceries))
}

Expected output:
Items on list: 5

If an array is declared with a size, then len() always returns the exact size, irrespective of whether there are values stored in some of the array's slots. An array is always the size that it was created to be.

Also, there is an operation cap(), which is called "capacity". Arrays cannot be lengthened or shortened, but the two functions, cap() and len(), return the same value. Use len(arr) instead of literals for the size. If you ever change the array declaration, len() adjusts automatically.

When the array is of length, len() always returns the size (independent of whether or not there are zeroes in the array). An array is always allocated the memory space it was declared to have.

Arrays are valued, not references.

As a result of Go's copy behavior on assigning an array to a new variable, the entire array is copied. There are two independent variables – if one changes, the other one definitely will not change at all. Let's say we think of an example;

package main

import "fmt"

func main() {
groceries := [3]string{"Bread", "Milk", "Eggs"}
backup := groceries// This copies ALL of groceries into backup

groceries[0] = "Brown Bread"// Change the original

fmt.Println("groceries:", groceries)
fmt.Println("backup:", backup)
}

Expected output:

groceries: [Brown Bread Milk Eggs]
backup:[Bread Milk Eggs]

The above shows that despite replacing groceries [0] with ‘Brown Bread’, backup was not affected. This is similar to photocopying your shopping list! After they've made the photocopy, it remains unchanged if they write on the original. They started identical, but are now two completely separate pieces of paper.

Sharing With Pointers

If we want, the changes that we make with our new variable to affect the original array, it's using a pointer.

package main

import "fmt"

func main() {
groceries := [3]string{"Bread", "Milk", "Eggs"}
shared := &groceries// & means "give me the address of groceries"

groceries[0] = "Brown Bread"

fmt.Println("groceries:", groceries)
fmt.Println("shared:", *shared)// * means "follow the pointer to the value"
}

Expected output:

groceries: [Brown Bread Milk Eggs]
shared:[Brown Bread Milk Eggs]

&groceries make a pointer. You don't copy the array; you copy a small "address" indicating where the array is stored in memory. That is followed by the word ‘*shared follows that address to get the actual value. When Shared access is needed, Pointers are used. In most situations, you'll opt for the default copy behaviour, which is more secure and easier to do.

Comparing Arrays

Go and share how you can use “==” and “!=” to compare two arrays of equal “size” and “type”.

package main

import "fmt"

func main() {
list1 := [3]string{"Bread", "Milk", "Eggs"}
list2 := [3]string{"Bread", "Milk", "Eggs"}
list3 := [3]string{"Bread", "Milk", "Coffee"}

fmt.Println("Same?", list1 == list2)// true
fmt.Println("Same?", list1 == list3)// false
}

Expected output:

Same? true
Same? false

Two arrays are equal if they are of the same type and length and the elements of the arrays in the corresponding positions are all equal. You must have both conditions.
Comparison of differently sized arrays is not possible. The compiler will halt you, since they are of different types.

Looping Through Arrays
For small arrays, manually writing the below would work: groceries[0], groceries[1], groceries[2]. Anything larger, you just use a loop to visit each element by itself. Some of the loops you can use to accomplish this are listed here:

The for range Loop

The most popular looping over an array in Go is the following for range loop:

package main
import "fmt"
func main() {
groceries := [5]string{"Bread", "Milk", "Eggs", "Butter", "Coffee"}
For each element (index, item) in the groceries: {
fmt.println("Index: " + index + " Item: " + item)
}
}

Expected output:

Index: 0 Item: Bread
Index: 1 Item: Milk
Index: 2 Item: Eggs
Index: 3 Item: Butter
Index: 4 Item: Coffee

The index will contain the number of the slot that is being modified on each iteration through the loop, and the item will contain a copy of the element being modified. The loop stops by itself when it runs out of elements. No more worrying about out of bounds.

In Go programming, all the variables defined must be used. The for-range loop provides Go with two variables in its "for" clause: the index and element variable. If the index isn’t useful to you, then you can't just leave it there intact. It will refuse to compile with Go.

This is where the blank identifier _ is introduced. It is Go's way of letting you say, "I know this value exists, but I am deliberately throwing it away."

package main

import "fmt"

func main() {
groceries := [5]string{"Bread", "Milk", "Eggs", "Butter", "Coffee"}

for _, item := range groceries {
fmt.Println("Item:", item)
}
}

Expected output:

Item: Bread
Item: Milk
Item: Eggs
Item: Butter
Item: Coffee

It's also possible to discard the value and keep the index. If so, simply do not use the second variable at all:

For each index in the groceries array {
fmt.Println("Index:", index)
}

A classic for Loop.

In the case where you require more control, such as when going in reverse or skipping an element, the classic counter-based for loop is best:

package main

import "fmt"

func main() {
groceries := [5]string{"Bread", "Milk", "Eggs", "Butter", "Coffee"}

for i := 0; i < len(groceries); i++ {
fmt.Println("Position", i, "->", groceries[i])
}
}

Expected output:

Position 0 -> Bread
Position 1 -> Milk
Position 2 -> Eggs
Position 3 -> Butter
Position 4 -> Coffee

Iterating in reverse:

for i := len(groceries) - 1; i >= 0; i-- {
fmt.Println(groceries[i])
}

//`Output: Coffee → Butter → Eggs → Milk → Bread`

Printing every other item:

for i := 0; i < len(groceries); i += 2 {
fmt.Println(groceries[i])
}

//`Output: Bread → Eggs → Coffee (slots 0, 2, and 4)`

Multi-Dimensional Arrays

So far, all the arrays have been a single row of values (one-dimensional). Multi-dimensional arrays (arrays of arrays) are also supported in Go.
The most common case is a 2D array, which is a grid or a table. For instance, if I go to the shops every week and make a plan for the items I want to buy by each day and area of the shop:

package main

import "fmt"

func main() {
// A 3-day plan with 2 items per day
weeklyPlan := [3][2]string{
{"Bread", "Milk"},// Day 0
{"Eggs", "Butter"},// Day 1
{"Coffee", "Fruit"},// Day 2
}

for day, items := range weeklyPlan {
fmt.Printf("Day %d: %s and %s\n", day, items[0], items[1])
}
}

Day 0: Bread and Milk
Day 1: Eggs and Butter
Day 2: Coffee and Fruit

[3][2]string: An array of 3 elements, each of which is an array of 2 strings. The first index tells you which row to choose, the second index tells you which column to choose:

weeklyPlan[0][0] = "Bread"// Day 0, first item
weeklyPlan[0][1] = "Milk"// Day 0, second item
weeklyPlan[2][1] = "Fruit"// Day 2, second item

An index position is needed to reference a particular cell, the first being the row index, and the second, the column index.
passing an Array object to a function.
In Go, an array passed to a function is itself a complete copy of the array; the function does not refer to the original array. Any changes the function makes don't affect the original:

package main

import "fmt"

func printAndModify(list [3]string) {
list[0] = "Changed"// Modifies the LOCAL copy only
fmt.Println("Inside:", list)
}

func main() {
groceries := [3]string{"Bread", "Milk", "Eggs"}
printAndModify(groceries)
fmt.Println("Outside:", groceries)// Original is unchanged
}

Expected output:

Inside: [Changed Milk Eggs]
Outside: [Bread Milk Eggs]

The function takes a snapshot of an array that is independent of one another.
If you have to change the original function, provide a pointer:

package main

import "fmt"

func updateFirstItem(list *[3]string) {
list[0] = "Brown Bread"// This modifies the original
}

func main() {
groceries := [3]string{"Bread", "Milk", "Eggs"}
updateFirstItem(&groceries)
fmt.Println("Outside:", groceries)// Now the original IS changed
}

Expected output:
Outside: [Brown Bread Milk Eggs]

If you have a large array greater than a few hundred elements, always use a pointer instead of copying to avoid the cost of the copy.

Limitations of Arrays

Though concise and straightforward, arrays are restricted in their use and come with limitations that you'll hit hard soon.

The Size Is Fixed Forever

After defining a [3]string, it will always contain exactly 3 strings, always! You can't add a fourth item. You can't remove one to shrink it. The size is baked in at compile time. If your shopping list grows to 6 items, your [5]string array can't help you.
The array size can not be a variable, must be a literal number or named constant:

n := 5
var groceries [n]string

The above is a compiler error because of the occurrence of the variable n.

Fix:
const n = 5
var groceries [n]string// it Works, n is a constant

This means you can't create an array whose size depends on something you only know at runtime, like how many items the user typed in. For that, you need a slice.

Passing Large Arrays Is Expensive

Every function call copies the entire array. For a [10000]string, that is 10,000 strings copied just to call a function.
Arrays of Different Sizes Are Incompatible Types
A function that accepts [3] strings can't be called with a [5]string. You would need two separate functions with different signatures.
append() Does Not Work on Arrays
append() — the function that adds elements to a collection — only works on slices, not arrays:

groceries := [3]string{"Bread", "Milk", "Eggs"}
groceries = append(groceries, "Butter")// Compiler `error`: append expects a slice

These limitations are not bugs. Fixed-size value types are simple, predictable, and give the compiler strong guarantees. But most real-world programming needs something that can grow and shrink at runtime. That something is the slice.

Common Mistakes with Arrays

Mistake 1: Assigning Arrays of Different Sizes

list := [3]string{"Bread", "Milk", "Eggs"}
var biggerList [4]string = list//  Compiler `error` — different types

Fix: make sure both arrays have the same size, or use a slice if you need flexibility.

Mistake 2: Expecting Assignment to Share Data

list := [3]string{"Bread", "Milk", "Eggs"}
backup := list
backup[0] = "Brown Bread"
fmt.Println(list[0])// Prints "Bread", NOT "Brown Bread" — list was not changed

Arrays are value types. Assignment copies everything. If you want shared access, use &list to get a pointer, or switch to slices.

Mistake 3: Off-by-One on the Last Element

groceries := [3]string{"Bread", "Milk", "Eggs"}
fmt.Println(groceries[3])//  Runtime `panic`: index out of range

For an array of length 3, the valid indexes are 0, 1, and 2. The last valid index is always len(array) - 1.

Structs in Go

Frihk Ian — Thu, 04 Jun 2026 07:24:29 +0000

Let's explore structs in Go. If you know Go's basic types like string, int, and bool, structs let you handle more complex data.
Say you're building a store app. You need a product's name, price, and in-stock status. Using separate variables quickly becomes messy.
Structs can simplify this. Picture structures are like a blueprint. It makes it possible to package all the related information in one neat and organized bundle.
Now let's dive into creating and using custom data types in Go.

Declaring Structs

Before using a struct, we first need to describe what it looks like. The result of defining a struct is not a piece of data, but the blueprint of data we want to store later on.
Let's take a look at the declaration of the Product struct:

package main

import "fmt"

// We use the 'type' keyword to define a new custom type.
// We name our type 'Product' and specify that it is a 'struct'.
type Product struct {
   Name    string  // Field for the product's name
   Price   float64 // Field for the price
   InStock bool    // Field to check if it's available
}

Creating Struct Instances

Using the struct we just created, let's create a product. Using the struct blueprint to create a piece of data is referred to as creating an instance.

package main

import "fmt"

type Product struct {
   Name    string
   Price   float64
   InStock bool
}

func main() {
   // Creating an instance of Product using a "struct literal."
   item1 := Product{
       Name:    "Wireless Mouse",
       Price:   25.99,
       InStock: true,
   }

   // Creating an instance but leaving fields blank
   item2 := Product{
       Name: "Mousepad",
   }

   fmt.Println(item1)
   fmt.Println(item2)
}

Expected Output:

{Wireless Mouse 25.99 true}
{Mousepad 0 false}

You might be thinking Why does item2 show 0 and false when we didn’t set them?
This is one of Go’s most important behaviours: zero values. In Go, when you declare a variable but don’t give it a value, Go doesn’t leave it empty or undefined (which causes bugs in many other languages). Instead, Go automatically fills it with the zero value for that type.
Since we gave item2 a name, Go automatically sets the price to 0 and in stock to false . This is one of the features in Go that make it exceptional.
Accessing and Modifying Fields
When you want to modify or read information from a struct, you use a dot notation. Consider the dot to be opening up a particular drawer of your filing cabinet to view a folder.

package main

import "fmt"

type Product struct {
   Name    string
   Price   float64
   InStock bool
}

func main() {
   item := Product{
       Name:    "Keyboard",
       Price:   45.00,
       InStock: true,
   }

   // Reading a field
   fmt.Println("Original Price:", item.Price)

   // Modifying a field
   item.Price = 39.99

   fmt.Println("Discounted Price:", item.Price)
}

Expected Output:

Original Price: 45
Discounted Price: 39.99

Anonymous Structs

Sometimes we want to bundle up some information for one-time use. In such a case, we don’t want to have to go through the trouble of formally defining a whole blueprint. They are particularly useful when holding configuration settings, grouping test inputs, or temporarily organising data for a single function. We use anonymous structs in this way:

package main

import "fmt"

func main() {
   // Declaring and initializing a struct at the exact same time
   config := struct {
       Port string
       Env  string
   }{
       Port: "8080",
       Env:  "Production",
   }

   fmt.Println("Running on port:", config.Port)
}

Expected Output:

Running on port: 8080

This is a little confusing, if you are new to Go, because you create the blueprint, then use it to create an instance. Let's look at the code snippet again.

  config := struct { <- this is the blueprint opening brace
       Port string
       Env  string
   }{   <- this is the closing brace for the blueprint, followed by an opening brace.
       Port: "8080",
       Env:  "Production",
   }   <- this is the closing

Think of this like defining a shape, then filling it. Keep in mind that this is a non-reusable type.

Nested (Embedded) Structs

Unlike other programming languages, Go has no “classes” or “inheritance”. Instead, Go employs a technique of packing smaller structs into larger structs, similar to Russian nesting dolls.

package main

import "fmt"

// The smaller struct
type Address struct {
   City    string
   Country string
}

// The larger struct
type User struct {
   Name    string
   Contact Address // Embedding the Address struct here
}

func main() {
   player := User{
       Name: "Alice",
       Contact: Address{
           City:    "Nairobi",
           Country: "Kenya",
       },
   }

   // Accessing the nested data
   fmt.Println(player.Name, "lives in", player.Contact.City)
}

Expected Output:

Alice lives in Nairobi.

Struct Comparison

A question might pop into your brain asking, “Are you able to compare two structs to determine whether they are equal or not?” Yes! Go supports the normal == operator, but only if all the fields within the struct are comparable.

package main

import "fmt"

type Product struct {
   Name  string
   Price float64
}

func main() {
   item1 := Product{Name: "Mug", Price: 12.50}
   item2 := Product{Name: "Mug", Price: 12.50}
   item3 := Product{Name: "Mug", Price: 15.00}

   fmt.Println("Are item1 and item2 identical?", item1 == item2)
   fmt.Println("Are item1 and item3 identical?", item1 == item3)
}

Expected Output:

Are item1 and item2 identical? true
Are item1 and item3 identical? false

Go looks at every single field. If everything matches perfectly, the structs are considered equal.

The Photocopy vs. The Original

This is the most essential concept for beginners in Go. Go’s default behavior is to send a struct by value into a function.
If you were to give a friend a copy of your notes, how would they look? If they add a mustache to the photocopied version, you are fine! This is the default behavior of Go. To change an original struct, the function has to be passed a pointer to it (that is, the original notebook).
Let’s observe both of them together:

package main

import "fmt"

type Product struct {
   Name  string
   Price float64
}

// Pass by Value (The Photocopy)
func failedDiscount(p Product) {
   p.Price = p.Price - 5.00
}

// Pass by Pointer (The Original)
func successfulDiscount(p *Product) {
   p.Price = p.Price - 5.00
}

func main() {
   item := Product{Name: "Book", Price: 20.00}

   failedDiscount(item) // Trying to discount the photocopy
   fmt.Println("After failed discount:", item.Price)

   successfulDiscount(&item) // Giving the function the original via '&'
   fmt.Println("After successful discount:", item.Price)
}

Expected Output:

After failed discount: 20
After successful discount: 15

Best Practices & Common Beginner Mistakes

In Go, names of fields that begin with a capital letter are “exported” and available to other packages (as opposed to names that start with a lowercase letter, which are “private”). If it begins with a lower-case letter (e.g., name), it belongs only to the package it is in. If in any doubt, make them capitalized so that you can use them freely.
Pointers for Modification: Keep in mind the photocopy rule. If your function will call to change or update a struct, then you must pass a pointer (*).

Summary & Your Mini-Challenge

You’ve made it! You’ve learned to structure unsorted variables into orderly, sensible structures. You know how to construct blueprints, make instances, navigate nested data, and update nested data correctly with pointers.

DEV Community: Frihk Ian

Go for the JavaScript Developer: What Tripped Me Up and What Finally Made Sense

Two Languages, Two Personalities

Errors: Thrown Versus Returned

Concurrency: One Thread Versus Many

Types: Suggestion Versus Contract

Tooling: The Stuff You Feel Every Day

What I Still Love About JavaScript

Why I Use Both

The Bottom Line

Lessons From Learning With No Teacher

Why This Model Exists

What Actually Works

What Is Genuinely Hard

How I Decide I Have Been Stuck Long Enough

Asking Well Is a Skill

Learning to Give Feedback

Would I Recommend It?

Five Years Ago, "Junior Developer" Meant Something Different. Here's What I'm Facing Now.

The Bar Was Lower, and I'm Not Complaining About That

Fast forward to today, and the expectations have shifted. A Portfolio is not all there is anymore. You Have to Prove You Can Ship.

And as the required stack broadens, one thing remains clear: fundamentals still matter.

Just as the fundamentals remain crucial, another major shift has arrived: the role of AI in entry-level work.

At the same time, the landscape for junior developers isn't just changing in terms of skills and tools—it's also expanding geographically.

Visibility in the community has become just as important as technical skills.

Given all these factors, it’s natural to wonder whether this new landscape is fair.

What I'm Doing About It

In the end, here’s what it comes down to:

I Got a Signed Job Offer Letter for a Job that Never Existed

The offer that wasn’t.

Why it lasted for more than 48 hours

The tell, and what I walked away with

What to look out for and what to do.

Every Automation Wave Was Supposed to Kill Programming Jobs. This Time People Actually Believe It.

The pattern, if you actually look at it

Why people believe this time is actually different

So which is it

What are the ethical implications of AI in healthcare?

The thing is, though. Funny when it's a food that's poisoned. But is it still funny when it's your bloodwork

Which leads directly into the second problem, the heavier one: When it goes wrong, who owns that?

Nobody Can Agree What a Software Engineer Even Does Anymore, and That's the Real Story of 2026

Quite simply, the same name, a very different role.In simple terms, the same name, a very different role.

Explain the reasons behind this happening now and not at another time.

Let me know your true mismatch

Vibe Coding Didn't Kill Junior Devs' Careers. It Just Fast-Forwarded Them.

The surging demand for hiring that no one anticipated.

Next, the codebases had to be tested!

The market took no notice of this,

Multiagent orchestration article

Nobody's Reading Tutorials Anymore. They're Just Asking AI.

Array in Go

What is an Array in Go?

Zero Values

Declaring an Array

Using the var Declaration

Array Literals

Let the Compiler count for you — The ... trick

Sparse Initialization

How to access elements and modify an array.

What are the consequences of going beyond the lines?

Getting the Length with len()

Arrays are valued, not references.

Sharing With Pointers

Comparing Arrays

The for range Loop

A classic for Loop.

Multi-Dimensional Arrays

Limitations of Arrays

The Size Is Fixed Forever

Passing Large Arrays Is Expensive

Common Mistakes with Arrays

Mistake 1: Assigning Arrays of Different Sizes

Mistake 2: Expecting Assignment to Share Data

Structs in Go

Declaring Structs

Creating Struct Instances

Anonymous Structs

Nested (Embedded) Structs

Struct Comparison

The Photocopy vs. The Original

Let the Compiler count for you — The `...` trick