Month: April 2020

bookmark_borderWhat is hoisting in JavaScript?

Posted on by kalkus

What is hoisting is one of the standard JavaScript recruitment questions. For some devs it’s one of the quirks of JavaScript, for others it allows understanding the language deeper. Let’s take a look at the example:

console.log(foo);  //returns undefined not ReferenceError exception 
var foo;

Console.log will not throw the exception. It will print undefined.

Why?

In most of the programming languages, we should have some ‘variable undeclared’ exception. In JavaScript, when the code is executed, the declarations of the variables (declared using var keyword, but not let!) and functions are hoisted, moved to the top (of the scope).

Important thing to notice is that initializations are not hoisted.

console.log(foo);  //returns undefined  
var foo = “bar”;

But why do we need it?

Well, if we need it or not is a good question, but let’s take a look at the example of how hoisting can be useful. As I said before – declarations of functions are also moved up. Therefore we can use the function before it’s declared:

sayHello("Mark");

function sayHello(name) {
  console.log("Hello " + name);
}

To read more about the hoisting see: https://developer.mozilla.org/en-US/docs/Glossary/Hoisting

bookmark_borderWhat does question mark and dot operator ?. mean in C# 6.0?

Posted on by kalkus

C# 6.0 introduced new operator – null conditional operator ?.

The way it works is very simple. It checks if the left part of the expression is null and if it’s not it returns the right part. Otherwise, it returns null.

Simple example:

var thisWillBeNulll = someObject.NullProperty?.NestedProperty;
var thisWilllBeNestedProperty = someObject.NotNullProperty?.NestedProperty;

Executable example:

//Rextester.Program.Main is the entry point for your code. Don't change it.
//Compiler version 4.0.30319.17929 for Microsoft (R) .NET Framework 4.5

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text.RegularExpressions;

namespace Rextester
{
    public class Person
    {
        public string Name { get; set; }
    }
	
    public class Dog 
    {
        public Person Owner { get; set; }
    } 
    
    public class Program
    {
        public static void Main(string[] args)
        {
            Dog dog = new Dog();
            Console.WriteLine(dog.Owner?.Name == null);
            // this will print True
            dog.Owner = new Person() { Name = "Fred" };
            Console.WriteLine(dog.Owner?.Name); 
            // this will print Fred
        }
    }
}

The above example can be executed here: https://rextester.com/TBC19437

Documentation: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/member-access-operators#null-conditional-operators–and-

bookmark_borderDaily at 9 AM

Posted on by kalkus

A software house is not a convenient store. The work can start pretty much at any time. What’s important is that people who perform the tasks together can communicate, meet, and share their thoughts. This flexibility is important because the chronotype is said to be like a human height – you can’t change it without breaking a bone.

What is chronotype?

Chronotype is being a night owl or the morning bird – it’s the preference of the organism to wake up early or stay late. Apparently, in traditionally living tribes it breaks down so that about 25% of the population likes nightlife, 25% morning, and the rest something in between. This would serve the survival of the group because at every moment of the night and day there is someone who watches.

So we have Mark, who gets up at 5 AM and Bill, who falls asleep at 1 AM. Theoretically, they both have flexible working hours and must meet from time to time on a call.

Then scrum master sets up the daily scrum meeting at 9 AM.

Mark is cool, he comes at 7 AM, he will eat breakfast, he will poop, he will browse cat pictures on the Internet and he is ready and fresh for confession from yesterday’s tasks.

Bill, on the other hand, gets up sleepy every business day, because he would like to come at 12 and cannot sleep earlier. Frustration grows, and IQ decreases. He sleeps well only on weekends and holidays. Every morning he’s in a hurry, sleepy at this damn daily and the whole day too. In addition, the team looks at him crookedly. Lazy, late, sleepy, cursed black sheep!

Meanwhile, research suggests that the night owls are more intelligent, not lazy: https://www.psychologytoday.com/us/blog/the-scientific-fundamentalist/201005/why-night-owls-are-more-intelligent-morning -larks

This seemingly unimportant organizational habit – organizing daily at 9 AM – drives the significant part of the team inefficient. How much of it depends on luck, but statistically around a quarter. There’s no reason why daily meetings can’t be scheduled at the end of the day or in the middle of it. It is simply a habit, a ritual that has spread and is mimicked in a reckless way.

To sum up: when organizing a scrum team, it is worth paying attention to the preferences of its members regarding the hours in which the meetings are to take place. This also applies to meetings at around lunchtime, when some people may simply die of hunger because of discussions lasting several hours.

Early daily scrum meetings can reduce the performance of the team as long as any night owls are the members. It is worth remembering.

bookmark_borderSenior developers’ greenfield

Posted on by kalkus

You have a million dollars to spend and an idea for a product. What would you do?

You would recruit the best people and believe that their experience will make the team effective in creating high-quality software, right?

But…

You come after three months and you see that:

  • the first month passed on discussions about branching strategy, test architecture, deployment, application, cloud selection, CI / CD technology stack and the application itself, choice of linter and code formatting standard and several other similar topics
  • one and a half months it took to implement the infrastructure in the cloud, automatic deployments, application architecture and refinement of tasks
  • in the last two weeks, the team have delivered the header and footer as well as user login and registration

You feel hypertension pressing against the walls of your arteries, your kidneys are itching from adrenaline production, and tooth enamel creaks from nervous tension. However, you also learn that:

  • Max is going to quit because he disagrees with Peter regarding the chosen infrastructure of the application
  • Anne has hardly spoken for two weeks and nobody knows what she is doing, but apparently she is configuring the cloud
  • Half of the code was written by Xi
  • Matt is hated because he does not accept pull requests
  • Mark wants to be a team leader even though you have agreed that there will be no team leader

You return home, open 18-year-old Glenfiddich and with each sip, you become more and more convinced that IT is a swamp.

What went wrong?

Of course, the described situation is exaggerated, but there is a lot of truth in it. There are two problems – greenfield and seniority.

Greenfield is a new, fresh, pristine project – one that is built from scratch, where devs have the freedom to choose technology, practices, architecture, practically everything. This is the dream of many programmers locked in the cages of maintenance of legacy systems.

High seniority is good, valuable, almost priceless, but in everything you need balance, and good is never pure – there is always a flaw in it. The flaw of the senior developer is his ego. Many experienced programmers are convinced that they have seen so much that they think they are always right. The truth is, however, that everyone is sometimes wrong, and that many opinions in IT do not matter – or they do, but the profit is less than the cost of not making a decision.

Gathering many seniors in a greenfield project is a risky venture. The ability to choose technology and architecture inevitably creates a discussion in the first phase of the project. The more seniors, the more frenetic this discussion will be. Juniors or mids will rather adapt – seniors will usually stubbornly defend their opinions. This is understandable, of course, but it is disastrous for this type of project.

A ‘self-organizing team’ is an additional source of the problem. When there is no official leader, there is a fight for power. When there are no obedient sheep, because we selected only old stagers – we have a problem.

Seniors devs’ greenfield is a synonym for failure. During the selection of the team members for the greenfield project, let’s not be tempted to choose only experienced professionals. The selection of an official leader is also a good idea – this will speed up the building of the hierarchical structure, reduce the struggle for power and give clearly defined responsibilities to team members.