DEV Community: Marco Kühbauch

GitHub Copilot is not stealing our jobs

Marco Kühbauch — Fri, 20 Aug 2021 13:48:57 +0000

It's not. And never will. You can relax and stop searching for alternative
career ideas. In my opinion Github Copilot is one of the best things that
could happen to us developers in the current state of (web) development.

In this blog post I will explain why I think this is the case.

What you can learn from this blog post:

What is GitHub Copilot
What can GitHub Copilot do
Why it's not stealing our developer jobs

What is GitHub Copilot

GitHub Copilot was announced on June 29th 2021 as your AI pair programmer.
You can read the introduction blog pos over here:
https://github.blog/2021-06-29-introducing-github-copilot-ai-pair-programmer/

It claims to help you write better code.

GitHub Copilot draws context from the code you’re working on, suggesting whole
lines or entire functions. It helps you quickly discover alternative ways to
solve problems, write tests, and explore new APIs without having to tediously
tailor a search for answers on the internet.

As you type, it adapts to the way you write code—to help you complete your
work faster.

As soon as I read the announcement I was hyped. I was tired of writing the same
JavaScript code over and over again. Mapping over arrays, manipulating part of
the data and returning it as some sort of HTML. Sometimes I feel like I'm
doing nothing else than that.

I immediately felt like I knew where GitHub Copilot would make my life easier.
Without getting scared that it would do ALL the work.

What can GitHub Copilot do

As I saw the first few posts coming in from people who where lucky enough to try
it out, I felt supported in my gut feeling, in my assumption in what Github
Copilot could do - and what not.

People showed how GitHub Copilot knew where they were going when writing a
specific function. It took the tedious work from their shoulders by writing
out the detailed specifics for them. And this was so cool to see.

I entered my email to join the waiting list and after a few weeks I got the
invitation to the repository and was able to install the Visual studio code
extension.

My first few tries were pretty basic. I defined a function and GitHub Copilot
knew by the name of this function what logic I wanted to write inside of it.

I created a new file, imported React and it suggested the skeleton of a whole
functional component.

I started to use the Array.prototype.map function
on an Array of data I got from a GraphQL query and it suggested to manipulate
parts of the data and knew how to return it as semantic HTML.

I'm still at the beginning of using the advantages of GitHub Copilot but I
already miss it here in Notion where I'm writing this blog post as there are no
suggestions.

But GitHub Copilot is not just auto-completion. You can turn comments into
code. You can use it to write repetitive code. It can even write tests for
you. And it can show you how to write a certain part of your code in a different
way.

I already notice how this makes me faster and more confident. I really feel
like I have a copilot with me all the time, a second pair of eyes, supporting me
and making my code less error-prone.

This gives me a lot of confidence when tackling new problems.

Maybe this will eliminate the time spent on searching the internet and
understanding how Array.prototype.reduce works for the 317th time.

I also can image that GitHub Copilot will make learning and working with a
language you're not that familiar with a way better experience.

This are just my first impressions on it. You can checkout the documentation
here: https://copilot.github.com/

It shows a lot of detailed examples and usecases.

Why it's not stealing our developer jobs

So when this GitHub Copilot is doing all our work, is it stealing our jobs?

Do we still need people to program? Do we still need human beings for web and
software development?

Of course this is a highly philosophical and controversial questions because it
points into the direction of "Can AI take over?".

I'm no expert in AI at all and in no means can I answer this questions. But I
know that GitHub Copilot will not steal our jobs.

I know this could sound naive and maybe in a few years we're all unemployed and
you can tell me: "I told you so". But I strongly believe that this is not the
case.

My assumption is, that AIs like GitHub Copilot will help and support us.
They will make our lives easer. But this doesn't mean we won't have jobs
anymore.

This means we have more time to care for the more complex and bigger problems,
we claim to solve with web and software development.

This means we can solve some tasks faster and have more energy for higher
obstacles.

In the end a human being is always needed to point something like GitHub Copilot
into a certain direction. We have to tell it what kind of function we want to
write, to solve this problem in a certain way.

The creativity comes from us, that's one of humans biggest strengths. I know
that AI can become creative too, as we've seen with numerous examples of AI
creating art and music.

But I strongly believe that the best outcome will always be achieved when
humans and AI work together.

We're still at the very beginning and GitHub Copilot will learn more and more
about how we program. I'm very excited how this turns out.

This blog post was originally published on marcokuehbauch.com.

Head over there to let me know what you think and share it with others!

You can also find me on Twitter at @mkuehb.

The most important things I learned from my colleagues working in web development - part 1

Marco Kühbauch — Wed, 17 Mar 2021 16:26:29 +0000

I call myself extremely lucky. I had and still have the opportunity to work together with some extraordinary human beings.

They helped me and others to grow and get better at what we're doing. Not only in technical matters but also in soft skills.

This blog post is for me. To always remind me about the most important things I learned from my colleagues working in the web development industry. And maybe you can take away something from it, too.

What you can learn from this blog post:

We write code for humans, not machines
It's always we - not you alone
Seniority has nothing to do with age
No finger pointing
Underpromise - overdeliver

We write code for humans, not machines

Do you know that feeling when you used a cool feature of your favorite programming language? Or refactored a long function? Or turned a long function into a one liner?

And do you also know the feeling of coming back to this code after a few weeks and not understanding a single thing that is happening there?

You might have had good intentions– improving the code base. But if you don't put much thought into it and just refactor something because one-line functions are "cool and smart", you're making things worse.

Imagine how this must feel for your fellow co-workers who didn't even write the code. They need a lot of mental processing to follow along here.

So always remember: we write code for humans, not for machines. I know in the end it's the machine who compiles and runs the code. But for the most part, code should be human readable. It should be written for humans so other humans can understand, change and improve your code.

It's always we - not you alone

We are a team. We work together as a team and the code, the products, the features we release are the result of this team work. Nobody is responsible for something alone. Its always a team effort.

I know how it feels to implement a whole new feature by yourself and you feel the urge to tell everyone about it. That's just your ego talking.

Of course you can be proud of yourself. Celebrate yourself, acknowledge what your capable of.

But don't forget the work of your teammates that also played a major role in it. From the conception of the feature to the design, the code review to the testing. It's always a "we did this together".

Seniority has nothing to do with age

When I started working in web development I was often under a certain impression. I thought that after working for a few years in this area you automatically turn into a senior developer. You get this shiny new title, more money and more respect.

It took me a while until I figured out, that this is not how it works. Just because you're growing older doesn't mean you become a senior. There is so much more to seniority than just age.

For me personally getting to a senior level means, developing into a specific person. A person who can teach, motivate and get the best out of all their team members. Who has a lot of experience but doesn't brag about it.

Who can lead others and also follow their advice. Who has a lot of ideas, opinions but also acknowledges others and can admit when they are wrong.

It's a person you want to look up to. A person you look forward to learn more from everyday. And became someone like them eventually.

These are just a few facts and this description only scratches the surface. My good friend Dom wrote a fantastic blog post on this topic:

https://islovely.co/posts/how-to-go-from-junior-to-senior-developer.

I have one planned too on the senior subject, so make sure to check-in again in a few weeks!

No finger pointing

When things go wrong and you know your colleague messed up, it's super easy to point at them and shout "they did this, they are responsible"! Don't be that person. It's not helpful in any way.

Of course you need to find solutions for problems and figure out everything that lead to a specific outcome. But pointing at someone and blame them is the wrong way to handle it.

Why? It's the same I already wrote about above in "It's always we - not you alone". We are a team and we are always responsible for things as a team, no matter if it's about success or failure.

When we know that someone contributed to a problem we can talk to them, help them to improve and tell them what to do next time, so it doesn't happen again.

Fixing problems always works better without finger pointing.

Underpromise - overdeliver

When I started as a web developer I was always super proud of the things I did. And I always wanted to show people what kind of cool things I could make.

This also led to the thing that I could not make realistic estimates. I always wanted to make something super cool and shiny at all costs.

So if someone suggested to build a specific feature and I loved the idea, I would want to build it without actually thinking about the real effort and time it would take. I just wanted to do it.

Maybe I already knew from the start that it could take much longer than expected. But I wanted to ignore that fact and make everyone proud.

Sooner or later I came to the conclusion that this wasn't helpful. If you promise something and can't deliver, you have to break your promise.

It's way easier and healthier to under promise.

And if all goes well and you have more time for something than expected you still can over deliver.

These are the first 5 things I learned from my colleagues working in web development. This is part one of a series, so stay tuned for more!

Getting started with golang - a beginners introduction to programming in go

Marco Kühbauch — Fri, 26 Feb 2021 20:00:52 +0000

How I got to know go

"Wait, what? What's happening here? Your previous blog posts were all about frontend development, CSS JavaScript, React. Now this..go? What is it? And why are you blogging about it?"

If this new content on my blog confuses you a little, I'm sorry! A lot of new things happened to me in the last months and one of them is, that I'm taking a closer look on both (all?) sides of web development. Which includes working with and learning more about backend technologies.

My first contact with everything else than frontend was in a project were we worked with NodeJS/Express and MongoDB.

This granted me a lof ot knowledge on how all parts of a web application work together. From the frontend, to API Calls, middlewares, services, raw SQL and to the database.

In the project I'm working in right now, we're using go in the backend and therefore I'm learning go!

And to make the most of it I will document everything I learn about go in this blog post. So I have a place to come back to and look at when I forget everything.

And maybe you can learn something from it too!

So...go. What is it?

Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.

At least that's what it says about itself on its website. Let's see what wikipeda has to say about go:

Go is a statically typed, compiled programming language designed at Google by Robert Griesemer, Rob Pike, and Ken Thompson. Go is syntactically similar to C, but with memory safety, garbage collection, structural typing, and CSP-style concurrency. The language is often referred to as Golang because of its domain name, golang.org, but the proper name is Go.

Ah that tells a bit more about it. Interesting! Now that we are behind the get to know each other phase, let's see what topics I'll cover in this blog post. As the title says it will be an absolute beginner introduction.

If I'm wrong about something or made mistakes, please let me know!

What you can learn from this blog post:

packages, import, export
Variables
Functions
Data types
for
if, else
switch
struct
arrays
slices
range
map
method
pointers
pointer receivers
interfaces
errors

packages, import, export

Every go program is made up of packages. You always have to have a main package, where your app starts. You can import your own packages or one of the hundreds of go packages.

A name (of a function, struct etc) is exported and therefore can be imported if it begins with a capital letter.

package main

import (
    "fmt"
    "math"
)

// is not exported
func main () {
    PrintStr()
}

// can be imported from other packages in your app
func PrintStr () {
    fmt.Printf("Hello World")
    fmt.Println(math.Pi)
}

Variables

There are several ways to declare variables in go. The classic var lets you declare one or more variables at once. The const lets you declare constant variables. The := shorthand lets you declare and initialize a variable at once inside a function.

var a = 10
const 1 = 10

// shorthand for declaring and initializing a a variable inside a function
a := 10

Functions

A function in go can take zero or more arguments. The type of the input parameter comes after the variable name. When the parameters have the same type you can combine the type declaration.

The input parameters are followed by the return type.

A function can return any number of results. In go explizit returns are required.

func multiply (a, b int) int {
    return a * b
}

multiply(3, 6)

Data types

Surprise, surprise go has values like boolean, strings and integer. Here's a list of all of them.

bool

string

int  int8  int16  int32  int64
uint uint8 uint16 uint32 uint64 uintptr

byte // alias for uint8

rune // alias for int32
     // represents a Unicode code point

float32 float64

complex64 complex128

Variables declared without an initial value are given their zero value:

0 for numeric types,
false for the boolean type, and
"" (the empty string) for strings

for

Coming from TypeScript, there is no such thing as the array methods map, reduce or filter in go. The for loop is all you have.

A for loop consists of the following:

an init statement; condition expression; post statement

There is no need for parenthesis surrounding the three components. The init and post statements are optional.

The for loop can also be used as while().

var a = 10

for i := 0; i < a; i++ {
    a += i
}

if, else

If, else is pretty straight forward in go. No parenthesis are needing surrounding the condition.

var a = 10

if a > 9 {
    fmt.Println(a)
}

switch

A switch in go only runs the selected case, not all cases that follow. The default case is optional.

The break statement is provided automatically.

You can combine expressions in the same case by using comma separation.

switch time.Now().Weekday() {
    case time.Saturday, time.Sunday:
        fmt.Println("It's the weekend")
    default:
        fmt.Println("It's a weekday")
}

struct

A struct is a typed collection of fields. Structs are mutable.

type server struct {
    host          string
    port          string
}
server{"localhost", "8080"}

type person struct {
    name string
    age int
}
person{name: "Marco", age: 29}

arrays

Arrays are numbered sequences of elements of a specific length.

The following creates a variable a as an array of 10 integers.

var a [10]int

In go arrays can not be resized, because the length is part of the type.

The built-in len method returns the length of an array.

var names [3]string{"Tim", "Mandy", "Stefanie"}
len(names) // 2

slices

Unlike arrays, slices have no specified length, so they are dynamically sized. They are build on arrays but are more powerful and therefore more used than arrays in go.

To create dynamically sized arrays (slices), you can use the make function.

// slice of type in with length 5
a := make([]int, 5)

// slice of type string with length 3
s := make([]string, 3)

Slices can also be build by slicing an existing array or slice. In the following example, a slice is formed on the numbers array by specifying two indices, a low and high bound.

// array
numbers := [5]int{1, 2, 3, 4, 5}

// slice of numbers array
specificNumbers := names[0:3]

Its also possible to create slices of slices.

board := [][]string{
        []string{"_", "_", "_"},
        []string{"_", "_", "_"},
        []string{"_", "_", "_"},
    }

To enhance a slice, you can use the append function. This is one example of what makes slices more powerful than arrays. Append returns a slice with one or more new values.

var s []int

append(s, 1, 3, 4, 5)

Slices can also be copied.

s := make([]string, 5)

s[0] = "H"
s[1] = "e"
s[2] = "l"
s[3] = "l"
s[4] = "o"

c := make([]string, 5)

copy(c, s)

map

A map is combination of key value pairs. In other languages it's often called dictionary.

// creates an empty map of string - int key - value pairs
m := make(map[string]int)

// sets an the key "age" with the value of 29
m["age"] = 29

// deletes an element of a map
delete(m, "age")

range

To iterate over a map or a slice you can use range.

It returns two values: index and a copy of the element at that index.

The index or value can be skipped by using _

numbers := []int{1, 2, 3, 4, 5}

for i, num := range numbers {
    fmt.Printf(i, num)
}

method

A method is a function with a special receiver argument.

type Server struct {
    host          string
    port          string
}

function (s Server) printServer() {
    fmt.Printf(s)
}

See that we pass the Server as s as a receiver argument to the printServer function before we the function name declaration?

Everything inside the function body has now access to the members of the struct.

pointers

Pointers hold the memory address of a value.

i := 42

// generate a pointer to i
p = &i

// read i through the pointer p
fmt.Prinln(*p)

pointer receivers

Methods can be declared with pointer receivers.

The differences between pointer receivers and value receivers are:

pointer receivers can modify the value to which the receiver points
with pointer receivers you can avoid copying the value on each method call
sending the value of the variable to the function, but not the variable itself
the value of the variable isn’t passed to the function, just its location
pointers are adresses to a particular place in memory

type Server struct {
    host          string
    port          string
}

function (s *Server) printServer() {
    fmt.Printf(s)
}

Pointers and pointer receivers are little bit more advanced topic but it's good to have heard of them as a beginner.

interfaces

Interfaces are named collections of method signatures. To implement an interface you just need to implement all methods in the interface.

type interface {
    methodOne() int
    methodTwo() int
}

func methodOne() int {}

func methodTwo() int {}

errors

A nil value in the error position indicates that there was no error.

if err != nil {
    // log the error
}

Calling code should handle errors by testing whether the error equals nil.

And that is it, these are the programming with go beginner topics I came across the last weeks and months while learning and working with go. I hope you like it!

Did you know everything already or did you learn something new? Do you have other great examples? Let me know!

You can send me an email or message me on Twitter.

Resources:

🚀 React performance quick wins 🚀 - 7 easy ways to improve your React performance - part 2

Marco Kühbauch — Sat, 23 Jan 2021 16:24:51 +0000

In part 1 of this react performance quickwins series, we already learned about:

One useState hook instead of multiple for connected data

The second part of this series brings you another 4 great quickwins you can apply directly to your code and improve your performance

This Post is Part 2 of a series.

Part 1: 🚀 React performance quick wins 🚀 - 7 easy ways to improve your React performance - part 1

What you can learn from Part 2 of this React performance quick wins series:

Avoid anonymous functions
Define objects outside of your component
React.lazy and React.Suspense
Virtualized lists

Avoid anonymous functions

It's easy to use an anonymous function when you want to add a quick callback function to a component.

import * as React from 'react';

const MyComponent = () => {
  return (
    <button onClick={() => console.log('Button clicked')}>Click me!</button>
  );
};

export default MyComponent;

But if you're on the lookout for a quick performance win, that's something you can avoid.

Anonymous functions aren’t assigned an identifier like const/let/var. This means they are not persistent whenever this functional component gets rendered again. So JavaScript has to create them again and again on every re-render.

This becomes a problem, if you're rendering a loooot of elements, like a lot of table cells, which all make use of an anonymous function.

There is an easy way to solve this. You can simply change it to a named function.

import * as React from 'react';

const MyComponent = () => {
  const handleClick = () => {
    console.log('Button clicked');
  };

  return <button onClick={handleClick}>Click me!</button>;
};

export default MyComponent;

That's it for quickwin number 4: avoid anonymous functions!

Define objects outside of your component

Here comes quickwin number 5. Something similar as described above can be applied to objects.

If you define an object as a object literal and pass it in as props, this object will have to be recreated on every rerender.

import * as React from 'react';

const MyComponent = () => {
  return (
    <div style={{ textAlign: 'center', fontSize: '14px' }}>
      This is the text of my component.
    </div>
  );
};

export default MyComponent;

Instead define your object outside of the component. Now it is created once on the initial render and not being touched on every rerender.

import * as React from 'react';

const DIV_STYLES = {
  fontSize: '14px',
  textAlign: 'center',
};

const MyComponent = () => {
  return <div style={DIV_STYLES}>This is the text of my component.</div>;
};

export default MyComponent;

Performance quickwin whoop whoop! 🚀

React.lazy and React.Suspense

With React.lazy you can "lazy load" your components. This means your component is only rendered when it is truly needed and not loaded unnecessarily.

The less you need to load, the better your performance!

This can easily be combined with React.Suspense for rendering some fallback content.

I wrote a whole Today-I-learned post about this topic, check it out here: Today I learned: React Suspense lazy-loading

That's also a great way to improve your react performance without too much effort.

Virtualized lists

If you've ever worked with long lists or tables with a lot of rows in React you know how much this can impact your performance. You have to render a lot of content, usually a lot of divs.

We already learned that too much DOM nodes is not a good idea. Also updates and rerenders can be really painful because they take just way too long.

With virtualized lists only the list items get rendered, that are actually in the viewport. That's pretty cool. But how does this work? Don't worry, you won't have to build this yourself. There are already amazing tools out there which do the job for you.

Check out react-virtualized by Brian Vaughn.

It's pretty easy to use and you don't need to worry about displaying long lists and tables anymore.

So that's it, these are my 7 easy ways to improve your React performance. Did you already know all of them? Do you have any additional tips? Let me know!

Just send me an email or message me on Twitter.

🚀 React performance quick wins 🚀 - 7 easy ways to improve your React performance - part 1

Marco Kühbauch — Fri, 13 Nov 2020 15:22:40 +0000

At the beginning of the year I wrote a blog post about React performance improvements. It‘s one of my favourite blog posts I ever wrote. It’s a great example of documenting everything while you learn it.

It’s a very in depth analysis. It shows you how to test and measure the performance of your React application and a lot of ways how to improve it.

In the contrary this blog post has the goal to give you a lot of quick wins for your performance. Things you can change and adjust, without too much effort.

So you can see it as an addition to my original react performance blog post. The first one builds the foundation. This one adds the cherry on top.

This post is part 1 of a series.

Part 2: Coming Soon

What you can learn from this blog post:

Always use a key when mapping (and not index)
Use React.Fragments instead of divs as parent element
One useState hook instead of multiple for connected data

Always use a key when mapping (and not an index)

When mapping over an array and rendering a list of items, make sure you always use keys for every item.

Keys help React identify which items have changed, are added, or are removed. Keys should be strings that identify a list item, such as an ID.

Here is a quick example of the usage of keys. Check the return method of this component. There we use the id of every animal as a key.

import * as React from 'react';
import { AnimalCard } from './animal-card';

const animals = [
  {
    id: 1,
    name: 'dog',
  },
  {
    id: 2,
    name: 'cat',
  },
  {
    id: 3,
    name: 'unicorn',
  },
];

const Animals = () => {
  return animals.map(animal => {
    return <AnimalCard key={animal.id}>{animal.name}</AnimalCard>;
  });
};

export default Animals;

If you're not using keys, React has to a hard time to figure out which items to update. This can lead to updating every item although only one changed.

This can be a massive performance impact! 😫

If you don't have access to unique identifiers, indexes can be used as a last resort. It is not recommended to use them as keys but it's better than not using any keys at all.

If the order of items changes, the index changes as well so React has to update every item anyway.

You can learn more about why keys are important in this article about reconciliation.

So that's it for quickwin number one: always use a key when mapping!

Use React.Fragments instead of divs as JSX parent element

Next up: quickwin number two.

When you return multiple elements from a component, JSX needs a parent element to wrap them. A quick way to do this, is to put a <div> around them.

I admit it, I've done this too, way too many times.

import * as React from 'react';

const MyComponent = () => {
  return (
    <div>
      <span>Hi!</span>
      <span>Hope you can learn a lot from my blog posts</span>
    </div>
  );
};

export default MyComponent;

But the next time you need a JSX wrapping element, think again! You can use a React.Fragment for that!

import * as React from 'react';

const MyComponent = () => {
  return (
    <React.Fragment>
      <span>Hi!</span>
      <span>Hope you can learn a lot from my blog posts</span>
    </React.Fragment>
  );
};

export default MyComponent;

And the best thing is, there is even a short syntax for this.

import * as React from 'react';

const MyComponent = () => {
  return (
    <>
      <span>Hi!</span>
      <span>Hope you can learn a lot from my blog posts</span>
    </>
  );
};

export default MyComponent;

But wait, why does this boost my performance? Good question! Here's the thing. The more DOM elements your React application has, the longer the render process takes.

Google's performance tool lighthouse recommends not more than 1500 DOM nodes in total.

So by removing every unnecessary div, like the one we've used way too often as a JSX parent element wrapper, we already get closer to that goal. And we can boost our performance!

You can read more about why you should avoid too many DOM nodes in this article: https://web.dev/dom-size/

One useState hook instead of multiple for connected data

Another performance quickwin you can achieve easy, is using one useState hook instead of multiple ones for connected data.

Imagine a developer built a form with several input elements. Therefore they added four individual useState hooks.

That could look something like this:

import * as React from 'react';

const MyBigForm = () => {
  const [username, setUsername] = React.useState('');
  const [email, setEmail] = React.useState('');
  const [password, setPassword] = React.useState('');
  const [nickname, setNickName] = React.useState('');

  const handleUserNameChange = event => {
    setUsername(event.target.value);
  };

  const handleEmailChange = event => {
    setEmail(event.target.value);
  };

  const handlePasswordChange = event => {
    setPassword(event.target.value);
  };

  const handleNicknameChange = event => {
    setNickName(event.target.value);
  };

  return (
    <form>
      <label>Username:</label>
      <input value={username} name="username" onChange={handleUserNameChange} />

      <label>Email:</label>
      <input value={email} name="email" onChange={handleEmailChange} />

      <label>Password:</label>
      <input value={password} name="password" onChange={handlePasswordChange} />

      <label>Nickname:</label>
      <input value={nickname} name="nickname" onChange={handleNicknameChange} />
    </form>
  );
};

There is a lot of useState and onChange going on here, right? Phew. We can optimize for the better here!

By removing the individual useState hooks and implementing a combined one, we're making sure to reduce the size of the component and therefore improve the performance.

And we can also get rid of all the handleChange functions, which all seem to do the same.

import * as React from 'react';

const MyBigForm = () => {
  const [formdata, setFormdata] = React.useState({
    username: '',
    email: '',
    password: '',
    nickname: '',
  });

  const handleOnChange = event => {
    setFormdata({
      ...formData,
      [event.target.name]: event.target.value,
    });
  };

  return (
    <form>
      <label>Username:</label>
      <input value={username} name="username" onChange={handleOnChange} />

      <label>Email:</label>
      <input value={email} name="email" onChange={handleOnChange} />

      <label>Password:</label>
      <input value={password} name="password" onChange={handleOnChange} />

      <label>Nickname:</label>
      <input value={nickname} name="nickname" onChange={handleOnChange} />
    </form>
  );
};

Wow a lot less code and a lot more readable, don't you think? It's always a good idea to keep your state in an object, if you're dealing with connected data.

Don't get me wrong: using and calling multiple useState hooks is not a bad thing! React has no problem with that.

But in this example it's also about removing duplicate code and rethinking your components.

And if JavaScript has to allocate the memory for only one function instead of four, that's also a performance quickwin! And that's what we're here for, right?

That's it for part 1 of this React performance quickwins series! Hope you could already apply some of them and make your React app even faster.

Let me know if these tips helped or you have other tips, you'd like to share.

This blog post was originally published on marcokuehbauch.com.

Head over there to let me know what you think and share it with others!

You can also find me on Twitter at @mkuehb.

How to overcome imposter syndrome as a developer

Marco Kühbauch — Fri, 30 Oct 2020 17:02:13 +0000

I was in a comfortable position at a previous job. I was working as a frontend developer and after two years in this job, I knew my way around. I knew about every feature our product contained. I knew the code. I could tell which component was responsible for what.

I knew where most of the questions at me where headed before someone finished them asking. This felt like home. This felt like the absolute comfort zone.

What you can learn from this blog post:

What is imposter syndrome
Why you feel like an imposter
Why you aren't an imposter
Overcoming imposter syndrome
- Set yourself realistic goals
- Keep track of your accomplishments
- Don't compare yourself to others
- Your teammates and colleagues may feel the same
- Ask for Feedback
- Even the experts in our industry feel this way

After switching jobs imposter syndrome hit me hard. At first I felt like a fraud. Everything was new to me. The code, the tools, the workflow, the people, the team. I felt like I had to relearn everything. And like I did not know anything at all.

I always thought that sooner or later somebody would come to me and say: "You know, we've watched you long enough and now you've been caught. You don't know anything about software developing." handcuffs click.

Did you ask yourself questions like am I good enough? Do you often have thoughts like do I know enough to be a good developer? Can I help make this product better? My skills are way to bad. I should quit. I know nothing.

This kind of thoughts are bad and not helpful at all you could say. But still a lot of people have them.

Chances are you've felt the same at some point in your career. Chances are you will feel like that everytime you start a new job. This all sounds very negative. But the good news is: you are not alone!

A colleague of mine once told me that they should take two weeks off to learn a specific technology. Because they feel like they "know nothing about it". And they are developers, I learn the most of and look up to. In my eyes they know their stuff pretty well.

If anything of this above sounds familiar to you, let me tell you about the imposter syndrome.

What is imposter syndrome?

Wikipedia gives a very good definition of imposter syndrome:

Impostor syndrome (also known as impostor phenomenon, impostorism, fraud syndrome or the impostor experience) is a psychological pattern in which an individual doubts their accomplishments or talents and has a persistent internalized fear of being exposed as a "fraud".

If this sounds familiar to you, chances are you also feel like you do not deserve certain things. You think your achievements are not you own and your success is attributed to luck.

For some people it gets even worse. Often anxiety, stress or depression go along side with imposter syndrome.

Why you feel like an imposter

So the questions is why do we feel this way? What causes imposter syndrome? It does not sound like something that could benefit our work, our life or anything between. It sounds harmful and could also hold as back.

A lot of developers are self taught. Often they suffer from imposter syndrome because they do not have a CS degree. And this is still required by a lot of companies. Thus they think, they are not "real" developers, if they haven't learned their stuff at a university.

Another reason why we feel this way is that the web industry is one of the fastest changing industries. Every week or so this new technology gets popular. A new JavaScript framework will replace the most popular one right now and you need to know about it and have learned about it yesterday. Which is obviously not possible.

So we get the feeling we need no know everything but we can't. And we don't accept the obvious reasons, we think we as developers, as humans are the problem.

There is always something new to learn in this industry. This is on the one hand a really nice thing and motivates me but but it's hard to stay on top.

Every programming task you do at work is like a small challenge. If you succeed everything is fine. But if you don't find a solution right away you question yourself. You question your knowledge and if you've even capable of this job.

We compare ourselves to others. This new kid just joined the company and already build this super complex feature. Because they are programming since they are 12 years old. I will never be as good as them. Sounds familiar?

Why you aren't an imposter

Let's take a quick break and a deep breath.

Let me tell you that you took the first step. We analyzed the problem and we saw the situation for what it really is. There are a lot of ways to grow out of it and change. From here on the positive takes over.

You are not an imposter because you do not need a CS degree to be a good developer. It can help in some ways but the knowledge to be a good developer is not only trapped inside a CS degree.

You are not an imposter because take a look. See how far you've come. What you've achieved in your past, all you've done. Even if you're a beginner remember all the things you've learned so far, even the smallest.

My incredibly talented girlfriend draw this beautiful picture about this topic.

@findingthelittlethings_

I take a look at it as often as I can because it's always a good reminder.

You are not an imposter because you've got the job right? You convinced someone to hire you as a developer. That's a big achievement you can't fake.

You are not an imposter because remember this one little crazy bug you solved which seemed like "a hell no we will never solve this bug at all". But you did.

You are not an imposter because you don't know everything. And that's totally fine. You can't know everything. And even if you could, that would be really boring, right? One of the greatest things in life is that there is always something new to learn.

Overcoming imposter syndrome

Now as we have set the clear picture why you are not an imposter, here are more tips on how to deal with imposter syndrome and eventually overcome it.

Set yourself realistic goals

Set yourself some realistic goals! Telling yourself that in three weeks you will know the entire codebase by heart is an impossible goal. Rather set up smaller goals which are clear and measurable.

Keep track of your accomplishments

Write down everything you achieved. Even the smallest things. Everytime you struggle, you doubt yourself, take a look at that list. Be proud of what you've learned and achieved. This helps a lot.

Don't compare yourself to others

Comparing yourself to others is never a good idea. It always leaves you feel bad about yourself. You don't know the history of others, how they learn and how they think. Everyone is different and has their own strengths and weaknesses.

The next time you compare yourself to the new team member, who already seems to know everything - stop right there. Be happy for the new colleague because they settled so quickly.

Than compare yourself to you from last week or last month. There are definitely things you've learned, features you built and bugs you crushed.

Your teammates and colleagues may feel the same

Talk to your colleagues about it. Chances are they feel exactly they same as you do. Help to build a culture in your company where it's easy and desired to share knowledge. Where you help each other and not knowing everything is considered normal. Do more pair programming and knowledge sharing sessions.

Learn to be brave and answer questions with: "I don't know an answer to your question right away. I need to think about it first." I know this seems very hard, but in the end everyone benefits from that.

Finally be aware of the fact that the work and achievements as a team is, what counts.

Ask for Feedback

If you're feeling like an imposter remember that the only person you get feedback from right now is yourself. To stop this cycle and get a more realistic view of what is really happening, don't hesitate to ask your teammates and colleagues for feedback! They can give you valuable answers on how you're really doing and where you can improve.

Even the experts in our industry feel this way

When I came across this blog post by David Walsh, I was astonished. He writes a lot of blog posts about the JavaScript ecosystems. He worked for Mozilla for over 8 years. Developers go to his blog to get help, read his tutorials and learn stuff. And even he feels this way. This shows a whole new perspective. Take your time and head over there to read this. I'll wait here.

And than you'll see that you're absolutely not alone feeling like this. You're fine.

Conclusion

Dealing with imposter syndrome can be hard and your are not alone in this. The first step is to realize that you suffer from it. From there on you can grow into a more healthy relationship with yourself. There are a lot of tools you can use to cope and deal with imposter syndrome.

I hope I could explain this topic a little better and you can use my tips to overcome imposter syndrome.

Did you ever suffer from imposter syndrome? Do you know friends who feel that way? Make sure to send them this blog post and let me know what you think about this topic.

This blog post was originally published on marcokuehbauch.com
Head over there to let me know what you think and share it with others!

You can also find me on Twitter at @mkuehb

React Performance Improvements

Marco Kühbauch — Wed, 28 Oct 2020 10:47:00 +0000

In this blog post I'm going to introduce several tipps and tricks to boost the performance of a React application.

I learned a ton while improving the performance of a large and complex web application recently and wanted to share everything so others don't have to search all over the internet for this useful and important information.

What you can learn from this blog post:

Where to start
- Chrome DevTools Lighthouse Audit
- webpagetest
The Biggest Problems
- Time to Interactive (TTI)
And how to solve them
- Removing DOM nodes
- lazy-loading images
- code-coverage
- code-splitting
- React Profiler
- Chrome Performance Analyzer
- Bundle-Analyzer
Conclusion
Sources

Where to start

If you notice that your React App is slow or takes a long time to load, you have a few options to verify that and get an insight into where the biggest problems are.

Chrome DevTools Lighthouse Audit

First of all you can measure your performance score with the Chrome Lighthouse Audit which is available in the Chrome DevTools.

You can choose between measuring the performance on mobile or desktop. If you just want to get your performance score, you can check off the other audits, like Progressive Web App or SEO.

You should also activate throtteling, because not everyone is on the newest MacBook Pro with 64GB of RAM and i9 processor while browsing on a 5G network. I usually use Applied Slow 4G, 4x CPU Slowdown.

After the audit is finished, you get a nice overview over the scores, the metrics and how they are calculated. You also get opportunities and diagnostics which can tell you why your app is slow and how to solve common problems.

webpagetest

Another tool to verify the perfomance of your React application is webpagetest.org. After you enter a URL and start the test, it returns a test result and grades specific parts of your application. It is also pretty useful in finding problems and ways to improve the performance.

The Biggest Problems

Time to Interactive (TTI)

In case of React applications where a lot of JavaScript is involved, often the time to interactive identifies itself as the biggest problem. TTI means how long it takes a page to become interactive.

The TTI gets slowed down by a few things. The ones which are directly related to a lot of JavaScript code and therefore React are:

too much main-thread work
an excessive DOM size
too much JavaScript execution time

To summarize this: When a user navigates to your page and can not click around for a few seconds, because your JavaScript is not fully parsed, compiled and executed, this is bad.

Especially when you are using server side rendering where the user already can see your page but not interact with it yet.

This all happens because your browser has to execute too much JavaScript at once, because certain scripts are blocking, because you just want to do too much at once in your code.

Uff. This sounds a little exausting. We need solutions. Let's tackle the problems one by one.

And how to solve them

Removing DOM Nodes

Perhaps the easiest step to improve the performance of your react application is to reduce the amout of DOM Nodes. If you hide a lot of your components with CSS, check if you can render them conditionally instead.

This decreases the size of the DOM which means less components need to be rendered, which means less JavaScript needs to be executed.

This will especially be helpful, when you have a long list of items, render all of them, but show only the first 5 initially. Robin Wieruch has a great article on conditional rendering in React.

lazy-loading images

If you load twenty images initially, which are located at the bottom of your page, meaning the user can't see them at first glance, this is a lot of wasted time and potential.

Instead you can detect when the user gets closer to the images and then render them. Because that's the point where you actually need them. The npm package react-lazyload makes this surpringsingly easy.

This results in executing less JavaScript code but it also solves another very common problem: too many http requests.

So its a good idea in general to only render and show the code the user needs to interact with your React app initially, instead of just rendering everything.

code-coverage

Chrome offers the opportunity to detect unused code in your application.

The code coverage tab is located in the Chrome DevTools. You can find it in the command menu when you type coverage.

It can track a whole reload of your application and is still tracking and updating the code coverage when you're interacting with your application.

This is another super easy quick win, which can help you to improve your performance by removing unused code.

code-splitting

In a large and complex react application code-splitting is possibly one of the best ways to improve your performance.

The idea of code-splitting is to split your code in ways it is needed in your application and therefore render only the code which is needed for the current UI.

Imagine having a Landingpage and a page where you show some articles, let's call it blog. Does the blog need to download and execute code which is only needed on the Landingpage? No!

So you can use clever tools, who are capable of detecting where your code is actually needed and split it up. That's code-splitting.

One of these clever tools is React.lazy. You can read and learn more about it in the React docs code splitting section. Please note that React.lazy is not available for server-side-rendering. Code-splitting in a server rendered app can be achieved with Loadable Components.

React Profiler

The React Profiler is another useful tool to gain more insight about what your React app is doing and why. It is part of the React Browser Plugin and can be located in the DevTools.

When you profile your app it collects timing information about each component that is rendered. It also shows how long a specific component took to render, if it needed to be updated and so on.

So you can either see if a component took way to long to render or identify unecessary rerenders. Both are ways which can help you to identify performance bottlenecks.

Chrome Performance Analyzer

Another way to collect information about your performance is the Chrome Performance Analyzer. It's also located in the Chrome DevTools and lets you record the load performance of your app. This is the place where you analyze your loading time in to the deepest. It just has so many options.

Take your time to read through the documentation of this performance evaluation tool.

It makes sense to spent more time to fully understand what this tool is capable of. It can totally help you boost your performance because it shows you everything that's happening with your JavaScript.

Bundle-Analyzer

The Webpack Bundle Analyzer is a npm package which "visualizes the size of webpack output files with an interactive zoomable treemap". To use this package your application has to use webpack for the bundling of course.

This Analyzer is such a great tool. It shows you exactly what files you give out to your users, how big they are and also which files should absolutely not be in your bundle.

In case of the large and complex web app I was working on, by using this analyzer we realized that some packages where depending on the whole lodash library which is a lot to include in to your bundle if you actually just need one functionality of it.

Conclusion

All these steps are great and helpful ways to find out why your React application is slow and how to change that. You don't have to implement all of them, maybe already one of them will help you speed up things.

I hope you could learn something here and if you know more ways to boost the performance let me know!

This blog post was originally published on marcokuehbauch.com
Head over there to let me know what you think and share it with others!

You can also find me on Twitter at @mkuehb

DEV Community: Marco Kühbauch

GitHub Copilot is not stealing our jobs

What is GitHub Copilot

What can GitHub Copilot do

Why it's not stealing our developer jobs

The most important things I learned from my colleagues working in web development - part 1

We write code for humans, not machines

It's always we - not you alone

Seniority has nothing to do with age

No finger pointing

Underpromise - overdeliver

Getting started with golang - a beginners introduction to programming in go

How I got to know go

So...go. What is it?

What you can learn from this blog post:

packages, import, export

Variables

Functions

Data types

for

if, else

switch

struct

arrays

slices

map

range

method

pointers

pointer receivers

interfaces

errors

Resources:

🚀 React performance quick wins 🚀 - 7 easy ways to improve your React performance - part 2

Avoid anonymous functions

Define objects outside of your component

React.lazy and React.Suspense

Virtualized lists

🚀 React performance quick wins 🚀 - 7 easy ways to improve your React performance - part 1

Always use a key when mapping (and not an index)

Use React.Fragments instead of divs as JSX parent element

One useState hook instead of multiple for connected data

How to overcome imposter syndrome as a developer

What is imposter syndrome?

Why you feel like an imposter

Why you aren't an imposter

Overcoming imposter syndrome

Set yourself realistic goals

Keep track of your accomplishments

Don't compare yourself to others

Your teammates and colleagues may feel the same

Ask for Feedback

Even the experts in our industry feel this way

Conclusion

React Performance Improvements

Where to start

Chrome DevTools Lighthouse Audit

webpagetest

The Biggest Problems

Time to Interactive (TTI)

And how to solve them

Removing DOM Nodes

lazy-loading images

code-coverage

code-splitting

React Profiler

Chrome Performance Analyzer

Bundle-Analyzer

Conclusion

Sources: