DEV Community: gulnur

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.

Key Enhancements in Java 22

gulnur — Wed, 31 Jul 2024 22:53:18 +0000

Java 22 introduces several important changes that improve developer experience, code safety, and performance. Here’s a quick overview of the most useful updates:

1. Record Patterns
Record Patterns simplify pattern matching with records. They enhance the readability and conciseness of code by allowing direct extraction of record components in a single statement.

if (person instanceof Person(String name, int age)) {
    // Use name and age directly
}

2. Virtual Threads
Virtual Threads, introduced as a preview feature, provide a lightweight concurrency model. They enable handling a high number of concurrent tasks more efficiently without the overhead of traditional threads.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(() -> {
        // Concurrent task
    });
}

3. Foreign Function & Memory API (FFM API)

This API improves interaction with native code and memory management, making it easier and safer to work with native libraries and off-heap memory.

try (var allocator = MemorySegment.allocateNative(1024)) {
    // Work with native memory
}

Enhanced Switch Expressions

Switch expressions continue to evolve with improvements like more flexible patterns and clearer syntax, reducing boilerplate and enhancing code readability.

var result = switch (dayOfWeek) {
    case MONDAY, FRIDAY -> "Working day";
    case SATURDAY, SUNDAY -> "Weekend";
    default -> throw new IllegalStateException("Unexpected value: " + dayOfWeek);
};

Improvements to NullPointerException

Java 22 provides more detailed messages for NullPointerException, helping developers diagnose issues more effectively by pointing out the specific variable that was null.

String name = null;
System.out.println(name.length()); // Enhanced NPE message: "name.length()"

Java 22 brings valuable enhancements that streamline coding practices, improve concurrency, and offer better tools for native interactions.