DEV Community: BlazingBits

BlazingBit's Declassified Junior Dev Survival Guide

BlazingBits — Thu, 31 Jul 2025 01:00:06 +0000

As a Senior Developer a topic that often comes up in conversation is how I mentor and teach my Juniors. Software is a massive field. There's always something to learn and its easy to feel like you're starting from last place in the race. This is doubly true for true Juniors starting their first real dev job. They're nervous, excited, and overwhelmed all at the same time.

I decided to sit down and write up this article for those Juniors (and some Seniors who hopefully find themselves mentoring the next generation of great developers). College and Bootcamps do their best but they can't prepare you for everything you'll face when you enter the workforce. Writing a sorting algorithm off the top of your head won't prepare you for success in the workplace. Hopefully you gain some insight on how to be the best dev you can be from this article and start to build your own reputation!

Don't Be Afraid to Ask Questions

Picture this. You're a new hire at a software company that's been around the block a few times. You've been placed on a great team working on a few different projects that have already been running in production for quite some time. You've finally made it. All those late Red Bull fueled nights and LeetCode cramming sessions have paid off.

The team you've been placed on has a great mix of Mid Level, Senior, and even a Staff Engineer. These guys have been in the field for a while and you're excited to work on something real. You join your first standup meeting of your career and people start talking. They're using all kinds of words and acronyms. Some you understand, at least in passing, some... you have NO idea. Did they go over that in orientation?

What do you do?

This is your first real challenge as a Junior developer. You're thrown in the deep end without a life raft (so you think). It's different from college or the bootcamp. There's no presentation beforehand to prep you for all this new information. There's no homework assignment (that you definitely didn't do last minute) to bring you up to speed. You're lost. What can you do?

Start asking questions! The first fear you will have to overcome on this new journey is the fear of looking stupid. No one expects you to know everything. In reality, your team will be more concerned that you aren't asking questions.

You don't know what you don't know. Don't be afraid to ask, "what even is this thing?" This is the easiest thing you can do to start learning and making an impact!

If you find yourself with a million and one questions at the end of a meeting. Don't worry! Your team is there to support you. I find it practical to write down questions that come to me during meetings but aren't urgent. I then get to work and start finding answers. Sometimes I do the dirty work and use my google fu to get a baseline understanding. Other times I find it more helpful to turn to my peers and ask them directly. There's no shame in not understanding something.

Speak Up, Speak Out, Get Noticed

One trait of new Junior engineers I've seen over the years is that most (but not all!) tend to go silent when someone important is in the room (or in the slack channel). When a manager or someone with a fancy sounding title joins the conversation they'll go from lively conversationalists to stone cold stoics.

Speak up! Don't let the fancy titles and the higher salaries scare you. They're just people like you and I. Share your thoughts and opinions like you would if they were not involved in the conversation. Showing them that you're actively participating in the team's discussions and not just sitting there waiting to be told what to do is great way to build your reputation and have you stand out! The same goes for leading meetings. If you have an opportunity to lead a meeting for your team, no matter how small the topic. Take it!

I was extremely lucky early on in my career to have this fear of important titles/people worked out of me. During my internship (and unbeknownst to me) I and my teammate worked along side our company's CTO for the entire duration of our summer internship. We treated him just like any other person. We had lots of chats, after work bar hang outs, and built a great camaraderie. It wasn't until our internship ended and we got actual full time positions at the same company that we learned just how fancy his title was! After the initial shock wore off, we learned an extremely valuable lesson. Behind the fancy title, he was just another nerd like us.

Soft Skills Matter

A misconception I think a lot of Junior engineers and students have is that Engineering is a solo sport. "I don't like people so I went into tech" is something I not only heard a lot while I was in school but, continue to hear from students and newly hired Junior developers. I'm here to tell you, if you think that's true, you're in for a very, very, long career.

Software is a team sport... and the team isn't all just us developers. You will have to talk to business people, managers, sales guys, customers. A multitude of people all with different personalities.

Your soft skills will matter. We as engineers get a little leeway (people kind of expect us to be a little awkward). But the ability to communicate effectively and at a level everyone can follow will do more for your career than any Javascript framework of the month. Plus, no one wants to work with someone who comes across as an asshole.

Sometimes Less is More

It's not the quantity of code you write, its the quality. Professional development isn't a competition. There is no annual award ceremony for the most lines of code written.

A trait I see in a lot of fresh Juniors is the tendency to want to write tons and tons of code, for every problem that's presented. I'm here to hopefully keep you from falling into that trap. Take a second to stop and think about the problem.

Before automatically hammering out a bunch of new code to tackle a problem. Take a breather. Look around. Is there code already in the project that does what you want? Or, a more realistic example, is there code already in the project that does 80% of what you want that just needs a few tweaks? Some times less is more and you'll save yourself a ton of time come peer review if you slow down and take stock of what is already there.

I wasn't immune to this. It's one of many lessons I learned the hard way. I remember early on in my career I was tasked to implement a small feature in our code base. I did what any Junior would do, I got to work! I wrote a bunch of new methods, unit tests, beautifully designed code (at least I thought it was at the time). When I was finished I opened my pull request and sent it to my mentor for review, thinking I had just nailed it. My mentor being the calm and cool veteran that he is (we are still friends to this day 10 years later, shout out Carlos) called me over to his desk, talked over everything I did and what it did great and what it did not so great. And then, highlighted it all, hit delete, and replaced it with a single method call that was already written... It's a tale as old as time in our field.

Giving and Receiving Feedback

That last story brings us to a very important topic. Giving and receiving feedback to and from your peers. This is something you will have to do at all levels, through your entire career and this advice is applicable to all levels of your software journey.

First and foremost, leave your ego at the door. Engineering is a team sport. You may be super proud of the pull request you've just opened. And you should be! That doesn't mean you've written perfect code. There is always something to improve and your peers want to see you improve! Comments on your code are NOT personal attacks. They're simply recommendations or potential pitfalls you might have missed. Don't grow overly attached.

Make your feedback count. I once worked with someone who left a million comments on every PR... The only problem is, none of those comments were helpful. They were pedantic, didn't point out any real problems, and didn't improve any aspect of the code under review. Everyone has their own ideas of beauty. This is true for art, furniture, and even code. But stylistic comments (unless its just insanely garish) do not provide any value.

Leaving a million comments on someone's pull request that say something along the lines of "you didn't end the comment with a ." are not helpful and will actively harm your reputation. *Eventually, your peers will not take your feedback seriously and start to automatically assume you have nothing helpful to say, even when you do! *

Try to use inclusive language. Try to form your feedback in questions. While you should strive to keep your ego in check, not everyone is as good as it as you might be. You don't want to attack your coworker. Using inclusive language is a good way to mitigate those hard feelings when leaving feedback on something they've worked hard on and are proud of.

Additionally, getting straight to the point can sometimes feel like an attack. I try to use words like "we", "what if", "what happens when?" when writing feed back to help avoid any feelings of attack. A good example would be "what happens when this call throws an error? Should we catch it and try to fix the issue or should we let it bubble up?" or "we should look into what happens when this value is null"

On top of being a little less hostile, asking questions can also trigger meaningful conversations. "What happens when this API call throws an error" could lead into a conversation on the best way to report the error to the user. Or it could lead into a conversation about testing patterns. Or even discover a whole new area of work that is a missed opportunity. These conversations might not have ever happened if you made more direct feedback of "catch the error".

Its Okay to Make Mistakes

One thing I wish new developers would learn is to get over their fear of mistakes. I know, I know, that's asking for a lot. Keep in mind that we're all human. It's not a question of if we make a mistake but when. And, that's okay.

The simple fact of the matter is... you're going to make mistakes. That doesn't mean you're a bad developer. It doesn't mean you're not cut out for this career. It just means you're human. Don't shy away from your mistakes. Embrace them and learn from them and you'll come out stronger and better than you were before. yes... I know that sounds cliche but its true. Don't beat yourself up over them.

If someone tries to tell you they've never goofed up in this field they're either the luckiest person in the world... or they're lying to you.

Make Friends

For many of us high school or even college were the last times we were in a structured environment full of people entirely in our own age bracket. Unless you're in a company full of just your friends you're going to be working along side people of all walks of life and all ages. Embrace this!

Make friends with your coworkers! I'm assuming that you enjoy development work (if not, then you're in for a rough time) but its not always fun. That's just the nature of having a job. Making friends and building relationships with your coworkers will do wonders for your mental health and help pull you through those rough sprints.

Your coworkers are also a vast wealth of knowledge. You'll be surprised how much you can learn from them just for little side conversations. Those interactions, inside jokes, and conversations will help bring joy to your daily life, especially when things get tough.

I understand that not every one of us are social butterflies. In fact, I'd wager that more of us are introverts rather than extroverts. Don't force your social interactions. This can have the opposite effect that you want. In time you will naturally grow closer to your team and become more comfortable working and socializing with each other. But keep in mind, relationships of any kind take work.

I'm lucky enough that I've managed to build lasting relationships with a lot of coworkers. I still talk regularly with people I haven't worked along side with in years. Its always fun and interesting to hear what they're up to and learn about the things they're working on. I've learned an immense amount from them as well. And I know if I ever get in a pinch I have a wonderful supporting community to fall back on.

Its All About Balance

Work life balance has become a buzz word of sorts these recent years, that doesn't make it any less important however. Engineering and software development is a tough job. I won't sugar coat it, it can be hard, confusing and stressful.

As with all things in life, its exceedingly important to strike a balance. Especially in this field. Its your job as a professional to keep things balanced out. Without some kind of work life balance you risk crashing and burning. And trust me, that crash is hard.

Take notice of how you're feeling. There is no harm in taking some me time. Your company has a PTO policy for a reason, use it! Take a vacation to de-stress and unwind, even if it's just a stay-at-home-cation. It can do wonders for your stress levels and help you feel invigorated when you come back to work.

Sometimes this job calls for crunch time. You'll have to burn the midnight oil every now and then. But don't make that a common occurrence. You'll do more harm than good being known as the "work-a-holic". And the longer hours you pull the worse your work will become.

Tying It All Together

Hopefully you've gained something from reading this short little article I've put together. Starting your career is a daunting feeling. There's so much going on and so much to learn it's easy to feel overwhelmed. It's my hope that this guide has given you some guidance and tips on how best to navigate the early stages of your career. Asking questions, speaking up, embracing your mistakes, making friends, knowing how to give and take feedback and, keeping your life in balance will set you on the right path for a rewarding career!

AI Notice

AI was used to proof read and point out any grammatical and spelling mistakes. After all I'm an engineer not an English major.

What Hockey Taught Me About Teamwork

BlazingBits — Sat, 03 Aug 2024 03:16:57 +0000

I've been playing adult recreational hockey (Beer League as its more commonly called) year round for about 5 years now. Currently living, and being born and raised, in the Deep South always gets me some odd looks when people ask what my hobbies are. Hockey just isn't popular down here, and nothing can touch the juggernaut of Football.

In those 5 years I've: won league championships, skated so hard I thought I might die, seen tempers flare, shared in the excitement in the locker room after a big win, sat in silence after a hard loss and, have fallen on the ice more times than I can count.

I didn't pick up hockey until I was well into my 20's. I'm definitely not what you would call "impressive". But, it's one of the most rewarding parts of my life.

During the day I'm a Senior Software Engineer, a career I've happily been in for almost 10 years now. I love development, its also another majorly rewarding part of my life. Much like hockey, development too, is a team driven sport.

Here are some the of lessons I've learned about team work during my (extremely) amateur hockey career and, how it applies to my actual career. For those of you who aren't familiar with hockey, don't worry, I will break down the intricacies of the sport as best I can and how they relate to a real world software development team.

Everyone Has A Role To Play

Hockey is an extremely team oriented sport, with out a healthy team dynamic and culture your team simply wont perform its best. I believe this to also be true for software development teams. In a healthy team, everyone has a role to play and no one person can do it all alone.

Understanding the strength and weaknesses of the team makes a huge difference in how well your team plays. Positioning your team to take advantage of as many strengths and cover as many weaknesses as possible is a sure fire way towards success in both sports and engineering.

Knowing your strengths and weaknesses, knowing your role on the team and how it changes over time and, being honest about these things with your teammates and leaders can help build a super productive team. As much as us developers like to think we are super geniuses, we don't know everything. You have to be honest with yourself and your team. Covering the gaps in skills can only help you in the long run. Allowing the team to be more productive and gives you the opportunity to learn from others and make that skill gap less large.

Put The Team Above Yourself

While it's important to stand out and build a reputation for yourself. No one wants to play with a puck hog. Putting yourself above the teams needs, only doing things that make yourself look good and, throwing your teammates under the bus is not a recipe for a winning team on or off the ice.

As in hockey, the same is true for software development. Putting yourself above the team only builds resentment, ruins team dynamics and, creates a toxic environment. If everyone is only looking out for themselves it's going to be hard to build a great product or deliver a critical feature.

Assists are just as, if not more, important than goals. Gretzky, Ovechkin, McDavid, these are all big stars in the NHL. Even if you aren't a big hockey fan you probably recognized at least one of these names. These guys put up big numbers, score lots of goals and, most importantly, have earned the trust and respect of their teammates.

The respect and trust of their teammates is exactly why they're so great. Its true that these guys have immense hockey talent but, without the backing of their teammates they wouldn't be stars. They also recognize the importance of that teamwork and know when its better to support a team member instead of hogging the puck and trying to get a goal themselves.

You have to put the team above yourself. You're all in this together. Being a good engineer isn't just about how many features you can slam out, how many bugs you can fix or, how impressive your boss thinks you are. A good engineer should always be concerned about the team. The team's wins are your wins and the team's losses are your losses.

This of course, also means you can't always be the Star player. Its better to give an assist and back up your fellow teammate(s) who might be better positioned to solve a problem. And to trust that they will do the same for you when the circumstances are different.

Once the team starts thinking of themselves as a collective, rather than a bunch of individuals fighting for the limelight, life gets a lot easier and work becomes a whole lot more fun. The team will be better aligned with its goals, ideas and solutions will appear more easily, team member turnover will drop, and it will be harder to rock the boat when the unforeseen critical issues rear their ugly head.

Call for A Pass

Hockey isn't a quiet sport. The sticks slapping on the ice. Bodies and pucks slamming into the boards of the arena. These are all common sounds you'll hear at a hockey game. Another one you might notice, if you've ever gotten the chance to watch a game in person, is that hockey payers yell... a lot.

They don't yell in anger though. They're communicating.
"Heads up!"
"Watch the crease!"
"Boards!"
They're talking to their teammates to let them know what they're missing or what they're about to do.

While you probably shouldn't yell at your teammates in the office or over Zoom (No one wants to deal with that). You should keep that same spirit of communication. Open a dialog with your team. Let them know what you're about to do. Tell them you're struggling with something. Share your ideas and solutions so your teammates can offer suggestions.

The last thing you want to do is build a silo. Communicate openly and honestly with your team to help foster collaboration and knowledge sharing. Not only will it help your team come up with better solutions it will make your work more enjoyable.

Protect Your Teammates

Hockey is famous for its fights. Searching for "hockey fights" on youtube will bring up hundreds of videos at all levels of the game. But why do hockey players drop the gloves and trade knuckle sandwiches?

It's all about protecting your teammates. In hockey there is an unwritten Code. A set of rules of behavior that players instinctively know and follow. When another team's player breaks those rules it can put your teammate in a dangerous situation, and consequences are sure to follow.

Now, don't misread this, I'm not advocating for violence in the work place. The important take away from this is that you should strive to stick up for your teammates and expect them to do the same for you. We're all human, we all make mistakes.

Sometimes things happen. A bug made it past testing or someone misunderstood the impact a particular change will have. If you haven't caused at least one major event in your career your either lying or the luckiest person in the world.

You should strive to build a zero blame culture for mistakes on your team. Instead of throwing your teammate under the bus look at why this particular issued happened and what you can do, as a team, to ensure it doesn't happen again. The only real mistake is one you don't learn from. Discuss what can be done better next time. Do you need to add some more tests around this feature? Is there a process change you can implement to better understand the impact a change will have?

You want to build a culture where it is okay to make mistakes, a culture of trial and errors without fear of retribution. An engineer who isn't in fear of his livelihood is going to be more innovative and productive. When they know the rest of the team has their back they will seek out different solutions, be more willing to experiment, and stick around longer.

Stay Disciplined

In hockey a "disciplined" player is a player that has few penalty calls against them. Penalties are measured in minutes, 2 minutes for a minor and 5 minutes for a major. A player with a high penalty minutes stat is considered "undisciplined" and thus harmful to the team.

In software should endeavor to make your team as disciplined as possible. If we consider critical issues, bad deployments, and other such things as "penalties" you should strive to create processes and tools to stop as many of those penalties as possible before they happen.

Unfortunately, there is no one single roadmap to accomplish this. A disciplined team will look different at every company, and even within a single company. There are a few things I think apply universally to a disciplined team however:

A straight forward "definition of done". What does it mean to call a task finished? Is it when the code is deployed? When the PR is merged?
A clear testing strategy and, an automated testing suite. Your team needs confidence that the big refactor they just finished didn't break any existing behavior or, that the new feature actually does what its supposed to.
An honest peer review process. Rubber stamping change requests does nobody any good. The review process is the time to point out any pitfalls the author may have missed. It's also the time to praise the author for their clean or innovative solution!
A battle tested rollback strategy. When things do go wrong (not if, when) the team needs to be able roll back changes easily and quickly to get everything back in working order.

When something does pop up, you want the team to have the comfort in knowing they did everything they could to prevent it and that they have the back up and support of each other. Remember, protect your teammates.

The +/- Stat

Hockey is a chaotic, fast paced game. You've got a bunch of people with knives strapped to their feet slamming into each other at 10 to 20 miles per hour (16 to 32 kilometers per hour). In all this chaos its sometimes hard to know if you're truly having an impact on the teams performance.

Hockey has an interesting stat called the +/- (plus-minus) stat. Its a pretty straight forward way of looking at the impact an individual player has on the team. For every goal scored for their team while that player is on the ice they get a +1. For every goal scored against their team while the player is on the ice they get a -1.

Instead of just tracking how many goals or assists a player has, you can look at their +/- stat and see what actual impact they have for the team overall. Everyone has a role to play and it isn't always scoring goals or making assists.

Unfortunately, we don't have official stat trackers in the engineering world. So it falls to us. Its important to understand your impact on the team at large. Your own personal +/- stat. This helps hold you accountable and helps you see any problem areas you may need to focus on or, may want to ask your teammates for back up with. It also allows you track your wins, the things you've helped with to bring the team to victory. Which can be especially important come annual review time to get that well deserved raise or promotion.

Conclusion

Whether its hockey or software the dynamics of a healthy team have a lot in common. Putting the team above yourself, knowing your role and the teams strengths and weaknesses, building a culture where its okay to make mistakes, and sticking up for your teammates are all building blocks to building a great team culture. A good engineering team will be able to tackle more challenges and be more productive than a dysfunctional one.

But what do you think? Do you play sports? What other lessons have you learned in your professional career from your hobbies and activities?

Parallel Sub-tests in Go: A Cautionary Tale

BlazingBits — Thu, 06 Jun 2024 03:46:29 +0000

By default Go executes tests sequentially, one test after another. In version 1.17 they added the ability to execute tests in parallel with a super easy and simple one line method t.Parallel().

func MyTest(t *testing.T) {
  t.Parallel()
}

Go will execute any tests that call this Parallel method, well, in parallel, by pausing each test and then resuming when all the sequential (tests that do NOT call the t.Parallel() method) have finished execution.

I won't dive too deep into that subject here, Jetbrains has a wonderful article already written you can read here that I used as a reference for this post.

What we're really here to discuss today is how t.Parallel() interacts with sub-tests in go.

But first, What is a sub-test and how do I use it?

A sub-test is a test function inside of a parent test function. You usually find them in situations where there is a common setup requiring a bunch of different conditions to be tested. Its a more readable and cleaner than throwing them all into a single HUGE function.

Below is a bare-bones example of a sequential test with a subtest:

import (
    "fmt"
    "testing"
)

func TestSequential(t *testing.T) {
    fmt.Println("Running main test...")

    t.Run("SubTest", func(t *testing.T) {
        subTest(t)
    })

    fmt.Println("Main test finished!")

}

func subTest(t *testing.T) {
    fmt.Println("Running Subtest!")
}

And here is the output of running that test. It's what you would expect:

Running main test...
Running Subtest!
Main test finished!

"Wow, that seems pretty useful!... wait, didn't you say this was a cautionary tale? What could go wrong with that?" You might be asking yourself.

Just like regular tests, you can also make sub-tests parallel by simply calling the t.Parallel() method! Pretty sweet right?

Well, you'd think so. But be warned. Parallel sub-tests play by their own rules!

Parallel sub-tests execute AFTER its main parent test has finished executing. And, its only after going slightly insane over a bug in one of our tests, that I stumbled upon this nugget of knowledge buried deep in a go dev blog in the Control of Parallelism section.

The below simple test set up demonstrates this issue:

func TestParallelSubTests(t *testing.T) {
    fmt.Println("Starting main test...")
    t.Run("SubTestOne", func(t *testing.T) {
        testOne(t)
    })

    t.Run("SubTestTwo", func(t *testing.T) {
        testTwo(t)
    })

    fmt.Println("Main test done!")
}

func testOne(t *testing.T) {
    t.Parallel()
    fmt.Println("Running testOne!")
}

func testTwo(t *testing.T) {
    t.Parallel()
    fmt.Println("Running testTwo!")
}

Based on our previous sub-test example, what do you think the output will be?

Well, as it happens. It actually executes these two sub-tests, testOne and testTwo AFTER the main test, TestParallelSubTests has already finished its execution.

Don't take my word for it. Here are the logs.

Starting main test...
Main test done!
Running testOne!
Running testTwo!

Things get even more confusing when you throw a defer statement in the mix

I've previously gone over defer statements in go and how they, like these parallel tests, also execute after the containing method has finished its execution. You can read more about that here.

So what happens when you mix the two, parallel sub-tests and defer statements?

They both execute after the main test has finished its execution, but it seems that defer statements will execute BEFORE your sub-tests.

Here is the test setup, it's the same as the previous setup, but with an added defer statement:

func TestParallelSubTests(t *testing.T) {
    fmt.Println("Starting main test...")
    t.Run("SubTestOne", func(t *testing.T) {
        testOne(t)
    })

    t.Run("SubTestTwo", func(t *testing.T) {
        testTwo(t)
    })

    defer deferredPrint()

    fmt.Println("Main test done!")
}

func testOne(t *testing.T) {
    t.Parallel()
    fmt.Println("Running testOne!")
}

func testTwo(t *testing.T) {
    t.Parallel()
    fmt.Println("Running testTwo!")
}

func deferredPrint() {
    fmt.Println("Deferred method!")
}

And here is its resulting output:

Starting main test...
Main test done!
Deferred method!
Running testOne!
Running testTwo!

So dear reader, BEWARE!

The parallel sub-test execution order can cause some serious stress induced headaches if you're unaware. Even more so when you're using it in conjunction with defer statements.

Its especially concerning when you consider that the main use case of these sub-tests is the common setup and teardown of testing data or infrastructure. If you're caught off guard you may be tearing down your test environment before running any tests!

Defer Statements in Go: A Short Crash Course

BlazingBits — Thu, 30 May 2024 20:31:34 +0000

What is the defer statement?

In Go, a defer statement gives you the ability to execute a function AFTER its containing function has finished execution.

The easiest way to think about it is a callback, or a finally block for developers more familiar with Java.

You will commonly see defer statements being used to clean up resources, such as files and database connections.

defer Statement Syntax

func main() {
  myFile, err := os.Open("my-file.txt")
  defer myFile.close()

  if err != nil {
    panic(err)
  }
}

The above is an example of using defer to clean up resources, in this case, closing a file after we are done with it. The defer statement will not execute until after our main method has finished its execution.

Using defer directly after opening a resource that needs to be manually closed or handled (like files!) is a best practice. This way you know for sure there be no left over resources and you won't forget to manually close it later on in the code.

I like to keep such defer statements as close as possible, ideally right under, the line that opens the resources.

Using Multiple Defer statements

defer statements are placed on a stack. Meaning the last defined statement will be the first to be executed. This is something I had to learn the hard way after facing a particularly confusing bug!

Consider the following code:

import "fmt"

func main() {
    defer deferredPrint("0")
    defer deferredPrint("1")
    defer deferredPrint("2")
}

func deferredPrint(s string) {
    fmt.Printf("%s\n", s)
}

What might its output be?

Since defer statements are placed in a call stack (LIFO) the output is the following:

2
1
0

Notice that the last defined defer statement is executed first!

Defer Statements in Go: A Short Crash Course

BlazingBits — Thu, 30 May 2024 20:31:34 +0000

What is the defer statement?

In Go, a defer statement gives you the ability to execute a function AFTER its containing function has finished execution.

The easiest way to think about it is a callback, or a finally block for developers more familiar with Java.

You will commonly see defer statements being used to clean up resources, such as files and database connections.

defer Statement Syntax

func main() {
  myFile, err := os.Open("my-file.txt")
  defer myFile.close()

  if err != nil {
    panic(err)
  }
}

I like to keep such defer statements as close as possible, ideally right under, the line that opens the resources.

Using Multiple Defer statements

defer statements are placed on a stack. Meaning the last defined statement will be the first to be executed. This is something I had to learn the hard way after facing a particularly confusing bug!

Consider the following code:

import "fmt"

func main() {
    defer deferredPrint("0")
    defer deferredPrint("1")
    defer deferredPrint("2")
}

func deferredPrint(s string) {
    fmt.Printf("%s\n", s)
}

What might its output be?

Since defer statements are placed in a call stack (LIFO) the output is the following:

2
1
0

Notice that the last defined defer statement is executed first!

Defer Statements in Go: A Short Crash Course

BlazingBits — Thu, 30 May 2024 20:31:34 +0000

What is the defer statement?

In Go, a defer statement gives you the ability to execute a function AFTER its containing function has finished execution.

The easiest way to think about it is a callback, or a finally block for developers more familiar with Java.

You will commonly see defer statements being used to clean up resources, such as files and database connections.

defer Statement Syntax

func main() {
  myFile, err := os.Open("my-file.txt")
  defer myFile.close()

  if err != nil {
    panic(err)
  }
}

Using defer directly after opening a resource that needs to be manually closed or handled (like files!) is a best practice. This way you know for sure there will be no left over resources and you won't forget to manually close it later on in the code.

I like to keep such defer statements as close as possible, ideally right under, the line that opens the resources.

Using Multiple defer Statements

defer statements are placed on a stack. Meaning the last defined statement will be the first to be executed. This is something I had to learn the hard way after facing a particularly confusing bug!

Consider the following code:

import "fmt"

func main() {
    defer deferredPrint("0")
    defer deferredPrint("1")
    defer deferredPrint("2")
}

func deferredPrint(s string) {
    fmt.Printf("%s\n", s)
}

What might its output be?

Since defer statements are placed in a call stack (LIFO) the output is the following:

2
1
0

Notice that the last defined defer statement is executed first!

Go's list of keywords is surprisingly short

BlazingBits — Mon, 10 Jul 2023 14:10:48 +0000

Every language has a list of reserved keywords you aren't allowed to use, but Go's list is surprisingly short leaving it open to do all kinds of funky things.

Below is a list of all the reserved keywords in Go (as of writing this post):

break
case
chan
const
continue
default
defer
else
fallthrough
for
func
go
goto
if
import
interface
map
package
range
return
select
struct
switch
type
var

( Source )

An Experiment

The keen eyed among you might have noticed that there are two missing values on that list that one might expect to be there.

Notice the words true and false aren't listed as reserved keywords in Go. Does this mean we can reassign the meaning of true and false?

Lets perform a small experiment to find out:

package main

import "fmt"

func main() {
  false := true
  fmt.Printf("In Boolean Logic, is a false statement actually true? %v", false == true)
}

Running this short experiment produces the output:

In Boolean Logic, is a false statement actually true? true

There You Have It

As you can see by our short experiment above, true and false not being reserved by the Go language lets you turn boolean logic upside down. Stop means go. No means Yes. Up means down. Its a quiet a powerful trick to have and I would definitely NOT recommend using this in any real code.

What other words did you notice weren't reserved? Can you think of any other universe altering techniques you could get away with?

Let me know in the comments (: