How to be a programmer, or at least communicate meaningfully with one.

How to be a programmer, or at least communicate meaningfully with one.
keywords programmer 101 HOWTO hacker programer professional development linux java smalltalk C++

author: totierne Version 0.4
----------------------------------------------------------------------------------------------
TODO:
Note the oracle angle http://www.gecoities.com/FirstStepsInOracle.html
Encourage growth by readers in a twiki.org or www.c2.com wiki style,
is gettin a postcard more likely, Turloch, 33 Elm Mount Close, Beaumont, Dublin 9,Ireland
What insane memes do I want to send on this informative enough carrier wave... :)
------------------------------------------------------------------------------------------------
please write comments on: http://raq437.uk2net.com/twiki/bin/view/TWiki/HowToBeAProgrammerDiscussion

I will not comment further unless you do, this is an extreme approach, you supply on demand but do not do work that is not going to be immediately appreciated as requirements and directions may change...

There are a lot of resources on the web...
-----------------------------------------------------------------------------------------------
Preamble2:
Mention java trail tutorials http://java.sun.com/docs/books/tutorial/index.html

I want to twiki this document..

I should really have mentioned analysis design and documentation techniques such as javadocs, uml and crc cards. Martin Fowlers book on UML has a fairly sane overview of multiple iteration development, and tackleing risk at the start.
----------------------------------------------------------------------------------------------------
Preamble1 on a straw poll around two people it should be noted that:

it was suggested c might not be the best place to start, it enforces procedural programing and there are different ways of thinking about programing one should exercise. smalltalk ((very) object oriented) and lisp(or guile or scheme, functional programing) advocates are usually very good at talking big and pointing out the big picture, but are not very commercial. C enforces low level considerations. Maybe doing a little bit on different languages is not so bad, it makes you better at whatever language you settle on, but you really should have a tool (or two) of choice.

>always go command line first, then maybe graphical once you appreciate what is happening underneath
The additional big bonus of command line tools is they can be automated easily and so the work can become 'scaleable', 1 person can do the work of 100, and boring work need only be done once.
---------------

START HERE FOR REAL _________________________>

The article mentioned in the link describes the environment and gets a programmer away from the solitary and largely useless to everyone lonely coder stereotype:
http://developers.slashdot.org/article.pl?sid=03/01/29/1622207&mode=thread&tid=156
view the comments with 'highest scores first' switched on.

Always have a practical small project [mini application] and goal in mind, the initial one is usually to print 'Hello World' on the screen, using [c or java or shell ...]

Things to learn in order:
some [editor, emacs or vi] some c [K&R is THE book for reference] some java some oracle
look up www.c2.com and the hacker jargon file.
some scripts and os knowledge to tie them together [shell(bash or sh), or perl]
some debugging tools.[always go command line first, then maybe graphical
once you appreciate what is happening underneath]
some extreme programming guidelines

decide on your philosophy to make decisions easier based on higher goals (beauty?) which makes decisions on incomplete information a more managable question of taste.

some source control systems
learn what libraries, frameworks, and applications to use and integrate with.
some jsp if you feel that is the way to go
some j2ee if you feel that is necessary

Then try to get into a real (small) project on
http://savannah.gnu.org/
http://sourceforge.net/

initially logging or confirming bugs, improving documentation.
Then pinpointing bugs, then fixing bugs, then communication with developers in an apprentice mode.

Then try to get into a real (large) project on
http://savannah.gnu.org/
http://sourceforge.net/

start your own project if you feel you have to...

Document everything to get things clear in your mind and to communicate your issues and solutions to yourself and other people.

Then you can talk meaningfully as a business resource for programmers - do not assume you know enough to talk to them about programing to them on a peer to peer basis.... until [maybe] you have mentored another new person (newbie or lamer or script kiddie).