One of the marks of a good senior developer is that they have lots of interesting opinions.
Several years ago I started my first job as a “senior” Go developer. You see, after a modest 3 years in the industry, my arcane ability to use the Go standard library’s strings.
DHH, the creator of Ruby on Rails, Hey, Basecamp, and a few other things, recently wrote an article titled “Programming types and mindsets”, and I just have to chime in on this one.
Have you ever started a new software development job and thought: “Wow, what a beautifully architected system!
The following names are all valid variable names in nearly every programming language: dogName dog_name DOG_NAME dog-name But which one should you use in your projects?
There is a common trap that we fall into as developers, and it is believing that because some code “worked” that the code was written “correctly”.
🔗 In this world, nothing can be said to be certain, except death, taxes, and migrations.
In the context of back-end web development, an ID is just a unique identifier for a record of data.
“Dead Poet’s Society” is a classic film, and has become a recent favorite of mine. There’s a scene in particular that I enjoy, where Robin William’s character explains that it’s bad practice to use terms like “very tired” or “very sad”, instead we should use descriptive words like “exhausted” or “morose”!
I recently had a ticket opened on my team’s backlog board requesting the ability to bypass our API’s caching system.
Too often I neglect the idea of UX design in backend work. The goal of user experience design is to give users a product that’s easy to use.
I’ve noticed that bugs introduced into an existing code base are often due to poor variable naming more than one might suspect.
Functional programming is a way to write code where programs are created strictly through functions. Functional programming has gained quite a bit of traction in recent years among the development community, mostly because of the benefits it provides.
“Don’t repeat yourself”, or “DRY” for short, is a somewhat controversial principle of software development. It aims to make code cleaner, which is to say less buggy and easier to work with.
I often hear that we need more and better comments in the code we write. In my experience, we frequently need better comments, we rarely need more, and we sometimes need less.
Constants can be confusing and easy to misuse in Go if you are coming from an untyped language.
Writing technical documents like API or architectural documentation which exceeds a simple flow diagram can be a daunting task.
One of the first concepts new developers learn is the if/else statement. If/else statements are the most common way to execute conditional logic.
In Go, we often need to return zero values. Idiomatic Go encourages the use of guard clauses, and guard clauses necessitate the need to return early.
My team has been spending less of our “free” time working on bugs and features from the backlog, and more time refactoring our code and tests.
There are quite a few ways to create new maps and slices in Go, for example, they can both be initialized using the make() function, the new() function, as literals, or by using the var keyword.
Have you ever had the problem where you submit a pull request and the diff is much larger than it should be?
Sorting is a common task in programming, and for that reason, most languages have a default sorting algorithm in their standard library.
Go is strongly typed, and with that, we get many options for simple variable types like integers and floats.