Feb 28
David MartinezBest Practices
I am big on flow time. Whenever I am placed in a completely new environment I strive to find a way to achieve the maximum possible flow time.
Here's a great description of this with an eye to human interruptions, which cites De Marco's Peopleware and also makes the connection to ESR's Jargon file.
You should not break without good reason the concentration of a
programmer while they are working. If at all possible, communicate via
e-mail or some other way that lets them react when they have the time.
What follows are some justifications as to why this is so
important.
- Cringe from Crossing a Concentrated Coder, by Lars Wirzenius
But note that this doesn't stop with people, it happens with your choice on technology and tools as well. I think one of the reasons scripting languages have taken off the way they have is that, since they require little or no waiting between changing the file and seeing the results onscreen, they optimize the available flow time even with basic tools (Most of my rails development is currently done with vim and a shell window).
Stop for a few minutes, take a look at your day to day activities and ask yourself when your flow time is typically interrupted by your tools, and whether you can do something to eliminate that interruption. Good tools are designed to reduce or eliminate the flow time interruptions. Bad tools get in the way of that flow time.
Note that if you're only learning to use your current set of tools now, you may find interruptions that are just a part of the learning process - those you can write off as learning time, since they will go away once you master your toolset. But if your process or tool forces you to stop your flow constantly, find a way to improve it or use different tools. You'll be glad you did.
A perfect tool or IDE makes the write-build-test cycle feel so seamless that you forget to think about it, maximizing your flow time.
Finally, note that this optimization is only intended for development time. Your deploy process should still be using build script (i.e., no "building from your IDE" to put in qa or production, please!).
technorati tags: flowtime, programming, agile, flow
Jan 18
David MartinezBest Practices
The problem is that our industry doesn't know how to draw the line between the person dabbling in programming and someone who does it for a serious living. The kid who builds the bird house above would never be hired to build an actual house. Not true in Software Development.The .com era was the perfect example of this. Anyone and everyone was a programmer once they knew HTML. This dillutes how our industry is viewed by the outside world. It keeps us in the 'geeks w/ keyboard' box.
Memoirs of a Bystander - I'm not anit-newbie
A couple of thoughts about Griffin's post (and his prior post):
I am absolutely in favor of providing the basic logic of programming to non-programmers. It can only help them understand why the requirements they produce need to be carefully written.
The "Geeks with keyboards" worldview is a problem of both sides - you won't find anybody under 30 who has never touched a computer keyboard (and very few people under 25 who never had to fix a configuration problem on a computer, even if it was just to run Doom), so that view simply no longer applies.
On the other hand, we "geeks" shouldn't think we'll never need our people skills because we'll always be coding and therefore everyone who can't write kernel drivers or run a windows device driver under the debugger must be a dumb jock. This is an endemic problem in our industry as well.
More
Nov 18
David MartinezBest Practices
How do people think RSS URLs could be secured for use in financial subscriptions?
After listening to Steve and Leo's Security Now #13 podcast on WPA encryption, I came up with this idea.
Comments are welcome.
More
May 18
David MartinezBest Practices
The Pragmatic Programmers have a great article called Cook Until Done, about the different ways you need to convey instructions, making it difficult to get a "cookie cutter" approach to development. Worth checking out..
Mar 30
David MartinezBest Practices
Peter Merholz writes in AdaptivePath about Metadata and classification. Having done a fair of metadata myself, I can relate to this and I'd be interested to see how this evolves..
Mar 09
David MartinezBest Practices
I recently started putting together an archive of old stuff. There's nothing that will humble you more than looking at old code from, say, 5 years ago. 
Wow this is embarrasing .
Jan 03
David MartinezBest Practices
Becoming great at what you do, in development as in other disciplines, involves practice. PragDave has compiled a list of Code Kata for you to practice. More
Apr 06
David MartinezBest Practices
Eric Armstrong has a couple of interesting ideas on how to design programs to accomodate UI's, yet remain unit-testable (is that a word?). More
Dec 17
David MartinezBest Practices
So a few years back, 50-somethings were complaining that companies were only hiring kids. Today, kids are complaining that companies are outsourcing. Bad jokes and useless "poetic justice" speeches notwithstanding, by this time, everyone is aware that "For people who view this as a career, engineering is in worse shape now than it's been in years". What to do?
Through my favorite folks, the "Pragmatic Programmers", I came across their presentation called "How to keep your Job", dealing with just this topic. Very much recommended..
Dec 17
David MartinezBest Practices
This is a good article on how to do defensive coding and defensive unit testing. It includes some figures to convince you of why defensive coding is important, and some good defensive coding tips..
Older Entries Newer Entries
RSS