When I joined a startup building software for a specialized industry, I thought my job was to write good code. But I learned that wasn't enough. Good code is part of the job, but that's not the real challenge—it was understanding what the code needed to do and understanding the problem from an engineer's perspective.

The Problem with Not Knowing the Domain

You've probably heard the phrase "Give a man a hammer, and everything looks like a nail." I've seen this happen several times when developing features. Software engineers can mistake something that looks like a data problem as a data problem and write everything to the database. On the other hand, engineers might take a simple data problem and try to calculate it dynamically when storing it would be simpler.

The zen here is being able to make the right decision. You need to take context from both sides and see which way is the efficient way to handle it. Do you want to store it in the database, or do you want to create a way to calculate it on the fly?

Here's the thing: domain experts often don't know what's possible with software, and software engineers often don't know what's possible in the domain. Domain experts might suggest solutions based on their current constraints. "We need a form where we can enter all 50 parameters," they say, because that's how they've always done it.

But maybe you don't need all 50 parameters. Maybe you need 5, and the other 45 can be derived. The expert sometimes misses this just because this is how they've always done it.

How to Bridge the Gap

1. Learn Enough to Participate in the Conversations:

   You don't need to become a domain expert, but you need to know what they talk about and be able to take part in their conversations. When the room is full of domain experts talking about the domain, you should be able to participate in the conversation. You need to know the big picture behind the topic. You can't just sit there as "just a software engineer." If you feel like you're bored, have no idea what the conversation is about, or have zero comments or questions—then you're not taking part in the conversation.

2. Don't Just Implement What Engineers Want You to Implement:

   I've made this mistake so many times—just doing what they wanted from me and implementing what they asked for, only to realize there was a better way to do it. Here, you have to be able to understand the problem from a domain expert's perspective and realize their pain point. You need to be able to see the best solution from a software engineer's eyes and implement something that the end user would be happy with. You need to be able to put on at least three hats.

3. Work Together on the Solution, Not in Sequence:

   The traditional approach is: domain expert defines requirements → software engineer implements → domain expert tests. This approach doesn't really work. You have to find ways to create solutions together. The tricky part is that you need domain knowledge, but you can't let domain experts dictate the implementation. Domain experts know their field. You know software. The solution lives at the intersection. They might say: "We need to manually adjust these 20 values every time." You should think: "Why are these values changing? Can we derive them? Can we automate this? What's the underlying rule?" Sometimes the answer is: "No, they genuinely need manual control." But often, there's a better way that neither of you would have found alone. In my experience, workshops to find solutions together and pair programming have been effective ways to figure out how to build small prototypes and expand on those gradually. I've written more on Sharing Domain Knowledge and Building Better Teams

You Don't Have to Know Everything

Remember: there will be moments when you don't understand something, and that's okay. Be humble and accept it. Or you can cheat a little and fake it—but being honest builds more trust in the long run.

Conclusion

When you're building a complex piece of software, the team handling this should be able to see it from three different people's eyes:

• The domain expert: What they are trying to solve
• The software engineer: How they are trying to implement it in an optimized way
• The end user: How this will solve their problem

If you get enough context on each side of the problem, then the solution you build will be to the point and spot on

When you're working with large amounts of code that primarily deals with geometry, it isn't always easy to make changes or understand the logic at a glance—even though it's usually doing something simple: creating a couple of lines and points.

You might have 1,000 lines of code that generates one simple geometric representation. Even if you wrote the code yourself, you're often missing the big picture by just reading it line by line.

I learned this lesson when I inherited some particularly complex code. Reading through it line by line wasn't enough. The logic was sound, the implementation was smart. I had to understand it first to be able to make changes to it, but understanding what it actually did required something more—something I had already been doing while developing.

I'd been visualizing it on paper and whiteboards.

I was making changes to the code, but even with unit tests, I wasn't quite sure if the big picture remained intact.

I needed to see the code!

But often in a cloud-based application, visualizing something requires so much work and wiring to make it visually available in the system. After all that effort, you don't really want to keep it in your codebase—it's just for you to test some piece of code.

I know what you're thinking: good code should be readable. Yes, I agree!

Clean code is important. But when working with geometry, it's not just the logic that matters—the end result is what's important, and you need to see it somehow. This approach isn't limited to geometric and spatial data either. Complex logic that depends on relationships between different elements can be visualized too. You can use it in signal processing, statistics, or anywhere the results have patterns or the generated data has a shape you can test visually.

For these problems, reading code is like trying to understand a sculpture by reading a description of it. You might get the idea, but you won't really see it.

In Farsi, there's a saying: "Hearing is never like seeing."

The Moment of Realization

I spent hours trying to understand code I'd written 8 months ago—or worse, complex code written by others. We've all been there. While trying to understand the code, I had a simple idea: what if I could visualize what the code was doing at each step? Then I would

1. understand the code more easily, and
2. when making changes, see whether I was on the right track.

I don't know if this is a common practice, but it helped me and later helped others write better code.

The concept is simple: write tests that produce visual output alongside their assertions.

import matplotlib.pyplot as plt
import numpy as np

def test_rotation_visual():
    points = np.array([[0, 0], [1, 0], [1, 1], [0, 1], [0, 0]])
    
    angle = np.pi / 4
    rotation_matrix = np.array([
        [np.cos(angle), -np.sin(angle)],
        [np.sin(angle), np.cos(angle)]
    ])
    rotated = points @ rotation_matrix.T
    
    fig, (ax1, ax2) = plt.subplots(1, 2, figsize=(10, 5))
    
    ax1.plot(points[:, 0], points[:, 1], 'b-o', label='Original')
    ax1.set_title('Before Rotation')
    ax1.axis('equal')
    ax1.grid(True)
    
    ax2.plot(rotated[:, 0], rotated[:, 1], 'r-o', label='Rotated 45°')
    ax2.set_title('After Rotation')
    ax2.axis('equal')
    ax2.grid(True)
    
    plt.savefig('test_outputs/rotation_test.png')
    
    assert rotated.shape == points.shape

And the result for the test generates the below image:

Wasn't that just much easier?

This test does two things:

1. Makes standard assertions (the shape is preserved)
2. Produces a visual artifact you can inspect

When the test runs, you get an image showing exactly what the transformation did.

When Visual Tests Became Essential

Visual tests became truly valuable when dealing with algorithms that had multiple interacting components. When you have systems where components affect each other—like constraints in a spatial system—visual tests show the relationships clearly:

def test_constraint_system_visual():
    # Setup elements with constraints
    elements = create_test_elements()
    constraints = apply_constraints(elements)
    
    # Visualize before and after
    fig, axes = plt.subplots(1, 2, figsize=(12, 6))
    
    plot_system(elements, constraints, axes[0], title='Initial State')
    
    resolved = resolve_constraints(elements, constraints)
    plot_system(resolved, constraints, axes[1], title='After Resolution')
    
    plt.savefig('test_outputs/constraint_system.png')

The Unexpected Benefits

1. Documentation That Can't Go Stale

The visual outputs are always in sync with the code because they're generated by it. Unlike diagrams in documentation, they can't become outdated.

2. Cross-Disciplinary Communication

When working with domain experts who aren't software engineers, visual tests bridge the gap. They can verify the logic is correct by looking at the output, without reading code. A domain expert once told me: "I can't review your code, but I can tell you if it looks right."

3. Confidence to Refactor

Visual tests give you confidence that refactoring didn't change behavior. The assertions might pass, but if the visual output looks different, something subtle changed.

4. Faster Debugging

When a bug appears, the visual test immediately shows where the logic diverged from expectations. No more adding print statements or stepping through a debugger for 20 minutes.

How to Implement This in Your Project

1. Use matplotlib or Plotly as the main libraries to generate images
2. Create a directory for outputs (e.g., /test_outputs) and add it to your .gitignore file
3. Based on the output you're getting, create helper functions to generate visualizations easily

Optional Enhancement: You could also add this to your CI and compare generated images to a checked-in reference image, this s something I thought of but never really tried but technically it should work well and you can automate these tests.

def images_are_similar(img1_path, img2_path, threshold=0.95):
    """Compare two images for similarity."""
    img1 = np.array(Image.open(img1_path))
    img2 = np.array(Image.open(img2_path))
    
    # Calculate similarity metric
    similarity = calculate_similarity(img1, img2)
    return similarity > threshold

Handy Tips

Use Subplots

Show before and after states, or show progression through steps. This makes the visualization more informative.

Add Annotations

Label important points and highlight problem areas. Identify the important points and lines, and add indexes, numbers, and values to them.

Review Them Regularly

Actually look at the visual outputs. They're only useful if you use them to understand the system.

We spend a lot of time making our code readable. Visual tests take that one step further—they make code visible.

Try It Yourself

Next time you're working on an algorithm that's hard to understand or verify, ask yourself: "Would I need to explain this on a whiteboard?" If the answer is yes, you're probably better off visualizing the code instead.

Imposter syndrome is very common in software jobs. Like anyone else in this industry, I've also felt it but but with the right mindset it can help you grow.

Why It's So Common in Our Field

Maybe the main reasons for this is that the industry is moving ridiculously fast and there are always people that know something or some parts better than you. It takes a long time to master all skills in software, and by the time you master some of them it becomes outdated and you need to work on some other skills. To add to this, when building software products there is domain knowledge involved and you probably don't know much about the domain and need to accept this as a fact.

Shifting Your Mindset

First of all, it's not a bad thing—don't see it as a negative thing. After doing a little search online, I found that I'm not alone and that made me think I need to accept that it isn't only happening to me. Because if it was only me, then I should be worried. Second thing I realized was that I do have some strong skills that maybe others might be struggling with, and I have some weak technical skills. Maybe my weaker technical skills and too much comparing myself with others was giving me this feeling. I needed to make up for the weaker skills and just stay calm and be realistic about my skills.

Focus on Core Skills, Not Just Tools

You need to be able to identify the core skills you need to develop as a software engineer. JavaScript is a tool for software engineers—tools change rapidly and even though you can master it and become the expert JavaScript developer, it won't be enough. Of course, as a software developer you need some basic understanding of how to develop software, but this isn't the only thing.

The Four Essential Skills

1. Problem-Solving and Domain Understanding

   Breaking down bigger problems to smaller chunks and getting a good understanding of how to approach problems. To do this you need to have a good understanding of the domain you are working in first. Then you need to know enough about the problem you are solving for this domain. Having a high-level overview of the domain always helps.

2. Communication

   Communication is also a crucial skill you need to develop to be able to work on solutions. Often, solutions one person comes up with isn't the best or the most efficient approach. As an example, I often tend to complicate things and my solutions are complex—not necessarily wrong but too much for the specific problem. Communication with others helps filter out the unnecessary parts. Communication and alignment overall is handy to collaborate, and the more and clearer communication you have throughout the development of a feature, the better it is.

3. Being Open to Learning

   You should know that learning is a very important part of the job. If you aren't open to learning new things and experimenting and doing things with different tools, then you are going to be left behind on the skills. This is so easy to see with the recent AI burst—if you fight learning AI and using AI, you will soon find yourself in the corner.

4. Collaboration

   Collaboration is also very important here. Finding optimal ways to solve a problem together and working with others—you need to be able to give feedback in a good way and receive feedback in a good way. Make sure you understand that different people prefer to work in different ways and be open to trying different ways of working. Remember, there isn't one perfect way to do things.

Final Thoughts

I'm sure there are things I've left out or haven't yet realized, but these 4 items are the most important ones I could think of. But there is something very important you need to always keep in mind: others are also experiencing this, so you need to be mindful of this and make sure you aren't making things difficult for them. Good communication and open collaboration. Keep your feedback constructive and be careful!

Remember: imposter syndrome isn’t a flaw. It’s a sign that you’re challenging yourself, and you can use it to your advantage.

When I joined a multidisciplinary startup team, one of the first questions we were asked was:
“How will you handle cross-team collaboration, especially with people from different backgrounds and competences?”

At the time, I didn’t have a good answer. But as I became more involved, I started to understand how crucial this question really is.

In the early stages of a startup, figuring out how teams are built and how people will work together is essential for creating a strong culture. It’s also important to get everyone involved in building the product — but that’s not always easy.

My First Encounter with Pair Programming

I first heard about pair programming when I was applying for jobs in Estonia. I didn’t get that job, but the idea stuck with me.
Later in my career, I found myself coding and explaining what I was doing to project managers who had no coding experience. They were curious and eager to learn, and I didn’t mind showing my work and talking through my process. This wasn't pair programming yet, I always had the control but I was getting the questions and practicing how to answer those questions.

It was later that I discovered the true power of this kind of collaboration — especially when working with people from different domains within the team trying to build the same product. We often covered each other’s gaps in competence and learned from one another in the process.

Not everyone is comfortable with pair programming. I’ve always been okay with someone watching me work, but I realized that’s not the case for everyone. Some people do their best work when they’re left alone, and sharing control of the keyboard can feel challenging.

Making Pair Programming Work

If you decide to try pair programming, a few things make a big difference:

1. Keep it truly collaborative.
   Don’t dominate the keyboard or make all the decisions. Both people should contribute equally — switch roles often between driver (who types) and navigator (who reviews and guides). It's easy to forget this and without a good balance it's going to be difficult.

2. Use the right tools.
   For remote work, tools like VS Code Live Share or Excalidraw for quick sketches are great. If you’re in person, a whiteboard or sticky notes work perfectly.

3. Be patient.
   It might feel slower at first, but that’s just how it works. I realized that if I had to understand and implement the other person’s part alone, it would have taken me even more time in the long run so giving it time pays off.

4. Accept what you don’t know and be humble
   You’ll get questions you can’t answer right away — and that’s okay. Stay humble, keep an open mind, and remember there are no dumb questions.

5. Stay available.
   Even when you’re working separately, make sure your partner can reach you. Sometimes, just staying in the same call (muted) helps keep momentum when quick questions come up.

The Benefits of Pair Programming

One of the biggest benefits is knowledge sharing — it happens naturally during sessions. You quickly align on technical decisions and gain a shared understanding of the system’s architecture and direction.

Pair programming also helps build empathy and teamwork. You learn how others think, how they solve problems, and how to communicate effectively under pressure. Over time, you start covering each other’s competences, and the sessions naturally become more balanced.

I’ve even tried sessions with three people, where each focused on one part of the problem. It was trickier to manage, but interesting — almost like a taste of mob programming. maybe.

Another important benefit is productivity, You get more done in the long run. Features are also built in a better way and you write better code. I don't know if it's just me, but I think I write more structured and cleaner code when I do it with other people.

Final Thoughts

Pair programming isn’t something you need to do all the time, but when it makes sense, it’s an incredibly powerful way to build both a product and a team, even if it feels slow at first.

One of the most difficult things I've had to figure out in my career has been understanding different ways of working across various environments and cultures.

Let me explain.

Cultural Differences in Management

In countries like Turkey and Iran, managing teams and companies is different compared to Norway. There you would have a more hierarchical way of managing.

You have the top-level managers who make the big decisions, then you have the mid-level managers who are making more granular decisions, and then you have the workers who don't need to make many decisions and focus more on execution.

This reminds me of a story from university.

A friend of mine was taking a soil mechanics exam. The professor asked, “How many holes do you need to dig?” My friend didn’t fully understand and asked for clarification. The professor said, “Imagine I’m the worker and you’re the engineer — how many holes should I dig?” My friend confidently answered, “Six.” “Why six?” the professor asked. “Because you’re the worker,” my friend replied. “Just dig. You don’t question my decisions.”

That conversation captures how work hierarchies often operate — clear authority, limited questioning, and fast decisions.

A more democratic approach

But in Norway I experienced something different. When working, there is more discussion around decisions and everyone gets to say what they are thinking.

I imagine it like this: you have a giant ship to build. You either give the workers each a small hammer and let them do their work, or you have a huge hammer and you all have to lift the hammer up and hit the nails together.

This is actually quite tricky to do because you need to be open to finding the solution together. You need to be able to know what you are deciding but be open to decide with others. Titles can sometimes make it harder to keep an open mind, but the right culture helps overcome that.

Size and Structure Matters Too

But cultural factors aren’t the only thing that shape management styles — company size and structure also play a big role. In large organizations, there are often more layers of management, established processes, and clearer roles — which can make decision-making slower but more predictable. In startups, however, things tend to be more fluid. There’s less structure, fewer defined roles, and decisions can happen quickly — sometimes too quickly and sometimes can take for ever to decide. That freedom can encourage creativity, but it can also lead to confusion or misalignment if communication isn’t clear.

Finding Balance

Which one is better? I think there are times you need to use either approach and you need to be smart about using them. But the challenge for me at first was that making some decisions felt unnatural and I even felt like I might be rude to the manager. But there is a thin line here. Without balance, teams waste time over-discussing decisions. As a manager, it is important to be able to distinguish when it is needed to make a decision and when to let people discuss. If you leave everyone too free, then it becomes chaos. If you decide everything for people, then it also becomes chaos.

Key Takeaway

Overall, having a balance between the two approaches is the key, and the difficult part is knowing when to use which one. A way to handle it is to timebox the decisions that need to be made and establish clear frameworks for when collaborative discussion is valuable versus when swift decision-making is required.

Understanding these cultural dynamics has helped me adapt faster and build trust across teams — something every global professional eventually should learn.

One of the most valuable lessons I've learned throughout my career is deceptively simple: communication is everything. More specifically, creating the right channels and fostering transparency is very crucial.

The Transparency Principle

I've learnt when you put information out there, something interesting happens. The right people respond to it—and even those who don't respond directly begin thinking about it. Their decision-making shifts. Their perspective broadens. This is the compound effect of transparent communication. You might not see the effect right from the start but after a while you will realize the difference.

The Introvert's Dilemma

As an introvert who has dealt with social anxiety at times, I've learned this lesson the hard way. I naturally prefer to speak less, and I've noticed many technical professionals share this tendency. We often assume that what seems obvious to us is obvious to everyone—so we stay quiet.

This assumption is almost always wrong.

In a healthy, active work environment, the goal should be to create the right channels, use the appropriate tools, and communicate as much as necessary to keep everyone aligned. This practice is easy to forget and difficult to master, but once you get use to it, the value becomes clear.

Choosing Your Channels

Different types of communication require different channels:

• Workshops for collaborative problem-solving and skill-building
• Team meetings for alignment and collective decision-making
• One-on-ones for personal feedback and career development
• Async tools (like Slack) for everyday communication where the others don't make sense
• Daily/Bi-Daily standups useful for aligning on progress

Startup Communication vs. Corporate Communication

In the traditional environments I've worked at, often operate on a "need-to-know" basis, where managers gate-keep information. This approach takes you up to some point but then it becomes impossible to handle for both parties, it is difficult for the manager and difficult for the employees.

In startups, you're working with a small team where everyone shares a similar energy level and excitement about succeeding together. Transparency isn't just nice to have-it's essential and helps keep that energy up. When founders and team members alike can see the direction clearly, everyone makes better decisions.

Both parties benefit from this open exchange of information.

Keep the Information Flowing

It's crucial to maintain open communication channels and keep everyone in the loop. This means giving everyone the space to speak and contribute, even if you're not obligated to act on every piece of feedback immediately.

The key insight here is that you don't necessarily need to do something about every comment or concern raised. Simply having the information out there is valuable. People will absorb it, process it at their own pace, and it will inform their thinking and actions over time. This passive osmosis of information is just as important as active discussion.

Conclusion

Communication isn't just about talking—it's about creating an environment where information flows freely, where introverts and extroverts alike feel empowered to share, and where transparency becomes the default rather than the exception.

The investment you make in building these communication practices will pay dividends in team alignment, better decision-making, and a culture where everyone feels informed and valued. Start small: pick one channel to improve, commit to more transparency in one area, or simply share that piece of information you've been holding back.

Remember, the goal isn't perfection—it's progress. Each conversation, each shared update, each open discussion builds a foundation for a stronger, more connected team.

A while ago at work I had to compare some JSON files to make sure the changes were what I expected—and I had to do this over and over.

Well, how do you do this as a developer? You use Git or a diff comparison tool in VS Code (if you’re used to using VS Code).
As you might know, JSON files aren’t ordered like lists. It’s easy to lose the order, and then when you look at the diff it’s basically impossible to tell what actually changed.

What if there was a small tool that could sort and compare JSON so I wouldn’t need to think about how to sort it or where to compare it?
That’s how, on a weekend, I decided to spend a couple of hours on this. Of course, with AI now you can achieve much more—and that’s how it helped me quickly create a sort and compare plugin for VS Code.

But the curiosity didn’t stop there. Now I had a plugin—how do I publish it on the VS Code Marketplace? Of course, AI will give you the steps, and on one of those steps you’re going to realize it’s easier to just follow the documentation. But come on, it’s Microsoft we’re talking about—so back to AI I went to try to make it work!

I eventually managed to publish it, and it felt good.
You can install it from here:
👉 VS Code Marketplace

After a couple of weeks I was surprised that the extension was being downloaded about 20 times every day. I still can’t figure out why, but interestingly it has now been downloaded 4K+ times since I created it in early 2024. That’s insane!

I have a hunch that it doesn’t matter how simple something is—if it solves a problem a lot of people have, it’s going to get attention. The hard part is finding that specific problem. I don’t think those people were even aware they were struggling with this. Maybe they knew but were too lazy to do something about it.

I can imagine that out of the 4.5 K people (and many more) who tried to find a JSON sort-and-compare extension, most gave up and did it manually when they didn’t find one. But if that happens enough times, you just get fed up and want to automate it.
The mindset is important here: an engineer might think, let’s just get it done, I can always build my own tools, while an entrepreneur would see the opportunity to build a tool for everyone.

Here’s the GitHub repo—feel free to give it a ⭐ or add features!
👉 GitHub

I decided to create a blog and the challenge is to create a minimal blog in less than 15 minutes.

I decided to go with something fast, with easy setup. Quick—think: what can be lightweight and get me what I want?

I’ve experimented with Deno before, and in my head Deno is the cooler, hip brother of Node. I wanted to use it, so Deno was chosen.

Created a new folder and searched for a static site generator for Deno. First result? https://lume.land/—so I chose that.

Now to figure out how to organize and configure the code.

Reproduce This Setup (DIY)

Make sure you have these installed:

• Deno
• Git (to push to GitHub)
• Firebase CLI

2) Scaffold the project

mkdir my-blog && cd my-blog
deno run -A https://lume.land/init.ts

This will create _cms.ts, _config.ts and deno.json and you can run the serve task to spin up the dev server.

deno task serve

3) Configure the pages

Add a new file named index.vto which will handle the posts. The posts will go unde the /posts folder and I want lume to fetch any .md file within that folder and show it to the user. Eventually I ended up with something like the below file for the contents of index.vto

<a href="/me"> About me</a>
<hr />

{{ for post of search.pages("url^=/posts/") }}
  <article class="post-summary">
    <h3><a href="{{ post.url }}">{{ post.title }}</a></h3>
    <div class="post-description">
    <p>{{ post.description }}</p>
    </div>
  </article>
  <hr />
{{ /for }}

4) Configure Lume

below adds the plugins to lume.

import lume from "lume/mod.ts";
import metas from "lume/plugins/metas.ts";
import sitemap from "lume/plugins/sitemap.ts";
import feed from "lume/plugins/feed.ts";
import search from "lume/plugins/search.ts";
import date from "lume/plugins/date.ts";

const site = lume({
  location: new URL("https://yourdomain.com"),
});

site.use(feed({ output: ["/feed.xml"] }));
site.copy("assets");
site.use(metas());
site.use(sitemap());
site.use(search());
site.use(date());

export default site;

Finally would be to add some styles and to deploy it. Quickest and one of the easiest ways to deploy is to use firebase. All you need to do is to make sure you have firebase installed. Login to firebase in your cli and initialize hosting.

Make sure you create the firebase project from the firebase console.

firebase login
firebase init hosting

Once you have done these steps you can deploy with

firebase deploy --only hosting

A last touch would be to configure github actions to auto deploy. Which means whenever we merge changes to git on main we get the latest deployed version.

To get the configuration for this you can run firebase initand select Hosting: Set up GitHub Action deploys. This will create two files under .github/workflows.

These files are for node and we need to make some changes for it to work with out Deno project. using the deno image we can run our deno task build command to build the project.

I am happy for now but will be improving it in the future.

The purpose of this blog is to share my thoughts, reflections, learnings and experiences. I’ve been wanting to start something like this for a while, and now feels like the right time.

Here, I plan to reflect on the past, document what I’ve learned—both technical and non-technical—and keep learning along the way. I also want this to be a space for experiments and ideas. I’m not entirely sure how I’ll organize those yet, but for now, simply starting the blog feels like the most important first step.

I decided to go with something fast, with easy setup. Quick—think: what can be lightweight and get me what I want?

Read more about it here