DEV Community: Parth Makawana

What happened to “Javascript Killer” WebAssembly? Is it already dead?

Parth Makawana — Fri, 27 May 2022 08:53:02 +0000

Looking at the current technology market situation, the hype around Web3.0, Metaverse, Blockchain, AI, ML etc., reminds us of how rapidly the technology market changes. It is so rapidly evolving that technologies that we thought would be the future of the industry today, would disappear entirely from the industry a day after tomorrow.

We have so many examples of tech that were hyped for doom, many of them are either extinct or on the verge of extinction. Just a few of them are surviving. and merely a handful of them could thrive.

We’ll look back at one such hyped tech “Web Assembly” by answering What, Why and When:

What is WebAssembly?

Why do we call it Hyped for doom?

When will it be dead?

What?

First, let us understand what is WebAssembly or WASM for short? Why did everyone think it would become a “Javascript Killer”?

Now, What is WebAssembly? If we go by the definition from its official website, It states:

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.

Basically, It is a low-level, assembly-like language which gets stored in compact binary format so that it can give a near-native performance.

As mentioned in the definition, WASM was designed as a compilation target for other languages, allowing server-side code (such as C or C++ code) to be compiled into it and executed inside the browser.

It can let you code in any low-level programming language thus removing the barrier of understanding a particular programming language. It has native browser support so it is accepted across the browsers.

Imagine a non-web developer writing a piece of code in a non-web-compatible language using WASM and still being able to create amazing web apps that can run on browsers with near-native speed. That is the power of WASM and that was what’s promised.

Now, It was never intended to crush out javascript in the first place, but to work alongside it and overcome its issues and boost its advantages.

However, as I mentioned it was hyped to a general audience as a replacement for javascript, which is totally incorrect. People across the world started comparing it with javascript as if WASM was a rival to JS but in reality, WASM is a companion of JS and that’s where the tag “Javascript Killer” came into being.

The reason why people started comparing WASM with JS is that WASM promised to solve several issues that JS has like Security issues, Cross-platform support, Improved speed, Improved Debugging, and Garbage collection to name a few.

But did it deliver on that promise? Let’s find out in my next section.

Why?

Now, Why did we call WASM, hyped for doom? Is it because it did not deliver on its promises? Well, partially, YES!!!

The promises it delivered are Faster and easy coding, cross-platform development, and biggest of all, Improved performance.

It does deliver faster and easy coding as it allows developers to write the code in their native programming language so little or no training and exercise are required.

The biggest marketed feature of WASM was its improved performance over JS. And It does deliver on that promise. The obvious reason for it is that it translates into a binary instruction which is of course lite weight than JS text files. There have been many articles around the internet which did benchmark tests across different browsers and devices.

And usually, WASM was 30–60% faster than JS depending upon the browser and devices.

So what went wrong, you might ask?

Though it exceeded the benchmark tests, Manier times, users and developers have found that real-world performance does not match that of benchmarks. It does exceed JS performance but not as much as the benchmarks suggested. Which basically disappointed many people.

But one of the most prominent failures for WASM was its promise of improved security over JS.

We all know JS has several security issues on its own, and WASM promised to resolve them, however, in real-world applications, it failed to deliver on that promise. If you look at statistics here, It states that Half of the websites using WebAssembly use it for malicious purposes.

So the very tool that was designed to improve security is being used for malicious purposes.

That’s why is said it partially did not deliver on its promise.

But that’s not all.

We, the developers and people of the tech community understand that new technology can not be perfect at first. It takes many iterations to be in shape and start delivering. So we really want WASM to gradually improve and start to deliver over iterations.

But the problem WASM faced apart from its security issues and some performance mismatch between the benchmark and real-time is the marketing and getting the attention of developers and people of the tech community.

Though it was released with a bang in 2017 and later many products like Blazor made headlines with WASM, Many people do not know what WASM is capable of doing or have never got their hand on it to experience how it is different from other front-end/client-side frameworks. It’s been too long to get its well-deserved attention and widespread adaptation in real-world applications.

So, combining poor after-launch marketing along with security issues, It became the hyped for doom tech.

So the question we now raise is how long will it be able to continue this way? Will it survive any further or if not when it will be dead eventually? Let’s find that out in the next segment.

When?

It’s been 5 years since WASM was released and its potential is still fully not explored and adapted for the obvious reasons we mentioned above.

So will it be able to continue this way and survive, or will it be dead? and when it will be dead?

Well, I truly wish it to succeed as it's an exciting piece of tech with lots of potentials. So I really do not wish it to go into dust this soon. But unless it resolves the issues I mentioned above, It won't be long before WASM may get forgotten.

It has the potential to co-operate with the current technology trends like Gaming, metaverse and crypto/blockchain applications as it can do the huge computation in real-time with high performance. So If adopted well, it can become the prominent force driving client-side development provided it starts delivering on its promises.

Until then, Happy Learning!!!

Are you using Agile or Lipstick Agile?

Parth Makawana — Tue, 10 May 2022 08:56:30 +0000

Agile Methodology was founded in the early 2000, but it picked up pace in the early 2010s.

Since then, more and more organisations try to be agile in their core values and practices (People call it “Living Agile”), but others following them just boast about being agile and call it a day, without solving core issues and following its principles. (Call it “Lipstick Agile”)

In this article, We’ll revolve around Lipstick Agile and answer the following questions:

Why do we call it “Lipstick Agile”?

What are its traits?

When should you be alarmed? and

How can you overcome it?

Let’s get started then!!!

Why?

First, Let’s go through the term “Lipstick Agile”.

I apologise for borrowing the term from Stefan Wolpers, But the term is surprisingly simple and complex at the same time.

A basic explanation of why it’s called “Lipstick Agile” is the simple illustration of the first image in this story where a pig is forced to apply the lipsticks and makeup to make it look good. It’s obvious that even though we apply as many lipsticks, a pig at its core is still a pig and it will do as good as a pig even if we expected it to be better after applying lipstick.

Likewise, If you try to enforce the Agile manifesto under individual’s throats without addressing the organisation’s and individual’s static and rigid mindset, you are falling in the trap of Lipstick Agile.

Though it’s a very simple explanation of the term, the complexity of this term lies in finding out if you are using Lipstick Agile or not?

So I’ll try to address and declutter that complexity in the next segment.

What?

Now, What are the traits of Lipstick Agile? How can you identify if you are falling into Lipstick agile or not?

For that, as an individual/leader, you would need to ask yourself these questions by being true to yourself. Don’t give answers by your theoretical knowledge but by answering it from what you practice.

Ready?

Here they are:

Is your team’s or individual’s mindset rigid? Do they or you welcome changes as they come than resist them?
Is your appetite for numbers like revenue, contracts and customer retention strong? or can you be flexible for negative numbers?
Do you stick to the processes and tools set by your organisation/team? or do you empower or motivate individuals to explore various processes and tools?
Is working software important to you over the history of tickets and documentation?

If the answers given by your heart are on a scale of No to neutral, then you are definitely using Lipstick Agile. Even if you said yes to most of it, I would burst that bubble in just a moment. But before that, you might be wondering, these questions seem familiar. And you’re right!!! These are taken straight from the Agile Manifesto.

So even if you said yes to the above questions, let’s break those further down.

Do you stick to the agile ceremonies even if they are not fruitful? Do you keep doing the standup meetings even if it’s just status updates? Do you even work on good, bad or improvement points from retrospectives?
Do you believe that increasing revenue or new contracts or customer retention ratio are the primary metrics to measure success? Do you put numbers like those, preference over customer satisfaction?
Is Burndown chart, Velocity, CFD, Throughput, Time logs, Bug counts, Jira reports and sticking to processes set by the organisation/team more important to you than the business value of features and an individual?
Do you prefer everything should be documented, be it in Docs, Jira Ticket or Commits? Do you rigidly maintain the history of work done by individuals than worry about the impact of work done?

Now I assume, your answers might have changed because that’s what most of the “Self Trained Agile Organisations” do.

Now, don’t get me wrong, I do not say that numbers like revenue, contracts, retention ratio etc and metrics like burndown, velocity, reports etc doesn't matter. It most certainly does. But it does only when team & individuals have matuared enough in Agile Transformation.

Following them rigorously and making decisions based on that while your team or individuals still don't have an Agile mindset or are not trained for it, is of no use. In fact, It may adversely affect your team/organisation.

Lipstick Agile works fine for most of the teams & organisations who take pride in being Agile even if it’s false agile. It only starts to get painful when things start to go sideways. That’s when you should be alarmed. We’ll discuss those alarms in the next section.

When?

When you should wake up from false pride in using Agile while you are actually using Lipstick Agile? What are the signs of that wake-up call?

Well, for starters, the first and major indication would be your customers. If they are not happy with what you deliver or they don't find business value of the features you have delivered, then you should be alarmed.

The second would be the satisfaction of individuals. If the individuals feel that the work they are doing is not making any sense, or they feel the meetings or several agile ceremonies are wasting their time without giving any fruitful results, or they feel that the processes and tools they are using are rather an overkill than facilities, then you should be alarmed.

Third would be your feeling about the deliveries and performance of your team. If you think that burndown, throughput, bug count, bug severities etc.(Yes, I admit here, metrics are relevant) and most importantly, the business values of deliveries are going sideways, or the teams or individuals are not in sync with themselves or with stakeholders and they are still working in silos, then you should be alarmed.

Now that we know what are the indications of a wake-up call, how can one overcome that? That’s what we’ll discuss in the next section.

How?

Now, Let’s circle back to the first question I asked in the breakdown questions in the “What?” section. Because the best solution to overcome the trap of Lipstick Agile lies there.

The question I asked was: Do you even work on good, bad or improvement points from retrospectives?

The retrospective is a very important ceremony which allows the team to focus on what went well, what didn’t go well and what we need to improve.

Most of the organisations/teams that are using Lipstick Agile either get away from this important ceremony totally or perform it just for the sake of … well, performing it.

The prime reason the retrospective is being done for name’s sake is that individuals and stakeholders lose their interest in performing it over time, as the points like what went well, what didn’t go well and what needs to be improved etc. stay in retrospect board only. It doesn’t translate into action items for future sprints.

To overcome the trap of Lipstick Agile, one should empower and trust their teams, individuals, stakeholders and end-users to provide actual feedback rather than imposing fear or letting them have disinterest in that ceremony by not making it fruitful.

Another way to overcome it is to envision and tackle real-world business values. Measure the work done by the team on a business value scale. Empower the individuals to raise red flags when they feel the work they are doing isn’t adding any value.

Ask individuals to remember to raise red flags by asking them to remember:
“If it doesn’t make any sense to you, it shouldn’t be there”

Once you fix those 2, the third alarm goes off automatically.

Hope you found it useful and practical.

Happy Learning!!!

The end of Mediocre Software Developer is near?

Parth Makawana — Tue, 10 May 2022 08:55:24 +0000

As we all know, Software development is a challenging and continuously evolving field. Not just today, It has been this way always. But in recent times, it has been accelerated at such a pace that many developers find it difficult to keep up.

So the question we are asking is: Will the fast-paced and rapidly evolving nature kill the jobs of mediocre programmers?

Again as per my previous articles, I’ll go by answering What, Why, When and How.

What?

What do I mean by Mediocre developers and the end of them?

Let’s first go with a Mediocre developer. I believe there are several traits of a Mediocre developer. Like:

Little or no interest in programming
Procrastinate to cope with the latest trends
Does not deep dive into the solutions he/she is working on

Now, What do I mean by end of mediocre developers? I do not mean that they would disappear from the industry. but realistically, they would keep doing mediocre jobs and maintain the legacy systems.

Why?

First, we need to understand why this question arose?

We’ve all been saying and seeing the fact that AI and robotics would eventually take over many jobs. But we all thought that Software Development is a field that is the brain behind AI, so developers would never be obsolete. However, in recent years, the increasing use of no-code and CMS based websites pushes us to think otherwise.

We think that no-code and CMS based websites can’t create complex and logical web apps. and that’s correct too. But then came GPT-3 and people created some amazing apps over it. And in October 2021, GitHub launched Copilot which allows a user (even non-technical users) to code by just providing comments or requirements in plain English language.

I know copilot is more like a fun playground right now, but it’s impressive to see how it can even provide solutions to moderate to some highly complex leetcode problems.

We still think it’s in an early stage, and it can never be as perfect and understanding as a human being, but it’s a start.

And then came GitHub Copilot Labs. and it blew my mind.

It explains code, answers some specific questions, and even translates the code from one programming language to another.

It can also let users understand the existing code so a developer would not always be required even if there need some changes in existing code.

Both extensions combined make us think, are the tech giants trying to get rid of expensive and slow human intelligence with cheap and fast artificial intelligence?

Apart from that, the rise of Web3.0 and decentralized applications would also push the mediocre developers out of mainstream development. It’s still too early to say whether web3.0 will become a driving force of this decade or not, but it would certainly make some impact.

When?

So when is this going to happen? When will the Mediocre developers become obsolete?

There’s no definite timeline one can think of. But with advancements in AI, It seems pretty closer than we think. My best guess would be that within the next 5 years, all the new developments would gradually shift to methods like no-code and may also use a non-technical person with GitHub co-pilot as a pair programmer.

It doesn't mean developers will be out of jobs. The projects which require heavy business logic or heavy configurations or personalisation or heavy database structure that a human brain can do better and faster than an AI which provide false results in that case, would always require a developer.

How?

How a developer can save him/herself? Well, There’s only one way. He/she will have to stop procrastinating and start learning new technologies.

It would be either AI or Web3.0 that would cause the end of Mediocre developers.
So It should be the primary goal to get on either of the trains to save him/herself from getting thrown out of the station before the trains left.

Happy Learning!!!

Tangled with front-end state management? Use the store!!!

Parth Makawana — Tue, 10 May 2022 08:54:29 +0000

Let’s be honest, State management on front-end applications is a tedious job.
Even from the days of Vanilla JavaScript to the date with many advanced JS Frameworks and libraries.

State management can be done in all three tiers of the application, be it backend, database or front-end. However, we will specifically talk about state management in the front-end side of it in this article.

Let’s get started in my much-appreciated style of WWWH aka What, Why, When and How.

What?

First up, we need to understand what is the state?

The state is just a snapshot or representation of the system from the client-side at a given point in time. It can be manipulated and represented in a seamless manner especially in single-page applications.

The state is basically a store of data take it Application related data, User Data, Navigation information, Communication-related data etc. And with any kind of data, we deal with, It can be either manipulated or consumed.

As for State Management, We can manipulate the state by various actions. It can be user actions, API response, navigation changes etc. On the other hand, we can consume that store to display the latest state of the application by querying the store. As simple as that.

As one can figure out from the above diagram, It’s a circular pattern that is continuous. But basically, if we start with the store, the store has the initial state of the application which is used to render the view, from which, the user performs any actions which in turn triggers a mutation to state and it continues.

There are multiple libraries that provide state management for different javascript frameworks like:

NgRx for Angular
Redux for React
Vuex for Vue

Why?

Now that we understood what is state and state management, let’s see why we need it?

Remember the time when we used to store a bunch of things into localstorage that can be manipulated and consumed throughout the application? then you would certainly remember the pain of getting all those key values organised.

State management takes care of the main pain point of organising the state for your application without you constantly worrying about it.

State management helps us to set, manipulate, organise and synchronise the current state of application throughout all the components in your application.

It also helps us to make API interaction and data flow through the APIs smoother and consistent. It can help us cache(not in the literal sense) the responses so that we can retrieve them as and when required quickly.

It also helps us to ease the communication between multiple components as the centralised store helps all the components to interact with it to change or access the data centrally.

When?

So, When we can think of using the store? What are the use cases in which using the store will benefit us?

There are mainly 2 scenarios in which one can think of using the store:

The application contains so many components that need to interact with each other frequently or
The application consumes redundant data frequently.

However, If you are developing a simple application with component silos, you are better off not using it as it would rather be complex and slow to implement the State management.

How do we decide when to use State management? I would like to borrow the below paragraph from ngrx website:

A good guideline that might help answer the question, “Do I need NgRx Store?” is the SHARI principle:

Shared: state that is accessed by many components and services
Hydrated: state that is persisted and rehydrated from external storage.
Available: state that needs to be available when re-entering routes.
Retrieved: state that must be retrieved with a side-effect.
Impacted: state that is impacted by actions from other sources.

How?

We can use state management by simply using libraries that help us implement state management. and it varies for javascript frameworks.

However, The basic concept of implementing a store is the same for all.

There are 4 actors which need to be remembered:

State: It’s the source of truth/data that stores the state of the application
View: Which consumes the state to present it to the user
Actions: Which are the cause of change in state
Mutations: Which gets triggered on the specific action and eventually change the state.

Rather than adding the snippet for all the JS frameworks, I would like to redirect you to the documentations of well known and well established libraries from various JS frameworks.

Angular: NgRx
React: Redux
Vue: Vuex

Happy Learning!!!

Mediator Pattern: A Capable Underdog?

Parth Makawana — Tue, 10 May 2022 08:53:27 +0000

Aghh, One more design pattern blog on my feed? I bet you are thinking the same. But let me assure you, you would be gaining at least some idea of why I called it Capable and Underdog at the same time.

I would be answering basically 4 questions here which everyone would ask when learning about a new pattern: What, Why, When and How?

So let’s get started:

What?

First and foremost, the question that arises hearing about a new pattern is why?
Why do you need some new patterns in your project when you already have more than 20 well-known design patterns floating around and in a stable state for most of the project.

Well, to understand that first we need to understand what is mediator pattern?

If we go by the definition from Wikipedia, it says:

“the mediator pattern defines an object that encapsulates how a set of objects interact.”

Over the head huh? Don’t worry.

As the name implies, the Mediator plays an intermediatory role to mediate. But mediate between whom? You guessed it right. Between classes. In other words, it provides a unified and single entity to communicate between classes. Let’s make it simple for now, it mediates between the core API Actions and the respective business logic they communicate to. So, it’s a behavioural pattern.

You would immediately ask, why do we need a mediator when we can already communicate between classes very easily by using plenty of other design patterns, to answer that, let’s move on to the next topic.

Why?

Imagine the Airport to be your application and you need to manage the air traffic.

Imagine if there was no Air Traffic Controller on the ground and planes needed to manage the altitudes and speeds by themselves, by interacting with dozens of other aeroplanes nearby?

It would create a mess, wouldn’t it?

Most of the traditional design patterns work on dependencies. Let’s say there are 3 classes that depend on 3 different classes to execute their business logic. What we do traditionally is resolve dependencies of the classes it consumes. Which makes the interaction many to many in a way. Which creates a spaghetti of dependencies.

Now imagine you need to decouple or change the interaction of some of the classes?

That’s where the mediator comes into the picture.

What it does is, basically take care of interactions.

Which solves several issues:

Direct/Tight communication between classes.
Handles complex dependency management.
Allows us to easily modify any interactions between the classes.

The scenario from above will now look like this in mediator pattern:

It's easily observable that it not just looks clean but also provides a unified interface to manage the interactions.

Ok, so now that we know what it is and why it was introduced, let's check some use cases on when to use it and when not to use it.

When?

Simply put, we can use a mediator pattern when you need to get out of dependency entanglement. When you have so many classes which are dependent on one another, managing dependencies create a headache.

We can use it when we need to easily change the behaviour of how classes interact between themselves, when we need to have an ATC kind of single entity to manage the interactions and when we need to encapsulate the objects being communicated such that only a single entity knows the dependencies between classes.

Of course, it’s not perfect. It comes with a price.

As with all other single entities, it’s prone to fail. A complex mediator with too many dependencies on it may become a single point of failure. So better not complicate it.

Now let's jump on to How we can use it?

How?

Don't worry, I won't be pasting the whole solution here. You can check out multiple examples of such projects on GitHub like this one here.

But to put it in basic context, you can install and configure MediatR Nuget Package, Create models and handlers pertaining to actions/workflows, and then use it in actions by sending the request to the mediator.

Mediator with CQRS

If you have visited the GitHub repo from above, you would have seen the term CQRS-Mediator Pattern. CQRS and Mediator are often used interchangeably which is somewhat incorrect.

Both have different use cases and problems to solve, but combining both is where magic is. The Nuget MediatR facilitates the use of both patterns, which is one of the reasons why these terms are used interchangeably. Learn more on CQRS here.

Capable Underdog?

Till now, we know why it's capable, but why it's still an underdog?

Unfortunately, there is no certain answer to the question, but in my opinion and observation, the reason would be that many existing projects use widely acceptable design patterns like singleton and factory patterns. But It’s evident that the use of the Mediator Pattern is accepted and growing especially in new solutions industry-wide.

Happy Learning!!!

Things you will realize about the corporate IT world, Eventually

Parth Makawana — Tue, 10 May 2022 08:51:38 +0000

Internet is full of articles with similar titles, some written by well-known authors. So, why bother reading this? Well, These points are my observations being in the corporate IT world for about 5 years now. Some of them may be generic for the corporate world in general. You may agree or disagree with a few or many of them. But every individual may have their viewpoint based on the degree of the circle of their experience they are standing on. And I would love to hear your thoughts on it.

So let's get started:

1. The Foundation of your career is very crucial

Colleges and universities form your academic foundation, but their importance gradually decreases when you step into the corporate world. It just becomes the first stepping stone in starting your career. Nothing more. Your academic excellence doesn’t necessarily convert to an excellent career. It depends on how excellent your career foundations are. I’ve seen many people who were not able to convert their academic excellence into an excellent career.

But what builds an excellent career foundation? You ask.

Well, It depends on the work, environment, and co-workers you get at the beginning of your career.
As a graduate, your obvious aim remains to build your experience, knowledge, and professional etiquette. You work as hard as a child who wants to reach up to his/her toy up in the attic. While getting knowledge is in your hands partially, these things still depend on the people you interact with every day.

A graduate is like a seed. It takes some great people and minds to nurture them into fruitful plants.

Having a mentor who can nurture that seed, is very crucial for an excellent foundation of a career.

But a mentor can only write something on a slate if it's empty. It's important for a graduate to wipe off all unnecessary experience, knowledge, and arrogance he/she has gained while in academics, and become a student once again. For a successful foundation, you need to surround yourself with people who not only improve your knowledge and encourage learning but motivate you to achieve excellence selflessly in the early stages. And even scold you for your misdirection and wrong behaviour.

On the other side, If you are surrounded by negative people at the start of your career, please know that you are doomed. Because, it only increases the unnecessary experience, knowledge, and arrogance you’ve gained till now. It diverts your attention from improving yourself to blaming others and increases your ignorance over time.

2. Processes Matters

As a developer, I’ve hated some of the software development processes and methodologies. I mean why do we need so many meetings, checkpoints, and processes to complete a small piece of work. Right? Well, they are there for a reason.

I’ve seen the chaos where there’s no established process, misunderstanding when there’s no meetings and conflicts when there are no checkpoints.

Yes, the processes should not be rigid, It should be agile enough to modification depending on situations. And Meetings should always be time-bound and to the point.

I’ve been first introduced to the Iterative model and then to Agile. I’ve personally liked the iterative model for the fact that it has the best of both worlds: Waterfall and Agile. Or for the fact that requirements are quite stable and easy for modification. But either way, Any established process is required for the team to perform consistently.

3. Building a network is important

Well, I for one, am not the right person to write about this as I am terrible at building a network. But I’ve included this because I realize that not having a good network of people damages your chances of getting good opportunities in the future. I have always behaved self-respectfully in getting in touch with former colleagues. Some may even consider that arrogance.

But I feel you should connect with people who wants to be connected with you. You should pull that string if you don’t get any response from other end. And focus on those who do. It might reduce your network, but it will be of the right people.

4. Comfort Zone kills your skills

In everyone’s life, there comes a time when they have achieved many of the things they’ve wanted, and now they sit back and relax. Everyone deserves to relax if the achievement is huge, but It should not convert into Comfort Zone. If you’ve achieved something excellent, relax, and regain your strength to set up new goals.
How do you find if you’re in your comfort zone or not? It's easy.

If you’re happy (or rather not stressed out) with whatever you do, please know, you are in comfort zone.

I know this is not a popular opinion and it's debatable. People always says that take pride in what you do, be happy in what you do, blah blah, but in ideal corporate world, If you’re always happy (or rather not stressed out) with even the wrong situation you are in, you are in the comfort zone.

You’re getting good pay, praises from everyone. That feels sweet. And who wouldn’t like sweet things?

But remember, sweetness causes diabetes, just the way comfort zone kills your skills.

And how can we get out of our comfort zone? Well that depends, is your comfort zone created by people around you? Then connect with new people. Or is it created by day to day work? Then change the work, thrive for doing better.

5. Learn to face conflicts and failure

This perhaps is the most common and crucial point in all, because we all face that almost daily.

Let’s start with conflicts.

It’s of-course fine to have difference of opinion on any point.

Having multiple minds working on a common thing may bring multiple views to the table and that’s actually beneficial. But the problem arises when these difference of opinion turns into conflicts.

And about failure, many successful people have already talked about failure, so I might not be the right person to comment on that. But certainly, there would be times when you won’t be at your best. Just keep breathing and focus your attention.

6. Respect/Adjust with your colleagues

Your colleagues and superiors play a crucial part in what you become in your professional career. You might be fortunate to have great colleagues that support, understand and motivate you. But many may not be that fortunate.

For those, there are few ways to deal with the situation.

Respect other’s opinions that may not adversely affect you, and Adjust with and understand other’s opinion that may.

There will be scenarios every day where you think, a piece of work can be done easily or better your way, but that may not be accepted. So rather than being heartbroken or hurt, try to find out why your opinion is discarded, compare it with what’s been accepted and improve upon it.

That doesn’t mean you should not voice out your opinions. You should always put your opinion on the table. If it’s accepted, be happy, if it’s not, adjust and understand why it’s not accepted.

7. Never mix up work, family, and friends

This one rule will be more than enough for peaceful work and life. That doesn’t mean you don’t share your good and bad things from work to family and friends and vice-versa, but define a line between what to share and what not.

That also doesn’t mean you don’t make friends at work, but identify the nature of that friendship.

If you cross that thin line of separating work, family, and friends, it will create a mess you wouldn’t be able to settle easily.

8. Be careful whom you consider as friends at work

Speaking of friends at work, it's very important, who you consider friends at work. Because let's be honest, in the corporate world, not everyone is your well-wisher and not everybody is your enemy.

How can you find such friends? You ask. Well, it's difficult.

Because you will get to know who your real friends at work are after you stop working with them.

That sounds crazy, but it's true to nature. True friends at work will always be happy to connect with you, improve one another, share knowledge and have fun even after you are no longer important to them.

They admire and connect with your nature, not your position and power.

But during your ongoing tenure, just consider them as your colleague. As you will eventually find out if they are friends or not.

9. Respect is a two-way street

The statement is self-explanatory. If you don’t give respect to others, you won’t get it from that person and others. There are several aspects to it, however,

Most of the people co-relate respect with position and power. That way, one just becomes an opportunist.

Getting respect is the right of every human being, whether they are powerful or not and knowledgeable or not. People tend to ignore especially those who either do not hold any power or have less knowledge than others. We know the power and position aspect easily, but let me tell you about the knowledge aspect. Those who are less knowledgeable than others, make mistakes while working, requires help by keeping their dignity intact. If you hurt their dignity by unnecessarily scolding them, they might approach you in the same way.

I’ve seen the magic of being a selfless helping hand to those in need, and the beauty of getting their respect back when they approach you.

10. Learning is the real earning

Learn, Earn, Adjust, Respect and Relax. Peace out. ✌

DEV Community: Parth Makawana

What happened to “Javascript Killer” WebAssembly? Is it already dead?

What?

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.

Now, It was never intended to crush out javascript in the first place, but to work alongside it and overcome its issues and boost its advantages.

Why?

And usually, WASM was 30–60% faster than JS depending upon the browser and devices.

But one of the most prominent failures for WASM was its promise of improved security over JS.

We, the developers and people of the tech community understand that new technology can not be perfect at first. It takes many iterations to be in shape and start delivering. So we really want WASM to gradually improve and start to deliver over iterations.

When?

Are you using Agile or Lipstick Agile?

Why?

What?

When?

How?

The end of Mediocre Software Developer is near?

What?

Why?

When?

How?

Tangled with front-end state management? Use the store!!!

What?

Why?

When?

How?

Mediator Pattern: A Capable Underdog?

What?

Why?

When?

How?

Mediator with CQRS

Capable Underdog?

Things you will realize about the corporate IT world, Eventually

1. The Foundation of your career is very crucial

A graduate is like a seed. It takes some great people and minds to nurture them into fruitful plants.

2. Processes Matters

I’ve seen the chaos where there’s no established process, misunderstanding when there’s no meetings and conflicts when there are no checkpoints.

3. Building a network is important

But I feel you should connect with people who wants to be connected with you. You should pull that string if you don’t get any response from other end. And focus on those who do. It might reduce your network, but it will be of the right people.

4. Comfort Zone kills your skills

If you’re happy (or rather not stressed out) with whatever you do, please know, you are in comfort zone.

But remember, sweetness causes diabetes, just the way comfort zone kills your skills.

5. Learn to face conflicts and failure

It’s of-course fine to have difference of opinion on any point.

6. Respect/Adjust with your colleagues

Respect other’s opinions that may not adversely affect you, and Adjust with and understand other’s opinion that may.

That doesn’t mean you should not voice out your opinions. You should always put your opinion on the table. If it’s accepted, be happy, if it’s not, adjust and understand why it’s not accepted.

7. Never mix up work, family, and friends

That also doesn’t mean you don’t make friends at work, but identify the nature of that friendship.

8. Be careful whom you consider as friends at work

Because you will get to know who your real friends at work are after you stop working with them.

They admire and connect with your nature, not your position and power.

9. Respect is a two-way street

Most of the people co-relate respect with position and power. That way, one just becomes an opportunist.

I’ve seen the magic of being a selfless helping hand to those in need, and the beauty of getting their respect back when they approach you.

10. Learning is the real earning

Learn, Earn, Adjust, Respect and Relax. Peace out. ✌