In one of my previous posts I talked about what Happy path engineering is and how understanding the time to implement plays an important factor in that.
So, if time to implement is important how can we get better at estimating the time we need and how can we help others understand the benefits that estimates bring (and, the often, innacurate nature of them)?
This is a post I’ve had in my mind for some time now and it’s based on my personal experience job hunting in the UK … 📖
And so it begins …
Our story begins several years ago when I first moved to the UK and put my CV online on some job board websites. What I hadn’t realised at the time was that the sites would distribute the CV to a number of recruitment agencies which was both great and a bit scary 😅
If this is the first time you come across the Go coverage profile then do read my last post: Test coverage in Go, working with packages and sub-packages. It is an introduction to Go’s cover tool, how to generate the coverage profile and how to use it to aggregate the coverage from the sub-packages to the root package.
If you are already familiar with the cover tool and the coverage profile then let’s dive in and see a few cases that you need to be aware of if you are trying to aggregate the coverage from the sub-packages all the way to the root of your package.
A test suite for any package is explicitly testing different code paths and identifies how your code works using different inputs. But does it actually manage to cover all the code branches that exist in your code? How about all the different functions?
One way to answer these questions is to thoroughly look at all the tests written (by you and your colleagues) and understand if there are any gaps. The easiest way to do that though is to use a tool, and in the case of Go this tool is called cover.
There is an excellent blog post on the Go Blog, called “The cover story” that describes how Go uses the cover tool to generate reports that I definitely recommend reading. In this post we are going to analyze a few parts of how the cover tool works and also provide a way to use it for packages which include sub-packages.
R is a number used as a simplified indication of how quickly COVID-19 (or any other infectious disease) is spreading and how critical it is to take additional measures to control the spread of the disease.
But what exactly does R represent, what are the values of R around the world and are there any resources we can use to see how it evolves over time? I am going to share what I learned but fair warning: I am not a doctor or an epidemiologist so please also do your own research using sources you trust.
There are different ways of debugging a Go program. You could use print statements to view the values stored in your variables during the execution or you could use a debugger. Some IDEs, like GoLand, offer this functionality by default but it is also interesting to see how to use the integrated solutions from the command line. Delve offers both command line clients and an API that can be used to integrate it to other tools (which is actually what GoLand uses under the hood).
If you haven’t heard the term before it’s used to describe a user or system flow that goes through all the expected steps without any issues. Everything else is referred to as an edge case, or a state that the user or the system entered that was unexpected or unplanned, which may even trigger an error report.
An Abstract Syntax Tree (AST) is a tree representation of the structure of a piece of code used mainly in compilers. ASTs can also allow us to traverse existing code and use the information collected to auto-generate new code, which we are going to do in this post! The structor is a command line utility we are going to build that given a domain package with struct definitions it automatically generates getter and setter functions for the fields of the structs.
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!