DEV Community: Catherine

How would I learn to code today?

Catherine — Sun, 27 Jun 2021 21:58:25 +0000

I was 17 years old when I decided to switch majors to Computer Science, without knowing exactly what it was or what I was in for. All I knew was that I liked HTML because of my extensive experience customizing my MySpace profile.

Today, years later, I’m reflecting on what I would do if I was learning to code from scratch. What would I do with the tools that are available today?

Book, Website or YouTube?

I’ve seen a lot of people get hung up on what medium is the best to learn to code. To be honest, I don’t think it matters. In most cases, anything that makes you postpone getting started isn’t worth thinking about too much.

Ideally, choose the medium you’re most comfortable with. I learn best reading vs watching, so I would personally choose a book or a website with tutorials. But a lot of people are more visual and video would work better for them.

What I think it’s more important is what you learn and the order in which you learn it.

Basics

The first thing you should learn is the basics. Pick any language that you’re curious about and learn about:

Variables
Data types
Control structures
Data storage and access

Which language? Again, it doesn’t matter as much as you think it does.

The purpose of the first programming language you learn isn’t to become an expert in it. It's just to learn how to think like a programmer. You can pick up another language later. In fact, it will be easier to pick up and learn any other language after you already know one.

That said, when people ask me which language to start with, I usually say Python or JavaScript.

Tutorial

After you learn the language basics, I think it’s good to do ONE tutorial to get a feeling of what it is like to start and complete a project in a short amount of time.

However, don’t start doing tutorial after tutorial or you’ll get stuck in tutorial hell.

Object Oriented Programming (OOP)

A lot of the languages widely used today are object oriented, so it’s a good idea to learn about that next. Learn the basic concepts and principles of object oriented programming.

Be warned that a lot of OOP resources start talking about animals and houses to teach you basic concepts, instead of using real world scenarios. In my experience you really “get” OOP when you actually start using it.

Algorithms and Data Structures

When you first start learning algorithms and data structures it might seem like meaningless theory, but they actually help you develop your problem solving skills.

In any given program you basically have data and a set of instructions that do something with this data. Learning data structures will make it easier to organize the data in a way that makes sense and makes its handling easier. And learning algorithms will help you figure out the most efficient way to handle data to get the result that you want.

Project

After learning the basics of the first 4 topics, it’s time to do a project on your own. You might think it’s early and that you don’t know enough, but trust me, after a certain point this is the best way to learn.

There’s always this gap after you do a tutorial where you feel like you understand the concepts but you can’t actually build something on your own. This is because the tutorial was holding your hand and telling you what code to write (which is fine). But the way to bridge that gap is to start a project on your own.

Of course, there will be many times when you won’t know what to do. That’s part of the process, and that’s when you will make use of your new best friend, Google. By looking up a problem that you are actually facing, finding a solution for it and then implementing it, you will absorb the knowledge easier than if you just read about it in a book.

A few tips:

Make sure that every time you come across a coding exercise or example that you actually type it instead of just copy pasting. That will help you remember things better. It does make a difference.
Be consistent. Make a schedule, or at least decide on a set amount of hours you’re going to learn every day.

There’s this stage when you’re learning something, when you realize: “wow, this road is going to be way longer than I thought”. Don’t get discouraged. It’s normal to feel overwhelmed at some point, but just keep working on it and you’ll see results.

Mindset. This kinda relates to the previous tip. You’re going to get stuck at some point, that is a Expect it so that you’re not frustrated when it happens. See getting stuck as part of the learning process.

Programming is mostly about problem solving so by encountering roadblocks you’re actually practicing one of the most important skills you need to have as a developer.

Google is your friend. To be a programmer you have to be a lifelong learner, because there will always be something you don’t know.

Luckily, every popular programming language has a big online community, and you can find an answer for virtually any question you have. So when you’re stuck, or if you’re not sure about something, just look it up online.

This is the end of the post, but this is not everything you need to know about programming! There are sooo many more topics to learn about, from design to testing and documentation. But if you want to get started, now you know how.

Humans, not computers.

Catherine — Tue, 08 Jun 2021 03:08:22 +0000

The other day I was reading this post by Hammad Khalid, and in it he mentioned what I think is a very important principle in software development: Write for humans, not for computers.

I remember taking my first computer science class, when code readability was not even a known concept to me. I would use variable names like a,b and x. I would create a Java program and pack all of my code in one class.

Now gone are the days of writing code that does the job and calling it a day. As are the days of one letter variable names.

I’m sure you have met developers that are very concerned about writing error free code and about performance and memory usage (which are all important things), but don’t care about whether their code is easily readable. I think most of us have been there at some point in our journey.

What’s the problem?

The problem with only caring about functionality and performance is that while the computer won’t care what your code looks like as long as it runs, at the end of the day, it’s humans that will have to deal with your code.

Your code might be perfect now, but it will likely require changes in the future. These changes will likely be made by other people. Or what if a bug is reported? If the code isn’t easily readable, it will be way harder for whoever is trying to fix it to understand what is going on. In fact, writing readable code will even make your future self’s job easier. Do not underestimate the possibility of being confused by your own code.

You could be thinking: “Well, that means I should write more comments then, so that when someone else reads my code they can understand what I’m trying to do”. Think again. The problem with relying on comments to make your code understandable is that they might eventually be wrong. There is no guarantee that the next person that changes your code will also update your comments. So the comments end up being inaccurate and confusing anyone who is reading the code. This is why it’s better for your code to be self explanatory.

So what IS the way then?

Here’s what you can do: If you feel like you’re code needs comments, try refactoring to make it more readable instead.

How?

Use method names to make it clear what the code is supposed to do.
Try your hardest so that each method does only one thing. For example, if you end up with a method name like createReservationAndEmailGuest, you can probably split it into 2 smaller methods, one that creates the reservation and another one that emails the guest.
If there’s a lot of code in one method, look for a way to separate it into smaller methods.
Use descriptive variable names. It doesn’t matter if they’re long. Get rid of a, b, c and abbreviations.
Avoid magic numbers at all costs. A magic number is a value with unexplained meaning. Basically a number thrown in the code that doesn’t mean anything to someone that didn’t write it. For example:
```
If(password.length < 8){
    return “Invalid password”;
}
```

Here you should replace the 8 with a constant such as MIN_PASSWORD_SIZE:

If(password.length < MIN_PASSWORD_SIZE){
    return “Invalid password”;
}

This gives the reader a more complete picture of what you're comparing password.length to.

Write unit tests. Unit tests actually provide documentation. If an application has good test coverage, developers can look at tests to learn what functionality it provides and have a general understanding of the app’s interface.
Don’t optimize prematurely. First focus on writing code that is readable, and then optimize if necessary. If a 0.1% of performance improvement is going to make your code less readable, chances are it’s not worth it.
Include a readme in new projects. Here you should include an overview of the purpose of the project, an explanation of the design/architecture, and instructions on how to deploy it locally, if applicable.

It might be annoying to do all this if you’re not used to it, and you might feel like you’re wasting time. But believe it or not, it will save you time along the way. Think about it: A lot of your work as a developer probably consists in reading other people’s code, especially if you’re fixing a bug. So actually, making your code easier to read will make new code easier to write, which will make your team more efficient overall.

Memory leaks in Java and how to avoid them.

Catherine — Tue, 08 Jun 2021 03:05:33 +0000

Garbage collection is the process by which the Java Virtual Machine determines which objects are no longer in use in an application, and proceeds to remove them from memory so that it can be recycled for other uses. Based on that, you might think that it’s impossible to have memory leaks in Java, yet here we are.

A memory leak happens when an application is no longer using certain objects, but they’re still being referenced. Because of this, they are not eligible to be removed by the garbage collector. As time goes on, and the application continues running, more and more objects like this get created until the available memory fills up. This could eventually lead to an OutOfMemoryError, which is impossible to recover from.

Memory leaks are some of the trickiest issues in Java Applications. They can be easy to miss and hard to detect.

How to know if your application has a memory leak

If:

Your application works fast when it has just started running, but slows down over time
Your application does okay with small datasets, but struggles with large datasets
You get OutOfMemory heap errors
Your application has random/weird crashes

… there’s probably a memory leak somewhere.

As I said, it can be difficult to detect memory leaks, so it’s best to avoid them. I’m going to tell you about some common memory leak scenarios and good practices to prevent them.

1. Heavy usage of static fields

This is a classic memory leak scenario where Java objects are being created without being released. Static references persist throughout the lifecycle of the JVM, and therefore the object cannot be cleared from memory.

For example:

public class StaticFieldMemoryLeak {
    private static List<Integer> integers = new ArrayList<Integer>();

    public void insertIntegers() {
        for (int i = 0; i < 100000000; i++) {
            integers.add(i);
        }
    }

    public static void main(String[] args) {
        StaticFieldMemoryLeak staticFieldMemoryLeak = new StaticFieldMemoryLeak();
        staticFieldMemoryLeak.insertIntegers();
        System.out.println("Done with inserting integers");
    }
}

By the time we reach the line where we write “Done with inserting integers”, we don’t need our List anymore. But since the List here is a static field, it will never be collected by the Garbage Collector, even after every line of code that uses it is executed.

Of course, this is a small example with a very simple program. But imagine that you have a large application with complicated processes, and it has a bunch of unnecessary static variables. In that case you would be using a lot of resources that could be used for other things, and you could possibly run out of memory.

Now let’s look at the same example, but this time we’ll declare the List as a local variable.

public class StaticFieldMemoryLeak {

    public void insertIntegers() {
        List<Integer> integers = new ArrayList<Integer>();
        for (int i = 0; i < 100000000; i++) {
            integers.add(i);
        }
    }

    public static void main(String[] args) {
        StaticFieldMemoryLeak staticFieldMemoryLeak = new StaticFieldMemoryLeak();
        staticFieldMemoryLeak.insertIntegers();
        System.out.println("Done with inserting integers");
    }
}

In this case, the List will be used and then properly discarded, and the garbage collector will be able to recover the memory it was using. Because it is a local variable, when we reach the point the code where the variable is no longer being used, the garbace collector determines that it can free up the memory.

How to prevent it?

At this point you probably know already: Be mindful of your use of static variables. Keep in mind that declaring an object as static means that its lifecycle is tied to the JVM’s lifecycle.

2. Unclosed resources

Forgetting to close a stream or connection is a common problem that causes memory leaks. I would say this is the one I have seen the most in practice.

Take a look at this example:

public class UnclosedStream {

    public void readFile() {
        StringBuilder strBuilder = new StringBuilder();
        URLConnection conn = new URL("http://testurl.com/large_file.txt").openConnection();
        BufferedReader br = new BufferedReader(new InputStreamReader(conn.getInputStream(), StandardCharsets.UTF_8));

        while (br.readLine() != null) {
            strBuilder.append(br.readLine());
        }
        strBuilder = null;
    }

    public static void main(String[] args) {
        UnclosedStream unclosedStream = new UnclosedStream();
        unclosedStream.readFile();
        System.out.println("Done with reading file");
    }
}

As we read the file, the memory usage will gradually increase. Then, because the BufferedReader is never closed, the memory won’t be released even after you’re done reading the file.

This can also happen with connections:

public class UnclosedConnection {

    public void readFile() {
        URL url = new URL("ftp://fakeaddr.net");
        URLConnection urlConn = url.openConnection();
        InputStream inputStream = urlConn.getInputStream();
    }

    public static void main(String[] args) {
        UnclosedConnection unclosedConnection = new UnclosedConnection();
        unclosedConnection.readFile();
        System.out.println("Done with connecting");
    }
}

As you can see, the URLConnection is never closed, so it remains open and holding memory resources.

How to prevent it?

Simple, always remember to either:

Close streams manually
Use try with resources, introduced in Java 8:

    try (BufferedReader br = new BufferedReader(
            new InputStreamReader(conn.getInputStream(), StandardCharsets.UTF_8))) {
        // whatever else you wanna do
    } catch (IOException e) {
        e.printStackTrace();
    }

This will automatically close the BufferedReader at the end of the try statement.

3. HashSets and HashMaps keeping object references alive

A very important feature of a HashSet or HashMap is to avoid duplicate elements. However for that to happen the objects you insert need to have a hashCode() and an equals() implementation.

If you insert objects without those implementations, it becomes impossible to tell which elements are duplicate. That means that you might end up adding a lot of unnecessary objects and increase the possibility of a memory leak.

How to prevent it?

Always add a hashCode() and an equals() implementation to your objects, if you plan to put them in a HashSet.

4. Calling String.intern() on a large String (Before Java 8)

The String.intern() method creates an exact copy of the String object in heap memory and Stores it in the String constant pool. Again, since it’s stored in JVM memory, it can’t be collected, and this might cause the garbage collector to be unable to free up enough memory.

If you need to store a lot of large strings in JVM memory, consider increasing the PermGen space.

In Java 8, PermGen space is replaced by Metaspace, which won’t lead to an OutOfMemory error.

How to find possible memory leaks in your application

OK, let’s say you are dealing with an application and you suspect you have a memory leak. How can you find out?

1. Eclipse

This applies for any code that’s JDK 1.5+ compliant. Eclipse will warn you about some memory leaks. It will throw a warning if there is any object that implements Closeable and the reference is destroyed but the object not closed.

To enable this, go to your Eclipse preferences and set the following:

2. Verbose garbage collection

You can do this by enabling the -verbose:gc parameter of the JVM configuration of your application. This will enable a very detailed trace of the garbage collection.

3. Benchmarking

Benchmarking allows you to measure the performance of sections of your code. That way you can constantly monitor it to find out if any particular method is particularly slow. If you want to learn more about benchmarking in Java, follow this link.

4. Profiling

A Java profiler is a tool that monitors JVM level operations, including garbage collection. Some popular ones are YourKit and VisualVM.

5. Code review

This is generally a good practice, but if you’re trying to find memory leaks, review the code closely, and try to get another set of eyes to review it as well. You might notice some of the issues I mentioned here.

I hope this helped you learn a little bit more about memory leaks and how to avoid them. If you’re currently stuck trying to find one of those, good luck bestie!

I tried the Pomodoro technique for a week. Here's how it went.

Catherine — Sun, 12 Jul 2020 17:39:51 +0000

This post was originally published to my personal blog. You can find it here.

I had to admit it: I had a productivity problem. It was not like it was ruining my whole life, I still got all my work done on time, and it was not like I was incapable of focusing on a task.

However, completing a task was sometimes taking me way more than it should, either because I got distracted or simply started doing something else.

This was happening especially with tasks that I found boring or that were too repetitive.

The problem with procrastination

At first glance you might think that the only problem with procrastination is that you don’t get your work done on time. But many chronic procrastinators are actually able to complete their work just fine.

To me, the real problem with procrastination is that you end up having to work longer hours, and at the end of the day you don’t have time for anything else. And even if you have a little time left, you just don’t have the energy. Ironically, because you can’t focus on work, your life ends up being just work.

That’s why it was very important to me to find a cure for my procrastination habit.

Enter the pomodoro technique. I first heard about it years ago from a coworker who swore by it. However, I was skeptical because I thought: How is a timer going to make me more productive? If I’m going to procrastinate I’m going to do it regardless!

But I finally decided to give it a try. If all these people are using it, there must be something to it.

These are the 6 steps from the original technique (from the Pomodoro Wikipedia page):

Decide on the task to be done.

Set the pomodoro timer (traditionally to 25 minutes).

Work on the task.

End work when the timer rings and put a checkmark on a piece of paper.

If you have fewer than four checkmarks, take a short break (3–5 minutes), then go to step 6.

After four pomodoros, take a longer break (15–30 minutes), reset your checkmark count to zero, then go to step 1.

Finding an app.

Technically, you can follow the Pomodoro technique with your phone’s timer. You can set it to 25 minutes manually every time, and then to 5 minutes for each break.

However, there’s no need, since there are a lot of websites and apps that do all of that for you.

Which app to use? I didn’t give this too much thought.

At first I tried using a website, since that seemed like the easiest option, but I didn’t like the fact that I couldn’t see the timer at all times. I could only get a notification when the 25 minutes were up. And honestly, I needed the motivation of seeing how much time was left until my next break.

So I decided to download a native OSX app, Be Focused. The app shows a timer in the menu bar.

How well did I do?

I'd say I was able to respect the timer for about 50% of the time it was running. The rest of the time I had some issues with it:

Sometimes I simply forgot to look at the timer in the menu bar and I missed the break.
Some tasks, especially complex ones, have their own natural breaks or pauses. And Pomodoro sometimes forces you to take breaks that don’t make sense, or it forces you to continue working when you have to take a break after completing a difficult task.

At times I found myself really focused on a task, but the pomodoro timer was showing me that I had 20 seconds left till my next break. I had to force myself to stop and the pause felt unnatural.

Sometimes interruptions just happen and I can’t control it. What if someone knocks on my door? What if I have to take a really important call? If you are at the office, what if a coworker comes to your desk? I work remotely so that doesn’t happen to me, but they still message me. Sometimes I can ignore them until I’m done with my current task but sometimes I have to reply right away.
Some distractions are inevitable. I don’t know if you feel the same way, but sometimes I get distracted by my own thoughts. My mind just drifts and I start daydreaming or thinking about something else. Sadly, a Pomodoro timer cannot prevent that.
Sometimes the timer would go off while I was in a meeting. I work remotely so nobody else heard it. However that’s just another instance where Pomodoro doesn’t work. If I’m in a meeting I can’t just leave for 5 minutes until my break is over.

But enough with the negatives. You would think I absolutely hated Pomodoro based on that list. No, I can still appreciate its positive aspects:

Knowing that there is a relatively small timeframe that I have to work continuously for, helps me to keep pushing through and not get distracted when doing boring tasks.
It definitely helped me waste less time. Whenever I felt tempted to check my phone I had the timer staring at me and I knew I couldn’t just start procrastinating and browsing Twitter.
It improves the quality of the time I spend on a task. If I know I only have 25 minutes to work on something, I will try to make the most of it. As opposed to thinking I have hours or the entire day to complete a task. It helps to have that mini deadline.
I don’t feel guilty when I am taking a break. Before, when I took a break it felt like I was wasting time, but with Pomodoro, those breaks are planned and they feel like part of my work day.

Something I’d like to improve

An improvement I’ll make next time is find something better to do in the 5 minute breaks. What I did last week was just go on twitter or check my phone, but I think a better use would be to do a short walk in my living room or look outside my window. Something that doesn’t involve staring at a screen.

Bottomline

I will still be using Pomodoro, but instead of starting the app at the beginning of the day and forcing myself to use it through the day, I will start the 25 minute timer for specific tasks.

I think it works really well for tasks that don’t require too much thinking. Or tasks that are boring and that I find hard to keep focused on.

My personal git cheat sheet

Catherine — Sun, 05 Jul 2020 22:05:56 +0000

With more than 160 commands available, becoming a git expert takes time. But everyone has a few commands that they use frequently. In this post I’ll share mine.

I want a clean working directory, but I don’t want to lose my current changes.

# save the current state of the working directory 
git stash

# apply the latest stashed change to your current working tree
git stash pop

# list stashed changes
git stash list

I messed up my last commit message.

# change the latest commit's message 
git commit --amend -m "Fixed message"

I accidentally pushed a file. Now I want to remove it from the remote branch (but not from my local branch).

git rm --cached <file-path>

I made a bunch of changes to a file but I regret it 😱. I want to go back to the main branch version.

git checkout main <file-path>

I want to take a commit from one branch and apply it onto mine.

git cherry-pick <commit-hash>

I want my branch to be based off the most recent commit of the main branch.

# 1. Get the latest version of the main branch 
git checkout main
git pull origin

# 2. Checkout your branch
git checkout <my-branch>

# 3. Replay your changes on top of the main branch
git rebase main

I want to squash the commits in my branch to a single commit, before opening a pull request to main.

Before squashing, make sure your development branch is based off the most recent commit of the main branch using rebase. Then:

# 1. Checkout your branch
git checkout <my-branch>

#2 squash commits
git rebase -i main

# The -i does an interactive rebase for you to move and squash commits.

I merged my branch into main but I want to rollback the merge

# 1. Checkout a new branch from the main branch
git checkout -b mybranch-rollback

# 2. Find out the commit hash that merged your branch to develop.
git log 

# 3. Revert the merge commit
git revert -m 1 <commit-hash>

# 4. Push the changes to your new branch
git push origin mybranch-rollback

# 5. Open a pull request to main for your new branch

How to do a good code review

Catherine — Mon, 23 Mar 2020 20:58:19 +0000

Did you read my post “Why do code reviews?”?. If you did, you know that with time, I learned to appreciate and even want other people to review my code.

When it was my turn to review other people’s code, the story was different. Many times I had no idea what to look for and, without knowing, ignored many problems in the code. I was also new to that company and didn’t have that much experience. This made me feel like I wasn’t qualified to review the code of people who had been doing this for 10 years.

Now that I have more experience, I want to tell you some things that I would have liked to know back then. These can help any developer that has to review code, regardless of their level of experience.

What should I look for in a code review?

That the code is easy to understand. Can you understand it without asking too many questions? The developer that wrote the code won’t always be there, so it’s ideal if the code is as self-documenting as possible.

That the code doesn’t introduce new bugs. You might not always have such a deep knowledge of the code that it allows you to find any bug just by reading it. But, you can try, to the best of your ability, to “run” the code in your mind while you are reading it. This will make it easier to identify the parts that could cause problems.

That it follows the industry best practices, and your team’s standards. When everyone writes code “their way”, the codebase becomes messy and inconsistent. As a result, it becomes harder to understand.

How can I perform better code reviews?

Ask questions. Sometimes you will notice obvious problems, and it’s natural to point them out or recommend a change. But sometimes a developer makes a design decision with a particular reason in mind. That reason is not always obvious when you are reviewing the code. In those cases, I recommend asking questions rather than giving direct recommendations. For example, instead of saying: “Move this code to a separate class”, you could say: “Wouldn’t it be better to move this code to a separate class?” Or, “Why did you include this code here and not in a separate class?” As a result, if there is a reason behind that decision, the person can explain it. If not, they can take your suggestion.

If you’re pointing out a problem, offer a solution. It is not very helpful to say “this is wrong” or “I can’t understand this code” if you will not offer an alternative. If you know something could be better, take a little time to think about how you would change it and mention it. Remember that the goal is to improve the code, not to be a critic.

Become familiar with the context of change. If you review a code change while not knowing its purpose, you cannot assess whether it works. Before you examine the code, look up the requirements. If it’s a bug fix, look up the description of the reported problem. That will give you a better idea of what the code should do, and you can evaluate it based on that.

Be impartial. It’s easy to think you should spend more time reviewing the code of a junior developer versus that of an experienced developer. I have missed things before by not being that thorough when reviewing the code of a senior developer. No matter who is the author of the code, there might be mistakes or points for improvement.

In conclusion...

The most important thing in a code review is attention to detail. The second one is approaching the task with the right attitude. The best way to perform a code review is to assume that there are problems, and that it is your job to find them.

Why do code reviews?

Catherine — Tue, 15 Oct 2019 11:00:53 +0000

I still remember the first time someone left me a comment in a code review. The disrespect, the audacity, how does anyone dare to criticize my perfect code?

For me it was a completely new experience to have someone else go through my code and tell me in detail what I should change. Fortunately, after going through the same thing a few times, I began to accept and understand the importance of code reviews, and I got used to my new life.

First of all, let's define: What is a code review? A code review is an activity in which one or more programmers examine another programmer's code. This is done in order to find problems of any kind at an early stage of the software development cycle.

Right now I can't imagine a project where code reviews are not performed, and the reasons are many. If your team doesn’t do code reviews, I hope these convince you to start.

No matter how much we want to believe it sometimes, we are not perfect. For that reason, having a group of engineers on your team check your code is extremely valuable. No matter how much you look at your own code, there are things you won't see just because you're too familiar with it.
A code review is an opportunity to learn from the different backgrounds of your teammates. Even when everyone in your team is an excellent engineer, everyone has different strengths. Some can be very good at unit testing, others will be better at design and architecture, and others at following good coding practices. The point of teamwork is to complement one another’s abilities.
Even if your code is perfect functionality wise and has no bugs, another crucial aspect is that the code is readable and understandable by other people. Remember that your code will most likely be modified by someone else in the future, so it's helpful to know if other developers can "guess" what it does.
Code reviews are also learning opportunities for other members of your team. It is not only for others to give you recommendations on how to improve your code, but also for everyone to learn to identify problems in code, and of course, to learn from the things you do well.
Finally, a review helps everyone to become more familiar with the codebase, and keeps everyone aware of the changes that are made to different repositories day to day. It is also a good way to introduce new members to a project and help them become familiar with the source code.

I hope I have convinced you that code reviews are important, if not essential, to software quality. If your team is not doing them, bring up the idea, or better yet, show them this article! Who knows, you might change their mind.