DEV Community: Branko Stancevic

Mindset of a Senior Engineer

Branko Stancevic — Mon, 20 Jan 2025 21:43:06 +0000

3 words mentioned in the title of this post are needed to be exactly that – senior engineer. Let’s break it down.

Mindset

Mindset is difficult to explain, and not because of its technical side. In fact, it’s the non-technical qualities that make it tricky yet essential to master. A senior engineer's mindset encompasses traits that go beyond coding skills and technical knowledge. Here are some key non-tech qualities every engineer should cultivate:

Decision-Making Based on Project Context: A senior engineer must evaluate project complexity, timelines, and client needs to make informed decisions. Balancing these factors ensures solutions are both practical and aligned with the bigger picture.
Clear Communication: The ability to rephrase and clarify concepts so everyone, regardless of their technical expertise, can understand is a hallmark of effective engineering. This includes bridging gaps between technical and non-technical teams.
Proactivity: Instead of waiting for instructions, a senior engineer anticipates challenges, identifies opportunities for improvement, and takes initiative to drive better outcomes.
Empathy and Collaboration: Understanding team dynamics, empathizing with colleagues, and fostering a collaborative environment are essential for creating effective solutions and achieving shared goals.
Adaptability: Projects evolve, requirements change, and technologies advance. A senior engineer’s mindset embraces flexibility and sees change as an opportunity rather than a setback.

Senior

Seniority isn’t just about years of experience. It can be summarized by this equation:

seniority = years of experience * (knowledge + mindset)

Knowledge is built over time through hands-on experience, learning from failures, and staying updated with the latest industry trends. But mindset—as described above—is the multiplier that transforms experience into seniority. Without the right mindset, even extensive experience may fail to lead to impactful contributions.

Engineer

It’s important to distinguish between an engineer and a developer. Both roles are valuable, but their approaches and perspectives differ.

A developer is often task-oriented, focused on completing assigned tickets without necessarily considering the broader context. They’re like ants working diligently on individual pieces of the puzzle.

An engineer, on the other hand, takes a holistic view. They consider multiple solutions, analyze trade-offs, and select the one that best meets the project’s needs. Engineers think about scalability, maintainability, and the overall architecture, ensuring their work contributes to the long-term success of the project.

An engineer’s mindset elevates their role from execution to innovation, making them indispensable in driving meaningful progress.

In conclusion, becoming a senior engineer requires a blend of technical expertise and a refined mindset. It’s about making thoughtful decisions, embracing responsibility, and consistently striving for excellence.

Function boobs or how people love to call them: Higher Order Functions

Branko Stancevic — Sun, 11 Jul 2021 07:20:31 +0000

- Branko are you crazy?
No I’m certainly not!

I just love crazy stuff in JavaScript. One of those things are definitely function boobs. I’m sorry, but I couldn’t find more describable and funnier name for this phenomenon so I’m gonna call it like that.

Foo()(), am I right? Hihi.

Let's dive in!

In your, so far, developer life, you must have seen something like this:

connect(mapStateToProps, mapDispatchToProps)(App);

Did you try to understand what this is and how the hell is it working?

This connect function is called Higher Order Function (HOF).

By definition HOF is a function that accepts and / or returns a function as parameter.

How it works you might ask?

First boob in connect accepts several things. Couple of functions for redux state and actions and some other options which are not the topic here so I’m not gonna cover it.

Second boob is basically return function from connect that accepts react component.

So, main purpose of the connect function is to prepare testament for its child (child that comes from the second boob).

All the information from testament (redux state and actions) is bound to the child’s props when connect is about to die. That’s why we access redux state via props.

Keep in mind that this is not the definition of connect function. This is just an brief explanation how things are working by my understanding.

function connect(state, actions) {
    /* testament preparation */
    const preparedTestament = {...};
    return (component) => {
        return <component props={props, …preparedTestament}
    }
};

So, at the end, connect returns anonymous function that returns react component but with appended props as I described earlier, hence we call it with 2 pars of brackets like this: connect()().

Why it is useful?

While this technique is used widely with connect, withRouter, etc. HOF can be used for custom stuff as well. For e.g. When you want to attach some component (notification sidebar or something like that) to 3 pages in your react app but omit on 4th and 5th.

Yes! Of course that you can use HOF outside of the react! And that’s the point where the real fun begins!

Or, or, you have already used it and you don't know it! Does map, filter, sort, reduce sounds familiar? :)

Conclusion

HOF as concept is definitely something worth exploring on the deeper level so don’t be afraid to use it, don’t be afraid to understand it. It will be easier with time passed by, and with that, a new horizons will open up for you. :)

Thank you for reading good people. 'til next time!

Lower CSS specificity as much as possible with Bem and Inuitcss

Branko Stancevic — Sat, 12 Jun 2021 10:01:29 +0000

I have to open this post with this disclaimer; in order to fully understand what's going on, you'll need couple of things sorted out.

Work with some CSS pre-processor (SCSS, LESS)
Familiarity with Bem Methodology
Familiarity with Inuitcss

Now, considering that we have established ground rules, let's begin.

Introduction

I have worked on several big projects in the past. By big I mean projects that ware in active development 6 months and more. My first part of engagement was organization of CSS. Second part was building JS (ReactJS and Angular 2) components and RestAPI integration, but that's not important so let's focus purely on CSS.

Property overrides

Every CSS tutorial I watched in the past, didn't cover very !important thing in the CSS world. Property overriding.

Why we try to avoid that, you might ask? Because my friend, what callback hell represents in JS, property overriding is just equally bad in CSS. Don't get me wrong, we still need to override something sometimes, but I believe there's a better and cleaner way to do so.

Epic dark story

So many unused properties lying somewhere deep inside your compiled CSS file. When project grows, you add more variants and more overrides and eventually because of CSS specificity you start using !important. Then you realize that you have overrode something that was not supposed to be overridden. Now you feel helpless and you are a one line of code from quitting but not the project. The job. Oh, and I won't even start talking about performance issues. :)

Show me the way!

So, first of all let's see how specificity work.

<p class="paragraph">
    <span class="red">Lorem ipsum</span> 
</p>

Let's say we have this html above on our page. Now, let your inner child play with the colors for a little bit. :)

.paragraph .red {
    color: maroon;
}

.red {
   color: red;
}

We already know that CSS is executing line by line from top to the bottom. Can you guess what color will be the element with class red? Of course not! Will be maroon. I'm sorry if I assumed you said red, it's fun for me to try to predict how your mind works.

Specificity took over and overrode red color. Can we somehow organize this differently so there is no overrides with no increased specificity? Of course!

I present to you my ultimate combo!

Bem Methodology

Actually current example is just about Bem Methodology but combo will make more sense later when we will be covering the big boys (projects).

Let's rewrite example above with Bem.

<p class="paragraph">
    <span class="paragraph__item paragraph__item—red"></span>
</p>

How can we color it?

.paragraph {
    &__item {
        &—red {
             color: red;
        }
    }
}

Keep in mind that this example only works with some CSS pre-processor like SCSS or LESS.

Watch closely how this example above will be compiled.

.paragraph__item—red {
    color: red;
}

What? :O Just one line and no stacking elements? No way.

& sign represents concatenation of strings, exactly like in JS where "2" + "2" equals "22". We exactly wanted that. Our first refactor done with lowest possible specificity.

Inuitcss

Now comes into the play second part of the ultimate combo and it is Inuitcss!

While Bem covers organization of html tags and their names (classes), Inuitcss gives you nicely organized, maintainable and scalable structure of CSS files.

I love Inuitcss because it covers everything from pages, layout, variables and some global settings to specific elements, mixins, helpers, components. Maybe I forgot something but you got the point.

Conclusion

With combination of those two paradigms and detailed planning of the project, specificity can be contained up to 2 or 3 levels maximum, while property overriding should be minimal and nicely executed. Project becomes maintainable and scalable, you don't want to kill yourself, your appetite comes back, and finally you are hungry for more.

Take care good people, and thank you for reading!

Why deep clone when we have stringify.

Branko Stancevic — Sun, 06 Jun 2021 15:34:00 +0000

Since this is my first post I just have to open it with “Don’t judge book by it’s cover”, just hear me out.

Problem

I have to be honest, deepcloning objects can be really messy. Sure, it is easier with some packages like loadesh, but when you do that “by the hand”, it’s hard to track what you did or didn’t copy, especially when big complex objects are in play.

Oh sorry, I forgot to explain why we have to clone objects in order to update them, and I can do that in just one word: immutability. Huh, okey, that was easy :) I’m kidding. Since I don’t know my audience yet, I will try to be as clear as blue sky, so let’s get more technical.

Immutability

Immutability is very important part of every react application. Component in react app is rendered based on props and state. When props or state changes (by this I mean when reference to the object is changed), components rerenders. It’s that simple.

When working with complex object which contain 3 or more levels of objects for e.g, and you want to change some property on third level, you need to copy that object where property lives, it’s parent, then parent’s parent. And that’s it, I think…? You see my point. Let’s say we have done that right, now we have an old unchanged object and a new copied object with just one property changed. Now, state can be updated and component rerenders! Hooray!

All that insecurity and potential bugs where your component didn’t update can be a result of badly managed immutability.

I hope I didn’t make you angry by this time but let’s get to the point.

Solution for all your problems

const user = {
    firstName: “Branko”,
    lastName: “Stančević”,
    location: {
        city: “Novi Sad”,
        country: “Serbia”
    }
}

const newUser = user;

Okay, now user and newUser have reference to the same object. If you try to do something like: user === newUser you will get true, as expected.

To avoid all spreading and loadash deepcloning functionalities to make new copy of the object, we can simply do this:

const newUser = JSON.parse(JSON.stringify(user));

user === newUser is no longer true, both of the constants have their own reference to the completly same data but different object. Even children objects don’t have same reference, hence you may do with that object whatever you want without worrying about immutability.

Simply pinpoint property in child object, change it and your job is done.

newUser.location.city = “Belgrade”;

Then with that updated object update your state or do whatever you want. :)

Conclusion

This idea can be explored furthermore, test performance against familiar processes of deepcloning is just one of the many roads that we can take together.

I’m frankly happy to hear out your thoughts on this topic good people.

Thank you for your time. I hope you have enjoyed reading this post :)