I take immense pride in my career and my achievements, but the road has not been easy. Sometimes others wanted me to fail, sometimes I doubted myself, and sometimes I dreamt about packing it all in. But here I am, a decade later… still standing! 💪

When it comes to your career, the race is an ultra-marathon through the desert in cheap shoes, not a nice jog on a manicured lawn. Keeping a sustainable pace is the key to success.

This post is a collection of lessons that I learned the hard way, which helped me stay consistent and show up another day. I hope they will also help you.

💐 Happy International Women’s Day! 💐

You don’t have to be beyond reproach.

When I first started as an engineer, I felt like I could not make any mistakes and my work should be the best I could possibly deliver. “Push yourself, work harder than everyone else, show them that you mean business!” became the mantra that I would repeat to myself every day. Of course, this affected my mental health, pushed me to drink alcohol to cope with anxiety and stopped me from learning. Within the first two years, I was miserable and questioning my career choice.

True equality in tech does not mean that the minorities need to be better than everyone else, but still get paid the same. You are allowed the same grace and understanding as your peers.

• You are allowed to make the same mistakes.
• You are allowed learn at the same pace.
• You should be given as many chances and opportunities.

Your place in tech is just as valid as everyone else’s. You don’t need to outperform to be worthy. Give yourself the space to make mistakes and learn from them, so that you can grow and have a sustainable tech career.

Never make yourself small.

I worked in-office jobs up until the pandemic in 2020. Six years of 2hr travel time each day. Six LONG years of showing up to the office every day and having to sit through in-person meetings. When I attended meetings, I would sit in the back, pull my shoulders forward, and hope that nobody talks to me. Typically, I didn’t speak in these meetings. On the rare occassions that I did, I would state my opinions as questions, hesitantly and unconfidently. I made myself small.

When you feel like you don’t belong, you don’t want to be noticed or singled out. However, people who don’t get noticed also don’t get given interesting opportunities, don’t get promoted and they definitely don’t get raises. Trust me, I know.

It can be helpful to imagine you are playing a part, a work persona. You can imagine who this person is, the kind of questions they ask and how they are perceived by others. Then, use your imagination to apply your mannerisms to your work persona. You are playing the part of a lifetime, so you’ve got to sell it! As you reconcile image of yourself and your work personna, you begin to show up to work in a confident way. The work personna is a crutch you won’t need forever, but it will allow you to let go of your perceived limitations.

As I mentioned in the previous section, you should never question your place in tech. You should be free to ask questions and voice your opinions when you go to meetings as well. Your thoughts are worth just as much as everyone else’s, so don’t hold them back. Getting noticed, demonstrating leadership and confidence, will craft you a sustainable tech career by setting you up for success when the next performance review comes around. 🤞

You are not an impostor.

At the beginning of my career, I was fully convinced that I was the person in the room that knew the least. That was fine because I was going to work extra hard and get better. Being a newly minted junior engineer is extremely liberating. Your job is quite simple: soak up knowledge, deliver work as instructed, and keep improving. This freedom doesn’t last, so make sure you enjoy every minute of it. As you get experience and credibility, the expectations of those around you increase. It was around the four-year experience mark that I first experienced the dreaded impostor syndrome, even though I did not know how to verbalise it.

Impostor syndrome warps all of your experiences, as if through a skewed magnifying glass. All of your achievements are minimised, all of your little failures are catastrophised and everyone around you appears to be effortlessly better than you. As these warped thoughts constantly swirl around in your head, the impostor syndrome is reinforced and the magnifying glass gets stronger.

At my lowest point, I thought I was sure to be let go on the basis of performance. I walked into my performance review expecting the worst. I was absolutely ecstatic when I got a meets expectations! It was then that I realised how warped my thinking had become.

The best weapon you have against impostor syndrome is reality.

• Start to write down every thing you do well and everything you learn, no matter how small.
• Document your wins even when it feels like you have nothing to celebrate.
• As the practice of celebrating your small wins becomes habit, you will see your improvements and begin to advocate for yourself.

In my experience, this process will help dismantle the impostor syndrome that has taken hold of your thinking patterns. You will begin to believe your own track record and improve your self confidence.

Impostor syndrome can cause a lot of people, especially minorities, to feel alienated and eventually leave tech. You can overcome it! Check out this page from the Calm blog for more techniques.

Lift yourself by lifting others.

As I look back at my career, I don’t remember code, tickets or problems. I remember the people I met along the way and the impact we had on each others’ lives. I think that’s really lovely. 🫶

Make it your priority to support others, in little or big ways. Show up for others, be compassionate and build a support network around yourself. Even in a larger city like London, I have found that tech is a quite small community. It’s quite handy to have friends in important rooms. 💪

If you’re not sure where to start, get involved with your local tech communities on meetup or engage online. I’m a firm believer in fostering in-person relationships though, so do try to cultivate a professional network in your area, not rely solely on online connections.

Working in tech can be lonely and difficult due to the complex nature of the work. Fostering connections with others will make you feel like you belong, as well as provide support to those around you. A sustainable tech career isn’t nurtured in isolation and you are not an island. 🏝️ Personal relationships are sometimes even more important than your technical skills.

Parting Thoughts

I can’t believe it’s already been TEN YEARS since I started my career. The last thought I’d like to leave you with is that if I can do it, so can you. It doesn’t matter whether you are trying to get your first job in tech or are looking for a new opportunity following a redundancy, you will find your next opportunity.

We can do hard things and will overcome whatever this ultra-marathon in the desert throws at us. 🏜️

Estimated reading time: 11 mins

Railway is a modern PaaS solution that makes deploying code easier. I’ve had a bit of time to experiment with it and was keen to write up my findings for how it worked with Go projects. In this post, I explore the magic of its deployment mechanisms and demonstrate how to use GitHub Actions to deploy code to Railway. Spoiler alert : I loved learning about Railway and will be building with it more in the future!

What is Railway? 🛤️

Railway is often compared to Heroku because it makes the provisioning of infrastructure and deployment of code much easier than other public cloud providers. This is perfect for me, a backend engineer who wants to build stuff!

Here are some of the key headline features of the platform:

1. Zero configuration builds : the Railway team have started the Nixpacks project. This project builds OCI compliant images based on the source repository. They currently support a variety of popular languages out of the box, including Go ⭐️ of course! For other languages, you can supply your own Docker file and still run on Railway.
2. In-built GitHub support : Railway services can be tied to a GitHub repository. Then, changes committed to configured branches automatically trigger services to be re-deployed. The cherry on top 🍒 is that the Railway CLI also makes it easy to configure GitHub Actions workflows. I will show you how this works later on in this post.
3. Secrets management : once deployed, Railway services are organised into environments, which then belong to projects. You can easily configure project secrets which are shared between different services in the same project. Services can also have their own defined secrets. This approach to secrets management gives you a lot of configuration flexibility.
4. Templates : the Railway team and community have created templates for even easier code deployment. You can create a project from a template, which then creates a public GitHub repo using your GitHub user. This repository is then linked to a Railway service using the previously mentioned GitHub support. At the time of writing, there are templates for the most popular Go web frameworks: fiber, gin, gorilla/mux and chi. The big advantage of using a template is that you will also receive updates when the template itself is updated. Railway also runs an OSS kickback programme which gives back 25% of template usage revenue to the template creators. That’s a great incentive for the Go community to extend Railway support! 🤑

Now that I have covered the fundamentals of Railway, let’s get hands on and see how easy it really is to run on Railway! 🚆

Signing up & setting up 🛠️

As you might imagine, signing up and onboarding are pretty painless. When creating an account, you can choose to sign up via email or using your GitHub account. I would recommend using your GitHub account, as that will also add Railway as a GitHub app, which will make it easier for you to leverage GitHub integrations later on. Once signed up, you will be put on the Trial plan which will give you a free $5 allowance to explore Railway with. Pricing then starts from $5 a month with the Hobby plan.

Once you’re all set up, you can create a new project from your dashboard or through the Railway CLI. Since I’ve never been a fan of ClickOps, I’ll do as much as possible using the CLI, even though the dashboard is easy to use and inspect. The CLI can be installed in a variety of ways depending on your OS. I installed it using homebrew:

$ brew install railway

Once installed, you will need to authenticate your CLI session in your terminal:

$ railway login

This command will authenticate you using the browser, but there is also a -browserless option.

As previously mentioned, Railway organises your work in projects. I must now create a new project which can be the home of my upcoming deployments:

$ railway init
> Project Name Will be randomly generated
Created project sneaky-window on Personal
https://railway.app/project/ee5d0509-b356-4581-a5af-d4dfcce84001

You can provide a name for your project or have a random one generated as above. A URL to inspect your project on the dashboard is also printed out. By the time this blogpost publishes, this project will have already been torn down, but it might be a good idea to keep this key secret!

By default, all projects have a generated production environment. All Railway environments contain the same services, but give you isolated instances that you can experiment on separately. You can create new environments using the Railway dashboard, but can then change between them from the CLI. A really neat feature is that environments can be forked and merged as well. Going forward, I’ll only be working in the default production environment.

That’s all the setup you need for now: you’ve signed up to Railway, set up your CLI for easier management and created a new project that you can deploy your work to. It’s time to get some Go code ready for deployment! 🚀

The Go European Weather checker 🇪🇺

I’ve written a small Go app that displays the weather in the European capitals as part of this Railway experiment. You can see it on GitHub at addetz/go-weather-checker. I have written this app from scratch, but I could have used one of the Railway Go templates as the starting point.

This little application uses the following technologies:

• labstack/echo is my chosen web framework. I’ve recently started using this framework and I really like how easy it is to configure routes, as well as construct JSON responses.
• GopherJS compiles Go code to JavaScript. I built a very small frontend to make the demo more visually appealing. This library allowed me to build the entire demo in Go, except for some simple HTML. The frontend is styled with bootstrap.
• OpenWeatherMap is the third-party service that I use to fetch weather data. This service provides you with 1000 free API calls per day. As part of sign up, you will be issued with an API key that you can use for querying.

The application is configured with 2 environment variables: the OpenWeatherMap API key mentioned above is mandatory and the port is optional, with a default value of 8080.

$ export WEATHER_API_KEY=XXX
$ export PORT=XXX

After setting our variables, the server runs like any old server:

$ go run server.go

Once the server starts up, you can navigate to it in the browser at localhost:8080 or whatever port you have configured. Now you can see what the weather is in any European capital! 😎

Deploying to Railway 🚆

As mentioned above, the source for my app is at addetz/go-weather-checker. The repo does not have a Dockerfile, but it does contain a go.mod file which will signal to Nixpacks that this is a Go application.

Back in my terminal, I link the repo root directory of the weather app with the previously created sneaky-window project and its default created production environment:

$ railway link
> Select a project sneaky-window
> Select an environment production

Linking my CLI session to this project allows me to run all future commands against this project and environment. I can then easily deploy the weather app using the up command:

$ railway up

At this point, Nixpacks will build and publish an image for my app and Railway will attempt to start a service running its built image. However, this service will immediately crash because I have not set up any secrets for my application. The deploy logs simply print the following and the application exits. 😱

2023/08/24 14:22:33 WEATHER_API_KEY must be set

At the time of writing, the Railway team are rethinking the secrets workflow within the CLI, so I am not be able to add the mandatory secret from the terminal. Instead, I add it as a shared variable to the project by navigating to the Railway dashboard and adding it to the project settings, then sharing it with the newly created weather service.

Once this variable is shared, the service will be successfully redeployed:

The running deployment shows us two things:

• Railway is able to detect that I am attempting to expose a webserver.
• The app is now listening on port :5784, even though this has not been configured at all.

How on earth is this all happening? 🧐

The secret lies in the magic 🪄 of Railway, of course… and the PORT environment variable. In order to expose web apps, Railway needs an IP and port. The IP is provided through configured domains, while the port is configured through a Railway provided PORT environment variable. If any apps you write are configured to use this variable, they will be able to expose endpoints to the internet without any further configuration.

There are 2 options for domain configuration: generate one or add a custom domain from the service settings. In this instance, I have generated a domain and my app will be exposed at https://sneaky-window-production.up.railway.app/. One really neat thing to notice is that Railway has also secured all traffic to my application with HTTPS without me having to configure anything in my app or create certificates. Nixpacks took care of that. 🤩

The cherry on top 🍒: GitHub Actions

As a final step, let’s talk about CI/CD with GitHub Actions. Workflow configuration and management have now become synonymous with GitHub Actions, so of course it makes sense that Railway supports this!

Railway allows the creation of project tokens in order to authenticate from remotes where even browserless login is not possible. You can create a new token from the Tokens tab of your project settings. This token will give you programmatic access to the project.

On the GitHub side, I add this token as a secret to the weather app repository addetz/go-weather-checker by navigating to Settings -> Secrets and Variables -> Actions. I will name this token RAILWAY_TOKEN as advised. I have also added a further secret called RAILWAY_SERVICE, which will allow me to instruct which service to deploy this repository to.

You are now ready to run GitHub Actions with Railway! A simple workflow which builds our app, runs our tests and then deploys the code using Railway can be seen below:

name: Deploy to Railway

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Setup Go
        uses: actions/setup-go@v4
        with:
          go-version: '1.21.x'
    
      - name: Install dependencies
        run: go get ./...

      - name: Build
        run: go build -v ./...

      - name: Test with the Go CLI
        run: go test ./... -v

      - name: Deploy Railway
        uses: bervProject/railway-deploy@main
        with:
          railway_token:  ${{ secrets.RAILWAY_TOKEN }} 
          service:  ${{ secrets.RAILWAY_SERVICE }} 

I deploy to Railway using an existing railway-deploy GitHub Action, which wraps around the installation aspects of the CLI. I make use of the configured repository variables to pass the token and the deployment service.

That’s all you need to seamlessly deploy your application to Railway with GitHub Actions. One aspect I have not covered is the ability to specify a GitHub repository as the service source, which will allow Railway to monitor the repository for changes on a configured branch, typically main, and then redeploy when new commits are made. You can read more about service sources and triggers on the Railway docs. I prefer to have control of deployments using GitHub Actions.

Parting words

This brings me to the end of my exploration with Railway! It’s been so interesting to learn about this great platform. There is a lot here that can make our lives easier and help us ship projects faster, so I hope this post will inspire you to explore Railway on your own as well.

I’ll be following up with a post on how databases & storage work in Railway, so stay tuned for that. And who knows… I might put forward an echo Railway template as well! 🤩

Happy coding, Gophers!❤️

Estimated reading time: 8 mins

I recently had the pleasure of discussing and demonstrating some of the key concepts of my “Test-Driven Development in Go” book on a live stream. This post summarises the main points covered by this 1hr coding session. Understanding these testing essentials will go a long way to helping you become a TDD practitioner.

Read on to see why you should care about testing and TDD!

Key principles

I was keen to explore the topic of TDD in Go because it was one of the parts of the language that I had a hard time understanding, despite its simplicity. There were only a few functions available in Go’s testing package, but I was unsure how to use them and it seemed difficult to build any test setup. Figuring out the testing process in Go took some time, especially as most tutorials are aimed at learning language basics, not test basics. I was keen to dedicate time share my knowledge, discover new concepts myself and write a thorough guide to writing testable code with TDD as the working process. This is why I took on the project of writing a book dedicated to testing techniques and the application of TDD.

The book is structured around the following four basic principles:

• Writing testable code starts with a thorough understanding of the language you are writing in: we need to understand the main structure and concepts of Go in order to be able to write testable code. We need to have a clear understating of concepts such as package structure, dependency injection, concurrency and more.
• TDD is hard because it is difficult to have a clear vision of what we are trying to achieve when problems are ambiguous: writing tests is easy in Go, as we use the same techniques as writing source code. Instead, the unclear understanding of the work we are trying to achieve and an over fixation on technical solutions is what makes it difficult to practice TDD.
• Engineers should take ownership of testing their product at all levels, not just unit: testing blogs & demos often focus on unit testing only. While this makes it easy for developers to write tests with small scope, engineers should take ownership of testing at all levels. This has the benefit of giving us a thorough understanding of how users will be ultimately interacting with our product, but also give us ownership of our product in a true DevOps way.
• Practicing TDD can help you organise your work and stay focused on solutions to user-problems: the TDD process involves writing tests alongside the source code. This encourages us to make conscious decisions for code structure that is focused on requirements and inputs, as opposed to get overly attached to technical solutions.

Tests are typically organised in the testing pyramid:

1. At the bottom of the pyramid, we have unit tests, which only test a single, isolated behaviour or piece of functionality. They are the fastest and most numerous.
2. In the middle, we have integration tests, which test the behaviour of multiple components together. They are complementary to unit tests, as they ensure that multiple units work well together not just individually.
3. At the top of the pyramid, we have end-to-end tests, which test the entire application. They are typically focused on validating the application exposes the correct user-facing functionality.

The method

The Red-Green-Refactor method is the working process for TDD. It the three steps described in the figure below. In the beginning, it might be cumbersome to swap between source code and test code, but it will quickly become second nature. The three steps of the method are:

1. The Red phase: based on provided requirements, we begin by writing a test with specified inputs and expected outputs. We run this test to ensure it is failing. This helps us avoid any false positives later on.
2. The Green phase: swapping over to source code, we write enough code to satisfy the previously written test and implement the functionality required. We re-run this test to ensure that it is now passing.
3. The Refactor phase: while the test and implementation are successfully fulfilling the requirement we have been focusing on, we can take the time to make any improvements to it in the refactor phase.
4. The process repeats until we have successfully implemented all functionality that the unit requires.

Tests should focus on testing outputs, not implementation. If tests are tightly coupled implementation concerns,they can become brittle when code is changed or refactored. Tests should be made as resilient to change as possible.

Unit testing essentials

Now that the process and main mechanisms are established, we can start to look at how to implement our first test. We begin at the bottom of the testing pyramid with unit tests.

Go functions, structs, variables and interfaces are organised in Go packages. Their visibility is restricted to the package unless exported with a capital letter. Directories can generally only contain a single package with some exceptions. One of these exceptions are testing packages. These packages end with the _test suffix and must match the name of the source package that is also defined in the same directory. These packages behave like any other external package, only having access to the exported names of the source package.

This is a very powerful mechanism. The usage of a test package ensures that we only test the externally visible functionality of the package, making our tests the first consumers of the package we are creating. We can then clearly identify what parts of exposed functionality need to be rewritten or clarified.

In Go, tests are just regular functions which comply to some restrictions:

func TestName(t *testing.T) {
  // implementation
}

• Test names start with the Test prefix followed by the test name in camel case.
• Test functions take a single parameter of type *testing.T.
• Tests live in _test.go files.

The testing package exposes methods logging and failing tests. The t.Error method fails a test but continues running the test suite, while the t.Fatal method fails the test and stops the execution of the entire test suite. The t.Errorf and t.Fatalf method counterparts which allow us to pass messages for formatting.

I demonstrate the Red-Green-Refactor method with a simple example and unit tests in the live stream from timestamp 09:10.

Integration testing

Unit tests do not have sufficient scope to ensure that functional requirements are successfully delivered. Often times, their implementation requires the usage of multiple units or components working together, delivering their specialised functionality in order to build the solution. In these cases, integration tests are often times a useful way to extend scope:

• Integration tests cover one or multiple components, ensuring that the individual components work well as a combined entity. In the microservices world, the different components might even be delivered by different teams. The integrations between these separate units are often the cause of errors or outages.
• While the logic of the particular component is verified by its unit tests, the purpose of the integration test is to exercise the conditions at the seams between the components.
• Integration tests have the advantage of allowing us to test bigger scope, without the complexity of having to run an entire application. As they are in the middle of the pyramid, they don’t require the entire application to be ready for running and testing.

The code required for implementing integration tests isn’t any different from unit tests. I demonstrate writing integration tests using httptest in the live stream from timestamp 44:38.

End-to-end testing

This stream did not cover end-to-end testing. I may dedicate a future blogpost to this topic, but in the meantime, I recommend that you explore BDD testing with godog and contract testing with pact.

Parting words

Let me just get this working and then I’ll see how to test it.

Often times, we feel like testing code is of lower importance than source/implementation code. This way of thinking results in complex, unmaintainable code that is riddled with bugs. Spending time unpicking complex code structure for later testing takes longer than incrementally making decisions, ensuring they are easy to test and implement solutions to provided requirements.

Therefore, I encourage everyone to take the time to improve and hone their testing practices. You won’t be disappointed with the results.

Happy coding, Gophers!❤️

Resources

Here are the links mentioned in the stream:

• My “Test-Driven Development in Go” book
• The slides presented in this session
• The repository with the demo code

Estimated reading time: 6 mins

In this post, I share some of my key thoughts from my LinkedIn Learning Future of Code Week episode discussing emerging languages. This session takes place on November 17th 2022. I was thrilled to be invited to share my thoughts with Marcus and Ray.

Make sure to sign up to the event on LinkedIn!

Session summary

Emerging languages often try to change how developers solve problems, but they also often change the course of legacy languages. Programming languages like Go and Rust are not just inventing new ways to work with code, but also having a clear effect on new versions of existing languages. Will the new take over the old? Will the adjustments to existing programming languages be enough to stave innovation? Or, is it best at some point to start from scratch and rethink the foundation of how we approach programming?

What Go does well

Go has been hailed as a language that is easy to use and deploy. There are a few reasons that should be top of mind when discussing this:

• Small syntax - Go’s syntax has been made small by design, so that it’s easy to pick up and become productive with. One of the purposes of the Go project was to simplify the act of programming and make it easier for developers to write statically typed code.
• Static typing - Go code is strongly, statically typed and compiled. The compiler catches a variety of bugs and allows for certain compile time performance optimizations. Go has built-in types for slices & maps which are easy to use.
• Structs - Go isn’t technically an object oriented language, but custom types are created using the struct keyword. Structs can have methods attached to them in the same way objects do. They have been described as lightweight objects since they do not support type inheritance.
• Interfaces - While Go doesn’t support type hierarchy, interface types create reusable behaviours in a versatile and robust way according to the principle of composition over inheritance. Interfaces are implicitly implemented on structs by the Go compiler. A struct can implement several interfaces just as long as it implements all the methods that they require. A common use case of interfaces is to wrap code coming from an external library into an interface on the side of the calling code and only expose a subset of external functionality in the internal codebase.interface{} is known as the empty interface. It is satisfied by all types and is used as a parameter type by code that handles values of unknown type.
• Building and testing Go code - The go command exposes functionality for building & testing Go code. This is easy to use and comes with the default Go installation. The source code is built into a binary executable. Executables can be built for other targets/architectures using cross compilation.
• Deploying Go code - The binary executable of Go source code contains not just application code, but also all the support code needed to execute the binary. This means that the Go executable can run without the need for system dependencies such as Go tooling to run on a new system, unlike other languages. Go executables can be directly deployed.
• Generics - recently added to Go, generics allows us to write better libraries that and data structures. From my experience, adoption of generics in production has been cautious. The Go team have put together talks and posts which discuss when not to use generics, as they are not a silver bullet to better code.

Performance & Concurrency

Go is a fast and performant language due to some very important optimizations:

• Inlining - the Go compiler saves function calls by treating the body of a function as if it were part of the calling function. This has the trade off of increasing binary size, so Go only does so when it makes sense.
• Escape analysis - Go implements this optimization which analyzes the scope of references to a value. If the references do not escape scope then they are saved on the stack which is much faster and does not need to be garbage collected.
• Garbage collection - prevents memory leaks and has very low latency. The Go garbage collector is an intricate piece of code that you can check out on the Go Blog.
• Concurrency - Goroutines are multiplexed to a small number of OS threads. They are described as lightweight threads with small stack sizes that are cooperatively scheduled and managed by the Go runtime. Goroutines yield control at natural stopping points, making them more performant than kernel managed threads.

One of the big advantages of using Go is the easier and more intuitive model of concurrency that is central to the language:

• Goroutines - Functions/methods can be run concurrently to other functions/methods by starting a Goroutine using the go keyword. They allow our application to use its resources optimally and perform more than one piece of work. All of the complex management and scheduling of goroutines is abstracted from the developer. Built on the concept of coroutines that is also used in Kotlin.
• Channels - Goroutines communicate through channels, which can be thought of as pipes through which data flows. Channels avoid data races by design as they maintain queues of goroutines and data themselves.The solid basics of Goroutines and channels can be combined to form a variety of basic and advanced concurrency patterns. Two notable concurrency patterns are pipelines and worker pools.

The future of Go

In my opinion, the future of Go is bright ☀️:

• Replacing legacy services - due to its superior performance, engineering teams will continue to decompose monoliths and write new services in Go. In an increasing amount of companies, Go and microservices go together hand in hand. This de-facto choice is because Go’s net/http package makes writing REST APIs easy.
• Increased demand - Go has recently “become a teenager” with its 13th birthday. It usage has been increasing and I would argue that it is moving away from emerging language status, as it has become adopted by major tech companies for mission critical jobs. You can see the full list of case studies on the Go blog.
• Compatibility promise - Russ Cox gave a talk at GopherCon 2022 about Go’s compatibility promise, which I really recommend. When updating to a new version of Go, you must compile your code again, but the team ensure that new versions do not break existing code. These guarantees make Go suited for writing Go code for the long term.

"Go is boring, and that's good!" - Russ Cox

Parting words

Obviously, I’m a huge Go lover ❤️ and I believe that the language is here to stay. It’s got so many cool features the Go team do a great job to improve tooling and add new features. An often underrated aspect is community. I’m proud to be part of the Go community, which is inclusive and welcoming. I think Gophers worldwide will continue to advocate for the language and grow.

Join the Gophers Slack.

Estimated reading time: 5 mins

In this post, I share some of my tech story as part of the Dev.to SheCoded campaign, organised on the occasion of International Women’s Day 2022. I won’t be using names of individuals or companies in this retelling, but if you recognise yourself in the narrative, don’t reach out to me with an explanation or justification. Just DO BETTER THAN YOU’VE BEEN DOING!

So, let’s begin.

Going to university

Being a woman does sometimes feels like drawing the short straw. Being an Eastern European woman on this wonderful continent 🇪🇺 sometimes feels like getting that already short straw broken in half. I am proud to be Romanian 🇷🇴 and I lived most of my life abroad, over two decades now. My family and I have lived through many prejudices for our accent, hair colour and “funny ways”.

Throughout my entire life, I have had the good fortune of having the support of my mother, father and older brother. They have been my compass, my strength and my unwavering supporters. ❤️

When I was 18, under the guidance of my family, I enrolled into the IT Engineering programme at the Technical University of Denmark in 2007. Yes, I did choose it because we thought it would be a lucrative career. When you are trying to make it in one of the most expensive places in Europe, you don’t have the luxury of discovering what your passion or dream job is.

My university “friends”

I arrived at university wide eyed and excited. The first two years were absolutely brutal - writing code didn’t come naturally to me, the subject matter was terse and I had to put in a lot of hours of studying. However, my dilligence did eventually pay off and I started getting high marks.

My university colleagues and “friends” made many sexist and callous remarks. One person flat out accused me of sleeping with the 60 year old male professor, another accused me of getting the grade because of the outfit I wore. Finally, when we were assigned a female professor, I was accused of getting the grade because we were both women.

Some of my professors weren’t exactly stellar either. One of them told me that if I wore red nail polish again he would flunk me as he found it too “aggressive”… and while I was at it I should get rid of the makeup too!

All of this had long term repercussions on me in the form of feeling out of place and like an impostor for much of my career. I have no doubt I would have quit if I hadn’t had my family in my corner, but I graduated with a high GPA and held my head high when I received my diploma. 🎓

I wish I would have stood my ground when I was treated poorly, but most importantly, I wish the few people I was close to had stood up for me. I remember the silent faces alongside those who accused me in front of everyone. Don’t be a silent face in someone’s forever memory.

We must learn to be better allies for women in tech!

The missing female mentor

After I finished my studies, I moved to London 🇬🇧 in 2014. I was fortunate to work with some great managers and engineers in my early career. They taught me technical fundamentals, supported me and helped me improve my self esteem.

After some time, I was excited to work for my first female manager. She ended up being really tough: she told me off for “being mousy and batting your eyelashes”, she forced us to deliver subpar work for tight deadlines and she would take out her bad days on the team. I have since worked with many accomplished, truly amazing women. 🤩

We often hold other women to the same prejudices that we have been held to our entire lives. I strive to be the female mentor I wasn’t able to find earlier in my career - to my friends, colleagues and anyone who reaches out to me.

As women in tech, we must be better role models and mentors for each other!

Don’t say the M word

Early in my career, I was often told what the maternity benefits packages were. They were probably trying to bolster my perception of the benefits package. I dismissed them with the wave of a hand. What’s this information to me? I’m young.

As I approached my 30’s, I did become aware of my biological clock. The recruiters stopped mentioning their maternity packages. I became keenly aware that if I say the M word, maternity, it would be potentially offputting to prospective employers. So, I stayed silent and signed contracts without asking.

The UK has absolutely horrible maternity leave, compared to many European countries. The law does not protect women’s income during maternity, so the private employer packages vary a lot here.

I will speak out and ask about maternity packages in the future. We have to get rid of the stigma of women in their 30s asking for their rights to decent maternity protections.

We need to support diversity in tech with generous maternity AND paternity packages!

Parting words

Thanks for reading all about my tech story and thoughts! It means a lot to me that you cared enough to read it. ⭐️ All in all, I feel optimistic for the future. I do believe that things are improving, even though we are far from true gender equality. I will strive to be a positive force of change in tech.

I will leave you with some family wisdom (I’m actually not sure if this is Romanian expression, or if it’s just a thing my mother says 🙈). Whenever I was sad or felt things were not going my way, my mother would say “the horses don’t die when the dogs wish them to” (nu mor caii cand vor câinii).

The meaning of it is related to hunting. The horses and dogs take off in the hunting party. Obviously, horses have much more stamina than dogs. Naturally, the dogs tire first and exhaustedly wish the horses the worst, but they just keep running. 🐎 I suppose this is a roundabout way of saying haters gonna hate 😆, but I like thinking of horses instead. 🐴

Remember, you’re a majestic horse and you leave us all in your dust!

Estimated reading time: 3 mins

In this post, I share what I learned about interviewing for a DevRel role, as I think there are a lot of folks who think they can’t achieve this role. This short list of Dos and Don’ts are really simple and easy to address. Make sure you follow them so you don’t lose out on any great DevRel opportunities.

Let’s make the most of those interviews!

Interview tips

1. You DON’T need to have a massive social media following to get your first DevRel role, but you DO need to have a Twitter, GitHub and LinkedIn profiles with some relevant posts on them.
   • As part of their initial screening, your future employer will look up your social media profile to see how you engage with the Tech community.
   • Eddie Jaoude often explains on Twitter how to engage with others in a constructive and friendly way.
2. You DON’T need to have a huge portfolio of talks, but you DO need to have some current examples of material you could produce.
   • Start a blog or write on dev.to or Medium to produce some writing samples. Personally, I prefer dev.to between the two as the text editing is in markdown.
   • If you do manage to speak at a conference, then you can use this as a video sample content. Otherwise, try to record a short tutorial or similar and upload to Youtube.
   • I made this blog using Jekyll and Github Pages, but if I were to start over I’d probably opt for dev.to.
   • In my experience in interview process, everyone looked at my blog and read some writing samples, including the CTO, when I got to the final round.
3. DO write a bespoke resume that highlights your DevRel adjacent experience.
   • Engineers are often used to just sending round the same resume to all their roles, as it doesn’t really play that much of a role when getting selected for interviews. This is not the best tactic if looking to get your first DevRel role.
   • I wrote up a special resume that highlighted my relevant experience more than just the technologies I worked with. You should include: your talk samples, your blog, any event organising experience (such as hackathons or other events) and any open source contributions you might have.
   • This will help your future employer see your DevRel potential, even if you might not have full time DevRel experience.
4. DON’T underestimate the power of the cover letter.
   • Engineers are not used to writing cover letters, but I think they are a great opportunity to showcase your writing skills when applying for a DevRel role.
   • I wrote a 1 page cover letter, where I explained why I wanted to be considered for the role. This gave me the option to explain my resume a bit more and offered some background about why I was interested in working at the company I was applying to. Again, everyone read this letter throughout the interview process.
5. DO research the company you are applying to more than you might do for an engineering role.
   • Most DevRel roles, including the ones where you will be joining an established DevRel team, require you to be a self starter with ideas.
   • Make sure you research the company you are applying to and come up with some concrete ideas of how you can contribute to their program.
   • I made some boards with screenshots from the company website where I jotted some ideas. In the end, I ended up sharing my boards during the interview. As I was quite nervous, my preparation helped me anchor myself and present my ideas.

Parting words

It might be intimidating to move into a new role, such as DevRel, but don’t underestimate what you can bring to the table!
The field of DevRel is still growing and getting more established, so there is definitely place for you to get started in it.

I’m happy to help with resume and cover letter reviews, so please don’t hesitate to reach out to me on Twitter if you need a second pair of eyes on these.

Happy interviewing & job hunting!

Estimated reading time: 5 mins

As 2021 comes to an end today, it’s important to take time to celebrate our wins and achievements throughout the year. I’m going to show you some of my nail designs that I’m most proud of.

You might wonder why bother putting effort into nails? They chip, break and they’re just nails. My answer is that I look at my hands all the live long day, so I want to look at a well presented manicure.

After all, isn’t it human nature to love things that aren’t fated to last? Youth, beauty, flowers… NFTs and Web3 😆 Also, it’s my blog and I’ll put nails on it if I want to 💅

NOTE: Due to the many dangers of improper gel use, all my nail art is done with regular, wet polish on top of my natural nails. The techniques I describe here apply to this type of polish.

Let me take you on my epic journey in nail art!

My first set 1️⃣

My very first set was an absolute disaster. I had one single brush that my partner had given me and I very shakily drew on these uneven lines. Absolute horror show! 😱

Even though this set is quite bad, I did get my essentials right. I applied a nourishing base coat, two coats of base colour, the “nail art” and then sealed everything with topcoat. These steps are very important to a long lasting manicure.

I’m including this set so you can get an idea of how badly things can go. Also, in true Dunning-Kruger fashion, I actually thought they were not that bad.

The discovery of striping tape 💡

After seeing how tough it is to draw straight even lines with your left hand on your right hand and YOLO’ing my first set, I looked up how lines are actually drawn. I discovered that colours are layered together and crisp lines are produced using striping tape - which is basically a very thin adhesive masking tape. It’s available all over the Internet.

Striping tape should only be applied on fully dry, top-coated nails! See this excellent video if you want to learn how to use striping tape correctly.

The power of the liner brush ⌇

While glitter polish is very forgiving to uneven applications, the liner brush has a long head that allows you to evenly load it and draw long lines. This is my liner brush, but there are many others.

The liner brush is the hero 🦸🏻‍♀️ of evenly coloured lines, from beginning to end. The set below is made with a combination of striping tape and liner brush.

Cheating a steady hand with tip guides ✍️

Even with the miracle liner brush, I found it really difficult to apply long even lines on myself. You can buy tip guides online to help you achieve the correct shape. As with striping tape, remember to apply them only on top of fully dry, top-coated nails otherwise the polish will rip off.

I really like this set, but I must admit it took me over 3 hours to do 🙈 It was really time consuming to pain stakingly align the chevron guides to match, so tip guides are kind of a pain.

How long can I go? 🤷‍♀️

This was the longest set of nails I had and they are absolutely fabolous!💯

They also demonstrate the almond nail shape, which comes naturally to my very curved nails. There are 7 nail shapes, but I find the almond the easiest to shape on my nails with a nail file.

Nail health is very important if you want to go long. You should focus on you supplements(B12 and Biotin in particular), as well as get into the habit of applying cuticle oil, which moisturizes and strengthens nails, if you want to grow naturally long nails. This is my cuticle oil, but there are many others online.

The drama of a good ombre 🎭

I’ve never been a girl for understated nails, so I absolutely love a dramactic good ombre.❤️

The process is a bit messy and time consuming on wet polish - you apply the polish to a makeup sponge and then layer it on your nails. You can see this excellent tutorial if you’d like to make your own ombre. I highly recommend using a liquid cuticle guard (or at least sticky tape!) as the polish will go all over your hands and it will be a nightmare to clean up.

Delicate art with water decals 🌊

My dear friend Alicia ❤️ gifted me some amazing water decals that can be used on nails. They are super cool and easy to use - you submerge the decal and the paper it’s attached to in water for 10 seconds and then you can delicately slide it off the paper and onto your nails.

Decals are really cheap and available all over the internet. They are a wonderful addition to a delicate manicure. You can see this excellent video if you want to see how to use them.

Water decals should only be topcoated once they are fully dry! Otherwise, the topcoat will not seal properly and they will pop off.

Finally… gold flakes for the New Year! ⭐️

Thanks for taking this journey in nail art with me! 🥳

It was really fun for me to share some of my favourite nails throughout the year. My sets last between 10 and 14 days so I did many more sets than those I’ve shared with you here. 🙈

My current set is a festive gold flakes set to welcome 2022! 🍾

Parting words

I’ve learned a lot about this awesome new hobby this year. I’m always happy to exchange tips and tricks with anyone who wants to take it up, so don’t hesitate to DM me on Twitter.

A great place for nail art and ideas is r/lacqueristas, where I sometimes post my sets.

May 2022 bring you all strong nails and no chipped nail polish! ❤️ ❤️ ❤️

Estimated reading time: 1 min

I’m super excited to share that I will be starting a new role as a Technology Evangelist at Form3 starting Monday, September 6th! It’s such a dream come true to have this opportunity to pursue my passion and step into Developer Relations. In this post, I will share what this new move means to me.

Wait, what is a Technology Evangelist? 🙈

Evangelists are sometimes also known as Technology Ambassadors. In short, this role is all about representing a company and presenting its technical solutions to a variety of stakeholders.

The definition of this role varies, but to me, the technology evangelist role comprises of the following:

• Working on internal and external technical documentation
• Helping produce marketing material which correctly represents the technology of their employer
• Speaking at conferences and blogging to promote their employer’s brand
• Helping with open source efforts to contribute to the tech community

The only way is up! 🚀

It’s been really nerve wracking making the decision to step away from my Back End role. In the end, it all came down to passion and the good fortune of finding an employer that wanted to invest in me. This encouraged me to take the leap! 🥳

For now, I am just super excited to have the opportunity to explore this role, speak at more conferences and really see what the developer relations life is all about. 🎤

Developer Relations roles and team are fluid and change from company to company and even over time. With this in mind, I think I’ll see the role very differently 6 months, a year from now. I just wanted to jot my thoughts down before starting this new, exciting journey.

Cross your fingers for me as I take on this new challenge!🤞

Estimated reading time: 5 mins

My talk for GopherconEU 2021 is live on Youtube! Preparing for this conference has been such a wonderful learning experience. In this blog post, I will share some of my lessons learned about pitching, preparing and delivering my conference talk. I hope this will break down the process and encourage other newbie speakers to take on this journey.

Let’s get excited about public speaking!

The Pitch

Your pitch is your first and only chance to impress the conference organizers and convince them to choose your talk for their event. While some established conference speakers are invited to speak without pitching, most conferences will open a Call for Papers where anyone can pitch a talk. To keep things fair, organizers will then choose pitches from their Call for Papers without seeing the name and profile of the author.

The skeleton/structure I use for my pitches is:

# Talk title
Insert your persuasive elevator pitch here
- Choose a fun, but descriptive title for your talk
- Include any technologies you intend to showcase
- Describe the format of your talk ie live coding, demo app etc.

## Overview
Insert longer description of your talk here: 
- Who is your intended audience? 
- Why is it worth learning about your chosen topic? 
- What is the angle you'll take on your topic? 

## Structure
Divide your talk into 3-4 rough sections
Describe each section in detail: 
- What will you be introducing in this section? 
- What will the audience take away from this section? 
- How does it cohesively hang together with the previous/next section?
- Include any rough points you intend to highlight

## Conclusions
Write a small paragraph describing exactly what we will learn from you
Keep the tone of this paragraph upbeat, encouraging people to attend your talk

You can see the entire pitch for my talk on PaperCall.io.

The Preparation

Okay, you’ve been selected to speak! Fantastic. Now it’s time to start preparing in good time to make sure that you are doing justice to yourself and your pitch.

Here are some helpful tips I’ve used during my conference preparation:

• Consider inviting a colleague to be your co-presenter: I really enjoy presenting as a duo since it allows me to incorporate fun exchanges with my colleague in front of the audience. This makes my talk more conversational and dynamic
• Set deadlines for yourself: starting with the conference date, work backwards to set yourself deadlines. I recommend finishing your slides about a month before the conference and using the last month for rehearsing and polishing the content. You can still make changes in this last month, but aim for a complete first version about a month ahead of the conference date
• Keep track of your work: treat your conference prep like any project and track your progress. Use any tool you like Trello, Miro, Jira, paper Post-Its, but make sure you keep track of your progress and any remaining tasks
• Regularly check in with your colleagues: if you’ve opted to present alone, try to run your existing work by your colleagues as you create it. This will help you get ideas during the process but also keep you on track
• Tell a coherent story: make sure that you ease into the more complicated/terse parts of your technical topic to ensure that members of the audience from different backgrounds can follow you. Make sure the sections of your presentation flow together and tell a coherent story
• Don’t underestimate the work: the rule of thumb for talks is that you should set aside 1 hour of preparation time for every 1 minute of finished talk ie. 30 hours of prep corresponds to 30 minutes of finished talk. If you are building a demo application, this will add even more preparation time

The Delivery

As the talk approaches, it’s time to take this show on the road!!!

Here are some helpful tips I’ve used for my rehearsals:

• Rehearse by yourself: you should rehearse your talk end-to-end alone first. You might be tempted to stop if it doesn’t go well, but do a rough full run through first. This will give you an idea if you have too much or too little material to make sure you land the expected time length
• Rehearse to your colleagues: after you have a good idea of roughly how long your talk will take, you can now ask some of your colleagues to listen to your talk. Aim for 2-3 dress rehearsals with your colleagues to make sure you have a good rhythm when the big day comes
• Keep it conversational: conference talks shouldn’t be long, boring lectures. Make sure to keep your presentation style conversational and your language approachable. Plan what you’re going to say, but don’t be overly rehearsed
• Always leave time for questions: time your talk to leave time for at least a few questions. While people in the audience can always come and discuss with you during breaks and socials, it is nice to discuss ideas with the audience as a whole, even if it is for a few minutes

Parting words

As I’ve discussed in this blog post, pitching and preparing a conference talk is a large undertaking and requires quite a bit of work.

But it’s not all doom and gloom!

Sharing your unique technical expertise and point of view with the community is a very rewarding experience. Preparing the talk teaches you lots of details about your chosen topic and public speaking itself is a great opportunity to challenge yourself in a whole new way. So if you’re curious about the experience, get pitching and just give it a go. I’m sure you won’t regret it.

Happy conference speaking! Go be the star you are!

Estimated reading time: 6 mins

Unit testing is paramount to writing stable, production ready code. In this post, we will talk a bit about what unit tests should cover and table driven tests in Go.

Let’s make Go tests our best friends!

Basics

For the sake of this testing discussion, let’s say we have created a new Calculator that prints out formatted results and we want to ensure that it is working as expected.

type Calculator struct{}

func (c Calculator) Add(x, y int) string {
	if y > 0 {
		return fmt.Sprintf("%d+%d=%d", x, y, x+y)
	}

	return fmt.Sprintf("%d%d=%d", x, y, x+y)
}

Go provides inbuilt support for testing using by using the testing package. A test is created by writing a function with a name beginning with Test and being followed by the name of the method under test. The test signature takes exactly one parameter from the testing package as seen below.

func TestAdd(t *testing.T)

The parameter t that is provided in the function signature is used to signal errors to the test runner by using Fail and Errorf. One simple test for our Add function can be:

func TestAdd(t *testing.T) {
    want := "2+3=5"
    c := Calculator()
    got := c.Add(2,3)
    if got != want {
        t.Errorf("Add(2,3) = %s; want %s", got, want)
    }
}

The unit under test

Unit testing aims to test individual units or components of a piece of software. The purpose is to validate that each unit of the code performs as expected. In other words, unit tests are for verifying independent behaviours that we want to expose to outside of the component under test. Functions and structs are exported from Go packages so unit tests should verify the functionality that your packages expose.

In Go, tests live together with the source code in files that match the name of the source code file and ending in _test. While not enforced, Go also encourages tests to live in a separate _test package which has the dual purpose of making sure test functions do not leak into source code as well ensuring that only exported functions/behaviours are available in the test code. (Note: Go does not allow multiple packages to live in the same directory, but _test packages are exempt from this rule.)

The eagle eyed readers might have noticed that the packages in the Calculator example conveniently left out package names. We can now revisit this example and include our packages. The Calculator can now live in the nice_math package in a calculator.go file.

package nice_math

import (
    "fmt"
) 

type Calculator struct{}

func (c Calculator) Add(x, y int) string {
	if y > 0 {
		return fmt.Sprintf("%d+%d=%d", x, y, x+y)
	}

	return fmt.Sprintf("%d%d=%d", x, y, x+y)
}

The test can live in the nice_math_test package in a calculator_test.go file. The test then imports anything it uses from the nice_math package explicitly.

package nice_math_test

import (
    "fmt"
    "github.com/addetz/nice_math"
)

func TestAdd(t *testing.T) {
    want := "2+3=5"
    c := nice_math.Calculator()
    got := c.Add(2,3)
    if got != want {
        t.Errorf("Add(2,3) = %s; want %s", got, want)
    }
}

Table driven tests

Table driven tests have been growing in popularity amongst Go developers. This technique allows the same test setup to cover a variety of scenarios and ensure that the code is working as expected.

The outline of a table driven test is:

• Declare a test case structure that holds inputs and expected outputs for the function. Optionally, a name for the test case can be stored as well in the structure as well
• Construct an list/map with the test cases we want to test. If using a map, the name of the function can be the map key. Note: I, personally, prefer to add the name of the test in the test case structure as it’s easier to understand conceptually than using the map key for the test name
• Range over the list/map of test cases and run any assertions necessary in a subtest using t.Run

We can now expand our previous test to cover all of the logic of our calculator Add method to test out those negative inputs that we had not looked at until now

package nice_math_test

import (
    "fmt"
    "github.com/addetz/nice_math"
)

func TestAdd(t *testing.T) {
	tests := []struct {
		name string
		x, y int
		want string
	}{
		{name: "two positives", x: 1, y: 2, want: "1+2=3"},
		{name: "one positive one negative", x: 1, y: -2, want: "1-2=-1"},		
		{name: "two negatives", x: -1, y: -2, want: "-1-2=-3"},
	}
	c := nice_math.Calculator{}

	for _, tc := range tests {
		t.Run(tc.name, func(t *testing.T) {
			got := c.Add(tc.x, tc.y)
			if got != tc.want {
				t.Errorf("got %s, want %s", got, tc.want)
			}
		})
	}
}

Subtests allow an itemised view of each test and their outcome, making it easy to detect and fix failures.

=== RUN   TestAdd
=== RUN   TestAdd/two_positives
=== RUN   TestAdd/one_positive_one_negative
=== RUN   TestAdd/two_negatives
--- PASS: TestAdd (0.00s)
    --- PASS: TestAdd/two_positives (0.00s)
    --- PASS: TestAdd/one_positive_one_negative (0.00s)
    --- PASS: TestAdd/two_negatives (0.00s)
PASS

All tests passed.

Assertions and libraries

When it comes to testing, there are a few libraries that are worth mentioning:

• The testing package comes with the standard library. It is easy to start with, but it quickly becomes tedious and repetitive when used on more complex code. It also provides the ability to write benchmarks for our functions as well
• The testify library provides easy to use assertions which come in super handy when asserting on objects. It also provides mocks for substituting dependencies (I’ve not really talked about mocks in this little post, as they deserve their very own discussion)
• The ginkgo library provides BDD style tests using the given/when/then pattern and is usually used with the gomega matcher library

Parting words

Unit testing in Go is easy when making use of table driven tests to test the behaviours that your Go packages export. The testing package allows us to write subtests and write assertions for our code, allowing one test to cover multiple scenarios, while keeping traceability in test results.

Other libraries such as testify and ginkgo provide synctactic sugar on top of the standard testing package, but many voices in the Go community promote writing simple functions and tests, for which the testing package should be sufficient.

I frequently use the testify library for its assertions and mocks, but the structure of your tests and what they cover is more important than the library you choose for testing. I would definitely recommend starting out with just the standard testing library, keeping things simple for as long as possible and then moving to other alternatives as the need arises.

Happy Go coding!