DEV Community: Sihan Tawsik

Junior Dev Mistakes: What I Wish I Knew Sooner

Sihan Tawsik — Sun, 30 Mar 2025 08:43:21 +0000

As they say, "The expert in anything was once a beginner." However, no one tells you how messy that beginning can be. You must experience it firsthand to grasp its depth.

When I started my career as a software engineer, I thought I had to prove myself by figuring everything out on my own. I spent hours debugging issues that turned out to be silly mistakes, nodded along in meetings while secretly Googling terms, and somehow managed to break things I didn't even touch. At one point, I seriously considered adding 'professional Stack Overflow user' to my résumé.

If you're feeling overwhelmed, second-guessing yourself, or wondering if you even belong, buckle up and hop on the bandwagon. We've all been there, and trust me, the ride gets easier. Here’s what I wish I had known sooner!

1. Code for humans, not just machines

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” - Martin Fowler

As developers, it's tempting to flex—writing clever one-liners, cramming logic into fewer characters, or over-engineering for the sake of it. But code isn’t just for machines—it’s for future you, your teammates, and anyone stuck maintaining it. Trust me, it’s not worth it in the long run.
If your code looks like an ancient spellbook, you’re doing it wrong. No one should need a decoder ring or a PhD in hieroglyphics just to figure out what you wrote.
Instead of writing code that’s impressive, write code that’s clear.
You should always:

Keep it simple – Clear names and straightforward logic > clever hacks.
Break it down – Small functions, modular code, readable flow.
Avoid over-engineering – If it needs a diagram to understand, you might want to rethink it.

Good code isn’t just about making computers understand—it’s about making life easier for the next person who reads it (which is probably you).

Write less spaghetti, embrace readability, and return to monke.

2. RTFM: Read the Docs or Debug Forever

I’ve been there, staring at my screen, convinced my code is flawless, yet somehow it refuses to work. Hours pass, Stack Overflow tabs multiply, frustration builds—only to realize the answer was sitting in the documentation all along.

Skipping the docs feels faster at first. Who needs official guides when you can just “figure it out”? But then, three hours later, you’re questioning your career choices, rewriting half your codebase, and preparing to submit yourself to the dark art of print debugging.

Before engaging in some hacky, overcomplicated solution, pause and read the docs. Chances are, someone has already solved your problem—and documented it. Reading first saves time, pain, and your last shred of sanity.
The reality? Reading the docs first saves time, pain, and your last shred of sanity. The moment you finally open the documentation and everything just works—it’s like finding the cheat code to development. A true ‘Why didn’t I do this sooner?’ moment.

3. Future-Proof Mode: Code That Adapts

"The right man in the wrong place can make all the difference in the world." – G-Man, Half-Life

You might think your code works perfectly today, but what happens when requirements change? Hardcoded values, rigid logic, and inflexible structures will turn even the smallest update into a nightmare-level boss fight.

Instead of writing code that barely survives the current sprint, build with Future-Proof Mode enabled. I always remember the three golden rules of futureproofing:

Use Configurations Over Hardcoding – Instead of burying values deep in your code, make them easily adjustable through env variables, config files, or database settings. One small change shouldn't require a full-scale refactor.
Embrace Modularity – Write self-contained functions and reusable components. Future-you (or your teammates) will thank you when features need updating without breaking everything else.
Plan for Change – Assume things will change—because they always do. Write flexible logic that can adapt without rewriting half the codebase.

Good devs solve problems. Great devs make future problems easy to fix.. Keep your code adaptable, and you won’t have to grind through endless bug-fixing quests.

4. The Art of Debugging: Think Before You Do

"Speed is good. Precision is better. Panic is death." – Some wise dev, probably

The room is quiet. Keys clack rhythmically. All is well. Then—bam. The bug appears. Chaos unfolds. The Slack notifications pile up. Your PM is breathing down your neck. The instinct? Type fast. Push something. Hope for the best.

But a true dev does not panic. A true dev transcends the console, merges with the stack trace, and debugs in the astral plane.

When crisis strikes, activate Zen Debugging Mode™. Calm your mind—the code is broken, but you are not. Breathe. Raging at your keyboard will not summon a solution. Observe the chaos—read the error message, follow the logs, and ask yourself: What would Stack Overflow do? See beyond the bug. Adapt, don’t react—a quick hack today is a production outage tomorrow.
Fix the problem, not just the symptom. Master the art of debugging—the impatient dev fights the bug, the wise dev understands the bug, but the true dev? The true dev makes the bug fix itself.

Stay calm, analyze, and execute with precision. A wise dev doesn’t just code. A wise dev waits, thinks… and then wins.

Conclusion

At its core, great development isn’t about writing code that just works—it’s about writing code that lasts. Keep it simple so others (and future you) can understand it. Read the docs before reinventing the wheel. Design for the future, because change is inevitable. And when chaos strikes, don’t react—analyze, adapt, and debug with wisdom.

Because beyond every clean commit, every well-placed log, and every thoughtful refactor lies something greater—the undiscovered possibility of what you’ll build next.

Working with sigmoid in Solidity

Sihan Tawsik — Sun, 18 Sep 2022 07:05:38 +0000

Introduction

While working on a project in solidity, I needed to make a calculation with sigmoid. Now, anyone who has already worked with sigmoid will know that it involves the irrational number e. In this article, I will describe what problems I faced and how I tried to approach the problem from a mathematical and programming concept.

The problem

Solidity does not have native support for fractional operations, rather it uses scaled version of numbers (i.e: uint256 and int256) to make operations for fractional calculation. for example, if you are to do an operation like this:

let x = 1/3;

In pure solidity the result needs to be scaled to adjust precision similar to this:

uint256 x = (10**18)/3;

On top of that the natural exponential function makes it harder to calculate in pure solidity.

\frac{1}{1+e^{-x}}

Solution Approach

I tried to make the solution for this problem using observation and estimations using the graph.
Let's look at the graph for sigmoid function:

As x approaches 5 and goes to infinity, the function result tends to reach 1.
And as x approaches -5 and goes to -infinity, the function results in 0.

The first observation that I got from this is that the graph is symmetric for positive and negative x.
If we shift the graph by 0.5 units below the y-axis, we will see that x and -x yield the same result but in opposite directions on the y-axis.

So, we can calculate the values for negative x by adding/subtracting some offset value with the positive x value. From the shifted graph, we can calculate the value for this offset.
We shifted the y values by 0.5, and we got relation for positive and negative x like this:

f (- x) - 0.5 = - (f (x) - 0.5)

From this equation we get:

f (- x) = 1 - f (x)

We can now use the positive x to calculate the values for negative x.

Polynomial estimations

We have reduced the problem domain in half, but the irrational number and the fractional calculations are still not solved.
What if we could express the function in some simpler polynomial function? We could use the Maclaurin series to achieve this.
Taking the first 6 terms for the Maclaurin expansion for sigmoid function, we get:

\frac{1}{2} + \frac{x}{4} - \frac{x^3}{48} + \frac{x^5}{480} - \frac{17x^7}{80640} + \frac{31x^9}{1451520}

If we plot g(x) and f(x) in the graph, we will see something like this:

The green curve is g(x) and the blue curve is f(x). We can see that the estimation does very well from 0 to 2 but diverges from the original curve after that. So, we can use this for values from -2 to 2 in our code.

Linear estimations

After that, I used linear estimations for the rest of the values. I found that from 2 to 5 i needed a linear estimation and from 5 to 9 to smooth out the results. Anything greater than 9 or less than -9, I assumed to be 1 and 0 respectively.

Polinomial estimation code

To implement the curve in solidity in simple terms, I processed the mathematical term a bit. It made it easier to write the solidity code.
The denominator of the term was 1451520. I also calculated the modifiers for the x nominators.

function buildModifiers() internal pure returns (uint256[] memory) {
        uint256[] memory modifiers = new uint256[](5);
        modifiers[0] = uint256(362880);
        modifiers[1] = uint256(30240);
        modifiers[2] = uint256(3024);
        modifiers[3] = uint256(306);
        modifiers[4] = uint256(31);
        return modifiers;
    }

As I have scaled the numbers by 10^18 I used a power function to scale down. One observation from the polynomial term is that all the power of x is odd, and thus the next x term can be obtained by multiplying the previous x term with x^2. I incorporated that into my code as well.

function power(uint256 base, uint256 scale)
        internal
        pure
        returns (uint256[] memory)
    {
        uint256 square = (base * base) / scale;
        uint256[] memory result = new uint256[](5);
        result[0] = base;
        for (uint i = 1; i < 5; i++) {
            result[i] = (result[i - 1] * square) / scale;
        }
        return result;
    }

Lastly, I multiplied the result with the modifiers and add/subtract the terms to get the answer.

function polynomial(
        uint256 base,
        uint256 scale,
        uint256[] memory modifiers,
        uint256 addition
    ) internal pure returns (uint256) {
        uint256 result = 0;
        uint256[] memory powers = power(base, scale);
        for (uint i = 0; i < 5; i += 2) {
            result += modifiers[i] * powers[i];
        }
        for (uint i = 1; i < 5; i += 2) {
            result -= modifiers[i] * powers[i];
        }
        return result / denominator + addition;
    }

The addition variable is the value for f(0) which is 0.5 scaled by 10^18.

The result

As I used fixed polynomials and linear approximations to calculate the sigmoid, I was able to calculate the result in constant time. So, the time complexity for this function was O(k) or O(1). And with 10000 different inputs for sigmoid, the final result had s mean absolue error of 0.00013193236860416846 or 0.013193236860416846%

Conclusion

I had a lot of fun working on this particular problem. It was exciting to use high school math along with observations to implement something that is natively not available in solidity. I wish to do more exciting stuff like this in the future as well. Happy coding!