typos

content/journal/2015/restraint-and-the-right-thing.html

@@ -0,0 +1,76 @@
+---
+title: Restraint and the Right Thing
+description: YAGNI
+created: !!timestamp '2015-6-24 22:29:00'
+---
+
+In computer programming, there is this idea called the Right Thing - that for a
+given programming problem there is one, and only one, correct solution. This
+idea is mostly obsolete, but many programers still believe it.
+
+According to Steven Levy in the book [Hackers](), the idea of the Right Thing sprang
+up at MIT in the 1960s. At that point, the idea was valid, but there are some
+points to note about the programming environment at the that time and place:
+
+1. Everyone had similar technical abilities
+2. Everyone was working on the same architecture
+3. Memory and processing power were extremely limited
+
+Given that environment, it is easy to see how one could conclude that there was
+only one correct way to solve a given problem. If you only have a kilobyte of
+memory, you cut corners to get everything to fit. If your CPU is running in the
+kilohertz, you make every clock cycle count. And so you ended up with programs
+that were as short and clever as possible to make the best use of the limited
+resources. This was okay, because the programming group was a monoculture,
+and your peers could be expected to understand and appreciate your cleverness.
+
+But those constraints no longer apply. Let's constrast that environment with our
+current one:
+
+1. Everyone has different technical abilities
+2. Everyone is probably working on the same architecture, but may be working on
+   different architectures
+3. Memory and processing power are vast, readily-available, and cheap.
+
+Every constraint placed on the early programmers is now gone. Software teams can
+choose how to optimize their programming environments. The Right Thing is now
+relative. Maybe you're working on a problem that takes a lot of processing
+power, so you optimize for that. Maybe you deal with terabytes of data, so
+memory and space are still constraints. If you work with embedded systems, you
+will have to deal with both.
+
+Realistically though, most of us are web developers working on problems that are
+neither new nor novel. We take data, store it, and return it at a later
+time. That's it. Given that environment, the Right Thing is different. The
+biggest cost on a software team is the programmers themselves. Therefore, care
+should be taken to write code that is easy to understand and easy to
+maintain. If that is done, the pool of programmers available is as large as
+possible. Clever code requies clever programmers to untangle, and they often
+come at a price.
+
+In the first draft of this essay, I wrote that "dumb code was the new Right
+Thing."  But this is not correct. Dumb code is easy to write, but not very easy
+to maintain. It's what you write when you are a novice, or when you need a quick
+script that will run once. Clever code is worse. It is difficult to write and
+even harder to maintain. (And often, the programmer is not as clever as they
+think.) The balance (as always) is somewhere in the middle, and this is where
+restraint comes in. You write dumb code as a novice, clever code when you know
+just enough to be dangerous, and maintainable code when you have the knowledge
+to be clever, but the wisdom to restrain yourself.
+
+Programmers are right up there next to evangelicals when it comes to being
+dogmatic and bull-headed. There is a reason that famous programming arguments
+have been called "religious wars." We learn design patterns. We learn about
+objects, factories, Single Responsibility and Tell Don't Ask. We learn a slew of
+other acronyms. And we try to use all of this any chance we get, because it's
+the "Right Thing." But that's academic. Anyone in industry is not being paid to
+be academic. The CEO is paying you to (1) ship and (2) not cost them an arm and
+a leg when you decide to leave but your code stays.
+
+I'm not suggesting that we throw all the design concepts out the window. I think
+many of those ideas can still be useful. But we have to be aware that every
+pattern or abstraction we introduce is one more roadblock in the way of that new
+programmer trying to understand our code. So if you decide to introduce that
+roadblock, you'd better have a good justification for doing so. And you know
+that fancy [ServiceLocatorFactoryBean](http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/beans/factory/config/ServiceLocatorFactoryBean.html) you've been working on? You're not going to
+need it.

content/journal/2016/big-red-button-pt-2.html

@@ -1,7 +1,7 @@
 ---
 title: The Big Red Button - Part 2
 description: TURN YOUR KEY SIR
-created: !!timestamp '2016-05-01 13:23:00'
+created: !!timestamp '2016-05-28 13:23:00'
 ---
 
 [A long time ago](/journal/2013/big-red-button-pt-1) I got some hardware from a
@@ -79,11 +79,12 @@
 }
 {% endsyntax %}
 
-Debouncing works the same way. If the button has changed states remained in the new
-state for a certain amount of time, you can safely assume it was actually pushed.
-Because the button is a mechanical device the connection when it is first pressed
-or released may 'bounce' open and closed. You need to account for this in the
-program, otherwise there may be intermittent bugs.
+Debouncing works the same way. If the button has changed states and
+remained in the new state for a certain amount of time, you can safely
+assume it was actually pushed.  Because the button is a mechanical
+device the connection when it is first pressed or released may
+'bounce' open and closed. You need to account for this in the program,
+otherwise there may be intermittent bugs.
 
 {% syntax c %}
 long lastDebounceTime = 0; // last time the input was toggled