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. For example:
One of the marks of a good senior developer is that they have lots of interesting opinions. After years of working on different software projects, they’ll be able to passionately explain why they think MongoDB is ass, paired programming is no fun, and the GitHub CLI changed their workflow.
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.Contains() function managed to leave a powerful impression on the hiring team.
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! I wouldn’t change anything here.”
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? Let’s chat about the popular naming conventions used in programming, and why you might choose one over another.
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 reality, for most technical problems, a good developer can likely point out several different solutions. Any of those solutions might be perfectly reasonable, while none of them is the single “correct way”.
In this world, nothing can be said to be certain, except death, taxes, and migrations. 🔗 Earlier in my career, I would come to a new project and inevitably a hectic migration would be underway. It’s not always a “stop the world” change, it can be as simple as switching from NPM to Yarn, but something is always changing. I used to naively believe my managers when they said cute things like “just this once” or “we’ll finally have our dependencies up to date.”
In the context of back-end web development, an ID is just a unique identifier for a record of data. For example, each user on a website will have its own ID. If the site is a social media platform, then each post will also have a unique ID.
“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. For context, our front-end team uses my team’s API to make fairly heavy requests to ElasticSearch, and one of the features of our API gateway is to cache the results of heavy aggregations for ~30 seconds. It turns out, every once in a while they need to run two of the same query within the ~30-second caching window and want an updated result set.
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. In the world of front-end development, that typically means making it obvious how to navigate your site, using commonly-understood icons, or implementing well-contrasted colors for foreground and background, making your site easy to read.
I’ve noticed that bugs introduced into an existing code base are often due to poor variable naming more than one might suspect. For example, a developer uses a rateLimit variable expecting it to be denominated in seconds while it represents minutes, resulting in a 6x slower schedule. Another developer expects dbConnection to be an open database connection, but instead, it’s just the connection URI.
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. DRY purports to accomplish this by reducing repetition in your codebase and replacing that duplicate code with abstractions like functions, classes, and methods.
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. Before you crucify me for my sacrilege, let me explain by giving you some of the “rules of thumb” I use for deciding when I should add a comment to my code.
Constants can be confusing and easy to misuse in Go if you are coming from an untyped language. Let’s take a look at some of the nuanced details of how they work in Go. It’s probably unsurprising, but Go’s constants are almost nothing like JavaScript’s bastardized version of the concept.
Writing technical documents like API or architectural documentation which exceeds a simple flow diagram can be a daunting task. If you have some experience with technical documents, you will probably agree that there is nothing more frustrating than bad documentation.
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. However, complex and nested if/else statements can quickly become a cognitive burden and compromise the readability of a program.
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. As a result, and perhaps somewhat counterintuitively, we’ve noticed a significant increase in our throughput of features and bug fixes.
Have you ever had the problem where you submit a pull request and the diff is much larger than it should be? Maybe the code looks identical, but GitHub tells you it’s completely different.
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. I don’t know how to find these systems reliably, I don’t know where they came from, what depends on them, and if they are safe to delete. For example, the dreaded 15 6 2 1 * /home/lane/backup.sh. You may recognize this as a Unix cronjob, a job that is scheduled to run on a server periodically.