Late Blooming Code

Neal Ford posed a question on Dave Rael's Developer on Fire podcast. He asked whether if you were offered $10,000,000 on the condition that you could never write another line of code for the rest of your life, would you take it? I'll leave it to you to go listen to the podcast if you want to hear Neal answer his own question, but you can have my answer here. Why Take the Money For me, and probably a lot of other people, the purpose of accepting the money would be to gain freedom. Having a sufficient amount of money with which one could live out the rest of one's life comfortably changes one's perspective and position considerably. With $10,000,000, I would no longer need to work. That's probably obvious, but considering how much of our time is spent working in and on our careers, that's an enormous gain. All of that time comes back to me because I am no longer compelled by necessity to go out and earn a living through labor. The Value of Work The difficu

Here's a debate that will never end as long as people are writing code: which text editor is superior? While there is one that I regularly use, I really think the answer to this question is none of them. They all have their strengths and limitations. It often comes personal preference, convenience and the nature of the tasks you typically need to accomplish. What is less often discussed is why we should even bother with using a text editor at all. What is a Text Editor? I'm going to back up a bit though. Let's first ask: what is a text editor? A text editor is a program with the primary function of editing and manipulating characters on a screen and writing them to and reading them from files. While text editors are very commonly used in software development, they are not restricted to that purpose. Anyone who has any textual content to write or edit can potentially benefit from using a text editor. Text editors generally don't provide much in the way of visual form

Bugs can be really evasive and produce some surprising, even "impossible" behaviors. Part of a software developer's job is to relentlessly hunt them down and destroy them. However, often at least half the battle is finding them to begin with. The best debuggers I have seen rely a lot on experience, both experience with the application and experience with debugging in general. The former is situation-specific, and there many not be any good ways to advance in that regard other than practice. However, we can extract some information pertaining to good debugging practices in general. Dig for Clues Using All Available Resources The first step in debugging an issue is ideally to reproduce the problem. This isn't always possible, but if you want any significant level of confidence that you have fixed a bug, you need to observe the broken behavior and understand how to trigger it from a user's perspective. Sometimes we're lucky, and a tester has taken the time to

In my varied life experiences, I have never encountered a vocation or activity that could build up one's confidence before snatching it away in such quick succession as in software development. There is magic in bending a computer to your will and having it execute your commands faithfully. However, as with all good tales of magic, there are many pitfalls, which can rapidly deflate your ego. Little Oversights Can Bite I once wrote database upgrade code that repaired some broken references in a database. This fixed several known defects. I was really proud of myself because the code came together quickly, it looked good and it worked well. It passed all tests and review, it was merged with the product and all was well. That is, until someone discovered that some databases were triggering crashes on upgrade. Fortunately, it took little time to find the source of the problem, but all of my pride vaporized, as I had to explain to my manager that I forgot to account for the possibil

This post discusses the whether to buy or build software components needed for your application. The title should give you a clue as to which side of the discussion I land on. Someone Else's Code One of the behaviors that I've noticed is significantly more often exhibited by junior developers versus more experienced ones is the tendency to build everything from scratch. While I can appreciate the enthusiasm for wanting to create something better than has been done before, this is often simply a waste of time. For many of the software tasks you will want to accomplish, someone will have made a library of framework that does 95% of what you want out of the box, lets you configure or extend it to do another 4.9%, and you come to realize that 0.1% remaining wasn't all that important anyway. In fact, with the proliferation of open source software, many of these software packages are 100% customizable because you have access to all of the source code and can change it at will

In this blog post, I show you how I automated entering credit card transactions in QuickBooks using the PyAutoGUI package for Python. Automating routine tasks is a great way to save yourself a lot of time. Whenever I spend a significant amount of time doing a partiuclar task on a computer, I ask myself if there is a way to automate it. Generally, as long as the input to the task is located on the computer, the answer is yes. The kinds of tasks that evade automation are those that have some kind of physical medium as an imput. While there are technologies that could help automate those tasks, it is much more complicated and difficult to do so. For tasks that can be automated, my favorite language for doing so is Python. Python has a wonderfully readable, expressive syntax, and there are an astoundingly large number of libraries and packages available that make the job of automating jobs much easier. One of my favorite simple examples of how Python saved me a lot of time is when I