We often correlate large systems with complexity, but that is not always true. Small systems can also be deeply complex when simple changes require disproportionate effort or context. Complexity is ultimately perceived by the reader rather than the author.

As developers, our job is not to create code that only we can work comfortably with, but code that others can understand, extend, and operate safely over time.

Complex systems usually present themselves in three ways:

1. Change amplification: small tasks require touching many areas of the system.

2. Cognitive load: too much context or domain knowledge is required to complete a task safely.

3. Unknown unknowns: you can no longer predict how changes will affect the overall system.

These symptoms are often caused by dependencies and obscurity. Dependencies increase coupling, which leads to change amplification and higher cognitive load. Obscurity hides intent and system behavior, creating uncertainty and making software harder to reason about.

As we build systems, complexity naturally accumulates over time. Systems rarely become unmanageable overnight. Instead, complexity grows gradually through shortcuts, inconsistent abstractions, layered workarounds, and local optimizations that ignore the broader design.

Reading this chapter contrasts nicely with No Silver Bullet. Some complexity is inherent to the problem domain itself, a tax we cannot fully eliminate. But accidental complexity is something we continuously introduce through poor boundaries, leaky abstractions, and inconsistent design decisions.

We should strive to make systems simpler by lifting common dependencies and making the system as obvious as possible without overwhelming implementations. Good APIs reduce this burden. Consumers should care about outputs and behavior, not internal orchestration or implementation details.

Complexity compounds not only through bad code, but through fragmented design thinking.

Now with AI, this becomes even more relevant.

Reflecting on the current state of software engineering, as we use more and more generated code, we are slightly doing ourselves a disservice by spawning agents into already messy codebases and slowly increasing the complexity of our systems.

We are moving faster and building more things. Two things can be true at once:

• We are shipping faster.

• We are increasing long-term system complexity.

The more we rely on these tools uncontrollably, the more we hand over understanding of the system itself. Over time, the system becomes increasingly unknown to us and therefore harder to maintain.

In the near term, everything may appear to work as expected. But I foresee an increase in bad software (and we are already seeing incidents that are becoming harder to patch, debug, and investigate). As we use these tools more, we should scrutinize their output carefully and ensure we still understand the decisions and interactions within our own systems.

Maybe. But if the underlying system is already complex, AI may simply generate even more complexity on top of it, making the system even harder to reason about.

As outlined in my previous post, “Design 2x and Ship Once,” we should strive to gain enough domain knowledge before blindly trusting the tool. It is important to maintain a high-level understanding of what is being added and steer AI tools toward less complexity, not more.

The better we understand the domain, the better the results we will get. We spend fewer tokens fighting the system, make better architectural decisions, and maintain healthier software over time.

Less is still more.

Reading it back, I think the post still holds, but the part of it that actually matters has shifted.

The top comment on the HN thread pushed back nicely at the time:

Anything worth coding is worth coding at least twice… writing the code is often the quickest way to understand which design questions you need to ask yourself.

I read that two years ago and kind of disagreed. I read it now and think, yeah, that’s basically how I work whenever using Codex, Claude Code, whatever your flavor of AI tooling, code got fast. Prototyping two versions of a thing isn’t a luxury anymore, it’s almost the default.

Code isn’t just output anymore. It’s part of the thinking.

So does the old post still hold? Yes. Just not where I expected.

The thinking didn’t go away, it moved up a layer

Two years ago, the hard part was: which abstraction, which data structure, which path do I commit to? That decision used to be expensive because implementing it was expensive. Today, you can spin up two prototypes in the time it took to write one, and the prototype tells you things the whiteboard never could. Honestly, the whiteboarding-then-deciding dance feels a bit overengineered now for a lot of problems.

But the part that did get harder is everything upstream:

• Should this thing exist?

• What does correct even mean here?

• What’s the actual user problem?

• What assumption am I making silently that will bite me on day thirty?

These questions don’t get easier with AI. If anything, they get harder, because the model will happily generate a beautiful implementation of the wrong thing. You end up with a clean abstraction around a workflow nobody actually needs, and you feel productive the whole time.

Let the model grill you

This is where Matt Pocock’s /grill-me skill earns its keep. It flips the usual dynamic. Instead of you prompting the model for answers, the model interviews you, walking down the decision tree of your plan one question at a time. Why this and not that? Why now? What happens if your assumption is wrong? It keeps going, sometimes 20+ questions deep, recommending an answer to each so you can either nod along or push back. The output isn’t code, it’s clarity about what you’re actually building.

This reframes the earlier point. The most useful thing the model does isn’t always to generate, sometimes it’s to interrogate. The “ask why five times” idea from the original post, that one I’d actually crank up the volume on, not down. Tools like grill-me are how you do it without having to discipline yourself into it.

Polished doesn’t mean correct

AI amplifies your thinking. It doesn’t fix it. It’s not a clean f(x)→x mapping where you put a prompt in and get a clean answer out. The output is shaped by everything you brought and everything you forgot to say. The question you didn’t ask. The constraint you didn’t mention. The assumption you made silently because it felt obvious.

Garbage in, polished garbage out. The polish is the dangerous part.

The new shape

So if I had to rewrite the old post for 2026, I think it’s something like:

Code is no longer the bottleneck, though it’s not exactly free either. Knowing what’s worth building is the bottleneck. And the only way I know to get there is still the boring one: sit with the problem, ask why a few more times than feels necessary, build a version, look at it, then ask again.

Two years ago I thought thinking was a step you did before code. Now I think it’s something you do around code: before it, during it, after it. The code is just one of the languages you think in now.

Thinking didn’t get cheaper. Everything else did.

I didn’t like the HYPE, but internally I liked the tech behind it. Before that, in 2018, I worked as a student tutor and was exposed to researchers who were actively working on small models and machine learning for data search and object recognition.

What changed?

As time went by, around the end of 2025, I decided not to go against the wave and did my first vibe coding session. Of course, the result wasn’t amazing. Things were “sloppy” and didn’t feel polished enough for my liking.

But I was hooked on Cursor’s tab tab and started using it more and more, and slowly bought into the hype.

I could use different models, rubber duck on my implementations and ideas, prototype quickly, and discard code without feeling like “but I’ve written so much”. I could build things that would take months in days or weeks, sometimes hours.

Then OpenCode came along, and I like the tools the Anomaly folks work on. Guess I was trying to be a contrarian and use something no one else was using. Then I slowly migrated to it, not as a super user but just keeping things simple.

And now?

Now I’m a token maxer 😂. I’ve embraced it, and stopped trying to cross the world on a boat when everyone was on a plane.

But I’m still a very opinionated user and I know how deceiving LLMs can be. I ran a test with a friend and it was evident that they just try to please you and do things to accommodate your desires.

But what changed? Why am I even writing this? The planning mode got me hooked for real for real.

It’s true that agents will generate an unmanageable number of LOC and deviate from the initial desired result, and I see folks have an unmanageable number of skills, rules, etc… the .md files that get outdated every day (don’t get me wrong, some are useful).

I decided to keep it simple and only hit build when I’m convinced and have a clear idea of what the desired outcome is. I would sometimes even generate some snippets to help me visualize, but spend most of the time prompting and thinking about what Good looks like, and even switch models during the process to get contrasting ideas. And yes, I still read docs, Stack Overflow, and google things in between, but the results are often good for what I’m looking for. Ofc I also gen slop, not always the desired result.

How do I work now?

It’s very similar to what I used to do before, but faster, as I don’t have to write things manually while I’m busy product thinking and reviewing outputs. Now I do:

1. Plan: gather all resources I need, analyze them, make sure they’re concise enough that if I gave this task to a fellow human or a non-super-powerful model, it would still work (accepting the slop caveat in some cases). Planning for the worst model, not the best one.

2. Evaluate and iterate on the plan: reading 😂. That’s what I’m still honestly working on, because so much text is generated that I get the urge to hit next all the time. Reading helps here to understand the plan, which I often ensure includes snippets. Hm, my plans I put in a secret folder, and they aren’t the ones the LLM creates (those are pre-plan). I generate full documentation planning each phase and iterate on them.

3. Execution: this is when I go for a walk and let AI do its thing. But as I said, I let it do it in phases so it’s humanly reviewable, and I stage them.

4. Review: this piece I now do on my own. With the changes staged, I review and correct until I’m happy to move to the next part.

The above may seem not so productive, and some would say “have rule X or skill Y do Z”. I tried, they don’t work for me. I like keeping things simple and sometimes slowing down to ensure I’m doing the right thing, especially when I’m writing customer-facing code and I know someone depends on what I wrote or instructed the LLM to do. I do it as well to be sure I can still debug manually if needed, in case providers are down or just not doing things right. And ofc I do it to avoid generating the same annoying floating UI with rounded borders that has no style (I have style, so my slop should at least have some).

Overall, just keep things simple and easy, do more with less. It’s cheaper, and you can always get great results.

If you’re into AI harnesses (dunno what that means for real, just sounds cool, so I’m saying it too) pi is a good example of less being more. Simple core, and it lets the user expand 😅.

Closing now: I sometimes vibe code, just generate code because it’s addictive and don’t follow any process, but these steps are for when I’m prototyping and all. Hm, and AI seems to be great with dev tools or productivity tools. They’re small in scope and have a very defined problem space. Now if you’re doing a SaaS and trusting AI alone, good luck. It’ll work, but your .env files will be out there :D.

Agentic code is fun. I’m now able to make some hard shit come to life easily. So if all those .md files are your thing, keep them, but the simpler, the better!

I think it’s safe to say that DRY (Don’t Repeat Yourself) is one of the most misunderstood principles in software development. Too often, it’s used as an excuse to avoid applying the right design patterns or to force everything into a single function just to avoid writing similar logic in different places.

Having seen DRY overused in codebases of all sizes, I’ve started questioning why we default to writing functions/classes that do everything. At first glance, it might seem like a good idea, but as the codebase grows and new requirements emerge, things get messy. We end up with functions that have lengthy argument lists, complex conditionals, and a lack of clarity in what they actually do.

The Problem with Overusing DRY 👎

“But what’s wrong with avoiding repetition?” you might ask. “Aren’t we just reducing unnecessary duplication?”

The issue is that DRY should be about eliminating actual redundancy, not forcing unrelated concerns into a single function. Let’s look at an example:

At first glance, this function might seem fine — it centralizes all the logic related to user actions. But on closer inspection, we’re doing more than we need to:

1. Unnecessary parameters: Not all actions require all parameters. For example, apply_discount requires discount, but view_product doesn’t.

2. Difficult to maintain: As more action types are added, this function will keep growing, making it harder to test and modify.

3. Error-prone: The more logic we cram into a single function, the more likely we introduce subtle bugs.

The Right Way: Separating Concerns 👍

A better approach is to separate each action into its own function. This might seem like more work initially, but it actually improves maintainability and clarity.

Now, instead of passing an $action_type and unrelated arguments, we have:

• ✔ Functions that take only the arguments they need

• ✔ Logic that is specific to a single concern

• ✔ Code that is easier to read, test, and maintain

This approach aligns with the Single Responsibility Principle (SRP), which states that a function, class, or module should have only one reason to change. Each function above now has a well-defined responsibility:

• purchase() handles user purchases

• applyDiscount() ensures discounts are applied correctly

• viewProduct() logs when a user views a product

By following SRP, we make the code more modular, maintainable, and easier to test. If new requirements arise—such as logging additional purchase details—we only need to modify the relevant function, without affecting unrelated logic.

When DRY Is Actually Useful 💡

While the above example shows when not to use DRY, let’s look at when DRY actually improves the code.

Here’s an example where we’re repeating the same logic across multiple functions:

We can extract the shared multiplication logic into a reusable function:

Why This Is a Good Use of DRY?

• ✔ Extracts real duplication – The multiplication logic is shared, but each function still retains its own responsibility.

• ✔ Improves readability – The code remains clear without unnecessary conditionals or excessive arguments.

• ✔ Keeps maintainability high – If we ever need to modify multiplication (e.g., logging operations), we can do it in one place.

DRY isn’t bad—it’s a great principle when used correctly. But if adding a new argument makes the function unpredictable or forces it to handle entirely different concerns, that’s a sign it should be separated.

Instead of blindly avoiding duplication, focus on keeping related logic together while separating concerns properly. This will lead to a codebase that is clear, testable, and easy to scale. And remember, DRY isn’t just about eliminating code duplication—it’s about reducing unnecessary redundancy, especially when the logic is shared, but still contextually distinct.

I ran through the same issue for so long until I heard a quote that said — “think twice, code once”, — and I incorporated it into my process; given that I like to visualise my thoughts.

The thinking process

Ideally, we should strive to produce maintainable and scalable solutions that are also easy to understand and test. Let’s say you have a task to add optimise a feature on a given app. At first glance, you may have an idea of what needs to be done and how, but then you decide to jump straight to implementation.

Going straight to implementation would be the best and fastest thing to do, assuming you have an idea of what needs to be done. Regardless of how much context I have on the feature, here is what I would do:

1. Gain context

Before doing any implementation, it is good to understand the context of why we are optimising the feature. This will enable you to define the impact of these changes.

You will retrieve all the requirements needed to implement your solution during this step. While understanding the context, ask yourself why five times. 

2. Draw your assumptions

Based on the previous step, you will now be able to write down your assumptions about what needs to be done and how. Ideally, you should have at least two possible paths.

Limit the number of assumptions to avoid being distracted or losing focus. Based on your assumptions, you can now stack rank them and drawing the pros and cons of each and compromising whenever necessary.

This step should be iterative, and it should be repeated at least once!

3. Implement

Selecting one of the potential paths or solutions now becomes more effortless, given that you already know the pros and drawbacks of one compared to the other. The implementation process will be faster as you have defined what needs to be done and how.

Overall, the message here is that before you code anything, you should spend some time thinking and writing down your thoughts. This will not only make you a better problem solver, but also help you become more aware of your decisions when crafting a solution.

As a bonus, I recommend you spend some time watching — Thinking Above the Code by Leslie Lamport1.

As time passed, and I engaged with more experienced engineers, it was clear that a common good trait was that they would do was to keep track of their process and daily/weekly wins.

Why track your progress?

You may have different reasons why you want to write down your high/lowlights, and some would want to do it:

• To ensure that they are on top of their daily tasks

• To write up reports

• For discussions in 1:1 with managers

Regardless of the reason, all the reasons above are still good reasons for you to at least get into the habit of tracking your progress. I personally started doing it more often to keep my manager informed and brainstorm ideas.

Initially, it seemed as if I was wasting my time, as I thought that not everything should be relevant to share or that I should always have very distinct learnings. Yet, when I revisited the older notes, I realised the growth and how much I was learning as time went by.

That boosted my confidence in the topics I am faced with on a daily basis and also improved my position in many discussions with other team members, as I didn't have to rely on my memory and talk from a good reference point2 .

Lastly, keeping track of my progress helps to ensure that I am well aware of my career goals and the opportunities for growth.

What to track and when to do it?

You may be asking now:

• What should I include in my journal?

• In which frequency should I do it?

There's no one-size-fits-all approach, as it all depends on you and your current scope. In my personal case, I keep a small notepad where I dump all my daily to-dos and expand my weekly journal from there.

I also schedule at least 45 minutes every Friday to write a more comprehensive note containing all the week's highs and lows. The topics I cover are:

• Highlights: describing what went well, and this also includes learnings;

• Lowlights/Blockers: what are my current challenges and items that I may or may not need assistance with;

• Discussion points: this may not be applicable for everyone, but I use this to discuss the points I want to debate with my managers and other ICs3 on the team

Overall, journaling or writing up your daily/weekly/monthly updates is an excellent way to observe where you can improve and what you are already doing well.

I'd encourage you to create a small routine in which you can write, review, and retain this to help you become aware of where you are in your career and identify what's next.

Throughout the past months, I have been approached by friends in the industry asking what my problem-solving process is and how I seem to always know where to look when asked for help. So, I decided to write this article to share how I solve the different tasks or problems I have at hand.

What is problem-solving? — You may ask; We can find various fancy definitions explaining what problem-solving actually implies. Some would define it as referring to psychology, computer science, cognitive science, or even logic, which is not wrong. Yet, in all different areas, it can be applied; it simply boils down to the ability of an individual or a group to solve given problems regardless of their complexity.

Problem-solving consists of using generic or ad hoc methods in an orderly manner to find solutions to difficulties. (Wikipedia)

Solving a problem

Most people approach problems differently; some use technique x, others technique y. Of course, some approaches are more efficient than others, but I don’t think there is a predefined method of solving a problem. I personally use a process that I have seen some of my favorite engineers use, proving to get the job done.

Enough talking; LOL; here is how I solve problems regardless of their complexity:

1. Understand the problem

Problems are like puzzles; we need first to see a complete picture before attempting to solve it. The first step to solving any problem is understanding what you are being asked to accomplish.

🚩 ”we cannot do anything without understanding.”

A common mistake that I would often make when assigned a task was to jump straight to my code editor and start writing the solution without knowing the final picture. Eventually, I would figure it out and solve the task, but I was very inefficient as I would ask the right questions late because I didn’t have a complete picture of what I was asked to do.

Clearly, before starting, we should seek to comprehend what is that we need to achieve; for this, we need to:

• Ask the right questions

• Write down the problem as you understood

• Validate your understanding of the problem

2. Break down into smaller chunks

After learning what the problem we have at hand is, we now should be to divide it into smaller and achievable subtasks. Using the puzzle analogy, if you have a big puzzle, you clearly have a picture of how it will look like once you complete but to quickly solve it, ideally, you would group the pieces that fulfill a section into small chunks. The same should apply to any problem you are solving.

Before writing a line of code (if the solution requires you to code), you will need to have a step-by-step approach that would help you have a solution for your problem puzzle. This can be challenging, but you can break things down and have a clear path to your solution if you understand the problem.

To get better at this, you will need to practice writing down; this can be seen as you are writing pseudocode that solves your problem by listing all the steps and indicating checkpoints that should be met before moving forward to the next stage.

🚩 “Divide and conquer.”

3. Relook the solution

Like in a code review process, in this step, if I have someone else available, I usually ask for a second opinion on my assumptions so I see if the next person at least can understand what it is that I am solving. Yet if I don’t have a second pair of eyes, I simply reiterate each step as if it was a new problem to be 100% sure of the solution I have in mind.

As this is the last step, I usually take more time catching possible issues and going back to the drawing board to adjust my initial assumptions.

🚩 The aim is to “write twice and code once.”

Only after relooking at my chunks; I do start applying what I have written down, always keeping in mind that this is not the absolute solution and that it can constantly be improved.

After all, solving problems is a skill that requires time to be developed (I am still working towards improving myself to become a better problem solver). Yet, I realized that the more problems you solve, the better you will become at providing a solution to issues that come your way, regardless of their complexity.

This doesn’t only apply to the software engineering profession but to all others. We are all solving problems one way or the other, so we all should find a process that works to better solve the problems we encounter daily.

Let’s keep on hacking 🙂.

Writing software solutions is a very exhaustive process and can get complicated when not thoroughly thought out.

Many of us (developers, software engineers, whatever you call yourself) tend to jump straight into building solutions before understanding “the why”, especially when we are very early in our careers.

E.g: Person A has problem X. We jump on and just decide that we can solve this problem by using tool Y. After the time spent writting some code we eventually solve the problem 🎉 , but Person A reports back that it was not even the problem they were attempting to solve!

TL;DR

After several discussions with a teammate, we both concluded that the best code is no code.

If there is a need for code, then it should be as simple as possible at first.

I know it may be asking yourself: how is it that the best code can be no code at all 😅? Let me explain what we mean by showing a few points:

The problem doesn’t need a software solution; it needs a behavioral change.

Before adding a new feature or building something new we need to ask ourselves the reason: why? – Without understanding the true reason we shouldn’t be writing any code at all. Sometimes (especially) when you build an entirely new product you will need to try to understand the core of that request.

During my university days, we studied Human-Computer Interface, and there I understood that we are building solutions for humans and humans will use these products, thus before changing the position of a button you will try to understand if there is a true need to make those changes.

Your code is not always needed.

This point talks back to the first one, imagine a scenario where you spend close to 2 hours trying and figure out how to solve a given problem that you think your code would solve, and then your code is never checked into production.

“Wasn’t my code good enough?” you may ask — but the reality can be that your code was never needed in the first place. The solution to the problem you were trying to solve had more to do with the way users were interacting with your solution. Thus we need to understand that when we are writing a piece of code, sometimes it will be deleted and forgotten like it never existed.

You might be tricked by your product manager.

Product managers or product owners (in some cases) are responsible for researching and understanding how users are interacting with a product, for this they conduct researches to understand the user needs and then write up the next set of features that should be built.

Your job as developers is to build those features, yet, we still need to try understanding further what is it that these features will be solving for.

I’ve been in situations where a new feature request seemed to be a great idea 💡, but after jumping into the code and connecting the dots I noticed that the code I was writing didn’t really solve the problem as it was instead potentially creating more problems for the final users.

The product manager can come up with a valid reason why they do need feature x to be built and we get paid to build it, but it is also apart of our job to access every single request before doing them.

Have always the product in mind, your code is there to simplify its users’ life. Seek to deeply understand what your are solving for.

You still have to code

To sum up, the lesser you write code and the more you understand the why of things the better your solutions will end up being. But, when you code something ensure that you write your code in the simplest way possible avoiding overcomplicating your implementation.

Keeping things simple and understanding them will allow us to test faster and get to know if our solution actually will solve the problem for the final user.

The best code is no code and the best solutions are the ones where your code is simplified and easy to extend.

Happy hacking!

Firstly, I want to clarify that I don't consider myself a sound software engineer, even though I learned how to write computer programs in high school. About three years ago, I landed my first job as a software engineer in a small start-up company in South Africa. That same year, people started calling me either software [engineer, developer, etc…] or whatever else.

As a result of working in a start-up that developed a solution for outside customers, I was expected to get things done. Although I moved jobs, the story remained the same. Eventually, I realized that my job was to get things done, and most of the time, I got them done quickly.

One day, in November of last year, I read an interesting article titled "The Product-Minded Software Engineer" by Gergely Orosz. It drastically changed my way of viewing my job as a Software Engineer. In this blog post, the author stated many interesting points that I wish everyone who builds software would think about.

The Checkboxes

But why the title, you may ask? The answer is that we all eventually become people who check boxes and mark them as done to secure our monthly income. This may apply to other jobs as well.

Most of the time, as an engineer, you will get called by your managers or team leaders, who will assign you a task, explain to you their expectations (most of which come from clients), and give you time to complete it. Then, you will say yes without asking the intent of the job. You will go and perform the task and wait for the next one, and the cycle repeats itself.

You may feel like you are growing because you completed 10x more tasks this week than the previous week, you got 100+ commits in a month, and you are done with your checklist. But you may not realize that you trapped yourself in an addictive cycle of ticking off boxes.

The Problems

After being there, I realized that checking the boxes alone was feeding my impostor syndrome more and more, as I was constantly in the mindset of "it is working, don't touch it, move to the next one." It was fun and exciting to always get kudos due to the number of tasks I was checking on my "to-do list." Yet, I found some problems with this:

1. Doing things because they have to be done without understanding the reason for their existence

All software engineers can relate. Many times, we are asked to change or add functionality to a system and just go and build, being unable to differentiate why it is needed vs. why I am building it. You might be building an unnecessary feature because the client or project owner said so, and in the end, you will be asked to remove it because it was not needed.

2. Being a false solution provider

Do software engineers know what their job means? Let's remember the job description. When you constantly tick off boxes, you will think that you are providing solutions, yet you are simply pleasing the asker.

3. Building things that you don't understand

This one complements my first point. The overall beauty of any job is being able to provide solutions to a specific group of people, and it is sad sometimes to see that the solution providers don't take some time to understand what we are trying to solve, thinking that if it is done, it is done. The small boxes we tick off every day add up to a bigger one, which is our contribution to the outside world, and not knowing what you are solving for can lead to future failure.

4. Poor solution

You are ticking off things, but is the overall picture important? Many of us get called to meetings and are given the project scope, and then we get the feature list and start implementing. As the other points above state, small tasks add up to a bigger one; the feature list you get will add up to an entire software system, web app, you name it.

Yet you can deliver it on time and within scope, and everyone is clapping, etc.… forgetting that you don't know who you will build it for and if it is needed to use x approach instead of y approach. So you built a poor solution that you would also not prefer to use.

In conclusion, I believe that all software engineers should know a bit of product mindset because everything has a lifecycle and needs to tell a story for those who will use your solutions. Ticking boxes alone may prevent you from understanding what you are doing. When we are assigned tasks or requests, we need to always be able to analyze and understand who we are solving for, why the solution is needed, and what it is that we are creating. If we aren't sure and unable to answer these questions, we are just ticking off boxes.

Software engineering is more than simply writing a nice feature. It is about user experience and constant solution creation. Everyone should do things only when they understand the intent of the request.

I constantly say that building software is an art, and sound artists know what story they are trying to tell.

Happy hacking!