My experience trying TDD for the first time in Go

Bethany — Thu, 27 May 2021 19:10:44 +0000

Test Driven Development, commonly referred to as TDD, is the development principle that before writing any code, you should have failing test cases. Though it's been around for a while, it's certainly a buzzword in many developer circles along with "pair programming" and "agile". However, I've never met someone who actually practiced TDD. The idea is that by testing first, you can use tests as a benchmark for success while you're writing the actual functionality.

Sometime last week, I took a ticket to add some fairly standard CRUD (create, read, update, and delete) handlers for managing users and thought this was an excellent opportunity to try TDD for the first time.

The first day, I wrote my tests for some GET routes. We use something called go-mock in our unit tests, which allows you to only focus on testing the function you're writing. Because of this, I found that you still needed to have a good idea of the code you want to write while writing out the tests. In our case, we needed to mock out our calls to an external API. If you asked for my opinion after the first day, I would've told you that I could envision the benefits of TDD for something like end to end testing, where it's a black box and you're only verifying that the output is what's expected from a given input. But for unit testing, it wasn't any different than just writing the code first.

The second day, however, made me change my tune.

As I started writing functions that would need to modify what was returned from that external API, I found myself thinking of edge cases that I certainly would not have thought of while writing the code. These would be cases that I would likely catch while writing tests after the fact and would have to rewrite. Or, potentially, I wouldn't even catch them until it was caught in production! I found it not only made me more aware of edge cases but saved time, as well.

I'm not sure how this would work with a more complicated handler that would need to reach out to many more entities. The principle of TDD seems to be that the test is the gold standard for whether your code works, but tests aren't always perfect (at least mine aren't). I'm looking forward to continuing to use TDD in practice and refining my approach to development.

Do you use TDD? How has it helped you in practice? If you don't use TDD, is there a reason?

How Imposter's Syndrome Makes You a Better Developer

Bethany — Tue, 20 Oct 2020 02:48:11 +0000

Oftentimes the feeling of imposter's syndrome is seen as something that should be fixed. While lately more and more people of all skills have come out with their experiences of imposter's syndrome, it still is seen as shameful or a negative. I'm here to offer a slightly different take on it.

Imposter's syndrome is a sign that you're doing something right

Imposter's syndrome often occurs when you are stretching yourself and venturing outside your comfort zone. It is normal to feel more and more like an imposter as you grow in your career. If you let imposter's syndrome own you, then it can be detrimental. There are times where I have missed out on opportunites because I let it convince me I wasn't good enough to take on bigger tasks.

Rely on data, not on feelings

As developers, we tend to be very detail oriented. Imposter's syndrome makes it easy to feel that you're not doing well, but looking at data can keep you rooted. Keep an accomplishments document with all your successes that you can refer to when you feel you're not doing well. Whenever you're struggling with a concept, document it so you know what you should focus on learning. Gather data from others and ask for feedback, from code reviews to general one-on-one's.

Don't feel like you need to know everything

As a developer, your job isn't to know the answer to everything. Your job is to be able to solve problems. Focus on honing in your problem solving skills over specific knowledge, especially if you're a beginner. In-depth knowledge will come over time, but it will stick better if you are actively applying it to a problem. The other day I read an article that discussed "just-in-time" learning to fight the anxiety of needing to know it all. This additionally fights the inevitable burnout that comes with attempting to learn everything too quickly.

Normalize talking about your experience, no matter your experience

This is one that I realized later on in my career. When I was an intern and a young engineer, people would talk about imposter's syndrome, but as something that they had beat or something of their past, not as a constant. I thought that I was behind because I felt like an imposter all the time. Now, when I interact with younger engineers and interns, I make sure to be open that imposter's syndrome is something I continue to grapple with and it is normal and healthy to feel it as they continue to learn. Whether you are new to your field or are someone that newer engineers might look up to, be open and honest about your feelings. Imposter's syndrome is not a weakness, but shows you are growing and embracing being uncomfortable.