DEV Community: rzeczuchy

3 lessons about teamwork I learned working as a PM 👐

rzeczuchy — Tue, 03 Nov 2020 13:40:16 +0000

Not only is this post not strictly related to coding, but I also mentioned I am a PM right in the topic. What is this, reverse-clickbait?

Normally I post about code, but I sometimes want to write also on topics connected with teamwork. Most developers I met understood that good teamwork is everyone's concern, even though they probably don't spend as much time reading about it as they do learning about newest tech.

So today I wanted to write about three most valuable lessons I learned working with a team. They are not relevant only to a PM's work - on the contrary. The most valuable lessons I learned were not on how to hold a productive status meeting or effectively negotiate with stakeholders, but rather on how to work with other people.

I also want to say up-front that I learned there lessons in equal parts through success and failure. There were times when I stuck to them, and that felt cool, but also times where I failed and regretted it afterwards. So this is not an attempt to fashion myself as a genius project manager or anything like that - just to share some advice that turned out to be true for me 😉

With that disclaimer over, here comes the meat:

It’s easier to talk about other people, than to talk to them 🙊

One thing that I’ve definitely heard too much of when working with a team (sometimes also out of my own mouth) is complaints about how other people work. “I think his coding is too slow”, “I don’t understand what she tried to achieve with this solution”, “I wish they could be clearer about their expectations”.

Complaining about other people’s work when they are not present is very common. Sometimes it seems like a natural way to vent some of the stress we face in our work. We also do it just because it’s so easy. However, it’s also something else: completely unproductive and potentially harmful. By complaining about how others work, you are wasting both your own time, and the time of the person who is listening to your complaints. Meanwhile, nothing is actually being resolved. Moreover, if “team gossip” like this escalates, it can result in a lot of unwanted conflict that could have been avoided.

There may be rare situations where talking to someone else about your teammate’s problem might be more appropriate, but I think that in most cases you are far better off talking to your teammate directly. You will resolve issues faster, and get a chance to understand your teammate’s work and the challenges they might be facing.

Making decisions for others is tempting, and probably wrong 🤔

No matter what role you have on the team, sooner or later somebody might ask for your help with a problem. If you are their manager or senior, you might feel obligated to decide for them how to solve that problem - but I don’t think you should do that. Why?

People dislike making decisions. That’s completely understandable - we all have to make so many every day that sometimes it just becomes tiring. If we get a chance to push some of these decisions onto someone else, like a manager or senior, we will usually (even unintentionally) do so. However, that is a slippery slope. If a teammate comes to you with a big problem and you decide for them, they will come back to you the next day with a smaller problem. This will keep happening until you are drowning in a puddle of tiny decisions that your teammate was perfectly capable of making. You are now wasting your time micro-managing someone else’s work, but you’re also doing something far worse - you’re undermining their confidence.

Rather than doing that, I think it’s better to ask questions, to give your perspective when asked for it, and to help your teammate discover the solution for themselves. In the end, they are the ones that are closest to the problem - so they will probably be able to come up with the best answer.

We forget praise quickly, but remember criticism forever 🤷‍♀️

You know that thing your brain does sometimes when you’re going to sleep, and suddenly remember something stupid you've said or done years ago? I’m not a psychologist, so I don’t know what the exact cause for that is, but I think we all tend to remember negative experiences much more vividly than positive ones. This happens in the workplace too - when I receive feedback, I tend to focus on the negatives much more than the positives. This is why I think you should criticize people’s work only when you really have to, but praise it whenever you can.

No team is 100% in sync - some problems are bound to crop up, either with your or somebody else’s approach. If you think it will be productive to point out an issue with your teammate’s work, by all means do so. Keep your feedback constructive and to the point, but also make sure that it comes from a place of empathy. The situation is rarely as straightforward as it seems, so I think you should always be ready to listen to your teammate’s perspective. Your aim is not to undermine anyone, but to resolve a problem so that your team can work better, right?

The flip side is that you should also praise your teammates for the work they do whenever you get the chance. I’m not saying you should tell everyone they are “doing a great job” everyday right after the morning coffee - that would be dishonest (unless your team just happens to be doing a great job every day right after the morning coffee). But when your team or one of your teammates does get something right, don’t be embarrassed to openly praise them. Get into the habit of pointing out small successes. You might notice that this builds up not only your team, but also your own confidence in the project and the work you do.

Final thoughts

In the end, I want to stress that I don’t believe these are sacred rules that everyone should follow - or that anyone is wrong for having a different outlook. Every team is different, every company has their own management style and work culture. But regardless of where and how you work, I think it's a good exercise to try to verbalize your own principles. To think about the values that you believe in - like honesty, trust, courage - and how you can apply them best in your work in the work you do for your team.

If you have any of your own pointers about teamwork I'd love to read them 😊 And if you wrote a post on this topic in the past, definitely post a link in the comments!

Are template engines still relevant in 2020?

rzeczuchy — Wed, 28 Oct 2020 11:07:55 +0000

Some years ago it seemed to me like JS template engines (Pug, Nunjucks & co.) were all the rage, but I haven't been hearing a lot about them lately?

Recently I went on YouTube to look for some materials on Pug/ Nunjucks/ Handlebars, and the majority of results I got were old stuff from around 2-4 years ago. I checked on Google Trends and searches for the phrase "template engine" seem to be gradually decreasing - and I'm not really seeing them in the requirements for frontend dev positions, either.

Is this because JS templating engines have been sidelined? Or is it just assumed now that every web dev will have had some experience with them? 🤔

3 things I would tell the me from the past to expand my coding brain

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

Like many people on this platform, I am a self-taught developer. I do not have a degree in computer science, nor any kind of formal technical education. When I wrote my first line of C#, I had no preconceptions about computation and programming. "How computer know what do? Why is function? What interface?" were the questions I had back then, when my coding brain was small and smooth.

However, once I got over this initial hurdle of learning a programming language, I was still a long way away from understanding the disciplines and routines that developers use to write better code. My brain has gotten wrinklier, but it was still way to small. I wanted to learn good practices, I just did not know where to start.

In case time travel ever becomes commercially available, I am writing this article for my past self, so that he may expand his brain.

PLEASE start using Git already?

If there is only one thing that I could tell the smooth-brained me from the past, it would be this: make a GitHub account and start committing your code NOW.

A big part of progressing as a developer is building on the solutions you already wrote - so keeping even your earliest projects on GitHub is a smart move. Storing your projects on your hard drive is no good, you can and will lose some of this data. A well-maintained GitHub account is also something that will make your life easier once you decide to look for a job in tech.

Me from the past: But I don't intend to make programming my job...

Correction - you don't intend to make programming your job yet! Besides, there are other reasons to learn version control: it helps you understand development routines and keep a better discipline when working on a project.

M.f.t.p.: Learning Git console seems like a drag though...

Suck it up - there's only a couple of commands that you need to learn to start using Git. And if you really don't want to do that yet, use GitHub Desktop. But make sure to learn console as soon as possible.

M.f.t.p.: Does it even make sense to use version control if I'm working alone?

Yes, it does. It gives you peace of mind when you make changes to your code, since previous versions of your program are saved to Git, and you can always come back to them. But, if this is not enough motivation for you, maybe you should...

Try teaming up with other people

One thing that I wish I started doing earlier was teaming up with other devs. Teaming up with others not only makes development more fun, but is also a great way to boost your learning speed.

M.f.t.p: But I don't have friends who code in the same language as me?

Added bonus - you can learn a new language! Go outside your comfort zone, try new design patterns and new technologies. If you get stuck, your friend/ coding partner/ someone on your team will be able to help you.

M.f.t.p: I don't think I'm good enough to work with others yet.

And when exactly will you be? You don't need certification to start working with and learning from other devs. If you don't feel ready now, avoiding teamwork will not make you feel any more ready in the future.

It's teaming up with other people that will force you to improve the quality of your code. You will need to agree with your teammates on common practices that will make your teamwork easier. You'll need to stick to certain naming conventions, make sure your code is readable to others, that it's refactored and has useful comments. And if your teammates are quality-oriented, they might suggest other good practices such as to...

Start testing your code

M.f.t.p: But I always test my code? I run the program and...

...run the program and see if something breaks? Yeah, yeah. Listen, that's cute - but I mean a different kind of testing. What you are referring to is known as manual testing. It means that somebody has to manually build and start the app, and then check if any errors or bugs occur while the code is executed. What I was referring to, though, is automated testing.

Automated testing means quite simply writing code that will automatically test your application or some segment of it when executed.

M.f.t.p: So, you write code to test your code?

I don't need your snark. And yes, that's what you do. It makes sense in the long run.

You see during the course of development, you are more than likely to come back and modify/ refactor certain parts of your code several times. Each time you do that, you risk that something in your application will break. This means that sometimes you will have to manually test and fix a certain bug multiple times, which is known as regression. If you write an automated test for this piece of code, each time you modify it you can just run the relevant test suite and it will tell you whether the code is still working as you intended or not. Cool, right?

M.f.t.p: But I thought automated tests are written by testers?

Yes and no. Yeah, some teams have testers who handle automated tests. But that doesn't mean you should think about testing the code as "someone else's job". If you get into testing, you'll see various ways in which automated tests improve the quality of code you're writing. If you don't believe me, here's a link to a great video that explains the benefits of testing your code. You will have to wait until 2017 when they upload it, though.

Also one last piece of advice - please start exercising and taking care of your back now? You'll need it to support your massive galaxy brain after it absorbs all the new coding knowledge.

Using random numbers in C#/.NET 🎲

rzeczuchy — Mon, 12 Oct 2020 16:07:49 +0000

There will be times while coding, when you might need to simulate some sort of probability or non-deterministic behavior. Usually the simplest way of doing that is using random numbers.

Luckily for us mortals, C# has a very easy way of approximating random numbers. All you have to do is use the Random class from the .NET framework to generate a pseudo-random number:

using System;

namespace GeneratingRandomNumbers
{
    class Program
    {
        static void Main(string[] args)
        {
            Random random = new Random();

            Console.WriteLine(random.Next(1, 10));
            Console.ReadKey(true);
        }
    }
}

The above code will initiate a new Random number generator for you, and calling the Next function will then return a pseudo-random number between the min and max values you provide as parameters.

However, the above code actually has a couple of problems. Let's talk about those.

First of all, you might have noticed that I keep referring to these "random" numbers as pseudo-random. This is because a number returned by the random.Next method is not really completely random. Simply put, the Random class uses a complex algorithm that makes it seem like the numbers are random.

According to the .NET documentation, the algorithm takes a seed that is time-based. This means that if we create multiple Random objects at the same time, they will all produce the same sequence of numbers. You can actually test this by doing something like this:

Random random = new Random();
Random anotherRandom = new Random();

for (int i = 0; i < 10; i++)
{
    Console.WriteLine(random.Next(1, 10) + ", " + anotherRandom.Next(1, 10));
}

Console.ReadKey(true);

There are some instances where we might want to reproduce the same sequence of seemingly random numbers. However, in most cases we would like to always produce a different sequence. A good way to ensure that this is the case, is to make our Random object static, and always derive all random numbers from the same object.

We might thus want to do this:

using System;

namespace GeneratingRandomNumbers
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(RandomNumbers.GetRandom(1, 10));
            Console.ReadKey(true);
        }
    }

    static class RandomNumbers
    {
        private static Random random = new Random();

        public static int GetRandom(int min, int max)
        {
            return random.Next(min, max + 1);
        }
    }
}

Because we are only using one Random object in our application, the sequence of numbers should not repeat (at least there are statistically very low chances of that happening).

One last thing you will notice is that when calling the Next method in GetRandom, I increased the maxValue parameter by one: random.Next(min, max + 1). This is because the minValue argument that the function takes is inclusive, but the maxValue argument is exclusive. So for the function to ever return the max value we provided, we have to add 1 to the parameter.

One last thing to point out is that, while the Random class is sufficient for most practical reasons, if you want to generate cryptographically strong random sequences, you'll probably want to use the RandomNumberGenerator class. The sequences produced by this class are much less predictable, and thus more secure.

Now you can go and do something random! Thanks for reading!

Cover photo from Unsplash ❤️

3 tips for SCSS beginners to better leverage variables

rzeczuchy — Fri, 02 Oct 2020 17:18:43 +0000

Variables are without doubt my favorite feature of SCSS. I'm pretty sure I'd be using SCSS even if variables were the only improvement it offered over plain CSS. They are just so much better than CSS's awkward and lumpy custom props.

This is why it saddens me so much to see people not really using SCSS variables to their full potential. If you happen to be one of those people, here's a few ways you can change that ;)

Note: all the examples in this post are written in SCSS, since that is my preferred syntax, but as far as I know, the same general rules will apply to Sass.

Tip 1: Use scope

Usually when I see someone using SCSS variables, they use pretty much exclusively global variables. Setting font stack, font sizes, colors at the top of the document - you know, the usual thing.

However, it's good to always remember that SCSS variables support scope. This means that a variable declared in a block will only be accessible within that block. Like so:

.some-element {
  $some-spacing: 1em;
  // The variable can be used locally.
  padding-left: $some-spacing;
}

.another-element {
  // This will fail - the variable is not accessible here.
  padding-left: $some-spacing;
}

This means we can use variables whenever we need them, and we don't have to make a mess by declaring a truckload of globals at the top of the module.

Moreover, if we declare a global variable, like $primary, and then decide to change it for some unique section, we can do that locally without overwriting the global variable for the rest of the elements:

$primary: #03a;

.some-element {
  // This will override the variable's value in this block.
  $primary: #f06;
  color: $primary;
}

.another-element {
  // But here the original value will be applied.
  color: $primary;
}

Good old scoping gives us the liberty to declare new variables, without worrying that we'll inadvertently mess up global styles.

Tip 2: Avoid magic numbers

One thing I love about variables is that they give me an easy way to avoid using magic numbers in my code. So for example, if I have an element that will always be rectangular, instead of doing this:

.rectangular-element {
  width: 10em;
  height: 10em;
}

I can do this:

.rectangular-element {
  $size: 10em;
  width: $size;
  height: $size;
}

Next time I need to change the size of this element, I can update one variable instead of two properties. You might think this is a trivial change, but if an element has a lot of properties, having one variable that I know I'll be likely to update later at the top of the block is actually very helpful:

.some-element {
  // See how this is a bit easier to find?
  $size: 10em;
  position: absolute;
  top: 0;
  right: 0;
  margin-right: 1em;
  width: $size;
  height: $size;
  display: flex;
  justify-content: center;
  align-items: center;
}

This is even more useful if you're using nesting. A few blocks can then use a variable that is declared at the top of their parent block - very convenient!

Another way to leverage variables to avoid magic numbers is to look for patterns in the design. For example, you might encounter a layout where the designer has painstakingly unified all the spacings across the page. It would then be wasteful to throw away all this good work by doing this:

.some-element {
  margin: 3em 1em;
}

.another-element {
  margin: 3em 1em;
}

when instead we can do this:

.some-element {
  margin: $spacing-large $spacing-small;
}

.another-element {
  margin: $spacing-large $spacing-small;
}

This way we're again avoiding repetition, but also showing our understanding of the designer's intentions. And we can then thank our past selves once the designer's client decides that "all the spacings should be 2 pixels larger".

Tip 3: Keep looking

My top tip for working with SCSS variables is to always keep looking for better ways of working with SCSS variables. I started learning programming from OOP, so I tend to think about SCSS variables a bit like I would about C# or JS ones.

When you work on your other languages and learn practices connected to variables there, why not take a moment to think if what you learned can also be applied to SCSS variables? Flex that variable muscle, lest it becomes limp! 💪

If you have any cool tips on using SCSS variables yourself, I'll pay you handsomely in cookie emojis.

Netlify's pipeline is super convenient (and you can use it for free)

rzeczuchy — Mon, 21 Sep 2020 11:09:09 +0000

I want to start by saying that - though I will be fawning over Netlify's service a lot - this is not a sponsored post or review. I just genuinely find their solution great, and think more devs could benefit from using it. Especially since you can try it out at the low price point of zero ;)

What is Netlify

Ok, so what is Netlify in the first place?

Aside from posting intentionally bad developer puns on their Twitter, Netlify offers an “all-in-one platform for automating modern web projects”. Basically they provide a CI/CD pipeline that allows you to automate as much of your workflow as possible as a site admin.

From what I could gather, Netlify is geared mostly towards the coding crowd. A lot of the features they offer would probably get a shrug from non-developer site owners. As a coder, though, I consider most of them essential, and the rest at the very least convenient time-savers.

Before I dive into the details, I want to mention that so far I used Netlify to build static HTML/CSS sites and React apps, but it can just as easily service Vue and Angular, WordPress sites, Drupal sites and more. The features I describe below are general and from what I understand, they apply to all types of projects.

Features

So, how does one use Netlify, and what is so great about it that I felt the need to write a post?

GitHub integration

Using Netlify starts with integrating your project’s GitHub repository with Netlify’s pipeline. They have an easy-to-follow guide on how to do that. Once that is set up, every time you push to the GitHub repo, Netlify will run an automatic build of your site, and the new version will be up within seconds. I noticed at most a 10 seconds delay from the push to the updated build being up online, though that will probably vary depending on the type and size of project you're deploying.

The integration is a huge time-saver - push to repo, and the rest of the tedious stuff is handled for you. I did not encounter any problems with the automation at any point. After the initial setup, everything has run smoothly without any action required from my side.

Domains

Once the project is built, it’s available online on Netlify's default domain (projectname.netlify.app). It’s not bad, but for most projects that are not proof-of-concept, you’ll want to use a custom domain. Luckily you can do that even on the free plan (of course as long as you own the domain in question).

To use the custom domain, you need to set up your domain to use Netlify's DNS, which I found rather quick and painless. From then on you’ll be able to change DNS records and set up redirects inside Netlify's panel. For me that's just added convenience, since I'm more likely to be logged in there than to my domain's admin panel anyway.

One thing to keep in mind when using the free plan is that the project will always be available at the default Netlify address, even once you set up custom domain. Also, the free plan does not support password-protected websites, so once the project is built, it will always be publicly accessible.

SSL

When it comes to security, every site put up on the default Netlify domain comes automatically encrypted with SSL. If you add a custom domain, you have an option to include a cert from Let's Encrypt, which can be done with a few clicks.

Extras

Even though I don’t use any of the options I’m about to list here (so I can’t really comment on how well they work in practice), it’s worth mentioning that Netlify has some extra tools that help you run your site. Stuff like built-in analytics, managing signups and logins, OAuth integration for your users, or collecting form submissions without any additional server-side code sound like cool perks to me. These features are either free, or available for a small additional cost per site.

Summary

Overall, the entire process of setting up a website with Netlify, together with purchasing a custom domain, integrating the GitHub repository, setting up DNS and adding the SSL certificate took me just over an hour. That’s an exceedingly good time, considering that I also expect it to save me precious minutes every time I update the code.

Even though the free plan obviously doesn't come with any SLAs or guarantees, I didn't encounter any problems with the builds. I noticed no significant downtime or slowdowns, and at no point did I feel that I'm struggling to set something up. All the options I could possibly need were available out-of-the-box, with very little work required from my side.

Netlify’s free plan is a fantastic option to start if you want to host your personal website, and if you haven’t tried Netlify yet, I seriously encourage you to take it for a spin!