In the Divergent Tech Lead post I talked about a number of different interpretations of what a Tech Lead means. Since the role is by no means straightforward – you may need to develop different skills depending on your current team.
In my journey I have focused a lot on gaining specialized Domain Knowledge, building up Technical expertise, working on effective Team organisation & Planning, and perhaps most importantly clear & comprehensive communication. Let’s have a closer look at what all these really mean.
A couple of months ago I decided I wanted to learn a bit more about music so I decided to learn how to play the piano. This is an entirely new world for me, as I have practically zero prior knowledge. Little did I know then of how similar my experience was going to be to when I started writing code!
Arrays and Slices are two of the most common data structures you will ever use if you program in Go. They share a lot of properties as slices are ultimately build on top of arrays but also quite different.
Some time ago I decided to do a little research in an attempt to figure out which are the most often requested skills that a Tech Lead is expected to have. If you are interested in that post, it’s here.
Back then I was not surprised to see that there isn’t a universal set of skills that a Tech Lead is expected to have. Quite the opposite actually, different people perceive the role in different ways and have quite different expectations. This has led me in a definition I call the Divergent Tech Lead. But let’s start from the beginning …
A simple definition of Go routines is found the “Tour of Go” section about concurrency:
a Go routine is a lightweight thread managed by the Go runtime
Now if you have not come across threads before, threads is a way for a program to run parts of itself in some sort of concurrent way. In this post we are going to examine the differences between running a program sequentially, using Go routines and Wait Groups and we are going to talk about thread safe access to a data structure. So… Let’s get started 💪!
I am preparing some code for a another blog post I came across some very unexpected behavior on my terminal that really got me thinking 🤔. Time was behaving in 2 different ways depending on what it seems an entirely unrelated reason.
Writing code and building software is fun no matter which language one uses. But what we have found is that there is no “language to rule them all”. There are a number of languages out there each with its own quirks, strengths and weaknesses and that’s just amazing.
So where does that leave us as software engineers? We will probably need to pick up more than one languages as we go along, but what’s the best way to go about that?
A lot of things in life are a matter of perspective and visibility and the same applies to variables in Go 😅. But what is a variable’s scope, how is it defined and what does it mean to shadow a variable in Go?
Let’s (very) loosely say that the scope of a variable declares where this variable is visible from ie. if we have declared a variable at the top of the file then it’s visible from within the entire code of that file.
We can go even deeper than that though and we can break this question down into Go specific terms.