*How AI changed my job from writing code to reviewing it, and why that’s the biggest culture shift I have seen.*

I’m a software engineer at LinkedIn. I build Observe — our unified observability platform that consolidates metrics, alerting, SLOs, tracing, logging, profiling and incident management into a single UI. It’s a React + TypeScript + MobX frontend backed by a Go API, and it’s the kind of complex, high-stakes codebase where a bad merge can blind engineers to production incidents.

Not long back, hardly few months ago, I spent most of my time writing code. Today, I spend most of it reviewing it. Not because I got lazy — because the code is being written by AI, and my job shifted to something harder: making sure it’s *right*.

This is what that looks like in practice.

- -

## The Loop Changed

The old loop was: think → write → test → PR → review feedback → iterate.

The new loop is: think → prompt → review → refine → prompt again → review harder → ship.

Notice what moved to the center: **review**. I went from being the author who occasionally reviews peers’ work, to being a full-time reviewer who occasionally writes a prompt. On most days, I write more review comments than lines of code.

And here’s the thing nobody tells you: reviewing AI code is *harder* than reviewing human code.

When a colleague sends a PR, I can pattern-match against their style. I know their tendencies — Eg. John over-abstracts, Jane forgets edge cases, Mark writes beautiful code but skips tests. AI has no personality to pattern-match against. Every PR looks competent, complete, nearly perfect. The code compiles, the tests pass, the variable names are reasonable. But underneath, it might be solving the wrong problem, using the wrong pattern, or introducing a subtle dependency that’ll bite us in three months.

So I had to get systematic about it.

- -

## Teaching the Machine What “Good” Looks Like

The breakthrough wasn’t just getting better at prompting. It was **encoding our standards into files the AI reads before every task.**

We have three layers:

1. **Always-on rules** — files that load into every AI session automatically. Things like “no console.log — use structured telemetry”, “prefer CSS variables over preprocessor variables”, “never bypass pre-commit hooks.”

2. **Task-specific skills** — detailed playbooks for specific workflows. When the AI needs to write a unit test, it reads our testing skill. When it creates a PR, it reads our PR skill. These aren’t vague guidelines — they’re precise, opinionated instructions with good/bad examples.

3. **Architecture docs** — the AI reads our architecture file to understand how the application is structured, where services live, what patterns we use.

The result? The AI’s first draft is already 80% aligned with our conventions. My review work dropped from “rewrite this” to “adjust this.”

Let me show you what these look like in practice.

- -

## Skill #1: The PR Review Playbook

We wrote a skill that acts as an automated code reviewer. It knows our testing anti-patterns — things like mocking at the wrong layer, using brittle CSS selectors in E2E tests, or relying on hardcoded waits instead of proper assertions. It knows our backend conventions — where business logic should live, how errors should be structured, what good observability instrumentation looks like.

Every rule in that skill exists because we shipped a bug or wasted a review cycle. One mocking pattern alone caused three broken PRs before we encoded the fix. Now the AI catches it before I even see the code.

If you’re repeating yourself to the AI, stop repeating and start encoding. Turn your tribal knowledge into a file the AI reads on every task.

- -

## Skill #2: The “Minimum Change” Philosophy

This is the rule I enforce most during reviews: **only make changes that are directly requested or clearly necessary.**

AI *loves* to over-engineer. Ask it to fix a null check, and it’ll refactor the entire component, add error boundaries, create a utility function, and write documentation for a helper nobody asked for. A bug fix doesn’t need surrounding code cleaned up. Three similar lines of code are better than a premature abstraction. Don’t add error handling for scenarios that can’t happen. Don’t create helpers for one-time operations.

We encoded all of this into our project-level instructions so the AI reads it before every task. The most common review comment I still write is: “Revert this — it’s not what we asked for.” But it went from every PR to maybe one in five.

Senior engineering isn’t about writing sophisticated code. It’s about knowing when simple code is the right answer.

- -

## What I Actually Look For Now

My review checklist for AI-generated code is different from my checklist for human code:

**1. Does it reuse what exists?**

AI has a tendency to create new utilities when perfectly good ones already exist three directories away. I check if there’s an existing function, hook, or component that does the same thing.

**2. Is it the minimum change?**

Did it touch files it didn’t need to? Did it add type annotations to code it didn’t change? Did it sneak in “improvements” to neighboring code? Every unnecessary change is a risk surface and a review burden.

**3. Does it follow the unwritten rules?**

Every codebase has conventions that aren’t in the docs — store patterns, service layer idioms, CSS conventions. AI gets these right *only if* we’ve encoded them. When it doesn’t, that’s a signal to write a new rule.

**4. Would a new team member understand this?**

AI code often has an “uncanny valley” quality — it looks right but feels off. Variable names are reasonable but not what a human would choose. The control flow is correct but not idiomatic. I optimize for readability by someone who’ll maintain this in six months.

**5. What did it change that I didn’t expect?**

I always check the diff summary first. If task description asked for a 3-file change and see 12 files modified, something went wrong. Start with the unexpected files.

- -

## What I Got Wrong Early

**Trusting “it compiles” as a quality signal.** AI code almost always compiles and passes basic tests. That’s table stakes, not quality. The bugs are in the design choices, not the syntax.

**Not investing in skills early enough.** For months, I wrote ad-hoc prompts. Every session started from scratch, and I repeated the same corrections. The moment I started encoding rules into files, my review burden dropped by half.

**Reviewing AI code the same way as human code.** Human PRs have intent you can read between the lines. AI PRs have no intent — they’re executing a prompt. Review the prompt *and* the output. If the skill is wrong, fixing individual outputs is whack-a-mole.

- -

## The Uncomfortable Truth

Here’s what I’ve come to believe: the hard part of software engineering was never typing the code. It was knowing what to build, how it should work, and whether the result is good enough to ship.

AI made the typing part nearly free. What it didn’t change — what it *can’t* change — is the judgment layer. Is this the right abstraction? Is this change safe to ship? Will this scale? Will the next engineer understand it?

That’s what senior engineering is now: taste, judgment, and the discipline to enforce standards at scale. The engineers who thrive aren’t the fastest coders. They’re the fastest *reviewers* — the ones who can look at AI-generated code and, in minutes, decide whether it’s solid or subtly wrong.

I write less code now. And that’s the most senior thing I’ve ever done.

- -

*Next up: I’ll write about how to build these “skills” — the machine-readable rules that teach AI agents your team’s standards. Stay tuned.*

Hi, it’s been a while.

Today, I want to talk about how to go about writing a promotion document at a tech company.

A developer’s life is a full cycle with all types of work, ranging from BAU feature development asks to keep the business running, KTLO/Oncall, critical security tasks, platform maintenance, and even trivial work such as changing the color from red to blue.

Over a 1–2 year period, it is crucial to get your work recognized. Everyone likes to be rewarded in the form of appreciation, promotion, or increased pay. In practice, it gets complicated as some work has high impact but low visibility, while some work involves just a few lines of code but has a huge impact on the business. It is natural to forget or not mention fuzzy work done over the cycle.

I’ll discuss the template one can follow to create performance review document and how to go about structuring it.

1. Goals agreed for the last cycle

You need to align your focus areas for the upcoming year or cycle that you’re aiming for. Agreement needs to happen between you and your manager on the expectations from the current and next role. This way, there would be no surprises at the end of the cycle. Depending on the seniority of the role, goals should have a proper mix of business asks, KTLO, making Oncall process easier, platform, alerting/monitoring, identifying and fixing tech debts, web performance, knowledge sharing with the group, mentorship, library upgrades, etc. These are just some things on top of my mind which I have listed. One need not do everything, and it depends on the role and company. The idea is to have a fine mix.

2. Your accomplishments

After goals are listed, now focus on what you achieved and how you achieved it. I break this section into two parts.

1. Major goals — What was expected and mostly listed above.
2. Additional achievements — Raise the bar. These are core-tech bottoms-up projects you picked up.

Major goals

The following template works well in bullet points for all accomplishments:

• <Task Title> <JIRA Epic/Brief description> <Impact Metrics> <Solutioning Doc (LLD/HLD/test cases if present)>

This way, in a single line, you can provide all the important information for a project. We tend to skip fuzzy tasks or small items, but you can group them in 1–2 line items and attach JIRAs. Be sure to include them. No work is small; all types of work are required to keep the business running. (It is OK to ask your PM or EM to provide business/product metrics for the work you have shipped.)

Additional achievements

For example:

• 80% reduction in Sentry (Logger for UI) error fixes from 220K/hourly events to ~40K/hourly events. [JIRA ID, Solutioning Doc link]
• Preprod stability: Helped and drove different environment setups across different teams in the org. This ensured 100% dedicated availability for the stage environment.

3. How I worked with others

Stakeholder management, mentorship, helping and guiding peers through knowledge sharing, onboarding new joiners, code reviews, and design reviews are critical for a senior role.

• Instances of onboarding new PMs to the engineering side of things. Attach KT docs, etc.
• Instances of PR reviews where more than expected time was spent:

1. [PR_link1]: Pointing out better quality and modern code that doesn’t do what they are expected to do.
2. [PR_link2]: Pushing back on an inbound, low-quality code change coming in from another team.
3. [PR_link3]: Giving feedback to John on our coding style and performance. (Note: I later followed up in-person.)

• Mentorship for interns -> SDE1/2s. How they are now independent developers thriving and performing.
• HLD/LLD/Roadmaps for big projects with proper breakdown — <Links>

4. Levels and competencies assessment

Each level has some expected competencies defined. It could depend on company size, team, manager/HR discretion. Some companies have it documented; if not, you can always discuss this with your manager in a 1–1 meeting. In this section, based on the expected competencies, one needs to list the achievements. Here are some sample sections and examples:

Overall

I focused a lot on this area and made significant progress, exceeding expectations at my level. I am curious for more feedback and observations.

Software engineering

Drove and led end-to-end cycles of software engineering with true spirit and efficiency, meeting standard practices and guidelines.

Domain Knowledge & Tech Complexity

– Expertise in the domain

– Common solutions

– Tech debt reductions

– Contribution to documentation, gaps analysis

– Web performance improvements

Org Building & Collaboration:

— Evangelize across teams to improve product and tech efficiency.

— Mentorship

— Interviews/Hiring contributions

— Collaborations, testimonials, and relationships within and outside the team.

Execution & Operational Excellence:

— Domain expansion

— Started to add value in scrum ceremonies (demos, sprint planning, daily scrum, backlog grooming)

— Task breakdowns and Say:Do ratio

Results and impact

I’ve been prioritizing business results, and the impact shows. All key projects were shipped on time or before.

Citizenship

I spent a lot of time mentoring and onboarding others. I did not put additional focus on this area external to the company, though.

That’s all.

Today marks one amazing year with Flipkart. I got great news yesterday that I have been promoted at work to UI Engineer II. I want to reflect on the work, journey, learnings and take-aways from the last one year.

The Big Billion Days 2019 was around the corner when I joined, and the atmosphere was ecstatic. Floor was lit, occupied meetings room, people entering office at 8PM and leaving 5AM, while some coming at 8AM and staying late as well. One could not make out what are the ‘official working hours’.

I could sense and feel for the first time, it takes a lot and lot to pull up the biggest Indian Sale. I was a mere spectator in the war rooms, issues to be taken care of, meetings and dry-runs. Well those 5 days were amazing, and then came a cool off period.

I was waiting for my first gig and make my hands to go dirty with code! 😁 😎 I joined Marketplace Engineering which handles Seller Platform for Flipkart & 2Gud seller. Seller Listings Management ( SLM ) and Seller Settlements ( SSM ) were the teams I have to work with.

SLM is responsible for sellers to list products, maintain inventory, pricing from over 800M listings. SSM is responsible for seller payments. Both being transactional systems, it was extremely critical team for the Marketplace team, and that’s what I wanted. 😇 Tech stack is React + Redux mainly. Well you cannot avoid tech debt, and we too had it with some of the legacy code in Blinx ( an in-house framework by Flipkart, later open-sourced — https://github.com/blinxjs/blinxjs ). I was new to React as in my previous company I worked with Angular. Well, remember my idle time during BBD, that’s when I learned React & Redux. 😛

I had two experienced peers with me in UI, from whom I did learn about the codebase, KT sessions, deployments, github processes, etc. Well, one shifted to other team and while the other left in 3 months. So, I was the only one left in both the teams. ( Too overwhelming, I know 🤤 ) Was lucky to have a proactive PM with good features to work with for an UI Dev like me. Delivered two long awaiting features in span of 3 sprints. Well, NO production bug was the highlight.

A college fresher joined in, with no background in UI. With resource dearth in UI, we got him in UI to get started with. I got a chance to mentor him and prepare a roadmap to get started with UI. Well, it reminded me of my college 3rd year, when I started with it. Mentoring is full-time responsibility in starting. Constant pings, resolving doubts that may be too trivial to few, guiding along tests your PATIENCE to the core. Being calm and how to simplify a solution to a beginner is something I would take away as a key learning.

Later, I was profoundly involved with BAU tasks, released many features to improve seller experiences, and learning curve was exponential… and then kind of stuck.

I wanted to spend time on tech debts. Remember legacy code I talked about, so I migrated 1/3 to React. It was good experience as to migrate a code from language A → B, it is mandatory to understand A as well. Next up, I checked up package.json with heed of what all packages we import. Then I found styled-components needs an upgrade. A major one, from v3 to v5!
With only UI dev in the team, and my team being responsible for BAU work, bandwidth was an issue and timelines were in a crunch. So, I took it as a moonshot goal and made it like my own (personal) project to finish it. Huge learning, as we moved up to two major versions in a go, going through the release cycles for a library, noting down what/what-not changed, making sure to inculcate and handle the breaking changes. Regression cycles were countless. Change -> Test -> Deploy -> Repeat.
Make the migrations a smooth ones across a huge piece of code in a go was a challenge I gleefully overcame. Reduction of 13KB in bundle size was the reward except the learnings that I took with me.

I was made part of one more team — Flipkart Promotions. Here, sellers lists and manages all his offers that s/he wants to take part in which eventually move ahead to upstream systems and finally show up on Flipkart.com We had to launch Pre-Order feature, where customer can pre-order an item before the sale begins with assuring lesser price than Sale, guaranteed stock and faster delivery. As this involved over 10 teams across FK, I gained an understanding of how important stakeholder management, execution and collaboration skills are. Had to work with teams that I have never met or known. WFH setup did made it worse and more challenging to deliver this successfully. However, with team support and joint effort, it was a success in Independence Day Sale and we are ready to launch it in full flow for BBD 2020 which is just around the corner.

Today, 11th September in a monthly MP meeting, Promotions were announced. I was lucky enough that my work was recognised and made it to the next level in a day lesser than a year.

Looking forward to make it worth it! Cheers 🥂 .

Let’s connect at Twitter.

Hi, I am Kanishk, a Frontend Engineer.
Frontend Development is a lot easier now with evolving frameworks, libraries and just plug n play of modules than some say it was 5–10 years ago. With huge demand in React, it’s not surprising for college graduates or one looking to switch into Frontend Development are trying to master it.

With speedy world and evolving tech, no company can avoid using frameworks for development. Still, companies test knowledge of plain JS before hiring you.

In my limited knowledge, companies like MS, Amazon, FK which are known for their solid tech, rarely take into consideration in the stack you worked for if one is applying for beginner, intermediate level. It doesn’t really matter if you worked with Angular and job is for Vue.js developer.

With any MOOC you take or even in the docs of Angular/Vue/React, it assumes you to be thorough with JavaScript.

Do you really understand JavaScript?

For example,

• Angular comes up with built in router library, which makes is so simple to link and navigate between components. Have you considered implementing it on your own? Forget implementing, have you given thought about how does it work? I didn’t, before I was forced to think over it.
• With JSX in React, one can use .map operator to iterate over the payload given it’s an array and just populate the UI. What does .map do internally? How does it magically takes the array and run any operation on it and produce the result. One line, and done.
• With loops in vue.js, one could use v-for in HTML itself. Just like a traditional for loop. It can’t get simpler. Get in response, and your UI is ready to render.
• Even VSCode is written with JavaScript.

Eventually everything is JavaScript!

Knowing how things are working behind the hood, would definitely makes one a better developer. One can optimise for performance better. Get into the mode of developing using plain JS to learn and grow. Get back to roots.

However, question is what triggers you to learn about it?

Alternatively read at my blog:
https://kanishkagrawal.netlify.com/vanilla-js-projects/

An Assignment for an UI Developer is generally the round taken before the actual interview. The candidate is judged on his coding skills, whether he is using best practices, approach to the problem, and completeness of the solution in the given time frame.

I will discuss 7 projects one can practice to be confident with Vanilla JS. These would make you quite confident before appearing in an interview. Make sure to use Vanilla JS. Use promises, closures, fetch API, MVC architecture, ES6 class based setup.

1. Todo App

It can’t get simpler than this. Perfect app to start with. Don’t forget to use localStorage to persist state.
Comprehensive Guide: https://github.com/dwyl/todo-list-javascript-tutorial

2. Event scheduler ( like Google Calendar )

Create a calendar interface similar to google calendar. One may be able to change the view from day, week to months. User should be able to add, remove the event.

3. Tasks management app like JIRA, Trello

Comprehensive Guide: https://medium.com/appcoda-tutorials/building-trello-like-ios-app-with-drag-drop-api-alfian-losari-d76534529f0f
Learn how dragDrop events work: https://www.youtube.com/watch?v=C22hQKE_32c

4. Tic Tac Toe game

Comprehensive Guide ( Youtube ): https://www.youtube.com/watch?v=P2TcQ3h0ipQ
Comprehensive Guide ( Codepen ): https://codepen.io/vasanthkay/pen/KVzYzG

5. Rock, Paper & Scissor game

Comprehensive Guide ( Youtube ): https://www.youtube.com/watch?v=jaVNP3nIAv0

6. Image search engine using open GIPHY API

Problem statement: Using the following API, display the GIFs based on user’s search result.

API end point: https://developers.giphy.com/branch/master/docs/api/endpoint/
One should implement debounce, pagination, maybe infinite scroll! You’re free to fancy whatever you like. This has lot of scope to learn.

7. n-th level Commenting Widget like Facebook

Problem statement: Build a nested comment widget system like the one in Facebook, Twitter. User could reply, like, unlike, delete, edit a comment upto any level.
Demo: https://bootsnipp.com/snippets/ZkexO

Ace the UI Tech round: https://bit.ly/2kwXTYS

Feel free to discuss any of the above problems.
Thanks, happy to help!

Feel free to reach out to me on Twitter or Linkedin.
https://twitter.com/KanishkAgrawal
https://www.linkedin.com/in/agrawalkanishk3004/

Alternatively read at my blog:

Ace The UI Tech Round

Hi, I am Kanishk, a Frontend Engineer. Sharing my experiences with recent stints interviewing at top product based companies in India. There are innumerable blogs, videos covering in depth with most probable questions. I will attempt to highlight my experience with what the interviewer is looking for and how you can ace it up.
Practice apps for UI Task round: https://bit.ly/2kvmNIl

UI Task Round:

Typically an UI assignment which could be a home-takeaway ( 2–3 Days ) or to be done in company premise ( 2 hours ). Companies like Amazon, MS, Flipkart, GoJek Tech and the likes start their interview processes with this round.
This is the best time to showcase your skill without any pressure. You can impress an interviewer with just little preparation. I would recommend to refrain using any library/framework, as the person evaluating may not have prior experience with the framework. Some companies explicitly force you to use Vanilla JS only. Even they not, Vanilla JS is the way to go in this.

• Use DOM efficiently.
• Small things can make it large impact.
• Use ES-6, classes in Javascript.
• Prepare a scaffolding before hand. Mostly companies allow you to use your laptop.

Divide your code in MVC structure.
index.html would just reference to main.js . model.js should be responsible to get and set data.view.js should render view. It should call controller.js for all the events bound to UI. controller.js should hold the definition of events and should call model to set data, which eventually should re-render the view.

In main.js , one could you use -IIFE,
DOM events,
promises,
ES6 import, export,
use strict,
event capturing,
local storage
to impress the interviewer with almost zero effort.

Practice fetch API calls. How to read and manipulate response. Use promises. You do not want to waste your time googling it about. You would be asked to maintain the state of the application typically on refresh. localStorage is the way to go. Make sure you have done it before. How to stringify the API response and parse it to JSON while reading from local storage.

Wonder how JIRA, Trello works?
dragDrop events. I bet not many would know about it. Practice a small app with those events. They are exciting to the first timers. https://www.youtube.com/watch?v=C22hQKE_32c from Brad Traversy would help to get started.

ES6 should all over your code. Refrain from using non ES6 syntax. Pitch in map, reduce, for of , for in loops .

This is the index.html of the full fledged application.

Notice the meta tags. Each have their own meaning. Read about them. You could be asked about that.
Why do we need script type="module" ?
Advanced Reading: https://ponyfoo.com/articles/es6-modules-in-depth

Use Javascript to build your UI. This is something is not mandatory, but a good to have thing which shows your confidence in Javascript. Not everyone can effectively manipulate DOM. I would never forget the reaction of my interviewer when I did so, it definitely got me those extra brownie points. It just takes some practice and you’ll be good to go. It is just that we are just too much used to HTML, else almost everything can bee achieved with JS as well. See those <header> and .loaderYou could have CSS for them before hand.
And yes, with loader you can have an excuse to show that you know how to use keyframes to leverage animations.

How will you efficiently construct the DOM tree? How would you make sure while appending children to DOM, you do not reconstruct the DOM? document.createFragment is the way to go. Make sure to use it.
Further reading: https://developer.mozilla.org/en-US/docs/Web/API/Document/createDocumentFragment

Listing few things to take care which are on top of my head.

• Avoid console.logs / debugger in final submission code.
• Make sure you are comfortable using handling click, hover events.
• document.querySelector over document.getElementById . And you should know why.
• Indent your final code. Install Prettier in VSCode.
• Use let, const. Avoid global variables unless required.
• Camelcase for function names. hyphen separated for CSS names.

Practice building 3–5 apps purely in Vanilla JS and you’ll be good to go.
Let me know, if you wish to know about other rounds as well.

Thanks, happy to help!

Feel free to reach out to me on Twitter or Linkedin.
https://twitter.com/KanishkAgrawal
https://www.linkedin.com/in/agrawalkanishk3004/

📝 Read this story later in Journal.

👩‍💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.

<iframe> have been responsible for embedding pages for us till now, though there are many challenges associated with it mostly related to data sharing or navigating through web pages, cost associated to browser re-rendering the component again. For those who have used <iframe> a blank white screen is commonly seen, that glitch definitely do not enhance UX. Due to security reasons, iframe didn’t allow us to navigate into its content, with portals, one cannot only embed page, can also navigate to to their content.

<portal> allow users to navigate inside the content they are embedding. Portals are always created as top-level browser context, and can always be embedded into a page just like iframe. They are basically an upgrade over iframe. With portals, one can prefetch the content and create an illusion of smooth navigation when called upon. Portals can also overwrite the existing URL address bar, making it more powerful to be used for navigation.

Portal can be activated, which causes the top-level browsing context to navigate, replacing its document with the portal. The document receives an event when it is activated. It can use this event to receive data from its predecessor (the document which previously occupied the tab), and even move it into a portal context.

Further reading for specs: https://github.com/WICG/portals

Thanks!

What is a style guide?

• A style guide is a set of standards that outline how code should be written and organized.
• A style guide contains general rules about “how to write” code, e.g. which quotes to use, how many spaces to indent, where to put line breaks, etc. A lot of minor things.

Why a style guide is must?

• Each developer writes code differently. That’s fine, until we are working on our code.
• As count of developers increase 5->10->20->50, things get messy when all are working on common codebase.
• Style guides are created so new developers can get up to speed on a code base quickly, and then write code that other developers can understand quickly and easily!

“All code in any code-base should look like a single person typed it, no matter how many people contributed.”

AIRBNB STYLE GUIDE

In the blog, I have only included not-so-common practices for a Javascript developer. This would give you an thorough understand about What and Why in Javascript? For 100% complete guide, one must check out the link at the bottom.

Let’s get started.

Expected style in casing for Javascript and CSS:

• CSS: hyphens
• JS: camelCase

• CSS class names should be hyphen separated.
• Either use hexcode or rgb standard for color scheme throughout your application.
• Avoid using px, rem, em at once Choose one. Prefer em.
• font-weight: 400 ? What good is it for? Eliminate useless CSS.
• Read about mixins for SASS.

Strings in HTML vs JS

• Double quotes in HTML
• Single quotes in JS

When using multiple selectors in a rule declaration, give each selector its own line.

Object.assign( ) v/s {…}

First case not only mutates the object, would also lead to unforeseen errors and bugs. Well third wins over second over leaner code and added syntactic sugar.

Read more about spread operators : https://bit.ly/2vEsnKq

Do Not mutate an array

No more for loops are required to copy the items of an array. Three dots would do the trick.

Group your shorthand properties at the beginning of your object declaration.

Makes it simple to read and make decisions. Makes things simpler in a complex nested object structure.

Destructuring

Template literals bridges not only HTML and Javascript, also must be used for above case. We do pass an object consisting of n keys to another function (say), destructuring the keys in the function declaration would not only make code less to error prone, would also avoid making temporary unwanted variables(first case). Adds readability , as can be seen in the third case.

DO NOT break a loooooooooooong string

Simple reason. Makes code more searchable & easy to work with. First and second case eliminates the possibility of searching the code. Adding / or + would put an end to code readability.

Use template strings for string concatenation

Unarguably one of the best ES6 features. Must STOP using any of the first three ways.

• Easy to read
• Simple to implement
• Concise syntax

Always put default parameters last

Write concise and leaner arrow functions

• Parenthesis are not required if only single parameter is there in a function call. More than one, parenthesis are must.
• return statement can be avoided with curly braces if only one line is present in the function body.

Wrap in parenthesis if expression spans in multiple lines

• For better visibility where our function starts & ends
• Clear to read

Object direct access over computed access.

In my experience,

• Less prone to errors
• Faster
• Know what to expect

Interesting

• Shortcuts ONLY for booleans.
• Explicit comparisons for Strings & Numbers

No nested ternaries

• It is OKAY to write long control statements.
• AIM should be to make it readable for future developers instead to write short & difficult to understand code.

Control statements

• If control statement gets too long, each grouped condition should be put in new line.
• Logical operator should begin the new line.
  - Follows a similar pattern for chaining.
  - Improves readability, easier to understand logic.

Comments

• Use /* */ for multiline comments instead of //
• Place single line comments above subject of the comment and start comment with space.
• Use FIXME to annotate the problems
• Use TODO to annotate the solutions

Do not quote ‘’ keys in the objects

Single quotes in the keys for an object are not required. Hence, should not be used.

Spaces in brackets || parenthesis

• Add spaces in Curly brackets
• No space in square brackets and parentheses.

What could make a better codebase?

• Use spread operators over Object.assign
• Use spread operators to copy the arrays instead of looping through.
• Exploit array operations to the fullest. [ every, some, filter, reduce, map ]
• Avoid return statements for one liners arrow functions
• Acronyms always should be in capitals. ( Eg. HTTP, SMS )

Did I miss something? Let me know in the comments.

Thanks.

Complete guide: https://github.com/airbnb/javascript

Airbnb Javascript style guide — Key takeaways was originally published in Docon on Medium, where people are continuing the conversation by highlighting and responding to this story.

function myFunction(x, y, ...data) { //REST OPERATOR
console.log(x); // "a"
console.log(y); // "b"
console.log(data); // ["c","d"]
console.log(...data); // "c" "d"
}

var arr = ['a','b','c','d'];
myFunction(... arr); //SPREAD OPERATOR

Now let us try and understand what just happened here! Starting with the formal definition for Rest Parameters & Spread Operators.

Rest Parameters

It allows us to pass any number of arguments as an array. It is pretty helpful to write clean and non-repetitive code.
As in above example, prefixing ... on data allowed us to pass extraneous variables ( c & d ) to pass an arguments. Obviously only the ‘last’ parameter can be a ‘rest parameter’. If you try otherwise in console,

function myFunction(x, ...y, data) { 
console.log(x);
}
var arr = ['a','b','c','d'];
myFunction(... arr); 

Above would throw the ERROR as
Uncaught SyntaxError: Rest parameter must be last formal parameter

Spread Operators

According to MDN:
Spread syntax allows an iterable such as an array expression or string to be expanded in places where zero or more arguments (for function calls) or elements (for array literals) are expected, or an object expression to be expanded in places where zero or more key-value pairs (for object literals) are expected

Simply put, Spread syntax is super useful to expand elements of an array expression or a string. It also makes joining of arrays neat. Let us take an example.

const a = ['Hi'];
const b = ['How', 'are', 'you'];
const c = [a,b];
const d = [...a , ...b];
const e = [...a, 'John', ...b];

console.log(c); // [["Hi"], ["How", "are", "you"]]
console.log(d); // ["Hi", "How", "are", "you"]
console.log(e); // "Hi", "John", "How", "are", "you"]

Same can be done to get each character from a string as well.

const string = "javascript";
const character = [...string];

console.log(string); // "javascript"
console.log(character); //["j", "a", "v", "a", "s", "c", "r", "i", "p", "t"]

With ECMAScript 2015, spread operator makes operations like cloning and merging an object also easy.

const obj1 = {a: 1, b: 2};
const obj2 = {c: 3, d: 4, e: 5};

const obj3 = {obj1, obj2};
const obj4 = {obj1, ...obj2};
const obj5 = {...obj1, ...obj2, f: 6}

console.log(obj3);

//  {
  obj1: [object Object] {
    a: 1,
    b: 2
  },
  obj2: [object Object] {
    c: 3,
    d: 4,
    e: 5
  }
}

console.log(obj4); 

// {
  c: 3,
  d: 4,
  e: 5,
  obj1: [object Object] {
    a: 1,
    b: 2
  }
}

console.log(obj5);
// {
  a: 1,
  b: 2,
  c: 3,
  d: 4,
  e: 5,
  f: 6
}

console.log(obj4); 
console.log(obj5);

Cloning:

let obj1 = { a: 1};
let obj2 = { ...obj1}; 
let obj3 = obj1; 

console.log(obj2);
// {
  a: 1
}

console.log(obj3);
// {
  a: 1
}

obj1.a = 100;

console.log(obj2);
// {
  a: 1
}

console.log(obj3);
// {
  a: 100
}

I hope it helps, thanks for reading!

Three dots in JavaScript : Spread & Rest Operators was originally published in Docon on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ever happened that your Angular code runs perfectly in your local machine and fails in build for deployment. Well, if yes then this post will help you out to avoid unexpected ERROR while prod build.

Angular Compilation

Angular offers two types of compilation.

1. Just in Time (JIT) compilation

JIT compilation is the default when you run the build-only or the build-and-serve-locally CLI commands.

ng serve
ng build

2. Ahead of Time (AOT) compilation

For AOT compilation appending - -aot flag is required.

ng serve --aot
ng build --aot

Why Angular needs Compilation?
As Angular offers HTML templates and components with it which are not understood by the browsers directly. So , any of the above two type of compilation is required before they can run in a browser.

What different does AOT do?

During the build phase and before the browsers runs and downloads the code, the ‘HTML and Typescript’ code compiles into Javascript code. Compiling during build process ensures a faster rendering into the browser.

Let us see for the same piece of code how JIT and AOT compilation could make a difference.

ng serve

ng serve --aot

Clearly, ahead-of-time compilation could foresee the error failures that may occur ahead of time.

Why AOT?

• Faster Rendering
• Reduce Angular Payload
• Detect template errors earlier
• Less injection attacks chances
• Less Async HTTP requests

As Angular offers JIT compilation by default, therefore AOT compilation is recommended for above reason before building your code for deployment. AOT compilation performs more build restrictions and code optimisations compared to JIT compilation.

Ahead-of-Time (AOT) compilation in Angular was originally published in Docon on Medium, where people are continuing the conversation by highlighting and responding to this story.