What makes a good programmer?

This subject was being debated on a newsgroup that I subscribe to. I have been the matter some thought. While I am not personally a good programmer, I know quite a lot of people who are.

Here are some suggested rules that I would offer.

1. Except for video games programming, starting with the UI is the wrong place. Marketing like a UI. For many people in Marketing, if you have the UI then you have the application. After all if it looks right then what is there left to do? We all love Marketing folk. They see the world in such a different way.

2. Think in terms of data flow. This is obviously appropriate in applications programming but it is true of systems programming as well. A resultset is clearly data but then, so is a device context or a security descriptor.

3. Simple is better. Go for an efficient algorithm but don't micro-optimise. It is rare that you will need to do so and it will generally only be for a critical path.

4. Consider carefully if your application needs to be performant or scalable. Some things need to be both and that is hard to do. Having a scalable app when you need a performant one is not good. Having a performant app when you need a scalable one is terrible.

4. When implementing a module, consider how to test it. Most people do not like creating test harnesses. I can understand that. It is very dull. It also takes time that could otherwise be spent on developing code that you can sell. However, this fundamentally ignores real world economics. Most applications spend a lot longer in their maintenance phase than their development phase. Very often, this costs more than the initial development. Profit = income - cost. Reducing the cost a lot can be better than increasing the income a little. Unless your time costs nothing, this makes many accepted practices of debatable value.

5. Do not confuse activity with progress. I had one manager in a previous company who used to get worried if he couldn't hear keystrokes because that meant that we were not working. I am a big fan of thinking about any non-trivial problem for at least an hour. Some big problems need a couple of days. Thinking seems to bear a lot of resemblance to doing nothing but is much harder work.

6. Record at least the bare minimum of information. You don't have to write War and Peace but the design decisions and the reasons behind them should never be lost. Self documenting code is a nice idea but assume that the person reading the code is stupider than you. That person could well be you, dragged out of bed to fix a bug 3 years later after a really good party. Ok, most programmers don't get to go to really good parties but we can dream.

7. There are two sayings: "Never test for an error condition that you don't know how to handle" and "It was hard to write so it should be hard to understand". Neither has any validity.

8. Do not rely on undocumented anything.

9. When reviewing code, leave it a couple of days after writing it otherwise you will read what you thought that you wrote. If you can't do this, best to get someone else to review it.

10. Remember Dykstra's advice. If you can not clearly explain to someone what your program is going to do then you are not ready to start writing it.

Signing off

Mark

Comments

• Anonymous
  November 04, 2005
  I totally disagree...Some us do get to go to good parties ;-)
  
  I would add that programmers that spend more time intially listening then coding also tend to write better code.

• Anonymous
  November 04, 2005
  While ones choice of developing from "bottom up" or "top down" may be a personal choice, I'm dead against the "bottom up" concept, which is what you are proposing in #1.
  
  Perhaps I'm biased because I started as a graphic (web) designer and went into programming, so it's always natural to draw up how something looks and write functionality afterwards.
  
  IMHO you defeat your statement by saying that UI is marketing. There are 3 major reasons why you want to create the UI first and then the program behind it.
  
  First, when somebody specs out an application and defines all the features, creating the UI first allows you to have the look of the application and can get instant feedback from your customers. Since your customers are not programmers, they don't care about what's "under the hood", they only care how it looks. Once everything looks fine to them, now it makes sense to code. This is especially important from my experience when a manager "wants to see what you're working on" and non technical people will understand a bunch of screens of UI than pages of code. And with the UI in place, if you need to give a preliminary demo, you can write some placeholder code which emulates functionality and show people, and write the actual code later.
  
  Secondly the human brain works on a visible level better than an informational level (that's why you can see an apple is an apple in an instant but it takes you a long time to do simple math like 48 x 37, where as a computer performs these tasks reverse of the human brain). Seeing the UI helps you properly understand the scope and function of the application. It allows you to see related features that can be coded in a re-usable state that you might have not seen while coding.
  
  Last I wanted to add I've found I'm much more production by also coding in a 'top down' approach where after I create the UI, I have Visual Studio create all my button events so I have a bunch of place holder code, and create placeholder methods that they call. I then document what these things will do and with all the top 2 layers of methods I can begin any re-factoring and document them. At this point I have nearly every method needed to write the application and I begin coding these methods one feature at a time. This is the third advantage because once I hit this stage, anybody can walk into the middle of my project and pickup the code without having to learn anything because they have a plethora of English named methods that are well documented and all they have to do is write the code to perform this action.
  

• Anonymous
  November 04, 2005
  The comment has been removed

• Anonymous
  November 04, 2005
  That's nice, but #1 contains a huge flaw. Most of the people who do apps which have a UI must to do it first - because the users don't know what they want, but they know what they don't want when they see it.
  Throwing away the demo app is a huge waste of time, if you don't agree with that I know how you feel because I used to feel the same way - see joelonsoftware.com (et al) for many articles supporting my new opinion.
  
  The rest is really good, especially good description for #6 (dragged out of bed to fix a bug).
  
  #5 (Activity) In 1997 I worked at a place where one of the programmers used his microphone to record keystrokes and would play that through his speakers whenever he was either designing or drinking (and yes I mean beer and yes at work); he was the last one laid off before the company closed its doors.

• Anonymous
  November 04, 2005
  The comment has been removed

• Anonymous
  November 04, 2005
  Ah, debate is a good thing. Thank you.
  
  I think that we have a fundamental disjoint here. Starting with the UI is not top down programming. Thinking about the information flows isn't bottom up programming. Let me give an example.
  
  I am writing a patient record reporting system (I really am) and the specification that I got was a bit of paper with a rough sketch of what the desired output would be. I went and asked some questions about what was stored where and how the process would be done if it were a manual operation. That was a requirement document.
  
  Then I considered what the information flow was and where the boundaries would be. I considered what processing the data would go through. That was my design overview.
  
  I then designed my data structures. After that, I roughed out my class structures. Then I started coding.
  
  So, I may have explained myself badly but I don't think that this would be classed as a bottom up design but I have often seen people jump in to the coding as soon as they had a UI. The result was rarely ideal.
  
  Of course, I am not a good programmer and you may prefer other techniques.
  
  Actually, there is one place where you HAVE to start bottom up - Bootstrap Bootstrap compilers. It has been a very long time since I wrote one of those.
  
  Thank you for the contribution, guys.

• Anonymous
  November 04, 2005
  Chiming in to agree with the above posters about UI first.
  
  Also, regarding the part of #7 where you said this is bad:
  
  "Never test for an error condition that you don't know how to handle"
  
  ...I would have to disagree. If the error condition is a return code, then this statement is correct. However, if the error condition is a thrown exception, then this contradicts good programming practice.
  
  You should NOT catch an exception unless you know how to handle it or are in the UI layer. I know that is also MS's stance on things as well because I used to have code like this:
  
  try
  {
  //something
  }
  catch(Exception ex)
  {
  //handle all exceptions
  }
  
  ...but then I ran FxCop and it complained about catching Exceptions.

• Anonymous
  November 04, 2005
  Ok, we will have to agree to disagree about UI first.
  
  As for exceptions, rethrowing an unknown exception is handling it - but catching an exception and checking for an error are not quite the same thing.

• Anonymous
  November 04, 2005
  I don't know if I'm a good programmer or not, but I have given it a fair amount of thought. I think you do have to think about your interface fairly early on in the development process. I had a professor once who talked about whipping up prototype interfaces and getting feedback from the prospective user. That sounds like a very valuable tool. However, I think you need to know more than just what the user wants the application to "feel" or "look" like. Without a pretty in-depth understanding of what the inputs and outputs are (and how they interact), you could literally program yourself into an interface that would be impossible to make work. In most simple terms, you have to specify all the necessary inputs before you can produce a suitable output, I think. Perhaps that means starting at the middle layer and working one's way upward and downward simultaneously? I'm not sure, but I don't think I would rush into building an interface before I had a pretty good mental model of what lurked behind it.

• Anonymous
  November 04, 2005
  The comment has been removed

• Anonymous
  June 06, 2006
  i think that if we speek about programmation we must know her pragmatic.
  

• Anonymous
  June 15, 2009
  PingBack from http://mydebtconsolidator.info/story.php?id=12832

• Anonymous
  June 15, 2009
  PingBack from http://einternetmarketingtools.info/story.php?id=10826