Developers have a plethora of tools available to them. Maybe more so than any profession. New potential tools pop up monthly, perhaps daily.
Most developers I know are passionate about some of their tools. IDEs and editors tend to be a hot topic, filled with religious battles. But there are a lot of other tools we use on a daily basis that we may not think about as tools of the trade
As craftsman (yes, developers are craftsman, I’ll fill another blog post with some thoughts on that another time), we should take great care with our tools. You should be selective in the tools you use, weighing the trade offs of them versus the tools currently in your belt. You should freshen them up, keep them up to date and make sure to choose the correct versions. You should customize them, crafting configurations for them that serve your purpose. You should even create some tools, specifically for yourself but which may help others.
Choosing your tools
In Cal Newport’s “Deep Work”, the author recounts the story of a farmer outside of D.C. analyzing the value of a hay baler. It seems clear that there are obvious benefits to the hay baler for a
I’ve blogged a lot about distractions and thinking lately. One thing I’ve noticed is just how distracted we are in our world today. You know what I’m talking about, the constant buzzing from our smartphones. I’ve also talked about how to deal with that. That part of it is on us. But today I want to turn our attention to the root cause of this.
Sure, in some regard, your phone is what you make of it. You can ignore notifications to some extent, and you can do things to reduce them. But that is definitely not the default mode. I was turned onto this idea when I first heard Tristan Harris. He appeared on a podcast with Sam Harris (no relation).
Here’s his core idea. While we say technology is neutral, the reality is that the applications we install on our phones manipulate us. They trick us to open them. They trick us to spend more time on them. I was vaguely aware of this, but hadn’t heard it phrased in a way that the ideas became concrete.
Behind every app is a team of people working to keep your attention. Experiments
Coding is a small part of the job of a developer. We spend a lot of time at whiteboards, drafting designs. We spend a lot of time reading code. And we spend a lot of time thinking.
We all think about code. A lot. But what about everything else? Are you thinking about the design? How about the decisions you’re making right now and the impact they’ll have on you, your team, and others now and down the line?
Mistakes tend to happen precisely at the moments we aren’t thinking. Sometimes we’re just on autopilot. Other times, we’re focused solely on the task at hand, forgetting about how it will impact other future decisions.
We need to start thinking clearly about the problems we’re solving. Decision impact is one of the big ones for sure. Too many decisions are made in a silo. How are the changes you’re making today affecting others?
What about months down the line? This is often one of the big differences between junior devs and senior devs. Senior devs tend to be thinking about the long term product strategy. Junior devs often miss this. Start thinking deeper about this if you want to advance your career.
Speaking of careers, we
On a typical work day, I get interrupted from what I’m working on about 9000 times, or about once every three seconds. At this point I’m a pro at getting interrupted.
Now, obviously, this is hyperbole, but the point is valid. As developers, there are a lot of different pulls on our attention. Of course this isn’t unique to developers. But as tech companies move to open floor plans, the need to be able to focus, despite those distractions, is growing.
I’ve focused a lot lately on the idea of mindfulness while coding, but it is easy to see how distractions can prevent that. Any interruption can snap you out of your focus, and suddenly you’re rabbit-holing down a path you never intended.
Ideally, we can remove our distractions. I’ll touch on a number of ways I personally attempt to remove distractions from my work.
The first type of distraction we’ll need to deal with is external. This is interruptions coming at you from outside your control.
My number one way to
You sit down to start a new project. You start setting up the environment, maybe its a web service you're writing. As you're going along, you think, "what if I want to switch the database on the backend?" So you start to add in an abstraction layer there. You pack up for the night and promise to yourself to finish it tomorrow.
As tomorrow rolls around you think, "Gee, that DB abstraction is really boring to work on, so I think I'll work on something else." And this happens the next day, and the next…
Sound familiar? Maybe this happens to you at work too, you start designing a new service, and you make sure its scalable to 1000s of requests per second. But then your service is serving 10's of requests per day and you're already too late to the game.
This happens all the time, we get derailed with the technical details and totally miss focusing on the problem we were trying to fix in the first place. We take way too long to produce a solution, and end up either losing interest on a personal project, or bringing a work project to market way too late.
In my last blog,