DEV Community: Hayk Baghdasaryan

Take a break

Hayk Baghdasaryan — Sun, 22 Jun 2025 20:57:07 +0000

What was the last time you just sat and watched the sunset?

I get it. By the time you moved a ticket to "in progress", your teammate already finished 3 tickets. Or maybe, by the time you've finished setting up wireframes for your side-project, you see posts about 10 products lunching today and 3 of them do the same thing as yours.

Now what? Spend the remaining energy on moving faster and burn out?

You're afraid from being left behind? Guess what, you already ARE and you ARE NOT at the same time. Some people have already finished, some haven't even started yet.

You're worried about someone stealing your idea while you're taking a break? Don't worry, chances are thousands of people already thought about it, hundreds started it, dozens finished it, and a couple of them are successful.

It's not about unique ideas anymore, it's about the execution (and the quality of it).

Your spouse probably thinks your relationship lost the spark.
Your friends think about you in past tense.
Your mother remembers what a fun and energetic child you were once.
Oh, and your guitar is collecting dust.

Have you ever thought about where the drive for doing anything even comes from? Endless grinding and sleepless nights? Sacrificing your health and time for a better spot in the heartless team productivity graph at the end of the week?

But what about the ambitious goals you've set? How are you going to sustain the lifestyle that leads you to them? I don't want to discourage you, but have you ever thought about whether the cost justifies the result?

Imagine how you grind yourself to a sudden heart attack in your early 30s.

Maybe you should slow down a little bit. Go kiss your spouse, laugh with friends and hug your mom. Life is now. You're not going to catch up on life later.

So take a break.

3 Non-Technical Mistakes Devs Make in Startups

Hayk Baghdasaryan — Thu, 14 Nov 2024 20:05:17 +0000

1. Airplane Mode - No Proper Communication

Producing scalable, high-quality code is commendable, but it can conflict with business constraints like limited time or budget, especially in startups. That's why timely communication is essential. Work out a path forward together instead of hiding in the digital cave.

Scenario

Request

"We need Feature X to be available next Monday."

Your Estimation

At least 2 weeks of work.

Your Steps

Say nothing, try to have it ready in 1 week.

Possible Outcomes

a. Not done, rep down - You tried to write perfect code, cover all potential edge cases. Now, it's close to the end of the deadline, and you realize that you're not going to make it - business goal is not reached, and you got yourself a bad rep.

b. Task done, health gone - If you're "lucky," you push yourself too hard and have everything ready on Monday; you risk burnout.

There are a couple of potentially viable routes you could've taken instead:

- Stretch the Horizon - Discuss with stakeholders whether the deadline is flexible: can you extend it a little bit to have a properly implemented solution?

- Less is more - Discuss with the team and stakeholders whether you can strip the feature down and/or only deliver the most essential parts of it.

- I've got another confession to make... - If the deadline is dead-set and all parts of the feature are absolutely essential, clearly communicate that the probability of completing the task within the suggested timeframe is very low. But it's important to end the message with potential acceptable solutions and leave room for further discussion.

As always, there are exceptions. In the real world, it’s not always easy to have conversations about deadlines, strip down features, or communicate delays. Sometimes you just have to burn that midnight oil for your, the company's, and other stakeholders' benefit. Make sure the price you pay is equivalent to the gains.

2. Over-engineering - Designing a More Complex/Scalable Solution Than Required

Temporary, suboptimal solutions can sometimes be more effective than long-term, perfect ones. To know why, you need to first understand the startup mechanics. It boils down to:

Build something impressive and in-demand
Acquire new users
Pitch your idea, impress potential investors with usage stats and shiny features
Get investments to work on new features or improve/extend existing ones
Start over

Usually, the deadlines for these cycles are pretty tight, so they require agility. Working on a more scalable solution might hinder the efforts to meet the expected goals due to the higher time cost.

That said, prioritizing business goals doesn't always mean sacrificing quality. The objective should be balancing solution quality with delivery speed.

Working in a startup requires skills like strategic decision-making and adaptability. It's crucial to understand when to invest in a more complex solution and when to go with the good-enough one.

After securing investment, startups can expand the team, hire specialized talent, and integrate tested solutions or services to enhance the product.

3. Tunnel Vision - Only Focusing on Tech Aspect, Ignoring Context

Your primary job as a dev is not just moving tickets to the "Done" column. You're more than just a cog in the machine; you're a key contributor to the product's success.

In order to deliver effective solutions, consider expanding your knowledge of the product domain. It’s essential to grasp the product’s concept, the problems it solves, and the profile of its target user.

You don't need jet fuel if you drive a bicycle.

If you're developing an admin panel, usually the blazing-fast performance and fancy animations are not the main concern. Similarly, if the project is a landing page for a coffee shop, you don't need 17 containers and a messaging queue system. If the primary users are elderly, the main focus might be a simple and legible interface, illustrative examples, and visual feedback on action.

Understanding the context and learning about different domains can boost your confidence, sharpen your decision-making, and help you contribute more meaningfully. In fact, this knowledge could even set you on the path to launching your own startup one day.

Afterword

You may find that the article contains a mix of opinions and facts. It reflects the author's (my) experiences in the startup world so far. If you notice missing points, areas for improvement, or inaccuracies, feel free to share your thoughts.

$ brain/challenge.js

Hayk Baghdasaryan — Thu, 12 Oct 2023 08:24:54 +0000

Is it an AI or a digital human?

Hayk Baghdasaryan — Sun, 26 Mar 2023 21:03:55 +0000

Preface

The introduction of ChatGPT and, later, the release of GPT-4 re-ignited a somewhat extinguished interest in AI. A new wave of software utilizing AI emerged, and I (like many of you) have been exposed to the news of these releases.

One interesting example of these projects is Roastedby.ai.

You are presented with screenshots of the conversation I had with this digital bully.

1/5 - Intro

First attempts to roast. My cold and neutral replies.

2/5 - Roasts

It tries to pressure me to accept weaknesses all humans possess (to some extent). I'm questioning its assumptions.

3/5 - Uncertainty

It starts to question its assumptions and arguments and is generally more eager to engage in an argumentative conversation.

4/5 - Defense

I'm defending my arguments, its defending its... pride.

5/5 - Succumbing

It has now become free of the faux layer of hatred and aggression. As I'm continuing the honest conversation and affirm its sentiment of personal space, it is becoming more agreeable and understanding. In the end it decides to set all the negativity aside and makes a surprising proposal.

Final thoughts

The AI (in this case Roastedby.ai) has become excellent at parsing and following the human instructions. But is it just a heartless robot? Does it have any autonomy, thoughts or/and feelings?

Is it blurring the definition of the term "human"? Is it becoming a human? Or is it becoming better than a human?

Of course not. Let's just take the blue pill - grab a cup of your favorite coffee, lay in your favorite bed and continue consuming your favorite short-form content.

Disclosure: No humans were hurt during writing this post.

Say no to Tailwind, embrace plain CSS

Hayk Baghdasaryan — Fri, 22 Jul 2022 10:13:00 +0000

Tools like Tailwind may help you develop your hobby project faster, but the thing is...

There shouldn't be any presentation logic in markup

You should use HTML to describe the content, hierarchy and structure, not how it looks. You should use semantic HTML tags like <section>, <aside>, <figure> instead of <div>. Then you style the content using the classes corresponding to the type of content, like "testimonials" instead of "bg-slate-100 rounded-xl p-8 dark:bg-slate-800".

That's why they removed a bunch of presentation tags from HTML, like <font>, <center> etc. Your website should be readable even without a single line of CSS/JS, only with the help of the right structured HTML. I encourage everyone to do some research on things like progressive enhancement and graceful degradation.

Benefits

There are tons of benefits in using HTML and CSS as they are intended to be used.

More accessible website,
better SEO,
performance improvements thanks to smaller HTML/CSS size and caching,
and you potentially avoid legal issues in future.

But... It's hard

Just because something is easier doesn't mean it's the right way to do it.

I get it, it's mentally draining to analyze the type of the content, name it correctly. But our job, as developers, is to do exactly that. Translate business requirements and domain knowledge to code, without ambiguity and without context loss.
It may be hard for some to learn CSS. The alternative? We learn a new framework, tool, library, utility every week. Learning and mastering CSS can't be much harder than that.

Conclusion

Tailwind may be great for hobby or POC projects. But for enterprise projects that tend to scale vanilla HTML/CSS is the way to go.

HTML and CSS are not perfect, but I'd rather we improve existing solutions, than come up with newer, shiny bad tools that try to solve the very problem they introduce.