Graduating soon in Comp Sci. Need real world advice.

[Michael Wojcik]

[Followups should probably be directed to alt.usage.english, but I'm
not currently reading that group, and I feel it's rude to direct
followups to a group in which I'm not a participant.]

)> Well, I saw a block of text and thought, "Does someone with a BS
)> write that way?" Then I decided not to take the bait.
) ^

CBFalconer wrote:

) Here there be missing a period. Just to continue the silly
) picking of infinitesimal nits. The second comma is also highly
) unnecessary. We can leave further comment to the next nit
) harvester.

The first rule of English usage: there are no rules of English
usage. There is no English standard (generally recognized by a
majority of English users). There are only conventions, and they
vary widely.

That said:

I don't know, the question mark may count as a period there.

IME, among people who care about such things, Chuck's usage (with
the period) is currently more widely preferred. This would accord
with both "scientific" punctuation (the question mark applies only
to the phrase in quotation marks, so the enclosing sentence has not
been properly terminated yet) and "natural" punctuation (the
enclosing statement is a declaration, not a question, so it should
end with a period).

There is a style of some popularity - we might label it the "spare"
style - which tends to discourage punctuation wherever it can get
away with it; this is the style which discourages the comma before
the penultimate item in a list. I think it's dreadful, personally.

And the second comma should actually be a colon.

On what grounds? Certainly a colon is not wholly inappropriate,
but it is far more common in contemporary preferred English usage
to separate a direct quotation from the enclosing sentence with a
comma, as Joona did.

Now, as Chuck suggested, it is also common (and I believe becoming
more common) to omit the comma in some cases. This is particularly
true in the "natural" style, which would use a comma only if the
author would pause at that point if reading the sentence aloud. In
effect this generally means that the comma is omitted if both the
enclosing sentence and the quoted phrase are relatively short, and
the enclosing sentence flows into the quoted phrase well.

Of course "flows" and "well" are subjective, as is "relatively
short". Such are the difficulties of describing style - proscribing
it is even worse. This is one reason why "style manuals" like
Strunk & White often do more harm than good. On the other hand,
books about English usage which discuss topics in a reasoned manner
rather than trying to lay down rules, such as Fowler's, are often
both interesting and useful.

--
Michael Wojcik (e-mail address removed)

They had forgathered enough of course in all the various times; they had
again and again, since that first night at the theatre, been face to face
over their question; but they had never been so alone together as they were
actually alone - their talk hadn't yet been so supremely for themselves.
-- Henry James

 

[Willem]

Michael wrote:
)> And the second comma should actually be a colon.
)
) On what grounds? Certainly a colon is not wholly inappropriate,
) but it is far more common in contemporary preferred English usage
) to separate a direct quotation from the enclosing sentence with a
) comma, as Joona did.

You English types are weird. In Dutch, the correct punctuation would
be a colon. What do you use colons for in Engrish then ?


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Sudsy]

Michael wrote:
)> And the second comma should actually be a colon.
)
) On what grounds? Certainly a colon is not wholly inappropriate,
) but it is far more common in contemporary preferred English usage
) to separate a direct quotation from the enclosing sentence with a
) comma, as Joona did.

You English types are weird. In Dutch, the correct punctuation would
be a colon. What do you use colons for in Engrish then ?

Gouda avond! In Engrish we use colon to separate statements which link
to one another: kind of like this. Statements are linked in a different
manner with the semi-colon. Similar to i.e. (id est) vs e.g.
And Engrish people are weird?
Dooeeh! <combined with much horn blowing>

 

[CBFalconer]

Michael wrote:

)> And the second comma should actually be a colon.
)
) On what grounds? Certainly a colon is not wholly inappropriate,
) but it is far more common in contemporary preferred English usage
) to separate a direct quotation from the enclosing sentence with a
) comma, as Joona did.

You English types are weird. In Dutch, the correct punctuation
would be a colon. What do you use colons for in Engrish then ?

I don't know about Engrish (which I assume to be a form of
Japalese), but in English we find colons handy for:

introducing semi-colon separated lists;
smileys;
making assignment statements in the clearer languages;
signifying type in the better languages;
denoting ratios

and so on and so forth

 

[steve]

I think you meant:

Well, I saw a block of text and thought, "Does someone with a BS write
that way?" Then I decided not to take the bait.

not really I wanted to emphasize the "BS", whilst syntactically you are
correct, that is not the point i was making.
Sorry but it just does not look right, unless in reality , education
standards have dropped that much in last 25 years.

perhaps I should have written :

Well, I saw a block of text and thought, "Does someone with a "BS" write that
way?" Then I decided not to take the bait.

;-)

 

[steve]

[Followups should probably be directed to alt.usage.english, but I'm
not currently reading that group, and I feel it's rude to direct
followups to a group in which I'm not a participant.]

Well, I saw a block of text and thought, "Does someone with a BS
write that way?" Then I decided not to take the bait.
^

Here there be missing a period. Just to continue the silly
picking of infinitesimal nits. The second comma is also highly
unnecessary. We can leave further comment to the next nit
harvester.

The first rule of English usage: there are no rules of English
usage. There is no English standard (generally recognized by a
majority of English users). There are only conventions, and they
vary widely.

That said:

I don't know, the question mark may count as a period there.

IME, among people who care about such things, Chuck's usage (with
the period) is currently more widely preferred. This would accord
with both "scientific" punctuation (the question mark applies only
to the phrase in quotation marks, so the enclosing sentence has not
been properly terminated yet) and "natural" punctuation (the
enclosing statement is a declaration, not a question, so it should
end with a period).

There is a style of some popularity - we might label it the "spare"
style - which tends to discourage punctuation wherever it can get
away with it; this is the style which discourages the comma before
the penultimate item in a list. I think it's dreadful, personally.

And the second comma should actually be a colon.

On what grounds? Certainly a colon is not wholly inappropriate,
but it is far more common in contemporary preferred English usage
to separate a direct quotation from the enclosing sentence with a
comma, as Joona did.

Now, as Chuck suggested, it is also common (and I believe becoming
more common) to omit the comma in some cases. This is particularly
true in the "natural" style, which would use a comma only if the
author would pause at that point if reading the sentence aloud. In
effect this generally means that the comma is omitted if both the
enclosing sentence and the quoted phrase are relatively short, and
the enclosing sentence flows into the quoted phrase well.

Of course "flows" and "well" are subjective, as is "relatively
short". Such are the difficulties of describing style - proscribing
it is even worse. This is one reason why "style manuals" like
Strunk & White often do more harm than good. On the other hand,
books about English usage which discuss topics in a reasoned manner
rather than trying to lay down rules, such as Fowler's, are often
both interesting and useful.
[/QUOTE]

Hmm,
next time I should write more along the lines of:


I fink, like this is not a real post, cos the words just don''t looks right,
woot wiv them all being squashed up together?
cos loke my friend has a "B.S"", and he don't right this way.
He also Don't use HIs B.S cos he is a head banger in real good band.
but he also hangs around ' comp.lang.java.programmer' &
'comp.programming' trolling.



steve

 

[Matt]

If u are a job manager, u prefer candidates who are not working now,
or candidates who are working and look for another job? Software
development jobs in general are still not easy to find, they require
more and more experience and different skills sets.

please advise.

 

[Thomas Matthews]

If u are a job manager, u prefer candidates who are not working now,
or candidates who are working and look for another job? Software
development jobs in general are still not easy to find, they require
more and more experience and different skills sets.

please advise.

Eye preefr candates that cn spel n typ rit. 1s that cn spk n
spl English fluently are more likely to be hired than 1s tht
dont. Eye see u hv not changed your typing skills.

Software development requires more than just knowing data structures
and a language (hmmm, sounds like I am repeating myself from
else-thread). For example, if you are writing a database for
an autoparts store, you will need to know about autos. When
developing software for an embedded system, such as a vending
machine or laser printer, you will need to know about
electronics.

Get a job as an intern or an entry level programmer (or even
working at a fast-food restaurant) while you take classes
to learn more about software development.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

 

[Michael Nigohosian]

If you are seeking a pure programming job, chances are, as
an entry-level programmer, you will be doing a lot of
maintenance work, which is very good for you. Projects you
might work on include:

1. Updating a database with new fields or new tables
2. Fixing minor bugs
3. Installing programming tools and
updates on the department’s computers, etc

As a 10-year contract programmer, I have worked on many
projects, recent projects involved:

1) Converting a stand-a-lone Delphi database application to
a multi-threaded, COM server-based application accessible
over the internet

2) Designing a CORBA-based, distributed
application that runs on multiple platforms and serves data
via FTP, internet & phone lines to PC applications, Web
browsers & mainframes

3) Creating a reusable component architecture and
application framework (using common design
patterns) which serve as the foundation for building the
company’s in-house Windows applications

There is a pretty good article, “How to Gain "Real-world"
Experience While You're Still in School” on our Web site,
you might find it useful:

http://www.mwwcorp.com/cgi-bin/getp...com/programming/realworld.html&page=c0m6p14pg

Hope this helps and good luck.

Sincerely,

Michael Nigohosian
Author of the best-selling book:
"The Secret Path to Contract Programming Riches"

--
McGillis, Wilcox, Webster & Co., Inc.
Since 1993
www.MWWCorp.com

Maximize your computer career.
Sign up for your complimentary Contract
Programmer's Career Mastery™ E-Letter
Register here:
http://mwwcorp.com/subscribe/subscribe.html

 

[Gerry Murphy]

I will be graduating soon with a BS in computer science. However, I
feel unprepared for the real world. I've done small programming
projects on my own and did school projects, but I was never exposed to
what goes on in a real world programming environment.. Internships
were not too useful.. mostly web related stuff in html or flash.. not
any robust web or distributed apps were introduced to us. Plus with
all the jobs being shipped outside the U.S. (where I live), i'm
becoming a little disillusioned with programming as a whole now. Of
those that I know that have graduated, many of them cannot find a
decent programming job. Plus many of them don't know anything. My
knowledge is strongest in the Java langauge, I have experience with
C++,C,and PhP. But I do understand programming concepts. I have a non
programming job making a about $33,000/yr. I have been able to live
fine with that. What i'm asking for is some examples of things that
the professionals are doing. I'll appreciate some brief examples of
projects, assignments, or things that are done on a day to day basis
by those who are working. This can be in any language or platform. Any
little tidbit will be useful. I'm gonna try to boost up my skill
level on my own from the insight that I get from you all. I wanna get
my mind out of the limits of the class room and get a feel of whats
happening out there.

I feel for you. I'm not sure I'd advise anyone to major in C.S. these days,
but that's beside the point.

If I could give one bit of advice to every B.S.C.S on the planet it would
be, recognize that pounding out code is 10-20% of software engineering.
The remainder is maintenance. If you want to set yourself apart from
your brethren discipline yourself to document what you do and comment
your code. You'll be doing everyone, including yourself when you go
back to that code 6 months later, a favor.

I wish you the best of luck.

Gerry Murphy

 

[Phlip]

I feel for you. I'm not sure I'd advise anyone to major in C.S. these days,
but that's beside the point.

If I could give one bit of advice to every B.S.C.S on the planet it would
be, recognize that pounding out code is 10-20% of software engineering.
The remainder is maintenance. If you want to set yourself apart from
your brethren discipline yourself to document what you do and comment
your code.

And document & comment by writing unit tests. Any documentation or comment
that requires prose is a missed opportunity to improve and simplify the
code, so the remaining comments are all "// TODO" things.

 

[Stephen Kellett]

And document & comment by writing unit tests. Any documentation or comment
that requires prose is a missed opportunity to improve and simplify the
code, so the remaining comments are all "// TODO" things.

Wrong. Comments and documentation tell what the software *SHOULD* do.

The code tells you what the code does. This is not necessarily the same
as what the code should do.

Relying on the code for documentation means you have no idea what the
code should do. Relying on the unit tests for the same purpose commits
the same mistake. Anyone new coming to the project should be able to
read the documentation and comments to come to an unambiguous conclusion
as to what the software is meant to do. People reading the code and/or
unit tests are reading what the code does. In an ideal world both are
the same. In the real world, they often diverge.

Sadly, it seems not many people understand the subtle distinction
between the two positions, including many project managers.

Stephen

 

[Jim Cochrane]

I feel for you. I'm not sure I'd advise anyone to major in C.S. these days,
but that's beside the point.

If I could give one bit of advice to every B.S.C.S on the planet it would
be, recognize that pounding out code is 10-20% of software engineering.
The remainder is maintenance. If you want to set yourself apart from
your brethren discipline yourself to document what you do and comment
your code. You'll be doing everyone, including yourself when you go

To this I would add: As much as practical, design your code well so that it
is easy to maintain, and when you comment your code, comment it well (not
too much and not too little, etc.).

 

[David]

I feel for you. I'm not sure I'd advise anyone to major in C.S. these days,
but that's beside the point.

If I could give one bit of advice to every B.S.C.S on the planet it would
be, recognize that pounding out code is 10-20% of software engineering.
The remainder is maintenance. If you want to set yourself apart from
your brethren discipline yourself to document what you do and comment
your code. You'll be doing everyone, including yourself when you go
back to that code 6 months later, a favor.

I wish you the best of luck.

Gerry Murphy

I'd say that coding is about 5-10% of what I do. In general, I cover
all the workload for several projects except perhaps the management end
of initiating formal projects and declaring them sellable. I prefer to
let a manager be the buffer between sales and the rest of the company
anyway. Some of the projects are relatively small and only me or a couple
people know most of the details. For larger projects its definitely a
team effort. The image of a 'programmer' these days, especially one
who has a degree in a related field, should be that they can handle
everything from requirements and defining how projects should evolve to
maintenance, release, and support roles. I'd say there are at least
20 hats a person could wear on a given project for its lifetime.

Please, try to participate in all facets of your work. Many organizations
have specific member roles. You have a title such as programmer or database
architect, but you can and should have opinions on all aspects of the
project.

I can always use a good all around developer who can do a little bit of
everything. If you are so talented in one area that that is all you can do,
I may decide you're not worth keeping around. Rather than list a bunch of
items that could be considered, I'll just point to a recent listing of
topics
that an experienced software engineer and hopefully even a recent BS CS
graduate
would be aware of. Take a look at http://www.swebok.org. If you feel
unprepared
perhaps there is some reading and discussion you can do on the subject to
become
more comfortable.

David

 

[Arthur J. O'Dwyer]

Wrong. Comments and documentation tell what the software *SHOULD* do.

The code tells you what the code does. This is not necessarily the same
as what the code should do.

Relying on the code for documentation means you have no idea what the
code should do. Relying on the unit tests for the same purpose commits
the same mistake. Anyone new coming to the project should be able to
read the documentation and comments to come to an unambiguous conclusion
as to what the software is meant to do. People reading the code and/or
unit tests are reading what the code does. In an ideal world both are
the same. In the real world, they often diverge.

This is a great thesis. I've maintained before that while
comments are certainly useful, over-commenting is bad because comments
can only tell what the code was originally /meant/ to do (or was meant
to do at the last time the comments were updated, which in the real
world is often not the last time the /code/ was updated). Thus a lot
of comments add nothing to the reader's understanding of what the code
actually /does/, and thus are redundant. (One major exception is the
block comment that introduces a section, telling what it does in brief.
Natural language can often summarize an algorithm much more readably
than any programming language.)

You say the same thing with a different spin: Comments are rarely
useful to explain what the code /does/; anyone who wants to know that
will simply read the code (and besides, the comments can easily get
out of date anyway). Comments should be used principally to explain
what the programmer meant to do, what he was thinking, and so on; this
is the kind of information that the reader can't get from the code (in
most cases).

Those two positions look almost like opposites to me, but it's
more like a kind of wave-particle duality. Both positions would, I
think, agree that

for (i=0; i < 10; ++i) { /* Loop over 'i' */

is a silly use of a comment, and that

int scmp(const char *text, const char *pat)
{
/*
This function matches the string 'text' case-insensitively
against 'pat', where a vowel in 'pat' implies an optional
following digit. Return the length of the longest prefix
matched, or 0 if the pattern failed to match.
*/
...


is probably a good use of a comment. The only difference is the wording
of the condemnation or the praise.

-Arthur

 

[Michael Borgwardt]

You say the same thing with a different spin: Comments are rarely
useful to explain what the code /does/; anyone who wants to know that
will simply read the code

And rely on undocumented features and bugs, things that can easily
change / be corrected in the next version of the code?

Reading the code is NOT always the best thing to do.

 

[Guest]

If I could give one bit of advice to every B.S.C.S on the planet it would
be, recognize that pounding out code is 10-20% of software engineering.
The remainder is maintenance. If you want to set yourself apart from
your brethren discipline yourself to document what you do and comment
your code. You'll be doing everyone, including yourself when you go
back to that code 6 months later, a favor.

And, when you're outsourced, it'll make it that much easier for the
person replacing you to maintain the code as well!

 

[Robert B.]

And rely on undocumented features and bugs, things that can easily
change / be corrected in the next version of the code?

Reading the code is NOT always the best thing to do.

Think about the 2am panic call to fix a problem in someone else's code after
you've already had a hard 14 hour day and you'll not only appreciate good
comments, but you'll insist on them when you do the code walkthrus.

 

[Phlip]

Think about the 2am panic call to fix a problem in someone else's code after
you've already had a hard 14 hour day and you'll not only appreciate good
comments, but you'll insist on them when you do the code walkthrus.

Pick only one:

A> 2am panic call to fix a problem in someone else's code after
you've already had a hard 14 hour day, but their code has
copious comments

B> 2am panic call to fix a problem in someone else's code after
you've already had a hard 14 hour day, but their code has
wall-to-wall unit and acceptance tests

BTW option B has also been shown to dramatically reduce the incidences of 14
hour days...

 

[Robert B.]

Pick only one:

A> 2am panic call to fix a problem in someone else's code after
you've already had a hard 14 hour day, but their code has
copious comments

B> 2am panic call to fix a problem in someone else's code after
you've already had a hard 14 hour day, but their code has
wall-to-wall unit and acceptance tests

BTW option B has also been shown to dramatically reduce the incidences of 14
hour days...

I agree that the testing is required. However, I've been coding for 20
years in some really intensive environments with huge program, data, and
user bases. You can't test for everything and your example B proves it. If
you've had your "wall-to-wall unit and acceptance tests" and you've gotten
the 2am call, the problem probably won't be easy to find and anything the
program author can do to help will be appreciated. Testing helps, but is
not a panacea for management setting unreasonable completion dates (and tell
me that doesn't happen sometimes in the real world!) or any number of other
reasons that can result in a few long days. No one wants the 2am calls, but
they DO happen so why not help yourself and your co-workers. Spending a
little effort documenting your tracks for the people that follow you doesn't
take much time and helps everyone. It's always seemed to me that people
that are reluctant to document their code generally, but not always, fall
into 1 of 3 categories:
They either feel some strange need to prove an imagined superority to
the people they work with,
or they're not very good at coding and don't want to prove it by
documenting what they've written,
or they just don't understand the problem and can't explain their
supposed solution.

I've found an awful lot of ridiculous and unused code in undocument
programs. If you can't explain it, it probably doesn't need to be in the
program.