As a developer, how many times each day do you look something up online? I’m not talking about a simple piece of syntax, I’m talking about the things that are a bit harder to find.
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.
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.
Have you ever had the problem where you submit a pull request and the diff is much larger than it should be?
Singletons are fairly controversial as far as I can tell, especially in JavaScript programming. Let’s take a look at what they are, when to (maybe) use them, and when not to.
My worst enemy is processes that a developer spun up years ago on a server everyone has forgotten about.