It's better to figure it out on our own - we may have some special talent and organizational skill that would make it better.

A good cheat is to meet at look at stuff new, fresh from school with stars in their eyes prospects are doing. End users and developers not constrained by the limitations of a long career are a good source.

Some developers can write a Million lines of sluggish code, where another developer, solving the same issue, would build a "rocket" that solved the problem in a couple of thousand lines.

Projects are about organizational skills and not programming languages or a knowledge base.

Learning the art of structured top down flowcharting (real flowcharting) is not to be understated. A big project typically has a "center" thats where all the input comes together and transacts the [money] output.

For example - a sales order program has inventory and customer and vendor files. But servicing the customer, inventory or vendor files is not the central requirement. The requirement is to take the data from those files and merge them through the UI to create a sales order, an invoice and AR / AP transactions.

So when we think about what we need to do to build a sales order project, we don't go first to the inventory or customer data - we look at what data is needed to transact the invoice (in many cases a sales order can generate an invoice, an open AR item, purchases orders and backorder notices (to fullfil the sale).

So it would seem natural that the first priority would be to understand the where (and how) the transaction hits the road. This is design analysis.

Implementaion however, once the requirement (the "design") is understood, would mean building the services for inventory, customers, etc (derived from our understanding during the design phase) first, so they will be available for us to implement the transaction strategies!

So we design the center first - and write it last - after we write the supporting (or input) services.

THose detailed flow charts are important for independent developers. Learning [how to do] them is tedious (1000Hrs) - but once you've been through it - your noodle gets rewired. If we desire to be more than bench coders or "specialists" (DBAs and Report Writers), we need to learn design. If we want to design big money, big city, downtown powerful bad "A" solutions - we need the detailed understanding that it takes to to prioritize and specify.

That comes from flow-charts. Of course once we learn - we never acyually draw them again - because learning flow charting is not for the purpose of creating documents - but to rewire our organizational skills!

A developer with these skills can sell requirement and design analysis/specfications and get a pretty income just from describing the solution to commercial software companies (or big in house IT shops) without ever writing a single line of code.

The silk purse is knowing how to decipher the problem presented and knowing how to ask the "obvious" questions.

But writing the program and watching it punch through the gears like an Lambergini on steriods is more than money - it's sex (well,not quite, but almost:-)!

>Folks:
>
>Is it just me, or do you people think it's easier/faster to
>just write your own code than to try and figure out
>what another programmer is doing in his/her programs?
>
>I'm sure all of us here are well aware of "programming style."
>I've seen "code that matches my way of thinking," and
>"code that could _easily_ win 'The Obfuscated C programming
>Contest' -- HANDS DOWN! :^) -- held on the Usenet every year.
>
>Fortunately, a friend of mine and I have replaced some dewd that
>seems to think like we do, so reading his code isn't really all that
>difficult; however, it is very time consuming! What do you people
>think? Anyone else out there been/going through this? :^)
>
>Randall