DEV Community: gulnur

Why Engineers Wear Hoodies While Social Media Sells Perfection

gulnur — Fri, 22 May 2026 10:09:31 +0000

cover image is from->Image by catalyststuff on Magnific

This is not a technical post, but something I’ve been thinking about lately.
On one side, many scientists, engineers, startup founders, and developers live surprisingly simple lives. You see people at companies like Google, OpenAI, or research labs wearing the same hoodie every day, using old backpacks, drinking plain coffee, and focusing deeply on their work.

On the other side, social media constantly tells young people that they need more:
more skincare,
more fashion trends,
more luxury cafés,
more “must have” products,
more aesthetics,
more shopping hauls,
more routines.

Personally, I find this culture difficult to relate to. The less you consume the less you need. Especially on platforms driven by influencers, life is no longer presented as something to experience. It becomes something to perform.

And the contrast is hard to ignore.

I sometimes feel that scientists, researchers, and professors are no longer cultural role models for younger generations.

Many highly intelligent and productive people simplify their lives to protect their attention.
Meanwhile, algorithms encourage everyone else to consume endlessly.

Simplicity Is Not Laziness

There is a reason many developers and scientists dress simply.

People like Steve Jobs, Mark Zuckerberg, and many engineers in Silicon Valley became known for repetitive, minimal clothing styles.

Not because they could not afford more. Because reducing unnecessary decisions saves mental energy.

When your brain is focused on building products, solving problems, writing code, researching medicine, or designing systems, appearance becomes less important than clarity.

Simplicity creates focus.

A quiet room.
A basic outfit.
A clean workspace.
A smaller circle.
Less noise.

image is from->Image by freepik

For many builders, minimalism is not a fashion statement.
It is an optimization strategy.

The Influencer Economy Profits From Insecurity

Social media works differently.

Influencer culture often depends on creating dissatisfaction:
your outfit is outdated,
your body is imperfect,
your lifestyle is boring,
your room needs redesigning,
your skin needs fixing,
your morning routine is wrong.

The business model is simple:
make people feel incomplete,
then sell them the solution(!)

Sometimes the pressure is different depending on gender.

Many young women are pushed toward beauty products, fashion trends, and appearance focused consumption from a very early age through social media and advertising.

Meanwhile, many men are pushed toward status symbols, gadgets, cars, or financial success.

Both are forms of consumer pressure. And algorithms reward this behavior because insecurity drives engagement.

The result is a generation constantly comparing themselves to curated lifestyles that are often unrealistic, filtered, sponsored, or financially unsustainable.

Consumption Has Become an Identity

Years ago, people bought products because they needed them. Now many people buy products to build an online identity.

Coffee becomes content.
Books become decoration.
Travel becomes proof.
Gyms become aesthetics.
Even productivity becomes performance.

Sometimes people are no longer asking:
“Do I need this?”

They ask:
“Would this look good online?”

Builders Often Think Long-Term

One thing I notice about many developers, engineers, and technical people is that they often prioritize long-term freedom over short-term appearance.

Instead of spending constantly to impress strangers online, they invest time into skills:

coding
research
writing
building products
learning systems
creating businesses

I believe the reward is slower.
But usually more real.

While social media trends change every month, deep skills compound for years.

Maybe Simplicity Is Becoming Rebellious Again

In a world trying to monetize attention every second, simplicity almost feels rebellious.

Wearing basic clothes.
Ignoring trends.
Using things longer.
Reading instead of scrolling.
Building instead of performing.

None of these things look exciting on social media.
But they might create a calmer and more meaningful life.

And maybe that is why so many builders quietly choose simplicity.
I think Im going to wear my hoodie until it falls apart.

“Simplicity is prerequisite for reliability.”
― Edsger W. Dijkstra

Understanding B2B SaaS Products as a Developer

gulnur — Fri, 15 May 2026 17:08:28 +0000

Cover image is from->https://www.flaticon.com/free-icons/saas

When I first started software development, I mostly focused on technologies:

Angular vs React
Java vs Go
SQL vs NoSQL
Docker, Kubernetes, APIs...

But after some time, I realized something important:

A lot of engineering decisions actually come from the product model itself.

Especially the difference between:

B2B
B2C
SaaS products

Understanding these concepts changes how you think about architecture, UX, scaling, integrations, and even deployment strategies.

So here’s a simple explanation from a developer perspective.

What is B2B?

B2B means: Business to Business

A company builds software for other companies.

Examples:

Slack
Jira
Salesforce
GitHub Enterprise
Gitlab Enterprise
Storytelling/analytics/CRM platforms (I am using some of them on daily basis)

In B2B products:

Customers are companies
Sales cycles are longer
Integrations matter a lot
Reliability is critical
Documentation and APIs are very important

this usually means:

Authentication systems
Role management
Enterprise integrations
Audit logs
SDKs
Multi-tenant architecture
Scalability
Security compliance

A B2B customer might have:

thousands of employees
millions of requests
strict uptime requirements

So engineering expectations are usually higher around stability and maintainability.

What is B2C?

B2C means: Business to Consumer

A company builds software directly for end users.

Examples:

Instagram
TikTok
Spotify
Netflix
Duolingo

In B2C products:

User experience is everything
Fast onboarding matters
Viral growth matters
UI/UX decisions are critical
Engagement and retention are key metrics

this often means focusing on:

performance
animations
recommendation systems
personalization
mobile experience
A/B testing
analytics

A small UI change can affect millions of users instantly.

What Does SaaS Mean?

SaaS stands for: Software as a Service

Instead of installing software locally, users access it through the cloud.It is a cloud-based software delivery model basically.

Examples:

Notion
Figma
GitHub
Linear
PostHog

Most modern startups today are SaaS companies.

Typical SaaS characteristics:

subscription model
cloud infrastructure
continuous updates
web-based access
recurring revenue

SaaS usually involves:

cloud-native systems
APIs
observability
CI/CD
distributed systems
monitoring
scalability

B2B SaaS vs B2C SaaS

This is where things get interesting. Both can be SaaS products, but engineering priorities change significantly.

B2B SaaS

Examples:

Salesforce
Atlassian
HubSpot

Engineering priorities:

integrations
reliability
permissions
dashboards
reporting
enterprise security
API quality

Success metric:
“Can businesses depend on this product every day?”

B2C SaaS

Examples:

Spotify
Netflix
Canva

Engineering priorities:

engagement
UX
personalization
recommendation algorithms
responsiveness
growth metrics

Success metric:
“Do users keep coming back?”

Why This Matters

As developers, we sometimes focus only on code quality.

But product type affects:

architecture decisions
infrastructure
scaling strategy
frontend complexity
deployment frequency
observability
even hiring decisions

For example:

A B2B SDK product may prioritize:

documentation
API stability
backward compatibility

A B2C social app may prioritize:

realtime features
experimentation
recommendation systems
engagement analytics

Different products create different engineering cultures.

Overall,learning technologies is important.

However,I believe understanding:

how products make money
who the users are
what problems businesses are solving

can make you a stronger developer

PostHog Custom Surveys: Beyond the Default UI

gulnur — Wed, 13 May 2026 07:57:03 +0000

PostHog provides a powerful analytics and experimentation platform, including built-in surveys for collecting user feedback. However, in real-world applications especially dashboards, internal tools, or B2B SaaS products the default survey UI is not always flexible enough.

In this article, I’ll walk through how I built a fully custom in-app survey UI on top of PostHog, while still using PostHog as the data and analytics layer.

This approach allowed me to keep full control over UX, layout, and behavior without introducing an additional backend or feedback system.

Why Go Beyond the Default Survey UI?

PostHog’s built-in surveys are great for quick setups, but I ran into a few limitations and I would like to edit the pop-up.

Limited control over positioning and layout

UI didn’t fully match with my applicaiton

Needed a lightweight, non-intrusive CES-style survey

Wanted tighter control over when and how the survey appears

Instead of replacing PostHog, I decided to treat it as a survey engine, not a UI framework.

Architecture

The idea is simple:

PostHog Survey
↓
onSurveysLoaded()
↓
getActiveMatchingSurveys()
↓
Custom Angular UI
↓
posthog.capture()

PostHog decides when a survey should be shown.
My application decides how it should look and behave.

Listening for Active Surveys

One important lesson: calling getActiveMatchingSurveys() too early often returns an empty array.

The correct approach is to wait for surveys to finish loading.

posthog.onSurveysLoaded(() => {
  posthog.getActiveMatchingSurveys((surveys) => {
    if (!surveys.length) return;

    const survey = surveys[0];
    this.surveyId = survey.id;
    this.questionId = survey.questions[0]?.id;
    this.question = survey.questions[0]?.question;
  });
});

Why this matters

Without onSurveysLoaded, surveys may not be available yet

Ad blockers or strict CSP rules can silently block surveys

Defensive checks prevent runtime errors

Building a Lightweight Custom UI

Rather than using modals or full-screen components, I chose a small fixed-position card with a basic css, that feels native.

.survey {
  position: fixed;
  bottom: 24px;
  right: 24px;
  max-width: 360px;
  padding: 16px;
  border-radius: 4px;
  border: 1px solid #ddd;
  background: #fff;
  font-size: 14px;
  z-index: 1000;
}

@media (max-width: 768px) {
  .survey {
    right: 16px;
    left: 16px;
  }
}

Design goals:

Minimal color usage
Mobile-friendly
Easy to dismiss

No disruption to the main workflow

Submitting Survey Responses

When the user submits a response, the survey is sent back to PostHog as a custom event.

posthog.capture('custom_survey_submitted', {
  survey_id: this.surveyId,
  question_id: this.questionId,
  value: selectedValue,
});

When Does a Custom Survey Make Sense?

Custom surveys are especially useful when:

You need design-system consistency

You’re building internal tools or admin panels

Feedback should feel contextual, not disruptive

You want analytics-grade data, not just form responses

PostHog excels as the decision and data layer,custom UI lets your product own the experience.

If you want, you can visit posthog website,they doing lots of great things.

Useful Links:
https://posthog.com/
https://github.com/PostHog/posthog
https://www.npmjs.com/package/posthog-js

Getting Started with Playwright E2E Testing

gulnur — Mon, 11 May 2026 13:40:56 +0000

Modern web applications need more than unit tests.

You also need to test real user flows such as:

Login
Checkout
Form submissions
Navigation

This is where Playwright becomes useful.

Why Playwright?

Playwright is a modern E2E testing framework developed by Microsoft.

Main advantages:

Cross-browser support
Auto waiting
Parallel test execution
Fast and reliable
Works with Chromium, Firefox, and WebKit
Installation

npm init playwright@latest

Simple Login Test

import { test, expect } from '@playwright/test';

test('user can login', async ({ page }) => {
  await page.goto('https://example.com/login');

  await page.fill('#email', 'test@example.com');
  await page.fill('#password', '123456');

  await page.click('button[type="submit"]');

  await expect(page).toHaveURL('/dashboard');
});

One of the Best Features: Auto Waiting

Playwright automatically waits for elements to become available before interacting with them.

await page.click('#submit');

In many cases, you don't need manual waits anymore.

Running Tests

npx playwright test

You can also run Playwright in UI mode:

npx playwright test --ui

I personally use this mode a lot while debugging and fixing my tests.

If you are building production-grade frontend applications, adding E2E testing to your workflow is worth considering.

Before Cloning a GitHub Repository: How to Check If It’s Safe

gulnur — Thu, 07 May 2026 12:38:23 +0000

As developers, we clone GitHub repositories almost every day.

Sometimes to learn a new framework, sometimes to test an open-source project, and sometimes simply because a repository looks interesting.

But here’s the problem:

Running unknown code on your machine can be risky.
(I’ve also heard many stories on LinkedIn about this kind of scam. Yes, this is a real scam, and some people share these repositories with candidates who believe they are going through a legitimate interview process)

A simple npm install, pip install, or shell script may execute malicious commands, download hidden binaries, expose environment variables, or even install crypto miners.

Open source is powerful, but “public” does not automatically mean “safe”.

In this writing, we’ll go through a practical checklist to evaluate whether a GitHub repository looks trustworthy before running it locally.

1. Check the Repository Owner

Before cloning anything, look at who owns the repository.

Ask yourself:

Is this a real developer or organization?
Does the account have activity history?
Are there multiple repositories?
Do contributors look legitimate?

A repository created yesterday with zero history and copied documentation is already a warning sign.

Fake repositories often imitate popular projects using similar names.

Example:

react-official-tools
nextjs-fast-build
docker-helper-pro

Some malicious repositories are intentionally named to look trustworthy.

2. Inspect the Commit History

A healthy repository usually has:

consistent commits
meaningful commit messages
multiple contributors
issue discussions
pull requests

Be cautious if you see:

one huge initial commit
random generated commit names
no development history
suspicious binary file uploads

Check:

git log --oneline

If everything appeared suddenly in a single commit, inspect more carefully.

3. Read the Installation Instructions Carefully

One of the biggest mistakes developers make is blindly copying commands from README files.

Especially commands like:

curl something.sh | bash

or:

sudo chmod -R 777 /

Never execute commands you do not fully understand.

Look for:

external downloads
hidden shell scripts
encoded commands
unnecessary sudo usage

4. Check package.json or Build Scripts

For JavaScript projects, inspect the scripts section before running npm install.

Example:

"scripts": {
  "postinstall": "node install.js"
}

postinstall scripts execute automatically during installation.

Check for:

obfuscated JavaScript
external downloads
crypto mining packages
suspicious environment variable access

Useful commands:

cat package.json

grep -i "postinstall" package.json

5. Review Dependencies

Sometimes the repository itself is clean, but dependencies are malicious.

Attackers occasionally publish packages with names very similar to popular libraries.

Example:

expresss
reeact
lodas

This is called typo-squatting.

Use tools like:

npm audit

pip-audit

go mod verify

Also check:

outdated dependencies
abandoned packages
unknown private registries

6. Avoid Running Unknown Code on Your Main Machine

This is probably the most important habit.

If you are testing an unknown project:

use Docker
use a virtual machine
use a separate development environment

Example:

docker run -it --rm node:20 bash

This isolates the environment and reduces risk.

Running random repositories directly on your personal machine is not a great idea.

7. Look at the Security Tab

GitHub provides useful security information.

Check for:

security policies
dependency alerts
vulnerability reports
signed commits

Repositories with active maintenance and security practices are usually more trustworthy.

8. Be Extra Careful With AI-Generated Repositories

AI tools make it easier than ever to generate fake or low-quality projects.

Some repositories now contain:

copied README files
auto-generated code
hidden malicious payloads
fake stars or fake engagement

A professional-looking README does not guarantee safety.

Always inspect the actual code.

Open source software is one of the best parts of modern development.

But developers should approach unknown repositories with the same caution used when downloading software from the internet.

A few minutes of inspection can prevent:

credential leaks
malware infections
exposed SSH keys
compromised development environments

Before running code, take a moment to verify what you are actually installing.

The Day I Stopped Saying “This Isn’t My Job”

gulnur — Sat, 04 Apr 2026 20:41:26 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

I was hired as a full stack developer.

My daily work mostly revolved around building features, improving backend services, working on frontend interfaces, and making sure users had a smooth experience. Infrastructure operations, SSL certificate renewals, or platform upgrades were never officially part of my role.

But in real engineering teams, reality rarely follows job titles.

One day, our GitLab instance required a version upgrade. It was not a simple “nice to have” update. The upgrade was important for security, compatibility, and long-term maintainability. Around the same time, one of our Red Hat OpenShift SSL certificates was approaching expiration.

Both tasks carried risk.

A failed GitLab upgrade could interrupt the entire development workflow for the team. An expired SSL certificate could break secure access to critical internal services. Neither of these problems could wait comfortably for “the right team.”

And that was the moment I had to make a choice.

I could say:

“This isn’t my responsibility.”

Or I could step forward and learn.

I chose the second option.

Learning Beyond the Role

At first, I felt the weight of uncertainty.

As developers, we often become comfortable inside the boundaries of our official roles. Frontend, backend, API integrations, databases these were familiar territories for me.

But production systems teach a different lesson:
software is never isolated from infrastructure.

So I started where every engineer starts when facing something unfamiliar: documentation.

I carefully reviewed the GitLab upgrade path, version compatibility notes, backup procedures, and rollback scenarios. I made sure we had snapshots and restore points before touching anything.

For the Red Hat OpenShift SSL certificate update, I studied how secrets, routes, and ingress configurations were managed inside the cluster. I traced how the certificate propagated through the environment and planned the safest replacement sequence.

The technical work itself mattered.

But what mattered more was learning how to stay calm around systems that affect everyone.

The biggest challenge was not technical complexity.

It was psychological.

The fear of breaking production.
The fear of causing downtime.
The fear of touching systems outside my “comfort zone.”

What helped me overcome that fear was process.

Read the documentation twice
Prepare backups first
Test in lower environments
Create a rollback plan
Communicate the maintenance window clearly
Validate after every step

I realized confidence in engineering is rarely about already knowing the answer.

It comes from knowing how to reduce risk.

That experience changed how I think about growth in tech.

Sometimes the most important career moments begin exactly where your job description ends.

What This Taught Me About Inclusion in Tech

One reason I wanted to share this story for the 2026 WeCoded Challenge is that growth opportunities in tech are often shaped by trust.

Sometimes inclusion is not only about who gets hired.
It is also about who gets trusted with meaningful problems.

Being given space to step into unfamiliar responsibilities helped me grow faster than any predefined roadmap could.

And I believe equitable teams are the ones that create these learning moments for everyone: not based on title, seniority, or assumptions, but based on curiosity, support, and trust.

That GitLab upgrade and SSL certificate replacement were small operational tasks in the bigger picture of engineering.

But for me, they represented something larger.

They taught me that titles define your starting point, not your limits.

Sometimes the best thing you can do for your career is to stop saying:

“This isn’t my job.”

And start asking:

“How can I solve this safely?”

I believe that mindset has stayed with me ever since.

Trunk-Based vs. Branch-Based Development: Which Strategy Fits Your Team Best?

gulnur — Wed, 01 Apr 2026 14:41:34 +0000

One of the most important factors that shapes development speed and code quality in modern software teams is the branching strategy. Two of the most common approaches are Trunk-Based Development (TBD) and Branch-Based Development.

Let’s compare both approaches in a clear and practical way.

What Is Trunk-Based Development?

Trunk-Based Development is a workflow where all developers integrate their changes into a single main branch (usually main) using either very short-lived branches or direct commits.

Advantages

Encourages small and frequent commits
Reduces merge conflict risk
Works perfectly with CI/CD pipelines
Speeds up release cycles
Safer deployments with feature flags

Disadvantages

Requires strong testing discipline
Large features may need careful feature toggle management
Can be challenging for teams new to the practice

What Is Branch-Based Development?

In this model, developers create separate branches for each feature, bugfix, or release. Git Flow is one of the most well-known examples of this approach.

Advantages

Easier isolation for large features
More controlled code review workflows
Fits enterprise approval-based processes well

Disadvantages

Long-lived branches often create merge conflicts
Integration happens later
Release cycles can become slower The classic “it worked on my branch” issue happens more often

When Should You Use Each One?

Fast-moving startup and SaaS teams → Trunk-Based Development
Enterprise teams with heavy approval workflows → Branch-Based Development
Teams with mature DevOps and CI/CD culture → TBD

From my experience, especially during fast upgrades,urgent production hotfixes, the trunk-based approach significantly improves integration speed and reduces operational risk.

If your goal is faster releases, fewer merge conflicts, and stronger CI/CD pipelines, Trunk-Based Development offers a more modern engineering workflow.

Interestingly, I realized that we had already been applying this approach in some of our projects without even knowing it had a formal name. I first came across the term in a LinkedIn job requirements section, which made me reflect on how naturally some engineering best practices emerge in real-world teams.

I think the real key is this: your branching strategy should match your team’s deployment culture.

Habits I Learned Too Late as a Developer — part 2

gulnur — Sat, 21 Feb 2026 18:28:49 +0000

3️⃣ Not reading software-related books

For a long time, I didn’t read any software-related books.

I relied mostly on tutorials, short articles, and videos.
They felt more practical and faster to consume.

What I didn’t realize was what I was missing:

Long-form thinking and well-structured mental models

Ideas that stay relevant for years, not weeks. Short content is great for learning how to do something. Books are better at teaching why things work the way they do.

Without reading books, my knowledge stayed shallow and fragmented.
I knew many tools, but I lacked depth in fundamentals like system design, data modeling, and architecture.

I learned this late:

a few well-chosen books can save you years of trial and error.

Books that changed how I think:

Clean Code — not for rules, but for learning how to read code critically

Designing Data-Intensive Applications — for understanding real-world systems and their trade-offs

The Pragmatic Programmer — for a long-term developer mindset
This link might be helpful if you want to reach some of them

📕sample books
🔗a nice article

4️⃣ Focusing only on code 🖥️ and ignoring networking opportunities

Another habit I learned too late was attending meetups, events, and developer gatherings.

For a long time, I simply wasn’t aware of these communities:
Google Developer Group meetups, Cloud Days, Developer Days, Java Days, and similar events.

When I finally started attending them, I met many experienced developers and learned far more about industry trends than I expected.

Before that, I used to think:

Networking wasn’t necessary for “real developers”

Skills alone would speak for themselves

Events were mostly marketing or a waste of time

That mindset was limiting.

By not attending events, I literally missed:

How other developers think and work
Industry perspectives outside my own bubble
Opportunities to learn without preparing anything in advance

Networking doesn’t mean selling yourself.It means exchanging context.

Sometimes, a single conversation at a meetup teaches more than hours of solo learning.

Which habits did you realize too late in your developer journey? 👀

Habits I Learned Too Late as a Developer — Part 1

gulnur — Wed, 18 Feb 2026 07:53:41 +0000

For a long time, I believed that writing more code would automatically make me a better developer.
It didn’t.

I was improving my syntax and learning new frameworks, but I was mostly doing it in isolation.
What I missed for years was the ecosystem around software development,the people, the discussions and the shared knowledge.

These are some of the habits I learned much later than I should have.

1️⃣ Not following high-quality open-source projects

I used GitHub mainly as a place to store my own code.
I wasn’t actively following well-maintained, widely used open-source projects.

That meant I missed:

How real-world projects are structured

How maintainers review pull requests

How design decisions are discussed in issues

What “production-quality” code actually looks like

Reading good code consistently turned out to be just as important as writing my own.

What I do now

Even when I’m not actively coding, I visit GitHub weekly and check my starred repositories.
I follow a small number of projects and occasionally read a single file, commit instead of trying to understand the entire codebase.

This habit alone changed how I think about code quality.

2️⃣ Not knowing developer communities like Medium, dev.to, or CodePen

For a long time, learning meant courses, tutorials and bootcamps only.
I underestimated community-driven platforms.

What I later realized:

Courses teach ideal scenarios and sooner or later, you forget most of them

Community posts show real-world mistakes and trade-offs

Small experiments often teach more than full tutorials

Platforms like dev.to and CodePen expose you to problems people are actively solving, not just concepts explained in isolation.

Following challenges and community experiments is also fun.
And that matters more than I used to think.

If I want to become a better developer, I need to enjoy the learning process, not just endure it.

How to Write an ATS-Friendly CV: A Complete Guide

gulnur — Tue, 07 Oct 2025 10:22:22 +0000

In today’s job market, it’s not just recruiters who review your CV
Applicant Tracking Systems (ATS) often decide whether your application even gets seen. If your CV isn’t optimized for these systems, your experience and skills might never reach the hiring manager. Here’s how to write a CV that passes ATS filters while still impressing humans.

1. What is ATS and Why Does It Matter?

An ATS is software that scans, filters, and ranks CVs based on keywords, formatting, and relevance to the job description. A poorly formatted CV can get rejected automatically, even if you’re the perfect fit.

2. Choose the Right File Format

Best options: PDF or DOCX (most ATS tools can read both).

Tip: While many modern ATS systems can read PDF files, some older ones may struggle. To be 100% safe, submit your CV as a .docx file unless the employer specifically requests PDF
Also you may want to check file size too.

3. Keep the Design Simple

Stick to standard fonts: Arial, Calibri, or Times New Roman.

Avoid tables, graphics, icons, or text boxes.

Use clear headings and consistent spacing.

4. Use Keywords Strategically

Scan the job posting for required skills and titles.

Match those keywords exactly (e.g., if the posting says “Java Developer,” include “Java Developer” in your CV, not just “Java”).

List tools, certifications, and methodologies (e.g., Agile, Scrum, AWS).

5. Stick to Standard Headings

ATS tools recognize traditional section titles:

Work Experience
Education
Skills
Certifications
Languages

Creative headings like “My Journey” may confuse the system.

6. Write Bullet Points with Action Verbs

Avoid long paragraphs. Use concise bullet points.

Start each with strong verbs: Developed, Managed, Optimized, Implemented.

Quantify achievements:
“Increased sales by 25%”
“Led a team of 10 engineers”

Avoid using vague expression about your accomplisments

7. Format Contact Information Properly

Write your phone number in international format: +1 xxx xxx xxxx.

Use a professional email address(firstname.lastname@email.com).

Include a LinkedIn URL (avoid shortened links like bit.ly).

8. Skip Unnecessary Details

No date of birth, marital status, or full home address.
Even photo can be unnecessary for some applications.

Stick to what’s relevant to the role.

9. Keep It the Right Length

Ideal CV length: 1–2 pages.

Make every line count.

10. Test Before You Submit

Use online ATS simulators (e.g., Jobscan, Resumeworded) to check how your CV matches the job posting. This helps you adjust keywords and formatting before sending.

Final Thoughts

Writing an ATS-friendly CV isn’t about being flashy,it’s about being clear, structured, and keyword-optimized. Pass the system first, then let your experience and achievements convince the recruiter.

Remember: Step one is getting past the robot. Step two is winning over the human.

Axero Frontend Challenge: Building a Dynamic Office Intranet Interface

gulnur — Sun, 27 Jul 2025 14:21:00 +0000

This is a submission for Frontend Challenge: Office Edition sponsored by Axero, Holistic Webdev: Office Space

What I Built

I designed a nostalgic-futuristic intranet homepage for a fictional company called NeoOffice. My aim was to blend retro design elements—such as pixel fonts, VHS-glitch effects, and old-school widget with a clean, responsive layout that feels modern and functional. The homepage includes:

🌟 Employee of the Month widget with dynamic highlighting
📆 Upcoming Events section for internal meetings and community activities
🧭 A modular dashboard with useful internal tools (e.g., HR portal, task board)
💬 Team Spotlight and cooler-style announcements
🎨 Subtle CSS inspired by classic office life

I wanted the homepage to feel like something you'd find in a 90s sci-fi movie…

Demo

Live preview on:
Github: https://github.com/Gulnur-Altan/Nostalgic-Futuristic-Webdev-Office-Space

Journey

This was one of the most creative front-end challenges I've participated in. I started with a wireframe in Figma, then experimented with nostalgic UI elements like:

Monospace pixel fonts

Glowing neon details
Subtle hover animations

For accessibility, I followed WCAG color contrast standards, ensured all interactive components were keyboard-navigable, and added labels where needed.

One of my favorite parts was building the Employee of the Month card. I wanted it to feel special—so I gave it an animated badge, spotlight effect, and hover interaction.

I also added a dashboard panel to simulate internal tools like “Today's Tasks” access.

Overall, this project helped me blend creativity with usability, and it helped me understand thoughtful UI/UX in internal tools.
displayed publicly.

revert the merge

gulnur — Tue, 08 Jul 2025 14:26:29 +0000

🔄 How to Undo an Accidental Merge to the Master Branch
Merging the wrong code into the master branch is something that happens.Fortunately, Git and ways to undo this safely.

Here’s a guide to help you revert that accidental merge depending on your situation.

💬 Option 1: Revert the Merge Commit (Safe and Recommended)
If the merge created a merge commit, you can revert it with:

git revert -m 1
git push origin master -m 1

tells Git to keep the first parent of the merge (usually master) and revert the changes from the merged branch.

You can find the using git log

This will create a new commit that undoes the changes from the merge — safe and clean.

💥Option 2: Hard Reset (Dangerous on Shared Repos)
If you prefer to reset master to a previous commit (for example, before the merge), you can run:

git reset --hard
git push origin master --force

💥Warning: This method rewrites history and can break things for teammates.

⬅️ Option 3: Use GitLab’s “Revert” Button (Easiest)
If you’re using GitLab and the merge request is still visible:
Go to the merged Merge Request and click the Revert.
GitLab will create a new merge request that reverts the merge.

Merge it — and you're done!
This is a safe and GUI-friendly option if you prefer not to use the terminal.