One of my favorite reads is Joel Spolsky’s Things You Should Never Do. He wrote this post almost twenty years ago, outlining the downfall of Netscape and others because they spent years rewriting working code. His solution is, unsurprisingly, to refactor. About a year before Joel wrote Things You Should Never Do, Martin Fowler published his popular book, Refactoring: Improving the Design of Existing Code.
So, my question is, if we as a community figured out — twenty years ago — that we should stop rewriting programs, why is it still commonly done today?
This post originally appeared on JustinDFuller.com.
This series, Go Things I Love, is my attempt to show the parts of Go that I like the best, as well as why I love working with it at The New York Times.
In my last post Go Things I Love: Methods On Any Type, I demonstrated a feature of Go that makes it easy to build Object-Oriented software.
This post, Channels and Goroutines, will demonstrate a few neat concurrency patterns in Go.
This post originally appeared on JustinDFuller.com.
Now that I am working with Go as my primary language at The New York Times, I want to explore some of my favorite features of the language. I don’t intend this to reveal previously unknown features or best practices; I just want to share some of the reasons that I enjoy working with the language.
Typically a method is defined as a function that belongs to an object or class. This means you wouldn’t necessarily add a method to a string, boolean, or number.
This limitation might lead a developer to produce code…
This post originally appeared at JustinDFuller.com
Are you struggling to find projects to showcase to potential employers? Have you been practicing LeetCode as you prepare to interview for a Software Development job? Do you occasionally practice a Kata on Codewars to keep your skills from getting rusty?
If you answered yes to any of these questions, you should consider saving every practice problem you do in a public git repo, like Github.
TL;DR: If all tests are mocked, you don’t know if your code really works, you only know that, theoretically, it is supposed to work if the integrations adhere to the contract you expect.
Mocking, stubbing, or maybe — even better — dependency inversion, they can simplify testing and make your code easier to change, but can they cause problems too? Let’s see.
Take a look at this test where we are saving a file using an external file service.
Welcome to my intervention. I’m a refactoring addict and I’m not afraid to admit it, but there’s only one problem: I’ve been doing it backwards. You see, what I’ve been doing could be more accurately described as premature code abstraction.
We all know about refactoring. If you’ve read even a single programming book, or if you spend much time on Medium, you’ll have heard all about it. It’s an important concept that keeps code understandable, maintainable, and extensible.
At least that’s what everyone tells me.
So why has refactoring not been accomplishing what I was hoping?
As I wrote my…
“A validation error occurred.” Yep. Thanks!
The release is imminent; this is the last update that needs to be verified, and I get an error message that’s as useful as the close button on an elevator.
It turns out that it is a validation error, kind of. The input I am giving is a duplicate. It’s valid, it just already exists!
Wouldn’t it be so helpful to know that?
In fact it would be helpful to be informed of several things when errors happen. I don’t need to know everything. The history of programming won’t help me here. …
I like to think that I’m a simple guy, I like simple things. So whenever I sense complexity, my first reaction is to wonder if I can make things easier.
Before I transitioned to software development, I spent time as a sound engineer. I was recording bands and mixing live shows. I was even recording and mixing live shows for broadcast. During that time I talked with too many people who would always attempt to solve problems by purchasing some expensive, more complex equipment. Sadly the return on investment never seemed to be all it promised.
Instead of buying into…
Most of us have heard of “writer’s block”, but have you heard of “developer’s block”? Just like a writer, a software developer can sit staring at a screen, not knowing where to begin. Sometimes that blank screen can be too intimidating and the code just doesn’t come to you.
So what do you do? Do you just take a coffee break, come back an hour later and hope you figure it out then? Maybe you can go talk to your coworkers, joke around for a bit, and put off getting that code working. Don’t worry, future you can deal with…
The day has finally arrived. Is it your first day on your job, or have you been doing this for ten years? It doesn’t matter. We all eventually find ourselves with a task that we simply do not understand.
So what should you do? Should you just get started and hope it works? Should you immediately tell your boss that you can’t do this because you don’t understand?
I imagine that you know the answer is neither!
In programming, as with any other profession, I have found that it’s almost impossible to go through a week (and sometimes not even…
Husband, Dad, Software Developer at The New York Times.