DEV Community: Prakhar Yadav

Markdown in ServiceNow: how I made rich work notes easier

Prakhar Yadav — Tue, 16 Dec 2025 14:29:54 +0000

I wanted a better way to write rich notes inside ServiceNow work notes. At work we type a lot of short updates, code snippets, and checklists. The default journal box in ServiceNow is fine, but writing formatted text feels slow and error prone. So I made two things: a small library and a browser extension that uses it.

Links

Library on GitHub: https://github.com/yadav-prakhar/markdown-servicenow
Published on npm: https://www.npmjs.com/package/markdown-servicenow
Browser extension: https://github.com/yadav-prakhar/markdown-sn-extension

Why I built this

I wanted to write notes in markdown and have them appear nicely formatted in ServiceNow journal fields. The goals were simple:

Save time when writing work updates.
Support common markdown like lists, code blocks, bold, italic, and blockquotes.
Keep the output safe for ServiceNow journal format so pasting does not break anything.

I built the library first so the conversion logic is reusable. Then I made a small extension so I can write in a tidy editor and paste formatted output into ServiceNow with one click.

What the library does

The library takes markdown and converts it into markup that can be understood by ServiceNow journal fields. It handles:

Headers, paragraphs, bold, italic
Ordered and unordered lists
Inline code and code blocks
Blockquotes
Tables (basic)
Highlights
Github syle alerts

Element	Syntax
Headers	`#`, `##`, `###`, etc.
Bold	`text` or `__text__`
Italic	`text` or `_text_`
Bold + Italic	`*text*`
Strikethrough	`~~text~~`
Highlight	`==text==`
Inline code	`code`
Code blocks	` fenced blocks
Links	`[text](url)`
Images	`![alt](url)`
Unordered lists	`- item` or `* item`
Ordered lists	`1. item`
Blockquotes	`> quote`
Alerts	`> [!NOTE]`, `> [!TIP]`, `> [!WARNING]`, etc.
Tables	Pipe-delimited tables
Horizontal rules	`---` or `***`

It also takes care of ServiceNow specific quirks so the output shows correctly inside the journal editor.

Sample outputs:

The browser extension

The extension is tiny and focused.

It gives a markdown button below the journal field (comments, work notes, etc.). Once you've typed your markdown, just click it and the text is converted in-place to the journal style entry.
It gives me a small editor pop-up where I write markdown. When I click convert, the extension runs the library, converts the text, and copies the result. Then I paste into the ServiceNow work notes. This saves a lot of clicking and cleanup.
It also has a context menu entry. Just write the markdown → select it -> right click → select Convert Markdown to ServiceNow

Features I built:

Quick editor popup
Live preview of converted output (optional)
Copy to clipboard button
Small settings panel to tweak conversion behavior
Context menu to convert selected text
Button next to Journal field to convert in-place

How to use it (quick)

Install the extension from the repo or load it as unpacked during development.
Open the popup and write your markdown.
Click Convert.
Paste into the ServiceNow work notes field.
Confirm the formatting looks right in the journal.

Before	After

A short technical note

I wrote the library in JavaScript so it is easy to publish on npm and reuse in the extension. The conversion logic is modular, so you can plug it into other tools if you want. I tried to avoid heavy parsing libraries to keep the bundle small.

If you are curious about internals, check the README on GitHub for examples and the small test suite.

What I learned

Small tools solve repeated friction. What took minutes every day becomes seconds.
Writing robust text conversion needs many small rules. Edge cases show up fast.
Packaging a tiny library first made the extension easier to build.

Next ideas

Open to ideas & pull requests if you feel like doing something yourself.

Where to find it

Library: https://github.com/yadav-prakhar/markdown-servicenow
npm: https://www.npmjs.com/package/markdown-servicenow
Extension: https://github.com/yadav-prakhar/markdown-sn-extension

Feel free to open an issue or a PR. If you try it, I would love to hear how you use it or what features you want.

Thanks

Feel free to star the repo if you like it :)
👇 and here's an avatar of me for no reason at all 🤭

🚀 Introduction to Git Worktree (With Oh My Zsh Aliases)

Prakhar Yadav — Mon, 17 Nov 2025 05:12:06 +0000

If you’ve ever had to switch branches in the middle of work, stash your changes, or juggle multiple clones of the same repository… you already know the pain.

Good news: Git Worktree makes all of this much easier.

This guide will introduce:
• What Git Worktree is
• What Oh My Zsh is (and why its aliases help)
• Real workflows for single-repo apps
• Real workflows for monorepos

Let’s make your Git life smoother and your workflow faster. ✨

🌱 What is Git Worktree?

A Git worktree is a feature that lets you check out multiple branches of the same repo at the same time — each in its own folder.

Think of it like having multiple “workspaces” linked to the same Git repository.

Why use it?
• No need to clone the repo again
• No need to stash or reset your local changes
• You can develop, test, or review PRs in parallel
• Saves time and disk space
• Cleaner workflow

Example:
You’re working on feature/homepage-redesign but your teammate asks you to check hotfix/login-bug.

Instead of stashing everything:

git worktree add ../login-hotfix origin/hotfix/login-bug

Boom — a new folder opens up with that branch, while your original branch stays untouched.

🌀 What is Oh My Zsh? And Why Are We Talking About It?

If you use Zsh (default shell on macOS), then Oh My Zsh is like a power-up.

It’s a framework that adds:
• Useful plugins
• Completion
• Themes
• Shortcuts
• And… Git aliases that save a LOT of typing

Instead of typing:

git worktree add ../some-folder feature-branch

With the Oh My Zsh git plugin, you can type:

gwta ../some-folder feature-branch

Here are the key aliases for Git Worktree:

Alias	Full command	Meaning
`gwt`	git worktree	Base command
`gwta`	git worktree add	Add a worktree
`gwtl`	git worktree list	List worktrees
`gwtr`	git worktree remove	Remove worktree
`gwtp`	git worktree prune	Remove stale entries

To enable it, make sure your .zshrc has:

plugins=(git)

Reload:

source ~/.zshrc

And you’re set.

⚙️ Workflow Scenario 1 — Single-Repo App

Let’s say you have a normal project:

my-app/
  src/
  package.json
  ...

You’re working on a big feature:

feature/new-ui

But someone needs your help reviewing:

feature/navbar-fix

Instead of stopping your work:

➕ Add a worktree

gwta ../navbar-fix-wt origin/feature/navbar-fix

Now you have:

my-app/                  ← your main work continues here
navbar-fix-wt/           ← completely separate workspace

👇 Inside navbar-fix-wt/
• Open code
• Run tests
• Try builds
• Review changes

When done:

gwtr ../navbar-fix-wt

Back to your original branch, untouched.

🔥 Why this is awesome
• No stashing
• No losing uncommitted changes
• No slow clones
• You can have 3–4 worktrees open if you want

🏗️ Workflow Scenario 2 — A Monorepo with Multiple Apps

A common setup:

company-monorepo/
  apps/
    web/
    admin/
    mobile/
  libs/
    ui/
    utils/

Now imagine you need to:
• Work on web-app-feature
• Test something in admin
• Also prepare a PR fix for mobile

Instead of checking out branches back and forth:

1️⃣ Create worktrees for each branch

gwta ../wt-web-feature web-app-feature
gwta ../wt-admin-experiments admin-dashboard-refactor
gwta ../wt-mobile-fix mobile/login-crash

Folder layout becomes:

company-monorepo/           ← your main repo
wt-web-feature/
wt-admin-experiments/
wt-mobile-fix/

Each folder is:
• A checkout of a different branch
• Still shares the same .git data
• Fast to create (no re-cloning!)

2️⃣ Work in each independently

cd ../wt-web-feature
npm run dev:web

cd ../wt-admin-experiments
npm run dev:admin

cd ../wt-mobile-fix
npm run dev:mobile

Yes, you can run multiple apps side-by-side — perfect for monorepos.

3️⃣ Clean up when you’re done

gwtr ../wt-web-feature
gwtr ../wt-admin-experiments
gwtr ../wt-mobile-fix

🎯 Final Thoughts

Git Worktree is one of those features that feels small but saves huge amounts of time once you start using it.

Combined with Oh My Zsh’s aliases:
• Faster workflows
• Cleaner development environments
• No more “stash → switch → test → switch back” loop
• Perfect for multitasking across branches
• Perfect for monorepos where multiple apps run at once

If you work on anything slightly complex - frontend frameworks, backend services, monorepos (& ServiceNow apps in my case) - Git Worktree is a superpower 💪

Easy Callback, Promises, Async-Await

Prakhar Yadav — Sat, 28 Aug 2021 22:05:36 +0000

After having read about callbacks, promises & async-await multiple times in not so easy to comprehensions, I finally have wrapped my head around them.
And today I'd share it in simpler terms that I am able to remember & understand.

Callbacks

Callbacks are functions being passed as arguments. That's it. That doesn't satisfy you then read these one page articles (to arrive on same conclusion of course):

Promises:

functions that are not run sequentially. They are run when possible.

const fun = new Promise ((resolve, reject) => {
  if(<some condition>)
    resolve("some success message");
  else
    reject("some failure message");
});


fun()
  .then(msg => console.log(msg)) // some success message
  .catch(msg => console.log(msg)); // some failure message

Resolve is called to indicate & return success status of the Promise, & Reject is called when we need to show failure.

Once returned we need to handle the stuff as well right?

then() is used to handle the resolved state
catch() is used to handle the rejected state

See! Simple.

Async - Await

Just a wrapper around Promise. Async-Await use Promises in the background.
Why was this done?
Because sometimes developers tend to nest things up. Nesting Promises makes it difficult to write, read, follow & understand at one look.

So why not make it easy to read & understand.

const fun = async () => {
  await functionToPerformAsynchronously();
}

That easy. You can easily make any function run asynchronously, by appending a await before it. Just remember that await statement must be in a function declared as async.

And you know what! async functions are nothing but promises (well not really; they return promises).

Don't confuse yourself, just read along and find more detail in the links mentioned at the end.

Which is why you can do this:

const fun = async () => {
  await functionToPerformAsynchronously();
}

fun()
  .then(<whatever you want to do here>) //runs when fun() has run successfully and did not encounter any issue while it ran
  .catch(errorMsg => console.log(errorMsg)); // runs when fun() had some problem running. We can display the problem as an error message is returned & can be displayed like in this example.

Want to dig deeper?

Here are one of the best & easy to follow official Node documentation on each one of the three:

Determine the kind of Software

Prakhar Yadav — Fri, 27 Aug 2021 20:06:06 +0000

Iterative approach effect on prerequisite

Different kinds of software projects need different balances between preparation and construction.

(scroll to the Appendix at the end to see some good practices for common kind of software practices) 👇

Some projects need iterative & some need sequential approach.

A misinformed opinion is that iterative techniques don't need to focus on prerequisites.
However in reality, Iterative approaches only tend to reduce the impact of inadequate upstream work, but they don’t eliminate it.

Example table below compares 2 approaches with respect to prerequisites. Approach 1 relies solely on testing & discovers defects later, making the cost higher, and Approach 2 discovers defects iteratively as the project progresses.

Skipping Prerequisites	Focusing on Prerequisites

A focus on prerequisites can reduce costs regardless of whether you use an iterative or a sequential approach.

Most projects are neither completely sequential nor completely iterative. It isn’t practical to specify 100% of the requirements or design up front.

One common rule of thumb is to plan to specify about 80 percent of the requirements up front, and then practice systematic change control to accept only the most valuable new requirements. Another alternative is to specify only the most important 20 percent of the requirements up front and plan to develop the rest of the software in small increments.

How to choose between Iterative and Sequential Approaches

You might choose a more sequential (upfront) approach when:

requirements are fairly stable.
design is straightforward and well understood.
development team is familiar with the applications area.
project contains little risk.

You might choose a more iterative (as-you-go) approach when:

requirements are not well understood.
design is complex.
development team is unfamiliar with the applications area.
project contains a lot of risk.

Appendix

Table: Good practices for 3 common kinds of projects

Importance of prerequisites

Prakhar Yadav — Thu, 24 Jun 2021 22:15:12 +0000

Paying attention to quality is also the best way to improve productivity. We do this by adopting high quality practices which emphasize quality at the beginning, middle & end of the project.
Emphasizing quality at the beginning implies you plan for high quality product, require high quality product & design a high quality product.
Emphasizing quality in the middle of the project means emphasizing on construction practices.
Emphasizing quality at the end of the project means emphasizing on system testing.

Upstream activities, i.e. architecture, design, and project planning can be done well. Projects will run best if appropriate preparation activities are done before construction begins.
Goal of preparation is to reduce chances of risk as early as possible. Common risks are poor requirements and poor project planning. Hence preparation tends to focus on improving requirements & project plans.
(specific approach to risk reduction must be decided project by project).

WIMP syndrome

Lack of planning can often be attributed to team's leadership. This is often due to WIMP Syndrome of managers. Why isn't Mary Programming?

If your manager happens to be such brigadier general and orders you to start coding right away, it's easy to say "Yes sir!" But that's a bad response, and you have several alternatives:
i.   You can flatly refuse to do work in an inefficient order, that is iff your relationship with your boss & your bank balance are healthy enough.
ii.   (Ethically questionable) Pretend to be coding. Put an old program listing in the corner of your desk (or opened somewhere in your screen) then go right ahead and develop your requirements & architecture with or without your boss's approval. You'll do the project faster with better quality results.
iii.   You can educate your boss in terms of technical projects & how/why planning beforehand will be better.
iv.   Find another job.

Compelling & Foolproof arguments for doing prerequisites before Construction

This section will help you deal with bosses who have not seen the light yet. Learn the argument & then sit down with your boss for a heart-to-heart discussion.

Appeal to Logic - plan before building Big projects require more planning; small projects need less. From management point of view, planning means determining amount of time & people the project will need. From technical point of view, understanding what you want to build, so that you don't waste money/time/resources building the wrong thing. Sometimes users aren't entirely sure what they want at first, so it might take effort in finding what they really want. That's cheaper than building the wrong thing and throwing it away to start anew. It's also important to know how to build the system before starting to build it.
Appeal to Analogy - do things in the right order Building software is similar to any other project. If you make a house, you make architectural drawings & blueprints before pounding the nails. You don't start decorating a Christmas tree before putting it in a stand. You don't get dressed before you take a shower. You don't put on shoes before wearing your socks. Things need to be done in order. If any impurity is introduced in the beginning it'll contaminate the complete food chain. In programming, if your requirements are contaminated, they'll contaminate the architecture which in turn will contaminate the construction & hence will lead to radioactive polluted software along with a malnourished grumpy programmer. You don't want that.
Appeal to Data - speak stats for proof The principle is to find an error as close as possible to the time it was introduced. The longer the defect stays in software food chain, the more is the damage it causes further down the chain.

Time introduced x Time detected	Requirements	Architecture	Constriction	System Test	Post-release
Requirements	1	3	5-10	10	10-100
Architecture		1	10	15	25-100
Construction			1	10	10-25
Architecture		1	10	15	25-100
Construction			1	10	10-25

Table: average cost to fix defects based on when they're introduced & detected (units in multiples of $1000)

Measure Twice, Cut Once: Upstream Prerequisites - Introduction

Prakhar Yadav — Thu, 24 Jun 2021 21:35:32 +0000

Before you begin construction of software, you need to prepare for it.

And preparation is tailored to the specific project.
The carpenter's saying, "Measure twice, cut once" is highly relevant to software development as it is in any other form of craftsmanship. Doing the most expensive part of the project twice is a bad idea.

This chapter lays groundwork for construction phase, without discussing construction directly (which will be discussed in chapter 5). Here we will discuss various prerequisites before construction.

Here is the chapter's layout:

Importance of prerequisites: cost of not doing prerequisites
Determine the kind of software you're working on: how prerequisites apply to your situation
Problem-definition Prerequisites: recognize written problem statement & if it is a good foundation for construction
Requirements Prerequisites: importance of clear requirements & how to handle change in requirements during construction
Architecture Prerequisites: how to determine the quality of existing architecture
Amount of time spent on Upstream prerequisites: time management in upstream activities (requirements, architecture, design, planning)

Code Complete Mini Notes

Prakhar Yadav — Thu, 24 Jun 2021 20:39:33 +0000

What?

I have started reading one of the most recommended books for software development, Code Complete (2nd ed.) that suggests best practices in the industry and talks about development journey from A-to-Z. Covering almost all the aspects of software development philosophy. But have you looked at the size of it!!!?

Yeah! Get a load of this bad boy.

Why?

Due to day to day work not many of us get enough time to read a book, let alone a book of this volume. I often find myself wishing if only people would write the summaries of books that they had been reading. It would speed things up a bit and time restricted people can also catch up with many literature.

So I for one am starting a series on it. I will be capturing the notes that I make along the way in easy words that will make it quick for people to go through the crux of the book.

How?

I'll start with Chapter 3 (which is where the real stuff begins) at first and move along, since chapter 1 & 2 discuss the philosophies initially. I plan on covering them at a later stage.

Every post may be a subtopic of one huge chapter. The banner image of each post will highlight which chapter does the topic belong to, and also the 1st post that begins a chapter will have the 1st line as description of the same.

I hope whoever plans on reading this finds it easy & convenient. I'm open to suggestions on how this can be improved.

p.s. Don't worry, I won't be leaving out much part.

List:

Chapter 3: Measure twice cut once - Upstream prerequisites

Resources for enthusiasts - software dev. & cybersecurity

Prakhar Yadav — Thu, 17 Jun 2021 11:15:19 +0000

Hey folks. Tell me if this happens to you as well.
I find myself often torn up between my interests in web development and cybersecurity. I try to learn stuff in both the paths but it becomes very exhausting.
Sounds familiar?

When it comes to learning, multitasking is not really a friend. Better progress is made when we pick up one thing and achieve the target. But the FOMO (fear of missing out) on the other thing distracts too much.

To deal with this, I at least try to stay up-to-date on the latest developments, outside of my learning time, through podcasts, news-boards & twitter.

Here are my go-to resources for cybersecurity:

These podcasts and articles are the ones that help me & I hope you find them helpful as well.

Interview Prep suggestions & resources

Prakhar Yadav — Fri, 11 Jun 2021 22:01:09 +0000

I have had the opportunity to get in touch with some of the great minds and gather their advises when I was preparing to get in tech companies. And I want to hold the torch while others go through the same phase in their lives.
In this article I want to share my interview preparation experience and some resources for anyone who is or will be going through the same.

Interview is not all about coding, hence the preparation for the same should not be.

You have to take into consideration all the parts involved, like:
1. Coding practice
2. Presentation skill
3. Rejection coping mechanism
4. Your expectations
5. Questions you should ask

1. Coding Practice

When it comes to coding, my go-to source is Leetcode. This is simply one of the most preferred practice sites and it has everything that you need. There are certain topics that are must do to be worthy enough in appearing for interviews. Trees, Graphs and Dynamics Programming. These are the deal breaker in many interview. Mind you, these are the ones that one must know well, after one has gone through basic data structure problems (arrays, linked list, stack & queues).
I have climbed the stairs in this order:
Arrays -> LinkedList -> Stacks -> Queues -> Hash table -> Trees -> simple problems on Backtracking -> Dynamic Programming
In between I also covered some String problems as well.
You can select a topic. Solve 5 problems daily (10/15 if you're planning a rigorous prep duration). And move from easy to medium. It's easy to follow. Trust me. Don't be overwhelmed. You got this.
In only 2 to 3 weeks you'll get a hang of it and know how and where to proceed.
You should also keep track of top questions list. These are found on the right side column.

Oh don't forget this page This should be you one stop shop for the coding practice guide.
You'll find links to most preferred articles that'll guide you how to approach certain type of problems.

Like this article will build your understanding of Dynamic Programming problems & how to think about them.

2. Presentation

This involves your body language, behavior, asking questions, think out loud, how to proceed if you are unable to think of a clear solution.
Radiate positive energy. Stay hopeful and cherish the time you are having. Being nervous is natural. But I took this advise from Simon Senek.

Signs of being nervous and excited are exactly the same. Your hands may shiver & sweat. You feel that adrenalin rush. You are alert.

Tell yourself that you're excited, and soon enough you'll hack your brain into believing it.

Then comes the behavioral part. You don't need to be extremely formal. You can keep your conversation lite and fun, while being respectful all the time. After all you are talking to someone who might be your future colleague. And he's human too. Don't sweat it. I always keep conversations lite and push in some funny responses. This will help you too. Trust me.
You will literally hijack the conversation and keep it in your control.

Whenever you are given a problem to solve, don't dive into depths of your mind to find the solution. Stay in the moment. Ask questions regarding the problem.

What is the size of the input? Is it an integer or can it be a string as well? In which format do we want the output?

Think of the interviewer as a colleague/friend with whom you are solving this problem. Ask for hints if needed.

Think out loud. Be vocal while you think of how to proceed. This will help them understand how you approach the problem and how your brain is functioning.

Hmm.. I'm thinking of storing the pair in a set. That may help us in fast retrieval/finding whether we have seen this before during the traversal.

How to proceed when unable to think of a solution?
There might be times when you have a faint idea but are unable to arrive at exact solution. You can just go ahead and ask for hints. If that doesn't help, communicate that little idea that you're having.

I'm unable to think of a good or exact solution, but I know that this can be solved using memoization.

Or you may not have any clue of the situation. Convey that even after thinking you were not able to think of a solution, because what all you know does not seem to apply in this particular problem. Don't beat around the bush for too long if you don't know what's asked. The interviewer will know when you'll try to bluff.

3. Coping from rejection

It's not necessary that every stone you throw, will bounce off the lake. Some are throws are just for trial.
Consider that you tried your best. Note down the points that you were unable to tackle. Work on them the next day. If you face multiple rejections in a day, or back to back rejections in consecutive days, then take a break. Calm yourself down. Be in peace. Meditate. Listen to songs. And most of all, talk to people and your friends. Make fun of the situation if you can. Have a lite laugh.
Remember, it's a small part of you big life, and this too shall pass. Destiny will take it's course and you'll be somewhere that you are supposed to be. This might be the learning phase to get there.
Diamonds are made when coal is exposed to immense heat & pressure.
You got this. Let's enjoy this time while it lasts.

4. Expectations

While done with the technical part of the interview, remember to reflect on your expectations of the job & the employer's expectations from you. Ask them what kind of skills, performance and attitude they expect from their employees. Ask them how they treat the people who meet those expectations. Explain what you're expecting in turn. This will help you and your employer understand the kind of dynamics you might have and whether or not you'll be suitable for this position. You might feel that you should not go for this... then listen to that gut feeling as well.

5. Questions you should ask

Finally you made it through all the parts of the interview. Congratulations 🎊 😄
Remember to ask a few questions:

What does the average day look like for an employee here?

How is the workload?

Do you get time for your family and friends?

How are troubling situations handled like sudden failure that needs to be addressed right away?

Suppose in distant future if I feel like changing my domain, say from web development to cyber security. Is there a provision to entertain such domain change? How difficult is it?

What is the performance expectation from an employee?

Is it a 6 days work week or 5 days work week?

BONUS: Resources

Finally I'll mention some links to resources that were helpful for me while preparing for interviews:

Leetcode : for coding practice.
GeeksForGeeks : for CS subject concepts, Design Patterns, coding (some must do questions here).
Pramp.com : for free mock interview practice with friends.
Design Patterns lectures on Coursera.
System Design youtube playlist by Gaurav Sen.
Puzzles from GeeksForGeeks as well.
Aptitude problems from Indiabix.

4 Git Habits & curated list of life-saving articles

Prakhar Yadav — Sat, 05 Jun 2021 13:14:52 +0000

Hi folks.
In this post I want to share some tips and suggestions on common best practices for the method of work, that are not always explicitly stated/taught.
When we transition to a new environment, there's a certain learning curve involved before we get on with our work smoothly.
I struggled with my modus operandi and after tripping on many pitfalls, I think these tips might be of help:

Don't branch when you start working. Branch when need to push.
I've had situations where I faced merge conflicts due to early branching. You don't know how long its gonna take for you to fix that defect or complete that story. By the time you are ready to push the changes to remote repository, there might be significant changes in many files. And may be even on the one that you're working on. This is typically the case when many teams are working on a repository. Hence, always create a branch to push your code when you are actually ready to push.
Pull every morning. Keep the code base up to date
Branching off of the previous comment, keeping the code base up to date is ofcourse very essential, but the frequency is what matters. I had this question when I started in my new role "how often should I pull?"
The answer is every morning. Don't worry you won't lose your work. And if you're unable to, because of un-committed changes, then stash your things are apply them after you've pulled.
This way, you can lift-off from where you ended yesterday.
Always sign/author your commits, if you don't.
Although some organizations have some guidelines regarding this, but that might not always be the case. Even though the organization has a way to keep track of who's changed what, it's always advisable to author your commits.
I prefer ending the commit message with:
Reviewed by: Reviewer Name <email@addre.ss>
Signed-off-by: Your Name <your@email.id>
Squash all your commits into one once you're done.
This is something you must be aware of already. Squash all your commits before merging. This way all the code changes for a fix/feature are consolidated into one, and the whole thing is much clearly maintained and tracked.

These are the few things I learned the hard way. I hope you adopt these habits soon if you don't already.
Before signing-off, below are some guides and articles in Bonus section, that I find very useful & you might too.
And even though cats may rule this world one day, you are reading Code with P. 👋🐈

BONUS - Resources

Git Crash Course by eclipse/omr project at github.com
What is Git Stash, how to use Git Stash? by @Yuvaraj
Top 10 Git Commands Every Developer Should Know By @Muthu Annamalai Venkatachalam
Confusing Terms in the Git Terminology by @Pragati Verma
Most practical git commands in a real workflow by @Jing Gu
What is Commit Signing in Git by Seth Falco

10 things I learned in first 6 months as software developer

Prakhar Yadav — Fri, 04 Jun 2021 19:27:23 +0000

As I ease into my new job as a software developer, I thought I'd share some tips & advise that I wish someone told me before I started. This could have made my journey much smoother. But to anyone out there who needs this, here's what I learned after 6 months in industry.

Keeping clear of the egoistic Sherlock.

Don't stay stuck on a problem for too long.
Don't be afraid to ask for help. Because someone might have stumbled on a similar issue before.
Google is your best friend.

No matter what level of proficiency, the biggest part of the job is to look for solutions by asking the right questions.
Keep educating yourself about anything that you don't clearly understand. Even if you are slightly foggy, google it.
Community is called so for a reason.

Be active in any community you have exposure to. Be it StackOverflow, FreeCodeCamp, dev community on Twitter, or even any community platform that your company has (given you are in a job or an internship), look for similar issues if you are stuck or post questions on the platform, and see how helpful our dev community is for yourself.
Stay professional & don't take things personally.

Stay professional. Keep delivering. Show diligence. Don't become lazy or take things for granted. You are being paid for things you are doing. You are doing this for yourself. Respect your bread & butter.
Don't be angry or irritated by the workflow. Everyone is following the schedule that is feasible to them and your opinion on what or how they should do things does not matter and maybe is even rude. Believe everyone is doing their best, trust them.
Respect your time.

Do not keep on working day & night. Your profession is there to support your life and the others dependent on you. Take out time for yourself. Don't half-ass it. Work with your heart in it, and then shut the system down to relax and enjoy your life as well. You are more than your job. Remember that.
Take breaks.

It is very easy to get burnt out due to hectic schedules and workloads. You have leaves to treat it. Use it wisely. Replenish yourself. Use weekends to stay away from your system and give time to things that you enjoy. Meditate. Because it's the greatest favor you can do for yourself.
Do not overdo your daily goals.

It is easy to lose track of your activities amid so many meetings, and responsibilities. Set your daily todos. Keep the list small. This will give you a clear picture of the road you need to travel, give you an idea of how much time the tasks will take, how you should organize your day to finish them, and save you a lot of time. Keeping it small will also keep you relaxed. Trust me. I know.
Your head is not a notepad.

Do not keep a note of things in your head. As soon as there is something that needs to be done, note it down. If there a meeting you need to attend, set a reminder for it? You have an event to be present in, keep track of it in the calendar. Flush your buffer as soon as it is filled, so that you can focus your energy on actual work and problem solving that you want to do.
Help others.

Can not stress this enough. Help the ones in need. If you have finished your things earlier, reach out to people and help them in things they are doing. Don't worry they won't give you much. Even a feeling of someone being present to help, gives tremendous relief, morale boost, feeling of joy, and speedy completion of tasks. You'll build a great rapport and a good network of people always ready to help you in your hour of need.
Note all that you do.

This may not apply to everyone, but I have found this very helpful to jot down every change that I make. I typically follow this tabular format:

Entity (widget or any feature) File changed The change itself (codes)

This way I can keep track of the changes that I am doing, quickly navigate them and refer similar things that I have worked on in past. This is a great time saver. It's a lot easier than it may sound. Do it. Don't argue. You'll thank me later.
p.s. I use OneNote to jot down any & everything.

BONUS

Learn to say No.
If your schedule is cluttered and you are on the verge of plucking your hair out, then you don't have to take everything that's asked of you. You should however be very gentle and polite in rejecting. Do not reject someone's request right away. Ask yourself are you that occupied. Then after due consideration, let them know that you are already working on such & such and suggest to them who can they reach out to instead. They are here because they need help or they are your manager 😂 either way they'll understand and not bother you with the load.
DO NOT misuse this power.
Believe in yourself
Don't run from problems to solve. The harder the problem the proficient you get. Believe you can do it. Spend some time researching it. Ask for help. Trust the learning curve. Don't let things scare you.

Why not to use Carousels

Prakhar Yadav — Fri, 28 May 2021 14:26:32 +0000

Carousels are those slide shows of content that can be seen across the web. You must have encountered some in the form of areas that can have informational content or promotional content or even ads. Even though they are vastly adopted, they aren't a very elegant thing on your website as they lead to accessibility issues and ultimately a bad user experience.
Take voiceover users for example; when the slide changes the content of the slide may be announced all of a sudden and the user surely will lose the track of elements they were interacting with (where the cursor is original).
And what if there's no proper implementation of auto-rotation of the slides.
Don't even forget about the navigation with tab and arrows. The user navigates the whole page with tab key, and then the slides are navigated with arrow keys all of a sudden?

These and many other cases surrounding the carousel, in turn, would lead to a chaotic user experience and a confused user.

A good carousel is no carousel.

Though the carousel consolidates the content in a specific region, a thorough discussion with designers, UX-engineers, and developers an alternative to carousels can be found for the teams that originally intend on implementing the carousel.

And even after all my arguments and various discussions if you just can't resist the temptation then here are some example implementations to consider:

Remember to refer to the WCAG guidelines when working on carousels. Here are some other enlightening links that you may find helpful:

Even though kittens love attention, carousels are not the best way to do that. 🙋‍♂️ 🥂