Steve Rowe's Blog

Ruminations on Computing - Programming, Test Development, Management and More

Browse by Tags

Tagged Content List
  • Blog Post: The Complexity Hammer

    I’ve been doing a lot of interviewing lately, especially of college students. There is one tendency I see a that really separates those that are good from those who still have more learning to do. This is the tendency of the good programmers to see elegant solutions to problems and the corollary that...
  • Blog Post: A Taste of Stack Overflow DevDays

    If you missed Stack Overflow DevDays , there is some audio from it available on Stack Overflow Podcast #71.   I wish there was a longer version of this.  It’s only about 1/2 hour of outtakes from the conference, but it is still interesting to hear.  These snippets are followed by a long...
  • Blog Post: Design Patterns Are Not Outdated

    A comment left on my answer to a question over on Stack Overflow has me a little worked up. I've seen this meme come out of programmers more and more and it just doesn't seem accurate. The statement goes something like this, "Design Patterns were only useful because C++ (or Java) was so broken." The...
  • Blog Post: StackOverflow DevDays

    I spent the day at Benaroya Hall for the 1st (annual?) StackOverflow DevDays conference. Overall eight speakers took the stage on topics from .Net MVC to Python to the Google App Engine. The room appears to hold just over 500 people and it was filled to capacity with programmers. There were some vendors...
  • Blog Post: Five Books To Read If You Want My Job

    This came out of a conversation I had today with a few other test leads.  the question was, “What are the top 5 books you should read if you want my job?”  My job in this case being that of a test development lead.  At Microsoft that means I lead a team (or teams) of people whose job it...
  • Blog Post: Some Programming Languages to Consider Learning

    Learning a new programming language can affect the way you think. While most modern languages are Turing Complete and can theoretically all accomplish the same things, that’s not practically true. Each language has its own strengths of expressiveness. For instance, trying to write dynamically typed code...
  • Blog Post: 10 Papers Every Programmer Should Read

    I’m always on the lookout for good reading material.  Michael Feathers over at ObjectMentor has served up a great post entitled 10 Papers Every Programmer Should Read .  I intend to.
  • Blog Post: Check Out Stack Overflow

    I’ve recently become quite addicted to the website stackoverflow.com .  It is a joint venture between Jeff Atwood and Joel Spolsky .  There is an accompanying podcast if you want to hear about the creation process.  The site itself is a question and answer site for programming questions...
  • Blog Post: Improving Task Estimation Accuracy

    In my opinion estimating how long it will take to write a piece of software is difficult if you haven’t done it before and with software we never have.  The more experience you have, the more you’ll have done similar things and thus the more accurate your estimates will be.  To help build this...
  • Blog Post: Using Perl for Mass In Place Editing

    Have you ever wanted to update some text in a bunch of files all at once without a hassle? I had reason to do this recently and turned to Perl for my solution. Once I found the implementation quirks, it turned out to be quite easy. This functionality is pretty well documented, but not for Windows. There...
  • Blog Post: Refactor To Make Immediate Change Easier

    Jeremy Miller gives his reasons for refactoring . He gives two over-arching reasons. The first is "To remedy a deficiency in code, design, or architectural quality" and the second, "To make a forthcoming change to the code easier." I'm very much in agreement with the second, but the first makes me nervous...
  • Blog Post: Design Principle: Don't Repeat Yourself

    There's a design principle I neglected to mention in my initial list but which certainly merits attention. That principle is this: whenever possible, don't repeat yourself (DRY). Put another way, do things one time, in one place rather than having the same or similar code scattered throughout your code...
  • Blog Post: Prefer Composition Over Inheritance

    It's probably about time to bring my "Design Principles To Live By" series to a close. This is the last scheduled topic although I have one or two more I may post. Let's begin with some definitions: Composition - Functionality of an object is made up of an aggregate of different classes. In practice...
  • Blog Post: Don't Blame the Compiler

    It's been a busy week without much time to blog. In the mean time, here's a good reminder. It's Always Your Fault . Jeff Atwood explains why it's always the wrong idea to blame your tools. New programmers especially see something they don't understand and assume that the tools (compiler, OS, libraries...
  • Blog Post: Which Language To Learn Next?

    Once you have mastered one programming language, it is a good idea to branch out and learn some others. Each language is optimized for different things. Knowing multiple will give you a larger set of tools one of which which may solve the problem at hand better than others. Additionally, and more importantly...
  • Blog Post: Classes Should Exhibit High Cohesion

    This is part 4 of my ongoing Design Principles series. When designing the classes in your model, it is important that they each have a specific role to play. Cohesion means joining together to form a united whole. Classes and methods should be highly cohesive. They should have a single function. Methods...
  • Blog Post: Is There Value In Code Uniformity?

    There seem to be two opposing views of coding standards. Some think that they should enforce uniformity in code. Everyone should use K&R braces, leave two lines between functions, and have a space after the if and before the opening parenthesis. Others (like me) think that there is little value in...
  • Blog Post: Arc Is Out

    Over 6 years ago Paul Graham told the world that he was working on a new programming language called Arc. It would be some derivative of Lisp, but otherwise not much was known about it. Graham is the author of 2 books on Lisp and a popular series of essays on topics ranging from programming to startups...
  • Blog Post: Design to Interfaces

    This is the 2nd article in the Design Principles to Live By series. An interface is--for the purposes of this post at least--an abstract definition of the functionality of an object. It is the signature of a class divorced from its implementation. Think of it as the list of methods (and properties...
  • Blog Post: Prefer Loose Coupling

    This is the 3rd post in the Design Principles to Live By series. Coupling is the degree to which software components depend on each other. Tight coupling is a high degree of dependence. In practical terms, it means one component needs intimate knowledge of how another works in order to successfully interact...
  • Blog Post: Encapsulate What Varies

    It took a lot longer than I expected but this is first installment of my Design Principles To Live By series:  Encapsulate Variation.  This is a quick tour through the principles behind the design patterns.  Following these allows will allow you to make the "right" choice in...
  • Blog Post: Design Principles To Live By

    Object-oriented design and design patterns can seem complex. There are a lot of ideas and cases to consider. However, there are a handful of principles that, if followed, will result in code that complies with most if not all of the patterns. These are the patterns behind the patterns. In my mind, there...
  • Blog Post: The Need for a Real Build Process

    Jeff Atwood at Coding Horror has a good post about how " F5 is not a build process ." In it, he explains how you need a real centralized build process. F5 (the "build and debug" shortcut key in Visual Studio) on a developer's machine is not a built process. At Microsoft, we have a practice of regular...
  • Blog Post: Don't Blame the User for Misusing Your API

    A conversation the other day got me thinking about interfaces. As the author of an interface, it is easy to blame the users for its misuse. I think that's the wrong place for the blame. An interface that is used incorrectly is often poorly written. A well-written one will be intuitive for most people...
  • Blog Post: A Little Design Advice

    A recent article on InfoWorld lays out "The eight secrets that make Apple No. 1." There are many things in the article that I disagree with but there are two that stick out as good advice for software design. The first "secret" is that engineering supports design and not the other way around. Traditionally...
Page 1 of 3 (71 items) 123