DEV Community: Uros Mitic

The Danger of Assumptions in Client Communication

Uros Mitic — Mon, 31 Mar 2025 15:11:50 +0000

At one point, my team was juggling three critical projects simultaneously, and dropping the ball on any of them was not an option. We successfully released the first project while also addressing additional Roku certification requirements for the other two. After the initial release, we shifted our focus to the remaining projects. However, as luck would have it, the newly released app began experiencing user authentication issues.

Initial Issue and Speculation

One evening, I received a call to join the war room. Our CTO informed me that the client was encountering problems, with most reports coming from Roku, FireTV, and tvOS platforms. He briefly explained how to reproduce the issue on FireTV, and the technical managers immediately began speculating about the cause, especially since these platforms did not share a common codebase. However, they did share the same UI/UX and backend.

Struggling to Replicate the Issue

The next day, I began troubleshooting but quickly realized that I couldn’t replicate the issue, no matter what I tried. I tested on various devices, OS versions, and even during the client’s peak usage times, but nothing worked. After a long day of debugging, I was invited to join a call with the client.

The client’s project manager was visibly frustrated, insisting that the issues be resolved on all platforms, starting with Roku since it was their largest platform. Our team’s initial response was to reassure the client that we were doing our best, but it quickly became clear that this approach was not enough.

Changing the Approach

Exhausted from the earlier debugging session, I wanted to get straight to the information that could help resolve the problem. Once given the opportunity, I started asking specific and targeted questions: the exact reproduction steps on Roku, the specific device models and OS versions affected, the time frame when the issues occurred, the percentage of affected Roku users compared to other platforms, and at least ten user accounts experiencing the problem.

As I asked these questions, something unexpected happened—the tension in the conversation noticeably decreased. The client began answering the questions and soon admitted they didn’t yet have the necessary information. We agreed to reconvene after their customer support gathered the data.

The Data Tells a Different Story

During the follow-up meeting, customer support provided the requested details. Surprisingly, Roku turned out to be the least affected platform despite accounting for more than half of their user base. The number of incidents was so low that they struggled to provide enough user accounts affected by the problem. The data clearly indicated that FireTV was the most problematic platform.

From that moment on, the narrative shifted from:

Roku is the main issue

to:

Roku is actually our most stable platform. What did you do differently compared to other platforms?

The Danger of Flawed Assumptions

Reflecting on the situation, it’s interesting how a flawed assumption almost led us to allocate additional resources to fix the problem immediately, which could have jeopardized the progress of other projects. The client’s faulty reasoning was as follows:

The majority of our users have Roku devices. The issue is present on all platforms, so Roku, being the largest platform, must be the most affected. Therefore, our priority should be fixing Roku first.

As soon as they heard from customer support that Roku was affected, ideas began spiraling, quickly diverging from the actual situation.

Important Takeaways

Easing Tension by Focusing on the Right Questions

The escalation started to subside, and client trust began to grow as soon as we focused on asking the right questions. To handle similar situations more effectively in the future, I decided to adopt the following framework:

Try to stop being defensive.
Demonstrate genuine concern for the problem.
Start asking targeted questions.
Actively listen to responses.
Involve the right people.
Keep information loops as short as possible.

Get the Right Info First to Avoid Miscommunication

Always have in mind that what might resemble a game of "Telephone" or "Chinese Whispers" from childhood is actually a common communication challenge in many established processes and organizations. To navigate any situation effectively, it's essential to base decisions on accurate information - making it a top priority to gather reliable data first.

AI and the Decline of Long-Term Code Health

Uros Mitic — Wed, 19 Mar 2025 13:56:28 +0000

It was a late afternoon, and six of us were sitting in the office, unwinding over a few beers. It had been a great day, one of my colleagues had just deployed a major feature, while my team had finally squashed a stubborn bug that had been haunting us for days.

As we chatted about the day’s wins, someone threw out an interesting question: What do we prefer in our daily work: building new features, refactoring, or fixing bugs?

For some reason, refactoring didn’t spark much debate. But when it came to feature development versus bug fixing, the room was split right down the middle. That conversation left me with a mental image of a spectrum when it comes to software engineering preferences: bug fixing on one end, feature development on the other, with refactoring sitting somewhere in between.

When AI Meets DRY

Personally, I lean toward the bug-fixing side of that spectrum, so when I came across GitClear’s analysis on AI Copilot Code Quality, it immediately caught my attention.

The key takeaway? AI-powered coding assistants boost developer productivity but at a cost. The analysis pointed out that these tools often suggest code that already exists somewhere in the codebase. Engineers accept these suggestions without checking if the same logic has already been implemented elsewhere. In other words, AI is subtly encouraging code duplication, which flies in the face of the DRY (Don’t Repeat Yourself) principle.

This is mainly driven by the fact that engineering productivity is still largely measured by lines of code written, number of commits or features delivered, completely overlooking the long-term maintenance costs that are introduced.

We already know that duplicated code leads to more bugs, and more bugs mean more time spent fixing issues instead of innovating. So while AI might make us feel more productive in the short term, it could be setting us up for a future where maintenance and defect remediation become our primary job.

The analysis even makes this prediction:

...in the coming years, we may find "defect remediation" as the leading day-to-day developer responsibility.

As someone who enjoys bug fixing and refactoring, that doesn’t sound too bad but from a software quality perspective, it’s a worrying trend.

Measuring What Matters

The analysis references a well-known quote from Peter Drucker:

What gets measured gets done.

and continues with:

There is a great hunger for more developer productivity. If "developer productivity" continues being measured by "commit count" or by "lines added," AI-driven maintainability decay will continue to expand.

As an Engineering Manager, I see our core software engineering principles - DRY, KISS, YAGNI, as fundamentally designed to keep long-term maintenance costs low.

To break this downward spiral, we need to rethink how we measure developer impact. Instead of focusing purely on velocity, we should define metrics that reflect an engineer’s contribution to long-term maintainability.

Ironically, our senior engineers have been telling us this for years. It turns out we needed a productivity multiplier like AI to fully understand the consequences of ignoring their advice.

Balancing Doubt and Responsibility: The Challenge of Being a First-Time Interviewer

Uros Mitic — Tue, 18 Mar 2025 08:41:20 +0000

Let’s be honest, as an engineer, whether you like it or not, you’ll have to take part in the hiring process at some point in your career.

Some engineers start interviewing earlier than others, and those who are new to it often feel anxious before stepping into the role of interviewer. I certainly did.

I remember my first experience: we were hiring for a Senior Roku Developer position, and I was asked to support my team lead in the process and provide a second opinion.

Why it Was a Challenge

At the time, I was still struggling with imposter syndrome, so questioning a senior developer who probably knew more than I did felt intimidating.
I also worried about misrepresenting my team and company by not presenting myself well.
And, of course, I feared making a poor judgment that could lead to a bad hire.

Interviewing More Experienced Engineer

To prepare, I wrote down all technical questions I wanted to ask, and then tried to note down the answers as well.

During this exercise, I had a realization: even though I knew the answers, I struggled to explain them clearly and concisely.

Following Richard Feynman’s famous saying, "If you can't explain it simply, you don't understand it well enough," I marked these questions as personal improvement topics for myself.

This process became my first step. It helped me establish a solid framework for the discussion and gave me a clearer sense of the direction that the conversation can go.

Maintaining a Professional Image

At its core, the real challenge was how I should conduct myself when challenged.

I decided to approach the interview with an open mindset, allowing myself to learn from the experience.

To make this work, the conversation needed to feel like two engineers discussing topics they're passionate about and not like one person asserting their opinions while judging the other.

Fortunately, the company really promoted this kind of culture, so I felt confident it wouldn’t be an issue.

The Pressure of Making the Right Hiring Decision

After reflecting on this pressure, I realized there was one thing I truly disliked: the possibility of being fooled by someone's misrepresentation of himself. To put it in the right context, I was more worried about being tricked than about making the wrong hiring decision.

It was a clear clash between my ego and my responsibility.

However, once I set my ego aside, I recognized that anyone could be misled by how someone presents themselves.

This realization helped me let go of my ego and allowed me to approach the interview with a more honest perspective.

In the end, it will be simple: if I genuinely enjoy the conversation and the candidate feels authentic, it will be a good fit. And if I notice any red flags, I will bring them up to my team lead.

The Lesson Learned

A few days before the interview, my team lead sat down with me, explained the process, and set clear expectations. This should have helped me focus on what really mattered - covering my team lead's blind spots and being there after to challenge him during the candidates briefing to ensure we hired the best possible fit for our team.

Looking back, it's clear how much I overthought and stressed about something that was much simpler than I made it out to be!

Preparing in detail for the interview definitely helped me significantly, but looking back, I would have enjoyed the process much more if I hadn’t gone into it with the wrong expectations. I built up a lot of unnecessary pressure, thinking I had to act like a seasoned interviewer right away. In reality, it was about learning, adapting, and growing alongside the candidate. If I had simply accepted the process for what it was - a chance to grow - I would have found it much more enjoyable.

Could This Have Been Avoided?

Absolutely. I never voiced my concerns to my team lead. By keeping my worries to myself, I never gave anyone the chance to reassure me that I was overcomplicating things.

It’s completely understandable to feel challenged during a technical interview, even when you’re the one doing the hiring. Yes, I know how strange that sounds! But, as always, communicate your concerns about the task at hand. That way, you can be sure there’s actually something to worry about!

The Day My Imposter Syndrome Was No Longer Just in My Head

Uros Mitic — Sun, 09 Mar 2025 17:47:52 +0000

I recently came across an article suggesting that Imposter Syndrome Has Its Advantages. It made me reflect on my own experiences, especially the fear of inadequacy I felt at the beginning of my software engineering career.

The article, featuring insights from Basima A. Tewfik, an assistant professor at MIT Sloan, argued that imposter syndrome can actually improve interpersonal skills. By making individuals more people-oriented and sensitive to others' perceptions, it enhances likability and positively impacts career growth. Interestingly, the study also found that imposter syndrome does not negatively affect performance.

Surprise! You’re a Roku Developer Now

After several years of leading and managing a network operations centar, I decided to switch careers and venture into software engineering.
During my learning period, I was lucky enough to get hired as a junior Android developer. I was really excited about the opportunity but I was also aware of the amount of knowledge I was lacking.
Two weeks before starting my first day in the new position, I received unexpected news: I would be working on Roku development instead of Android. At the time, I didn’t think much of it, mostly because I had no idea what Roku was. I even assumed it was Android based.

Small and obvious tip: never assume anything without doing your research!

Unlike Android, Roku devices run on Roku OS, which has its own proprietary language, BrightScript, and uses SceneGraph as a framework for building channels (applications). This was a steep learning curve I hadn’t anticipated.

The Day!

Three months into the job, I was preparing for my performance review, the one that would determine whether I’d be offered a permanent position. While I loved working with my team and was eager to learn, imposter syndrome had plagued me for months. I constantly questioned whether I was meeting expectations.

Uros, the team enjoys working with you. However, you’re really not a good software engineer, and I don’t know if we’ll be offering you a permanent contract at this time.

...the world came crashing down. I felt my "fight or flight" response kicking in, but I managed to stay composed, accept the news, and walk out of the office.

A few days later, my manager approached me again with an update:

We’ve decided to offer you a permanent contract, but without the salary increase we had initially discussed. I’ll also send you some materials and books to help you out.

Fair, I thought to myself, and jumped into whatever he had planned for me.

Internal Struggle

Weeks passed, but the feedback continued to bother me. The idea of being a “bad software engineer” lingered in my mind. Before long, I realized that I strongly disagreed with the assessment. But to be sure, I needed to determine whether the original performance review was truly accurate.

After some thinking, I devised a plan to get an "unbiased" evaluation of my skills. In short, the main idea was to seek the feedback from people who:

Had no personal relationship with me
Had no incentive to underestimate my abilities

The Plan

The best way to achieve the above, or at least the best way I could think of - was to participate in as many hackathons as possible and apply to as many jobs as I could! A real world scenarios where my skills would be tested with as little bias as possible.
This would help me move beyond handling the problem purely on an internal level!

Of course, this plan carried a risk: If my manager’s assessment was confirmed, I’d have to confront the possibility that a career in software engineering wasn’t for me. It may sound a bit dramatic from this perspective, but this is exactly how imposter syndrome works.

The Result

I’ll keep this brief: things turned out better than I could have imagined. Here are some key highlights:

I participated in the MIT Health Tech Hackathon in Belgrade, where our team was one of the top three winners.
With the same idea, we competed in Belgrade and Berlin Startup Connect, winning first place.
Most importantly, I received a job offer for a Medior Roku Developer position shortly after I started applying for interviews.
After several months at the new company, I made significant contributions to multiple projects, which led to an offer for a team lead position.

…and with that, finally, the feeling of being an imposter started to fade away!

The Conclusion

This experience reshaped my understanding of both positive and negative feedback. I realized the importance of creating an environment where employees feel encouraged to challenge feedback.

It also gave me the confidence to not just “trust my gut,” but to take action when I felt I had the necessary context despite the self-doubt lingering in the back of my mind.

While imposter syndrome can sometimes push individuals toward growth, it can also take a significant toll on mental health. As managers, we have a responsibility to minimize feelings of inadequacy by providing clear, honest, and frequent feedback, the kind that empowers rather than discourages.
I know, it’s not a groundbreaking revelation, but it’s one that’s always worth repeating!

The Unseen Influence of Past Job Experiences on Your Interview

Uros Mitic — Fri, 21 Feb 2025 18:57:44 +0000

The Trap Many Engineers Fall Into

Imagine walking into an interview, carrying the weight of your current or last job.
A job where your decisions were constantly questioned, your confidence eroded, and your efforts undervalued.
You disliked working in that environment, and now, you're determined to avoid ending up in a similar one.

Then, the interviewer asks:

In what type of work environment are you most productive and happy?

This is the moment you’ve been preparing for!

I'm most productive and happy in an environment where my decisions aren’t constantly questioned!

You answer with confidence, feeling a wave of relief — almost like you're addressing the issue with your current tech lead in that very moment.

But here’s the problem…

Despite your best intentions to find a more suitable workplace, you may have just lost your chance.

Why This Answer Can Backfire

A hiring manager might interpret your response as:

A potential red flag for collaboration – Does this person struggle with feedback?
Overconfidence – Are they unwilling to justify their decisions?
A strong desire for autonomy – Will they reject structured teamwork?

From my experience, candidates rarely intend to send this message, but the way they phrase their answer can unintentionally convey the wrong impression, creating a hidden impact.

I’ve seen many candidates fall into this trap. Instead of highlighting what they want in a positive way, they frame their answer as a reaction to past frustrations. This emotional response can make interviewers hesitant, even if the candidate would actually be a great fit.

I always strive to understand the emotions behind their words by asking further clarifications, but the initial response sometimes puts me in a position where I must convince other stakeholders not to see it as a red flag. Since misunderstandings can happen, addressing potential concerns from the start helps create a smoother conversation for both sides. With this being said, we also need to acknowledge the fact that hiring managers should also work on their interpretive skills and questions in order to avoid the misinterpretations. However, my primary goal here is empowering candidates to control their own narrative so let's keep our focus on that.

How To Find A Better Way to Get Your Point Across When Emotionally Charged

When answering emotionally charged questions, be mindful of how you express your preferences. Before answering, always think what's the question really about and how to get your point across while simultaneously covering all concerns that your point might provoke.

Let’s rephrase the initial response to emphasize key aspects that better convey your intent:

Instead of this:

I'm most productive and happy in an environment where my decisions aren’t constantly questioned.

Try this:

I thrive in an environment where there is mutual trust and open collaboration. I appreciate having the autonomy to make decisions while also engaging in discussions that focus on improving the solutions I suggested.

Or this

I'm most productive and engaged in an environment with mutual trust, where my decisions are met with constructive discussions while allowing a degree of autonomy based on my experience and expertise.

This approach communicates a desire for autonomy while leaving no room for misinterpretation.

Finally, with rephrasing the answer, the hiring manager is more likely to conclude that you:

Value trust and collaboration
Appreciate constructive discussions
Seek autonomy without rejecting teamwork
Are experienced and confident

Important: Before proceeding, it's essential to clarify that rephrasing your answer isn't about deceiving the hiring manager by telling them what they want to hear. On the contrary, it's about ensuring that your response provides full context, preventing unintended misinterpretations that could work against you.
While writing this post, I came across an interesting study on How Emotional Intelligence Might Get You the Job, that dives deeper into the subject of faking on personality tests/job interviews.
However, although it closely relates to the topic at hand, it deserves a separate in-depth discussion.

Final Takeaway

When a question triggers an emotional response during your interview, take a moment to pause and refocus. Instead of letting frustration shape your answer, think about how you can communicate your values and experience while providing a full context and addressing potential concerns in a positive way. In short - it's about ensuring clarity while maintaining authenticity in your answers. This subtle shift in how you frame your response, from reactionary to constructive, can help ensure your message resonates with the interviewer and positions you as a right candidate.

By thoughtfully managing your response, you'll be better equipped to present yourself in the best light and increase your chances of landing the role you truly deserve.

How to expose a field of a child node to the parent node interface using alias on ROKU

Uros Mitic — Fri, 24 Jan 2020 01:05:56 +0000

At the beginning, I would like to say that using alias on ROKU is kinda cool thing to do. Unfortunately, the same could not be said for the title of this blog post.

Let's say that you would like to change the field value of your child component outside of his parent node.
You would also like to avoid doing that with callFunc or with using observers due to unnecessary boilerplate code.
When you think about it, you actually don't want/need to do any extra stuff besides just changing the value of the field.
Here is where use of alias can come into play.

Example:

Here is our child component:

<?xml version="1.0" encoding="utf-8"?>
<component name="childComponent" extends="Group">
  <script type="text/brightscript" uri="./childComponent.brs"/>
  <interface>
    <field id="changeMe" type="string" />
  </interface>
</component>`

We have a basic childComponent that has a field defined on interface with the id="changeMe" and since we did not defined the value, default value for this field is an empty string.

Now let's add this child component to it's parent.

<?xml version="1.0" encoding="utf-8"?>
<component name="parentComponent" extends="Group">
  <script type="text/brightscript" uri="./parentComponent.brs"/>
  <children>
    <childComponent id="childId"/>
  </children>
  <interface>
    <field id="changeFieldInChildComponent" alias="childId.changeMe" type="string" />
  </interface>
</component>

Noticed something interesting in the parentComponent?
Take a look at this line:

<?xml version="1.0" encoding="utf-8"?>
<field id="changeFieldInChildComponent" alias="child.changeMe" type="string"/>

Yeah, that little thing is called alias and it will allow us to do exactly what we want!

Let's change the value of the changeMe field of the child component outside of the parent.

So in a component/node outside of parent which has access to our parentComponent, You should be able to to this:

m.parentComponent.changeFieldInChildComponent = "I'm not an empty string anymore"

And that's it! Field changeMe of a childComponent now should have the value of "I'm not an empty string anymore".
This also works with native ROKU component fields.

Roku development, where to start?

Uros Mitic — Sun, 08 Apr 2018 23:59:11 +0000

When I started learning Roku development I had a luck of working with an awesome senior developer who already had a lot of experience with the BrightScript and SceneGraph.
Everything that I wanted to learn I could learn from him(and I still do).
Unfortunately a lot of developers don't have this opportunity so I wanted to share few links that could help them learn Roku Development.

1.
For learning BrightScript start from codingalien.com and the Roku documentation.
Some information on the codingalien.com page is outdated so the good practice would be to compare it to the Roku documentation(You will also learn by doing this).
UPDATE:
After you get some grasp of BrightScript head over to learnroku/crash-course, this is for now maybe the best source of learning regarding ROKU development for beginners.

2.
SceneGraph, in short, is data structure that Roku uses to manage rendering of the application screens. After learning BrightScript this is where you should go next.

3.
When you get familiar enough with BrightScript and SceneGraph, play a little with the Roku examples from here. You can also check my github for some ROKU examples.

IMPORTANT UPDATE:
ROKU has created a Youtube channel and a ROKU channel with tutorials on for the new ROKU developers. This is really good starting point:
ROKU Youtube Tutorial channel
ROKU Course

VARIOUS TOPICS:
1.Roku Like A Hurricane - Short tips and tricks and nicely explained "how to" blog posts.

ADVANCED TOPICS:
1.
After you learned how to develop ROKU channels, You would need to learn how can you do unit testing on ROKU.
Thanks to George Cook and his great work on unit testing framework called rooibos that will be a lot easier then before.
You can check his unit testing framework, with great documentations and video tutorials here: rooibos.

TOOLS:
1.BrightScript 2D API Emulator - The ROKU emulator for 2d games is still a "new born" and in Alpha stage but with the great potential thanks to the awesome work of Marcelo Lv Cabral . Side Note: It's only for 2D API so it can't be used as a regular emulator for all things ROKU.
2.Roku Atom and VSCode Linter developed by WillowTree Aps

You can always ask for help from stackoverflow community and of course from the Roku Dev Forum.

Notable developers from the StackOverflow Roku Developers Community:
1.Nas Banov
2.Eugene Smoliy
3.alphablender
4.TheEndless

Hope I managed to help.
Have a great day.:-)

How to define a function in component interface on Roku(BrightScript/SceneGraph)

Uros Mitic — Thu, 29 Mar 2018 21:50:25 +0000

If you have custom component named "doWhateverScreen" and you would like to print a string passed down from a different component named "HomeScene" using function in "doWhateverScreen" component interface, this is how you would do it.

First in your doWhateverScreen.xml file add:

    <interface>
        <function name="doWhateverMan" />
    </interface>

Now in doWhateverScreen.brs file add your "doWhateverMan" function:

    Function doWhateverMan(param as String)
        print param
    End Function

Great, so far so good!Let us continue.
In your HomeScene.xml add this custom created "doWhateverScreen" screen/component and in HomeScene.brs init() function add:

    m.doWhateverScreen= m.top.findNode("doWhateverScreen")

We can now call a function named "doWhateverMan" from HomeScene.brs with:

    param = "Do Androids Dream of Electric Sheep?"
    m.doWhateverScreen.callFunc("doWhateverMan",param)

That's it! Have a great day. :-D

How to launch a Roku channel from within another Roku channel

Uros Mitic — Tue, 06 Feb 2018 13:44:23 +0000

Launching one application from another on Roku platform sounds pretty cool right?
It also sounds complicated, especially if you are following Roku Documentation.
So I will try to explain it as simple as possible.
In this article I will focus only on part of the code that is responsible for launching another channel, if you want to check the whole project, go here:
https://github.com/umitic/Roku-Channel-Within

Let us start:

What you are actually doing, when You are launching Roku channel from within another channel is basically sending URL request to your Roku device.
Nothing fancy there, right?
To be able to do this we will use Roku External Control API.

Here is the code for launching another app from the Task:

deviceInfo = CreateObject("roDeviceInfo")
deviceIP = deviceInfo.GetIPAddrs().eth1

urlString = "http://" + deviceIP + ":8060/launch/12"     

request = CreateObject("roUrlTransfer")
request.SetUrl(urlString)
request.AsyncPostFromString(urlString)

Ok, let me explain this little piece of code:

deviceInfo = CreateObject("roDeviceInfo")
deviceIP = deviceInfo.GetIPAddrs().eth1

Here we are creating "roDeviceInfo" object so we could get IP address of Your Roku by calling "deviceInfo.GetIPAddrs().eth1" on it.
GetIPAddrs() - Returns roAssociativeArray. Each key in the Associative Array is the name of a network interface and the value is the IP-address of the interface.
Normally there will be only one interface in the Associative Array and that's why we call it directly with "GetIPAddrs().eth1".

urlString = "http://" + deviceIP + ":8060/launch/12"

With this string we are creating URL for the launching request.
What is important here is number "12"!
Number "12" is internal channel ID, in my case it's an ID of the Netflix channel.
You can get internal channel ID from the URL of the channel in the Roku channel Store.
Here is how Netflix one looks like:
https://channelstore.roku.com/details/12/netflix
Notice that "12" just after the "/details/" part.
Lets us move on...

request = CreateObject("roUrlTransfer")
request.SetUrl(urlString)
request.AsyncPostFromString(urlString)

This should be straightforward to understand.
We are creating "roUrlTransfer" object, then we have to set URL for the request by passing urlString as argument.
And after that we are calling AsyncPostFromString with urlString as argument.

That is it!
You have just launched Netflix from Your channel! :-)

Just one more thing. Before launching the Netflix channel you will have to have it installed on Your device.
You can do it in "regular/non-developer" way or You can modify urlString variable to instal Netflix from your channel. :-)
You can check Roku Documentation to find more about this: https://developer.roku.com/en-gb/docs/developer-program/debugging/external-control-api.md