[OT] How to learn software design

E

Eric Böse-Wolf

I know it is off topic, but maybe someone could
give me a hint for a good book or few tips on
learning software design.

With software design I mean the step from the requirements
to some sort of software architecture.

Yours sincerely,

Eric Böse-Wolf
 
T

tanix

I know it is off topic, but maybe someone could
give me a hint for a good book or few tips on
learning software design.

Ok, I am going to give you some tips.

First of all, to learn software design, you'd better study
what is beauty. Yep, BEAUTY. Believe it or not.

Then get into music. Believe it or not.

Music will teach you the structures unlike anything you are
likely to read in any so calles software book.

Then, try to understand programming as a system.
A program is a SYSTEM, a highly complex interactions,
a higly complex structure, and immensely complex logic.

Every proggram has millions of logical conditions,
every one of which must EXACTLY fit with all others.

Then you learn to state things clear and simple.
Beauty is forever a simplisity, not complications.

If you start inventing the complicated ways of doing something,
watch out, you are in trouble.

Never EVER ignore even the most minute error.
It WILL bite you at the end.

Everything should fit PERFECTLY, 100%.
You can not ignore anything.

The program architecture is the crown jewel of programming.
If you think that optimizing something is where it's at,
think again. Look at your architecture.

"The house, built on the sand is BOUND to fall".

Documentation of your source code and user documenation
is one of the MOST important things.

Never EVER ignore errors. Handle ALL exception conditioins,
conceivable or not.

If you make your algorithm BASICALLY work,
but think that some things may NEVER happen,
think again. Becasue they WILL.

Document your source code in the most minute detail.
You'll never regret that one.

Beyond that, you can take any book you want.

There are few more things I could tell you.
But I am not in the mood.
With software design I mean the step from the requirements
to some sort of software architecture.

Yours sincerely,

Eric Böse-Wolf

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
 
T

tanix

[lots of sarcasm snipped]

So it all depends on experience?

First of all, if you snip the posts like you do,
you'll never become a good programmer.

Cunningness is not what programming is all about.

Secondly, programming is not a craftmanship,
even though many would claim it is.

You can not just memorize some buzzwords and hope to ever
create something that has beauty.

But it looks like you are a hopeless case.
Just another ass licker and a cunning man.
Unfortunately, people like you are the ones that end up writing
code that ends up being used by thousands if not millions of
people and all it is is your sadistic pleasure of torturing
others just because you are miserable yourself
and do not trust your own being
and do not believe there is such a thing as a grandior
of existance.

Too bad, another sadomasochist is born,
just like the most of them are already.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
 
S

Stefan Ram

Andy Champ said:
Mostly, yes. Get a job in a good software shop - not something little,

Some things come together: 0 experience, 1 intelligence (brain power),
2 education, 3 natural language skills, and 4 personal skills.

0 experience: but »experience is useless, unless you can learn from it«,
not everybody can indeed

1 intelligence: an intelligence above average helps to comprehend
abstractions, but it should not be too high so as not to get bored
on the job.

2 education: a certain knowledge helps: patterns, refactoring,
architectures like tiers/MVC, unit tests, revision control systems,
ideas like YAGNI, KISS, DRY, high cohesion/low coupling,
separation of interfaces from implementations, open/closed-principle,
dependency inversion, dependency injection, demeters law,
design by contract, delegation versus inheritance, ...

3 natual language skills: to communicate with team members,
superiors, and customers in meetings and in written documents

4 personal skills: intrapersonal skills: keeping one's poise even
in difficult situations and being able to focus on the job at hand;
interpersonal skills: communicating with team members, superiors, and
customers in a calm and businesslike way, even when under pressure.
 
S

Saeed Amrollahi

I know it is off topic, but maybe someone could
give me a hint for a good book or few tips on
learning software design.

With software design I mean the step from the requirements
to some sort of software architecture.

Yours sincerely,

Eric Böse-Wolf

Hi Eric

Besides what other said, I want to name a book about (object-oriented)
software design.
Recently, I re-read Object Solutions by Grady Booch. It's practical
and great.

Regards,
-- Saeed Amrollahi
 
J

James Kanze

Ok, I am going to give you some tips.

You've raised an interesting point. And it is at least
partially true. However...
First of all, to learn software design, you'd better study
what is beauty. Yep, BEAUTY. Believe it or not.

Study beauty in what way? I'm not even sure you can study
beauty, per se, except from a philosophical point of view (what
is beauty?). Good software engineers do generally have a strong
sense of beauty, but it's not really something that you can
study, per se. Except maybe by reading beautiful code (and
there's not much of that published).
Then get into music. Believe it or not.
Music will teach you the structures unlike anything you are
likely to read in any so calles software book.

That's an interesting point. I once heard that you should never
employ a programmer who didn't play a musical instrument.
Something about the ability to be creative in a structured
environment.

I don't think that studying music is really the most rapid way
of learning software engineering, but I do think that if you
have a feel for music, it's a good sign that you'll probably be
able to become a good software engineer. There is some sort of
a relationship with regards to the most basic skills.
Then, try to understand programming as a system.
A program is a SYSTEM, a highly complex interactions,
a higly complex structure, and immensely complex logic.

Yes. That's why modern software design borrows heavily from
architecture (Design Patterns, for example, which were invented
by an architect).
Every proggram has millions of logical conditions,
every one of which must EXACTLY fit with all others.
Then you learn to state things clear and simple.

This is an essential point. According to Dijkstra, the two most
important skills necessary in order to be able to become
competent are mathematical reasoning and the ability to express
yourself well in your native language. People who can't write
clearly and concisely (in their native language---you can't
always judge by the quality of writing you see here, because
English might not be the author's native language) will never
become competent programmers.

[...]
Documentation of your source code and user documenation is one
of the MOST important things.

Good documentation. Written before you write a single line of
code. Totally aggreed.
Never EVER ignore errors. Handle ALL exception conditioins,
conceivable or not.

It's an error to ignore an error:).

I'm not too sure what your point is. I would say that you must
define what the program should do for all possible input. (But
some of those definitions are more or less implicit. I've yet
to read a design specification which says that the program is
allowed to stop running if the machine is turned off. Although
at a higher level---I worked once on a system with a requirement
that the system continue to perform for up to 48 hours without
any external power. The system was for the electric company in
France, and I've always wondered if they didn't know something
they weren't telling the general public.)
If you make your algorithm BASICALLY work, but think that some
things may NEVER happen, think again. Becasue they WILL.

Yah. Someone will turn the machine off.:) (Seriously, if you
mean what I think you mean, then I agree 100%. Consider all
possible inputs. In a multithreaded environment, consider all
possible thread switches.)
Document your source code in the most minute detail.
You'll never regret that one.

At the lowest level (and I'm not sure that's what you meant),
you can easily over-document. There's nothing worse that things
like:

++ i; // increment i
for ( int i = 0; i < 10; ++ i ) // loop 10 times...

and such. In practice, within the actual code (as opposed to
specifying exactly what the function guarantees), I've often
found the most useful documentation to be that which describes
what you didn't do: why you didn't use the obvious algorithm
(e.g. because it would fail in some exotic case).

But the level of documentation is more what I would consider
part of the process, and not how to design.
 
J

James Kanze

Eric Böse-Wolf wrote:
Mostly, yes. Get a job in a good software shop - not
something little, but one with big teams. 10 years down the
line you'll probably have the idea.

And if you don't know software design, how can you tell if it's
a good shop. But it's true that the best way to learn software
design is to first look at some good designs, then try it,
getting your design and code reviewed by some good designers.

I don't know any books I'd recommend to cover everything,
perhaps because the field is too vast to be completely covered
by any one book. Off hand, I'd suggest Design Patterns, because
it does talk about design, and the snippets of code in it are
excellent examples of well designed code (but it doesn't really
mention any of the architecture issues). In the distant past,
Robert Martin had an excellent book about creating programs in
C++, in which he started from the system requirements, and
worked all the way down to the C++ code. I fear it's a bit too
dated now, with cloud diagrams (rather than UML) and a C++
without exceptions, and IIRC, without even templates. (Very few
compilers supported either at the time the book appeared.)
Also, because it was a book you could actually lift, the
projects considered were very small.
 
J

James Kanze

On Dec 19, 12:48 pm, (e-mail address removed) (Eric Böse-Wolf) wrote:
Besides what other said, I want to name a book about
(object-oriented) software design. Recently, I re-read Object
Solutions by Grady Booch. It's practical and great.

Are there recent editions. I learned OO from it (and yes, it's
an excellent book), but that was a long time ago. The edition I
read still used cloud diagrams, and talked about Ada, rather
than Java, as C++'s concurrent.
 
T

tanix

Eric said:
[lots of sarcasm snipped]

So it all depends on experience?

Mostly, yes. Get a job in a good software shop - not something little,
but one with big teams. 10 years down the line you'll probably have the
idea.

:--}

I like that one.
Yep, I pretty much agree with it.
After about 10 years, you just START getting an idea about what
programming is. By that time, you won't be asking THESE kinds of
questions. You simply won't have time for them.

As for getting a job with a good software shop, I doubt you have
a chance if you ask these kinds of questions.

Just get a job at ANY shop, even the stinkiest one around.
After all, you won't learn much from PEOPLE in that shop any
way you cut it. It is primarily a "job security" issue.
Everyone holds his own "secrets" and never shares it with
others. Otherwise, he becomes replaceable.

So, you will mostly learn from the projects and not from people.
In fact, I did some contract work for the best of the best, and
the "better" they get, the most rotten and unproductive the
environment becomes and the more arrogance you see, and less
of any kind of helping each other to clarify some issues.

So, get a job at the shittiest outlet you can find,
and THAT is where you are likely to find the most help when
you need it.

:--}

You will learn via search engines nowadays.
Very rarely anyone from your own company will be useful to you.
Most people are only interested in bragging about how great
they are and doing all they can to discredit and condemn others.
Again, a job "security" issue, the pittiest and ungliest thing
in the world in the scheme of things, and the most destructive
thing you are likely to find on ANY job.

Good luck.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
 
T

tanix

Some things come together: 0 experience, 1 intelligence (brain power),
2 education, 3 natural language skills, and 4 personal skills.

0 experience: but »experience is useless, unless you can learn from it«,
not everybody can indeed

1 intelligence: an intelligence above average helps to comprehend
abstractions, but it should not be too high so as not to get bored
on the job.

2 education: a certain knowledge helps: patterns, refactoring,
architectures like tiers/MVC, unit tests, revision control systems,
ideas like YAGNI, KISS, DRY, high cohesion/low coupling,
separation of interfaces from implementations, open/closed-principle,
dependency inversion, dependency injection, demeters law,
design by contract, delegation versus inheritance, ...

But what about Truth?
It isn't even in the picture?
Read the end of this reply to get an idea...

Ok, ok. I AM convinced you are an expert. Hopefully, you will
be able to solve the real world issues and do understand all the
buzzwords you spill out here, and, hopefully, you will be able
to talk to humans and be able to explain things clearly and simply
so someone, who does not know some issue, can really learn something
from you and not merely get insulted by your with your "hilier
than thou" pseudo-explanations, that are nothing more than
arrogance and insults.

So...

I have never noticed you before while looking through archives
of this group going back several years.

I just examined the the filters for expers on C++ Goldmine and
you name was not on it. Now it is. If you want your articles to
show up on C++ Goldmine, you just need to keep your name as
Stefan Ram. Your email does not matter.

The rest is automatic. With the next major revision of collection,
you will be presented in expert categories no matter that you
are talking about. There are at least 50 different categories
of issues on these sites.

My suggestion is, if you don't mind, is whenever you describe
something, be as detailed as possible and make sure everything
is self descriptive more or less, without a need for the
reader to dig up several levels deeper on different information
sources in order to be able to understand what you are talking
about.

The bottom line is this:

EVERYTHING you write, from now on, and for a while back already,
becomes a contribution to the global base on information.
In this case, on iformation on C++ related issue.

Now, the thing is, that once you describe some issue in sufficient
detail, providing all the necessary expanations, you, from then
on, close that specifi issue for generations to come.

They do not need to read any other books.
Because YOUR explanation and coverage totally and completely
covered that issue.

I hope you can appreciate what it means.

Also, be careful as to how you format your articles and interleave
your text with the text your are following upon.

Never use tabs.

Indent things only when necessary.
There is no need to indent usenet articles in general, unless
it is absolutely necessary, because it makes it hard to reformat
your articles to make them easy to be viewed via web.

On goldmine sites, poor article formatting is fixed automatically.
But there is a limit to how much things can be changed.
Specifically, because of the issue of code examples/snippets.
Because of those, the article formatting can not be drastically
changed and paragraphds can not be automatically reformatted.
You have to watch your paragraph formatting.

Well, anyway, just remember one thing,
what you write from now on, becomes a global knowledge base
and your articles could be found on ANY issue within milliseconds,
no matter what the issue is.
3 natual language skills: to communicate with team members,
superiors, and customers in meetings and in written documents

4 personal skills: intrapersonal skills: keeping one's poise even
in difficult situations and being able to focus on the job at hand;
interpersonal skills: communicating with team members, superiors, and
customers in a calm and businesslike way, even when under pressure.

Well, unfortunately you forgot one lil thing,
which to me is the biggest thing of it all.
It is called Truth.

I don't see it in your equasion.
How unfortunately.

You see, you can blabber here all your life,
and it is all pretty much meaningless,
unless the most critical criteria in your equasion
is something called Truth.

It is not how "nice" you are.
It is not how much you smile with that plastic smile,
stuck on your face forever, even when it is utterly unnecessary,
or even appropriate.
It does not matter if you know whose arse to lick and how.

But what DOES matter is Truth.
The best definition I have heard so far is:

THAT
WHICH
IS

Simple, ain't it?

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
 
T

tanix

Are there recent editions. I learned OO from it (and yes, it's
an excellent book), but that was a long time ago. The edition I
read still used cloud diagrams, and talked about Ada, rather
than Java, as C++'s concurrent.

A few months ago I read an article on debugging/logging by
Denis Ritchie (one of creators of C language).

What a pleasure that was!

He was presenting his argument regarding debugging vs logging.

What he said essentiall was this:

Lots of people tend to use debugging to fix the issues
with their code. As a result, they tend to get lost in tasty
local scope issues and can not see the whole picture easily.

He suggested to use a well designed logging system instead
of relying on debuggers as much.

Because a well designed logging system will immediately
expose your most critical system level issues,
while debugging will keep you busy for days looking at the
local scope variables or what have you.

What an insight.
It is like listening to 6th symphony of Tchaikovski,
compared to all the blabber all over the place,
which is nothing more than a noise in most cases.

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
 
S

Stefan Ram

James Kanze said:
That's an interesting point. I once heard that you should never
employ a programmer who didn't play a musical instrument.
Something about the ability to be creative in a structured
environment.

http://www.sciencecodex.com/musicia...ir_brains_more_frequently_than_average_people

But one also has to take into account that people from
more wealthy families are more likely to learn an instrument,
so that some of their ability might not be a consequence of
their musical exercises but of their overall better conditions.
See also:

http://scienceblogs.com/cognitivedaily/2009/07/music_participation_doesnt_app.php
competent are mathematical reasoning and the ability to express
yourself well in your native language. People who can't write
clearly and concisely (in their native language---you can't
always judge by the quality of writing you see here, because
English might not be the author's native language) will never
become competent programmers.

»I've found that some of the best developers of all are
English majors. They'll often graduate with no programming
experience at all, and certainly without a clue about the
difference between DRAM and EPROM.

But they can write. That's the art of conveying
information concisely and clearly. Software development
and writing are both the art of knowing what you're going
to do, and then lucidly expressing your ideas.«

http://praisecurseandrecurse.blogspot.com/2007/03/english-majors-as-programmers.html
It's an error to ignore an error:).

If you write a program for your own internal and temporary
use, sometimes you can code as if an attempt to open a file
will always succeed and cope with the undefined behavior,
segmentation fault, or whatever. I have this example in C:

#include <stdio.h>
#include <stdlib.h>

int main( void )
{ size_t buffsize = 16384;
FILE * source = fopen( "source", "rb" );
FILE * target = fopen( "target", "wb" );
unsigned char * buff = malloc( buffsize );
size_t read = fread( buff, 1, buffsize, source );
fwrite( buff, read, 1, target );
return EXIT_SUCCESS; }

Under my test environment, it indeed did copy correctly the
short test file I had prepared. So /it did get the job done
ONCE under these special circumstances/, and if this was all
that was needed, there is no need to write more than twice the
code with all run-time error handling.

(BTW: I am using the above program in my classroom as
an exercise for the students: The assignment is to add
all the error handling and resource releasing to it.)

You just need to know, /when/ to write this »Q&D« style and
/when not/. When you write code for a library that is to be
sold to customers, you should better think about possible
run-time errors and so.
 
I

Ian Collins

Pete said:
I used to play a musical instrument, but I've found that the thing
that's contributed most to my understanding of programming and program
design was law school. That's where I learned to cut through the
distractions to see what's really there.

But didn't that also train you to write arcane and bloated code (form
one who has seen what patent attorneys can do to a simple idea!)?
 
S

Stefan Ram

I know it is off topic, but maybe someone could
give me a hint for a good book or few tips on
learning software design.

http://www.cs.cmu.edu/afs/cs/project/vit/ftp/pdf/intro_softarch.pdf
http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
http://www.laputan.org/mud/
http://www.objectmentor.com/resources/articles/ocp.pdf

Design Patterns by Gamma, et. al.
Refactoring by Martin Fowler
Applying UML and Patterns, 3rd Ed. by Craig Larman

Structured Systems Analysis (DeMarco)
Patterns of Enterprise Application Architecture by Fowler
Object Oriented Software Construction by Bertrand Meyer
Object Oriented Software Engineering by Ivar Jacobson
Code Complete, 2nd Ed. by Steve McConnell
Test-Driven Development by Kent Beck
The Pragmatic Programmer by Andrew Hunt
The Mythical Man-Month by Frederick Brooks
Domain Driven Design by Eric Evans
Working Effectively with Legacy Code by Michael Feathers
 
I

Ian Collins

James said:
You've raised an interesting point. And it is at least
partially true. However...


Study beauty in what way? I'm not even sure you can study
beauty, per se, except from a philosophical point of view (what
is beauty?). Good software engineers do generally have a strong
sense of beauty, but it's not really something that you can
study, per se. Except maybe by reading beautiful code (and
there's not much of that published).

The book "Beautiful Code" is well worth a read.

http://oreilly.com/catalog/9780596510046
 
B

Balog Pal

Paavo Helde said:
I have hunted down and fixed a race condition error (one of my own,
unfortunately) in a multithreaded application which occured only after
running approximately 1 hour on a 16-core machine in parallel. I guess for
a 2-core machine it would have taken years to exhibit the bug.

Indeed, this episode taught me something new about "rare and unimportant
events".

There is a surefire method to produce race condition sraches: arrange a demo
for the top-level boss or most precious client.
 
T

tanix

I have hunted down and fixed a race condition error (one of my own,
unfortunately) in a multithreaded application which occured only after
running approximately 1 hour on a 16-core machine in parallel. I guess for
a 2-core machine it would have taken years to exhibit the bug.

Indeed, this episode taught me something new about "rare and unimportant
events".

Paavo

Well, I'll tell you even better than that.
One one of my contracts on the global voice messaging system
with as heavy traffic as you can imagine, I had a client/server
system. Client was written for windows, server for Unix.

I ran the load tests.
It all worked fine for DAYS, millions of messages exchanged,
and than boom. One funky message had one character wrong...

Try to fix that one, especially considering you have both parts
of network traffic, client end and a sever end.

After that, I am paying much more attention to those things
that are "impossible to happen".

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
 
E

Eric Böse-Wolf

http://www.cs.cmu.edu/afs/cs/project/vit/ftp/pdf/intro_softarch.pdf
http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
http://www.laputan.org/mud/
http://www.objectmentor.com/resources/articles/ocp.pdf

Design Patterns by Gamma, et. al.
Refactoring by Martin Fowler
Applying UML and Patterns, 3rd Ed. by Craig Larman

Structured Systems Analysis (DeMarco)
Patterns of Enterprise Application Architecture by Fowler
Object Oriented Software Construction by Bertrand Meyer
Object Oriented Software Engineering by Ivar Jacobson
Code Complete, 2nd Ed. by Steve McConnell
Test-Driven Development by Kent Beck
The Pragmatic Programmer by Andrew Hunt
The Mythical Man-Month by Frederick Brooks
Domain Driven Design by Eric Evans
Working Effectively with Legacy Code by Michael Feathers

Thanks.

Eric
 
T

tanix

tanix said:
Eric Böse-Wolf wrote:
[lots of sarcasm snipped]

So it all depends on experience?

Mostly, yes. Get a job in a good software shop - not something little,
but one with big teams. 10 years down the line you'll probably have the
idea.

:--}

I like that one.
Yep, I pretty much agree with it.
After about 10 years, you just START getting an idea about what
programming is. By that time, you won't be asking THESE kinds of
questions. You simply won't have time for them.

As for getting a job with a good software shop, I doubt you have
a chance if you ask these kinds of questions.

Just get a job at ANY shop, even the stinkiest one around.
After all, you won't learn much from PEOPLE in that shop any
way you cut it. It is primarily a "job security" issue.
Everyone holds his own "secrets" and never shares it with
others. Otherwise, he becomes replaceable.

There are certainly places where people won't share
information/techniques/etc. with others on their team - but they're
rarely the best people or the best teams. People at the top of their
game generally aren't small-minded - they don't need to be. They know
they're not replaceable how ever much they teach other people - and they
derive satisfaction from knowing how to do things and being able to
communicate that to others. Actually, explaining things to others is
often one of the things that helped them become so good. (For what it's
worth, I've noticed that the really serious people, who you don't expect
to e.g. reply to your emails with a detailed explanation of something,
are often the very ones who do.)

Sounds good. Just like a pipe dream.
Some kind of virtual sw paradise I might say.

Unfortunatly, with MY experience in the Silicon Valley,
doing the contract work on a cream of the crop level
for the biggest and baddest names in the inststry, such as
Intel, HP, Sun, SGI (Silicon Graphics), Amdahl, Hal Computers
(Fujutsu) and few others that is not what I saw.
BY FAR!

I don't want to waste my time or your time on pinpoining the
exact issues as I have not much hope for it. Seen too much
of that stuff and it is way too consistent.
Sorry to tell you that.
It's certainly true that you often learn more from projects than people
- but that's because on a project you're actually *doing* the thing
you're trying to learn, which makes it stick much better. On the other
hand, there are things that you can learn from other people that are
invaluable.

Well, it is an interesting issue and I do not mind spending a
few minutes on it.

Now, to my opinion, being helpful is about one of the most
critical aspects for ANY project.

You see, if I have some issue with something of someone elses
code, it takes a few minutes for them to tell me the tricks,
issues or provide a solution.

But it may take me DAYS if I need to dig ALL sorts of things
on my own. Plus, they can explain the underlying philosophy
of why they did what they did and what kinds of things it
may affect, which may take me MONTHS, if not years, if I
don't know it and have to just keep digging on my own,
not even suspecting some fine points.

But what I saw mostly, is pretty abrupt "answers", that are
not even answers, but the power trips of arrogance and
"holier than thou" attitude.

You see, if they spent just a few minutes of their time,
making sure it is all as clear as a bell, they could have
haved tens of thousands of dollars for their employer,
as hidden costs he does not even expect to have.

And instead, all they are interested is showing you how
"great" THEY are and how "stoopid" YOU are.
Sick trip pretty much.
Interestingly enough, most of them are just morons to me,
that spent a few years on programming and think they are
some kind of software kings. But when you look at their
code, you just want to puke.

One of the most common things used by these conmen
is not to document the code so it could be understood
by others in seconds instead of hours or even days.

Just look at ANY publishe code.

I bet you can make it 10 times more readable by simply
commenting things in place and mentioning the interactions
with other parts of the overall system, others may not
even suspect.

And instead?

Well, vast majority of code I had to deal with is not
even commented. A SUPER ego trip of "holier than thou".

And you are supposed to do what if you have to work with
that code? To be a mind reader or charvoyant?

And these suckers do not even care that it costs millions
to their employees because of all the unnecessary expenses
on maintaining that code, expanding and extending it, or
making it bullet proof.
It's an interesting theory - but a bit dubious IMHO :) You'd be much
better off getting a job at a place with good people *and* a good
information-sharing culture. They exist.

Well, may be.

But the guy is a newcomer more or less.
That is why he is asking this question to begin with.
So, first of all, he simply has no chance of getting a job
with "good sw house". They simply don't hire people like that.
Period.

He prolly won't pass his first interviewer.

As far as "they DO exist", sorry, I have to see one first.
I only recall a couple of people in my entire experience
that fall into that category, and I worked with hundreds.
Regards,
Stu

--
Programmer's Goldmine collections:

http://preciseinfo.org

Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top