Over the years I have noticed a habit among some developers that I’ve come to call Aphorism Driven Development. Many best practices are taught and remembered through the use pithy statements. Although these statements are easy to remember, they can’t capture the full context and connotations of the practice in question. If someone never learns… Read More »
I realize that the title of this post is likely to generate a lot of noise, but it’s a subject I have been thinking about for much of the last two decades. Over ten years ago, I wrote a post questioning the everything is an object approach several languages seemed to be taking. That post… Read More »
Long ago, I posted a short note On Proficiency where I noted four things I believed were needed to become proficient at an activity: aptitude, interest, knowledge, and skills. My experience learning software development took a different route than many developers today. I started development in very small teams (1-2 developers). I had actually been… Read More »
In a recent blog post, I suggested that the most important result of a developer writing code is the understanding of the problem/solution. Most of the reason for suggesting this change in focus is to help people understand that throwing away code that no longer serves a purpose is a good thing, not a loss.… Read More »
I recently heard an interview with Martin Fowler on the Ruby Rogues podcast. He pointed out a few things about the process of refactoring that I haven’t thought of in a while. Based on that interview and what I’ve read and learned elsewhere about refactoring in the past few years, I decided there are a… Read More »
It’s not a big surprise that most programmers feel that the most important result of writing code is the code itself. Other people might argue that while the code is important, other things are more important: Results of the execution of the code Money made by selling the program Business value realized by running the… Read More »
Every bit of code we write is the result of trade-offs. Some seem like no-brainers: what language to use, which paradigm to use. Others are more subtle: how important is speed/maintainability/memory, fail fast or never fail, fix a bug quickly or rewrite to prevent that class of bugs. One of the big trade-offs is between… Read More »
There are a few reasons that Best Practices get specified in a profession. Provide standards for judging proposed solutions. Provide cover for unforeseen circumstances. Provide a starting point for discussions to improve the state of the art even more. Help more junior people make better decisions before they fully understand the field. Applied to software,… Read More »
In the last post (Coding Style: Terse vs Verbose), I laid out some of the arguments for and against a verbose coding style and a terse coding style. Although, I didn’t delve deeply into what I meant by these styles, I hoped the details were less important than the general feel. However, by the end… Read More »
The practice of developing software depends on a large body of arcane knowledge and skills. Almost all of this knowledge is based on logical principles and built up to the point that we can do amazing work. Because programming has it’s roots in applied mathematics, there is an impression that programming is also a logical,… Read More »