This is what most programmers forgot to learn.

Programmers need to learn a style of development which

helps to reduce stress.

This style should be able to reduce headaches in coding and code

maintenance. It should make the programmer feel confident rather than

feel anxious.

But from my experience, a lot of programmers do the opposite. Some

did this purposely -- to make their code unreadable so nobody would

replace them.

I tell you, those did it purposely are putting their jobs before their

health.

No, they need to learn, first, how to think logically.

I'll worry about stress *after* I get my coffee consumption down to 3 quarts a day.

I did a lot of program maintenance in the past.

After reading their codes and their styles, I conclude that these are

what most programmers have in mind :


Goal ..................................... Importance
----------------------------------------------------
Get program to work ............... 100%
Ease code maintenance ............ 0%
Ease proofing of correctness ..... 0%
Prevention of bugs ................... 0%
----------------------------------------------------



Doing code maintenance for their programs is really a HEADACHE !!!

I'd modify that to:

Get program to appear to work ............... 100%
...

By which I mean that, unless forced to do otherwise, most programmers will do the most minimal unit testing, and will only test the cases they expect to work. The most rudimentary testing by someone else soon shows up the bugs in their code.

I have to admit I was wrong. Having seen the responses on this thread, I conclude that what programmers need to learn first is..

...drumroll...

How to read and comprehend a problem statement or question.

All your answers are very nice things for a programmer to learn, but not what he or she should be learning <b>first</b>.

You are absolutely right about the equal importance of all four points. They make the difference between a good and an average programmer. Usually beginners focus on flashy toolbars, animated icons, colored forms and other useless widgets and feel the urge to start coding. Only someone gifted enough to make one day a good programmer realizes soon enough that the time spent on careful planning, and code designed from the very beginning with additions and extensions in mind, as well as thoroughly tested code, can later pay many times and save a lot of future headaches. Some learn it the hard way, but also some never do.

This may be a little off the subject but...

I've watched this thread for a while and must put my 2 cents in. I'm a developer/architect that's been doing DBA work for the past 2 years. I totally agree with everything that's been posted here. It is very very very hard to find good developers that can understand business needs, design, develop, and implement a solid application. In my experience it seems that most developers have no clue how to design or implement a system. I'll give them develop since anyone can write spaghetti code. And it seems that every programmer labels themselves as architects. Whats up with that. I just interviewed 19 programmers that were entry level java programmers. They all said they were architects. The best architects I've worked with have spent years in the trenches and know a lot about everything. Not just how to draw an object model or code one language.

The best programmers/developers/architects must be able to:
Translate business ramblings into atomic statements of fact.

Then they need to know how to model the entities they have identified.

As to the first question of what programmers need to learn FIRST, I think it should be how to listen openly, without preconceived notions and ideas. Second comes the need to think logically. I would rather hire a programmer who had the ability to truly listen for understanding, but was less perfect in logic than one who was perfect in logic but not good at creative listening. The resulting product might take more maintenance if the programmer wasn't as great at logic but the one who listens will come up with a a product that fits our needs better.

All else being equal, the best will inform the client/employer/manager of various methods and engage her in decision making. Very few programmers understand business needs and realities, and few listen well enough, to fully understand what the client needs/wants. If this is done well, the next challenge is to able to engage the client/employer/operations manager in the decisionmaking about what type of product, such as quickly released spaghetti code vs. more costly code that is slower up front but more versatile and efficient later. Flexibility is needed even in how much the client may want to be involved in such decisionmaking. Such matters often are heavily influenced by the corporate "culture" and history of a place, factors which cannot be understood without listening.

Of course there are many professions where it creates a conflict of interest when in a situation where advising the client how save money is contingent on advising the client on ways to minimize the professional's billable time/dollars. doctors, attorneys, carpenters,plumbers, programmers ... all face this sometimes.

It's analogous to the way the doctor rushes out on his way to the next patient while the patient is left in the dust, having been interrupted while trying to find words to ask one more important question, perhapsthis most important question.

Mark

What programmers need to learn first is ... what you learn when you're exposed to doing maintenance on a whole lot of software that you didn't write, and you're not allowed to simply re-write it.
..
What they should learn second is just how much they really cost the company. Your "fat salary" is someone else's "big expense" and the payback is often questionable. They need to learn how to be cost-effective.
..
The third thing that a programmer should learn is that he or she is responsible for the end result, not the means to getting there. Not everything has to be written all over again from scratch! If the solution can be purchased, and many solutions can, then this is just as legitimate an option as "programming something new," and the programming staff will be just as involved, just as necessary with that as with any other option available to the business.

In many, many years of contract programming (we were the contractors, not "job shop employees"), we reached the point where everything came in by referral. We literally stopped advertising.
..
Furthermore, we saw clearly how referrals work both ways. We made business for many years by following and cleaning up after a certain person... I never met or knew the man... who had a delightful tendency to get jobs two-thirds done and then "not show up for work." He left a trail of tears behind him. And once we'd found the first one of his casualties, and fixed the problems and made the applications work (once he concealed his stuff behind no less than 43 passwords), sure enough those people talked to one another -- commiserating but also telling one another who'd been able to fix it.
..
That fellow finally either left town or skipped it; I don't know which. But it sure was great while it lasted.

Pals,

You were talking about programmers, or coders? See if hte following distinction makes some sense.

Programmer - Focus on writing code as the primary activity of software development, often attached with particular programming languages and parts of a whole software solution. In most cases, junior professionals join in a software house as a programmer (well junior programmer you know).

Software Developer - They are programmers who have expertise on developing a particular type of solution effectively and efficiently. In most cases, software developers are just programmers, may be with a better project experience. In some cases they are known indifferently as software engineers, though, I don't
think Software Engineers fall under these category.

Software Engineer - A software engineer is somebody who applies a formal or structured approach to the development of software. He thinks about correctness, completeness, reusability and workability that matches the end goal for the finished product. A good and short
alternate definition may be - a software engineer is one employed to solve problems by the application of information technology.

So allow coders to do whatever they want except claiming themselves as architects or software engineers. You may fill up the definistion for Software Architect.

Suppose that you wanted a new room added to your house. You agree with a contractor that he should show up at your house tomorrow morning.

Now suppose that this guy shows up, dumps a load of lumber on your yard, and starts cutting and sawing and banging away with a bunch of workmen .. then he wanders up to you and says:

You'd throw him and his workmen and his lumberyard right off your land, wouldn't you? Because you'd know he wasn't really competent no matter how much he'd bluster and blow. You'd know that if he didn't take the time to understand what you wanted, and to draw up a plan, first ... then you could never possibly get what you wanted out of him.

You'd also know that if his idea of "a plan" was to stare vaguely off into space and mumble that he understood, but he couldn't write it down or didn't want to take the time, or if he couldn't simply and plainly explain it to you in terminology you could understand .. then once again you could never expect to get what you want. He's a money pit and nothing more.

Yet this, I assert, is exactly how so many programmers operate. They have more-or-less mastered the tools of the job, but they're not businesspeople and they completely lack the soft skills of managing projects under budget and time constraints (which are, after all, imposed upon any project for precisely this reason!).

These programmers are happy to get $50 an hour without comprehending that "that's a $400-a-day expense to me, and after a month or so of that I could have bought a modest car ..."

There is such an expanse between "knowing how to throw a pot on a wheel" (no mean trick if you've ever tried it) and "running a profitable pottery shop."

sundialsvcs, couldn't agree more. I've seen this in the work world with computers, and (sigh) at home: despite careful screening, a Better Business Bureau member contractor really did a variation on that to my house--and as you said, I threw him out! It's grimly humorous in this forum, now a few years later while still making monthly payments on the truckload of money he wasted.

I guess all of got really very candid... Introspection paves the way .