DEV Community: Vignesh M

Nobody is working for 8 hours a day, Why?

Vignesh M — Thu, 15 Oct 2020 16:11:34 +0000

Recently I came across an interesting question on twitter about average working hours per day.

// Detect dark theme var iframe = document.getElementById('tweet-1307003566763077634-383'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1307003566763077634&theme=dark" }

A knowledge worker spends an average of only 2 to 4 hours a day on productive work. The rest of the time is not used to do any meaningful work (I read this in multiple places too, but can't find any original research on this).

Since I can't find any reliable sources to cite, I am writing this based on my personal experience. I work an average of 4 or 5 hours on a good day without any interruptions. On a bad, fragmented day, it'll be far less than that. There are multiple reasons for this.

40-hour workweek is a relic of the industrial era.

In the industrial era, the output is directly connected with the amount of time you put in. Most of the jobs don't require any thinking. Repetition was the key.

Imagine an assembly line worker putting together a few parts of a car. They almost did the same thing every day and their output is measured by the number of things they can put together per hour. When Henry Ford took brought the conveyer belt to the factory, it was seen as a revolution. It eliminated all the extra movements and increased performance. But the core principle of hours = output remains the same.

Enter our knowledge work era, things are blurry. Imagine a developer sitting in his desk thinking about something. Are they thinking about the current problem or just wandering? You'll never know. We can't measure the performance here by measuring the number of hours they put in. This is a fact that everyone knows. But we're collectively still hanging to the 40 hours work week.

If you're in a position of managing people who do creative work, understanding this simple fact is essential. Hours are not equal to performance. I believe in creative bursts that let people do a lot of work within a short time. performance scientists call this as flow state.

If a worker had a flow state of 3 hours per day their brain needs recharge time. The company is paying both for the peak and the recharge time.

Can we stay in the flow state more than 3 hours? Certainly.

Can we repeat it every day? Certainly, not.

Trying to push more than this average limit can have negative effects in the long run such as burnout. In this case, how to understand if someone is slacking? Start measuring their performance by their output, not by their time.

Knowledge workers contribute by their judgment, not time

I read The Almanack of Naval Ravikant recently and what he told about judgment struck a chord.

My definition of wisdom is knowing the long-term consequences of your actions. Wisdom applied to external problems is judgment. They’re highly linked; knowing the long-term consequences of your actions and then making the right decision to capitalize on that.

What a knowledge worker provides is their judgment and skills. Most of their job is decision making considering the trade-offs and benefits. The time they take has very little relevance. We can't rush to a decision if we care about the long term wins.

The human brain is not optimized for long, focused work

We were hunter-gatherers for a long portion of history. Humans lived and hunted as a group. The main rule is "when in doubt, run". Those who thought long and hard often perished in a predator's jaw. We're the descendants of those quick decision-makers. There was no point in history that an average human needed to use his brain for a long time and earn a living.

Our brain is not optimized for a long period of focused work, it gets tired. The attention span is an average of 20 minutes for humans. The contribution of push notifications and social media could have reduced that even further. So it is better to take breaks in between instead of pretending to be paying attention.

There is also a benefit by taking breaks which leads us to the next point based on the Zeigarnik Effect.

Knowledge work is not limited to the clock

It is not possible to shut off your brain from thinking of work problems after the clock. The brain works hard to solve difficult problems when you're doing something else on the surface. People claims about getting solutions for problems when they're taking a shower or going for a walk.

When you have an unfinished task or problem, it'll take the larger part of your attention and will stay in your brain even when you try to do other things. This factor is known as the Zeigarnik Effect. So it is natural for people to think about work after work hours and find good solutions.

In a way, knowledge workers are working outside of the clock as well. They're learning things in their spare time that impact their work at a later point in time.

A while ago, I was reading about optimizing angular performance. A couple of months later, when we faced some performance issues, I suggested a few ideas I learned from that post. The company is benefitting from the knowledge I gathered on my own time. The reverse is also true, Most of my skills are learned while getting paid from the company for it.

These are the reasons that people tend to work less than 8-hours a day. But there are business needs to measure and document everything.

How to measure productivity?

There is no actual way to measure the productivity of an individual developer. Many have tried and failed. Instead of trying to measure what's not measurable, You can think o the following.

Measuring the outcome of their work
How they contribute to the success of their team and to your business?

Ask the following questions about your team,

They miss deadlines regularly?
Your customers are frustrated because of your engineering team's velocity?
Does your team surprise you with reasons at the last minute?

The answer to these questions can create a discussion. If your organization is transparent you can find the problems and fix them easily. Trusting your team to do their job well can take you far then nitpicking on irrelevant details.

How to improve productivity?

There are ways that you can help your team to get more done by creating the ideal environment that is optimized for knowledge work.

Open offices are bad

I am aware of the serendipity aspect of open office plans. But the noise, mobile ringtones, chatter really beats that advantage. To be honest, I hate open office setup.

Ironically, I live in India where the population density is so high, open offices are the only way to keep real-estate costs in control for businesses. It is not practical to completely remove open office plans, but can improve the quality of your office by,

Create focus rooms and encourage people to use it.
Enforce some rules about distractions within the focus rooms.
Try to reduce the unwanted distractions in the open floor
Buy noise-cancellation headphones and earplugs for your workforce.

Difference between the manager's schedule and the maker's schedule

Paul Graham wrote an excellent article about this. In short, the knowledge worker's schedule needs long periods of uninterrupted work. If you schedule meetings in the middle of such periods, time is fragmented into two less useful pieces of time.

To avoid the fragmentation,

Implement no meetings days in a week or no meetings time range in a workday.
Plan all your meetings within the first or second half of the day.
Reduce the number of meetings you need, asynchronous discussions are more than enough.

If you're running a business or managing a team of creative people, stop thinking about the time and start thinking in terms of the value created. Their judgment and skills are important than their starting and closing time. Create an ideal work environment and trust your team to deliver results.

Note: My thoughts might be biased, attributed to my limited experience in other areas of business. I am happy to make any changes if someone provides a good counter-argument.

9 important lessons I learned as a developer for 7 years

Vignesh M — Mon, 05 Oct 2020 19:12:14 +0000

I'm working as a software developer for 7 years. You can read my background and how I got into the industry here. There are a few things I wish I learned earlier. Knowing these in advance would have made my job a lot easier. Some of this might sound pretty obvious, but not for me. If you're in the early stages of your career, doing a few of this will make you stand out.

1. We need to find the right place to work for

The company and the people you work for makes a huge impact on whether you love or hate your job. Not all companies are created and working equally. What worked for someone else might become your nightmare. How to find the right place for you? Experiment.

Switch between different places and switch early. Don't wait until the ship sinks and you might end up in worse conditions.

Vignesh M

@shivenigma

To be good in a negotiation you should be confident. To be confident enough you should be ready to give up that offer and search for another. Don't start searching for a job when your current situation is bad or don't wait until things went to the south.

06:10 AM - 15 Feb 2020

0 1

In most places, the only way to get a raise or a promotion you deserve is to switch to a different company. Hiring managers are saying that too many switches make your resume look bad. In my not so humble opinion, this is a bullshit metric. Entry-level employees are often treated poorly. It is hard to stay in one place for a long time. Stability matters if you're hiring for senior or leadership roles. But please stop looking for stability in entry-level applicants. Start treating them better and they won't have to switch a lot.

In my first 4 years, I switched 3 companies. The current place I work for is my 4th one and I am here for 3 years. Start experimenting early in your career. Ask around about the place you're considering to join. Take interviews with different companies and select the right one for you. Ageism plays a big role in our industry. As you get older the places you can even get an interview will reduce. Take your chances when you're in the early stage.

2. Tech skills are only part of the equation

I thought being technically competent and doing the hard work will make me shine. I was wrong. Tech skills are only part of the equation. It doesn't matter how great an engineer you're. If you're one of the types that do the work heads-down, You'll have a hard time getting the things you deserve.

You need some showmanship to get better results from tech skills. You can practice and improve showmanship by doing these,

Talk to people in different teams/projects and help them.
Be curious to learn how the business works and how all the teams work together to produce something.
Write blog posts and share them with peers in your organization.
Become the goto person for help on a particular technology
Contribute to open source and share it among your peers
Attend/Speak at conferences.

Doing the above will increase your visibility in an organization. Being visible matters a lot.

3. Titles matter

Titles are a complex topic. I was upset a few times when my peers were promoted and I wasn't. Once I got promoted, it felt the same as before. A title won't make much difference in what you want to do. For my job satisfaction and motivation, titles don't matter much anymore. But title plays an important role in a few areas,

Your title decides which room you can get in and which you can't. When deciding important things, people inside the room can influence it. They also have the advantage of insider information.
Titles give you credibility within and outside of your organization. People will take you seriously if you have a better title.
In some places, they have a salary cap for a title. It is problematic when negotiating for your next raise without a promotion.

4. Communication

This is another important thing that goes hand in hand with technical skills. The modern workplace is a complex environment dealing with complex problems. We need better communication skills than ever before. Speaking fluent English is not the equivalent of communicating well. Non-native speakers I know have this fallacy. It is possible to speak English well and to be a poor communicator. Communication is more about

Asking the right questions
Listening
Collecting your thoughts and expressing them well
Writing well

People who excel at both tech skills and communication skills will thrive.

5. Networking

This is one of my weakest areas. Having good connections will open a lot of doors for you. If you're looking for a job or a new member for your team, being part of a developer network in your area makes it easier.

You can find people easier than traditional hiring methods. Online communities such as Twitter, Discord servers, Whatsapp groups are great too. I found a few great teammates through a Whatsapp group. It can do wonders for you when you connect with the right people.

6. Negotiating skills are important

For developers, this can be a great skill to practice and improve. Negotiation skills are useful in situations other than salary negotiations. There are a lot of negotiations in everyday life that we may not realize.

Negotiating for more resources with the project manager.
Negotiating for more time for a feature with the client.
Negotiating with your colleague about the current implementation of a feature.

Psst: I wrote about salary negotiation tips for developers before.

7. Code is not the only solution

In the beginning, I was so proud of the code I wrote. I got upset if the business wanted any drastic changes or removed something I already wrote. I thought code is an asset and placed high value on it. How naive? Your code doesn't have any value on its own. It must give some tangible benefit to someone in order to be valuable.

As I get into senior roles and understood the whole software business, code is likely a liability. The more code we have the more effort, time, and money is required to maintain it. There can be better solutions to a problem than code. Think of solving the problem in a different way before reaching out for code. As Abraham Maslow said,

I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.

Being a developer can lead us to think of problems only within the context of programming. But we should always try to think outside of our strengths.

8. Aligning to the business needs

Your code is useless the minute it stops solving a business need. I used to argue for not doing a feature due to some technical limitations. But as developers, we must find a way to make it work. The code is there to support the business. We must align with business needs than our technical constraints.

There are some important technical decisions that can make or break the business and you must take a stance there. But In most cases, business requirements should take precedence over everything else.

Technical debt is trickier to reason in this way. The business people can't understand how technical debt is accumulating and about paying it off. Developers are in a better place to decide about paying off tech-debt. Understand the needs and targets of the business, advocate what's best for the business. There can be times where you must stop adding new features and address the tech-debt. You need to recommend and fight for it to happen.

9. Watch your users

You can go through numerous user experience theories or you can learn by watching your users working. If you're lucky enough to see users in-person, great. Otherwise, there are sophisticated monitoring tools such as Fullstory that gives you similar insights.

Once you learned about your users, use that knowledge to improve your application. You can influence design decisions, Improve performance and usability. In most cases, the users will always try to use your software differently than you imagined. Having this knowledge will definitely make you stand out from the rest.

Despite many of the hardships in this job, I'm really thankful for the tech industry. There were not a lot of industries I can get in without any formal education and skills. I don't know what I would be doing if I didn't get the first unpaid internship. It is one hell of a year for me as I'm exploring different areas such as writing, building apps seriously than before. Looking forward to the upcoming years and new challenges.

The 4 differences between Observables and Promises in Javascript

Vignesh M — Tue, 08 Sep 2020 11:37:16 +0000

Javascript is a single-threaded language and it is blocking by nature. Still, we can do things asynchronously without blocking further code execution. Speaking of async, there are multiple ways to run async operations. I mostly use Observables and Promises. There is async/await, but it is just syntactic sugar over promises.

The difference between promises and observable is one is my favorite interview questions. This question won’t reveal their technical competence but might show some assumptions they have about JS and tools. So what are the differences?

Frequency

Observables are a stream of data or events, they are capable of firing more than one value over time. The below code will fire up every second, indefinitely.

import { Observable } from 'rxjs';

const greeting$ = new Observable(observer => {
    const clear = setInterval(() => {
        observer.next('Hello, there');
    }, 1000);
    // Need to handle the interval here, otherwise you'll end up in a infinitely firing observable.
});

greeting$.subscribe(res => {
    console.log(res);
})

Promises are a single event. Once resolved, the promise is done. They are best suited for one-time events such as results of an HTTP call.

const greet = new Promise((resolve, reject) => {
   resolve('Hello, there');
});
greet.then(success => {
    console.log(success);
});

Ironically, the Angular team decided to use observables for their HTTP library HTTPClient, for good reasons. This is a great architectural decision that is further explained by the other reasons in this post. In short, observables give better control on execution and manipulating results than promises.

Cancellation

Observables can be canceled, there are multiple ways to do it. By canceling, any ongoing calls and further emissions from the observable will be ignored. In reality, observable can wrap a lot of things such as user events, HTTP requests, and promises. Not all of them can be canceled or reversed once you made the call. Regardless, further results will be ignored once you canceled the observable.

But promises can’t be canceled once you called them. There are some libraries that support cancelable promises. But ES6 promises don’t support cancellation. The callbacks of a promise will be handled by the browser’s event loop. so you can do nothing once it is called.

Asynchronous

Promises are always asynchronous, even if they are resolved immediately. To know why, we need to understand the event loop in Javascript.

What is Event Loop?

If you’re already aware of what the event loop is, you can safely skip this section.

To put it simply, event loop is Javascript’s solution to handle the blocking tasks. JS just moves the blocking things to a different thread.

But Javascript is single-threaded, right? You may ask.

Javascript is single-threaded for a developer who uses it. You can’t fire up a new thread for something and then get results back as we can in Java or Rust. But it doesn’t mean everything you write in javascript is running within a single thread.

when you execute the following code, something happens.

function getTitle(gender) {
  // This is a vague simplification, gender is not binary.
    return (gender === 'M') ? 'Mr ' : 'Ms '; 
}
function print(content) {
 console.log(content);
}
function greet(name, gender) {
 const title = getTitle(gender);
 const message = `Hello, ${title}. ${name}`;
 print(message);
}

greet("Draper", "Male");

Each function you call will be added to a stack, that is called the call stack. As each function returns, that function is popped out of the stack and the previous function is resumed. Once all the functions have been returned the stack will become empty.

When you make a lot of function calls like a recursive call that went rogue, you’ll get the “Maximum call stack exceeded” error. It means, there is only so much the call stack can hold and your code exceeded that limit.

Let’s imagine what will happen without the event loop. In the call stack, When a function is running, the other functions have to wait. When waiting for some functions such as network calls, the UI will freeze. If there is no event loop, all other code has to wait for the network call to finish and comeback. To overcome this, JS pushes the tasks that may take a long time into a separate thread.

setTimeout(function (
    console.log("I'll show up after 5 seconds");
) {}, 5000);

In the above code, if JS has to put that into the stack and wait 5 seconds, all other functions and user interactions will suffer. So it pushes async tasks to a different thread and continues with the rest of the synchronous code.

Once the asynchronous function finished running, JS will push the callback function to a queue called callback queue. Technically, there are two queues Microqueue and Macroqueue. For the sake of simplicity, let’s assume there is only one queue. Once a function got pushed into the callback queue, the event loop will kick in. The event loop will check if the current call stack is empty. The callbacks will not be executed until the current call stack is empty.

If the current call stack is not empty it means something is in-progress. Once the call stack becomes empty the event loop will push the items from the callback queue into the call stack. If there are multiple items in the queue, the items will be pushed into the stack one after the other and will be executed. If you need a deeper explanation of the event loop, check out this great talk

Back to promises

Javascript promises are using the microtask queue in event loops. When you create a promise, it’s callback goes to the callback queue even if you resolve it immediately. It has to wait until the stack is empty this is the reason promises are always async. The process of items added to the call stack, executed, and the callstack becoming empty again is the event loop. Promises always need one more iteration in the event loop to resolve.

Observables can be both synchronous and asynchronous, depending on the function the observable is executing. For ex, If an observable wraps a promise, it will be asynchronous. I was reading into the rxjs source code to understand how observables are working and found this

Remember, callbacks provided to subscribe are not guaranteed to be called asynchronously. It is an Observable itself that decides when these functions will be called. Always check the documentation for how given Observable will behave when subscribed and if its default behavior can be modified with a scheduler.

The best thing about observables is You don’t really have to worry about if an observable is synchronous or asynchronous. It just works the same way for the observer. It makes writing code a lot easier. You’re just going to subscribe, and the internals are well abstracted.

Evaluation

Promises are eagerly evaluated. When you define a promise and give a callback function to its constructor, that is called immediately. This is useful for the things you want to fire immediately.

Observables are lazily evaluated. When you give a callback to the constructor of an observable, it’ll be only executed after subscribe has been called on that observable. I found the following comment from observable’s source code that explains this fact in detail. This gives as much more control when using an observable.

You can pass the reference to an observable, and it won’t be executed until someone subscribe to it. It also allows us to transform that observable’s stream in multiple stages. I ofter create one observable at the service level and then add more operators that transform the data into different format in different places as required.

What I learned by creating 3 different landing pages for a single app

Vignesh M — Tue, 25 Aug 2020 14:59:10 +0000

In the earlier part of this year I read great books such as Start small, stay small and the Soft skills. Both is about side projects and their positive impact on your career. I was thinking about doing an app to practically try out what I learned from these books. But I was demotivated and couldn't do anything in the pandemic.I set learning Rust as one of my goals in 2020 and I started that on a whim. I have seen the #100DaysOfCode before, so I decided to take that challenge with Rust. I was logging my journey in a Notion page and I covered the basics of Rust. One thing I found painful is creating logs for everyday and then posting the summary to twitter. I spent different methods with Notion and finally created a weekly template. It took me a while to arrive at something that I'm satisfied with.

I realized everyone should be having this problem and there are no tools to track your progress and give meaningful insights. So I left my challenge in the middle (after 42 days). and decided to create whereami.dev. Simply put, it is an app that aids you to track your learning better. I joined the Indiehackers community and learned a great deal about building stuff. One of the important things I learned is, development should not be the first step in building an application. That's a slippery slope if you're your only customer, stakeholder, project manager, and developer.

Once I framed my idea, I built a landing page with Wix using a predefined template. The page looked very good but I didn't add any custom domains to Wix. I also added a mailing list for the subscribers and started validating it with few people on twitter. Everyone said it's a great idea and they will use it once I finished. But no one signed up for it. Since it is not a custom page I was not confident enough to share it with a lot of people or tweet it publicly. I was just flying under the radar.

After a few weeks, I was demotivated that no one signed up for it. I did some more reading and learned that branding is important for any product. Surprisingly, even for well-branded sites, the conversion rate is really low. I approached like 5 people through twitter and thought I did my user research, evidently, it was not enough. (I made lot of mistakes when talking to users, I realized them after reading The Mom Test . A must-read if you're thinking of launching something on your own.) I had a goal of getting 10 users before actually beginning the development. Following the advice, I spent a couple of hours and built my own version of the landing page. I improved the copy and added its own domain, but the design went worse. I ended up with a basic landing page, you can see it here.

For this page, I added a email list subscription from Emailoctopus and included CTAs in place and I hoped this landing page was better than the Wix one. In reality, it is complicated, I added custom domain and that boosted the branding but the design is not something I am proud of. It also has accessibility issues and some people pointed that out. I got only one subscriber with this version.

As a final push, I was thinking about creating a reusable landing page template that I can use for different projects. I am a bad designer, so I was looking for inspiration and found the amazing https://uselander.xyz template in the Indiehackers community. I had to swallow my developer pride and take it because it'll take me weeks to create a template as polished as this. After that, it was only a matter of time to alter the copy a little bit to suit this template. Adding some illustrations from undraw, I got a nice landing page. Another thing that took me a long time is to create a mockup of the app and adding it to the landing page. I spent a week in Figma to create it and it looked just okay. Perfection is the enemy of done, so I had to go with what I have. The new version looked like this .

After deploying the new landing page, I tweeted about publicly committing to it on July 13, you can see the sudden spike of activity on that day. I had a lot of people DMing me and asking me about the app and signups started to increase. Once I finished the landing page I started planning for the development. I must admit that I am pretty slow to be an Indiehacker. I can see people finish apps within weeks. But I don't really have that kind of superpower. By this time, I learned a great deal about what is a niche and how important it is to reach your audience. Luckily, my audience is a nice bunch of people who are active on twitter.

I was tweeting my progress regularly and also there are few big accounts where my target audience wanders around. I got their attention by commenting on my site on one of their suitable tweets. That's the spike you see on the 22nd of July. This method is really tricky to do right. Your intention should never be marketing your thing. In my case, it just happened to match well with their tweet.

My target was to have 10 users before building it and I have got 37. I am developing the application now, I am a lot slower than I expected due to work commitments. But the accountability of public commitment keeps me going. Few people asked me about how is it going frequently and I got 37 users waiting for the app.

Takeaways

The public accountability can do wonders to your productivity if you can bear the little stress that comes bundled with it.
The landing page, domain, and copy are important. They will give you confidence and your audience will start taking you seriously.
Using what's existing and building on top of that is a mantra I learned this from Indiehackers community.
There will always be room for improvement, never strive for perfection. Good enough should be the target.

In conclusion, landing page, domain, and branding are really important if you're just starting out and don't really have a reputation for your name. Some people advised using subdomains from a single domain. In my experience, It'll take time, money, and effort to convince your users that your app is worth giving a try, and having a domain is one of the things that gives them confidence that you're serious.

How Sunk-Cost fallacy is making us write bad code

Vignesh M — Wed, 12 Aug 2020 17:49:09 +0000

We're a team of 7 building an enterprise application with Angular and Angular Material. We have different plans and features that can be toggled for each plan using a set of feature flags. We built granular controls such that, if required the user can be allowed to view a feature but not to interact with or change it. Everything worked great and we've built around 60 such feature flags.

We introduced a new feature that comes inside a set of tabs we already have as basic features. This new feature is supposed to be visible as an extra tab in the middle of other basic tabs.

The above stackblitz is a stripped down version of what we have in our codebase. It worked well in our testing and we were ready to ship it to staging that day and to production later that week. But we never checked if the contents of the individual tabs were rendering if the feature tab is turned off. The tab labels were in place and it felt enough to move forward as other tabs were untouched. In the final rounds of testing, one of our team members noticed a weird issue. Some of the tabs were not rendering the contents inside them.

It was a Friday evening and almost everyone has already shifted into the weekend mindset. This got everyone on their heels and we started debugging it. There were few API timeout issues in the console but that can't be breaking the rendering. We handled API errors gracefully for all the known cases. Any unknown errors will be caught and will be turned into something human readable. So it has to be something else.

We were trying to optimize the initial loading time and one of the change is to delay the off-screen components rendering until they have opened. It's an experiment that's happening in it's own branch. By any chance, that code got into development branch? I checked the commit history and ruled this out.

Luckily the same dev who discovered the issue also figured out why this is happening. We used to use bootstrap with angular and later migrated our codebase to Angular material. Our bootstrap implementation of tabs is just divs toggled with conditions based on the current selection. The conditions that hide and show the divs in bootstrap were copied when we migrated to Angular material. The divs were using a hidden attribute that checks the active tab. When we added the optional tab in the config object and toggled it, the feature tab is removed from the DOM but the config object still maintained the same tab order and count. So when we open each tab the inner condition was always false hiding the contents of the tab (Check app component and its template in the below example).

Once we found the issue fixing it was a debate. When asked no one had a clue about why the condition and config are there. The code is sitting there for a while and it bothered no one. The existence of a code block implies that it is tested and it is important. Everyone knows that removing those conditions is the correct solution. But we also kept asking what if we added that to solve something else? What if the condition is removed and the tabs fail in some other edge case? As a fix, we couldn't immediately remove the tab object and the hidden attribute from the inner content div. Instead, we rewrote the tab object by taking the optional feature tab into account.

This is a great example of the sunk-cost fallacy. We are maintaining code just because it is already there. We were forced to write new features to work around the old implementations. No one is ready to let go even if we know that's the right choice.

My takeaway from this is that it is harder to remove code than to add new code. A development team should be really careful about the new code they're adding and vigilant about removing any old code that's unnecessary really soon. Removing old code may not be easy as it sounds even from a well-written codebase. I'm actually a little late to the party, there are few great resources out there explaining how problematic old code can be such as @swyx's tweet here.

shawn swyx wang

@swyx

Gresham's Law applied to code:

Hard-to-Delete code drives out Easy-to-Delete code over time.

"Technical Debt" is the wrong metaphor. When we are so scared of our own codebase that we put on bandage after bandage, we should worry about "Technical Mummification" instead.

11:31 AM - 24 Jul 2020

46 228

I found this Programming is terrible article that talks great length about writing code that is easy to delete. In my experience, Code that is easy to delete is mostly well written and structured code. I hope this article and the linked resources provoke some thoughts on your mind. Do you have any similar stories? Share with me in the comments.

Note: To handle the legacy implementation around the tabs, I created a new task in Jira and now testing it after rewriting it. So it is getting removed after all, but with thorough testing.

How important a college degree is to get a job in tech?

Vignesh M — Fri, 19 Jun 2020 14:33:15 +0000

Recently, I've seen people discuss on Twitter about whether a college degree is required to get into a tech job and if having one gives you any competitive advantage over the self-taught ones. I believe I can add a cent or two to that discussion. I am going to tell my story and experience so it might encourage others.

I am a self-taught developer working for around 7 years now. I don't have a computer science degree or not even a bachelor's degree for that matter. In my observation, a college degree is not mandatory to get a job in the tech industry but having one will be helpful in various situations.

I am from India, so my experience related to jobs and hiring is mostly based on the Indian job market. Your country's job market might be different.

The good parts

You won't have a student loan and don't have to run every day to repay it. It can be daunting from my personal experience and from some people I know.
You don't have to spend X years of your life studying for exams and those years might actually be a head start for your career.
College degrees are becoming less and less relevant to the actual things you have to do on the job. So it is not assured that you'll land a job offer after finishing your degree or you'll be employable.

The bad parts

Companies may not hire you for not having a degree. In India, a lot of companies won't consider candidates without a college degree regardless of their skills or experience. This will limit your choice to startups and mid-sized companies.
You might sometimes find it hard to understand the concepts related to computer science. It is not impossible to learn them on your own. You need to be self-aware of your gaps and constantly work on improving them. For example, I had trouble with understanding the big O notion which is used to measure performance of the algorithms. I still have troubles with data structures and algorithms. It is possible that you might face similar issues.
In my personal experience, people tried to take advantage of me in negotiations. Since getting a job without a degree is pretty rare in India, they might have thought that I didn't have any other choices.
People are saying that your academic qualification is taken into account when validating your VISA applications. My US VISA (B1) application is rejected twice. but I'm not sure that's because of my educational qualification. It is not an official statement from US embassy, it was just response of some people when I asked about the possible reasons for the rejections.

My thoughts

Those saying a computer science degree is required to be a software engineer are likely to be gate-keepers. A degree has very less effect on how great a developer can be. Computer science and Software Engineering are two different things and having a degree might help but it is not a precondition to become a great developer. Remember, most of the real learning happens in the job. I know a lot of great devs in both category and vice-versa. Having a degree alone will not make you a great developer.

It is not very easy to get your first job without a CS degree. I had to take an internship without a salary for a few months and then I was paid a little stipend, only to be fired after 6 months. But It wasn't hard getting another opportunity with that little experience. From this I learned that acquiring real work experience is invaluable when compared to a degree.

Once you got your first job and gained some considerable experience, not having a degree will become less relevant. If you can spend the time and money on education to get a degree, go for it. Things will be much easier if you have one. But If you are not in a position to do it, consider putting some hard work in building your portfolio, and start applying for jobs.

Don't assume you'll have to know everything on the job description to be able to apply for the job. Companies will always be ready to negotiate on technical skills because it is easier to train people technically. When I applied for the internship I know next to nothing about coding, and I was selected.

I mean no disrespect to the universities or their curriculum, but after all these years we should really start questioning the relevance of teaching COBOL in universities (They taught me in Madras University). This is mostly from my personal experiences and I would love to hear your thoughts about it.

You got a job, now what?

You might feel intimidated by the things you don't know when compared with your colleagues. Imposter syndrome kicks in and you'll panic that someday they'll find you that you're not good. The little secret is your colleagues might also feel the same way. Our industry is filled with lot of smart people and insecurity comes bundled with intelligence. Try to use imposter syndrome and try to learn the following concepts as you gain experience.

Data structures and Algorithms
Different programming paradigms such as OOP and FP
Design patterns
Accessibility
Big-O-Notion (this should be part of #1 in my understanding)
Memory management
A low-level language such as C
Software development life cycle
Agile methodologies
1. Different estimation techniques
2. Different kinds of testing (Unit, Integration)
3. Relational databases

The above list is based on my experience and personal understanding of my week areas, as you grow into your career you should be able to identify and prepare your own list. In the above list, no one is going to be needing most of the items for their day to day job. But in an ever-changing industry, having a solid understanding of the basics is necessary to keep yourself open and flexible for any situation.

I hope I told everything I had in my mind related to this topic. Do you have a degree or not and what's your story of getting into the tech industry? Danny Thompson recently had an interesting thread of self-taught developer's story. Check that out if you're interested.

Why I started learning Rust and impressions after a week

Vignesh M — Sun, 10 May 2020 12:53:04 +0000

[Originally posted at vikky.dev]

I decided to learn one new programming language every year since 2019. I don't plan to become an expert in a particular language. But it introduces a lot of new patterns and broadens our perspective. In 2019, my choice was Flutter. I was advocating about Flutter to our team and did a few side projects (which are never going to see the light of the day). Flutter was a great choice for both joys of learning and the potential of building something for my own.

For 2020, I have been thinking about learning either Golang or Rust that revered by devs working on it. After some days of thought, I decided to go with Rust because of a few things,

In Rust, variables are immutable by default. Having worked with JS and PHP in complex applications, I can say that this is a great feature. My understanding of the immutable state and unidirectional data-flow is low. I faced a lot of issues due to the misuse of immutable state. Rust makes it hard to make those mistakes.
Rust doesn't have garbage collection. I never worked with low-level languages that need developers to manage memory. But I know how hard it can be, I spent many hours on V8 blog reading how the garbage collector for JS works in chrome. It is really interesting, how a language works, without dealing with memory management and without being GC as well.
Rust has first-class support for WebAssembly. I first saw the real strength of webAssembly in
Figma. Their site is one of the most complicated web application and it worked like a charm. This is what web apps have been struggling for decades. I was thinking to use WASM into real projects. But I'm not ready for implementing and supporting it in production yet. In real projects, deadlines and stability matter the most. Learning Rust will help me work with WASM and then start using them in production apps.

Once I decided to learn Rust I didn't start it until recently due to my procrastinating nature. In April, I was scrolling through twitter and decided to start with #100daysofcode. I was not a believer in the social part of learning but it helps to connect with relevant people. Also, It holds you accountable when you commit to it publicly. So give it a try, even if you're an experienced programmer.

Setup

Rust is easy to set up by using the rustup. run the below command, and let it take care of installing and configuring your environment.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

After installing, I tried to build a hello world application and got served with this.

error: linker cc not found.

This means that rust is missing some dependency that it needs for compiling code. I was not sure about why the rustup script missed this dependency. So after some googling, I solved it by installing the build-essentials in Ubuntu.

sudo apt install build-essentials

I am using Webstorm with Rust plugin and it works well enough for me.

Learning Materials & tools,

Rust has one of the excellent official documentation and tools in my experience. It took decades for PHP to build composer and Javascript to create NPM. Rust has a command-line tool called rustc which will let you compile and run Rust programs. The best part is you don't have to use it when you have cargo. Cargo is the official package manager for Rust. The packages built by the rust community are crates. You use cargo to orchestrate the crates you want in your codebase.

If you want to check for any crates, head to creates.io, and search with the keyword. Once found, add it to your cargo.toml file. Every time you run cargo build it will install the dependencies automatically (There is no separate install command AFAIK).

Dependency Management

To manage the dependencies Rust uses two files. cargo.toml, and cargo.lock which are like npm's package.json and package-lock.json. The cargo.toml will keep the list of dependencies required for your project. It is maintained by the developer.

The cargo.lock is a detailed record of your dependencies and their dependencies. It records the exact versions installed in your machine. This is useful to reproduce the exact version of the dependency tree on other machines. You should not edit the cargo.lock file because it will be overwritten.

You might have noticed the extension of the cargo.toml file. TOML stands for "Tom's obvious, minimal language" and used for config files in rust. You can learn more about toml here.

Like the NPM ecosystem, if you're building an end-user application, you should include the cargo.lock to your VCS. If you're building a library that others will be reusing, your cargo.lock must be added to .gitignore.

Building & Releasing

We're too early in our rust journey to worry about building and releasing. Unlike JS/PHP, Rust is a compiled language. That means to run even the basic hello world example, we need to learn how to compile the code and run it. You can do that by using cargo.

cargo build command can be used to build the rust files into binary executable. If there are any issues in your code, the compiler will throw errors. Rust compiler's error messages are really helpful. They offer a possible fix for the error if you read the full message (you should).

So assuming your code compiled, a folder named target will be created. The Target folder contains all the build artifacts and intermediate compile stage files. Keeping the intermediate files will make the next compilations faster than the first compilation.

There are two types of builds in rust, one is debugging another one is for release. The debug build is not optimized and contains data required for debugging. The release build is optimized and it won't keep anything for debugging. You can create a release build by running cargo build —release command.

Rust includes the dependencies within your final build. This means that your binary should work without any issues in most systems. But this comes with a trade-off. Including all dependencies will increase the binary size. Rust chooses maximum portability over smaller binary executable.

Language syntax & Features

Modules

Rust's idea of code reuse/sharing within a project is a module. A module is a set of functions grouped under a common namespace. There are a lot of built-in modules in rust such as std which is the standard module.

We can create our own modules within the current file or as a separate file. Conventional wisdom is group modules on their own files. For me, the syntax for importing an external module is a little confusing. I have only seen a small part of it and yet to dive deep into defining using modules. My take away here is that Rust supports what is possible in PHP for modules and importing, use statement, and as syntax.

Access Modifiers

Rust supports two types of visibility public and private. The public is defined by pub keyword but there is no separate keyword (AFAIK) for private. Wondering why?

Rust chooses private by default. This is different than all the other languages I know. In typescript, PHP public is the default. From experience, I know how hard it is when debugging or refactoring to know the actual usage of a method.

In Rust, if it is not pub it can't be used anywhere, period. This is a great design choice that aligns with the rest of the rust's design principles. It makes it impossible to make mistakes in this regard.

Variables

Variables are interesting things in rust. They are defined using let keyword. Variables are immutable by default. To make them mutable you must use the mut keyword before the variable name.

// default immutable variable
let age = 26;

// mutable variable
let mut age = 26;

The immutability as default will make you take a moment and think about the usage for every variable. In effect, you will start thinking about the collective state and data flow.

Rust is strictly typed, but we don't have to define data types for every variable. Rust will infer data types from the value or the usage of the variable. Rust's type inference is different than typescript. When the rust compiler can't guess a variable's type or if there is an ambiguity of types, the code will not compile. In that case, we must define a type for that variable and get rid of the ambiguity.

Data types

Rust's primitive data types are integers, Float, Character, Boolean. There are compound types such as Tuples, and Array. I had trouble grasping the limits of each integer type such as i8 or u8. I wasn't sure how to decide which type of integer I should use in a given place. This is important because you should not use more memory than you need.

I loved how Rust made me think about the low-level stuff such as how much memory does this variable needs. Usually, in typescript, we just type it as the number and call it done. But rust has the following data types for signed and unsigned integers.

To calculate the limit of each type, the manual gave a formula that is really useful. I must admit, that any programmer with a CS degree or anyone having experience with other low-level languages might find this trivial but it is hard for me.

A variable can store -(2^n - 1) to (2^n - 1)-1 where n is the number of bits. This formula is for signed integers. So i8 can store -127 to 128.

The isize and usize are interesting types because their size will be determined based on the architecture of the system that the code will be running. For 32-bit systems they'll be 32 bit and 64 for the 64-bit machines.

When you try to assign a value that is bigger than the range of the integer type, It is an issue. In debug mode rust panics. Panic is rust's name for errors. In release mode, the code runs but reduces the value to the possible value that variable can store. This reducing behavior is called wrapping.

Statement vs Expressions

Rust introduces us to the difference between statement vs expressions. This difference plays a major role in how we create and return values from blocks and functions. Also in How we can assign values to a variable conditionally.

A statement is something that state that a new value is created or a new item is created in the scope. Ex.

Let number: i8 = 45;

In other languages statements can return values, but in rust statements can't return any values.

let a = b = 10;

the above code is valid in Javascript. Both a and b will be assigned with a value of 10. In rust, this will result in a compile error.

An expression is something that can return a value. Rust is an expression based language. Most things you use are expressions. Such as calling a function, calling a macro, evaluating a numerical operation. Since expressions return values, you can use them on the right-hand side of an assignment. That opens a lot of possibilities and syntactic sugar.expression-based

let age = {
    let current_year = 2020;
    let year_of_birth = 2013;
    current_year - year_of_birth
};
// age = 7;

Notice that we created a new scope using {} that is an expression. You can return a value from an expression simply by not putting a ; at the last line of the expression. If you use a semicolon, the expression will turn into a statement and you'll be served with an error. This might be hard to grasp at first. It makes sense once you starts writing functions with expressions.

Functions

Functions are named using snake_case and start with an fn keyword. Unlike variables, it is mandatory to define both the argument and the return types of a function. Argument are typed using the usual : symbol, function return types though uses a weird -> arrow.

Functions are made up of a series of statements and expressions. If you want to return a value you can use the return statement. But, the last expression in the function will be implicitly returned. So we may need to use the return statement only when we need an early return based on a condition.

Control Flow

Rust has if and the usual suspects such as the while and for..in. Conditionals in rust are different. In JS, if you put something in a conditional the interpreter will try to evaluate them to a truthy or a falsy value. That leads to some unexpected edge cases. But rust will not try to convert any non-boolean values to boolean and will throw a compile error instead. Rust if is an expression. so you can do this.

let number = if condition { 5 } else { 6 };

For looping, there is a construct called Loop. It just loops over the statements inside it until we stop using the break statement. All the other looping constructs can be written using just the loop and the break.

fn main() {
    loop {
        println!("All work and no play makes jack a dull boy!");
    }
}

I also learned a bit about what is ownership and how Rust does its magic without garbage collecting. That's a huge topic and I should learn about lifetime in rust before writing about ownership. For now, just assume that your variables will be removed from memory once the code ran past their scope.

Final words

These are the things I thought important in my first week of learning Rust. It is exciting to see how useful rust can be in a web developer's toolkit. I am hoping to finish 3, 4 projects before the end of the year and to learn rust to an intermediate level.

Are you familiar with Rust or thinking about learning it? Comment here or DM me on @ShivEnigma. let's chat about your experience and see if we can work together on any open-source project.

How to negotiate for a better salary - Tips for Developers

Vignesh M — Tue, 03 Mar 2020 05:18:20 +0000

You might be a great developer with a diverse skill set but if you don't have the soft skills that are required, you may not be going to the place you've been dreaming of. Negotiation is one of those skills that are important for any job. Whether you're negotiating for an offer in an interview or negotiating for a raise with your company, there are some simple things that you should follow to yield better results.

Recently I was discussing in a twitter thread that is discussing salary discussion and how to negotiate better. I attended almost 30 interviews before joining on my current job and turned down most of the offers I got in the salary negotiation round. I can say that I learned a thing or two in those situations and that twitter thread gave me enough motivation to write this down.

Note 1: This is written mostly based on the Indian job market and I am not aware of any other country's job market, but most of these points can be applied to any job anywhere.

Note 2: This is written with experienced developers in mind. If you're on the first 3 years of your carrier you might be still learning a lot, you're welcome to read this post but I am not recommending this advice for you.

1) Know your value (Market research)

First and foremost thing is to know how much you're worth as a developer. You should be aware of the average market rates for your skillset and experience. Companies will mostly try to stick within the market average unless they're in need of an urgent resource. But in most organizations this information is confidential and one should not reveal how much they're getting paid to their peers. This is partly for good reasons and partly used by some companies to take advantage of people.

So the only way to get this information is to get it from the community of developers around you. Go to your local meetup group, WhatsApp/telegram groups for developers and try to talk to them about it. To yield better results, share an anonymous form with the group and you'll have a better chance of getting that information.

There are online sources of information such as Payscale which provides this information along with further advice on your career path, but I am skeptical about the accuracy of the information. Recently there was also a twitter trend #KnowYourWorth in which a lot of people posted how much they make and someone did a stellar job of making a beautiful website with that information grouped by countries. Chances are twitter might be more accurate than payscale's data because it is very recent.

I suggest you use two or three methods of finding this information and then find an average between them. Try to have your expected salary around the average so you'll have a better chance of getting what you want.

2) Don't reveal your current salary

This is a great trick used by a lot of recruiters to limit your negotiating power even before you attend the first round of interviews. Mostly on your first interaction, they will ask you about your current salary. This is a tricky question and it is really hard to work your way around this.

Why you shouldn't reveal your current salary?

Because the companies are trying to use this information to determine what they can give you. They will bluff you with things such as 30% hike is the industry standard when switching between jobs. But the reality is there is no such thing as the industry standard. Companies will pay much more than what is being paid for the same role if they are in urgent need. After all, if the 30% hike is the highest limit you're going to give, why bother interviewing and having a salary negotiation round at all?

Don't fall prey for the tricks of a recruiter who is trained for this. So how do we handle the question?

The very straight forward answer to this question would be "I don't want to reveal my current CTC, let's discuss your budget and see if my expectations are in that range". Any decent recruiter would understand that you dodged their bullet and should move on by saying their budget. But some will counter you that it is absolutely necessary information for them to process your application.

If they insist on wanting that information just tell them your current CTC and let them know, you wouldn't want the current CTC to have any effect on your expected CTC before opening it up and let them know you'll not attend the interview if they pull up the industry standard thing when negotiating.

Another better way to handle this is that saying them "I can't share it now, I will share the current CTC later in my salary negotiation round. let's talk about expected CTC now". This is better because you've given them a hint about what are your expectations and then they can decide if they can afford you or not.

If you haven't revealed your salary in the first communication with them, you can avoid stating it in the final negotiation round as well, use the same technique of I don't want to reveal it, let's talk about what I want here instead of what I am getting now.

Doing this in the first round will be harder than doing it in the final rounds because the people in the final rounds have the actual decision-making authority and if you refuse to reveal your current salary they can actually work around it and give you better options.

Unfortunately, some of the recruiters who will contact you on the phone themselves believe that the 30% industry-standard thing is real and it'll be a lot harder to convince them otherwise. In that case, if you're not in a high need of a job respectfully refuse to reveal the salary and let them know you're open for discussion if they can work without knowing the current CTC. If they get mad and disconnect the call let them be. If enough people started doing this they will drop using this trick altogether.

If you're in a high need for the job you already lost most of your negotiating power (trust me, HRs can find this without directly asking you), one way to solve this is to do job searches when your position in your current company is not weak or things are not really bad. Another way is to have enough savings to be able to manage one or two months without working on a job.

In any negotiating situation, the upper hand is to the people who have nothing to lose if the deal isn't through. So always be prepared to walk away from an interview if your terms are not met.

3) Don't mention the expected number first

This is the 101 of salary negotiations, you should not open up about your expectations first because the one who opened up first might have been the one who sold himself shortly most of the times. If you can avoid or can talk them into opening up you can know what they can offer and then you can counter-offer.

If they're giving you a number its highly likely that they are ready to give you more than that, so use the market research information you got and then increase some X amount from it and then ask for it. You'll most likely be getting what you wanted if you done really good in the interviews.

But in some situations, if they are better in negotiation than you're they'll try to get the number out of your mouth and holding it for long is not a very good strategy. If you're asked more than once to say your expectations, don't give an absolute number. Give something of a range in which the lower end of the range must be a little higher than what you actually expect from them. If you give people a range they'll most likely pick a lower number in that range.

4) Learn the demand of the position

Like I said before, most companies will pay a lot higher than their usual pay scale if there is an urgent opening. If you are going to an interview try to learn about the urgency of that position from an employee of that company and use that information. If you can't get it from an employee, you can get it from the technical interviewer you're talking to.

Most of the technical interviewers might know about the urgency of the position, you can get the information from them by asking indirect questions about the project you're going to be working, how long this position is open, how many interviews were done for this position. This information not only helps you to learn the demand but to learn more about the work culture of the company as well. In any interview, you should be spending as much time as possible with the technical team and try to learn how it is to be working there because money is not the only factor to choose a job.

5) Market yourself as a brand

This is a piece of great advice I learned from the Soft Skills: The Software Developer's Life Manual by John Sonmez. It means a developer should think of himself as a brand and should try to market himself as one. This includes writing blog posts, podcasts, speaking in conferences, organizing events. If the technical team that is going to interview you know about you and your work already, your chances of getting what you want is really high.

Most of the salary negotiation round's outcome is based on your performance and the impression you made on the technical interviewer. Imagine if you are already known to be a great developer and impressed them before even getting into the interview. If you're known as a great developer it is also easy to learn a lot about the position because the people from that company will be more willing to have a conversation with you.

6) Using an offer to get better offers

This is where things start to get a little gray. I won't say that trying to get better offers using current offer is wrong but you should be fair and honest in the process. I have been on both sides of the recruitment table and learned that how much it costs for a company to interview and release an offer and how it affects if someone says that they're not joining on or before a week of their joining date.

If you used your negotiation skills and got what you've asked, the right thing would be not to attend any further interviews. But if they negotiated back and you're getting a lesser offer and you want to use this as leverage, you can do it fairly by doing the following.

Don't accept the offer right away if you're not satisfied with the given offer (In fact, never accept an offer without a day of thinking on it). Ask them time to think about it and let them know you're not completely satisfied with the given offer and you'll be open for other companies to approach you. If you do this chances are you might get a slightly better offer from the same company within a day or two.

Often They will try to make you accept the given offer and you should wait for at least 3-4 days before accepting that offer. Companies will push you to accept an offer but in reality they can wait longer because interviewing another candidate is costlier than waiting a few days for you to accept their offer.

In the meantime if you are contacted by any other company let them know you have an standing offer and we can continue if they are willing to offer more than that. Also let the first company that offered you know that you're in discussion with another company now and they are willing to release a better offer. This might sound wrong but what's actually wrong is doing it under the table and giving surprises to people.

If you're open about this any decent company will appreciate your honesty and try to counter what the other company has to offer. In the worst case, they will pull your offer back and you have to go through another company's interview where you may or may not get the offer. If you haven't got anything with the new company, you can contact the first company and check if the position and the offer are open now.

This approach is a bit of a mess in my opinion and I would just take the high road if possible. But there is nothing wrong with doing this because companies will interview multiple candidates to get a better candidate and this is no different than that. What makes the real difference is how honest and open you're about your actions to everyone involved.

Don't do's in a negotiation

Don't be greedy. if you asked X and given X, don't try to ask more again. It is over when you're given what you've asked.
Learn whether you have an upper hand or not and use these techniques only when you're in a demanding position.
Have an honest assessment of your skills and whether you can do justice for the amount you're asking.
Respect the time and investment the company is making on interviewing you and try to be fair to them (#6).

That's all I have to say about negotiating salaries, I don't consider myself an expert in negotiation. I have been doing really bad negotiations since the beginning of my career. But I learned from witnessing some of the good negotiators doing it and practiced those in actual interview situations. Negotiation is a skill, just like all the other skills it can be practiced, mastered.

Thanks for reading so far, I would love to hear your thoughts on the blog post feel free to comment or DM me on Twitter or LinkedIn.

A Deep Dive into Javascript Array Methods - Part 1

Vignesh M — Wed, 22 Jan 2020 19:13:19 +0000

[Originally posted at vikky.dev]

Javascript is great, it is single-threaded but fast enough for most use cases, it is easy to get started with but hard to master. 2019 has been great for Javascript and 2020 is not going to be any different. In this context, I am focusing more on writing beginner-friendly articles on Javascript this year.

In Javascript, we mainly use two data types arrays, and objects. Technically arrays are also objects in javascript, they have some prototype methods for traversing and mutating arrays (more on that is for another blog post). To work with arrays javascript has a lot of methods and sometimes it can be overwhelming to figure out which method does what and what arguments it takes, whether it modifies the original array or it creates and returns a new array.

In this post, I am going to explain some of the most used array methods based on how I understood them. I have also seen people use different methods for different purposes, like using map/filter to loop over an array, it works but that's not it meant to be used for. Hopefully, after reading this series of posts you should be able to pick up any trivial use case and work with the right JS method for it.

I originally planned to write this as a single blog post but after seeing the amount of information need to be put for each array method, I split it into a series of blog posts. This is the first part of the series.

1) You want to loop over an array (forEach)

array.forEach is the semantically correct method for this purpose, I have seen many people use map as well, it works but map means that you're somehow modifying the original array and forEach means you don't.

When I say about modifying an array, I am not saying that it is not possible, I rather mean it should be avoided. To keep your code clean and to easily let other devs know your intention of a code block.

The above code loop over an array and prints each element in the console. This is a very basic implementation of forEach.

Method Signature

callback - The function which will be called once for each element in the array.

currentValue - The current element that is being iterated in the array
index (optional) - The index of the current element in the array
array (optional) - The array that is being traversed

thisArg - This is interesting before ES6 arrow functions. you can specify something that can be used as this inside the callback function. If you don't pass thisArg, the value of this will be determined as to how a function's this will be determined.

Things to remember

forEach does not mutate the array which is being traversed, but the callback can do it. (I recommend not doing it for obvious reasons mentioned down below).
If the array is modified when forEach is running, some elements might be skipped as forEach doesn't make a copy of the array (Example).
Elements that are appended after the forEach has started will not be traversed.
undefined, uninitialized values in the array will not be traversed in forEach.
forEach is not chainable because it returns undefined.
Early termination out of forEach is not possible, you can only throw an exception. If you need early termination, use for or for.. in loop.
If callback is an arrow function, thisArg can be ignored as arrow functions lexically bind to this value.

2) You want to transform an array in some way

Transforming means that you're creating a new array by applying some sort of transformation to each element in the original array. let's add numbers to the languages array we used in our previous forEach example.

Method Signature

callback - The function which will be called once for each element in the array.

currentValue - The current element that is being iterated in the array.
index (optional) - The index of the current element in the array.
array (optional) - The array that is being traversed.

thisArg - This is the same as we saw for forEach, used to refer this value inside callback.

Map receives a function as the first argument and an optional index as the second argument, in the callback function you'll receive each item in the array as an argument and you must return the element after applying your transformation.

Things to remember

You should not use the map in either case below,
1. You're not using the newly created array that map returns.
2. You're not returning anything from the callback.
the map does not mutate the array which is being traversed, but the callback can do it. (In short, don't do it to avoid unintended consequences).
Elements that are appended after the map has started will not be traversed.
the map is chainable with other array methods.
Early termination out of the map is not possible. If you need early termination, you're using the map in the wrong place.
The callback must return value otherwise the result array will be an array of undefined values.
If callback is an arrow function, thisArg can be ignored as arrow functions lexically bind to this value.

These two are some of the frequent use cases I often come across in day to day work. I tried to write it as simply as possible to my understanding and I hope you find this useful. If you think if something has to be added to the post feel free to let me know in the comments. Try to play with these two methods a little bit if you find them difficult or confusing. Remember, practice is what makes things stick in your memory not just reading.

RxJs - You're probably doing it wrong

Vignesh M — Sun, 12 Jan 2020 13:36:00 +0000

I have to agree that the above title is pretty strong and kinda click-a-bait. But trust me, I was using the library wrong, I was not utilizing it to its full extent and was writing code which should be far easier. I am nowhere claiming to be an expert in RxJs but I have done these mistakes in the past and still witnessing others doing the same, so I took a chance to look back and wrote what I should have been told a year or two ago about RxJs.

To understand the problem behind this let's get to the background, if you're like me, you're probably forced into RxJs by Angular and you were just using it only to subscribe to HTTP calls and not even bothered to look at its documentation.

I hope few of us tried to use RxJs and tried to push our limits but failed or gave up, why RxJs seems so hard at the beginning? Like everything, RxJs indeed has a learning curve to it but it isn't the reason. It is our approach towards programming, most of us working in either procedural or OOP style and RxJs requires a little different approach towards how you handle events, input and output.

RxJs has two distinct characteristics,

It treats any event or input as a stream that can flow through various functions, operators.
It mostly uses pure functions to produce values and relies on them to keep the state error-free.

When I started with RxJs I had no clue how or when to use those operators it has, because it was not very obvious. All those RxJs tutorials I've read mostly never used any practical examples. They'll create a observable.from('thin air') and manipulate it, but I was never able to imagine where those operators will be helpful. I have tried my best in this post to stay relevant and to use real use cases as examples.

Map operator

Map mainly useful for transforming data. What it does is that every time your source observable fires, it takes the value and send it to the function you defined and then returns the result of that function as an observable. Imagine the following code which is not very unusual in any angular project.

The data returned from the API is all we care about, So instead of manipulating it inside the subscription, we can use the map operator.

The map operator is meant to do all the transformation with the observable data and to return a new observable which the subscribe function will receive. But what if the API returns an empty collection? our map will fail. We will see how we can fix it.

Filter operator

Filter operator is similar to array filter, in fact, all the operators are inspired by the Array functions in JS, so when your source observable emits a value, the filter takes the value and sends it to the predicate function you defined and if the function returns true it emits the observable.

We use the same functions we used in our previous map example but by safely checking if there is any data returned or not. Normally we would use an if condition,

In the above code, we are acting on the data regardless of whether it satisfies our condition or not. We can rewrite this using the filter operator like below, which will only act upon the data if it satisfies the predicate function provided.

The above subscription will only be reached when the API returned some data.

take

Imagine if you have a source (observable) that emits multiple values but you only care about the first n values. For example, if a user clicks on a button and you're making a call for that, if you directly bind your HTML event to the HTTP call, chances are multiple subsequent HTTP calls. But we can use take(1) to prevent this as it'll emit subsequent clicks after the first click.

You can see this into play in this stackBlitz, try commenting the take operator in the click event and you'll see it fires HTTP request each time you click the button.

Note: This is not the best way to block multiple requests from being fired, for example, you can't make the second request even after the first request has returned.

forkJoin

Forkjoin is a combination of operators which can be used mostly to get rid of nested subscriptions. Imagine that you have two http requests which are not dependent on each other, but you need the results from both of them to perform some operation.

Let's take our previous example, you thought of displaying pictures from both the Voyager and the Apollo side by side and for that, you are querying the NASA API, each request is async which means they'll return in their own time. But you want to display the data for both of them at the same time. Your basic instinct would be to make the first HTTP request and inside that subscription make the second request.

Nested subscriptions will work but they might create timing and memory leak errors, which is the last thing you might want to deal with. They are not very easy to read, debug as well. We should use the forkJoin operator to make both requests in parallel and wait for them until both of them arrives.

Forkjoin will take both of your observables, subscribe to each of them and once both have been fired, it will return you a new observable by combining both results. You can assume this as being similar to Promise.all()

Warning: If any one of the inner observables fails or doesn't emit, forkJoin will never emit a value.

Epilogue

If you have made it this far, I have to thank you first, I am still new to writing blog posts on my own and I would love any feedback. I am open for any RxJs horror stories as well in your codebase. Kindly let me know your thoughts in the comments.

[Originally published at https://vikky.dev/how-to-rxjs/]

Why I am Switching to Dvorak from QWERTY?

Vignesh M — Sun, 12 Jan 2020 13:23:56 +0000

As Developers, we are sitting in front of a computer and typing all day. If not careful, we tend to develop some bad habits which put our physical well-being at risk. We have to find the best chairs, keyboards, postures and make sure that we are not doing any long term damage to our body. I always tried to be conscious about posture when working and observer my peers and let them know about it. But keeping a good posture is the basics, there is a lot more to stay healthy when we're working on a desk for a long time.

We're almost spending more or less a quarter of our life on our desk. I believe that companies should think about this and provide better ergonomic support. For example, the desks we are using in most offices were designed for desktop computers. If you're using a laptop in one of those desks you have to crouch for all day and strain your neck and backbone. In this case, Consider buying one of these laptop stands. This will elevate the laptop to a better position. You'll also need a separate keyboard and mouse if you start using this kind of stand.

The next big thing after posture is how you keep/move your hands while typing and using a mouse. Many programmers were diagnosed with carpel-tunnel. They changed their lifestyle and/or gone through surgery to come over it. I have been thinking about improving my desk and working habits better for some time now. This QWERTY change is part of the effects of that thought.

QWERTY

For background, QWERTY is one of the most used and unchanged things in computers from their inception. Some people say that QWERTY was designed to slow down people from jamming the mechanical typewriter. But it's not proved to be an absolute fact.

In my experience, qwerty does make typing two letters a little difficult than it should be. It also placed some of the most used letters little out of reach. The result is, we have to make rapid movements across the keyboard even to type usual English words.

I am a decent typist in QWERTY who is standing around 65-70 WPM. Typing at this speed means making many finger movements fast. Keep doing it for long, you'll feel a pain in your wrists and elbows. I also drive a motorcycle for my commute. On a bad day's traffic, I can feel pain in my wrist even before getting into the office. The increased throttling and clutch usage in heavy traffic is a catalyst for the pain.

I haven't developed any carpel-tunnel yet, but I am worried that end up getting it. I thought about it and decided to give Dvorak (Programmer's Dvorak) a try. I have been thinking about making this switch for a long time. I got enough motivation once I started to feel very occasional pain in wrists when typing for long.

Dvorak

Dvorak is created by August Dvorak in 1936. It meant to replace QWERTY. Due to the training and changes required to replace QWERY, it never became mainstream. In my previous encounters with Dvorak, I found it to be a far comfortable layout than standard QWERTY.

A lot of people claim that Dvorak increased their typewriting speed but I don't think it'll increase my speed. Actually, after started in Dvorak for two days, my QWERTY speed also fell down around 5-10 WPM. I'm not even sure if I'll ever be able to type around the same speed (65-70 WPM) using Dvorak. But my main goal is to feel comfortable and maintain my physical well-being.

Trade-offs

Dvorak is an ANSI standard and it has first-class support in Linux, Mac, and Windows. We don't need any fancy keyboards (I would like this one though.) to switch to Dvorak. Saying that, using Dvorak can have a few issues or discomfort in general.

Once you got used to Dvorak, using other's machines or letting others use your's will be difficult. This can be solved by enabling keyboard shortcuts to toggle Dvorak and QWERTY.
Almost all the keyboard shortcuts are configured based on QWERTY. Using shortcuts becomes awkward after switching to Dvorak. This can be solved by using an auto-hotkey script.
Dvorak also places symbols in hard to reach places because they're not most used in English. This makes it hard for programmers to work with Dvorak. For this, there is a modified version of the layout called Programmer Dvorak. That makes typing programming symbols like brackets much easier than QWERTY.

I've started using Dvorak on 14/11/2019, I am still using QWERTY primarily. But I am slowly increasing using Dvorak every day.

When trying different layouts, for best results switching cold Turkey is the right way. But in my work, I can't afford a slow-down at this moment. so I am taking it as gradually as possible. If you're considering making the switch, try both approaches and see what works best for you. I'll also come up with another blog post about my experience after some time.

I hope everything will be good and I'll be able to go full Dvorak soon.

[Originally published at https://vikky.dev/qwerty-to-dvorak/]

How to become a better interviewer

Vignesh M — Sun, 12 Jan 2020 13:20:08 +0000

Interviews are hard to get right, this is not for the candidates but for the interviewers as well. There is a lot of guidance available for the candidates but not much advice for the interviewers. In an interview, you might think the test is only for the candidate, but it's not. When you're judging the candidate, the candidate is judging you and your company.

I've been interviewing for a few years and I was lucky enough to be with some smart people in the interview panel. I did a lot of mistakes and learned from them about what one should do and should not do as an interviewer. I am putting together what I learned and looking forward to engaging in healthy conversations about this. Feel free to write your thoughts to me.

Respect

The first thing is that we should respect the candidate. Respect should not be in the words. We have to accept we're not superior to the candidate in any way because we're offering them a job. I've seen a lot of people with this superiority and it is remains of Feudalism. We should eradicate it from our minds and culture.

In today's job market, there are a lot of openings and a shortage of talents. Top talents won't care much about losing or walking out of an interview because there is plenty of fish. You don't want to miss a great talent because of the way you treat them.

Time

It's been said a lot of times that you should not be late to an interview. I have seen companies expecting people to wait long, because their team is unavailable. No one bats an eye when companies do this to candidates. We should respect the candidate's time as much as we care about ours.

The technical team can be working late at night or coming late to work because of client timings. We had this exact issue at my work and we discussed and arrived at a plan which respects everyone's time.

Things you can do,

Make telephonic interviews whenever possible and applicable.
If you plan to give system tests to the candidate, inform them before the interview date so they can plan better.
Have a backup interview panel if the planned interviewer is not available.

Discrimination & Bias

Discriminating or biasing based on Gender, Appearance, Caste, Nativity, Age, etc., is not fair and professional. You're entitled your opinion but never bring your prejudices to an interview. It's always important to start with a clean slate and try not to bias towards anything.

Remember as an interviewer, you're not representing yourself. You're representing the company you work for. The candidate perceives your words and actions as the opinion of your company.

You should stick to what's defined in your official HR policies. Your opinions shouldn't matter inside the interview room. If your company has a custom that is biasing against something (like Gender, Age), either fight or flight.

Empathy

Attending interviews is a tiresome task. Most people won't search for another job when everything is good with their current one. They'll be under a considerable amount of pressure in every interview. As interviewers, we should put ourselves in their shoes and try to be empathetic. Start with a casual conversation which comforts them before starting up with technical questions.

If you feel that the candidate is nervous in the middle of the interview,

Offer them a small break
Ask them if they need some water or anything to get them back in their comfort zone.

Remember, It won't take much for you to be on the other side of the table and go through the same thing.

Start with good faith

In some interviews, I felt that the interviewer fixed their mind to reject me or trying to find the reasons for rejecting me. It is not because they asked me difficult questions but it felt that way. Fixing your mind on the result is very different from trying to get the best of a candidate.

You might have had a rough day at work or you have some personal issues, but that should not affect the interview. Always start with a positive mindset such as can we fit this person in our team? How he will impact the team and the company's goal.

Taking a short break before an interview will let go off some of the steam and you'll be able to do better.

Showing off

As an interviewer, never try to show off what you know. I know It is very tempting to prove that you're better than the candidate. In an interview, it doesn't matter what you know. What matters is what the candidate knows and whether they're a good fit for your team or company.

It doesn't matter who you are in your company when interviewing never talk or showcase yourself through questions. It earns neither the respect nor the impression you've been starving for.

Be open for different opinions and thoughts

You're asking a question and have an answer in your mind. The candidate answers it with a different approach. You should not expect them to say the answer you have in mind and grind them until they arrive at your solution. Every problem can have more than one solution. Our job is to check if the given solution solves the problem.

Everyone is coming from different backgrounds and we can't expect two people to agree on an exact solution for any given problem.

Skills Expectation

For every job opening, there must be some sort of basic skill requirements. We should ensure that the candidate fulfills that skill and can work and scale on that role. Please don't expect people to be overly qualified or to be aware of things that you are aware of. You can be an extremely talented geek but not everyone is built the same way, so their mileage may vary.

I've had this problem when I was starting to interview, I used to reject people because they don't know as much as I thought I knew at that time, My lead advised me to let go of this attitude and to have realistic expectations.

Don't expect a fresher or a one year experienced Junior developer to solve a complex architectural problem. Don't expect a front-end person to write complex SQL queries. Don't ask a Junior web developer "How many files are created when I create a table in MySQL?" because it doesn't really matter how many files are created.

So have a realistic expectation of skills required for the current position and ask relevant questions. If you don't know what it is really, talk to someone in your team or company. What is important is that if the candidate is ductile, he/she has the ability to scale, and reach out of their grasp.

Space for discussion

An interview is a two-way street, please don't assume that only you have the right to question. Always ask them if they have any questions before finishing up the interview. It really helps to understand the candidate better based on their questions.

Similarly, When the candidate is answering your question don't interrupt them with another question, let them conclude. if they are too elaborate on something, politely let them know about it to save time. Both of your time is important.

Evaluation

If a candidate answered 7 questions correctly but missed the last 2 or 3, would you now select them or reject them? The human mind tends to go with the last 3 and decide that the candidate is not worthy of it.

Evaluating a candidate should be an informed decision based on their overall performance, not just from an excerpt of the interview.

Conclusion

These are the thoughts I collected in my experience so far, I understand if you disagree with some or all of them. My experience of interviews might be very different from yours. But there is one universal truth, your skills can take you only so much, your attitude and humility can get you to places that you never imagined.

Let me know your thoughts in the comments section.

[Originally published at https://vicky.dev/how-to-become-a-better-interviewer/]