DEV Community: Adelina Simion 🥑

Craft Yourself a Sustainable Tech Career

Adelina Simion 🥑 — Sat, 09 Mar 2024 00:00:00 +0000

This year marks my tenth anniversary of working in tech. I graduated from university in Denmark at the end of 2013. I moved to London in the spring of 2014 and took a graduate Java developer position. Except for the odd 1-2 month break between jobs, I have been working full time for the past decade.

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. 🏜️

All Gophers aboard! Deploying your first Go app to Railway 🛤️

Adelina Simion 🥑 — Wed, 23 Aug 2023 00:00:00 +0000

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:

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.
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.
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.
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 by launching a new browser window, 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!❤️

Test-Driven Development in Go: principles and key concepts

Adelina Simion 🥑 — Sat, 06 May 2023 00:00:00 +0000

Estimated reading time: 6 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 :

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.
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.
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.

Figure 1 - The core principles of the book.

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:

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.
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.
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.
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.

Figure 2 - The Red-Green-Refactor TDD method.

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.

Figure 3 - Getting started with Go unit tests.

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.

Figure 4 - Integration tests allow us to test how well components work together.

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 implementing 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:

The Future of Code Week: Will Languages like Go and Rust Overtake their Legacy?

Adelina Simion 🥑 — Mon, 14 Nov 2022 00:00:00 +0000

Estimated reading time: 5 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’snet/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.

Nevertheless, Adelina coded

Adelina Simion 🥑 — Thu, 03 Mar 2022 00:00:00 +0000

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 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!

Tips for your first DevRel interview

Adelina Simion 🥑 — Sun, 20 Feb 2022 00:00:00 +0000

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

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.
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.
DO write a bespoke resume that highlights your DevRel adjacent experience.
- Engineers are ofen used to just sending round the same resume to all their roles, as it doesn’ 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.
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.
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!

Unit testing in Go

Adelina Simion 🥑 — Mon, 31 May 2021 00:00:00 +0000

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!

Go functions, closures and handlers

Adelina Simion 🥑 — Sat, 06 Feb 2021 00:00:00 +0000

Estimated reading time: 7 mins

While Go is not a functional language, functions are a central part of Go. They can be assigned to variables, passed as parameters and returned from other functions. This is known as support for first class functions and it allows Go programmers to compose higher order functions and closures.

Understanding these mechanisms can be a powerful addition to the tool belt of any programmer, so let’s take some time to explore the behaviour of Go functions.

Let’s get functional and elegant!

Basics

Functions are reusable code blocks, dedicated to performing well defined logic on inputs or parameters and producing outputs or return values.

In Go, functions are declared using the func keyword. The naming convention is to use camelCase. Unless exported, functions are available in the same package that they are declared into.

func myFirstFunction() {
    fmt.Println("This is my first function!")
}

Functions are allowed to take zero or more parameters and return zero or more outputs. The return types must be declared in the function signature.

The function hiBye below says hello and goodbye using 2 different return values.

func hiBye(name string) (string, string) {
    return fmt.Sprintf("Hello, %s!", name),
        fmt.Sprintf("Goodbye, %s!", name)
}

func main() {
    hi, bye := hiBye("favourite reader")
    fmt.Println(hi)
    fmt.Println(bye)
}

main prints out these values to produce the output below. See this in action on the Go playground.

Hello, favourite reader!
Goodbye, favourite reader!

Program exited.

Go also supports anonymous functions, which can be defined inline without having to be explicitly named. In the example below, hiBye now only lives inside main, but it will have the same output as before. See for yourself in the Go playground.

func main() {
    hiBye := func(name string) (string, string) {
        return fmt.Sprintf("Hello, %s!", name),
            fmt.Sprintf("Goodbye, %s!", name)
    }

    hi, bye := hiBye("favourite reader")

    fmt.Println(hi)
    fmt.Println(bye)
}

Functions can also be deferred using the defer keyword. The deferred call’s arguments are evaluated immediately, but the function call is not executed until the surrounding function returns. The code below defers the call to hiBye until main finishes its work.

func main() {
    hiBye := func(name string) {
        fmt.Printf("Hello, %s!\n", name)
        fmt.Printf("Goodbye, %s!\n", name)
    }

    defer hiBye("favourite reader")

    fmt.Println("Main says hello and goodbye!")
}

Due to the deferred function call, main prints first, finishes, after which the greetings are printed. See this in action on theGo playground.

Main says hello and goodbye!
Hello, favourite reader!
Goodbye, favourite reader!

Program exited.

Closures

Closures are a special case of anonymous functions, which can be a little confusing for those not used to them, so they deserve a moment to investigate.

A closure is a function value that references variables from outside its body. The function may access and assign to the referenced variables; in this sense the function is bound to the variables.

The example below returns a closure, each referencing its own index and greet slice, thus allowing it to maintain state between invocations.

func greet(greetings []string) func() string {
    index := 0
    return func() string {
        greet := fmt.Sprintf("%s!", greetings[index])
        index++
        return greet    
    }
}

func main() {
    his := []string{"Hello", "Salut", "Hej"}
    byes := []string{"Goodbye", "La revedere", "Farvel"}
    hi, bye := greet(his), greet(byes)
    for i := 0; i < len(his); i++ {
        fmt.Println(
            hi(),
            bye(),
        )
    }
}

main prints out these values to produce the output below. See this in action on theGo playground.

Hello! Goodbye!
Salut! La revedere!
Hej! Farvel!

Program exited.

Higher order functions

As seen in the basics section above, Go functions can be passed around, returned and assigned to variables. This is particularly useful for constructing a function, but not immediately invoking it.

Higher order functions are those functions composed from other functions. They can either accept a function as a type or return a function. Functions can be treated as any other value type, so composing higher order functions is easy and seamless.

The hiBye function can now be composed of 2 separate greet functions and invoked only once.

func print(name string, hi func(string) string, bye func(string) string) {
    fmt.Printf("%s\n%s\n", hi(name), bye(name))
}

func hiBye() (func(string) string, func(string) string) {
    hi := func(name string) string {
        return fmt.Sprintf("Hello, %s!", name)
    }
    bye := func(name string) string {
        return fmt.Sprintf("Goodbye, %s!", name)
    }
    return hi, bye
}

func main() {
    hi, bye := hiBye()
    print("favourite reader", hi, bye)
}

main prints out these values to produce the same output. See this in action on theGo playground.

Hello, favourite reader!
Goodbye, favourite reader!

Program exited.

Handlers

An interesting notable mention when discussing functions is in the context of building HTTP servers using the net/http package.

An HTTP handler is a function that runs in response to a request made to an HTTP server.

In Go, handlers are registered on server routes using thehttp.HandleFunc convenience function. It sets up the default router in the net/http package and takes a function as an argument.

func (mux *ServeMux) HandleFunc(pattern string, handler func(ResponseWriter, *Request))

A common way to write a handler is by using thehttp.HandlerFunc adapter on functions with the appropriate signature. Functions serving as handlers take a http.ResponseWriter and a http.Request as arguments. The response writer is used to fill in the HTTP response.

type HandlerFunc func(ResponseWriter, *Request)

The hiBye function explored so far can be easily converted to a handler function to serve the greetings explored so far. Note how the hiBye function is passed to the HandleFunc as a parameter.

func hiBye(w http.ResponseWriter, req *http.Request) {
    fmt.Fprintf(w, "Hello!\nGoodbye!\n")
}

func main() {
    http.HandleFunc("/hibye", hiBye)

    fmt.Println("Listening on :8090...")
    http.ListenAndServe(":8090", nil)
}

The full code can be seen in theGo playground, but it will need to be run locally and tested using curl. The output should be as below:

$ curl localhost:8090/hibye
Hello!
Goodbye!

The signature of the HandlerFunc is pre-defined, so what would happen if the function needed more parameters passed to it? As before, it would be great to pass a name to the greeting, as below:

func hiBye(w http.ResponseWriter, req *http.Request, name string) {
    fmt.Fprintf(w, "Hello, %s!\nGoodbye, %s!\n", name, name)
}

func main() {
    http.HandleFunc("/hibye", hiBye("favourite reader"))

    fmt.Println("Listening on :8090...")
    http.ListenAndServe(":8090", nil)
}

This throws compilation errors because HandleFunc is expecting a function parameter, but now the hiBye function has been invoked with only one parameter. Oh dear, what a pickle!

$ go run handlers.go
# command-line-arguments
./handlers.go:13:36: not enough arguments in call to hiBye
        have (string)
        want (http.ResponseWriter, *http.Request, string)
./handlers.go:13:36: hiBye("favourite reader") used as value

While there are other solutions to this problem out in the wild, a common solution is to use a wrapper function or closure to pass the parameter to the hiBye function. In this way, the returned function still conforms to the expected signature and the greeting gets its extra parameter.

func hiBye(name string) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "Hello, %s!\nGoodbye, %s!\n", name, name)
    }
}

func main() {
    http.HandleFunc("/hibye", hiBye("favourite reader"))

    fmt.Println("Listening on :8090...")
    http.ListenAndServe(":8090", nil)
}

The full code can be seen in theGo playground, but it will need to be run locally and tested using curl. The output should be as below:

$ curl localhost:8090/hibye
Hello, favourite reader!
Goodbye, favourite reader!

Parting words

That’s it for now. I’ve covered a lot of ground, but a few key points to remember are:

Go functions can be assigned to variables, passed as parameters and returned from other functions
Functions can be anonymous. This means they are declared inline and are not explicitly named
Closures are anonymous functions that are bound to variables outside of their body
Higher order functions are composed from other functions. They can either accept functions as a type or return functions
Handlers are functions that run in response to a request made to an HTTP server

Having a good understanding of functions can help solve a wide variety of problems through composition. I hope this post gave you an insight into the wonderful world of Go functions.

Happy Go coding!

Dealing with interview rejection

Adelina Simion 🥑 — Sun, 24 Jan 2021 00:00:00 +0000

Estimated reading time: 4 mins

The tech industry has high turnover and attrition rates. Engineers get out on the job market more often and spend more time preparing for and going through interviews than other sectors. On the flip side, engineers also have to deal with more interview rejections.

While it’s always painful to be rejected or not achieve a goal we worked hard for, rejections are a great way to learn. In this post, I share some of my ways to deal with the bitter pill that is interview rejection.

Let’s turn that frown upside down! :)

Turn that frown upside down!

The subjective and imperfect interview process

Before getting into handling interview rejection, let’s discuss the interview process itself. This will set the basis of what the rejection really means.

Typically, the technical interview process aims to assess:

Ability to contribute to technical projects : each team will be working with a different tech stack and solving their own unique set of problems. The interview process should (if thoughtfully designed!) pose coding challenges which are representative of what the team works on. The technical question is therefore skewed to look for a certain experience and profile
Cultural fit : even brilliant, genius engineers need to fit into their prospective team. The process does not focus on the technical solution only, it will (and should!) include an assesment of communication skills and team fit. Each team has its own practices and idiosyncracies, so interviewers will look for signals which reflect the team’s practices
Seniority and expertise : the team will be looking for a specific level of seniority as well as technical skill. Depending on the role, the interview process might assess attitude to learning and development as well as mentoring style to ensure that it fits with the expectations of the role they are trying to fill. A candidate that does well on the technical task might still be unsuccessful if they do not perform at the job role’s level of seniority

The interview process is a skewed and subjective process that, by design, can only assess technical ability in the frame of a single team’s work and expectations. Assessments of team fit are predictions that interviewers make on the basis of a relatively short interaction with the candidate.

Keep in mind that the process is far from perfect and don’t take rejections personally!

Making the most of interview rejection

Now that I’ve set the scene for what the rejection really means, it is time to look at how to make the most of an interview rejection.

Here are my tips to making the most out of interview rejections:

Request written feedback : most recruiters will want to give interview feedback on the phone to give a more personal touch to the process. Hearing the feedback can be emotional, making it difficult to remember the details of what was said. Make sure to request written feedback from the interviewers themselves instead of the recruiter’s short verbal version. This might take a while to receive, but most recruiters will be happy to help candidates improve
Solve the interview problems again : take the time to solve the interview problems again at home, making sure to fix any issues of the interview solution. This will empower and fill in any immediate technical gaps. Who knows? The same problem might come up at another interview in the future
Use it as constructive, free feedback : turn the power dynamic back and take the interview rejection as constructive feedback instead. I’ve learned where my technical gaps are and how to be better at communicating from interviews. Rejections are a great learning tool, so use them to direct and adjust interview preparation
Think of interviewing as a skill in itself : practice is important when picking up any skill. Treat all interviews as practice, where learning is the primary objective and getting an offer is the icing on the cake. No matter the amount of preparation and studying, the proof is in the pudding and there is no substitute for actually taking the leap and getting out there
Use the interview process to judge the employer : the interview questions are one of the strongest signals a candidate can get about their prospective employer, giving insight into what they find important and what working there might be like. If these questions don’t align with the candidate’s interests and experiences, then they might not be a suitable future employer, regardless of whether the interview is a success or not

Parting words

Remember, interview rejections happen to everyone!

Interviewing is more like dating than an academic exam. An interview rejection simply means that the candidate was perceived as not fitting well into the projected expectations of that team, not that they are not a good engineer. Just like dating, it’s all about two sides matching up what they’re looking for.

It’s important not to internalise rejection as anything more than it is. It is not a reflection of general technical ability, but a subjective evaluation of the candidate based on a skewed process. Take whatever constructive feedback the interview provides, learn from it and then move on, stronger and better.

Happy interviewing & job hunting!

A little more code review please!

Adelina Simion 🥑 — Sun, 10 Jan 2021 00:00:00 +0000

Most of us working in software engineering can agree that code reviews are important and should be a priority, no matter how busy we get. However, I have seen my fair share of teams that have struggled to carry out their best code review intentions into sustained working process.

In this post, I will discuss some code review best practices for both authors and reviewers, so that we can make the process as efficient and enjoyable as possible.

A little less conversation, a little more code review please!

Code review, what is it good for?

Code review, or peer code review, is the process through which the code author gets their colleagues/peers to check their work. The author typically submits a pull request(PR) which contains the implementation of all the changes they are proposing. The author’s colleagues typically read and make recommendations on the implemented code changes becoming code reviewers.

As mentioned in the intro, everyone seems to agree that code reviews are generally a good idea and they have been thoroughly discussed in articles, blogs and books.

A few of the benefits of code reviews are:

Better code quality : code reviewers can find defects or edge cases that the author has not considered before they are deployed to production. The cost of code review time is infinitesimal compared to the potential cost of a production outage
Knowledge sharing : engineers of all levels benefit from code reviews: newbies learn how to solve complex problems from the more experienced members, while experienced members stay in the loop with all the changes that the team is making and prevent knowledge silos
Increase code ownership : the team gets a sense of solidarity, responsibility and ownership for the whole codebase if the work is collectively agreed on. Code reviews offer the opportunity for everyone in the team to propose solutions and discuss the best solutions to problems
Ensure maintainability : once the team reach a mutually agreed solution, they can also ensure that the codebase is documented and maintainable. The code review process itself ensures that other engineers understand the work of the author, thus ensuring maintainability of the codebase

Code reviews are a very worthwhile time investment and are an essential tool for any team delivering stable production software. Unlike war, code reviews are good for many things!

Code review, where did we go wrong?

Some ways I have seen the code review process go wrong are:

Dramatically slowing down code delivery : code changes can be stuck awaiting for review for a long time and slow down delivery. A PR can be stuck waiting for review for days. Finally, the review is rushed and the code is merged to production at the last minute
Becoming a box ticking exercise : code changes are not reviewed in depth and in a constructive way. The code review becomes a box ticking exercise where all reviews are automatically approved, rendering the code review process irrelevant
Not sharing with the whole team : team members approve each others’ reviews without sharing them with everyone. Team members are not aware of all the changes made to the codebase

When it goes wrong, the code review process cannot give us the benefits discussed in the previous section. Code reviews then become a cumbersome annoyance that we avoid and ignore. When code reviews go wrong, it is all our fault!

I’m gonna write you a PR!

Having looked at the benefits of code reviews and how they can go wrong, it’s time to discuss what we can do as code authors to make the process smooth and enjoyable for code reviewers. The author starts the whole process and has a vested interest in making sure reviewers can make the best recommendations for their work.

In my experience, code authors should ensure that they:

Easily share proposed code changes : the proposed code changes should be easy to access and read. I mentioned earlier that code changes are typically shared by raising a pull request(PR) and sharing it with reviewers. PRs are hosted on Github, or a similar service, where the reviewers can view and comment. While this is common practice, simply extracting a diff file and sharing it would do the trick as well, as what is most important is giving reviewers a way to easily see the proposed code changes at a time that suits them
Write meaningful commit messages : commit messages are the first thing that code reviewers see when they start the review. They should be well written and offer context to what the changes are aiming to achieve. They should also link to any tickets/issues they are fixing to ensure traceability. Go’s contribution guidelines to good commit messages offers some very good recommendations on commit messages
Keep code changes small : it is tempting to extend scope and implement several things in the same code commit. This is a tendency that is common with less experienced engineers, and a mistake I often made in the beginning of my career. Large code changes are hard to test, stabilize and review. Remember that a code commit does not have to fix a whole ticket. A single code change should be a small, testable piece of work that achieves only one single piece of functionality. It should be complete, but should not attempt to do more than its small scope. This will allow reviewers to focus on the one change and reduce review time, making it easier to fit into their schedule
Allow the entire team to see the proposed change : make sure that code changes are shared with the team and assigned to appropriate code reviewers. Share the code change on the correct channels and ensure everyone in the team is aware of the change. Reviewers with the correct expertise should be assigned for review, going outside the team if necessary

Code changes which are well defined, well tested and provide sufficient context are a joy to review. As long as your code changes follow these simple rules, you can write me a PR any time!

These PRs are made for reviewing!

Finally, once good code changes are submitted for review, it is time for the code reviewers to shine and do their best work! The code review itself should be an enriching and constructive process for all.

In my experience, code reviewers should:

Make it a priority to unblock others : in essence, once the author has submitted their code change for review, the work is blocked until reviewed. It can be difficult to balance delivering own work together with code reviews, but code reviews should be the number 1 priority of the entire team. Unblocking others should always take precedence to delivering own work
Offer meaningful constructive comments : code reviewers should ensure they take the time to write meaningful, well formulated and constructive comments that empowers the author and helps them grow. Comments should take into account the level of experience and knowledge of the author, ensuring that they offer easy to follow guidance
Request explicit documentation : code reviewers should set aside their own experience with the codebase and request explicit documentation which might be useful for a newcomer, even if they themselves don’t need it. This ensures that code changes are maintainable and well documented
Agree on a team wide review turnaround time : my recommendation is that the team agree on a code review turnaround time and collectively enforce it, to avoid code changes being blocked awaiting for review. Once this is agreed, team members can block their calendars accordingly to ensure that they have the appropriate bandwidth to deliver these reviews in the agreed time frame

Code reviewers play a crucial role in shipping stable features at speed. Prioritize unblocking others and review these these PRs that are made for reviewing.

Parting words

Code reviews are such an important engineering tool: helping us deliver stable software, learn from each other and ensure we are shipping the best solutions. Engineers frequently change hats between code author and code reviewer during daily work, so keeping in mind what to do to make the other person’s job easier will ensure that the process remains efficient and enjoyable for everyone involved.

I hope you enjoyed this roundup of code review best practices with a musical twist.

Happy code reviewing!

Why do you like Go?

Adelina Simion 🥑 — Thu, 31 Dec 2020 00:00:00 +0000

I was asked this question - “Why do you like Go?” - during several job interviews. The question itself is not tough, but it is broad and full of opportunities to trip up. It’s difficult to distill your thoughts into a coherent answer in a high pressure situation.

I’m going to use this post to nail down an answer to this dreaded question.

Let’s Go!

Let's Go!

What the question means

The question is ambiguous, but it has been posed to me in this form. Even though I write Go code daily, I wouldn’t say I have any personal feelings of “like” towards it.

The question is meant to be a conversation starter about the usage and strengths of Go. In my experience, the answer should touch upon the broad areas presented below.

Writing & deploying Go code

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
First class functions - Go functions can be assigned to variables, passed as parameters to other functions and returned from other functions. This is known as support for first class functions. This allows Go programmers to compose higher order functions and closures, which are particularly useful for dynamic programming
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

Performance of Go

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
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

Concurrency in Go

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
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
Concurrency patterns - 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

Parting words

Since the answer to this broad question had a lot to cover, I have only given some brief headline answers to each topic. In an interview setting, you should be prepared to be asked to delve into more detail on any topics of particular interest. I am not be able to provide this level of detail in this post, but I have left some further reading links below which should be useful.

Go is particularly suited for building high volume, scalable, performant web applications. It has been gaining lots of popularity in the Dev community and has been adopted by big players such as Google, Uber and Netflix. I hope this blog post will help you answer questions about the benefits and strengths of Go, whether in an interview or not.

Happy Go coding!

DEV Community: Adelina Simion 🥑

Craft Yourself a Sustainable Tech Career

You don’t have to be beyond reproach.

Never make yourself small.

You are not an impostor.

Lift yourself by lifting others.

Parting Thoughts

All Gophers aboard! Deploying your first Go app to Railway 🛤️

What is Railway? 🛤️

Signing up & setting up 🛠️

The Go European Weather checker 🇪🇺

Deploying to Railway 🚆

The cherry on top 🍒: GitHub Actions

Parting words

Test-Driven Development in Go: principles and key concepts

Key principles

The method

Unit testing essentials

Integration testing

End-to-end testing

Parting words

Resources

The Future of Code Week: Will Languages like Go and Rust Overtake their Legacy?

Session summary

What Go does well

Performance & Concurrency

The future of Go

Parting words

Nevertheless, Adelina coded

Going to university

My university “friends”

The missing female mentor

Don’t say the M word

Parting words

Tips for your first DevRel interview

Interview tips

Parting words

Unit testing in Go

Basics

The unit under test

Table driven tests

Assertions and libraries

Parting words

Go functions, closures and handlers

Basics

Closures

Higher order functions

Handlers

Parting words

Dealing with interview rejection

The subjective and imperfect interview process

Making the most of interview rejection

Parting words

A little more code review please!

Code review, what is it good for?

Code review, where did we go wrong?

I’m gonna write you a PR!

These PRs are made for reviewing!

Parting words

Why do you like Go?

What the question means

Writing & deploying Go code

Performance of Go

Concurrency in Go

Parting words

Further reading