Fog Creek Software
Discussion Board

How to be a Programmer

Here's a link to an interesting and thought provoking essay by Robert Read.  Stumbled over the link while reading my current issue of Dr. Dobbs Journal (Apr 2003, p8).

Paul Wendell
Tuesday, March 11, 2003

beg pardon

Paul Wendell
Tuesday, March 11, 2003

The idea of the essay is nice... but it lacks from bad consistenty and is generally poorly written.

Someone with good writing skills could make a very fun-reading book on this subject.

Eli Bendersky
Wednesday, March 12, 2003

Paul, nice post!!!!!!!!!!

I haven't had a chance to read the entire article yet, however, I feel compelled to paste and comment on two paragraphs from the article's Introduction. I am doing this primary because I just finished reading the "Reluctance to Learn" post that was recently made here. The comments in that particular post have me wondering if I was wrong about the "developer shortage" that employers have been whining about for years. Maybe there really is a shortage of people capable of developing customized software solutions for small, medium and large businesses?

Imo, it seems as if there are currently far too many employed programmers who feel that software development in the business world is all about writing lots of source code and that the only thing they need to do to stay employed is learn several programming languages/technologies. I believe these people (as opposed to the VB developer who has no interest in learning the C programming language) are the ones who don't have the willingness to learn more about their trade.

In the business world learning more about your trade typically means learning as much as you can about all aspects of the software development process and learning to cope with the fact that maintenance work is a neccessary evil that you be required to perform throughout your technical career.

"Writing computer programs is important and takes great intelligence and skill. But it is really child's play compared to everything else that a good programmer must do to make a software system that succeeds for both the customer and myriad colleagues for whom she is partially responsible."


"This is very subjective and, therefore, this essay is doomed to be personal and somewhat opinionated. I confine myself to problems that a programmer is very likely to have to face in her work."

Business software development (as opposed to commercial software development) is what I get paid to do and it truly is a very subjective field to work in as a software developer. The so called "non-technical things" that many programmers apparently don't feel they need to know anything about are where I spend the majority of my free time learning how to do better. In other words, it has been a long time since someone gave me a technical spec or a requirements document and told me all I have to do is start coding!

As strange as this may sound to some, I believe the act of writing code to be the most "concrete" or the least subjective aspect of what I do for a living. I suppose this is the reason why so many developers seem obsessed with writing/talking about technology and certain programming languages. That is, the act of writing code is one of the few aspects of software development that developers truly have complete control over.

Are most developers who work in a business enivronment deluding themselves by thinking that this is ONLY thing they get paid for doing well?

The primary reason I read Joel's articles and visit this forum is because I believe this guy simply gets it! That is, he seems to understand the differences and similarities between commercial software development and developing software for a particular business.

One Programmer's Opinion
Wednesday, March 12, 2003

Thanks, I see myself giving this to people who are seriously curious about what programmers think and do during their day.  Evenhanded and yet (I think) subtle.

anonymous.. thanker
Wednesday, March 12, 2003

I agree with the fact that just being a good programmer isn't enough to make it past being an intermediate level developer, but the way this guy puts it, makes me think he's making up for a huge inadequecy.
  Writing good code and comming up with good design is NOT easy, despite what we all say.  Its very challenging to come up with a clean, elegant, scalable, modular solution in a given timeframe.  98% of developers can't do this.  I'm guessing this guy can't.  I'm not downplaying the fact that its good to learn how to develop software thats useful for the business, but theres no point if you can't make your code excellent in the first place.

Vincent Marquez
Wednesday, March 12, 2003

The table of contents would make a great job description ;)

Paul Wendell
Wednesday, March 12, 2003

"Its very challenging to come up with a clean, elegant, scalable, modular solution in a given timeframe."

I think the point is, that may not be where your bread is buttered. What does it matter if a program is all that, but people don't find it all that useful? I worked with a banker once, who was pretty good at writing lotus and office macros. Certainly no coding prizes, but he made tons of them for all kinds of daily tasks and they were shared all around the office. I remeber thinking they looked a bit amature in places...

Then during y2k hysteria, I had to go around to branches all over the province, and one thing I noticed on almost every computer were a few of his macros. The guy probably saved the institution millions in the long run, not just in time, but avoiding bad data entry etc. Compare that to the very robust, expensive, modular bulletproof y2k test disk I was inserting into each machine, I think you get my point...

The majority of what can be automated are tiny tasks that are hard to even notice as tasks unless you are well steeped in the enviroment. Certainly not worth a grand study and solution, but they do add up quickly and get used widely. For almost every task (other than perhaps coding the grand solutions) I would take someone great in the field and pretty good at coding over someone the opposite.

Robin Debreuil
Wednesday, March 12, 2003

On page 32, sec 6.6:
"There are different interviewing styles. Some are torturous, designed to put the candidate under a great deal of stress. This serves a very valuable purpose of possibly revealing character flaws and weaknesses under stress."

I find this interesting.  Don't people who use this, screw up the morale of new hires?

Wednesday, March 12, 2003

I suspect that the more tortuous the interview, the happier people will be if they get the job. It's a lot more pleasant to tell yourself "Wow, I got the job after that terrible interview, they must think I'm great" than to think "I got the job, but I'm working for a bunch of sanctimonious *******s who clearly enjoy torturing candidates". People will go to incredible lengths to deceive themselves that their new company is great. After all, they just accepted a job there!

The book "Influence, Science and Practise" has some insights into this phenomenom. Makes an interesting read. Thanks to Joel for the recommendation.

Anon this time, sorry
Wednesday, March 12, 2003

All stresses are not the same.  The stress of taking a final exam in college is different from the stress of giving a speech in front of a large crowd, which is different from the stress of apprehending a criminal, which is different from the stress of a torturous job interview, which is different from being on the free-throw line in a basketball game with 1 second left and a 1-point difference in the score.  The ability to overcome one type has little or no indication of how one would handle the others.

The stress that programmers are likely to face consists mainly of deadline pressures and reacting to system crises.  If you want to test that type of stress, give them something to design or code in an hour which is nearly impossible to complete in such little time (while bearing in mind that they aren't really expected to finish it, but you are interested in seeing how far they get and how they handle the pressure).  But if your stress test is based on grilling them with a panel of aggressive questioners, all you're really testing is their ability to handle being grilled by a panel of aggressive questioners. It may be important for a lawyer or salesperson or CEO to endure that type of stress, but programmers spend much less than 1% of their days in situations like that.  If that is how you hire programmers, you'll send away the actual good developers while hiring masqueraders who are good at politics.

T. Norman
Wednesday, March 12, 2003

T.Norman... that was a really great point.

As to "How to be a Programmer"... well as the ONLY programmer in my organization, I'm expected to not only write the code but to understand usibility, program design, program domain, and every other part that goes into making our software. There is one other person who does the lion share of user interaction design... but other than that it's just me. Talk about stress! ANY problem that arises, it's left up to me to find the solution. There is nobody to discuss it with, nobody to help, and nobody to run my possible solutions by. Try to interview someone for that... sheesh!

Wednesday, March 12, 2003

*  Recent Topics

*  Fog Creek Home