DEV Community: Jurica Kenda

How I hit 6 figures with 6 years of experience

Jurica Kenda — Fri, 04 Jul 2025 12:58:08 +0000

Something happened at year three of my career. I’ve dropped my ego and unlocked potential. Haven’t stopped since.

I’m having fun and it’s paying off rapidly.

During that time, something clicked. I’ve realized that the 80% in the 80/20 of software engineering isn’t tech. It’s the 20%.

Let’s break down the other 80% by splitting it into four categories. They’re unordered and you need all of them simultaneously. They’re levers you can pull to increase your value.

Lever one: communication
Just because you know how to talk doesn’t mean you know how to communicate. But you need to drop your ego in order to realize it.

I used to get frustrated when someone misunderstood the message I was trying to communicate. I used to believe they were either too lazy to think it through or too incompetent to understand me. But the reality was, I was incompetent in communicating.

The burden of communicating well lands on the speaker, not the listener.

It took me a while to accept this, but once I did, everything started moving smoother. I could immediately improve my communication because I took ownership of it. I took responsibility for the quality of my message and made sure I was understood by catering my tone, message, word choice, format, and many other things towards the listener.

The sole reason for communicating something to someone is to make sure they understand it. We already understand it, so why are we catering the message towards ourselves?

Lever two: leadership
If you’re not leading, you’re following. And that’s completely fine. I’m happy for you if that’s your thing.

But I want the leadership-level money. I’m not ashamed of that. I own it and I’m ready to work hard for it. Leadership also makes work a lot more exciting for me, which doesn’t hurt.

Around year three, I realized there was a whole suite of problems leadership positions provide you with. You get to be a part of really important business decisions, improve the efficiency of your team and the company, and lead projects that move the bottom line.

I’ve started bringing in more money, so they’ve started paying me more. This rationale makes so much sense. I’m baffled by the number of engineers who miss this point.

What are the behaviors I need to learn to be able to replace my tech lead? This became my mindset. I was trying to extract as much as I can from people who already were in leadership positions. I was learning from their successes and failures.

I was also stepping up. It felt uncomfortable at first. I was getting weird looks from my colleagues almost every time I would step outside of my role. Who does this kid think he is?

I’m a kid who values growth over comfort.

Lever three: business-first mindset
In all businesses, money is the name of the game. Through one mechanism or another, we’re aiming to earn more money. Like it or not, accept it and align with it.

Every feature, project, or meeting is an investment. We make money only when the returns outweigh the investment. There’s no going around this.

The more value you generate for the business, the more they will pay you. Therefore, you need to make decisions that are profitable for the business. Decisions that make sense for the business. And this requires novel thinking you’re probably not used to.

This one was tough to grasp. I needed to learn how to quantify the value of each effort, weigh them against each other, and select the most profitable one. Both in the long term and the short term.

I also needed to deeply understand the business of the company I was working for. Where do we earn money and where do we lose it? Understand the product, the company, the business, the market and the industry you’re in.

Lever four: perseverance
I’ve always had this trait. Not entirely sure how or why, it’s just part of who I am.

Even though it’s always been part of me, I assumed there’d come a time I wouldn’t need it. I used to believe there’s a point where things start going smoothly. I no longer believe in either of these things. I had to get rid of these limiting beliefs.

The more you’re leveling up, the more you start encountering increasingly difficult challenges. If anything, you now need more perseverance than ever.

I can’t tell you much about how to grow your perseverance because I never had to do it. My challenge was in learning to recognize when not to persevere. There is no cute and memorable quote for evaluating this.

Unfortunately, you’ll have to stop and think every situation through. But as a rule of thumb: give it some more effort. And then some more.

Lever five: tech
We’ve made a full circle. And now we understand that a strong technical foundation is one of the building blocks, not the entire house.

Three years ago, I made a decision to invest my time and energy into the other four, non-technical aspects of my career. I’ve doubled my gross salary twice during that period.

I wasn’t lazy or unmotivated prior to this. I was simply pulling one lever when I could have pulled four more.

Honestly, it’s an amazing feeling when you realize you have a say in your own career.

I’m excited to see what the next three years will look like. I’ll keep documenting my learnings, so if you’ve found value in this, make sure you stick around.

If you've enjoyed this content, consider reading more here.

5 Tips to Advance Your CS Career

Jurica Kenda — Thu, 09 Dec 2021 14:00:27 +0000

1. The price of context switching

Context switching is a process that requires the switching of the CPU from one process/task to another. In computers, it is one of the essential features that enable pseudo-multiprocessing since it happens blazingly fast. There is, however, a slight time overhead.

For humans, this overhead is amplified a lot. Our mental models are often vague and abstract, especially when we are involved in the activity of solving a difficult challenge. We don’t simply store stacks and the state that can be easily retrieved once discarded. Some of the stuff truly gets lost, and we lose a lot of time picking the pieces back up.

Some of the context switching responsibility belongs to ourselves, as we allow our smartphones and instant messaging applications to get the best of us. Some of it, on the other hand, belongs to our colleagues, as they interrupt us when we are diving deep into a certain problem.

It is your personal responsibility to create an environment that will endorse focus, deep work, and attention retention. Learn to combat your phone addiction and focus on the thing that matters the most when you are working - your work. Set hard rules among your teammates to prevent unnecessary interruptions.

2. Communicating with the management

Very early in your career will you learn the different levels of communication. Technology-oriented companies have an interestingly structured layout of people. Your management is a part of this layout.

Conveying information to the management is vastly different than conveying it to some of your peers or staff with the same job title, but a different level of seniority. Managers simply need the different, interfaced information from you.

Your manager does not need to know about every little bump on the road, yet he/she needs to know if the project will be delayed. He/she does not need to know the small technical trade-offs you make on a daily basis, yet he/she needs to know the ones that will affect the project, the performance of the system, etc.

There is an art to communicating with the managers in an efficient manner. You need to be able to present reports of how the project is coming along and where things are moving. Concise, concrete, and accurate data answering the questions: what, when, and why. Sometimes, an answer to how is provided, but this information is usually abstracted and presented minimally.

3. Staying relevant

The tech industry is one of the fastest-moving industries in the world at the moment. Certain technologies can become increasingly important in a matter of months, just to die out within a year or two.

It is implied that if you want to be a top performer, you have to keep building your skills and expanding your knowledge. Instead of perpetually chasing the rabbit and burning out, focus your time and energy on deeply grasping the fundamentals and underlying principles of the technologies you are trying to master.

With this approach, you will be able to merely update your knowledge by understanding the syntax and the slight nuances of the newly arrived technology. Even though things are moving fast, the new technologies are rarely very revolutionary. They are usually just clever implementations of very well-known principles.

Essentially, use the 80/20 principle to utilize your resources. The former chunk of your resources should go towards grasping the principles, while the latter should be steered towards learning the nuances.

4. Stagnation

As you progress through your career, you will climb different ladders and take on various roles. Each time you step up the ladder, the role inevitably gets tougher to fulfill.

This is bound to create an uncomfortable feeling. The trick is to get used to not knowing everything. It is a sign of growth and progress. Being comfortable with everything you do is a sign of stagnation in engineering.

One of the symptoms of this is imposter syndrome. Doubting your own abilities, feeling like a fraud, feeling like you do not belong and should not be here, feeling like everyone else is so much more qualified than yourself, refusing to accept and recognize your accomplishments…

This stems from the fact that the industry is constantly progressing and moving forward. You must not let it get to you. Keep reminding yourself it is okay to be uncomfortable for a while.

It is all about the seasons. It is a bit of a rough patch and a bit of smooth sailing. And the two alternate continuously. This pattern will emerge throughout your entire career. Get used to it.

5.Initiative

People consume your energy. An unbelievable amount of change can be achieved through your energy. You are constantly making an impact on people, leaving your footprint. Make sure it is a positive one.

Showing initiative is (should be) always welcomed and encouraged. Doing things you were not assigned to do, but are capable of doing well, is a good start. Volunteering, engaging in the company’s indirect but meaningful activities, actively proposing improvements and optimizations of the processes, workflows, and habits… The list is endless.

Of course, this does not imply you should stray away from your primary goal and get pulled into any little opportunity along the way. Do it after the primary target has been taken care of. Know how to prioritize. But also know how and when to go the extra mile and do more than requested and expected.

All of it should come from a genuine place. The “Fake it ‘till you make it” approach will not cut it here. People are extremely aware of your subtle intentions and will feel something is off about you if you try to apply this approach. You are either all in, or you are not. If you are not, you are in the wrong place.

If you made it this far, you might want to check out a book with related topics:
The Missing Semester: 100 things you were supposed to be told about software engineering.

5 Code Smells Everyone Should Know About

Jurica Kenda — Thu, 09 Dec 2021 13:55:02 +0000

1. Commented code

Commented code has no place in your codebase. Version control systems exist for a reason, among other methods of avoiding this.

If you are testing out a piece of new, replacement code in your system, find an alternative way to do it. For example, represent the service with an interface and swap them, while deprecating the former implementation. An alternative is to make some sort of configuration to switch strategies of execution. The point is: there are better ways to remedy this.

If you do not need the code anymore, just remove it completely. The fear of throwing away a piece of dead code just because you are sentimentally bound to it does not quite scream “professional”. Once again, version control systems.

If you are for some reason using this snippet to occasionally display/print/generate some report, commenting the code still does not qualify as a valid solution. If it truly is used that often, make it a service.

These snippets in your codebase are confusing to the reader and will only cause unease and latency when reading. Having commented code in your system shows a lack of care for the codebase.

2. DRYing based on coincidence

WET (we enjoy typing) code is terrible. Unnecessary duplication and redundancy breed a lot of issues. Anything you write is prone to errors, but duplicated code especially so. You now have more work to do: remember to keep all of the “replicas” in sync.

We found a remedy for the WET code. DRY (don’t repeat yourself) the code. Extracting the constants, methods, even services can be a very useful and powerful refactoring tool. But also a very dangerous one. With great power comes great responsibility.

Use it with deliberation. Two or more functions can be syntactically nearly identical but semantically worlds apart from each other. Let alone the constants you have in your code.

If it looks like a duck… it might not be one. Only a duck is a duck, not everything that looks like one. Actively think about the consequences of your actions when refactoring (and when not refactoring).

Extraction rooted in syntax is a form of very bad coupling. In your attempts to improve the code quality, you, unfortunately, made it worse. And the bugs are now even harder to trace.

3. Boolean parameters

A boolean parameter in a function is a code smell. A pretty severe one as well. It often displays one of the following: the laziness of the author engineer, rush to meet the deadline, insufficient understanding of the function in question.

The function clearly performs a certain action if the boolean evaluates to true, and a different one if it evaluates to false. Now, unless the function is named ifParamTrueThanSomethingOr... the name is hiding the logic and it is misleading the reader. If it actually is named this way, run!

Jokes aside, there are no benefits to this approach, only harm. The code is harder to read and refactor if needed. Because you are coupling things together. In most cases where we have additional snippets of logic dependent on the boolean parameter, we have multiple “clients” of the method. These clients obviously have different requirements. Imagine if your system logic changed, you would now need to locate all usages and reassign the appropriate boolean input.

Named parameters remedy these issues, but not sufficiently. They only make it easier to read code, all of the other issues remain. If you are still not convinced, decide for yourself where you will draw the line. How many things will your functions do? Remember each boolean adds a power of two to the possible usages of your function.

4. The one-liner

For some odd reason, young software engineers think writing condensed code is a virtue. Somehow, there is a notion that it makes you look smart and that this type of code is impressive.

Favor clarity over cleverness. Inlining is a great feature, and it has many applications where the code becomes simplified and easier to read and comprehend. But inlining up to a point where a single line of code performs 10 things in an obscure and seemingly magical manner is a school example of a code smell.

No one thinks you are impressive because you can write this type of code. It is not worth it. The code is now so condensed, that if you even have to make the slightest change to it, you are unable to. Just because it makes nearly everyone who reads it feel stupid, it does not imply that the code itself is smart.

The same applies to using odd features of the language you are working with. If it is not a well-known and widely used feature of the language, deeply evaluate it before using it. Your code should make your teammates feel comfortable and confident in what the code is doing, not make them afraid and leave them questioning the validity of it.

5. The three-times rule

If you find yourself writing the same piece of code three or more times, you should consider extracting it to a separate method, and perhaps even make it generic.

Not all duplication is evil, but some truly is and it may cost you. You will have to remember to synchronize all methods if a change is introduced, sometimes even update the corresponding documentation as well.

In all likelihood, you will forget some of these and create an issue incredibly hard to trace. Anyone who has encountered this type of bug knows exactly how difficult it is to find it.

Three times is just an arbitrary measure. The point being made is you should be extremely aware of duplication and what it means for your system. Does it scale well? What is the impact of having duplicated logic in your system? What is the breaking point where you finally decide to refactor this code?

Of course, as always, do not just mindlessly perform this. Evaluate the syntactic and semantic similarity of the usages and extract if the cohesion is strong enough. Do it carefully because you are essentially trading off duplication for binding and coupling. A risky move, sometimes worth playing.

If you made it this far, you might want to check out a book with related topics:
The Missing Semester: 100 things you were supposed to be told about software engineering.

The Missing Semester

Jurica Kenda — Sun, 14 Nov 2021 10:20:08 +0000

I'm happy to announce I had published my first (only?) book!

Software Development Engineering is a fast-paced industry. While the university curriculum tends to teach its attendants a vast number of concepts, ideas, and technologies, there still exists a gap to be bridged.

The Missing Semester aims to conquer this gap by providing insight into what it takes to be a #softwaredevelopment #engineer in the current #work marketplace. The book presents topics like teamwork, advice for technical growth, better #coding skills, system architecture, design principles, #career growth, #mentalhealth, and many more.

The topics discussed in this book are very prone to debate, so the book itself should be read with this in mind. The opinions presented are just that - opinions.

It's written in a concise, easy-to-read format and is a great starting point for anyone embarking on this industry. It's available on Amazon for anyone who finds this interesting and/or useful.

Godfatherr

Jurica Kenda — Sun, 19 Jul 2020 13:34:47 +0000

Join me in the making of a fluent and elegant error handling library in Go.
Let's have some fun!

Link: https://github.com/juricaKenda/godfatherr

Why Does Dark Mode Always Look 10x Better?

Jurica Kenda — Tue, 08 Oct 2019 15:47:16 +0000

Just implemented the 'dark mode' in my latest personal project!
How do you like it?
Test it out: https://github.com/juricaKenda/bashboard

Git Branch + Commit Templates

Jurica Kenda — Tue, 08 Oct 2019 12:04:17 +0000

Interested in free branch and commit templates?
Check them out and use them!
Link : https://github.com/juricaKenda/git-templates

Leave your two cents on the topic down below!

Progressive Web Apps vs. Desktop Apps?

Jurica Kenda — Mon, 23 Sep 2019 16:53:44 +0000

What do you prefer and why?

A couple of months ago, I created a desktop application for merging multiple .pdf files into one file. The application can also be used for extraction of certain pages from one file.
The initial project was supposed to be for personal use only, but I had decided to make it more user friendly and put it out for everyone interested to use. The user interface is very intuitive and easy to use.

Now I am a bit stuck on the distribution end.. I would like to reach as much people I can, so they can use my application. Is creating a web application out of it a better apprach?

Here is a download link to the desktop version: https://lnkd.in/dwjc-XC

Let's connect on Github!

Jurica Kenda — Mon, 23 Sep 2019 16:12:52 +0000

Let's connect!
Link your profiles down below. I am interested in checking out your projects and getting feedback on my own.
Here is my link: https://github.com/juricaKenda

Annoyed by Chrome Bookmark Manager I Created My Own. Should I release it?

Jurica Kenda — Mon, 16 Sep 2019 16:51:21 +0000

I was annoyed by my overcrowded bookmarks bar on Chrome, so I decided to create my own bookmark manager.
After creating the initial version, I thought it would be fun to make it accept CLI-like commands to filter out and open certain bookmarks.

For that, I created my own command form and its parser.

Commands implemented so far are :
ls - display all command
opn - open command

You can modify these commands with modificators:
rgx - looks for regular expression (works on both ls and opn)
tag - looks for a particular tag in page sentiment (works on display)

Modificators accept String arguments and based on them create predicates that will modify command execution.

This is what a parsable comman looks like:

Should I release this for public use? What features or commands would be fun to have?

10 Reasons Why You Should Always Overdeliver

Jurica Kenda — Thu, 05 Sep 2019 16:09:58 +0000

Customers, customers, customers...

Overdelivering on a project is the best thing you can do for your customer - and therefore for yourself! An astounded customer is an unbeatable advertisement for your business.
Not only that your customers feel that they got the service as it was described, they feel as if they got more! Perhaps if you look at the monetary value, they did indeed get more.. But they will certainly pay your business each and every cent of that difference.

Customer that is blown away by your delivery will instantly become a returning buyer and a personal affiliate partner. He will recommend your service to anyone he knows, and the best fact about it is - he will speak with pure enthusiasm and joy.
This is a lesson I quickly realized while working as a freelancer on Fiverr.
People will repay you multifold for the work you overdeliver. They will continually come back for any sequential project they require. They will refer you to their friends with similar interests. They will leave reviews that you couldn't even conjure up yourself.

And then comes even more magic.

Based on those very reviews, more intrigued customers will come. Overdeliver on their projects too, and.. Well, it's obvious. A massive snowball effect occurs.

I do Fiverr gigs just for fun. It is a way for me to practice people skills and effective communication with customers. Perhaps a month or two after I started overdelivering, the group of my dedicated customers exploded and I even had to put my account on vacation mode for a while due to too many requests I was getting on daily basis (remember, it was supposed to be a side job for fun, along with my Computer Science projects and faculty requirements, I couldn't let it become a full-time job).

This taught me an extremely valuable lesson I apply in everything I do nowdays.
I used the same technique to land a software engineering internship this summer. I gave my 110% to the task that was supposed to be just an overview of my current knowledge.

I gave it my all. And they recognized it. And they loved it!

The best thing is the positivity that this brings. And the fact that you can use it anywhere and anytime.
Overdeliver on a freelance job, overdeliver on your tasks at work, overdeliver when preparing a meal for someone..

Do it anywhere you go and you will create an atmosphere of delight around you at all times.

Recognizing Naive Development

Jurica Kenda — Sat, 24 Aug 2019 16:37:30 +0000

"A naively formulated goal transmutes, with time, into the sinister form of the life-lie.", writes Jordan B. Peterson in his book - 12 Rules for Life.

In the same book, he also explains what a life-lie is. To my understanding, a person living a life-lie is someone who is living their life premised upon a particular idea which supports only one preferable, narrowly defined and overly specific outcome.

The problem is in the rigidity of the expected outcome. Being rigid about your opinions, expectations and beliefs can rarely be a good and positive thing. Regardless of the context.

Naive developers

The same premise applies to programming. So, let's understand the root of this problem. How do you recognize a naive developer (and potentially see if you are behaving like one)?

A naive developer is a one which believes that his current knowledge will forever be well grounded and conclusive. Therefore he designs and architects the code structure in such manner that it only solves a specific problem he acknowledges. He refuses to forsee any other course of action and flow of the program. He is trapped in his own petty beliefs and ideas.
He is effectively blind.

A naive developer can easily be caught while pair-programming. He is a person who will continuously impose his own ideas without giving their partner a chance to present their own views on the issue at hand.

Approaching problem from a one-point-perspective, he will inevitably be forced to bend all of the forthcoming code out of shape, and into his poorly constructed mould. And this is where things start to get really unpleasant for a naive developer.

His unadaptable opinions created a code monster to deal with. The endless refactorings (if he even recognizes that is appropriate) will not be of much help. He must redesign the system.

But the real issue is not the code he created. It is his mindset and approach to the problem. If he doesn't take the responsibilty to see his own failures, he will continue creating code monsters in each problem he tries to solve.

So this is the part where you think about your approach to problem solving.

You should always keep reasking yourself : what is truly the problem I am aiming to solve? Getting stuck in the development rut is something every developer encounters from time to time. That is precisely why we should always develop with our one eye open, waitting to catch ourselves in our wrongdoing.

Rely on your fellow developers

Ask for a second opinion (at least). Trust someone with a fresh view on the problem. Listen to their ideas and propositions. Discuss the possible outcomes.

Take a coffe break

Seriously. Going on a 10 minute break can give your mind some space to rethink the problem you are solving.

Be honest with yourself

Last but not least, admit and correct a mistake when you know you had made one. Do not keep pushing an idea beyond its scope. A good sign you might be naively programming is too much (truthfully, any) hacky business going on.

Conclusion

To an engineer, the idea of making a mistake, especially one which implies a big analytical mistake, is hard to swallow. But it is something necessary to do, for the sake of efficiency and productivity.

Please give me your opinions and experinces related to this topic. I would love to hear them! Have you ever been a naive developer? Have you worked with one? What was the outcome?