What makes a good programmer?

Comments

# James Knowles said on November 4, 2005 8:53 AM:

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.

# Travis Owens said on November 4, 2005 9:50 AM:

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.

# Travis Owens said on November 4, 2005 9:55 AM:

I've thought of a 4th reason not to code 'bottom up'. Simply because it's the a$$ end of your solution.

As we all know, coding is becoming more higher level every few years. Higher level means you have to do less of the low end (bit juggling, etc). So if you start your solutions at this point, you're always being pushed up a level when you go to a new language.

IMHO it makes more sense to code top down because while the starting point (the UI) always stays the same, the finish line (the code) always changes.

VS.Net has proven that MS is taking developing to a more visual and less code driven approach. Without question we'll soon be able to write many common applications without ever having to write a single line of code. In fact I expect the next version of Visual Studio (Orca) to have many types of templates (wizards) that you can configure, drop some custom controls and then wire via mini wizards.

# ChrisC said on November 4, 2005 9:59 AM:

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.

# ChrisC said on November 4, 2005 10:10 AM:

Travis - well said, if I had seen your post before mine I would have remained silent.

Although depending on the size of the company and whether it is shrink wrapped it does make sense (in a VERY few cases) to do bottom up coding.

To those that think things should be bottom-up I will point out that with top-down you get agreement on the flow of the UI up front (not just islands of functionality, whose interaction may change b/c some screw-up in marketing didn't put enough thought into the specs and left out or mis-told you about how 2-3 features should interact with each other)

# marklon said on November 4, 2005 10:24 AM:

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.

# Rick Scott said on November 4, 2005 10:36 AM:

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.

# marklon said on November 4, 2005 10:43 AM:

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.

# Jerry Weichbrodt said on November 4, 2005 11:46 AM:

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.

# marklon said on November 4, 2005 11:54 AM:

Ah, and now we reach the crux of the matter.

Yes, the interface needs to be designed early. It is part of the design and can be part of the requirements. However, that doesn't mean that you design the UI and straight away start writing code to back up the UI.

Actually, let me qualify that. For non-trivial applications, you think about the design. Trivial applications generally still work when the design is botched. It just takes longer to debug it.

When a language/enviroment is very easy to use and very high level then simple applications are easier to write. Complex apps are just as difficult because it is the complexity of the problem, not the complexity of the language that you are battling.

# bek okk said on June 7, 2006 4:25 AM:

i think that if we speek about programmation we must know her pragmatic.

# marklon What makes a good programmer | debt consolidator said on June 15, 2009 4:19 PM:

PingBack from http://mydebtconsolidator.info/story.php?id=12832

# marklon What makes a good programmer | internet marketing tools said on June 16, 2009 12:54 AM:

PingBack from http://einternetmarketingtools.info/story.php?id=10826

Leave a Comment

Name (required) 

Your URL (optional)

Comments (required) 

  

Enter Code Here: Required

Remember Me?