[OT] How to learn software design

[tanix]

[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.

Bad advice. In big companies, people are on their own, and nobody to
guide them. At least that's my experience in a big company.

Yep. The same here.
In software business, you are on your own no matter how you cut it.
It is probably the most vicious kind of business there is.
The most mind-intensive, the most exploitive.
Sure, if you are on some non-profit project, that is a totally
different game. And if you are doing it all for fun and your own
entertainment, then yes, you can have as "good" of a design, as
your brain capacity and comprehension skills allow, and about
the most significant aspect of it is courage, courage to be
yourself and not merely repeat like a parrot what some book says
or what some "expert" advices.

You are on your own in this game of life, believe it or not.
You came here alone when you were born.
And you will leave alone when you die,
and thank to god they will even let you alone when you die,
cause they may stand by your bed and demand you sign some
stoopid paper so they get the benefits of your life,
fighting with each other who gets the biggest piece of the
pie. Those suckers are not even necessarily going to even
let you have the last joyous and extatic moments of life,
the moments when you leave this plane.

:--}

--
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.

 

[Michael Doubez]

[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.

Bad advice. In big companies, people are on their own, and nobody to
guide them. At least that's my experience in a big company.

Well, that's true for one's whole life Don't wait for somebody to
feed you.

But big compagnies may have veterans and hire interesting people and
consultants from which you can learn. Some will teach you freely; for
others, use a peephole

 

[Vladimir Jovic]

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.

Bad advice. In big companies, people are on their own, and nobody to
guide them. At least that's my experience in a big company.

Well, that's true for one's whole life Don't wait for somebody to
feed you.

Give a man a fish and you feed him for a day. Teach a man to fish and
you feed him for a lifetime.

But big compagnies may have veterans and hire interesting people and
consultants from which you can learn. Some will teach you freely; for
others, use a peephole

I agree with fanix on this matter (in his other posts on this tread) :
people in big companies are generally not helpful. They will answer your
question, but will hide details.

 

[Michael Doubez]

Andy Champ wrote:
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.
Bad advice. In big companies, people are on their own, and nobody to
guide them. At least that's my experience in a big company.

Well, that's true for one's whole life Don't wait for somebody to
feed you.

Give a man a fish and you feed him for a day. Teach a man to fish and
you feed him for a lifetime.

In the first place, why would you expect anybody to give you a fish or
to teach you how to fish ?

Even the more optimistics know we are in a rotten world.
(The more pessimistics say there is no way out.)

The answer would then be: if all else fail, see how others fish and do
the same.

I agree with fanix on this matter (in his other posts on this tread) :

AFAIS tanix is a troll and IMNSHO with a shallow depth of
understanding on the issue.

people in big companies are generally not helpful. They will answer your
question, but will hide details.

Or they don't have the will, the formation or the time to train. IME
if you come up with questions showing that you did care and broke a
bit you teeth on the problem, you'll find someone to help you get
through. And, if you don't ... at least you have what you got by
yourself.

 

[Vladimir Jovic]

Andy Champ wrote:
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.
Bad advice. In big companies, people are on their own, and nobody to
guide them. At least that's my experience in a big company.
Well, that's true for one's whole life Don't wait for somebody to
feed you.

Give a man a fish and you feed him for a day. Teach a man to fish and
you feed him for a lifetime.

In the first place, why would you expect anybody to give you a fish or
to teach you how to fish ?

Because I was naive and expected too much
I could have said more, but is already way OT

Even the more optimistics know we are in a rotten world.
(The more pessimistics say there is no way out.)

Only one way out, and it awaits all of us

The answer would then be: if all else fail, see how others fish and do
the same.


AFAIS tanix is a troll and IMNSHO with a shallow depth of
understanding on the issue.

Not completely. Most of his posts are long and full of bitterness, but
you can find good points there.

Or they don't have the will, the formation or the time to train. IME
if you come up with questions showing that you did care and broke a
bit you teeth on the problem, you'll find someone to help you get
through. And, if you don't ... at least you have what you got by
yourself.

I guess you are right.



Anyway, to try to get back on the track: try these links:
http://pathfinderpeople.blogs.com/hslahman/class_modeling/
http://pathfinderpeople.blogs.com/hslahman/books/

 

[tanix]

Andy Champ wrote:
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.
Bad advice. In big companies, people are on their own, and nobody to
guide them. At least that's my experience in a big company.

Well, that's true for one's whole life Don't wait for somebody to
feed you.

Give a man a fish and you feed him for a day. Teach a man to fish and
you feed him for a lifetime.

But big compagnies may have veterans and hire interesting people and
consultants from which you can learn. Some will teach you freely; for
others, use a peephole

I agree with fanix on this matter (in his other posts on this tread) :
people in big companies are generally not helpful. They will answer your
question, but will hide details.

Correct.

They will "answer" it in such a way that it would be easier
for you to find the answer elsewhere.

Again. "Job security" trip. And it is running rampant.
I bet the statistics would be simply mind shattering.
I suspect in AT LEAST 90% of all cases, these "answers" are not
even answers, but the ways to delude you, just to make sure
HE ends up on the top of YOU.

If I try to remember how many times in my entire history
someone was really helpful, I can remember just one guy,
more or less. His name is Dan Rubin from Boston, Mass. USA.
One of the nicest guys I EVER had to work with.
A beautiful soul.
I could dig up deeper and may be find a couple more,
just for the sake of argument.
And I mean out of HUNDREDS, if not thousands of people I had
to deal with.

If those suckers in the "leading" sw engineering companies,
and especially in that sick silicon valley would even realize
what it means, they'd prolly commited suicide.

Why?

Well, because it costs them BILLIONS!

The amount of money they have to pay to their emplooyees
is probably several times more than it is necessary
if people cooperated and were helpful,
instead of questioning each others intergiry
with every question anybody asks of them.

Just look at what is happening here, on these very threads.

What I see is some people are just attacking you essentially.
They'd waste YEARS of their worthless lives
just to prove that you are "wrong".
That Java is not much better than C++ in terms of memory
management.
That YOU must be simply fucked up and your "design"
is not "good", whatever the **** do they mean by that,
even after you told them they are dealing with cream of the
crop level, going down to kernel itself.

And they would twist and turn like poisonous snakes,
perverting everything you can imagine, insulting you and
your intelligence and trying to make a fool out of you,
and on and on and on.

What a royal waste of human life and human potential!

And some funken jackass tells you "well, you could desrribe
what you say in one sentence", like "coca cola is good.
drink coca cole" type.

Maaaan.
They suck.
Just like a black hole, if not better.
And WHO are these jacks on the wall?
The funken NOBODIES in the scheme of things?

Instead of these suckers finding something fun to do with
THEIR lives and enjoy the creative aspect, these perverts
poke their dirty noses into YOUR life and try to teach
you the "family values".

Ok, suckers, one more time:

Read THIS and be done with it.

http://preciseinfo.org/Convert/We_are_here_to_change_the_world_01.htm

Because THAT is where I stand.
And because it is about YOU. Not me.
So, when ANY of you cross my path, keep THAT stuff in mind.
Because I'll grind you to DUST by the time we are through with you.
No need to bother me with your horseshit.
Just eat it yourselves.

ONLY if you have something creative, something constructive,
something that REALLY works, something that opens up a NEW
dimension to me, you can talk to me.

Otherwise, just get out of my way.
Not a profitable enterprise indeed.
Some of the biggest guns around lost their skin
trying **** with me.

Deal?

:--}

--
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.

 

[tanix]

Andy Champ wrote:
Eric B se-Wolf wrote:
[lots of sarcasm snipped]
So it all depends on experience?
Mostly, yes. =A0Get a job in a good software shop - not something lit= tle,
but one with big teams. =A010 years down the line you'll probably hav= e the
idea.
Bad advice. In big companies, people are on their own, and nobody to
guide them. At least that's my experience in a big company.

Well, that's true for one's whole life Don't wait for somebody to
feed you.

Give a man a fish and you feed him for a day. Teach a man to fish and
you feed him for a lifetime.

In the first place, why would you expect anybody to give you a fish or
to teach you how to fish ?

Even the more optimistics know we are in a rotten world.

YOU are in a rotten world.
Not me.

Enough.

(The more pessimistics say there is no way out.)

The answer would then be: if all else fail, see how others fish and do
the same.


AFAIS tanix is a troll and IMNSHO with a shallow depth of
understanding on the issue.


Or they don't have the will, the formation or the time to train. IME
if you come up with questions showing that you did care and broke a
bit you teeth on the problem, you'll find someone to help you get
through. And, if you don't ... at least you have what you got by
yourself.

--
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.

 

[tanix]

Michael Doubez wrote:
Andy Champ wrote:
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.
Bad advice. In big companies, people are on their own, and nobody to
guide them. At least that's my experience in a big company.
Well, that's true for one's whole life Don't wait for somebody to
feed you.
Give a man a fish and you feed him for a day. Teach a man to fish and
you feed him for a lifetime.

In the first place, why would you expect anybody to give you a fish or
to teach you how to fish ?

Because I was naive and expected too much

Nope. Don't believe a SINGLE word thes kinds of people say.

Because you are ALIVE!
Because you are STILL human!
Because you STILL have a heart,
and not just a pump they think heart is.
Because YOU are the flower of the beauty
talking to beasts, not suspecting you are dealing with monsters.

Because YOU are the one that counts at the end.
Not them.

I could have said more, but is already way OT

Screw that "on topic" crap.

It is just an ugly trick of guilt manipulation.
Most of the blabber I see, being perfectly "on topic",
turns out to be some of the ugliest, totally "off topic" stuff.

Only one way out, and it awaits all of us

:--}

Ok, good enough for now.

Not completely. Most of his posts are long and full of bitterness, but
you can find good points there.


I guess you are right.



Anyway, to try to get back on the track: try these links:
http://pathfinderpeople.blogs.com/hslahman/class_modeling/
http://pathfinderpeople.blogs.com/hslahman/books/

--
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.

 

[Jorgen Grahn]

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.

You reason like I did when I was was very young and just a wannabe
programmer. There is *some* truth in it, but like they used to say at
Microsoft[1]:

Real Programmers Ship

meaning it doesn't matter how beautiful your code is if it's not
done (=kind of useful) when the users need it.

Also, I have noticed that the best way to create horribly ugly code is
to start with the intention to create a Work Of Art, and then run out
of time.

/Jorgen

[1] No endorsement intended.

 

[Jorgen Grahn]

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

Those are all well-respected books ... but IMHO you have to be a bit
careful when reading them. People -- and whole organizations -- tend
to get fanatical and applying the teachings (DP, UML, OO*, TDD)
anywhere they see the chance.

I also recommend Stroustrup's The C++ Programming Language, for the
few chapters at the end which deal with design, and working as a
programmer in general. Maybe he says it as well or better in his most
recent book too; I haven't read it.

Just reading isn't the best way to learn though. My other favorite
ways are, I think:

- maintaining lots of bad code
- writing lots of new code, and making mistakes
- discussing with other programmers
- hanging out on Usenet (maybe not so much for design
as for C++ techniques)

/Jorgen

 

[Kensai]

This was a great post, thank you!

Constantine

 

[tanix]

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.

You reason like I did when I was was very young and just a wannabe
programmer. There is *some* truth in it, but like they used to say at
Microsoft[1]:

Real Programmers Ship

:--}

I know, I know, and we did that too.
And what if you are NOT like Microsoft, trying to captalize on the
most rediculous things, such as not allowing your users to ship
yoour MVM unless they wired it in with your traps and go through
your KGB style interrogation just to "ship" the executable with
your stinky MVM?

Microsoft is sharks. Their interest is in maximizing the rate
of sucking of the blood of many by the few. You sneeze, you pay.
You want "customer support", you pay.
You want the most stoopid thing in the world, down to including
some of their stinky include file, you stand on your knees
and suck their weanie.

Is that enough for you?
Or you need more?

This project is not about shipping. I don't need to sell it.
I don't need money. I am fine as I am.
This is something, actually the ONLY thing, I can rely upon
once my box is on the net.

TOTALLY different set of criterias apply.
I can afford a luxury of spending YEARS designing and coding it.
I can afford to spend YEARS testing it.
I can afford to implement the craziest design ideas I can think
of without any cocksucker moron from microsoft breathing down
my neck and asking you "when is this thing going to be delivered?
We have the "daedline" in two weeks. If you don't have it by
that time, you are fired!"

Yep. Deadlines exist for dead people.
But I am alive.
I don't have deadlines.
I don't have their sick "code reviews" when some morons
waste hours on trying to discredit me and thus show how
"great" THEY are, so manaker makes notice of it and does
not put them on "kick arse first list".
I could care less what anybody blabbers about "good design".
I could care less what anybody thinks about memory management
issues.

I have about the best overall functionality I know of.
TOTALLY responsive GUI where you can open up ANY dialog boxes
and size them to any size you want, and, while they are open
you can perform ANY other operation they can imagine,
including, but not limited to, opening any other dialog
and doing anything they want there.

The most critical GUI panels or windows or views are fully
resizable.

I can give you a list long enough.

And THAT is what counts to ME, not to you.

YOU want to "survive", fine with me, go and "survive".

This is not a #1 priority item on my list, whether you
believe it or not.

Enough.

meaning it doesn't matter how beautiful your code is if it's not
done (=kind of useful) when the users need it.

Also, I have noticed that the best way to create horribly ugly code is
to start with the intention to create a Work Of Art, and then run out
of time.

/Jorgen

[1] No endorsement intended.

--
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.

 

[tanix]

Those are all well-respected books ... but IMHO you have to be a bit
careful when reading them. People -- and whole organizations -- tend
to get fanatical and applying the teachings (DP, UML, OO*, TDD)
anywhere they see the chance.

Agreed. It is not far from getting obsessed with some new fashion,
that may not even survive for more than a couple of years.

I also recommend Stroustrup's The C++ Programming Language, for the
few chapters at the end which deal with design, and working as a
programmer in general. Maybe he says it as well or better in his most
recent book too; I haven't read it.

Just reading isn't the best way to learn though. My other favorite
ways are, I think:

- maintaining lots of bad code

:--}

I like THAT one indeed.
You made my day!

- writing lots of new code, and making mistakes
- discussing with other programmers
- hanging out on Usenet (maybe not so much for design
as for C++ techniques)

Well, everyone has his own kicks, no question about it.

Have fun.

/Jorgen

--
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.

 

[James Kanze]

[...]

One more time: unless you appreciate beauty and music.
you are just a lamer to me.

One doesn't exclude the other.

That is why you make these kinds of statement.

Competence has NOTHING to do with this sucky "ability to
communicate". This is simply disgusting.

Competence in computer programming requires a number of
abilities. Communication is one of them.

Some of the brightest stars that ever walked this planet and
create work of art that hand in your museums and are being
sold for more than you can make in your lifetime, "could not
communicate".

Could Jimi Hendix "communicate"?

Have you ever listened to his music? That's true communication.

Could Dostoyevski "communicate"?

Are you saying the Dostoyevski didn't actually master his native
language, Russian?

Could MOST of other brightest stars "communicate"?

If they couldn't, we'd never have heard of them. Art is a form
of communication.

What do you MEAN by "communicating"?

Being able to transfer your understanding to others.

You mean YOUR dumbness of not being able to see the light of
day?

What we have here is a failure to communicate. Perhaps what's
bothering you is that you don't know how to communicate (and
thus, prove your incompetence).

Do you want Van Gogh or Modigliani "explain" to you what
their works mean?

They don't have to, since they know how to communicate.

[...]

Wow. I am impressed.
To see the fools that would PAY contracters to LEARN
something?

Maybe not such fools. After three months, I'd usually be better
than the conventional "experts". They hired me, in preference
to people with specific experience in the technique, because
they knew I could learn, and that I was capable of communicating
what I had learned afterwards.

Never head of such a thing. Sorry.

So you've never worked for a place which knew how to judge
competence.

 

[James Kanze]

Andy Champ wrote:
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.
Bad advice. In big companies, people are on their own, and
nobody to guide them. At least that's my experience in a
big company.

Well, that's true for one's whole life Don't wait for
somebody to feed you.

Give a man a fish and you feed him for a day. Teach a man to
fish and you feed him for a lifetime.

A lot of big companies understand this. At least in theory.

I agree with fanix on this matter (in his other posts on this
tread) : people in big companies are generally not helpful.
They will answer your question, but will hide details.

It depends on the company, and in most cases, on the department.
I've seen this at times, but it has certainly been an exception,
at least in recent years. Big companies seem to have learned,
and what was common practice twenty or thirty years ago
generally isn't tolerated today.

 

[James Kanze]

First of all, playing a musical instrument is not just a
matter of "manual dexterity", whatever it means to YOU, even I
know exactly what it means to me.

It's not just, but playing a Liszt sonata on the piano is one of
the most challenging things there is with regards to manual
dexterity. It's also challenging in a lot of other ways, and
some of those ways are relevant to programming, but someone who
has lamed their hands in an auto accident will never be able to
play Liszt, but they may be a very good programmer anyway.

To PLAY somthing, your mind needs to be able to process the
immense amounts of STRUCTURAL and SYTEMATIC information, if
you even BEGIN to comprehend what that means.

I'm beginning to suspect that you don't, but whatever. I never
said the contrary. I just said that it also requires a certain
manual dexterity, and that if you have the capability of
processing immense amounts of structural and systematic
information, but you've lost half your fingers, you still won't
be able to play Liszt. But you might still be a competent
programmer.

 

[Michael Doubez]

Michael Doubez wrote:
Andy Champ wrote:
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.
Bad advice. In big companies, people are on their own, and nobody to
guide them. At least that's my experience in a big company.
Well, that's true for one's whole life Don't wait for somebody to
feed you.
Give a man a fish and you feed him for a day. Teach a man to fish and
you feed him for a lifetime.

In the first place, why would you expect anybody to give you a fish or
to teach you how to fish ?

Because I was naive and expected too much
I could have said more, but is already way OT

Well, that's your job to determine it (too much, not well placed or
not handled appropriately).

Bitterness spring up for people th

 

[Michael Doubez]

Michael Doubez wrote:
Andy Champ wrote:
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.
Bad advice. In big companies, people are on their own, and nobody to
guide them. At least that's my experience in a big company.
Well, that's true for one's whole life Don't wait for somebody to
feed you.
Give a man a fish and you feed him for a day. Teach a man to fish and
you feed him for a lifetime.
In the first place, why would you expect anybody to give you a fish or
to teach you how to fish ?

Because I was naive and expected too much

((Oups))

Well, that's your job to determine it: too much ? not well placed ?
not handled appropriately ? someone wronged you ?

Whatever the answer, IMHO bitterness springs up when you could not
adapt to your environment.

[snip]

Funny how people start talking about software design and end up
talking about life choice. IMO it is because ultimately, software
design is also a matter of making choices relatively to a problem
space; which is easy to say .

 

[tanix]

Michael Doubez wrote:
Michael Doubez wrote:
Andy Champ wrote:
Eric B se-Wolf wrote:
[lots of sarcasm snipped]
So it all depends on experience?
Mostly, yes. =A0Get a job in a good software shop - not something= little,
but one with big teams. =A010 years down the line you'll probably= have the
idea.
Bad advice. In big companies, people are on their own, and nobody = to
guide them. At least that's my experience in a big company.
Well, that's true for one's whole life Don't wait for somebody t= o
feed you.
Give a man a fish and you feed him for a day. Teach a man to fish an= d
you feed him for a lifetime.

In the first place, why would you expect anybody to give you a fish o= r
to teach you how to fish ?

Because I was naive and expected too much

((Oups))

Well, that's your job to determine it: too much ? not well placed ?
not handled appropriately ? someone wronged you ?

Whatever the answer, IMHO bitterness springs up when you could not
adapt to your environment.

Oh, another smart fart.
:--}

You CREATE your own environment.
Chameleons "adapt".

People CREATE.

You CREATE your wold as you go.
Unless you think you are no more than a slave
of that "environment" and whatever you can do
is no more than a dead mosquito fart.

And so, eventually, you are BOUND to come to the junction
the mankind is at right now, and that is TOTAL devastation
on the face of the planet Earth.

Because all those lil parasites just silently "adapt"
and allow the most vicioust monster to exploit everything
that moves and does not move for that matter.

You need more?
Or it would be enough to activate some latent neurons
in your cockpit?

[snip]

Funny how people start talking about software design and end up
talking about life choice. IMO it is because ultimately, software
design is also a matter of making choices relatively to a problem
space; which is easy to say .

--
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.

 

[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.

You reason like I did when I was was very young and just a wannabe
programmer. There is *some* truth in it, but like they used to say at
Microsoft[1]:

Real Programmers Ship

:--}

I know, I know, and we did that too.

In fact, let me be even more blunt:

Real programmers are those, who DON'T ship!!!

Those, who "ship" write the crappiest code there is.

Why?

Well, simply because they have no time to do it
forever being under pressure to "release" and are being
forced to do a 3 month worth of work in 3 weeks.

Their documentation sucks.
It does not tell you anything useful.

Their code sucks.

And their sharks called VPs and CEOs are nothing more than
viciouse sharks, whose only interest is to suck as much blood
from anything that moves as they can manage.

Their customer support sucks
and at the biggest and baddest places is simply non existant.

Their "interpersonal skills" suck
becaues of "fear of survival".

They are, on the most part vicious,
utterly inhuman idiots, driven by the complex of inferiority.

Clear enough?

Or you need more?

And what if you are NOT like Microsoft, trying to captalize on the
most rediculous things, such as not allowing your users to ship
yoour MVM unless they wired it in with your traps and go through
your KGB style interrogation just to "ship" the executable with
your stinky MVM?

Microsoft is sharks. Their interest is in maximizing the rate
of sucking of the blood of many by the few. You sneeze, you pay.
You want "customer support", you pay.
You want the most stoopid thing in the world, down to including
some of their stinky include file, you stand on your knees
and suck their weanie.

Is that enough for you?
Or you need more?

This project is not about shipping. I don't need to sell it.
I don't need money. I am fine as I am.
This is something, actually the ONLY thing, I can rely upon
once my box is on the net.

TOTALLY different set of criterias apply.
I can afford a luxury of spending YEARS designing and coding it.
I can afford to spend YEARS testing it.
I can afford to implement the craziest design ideas I can think
of without any cocksucker moron from microsoft breathing down
my neck and asking you "when is this thing going to be delivered?
We have the "daedline" in two weeks. If you don't have it by
that time, you are fired!"

Yep. Deadlines exist for dead people.
But I am alive.
I don't have deadlines.
I don't have their sick "code reviews" when some morons
waste hours on trying to discredit me and thus show how
"great" THEY are, so manaker makes notice of it and does
not put them on "kick arse first list".
I could care less what anybody blabbers about "good design".
I could care less what anybody thinks about memory management
issues.

I have about the best overall functionality I know of.
TOTALLY responsive GUI where you can open up ANY dialog boxes
and size them to any size you want, and, while they are open
you can perform ANY other operation they can imagine,
including, but not limited to, opening any other dialog
and doing anything they want there.

The most critical GUI panels or windows or views are fully
resizable.

I can give you a list long enough.

And THAT is what counts to ME, not to you.

YOU want to "survive", fine with me, go and "survive".

This is not a #1 priority item on my list, whether you
believe it or not.

Enough.

meaning it doesn't matter how beautiful your code is if it's not
done (=kind of useful) when the users need it.

Also, I have noticed that the best way to create horribly ugly code is
to start with the intention to create a Work Of Art, and then run out
of time.

/Jorgen

[1] No endorsement intended.

--
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.