[OT] How to learn software design
Eric Böse-Wolf
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
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:
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.
Eric Böse-Wolf
ta...@mongo.net (tanix) writes:
> In article <7p3lqh...@mid.individual.net>,
> er...@boese-wolf.eu (Eric =?utf-8?Q?B=C3=B6se-Wolf?=) wrote:
>>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.
>
[lots of sarcasm snipped]
So it all depends on experience?
Eric
tanix
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.
>Eric
Andy Champ
> [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.
Andy
Saeed Amrollahi
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
James Kanze
> In article <7p3lqhFfs...@mid.individual.net>,
> e...@boese-wolf.eu (Eric =?utf-8?Q?B=C3=B6se-Wolf?=) wrote:
> >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.
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.
--
James Kanze
James Kanze
> Eric Böse-Wolf wrote:
> > 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.
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.
--
James Kanze
James Kanze
> On Dec 19, 12:48 pm, e...@boese-wolf.eu (Eric Böse-Wolf) wrote:
> > 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.
> 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.
--
James Kanze
Pete Becker
>
> 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 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.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
tanix
:--}
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.
>Andy
tanix
>Andy Champ <no....@nospam.invalid> writes:
>>Eric B�se-Wolf wrote:
>>>So it all depends on experience?
>>Mostly, yes. Get a job in a good software shop - not something little,
>
> 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?
Paavo Helde
daf0cf...@l13g2000yqb.googlegroups.com:
> On Dec 19, 10:00 am, ta...@mongo.net (tanix) wrote:
>> 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.)
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
tanix
>On Dec 19, 7:54 pm, Saeed Amrollahi <amrollahi.sa...@gmail.com> wrote:
>
>> > 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.
>
>> 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.
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.
Stuart Golodetz
> In article <P9udnaD819nDmrDW...@eclipse.net.uk>, Andy Champ <no....@nospam.invalid> 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.
>
> :--}
>
> 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.)
> 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.
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.
> 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.
>
> :--}
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.
Regards,
Stu
Ian Collins
> James Kanze wrote:
>>
>> 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 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!)?
--
Ian Collins
Ian Collins
> On Dec 19, 10:00 am, ta...@mongo.net (tanix) wrote:
>> In article <7p3lqhFfs...@mid.individual.net>,
>> e...@boese-wolf.eu (Eric =?utf-8?Q?B=C3=B6se-Wolf?=) wrote:
>
>>> 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.
>
> 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).
The book "Beautiful Code" is well worth a read.
http://oreilly.com/catalog/9780596510046
--
Ian Collins
Balog Pal
> 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.
tanix
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".
Andy Champ
<snip>
> 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...
>
The comment I make on comments is: Don't write what you are doing,
write why you are doing it. And best of all, write why you aren't doing
something else.
("Start the runge-kutta here to give it time to warm up before we need it")
("Don't alter the wibble here or you will break the flibbert")
IYSWIM
Andy
Andy Champ
>
> 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.
>
if it's really bad (or really good) they'll have heard.
Andy
Eric Böse-Wolf
> er...@boese-wolf.eu (Eric =?utf-8?Q?B=C3=B6se-Wolf?=) writes:
>>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
Thanks.
Eric
tanix
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.
>> 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.
>
>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.
>> 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.
>>
>> :--}
>
>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.
tanix
>James Kanze wrote:
>> On Dec 19, 10:00 am, ta...@mongo.net (tanix) wrote:
>>> In article <7p3lqhFfs...@mid.individual.net>,
>>> e...@boese-wolf.eu (Eric =?utf-8?Q?B=C3=B6se-Wolf?=) wrote:
>>
>>>> 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.
>>
>> 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?
Well, it is hard to put into words.
How can you POSSIBLY "study" beauty?
>> I'm not even sure you can study
>> beauty, per se, except from a philosophical point of view (what
>> is beauty?).
Good. Now you asked the "correct" question.
What is beauty?
Well, read the dialog of Socrates by Plato
on this exact point.
I bet you are going to get more help from reading it
than from anything you can read on this group.
>> 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).
Well, one of the properties of beauty is simplicity.
A beautiful code is never convoluted.
It is never a spagetti pile, a concuction of disassociated ideas.
It, for some strange, magical reason, falls into place.
Each part is in harmony with each other part.
At every single method you look, it does not look like a huge
something. It seeems it is not doing much.
Because you are on a local scope level.
But when you look at this thing from at least one level up,
all of a sudden, you see it all singing like a song.
It is a harmony of components, and not that sick dissonance
of "i fuck you and the only thing i care about is burning down
your house". Believe it or not.
Because THAT is how most of code I saw reads.
In any well designed system, the subsystems and components
sing in harmony.
Beyond that, you are on your own.
>The book "Beautiful Code" is well worth a read.
>
>http://oreilly.com/catalog/9780596510046
--
Pete Becker
No. Don't fall for the cliche that all lawyers are bad writers.
Ian Collins
> Ian Collins wrote:
>> Pete Becker wrote:
>>> James Kanze wrote:
>>>>
>>>> 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 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!)?
>>
>
> No. Don't fall for the cliche that all lawyers are bad writers.
I'm not falling for clich�s, merely reflecting on experience.
Look at it another way: laws are a lot more expensive to test than
programmes due to their arcane and bloated wording. Maybe someone
should give test driven legislation a go...
--
Ian Collins
Rune Allnor
> 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.
>
> to some sort of software architecture.
I am not a software engineer, although I do code up
the tools I need for my work, so my opinions might
not be directly relevant to your trade.
Howeer, there are a number of things you can do in
your day-to-day work to become better (and some that
you *must* do if you want to become really good, no
matter your trade):
1) Evaluate the craftmanship of people you see around you.
Some people are good at what they do, and produce
better code faster than the rest. Whenever you
come across somebody who does that, try and find
out somethoing about what it is they do that others
don't. Or what others do, thay they don't.
Of course, the same goes for people who fall behind.
It might, in fact, be far more efficient to learn
from other people's mistakes than from their successes,
for no other reason than that there are far more
mediocre than skilled people around.
2) Whenever you have the option to do things two or more
ways, map out the pros and cons with each approach.
Be concious about your choises: "I use method A because
it is faster to implement, while method B would have
produced faster code." Insight, whatever that is,
comes by becoming concious about your choises and
the resulting penalties / payoffs. The next time
around, your experiences might cause you to choose
differently when presented with similar alternatives.
3) Realize that the system is a collection of details.
"Techincal details" like exceptions, templates and
smart pointers have tremendeous impact on feasible
system designs. Make sure you understand the exact
impact these sorts of techniques have on resulting
code, both what readability / maintainability and
run-time performance and resource requirements are
are concerned.
4) Language governs ideas and ideas govern language.
Think on your feat when you talk with people about
the system. Wrap your mind around the problem as fast
and as intimately as possible. Follow up on descriptions
immediately when you talk with clients; poke for those
alternative descriptions and commenst that could blast
your mind wide open for what the client actually wants.
No one will ever be able to design a system for an
application they do not understand.
In essence, watch and evaluate (to yourself, not openly)
everything you hear and see, and everyone you meet and
talk to. Lern from them, both by mimicing their forces and
avoiding their mistakes. If you do this consitently for
sufficiently long time, you might eventually get to the
point where you are able to come up with a system design.
Rune
tanix
Cool. I like that one.
Pete Becker
It's a good thing you're not falling for cliches here. But thanks for
hijacking my post.
Mick
may not be Lawyers. Their purpose and the process to develop them has
little bearing on the Software Development Process. To match the
political process the 'IF..THEN..ELSE' would need to contain a 'MAYBE'.
tanix
Actually, a VERY interesting point relating to logic as such
and its binary nature, going back since the dawn of "civilization".
A while back, when I had do deal with expert systems,
I noticed that yes and not is not sufficient to describe all
conditions. So I had an idea about multi-valued logic.
Since then, they came up with the idea of fuzzy logic in AI.
How would you describe a rainbow?
Is there light? - Yes.
What color is it? - does not fall under yes or no.
Probably the most graphical example of this binary logic
if fascism, where things are described in black and white colors.
There is no notion of rainbow.
The end result?
Andy Champ
>
> 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!
>
Fascinating. I'm in England, and it doesn't seem to be like that over
here. I've heard tales of things like this, but never seen them.
Perhaps you should point out to your colleagues that if they wrote
maintainable code someone else could maintain it (which everyone IME
hates) leaving them free to write the interesting new stuff!
Or perhaps it is just that as a contractor you get given the s**** jobs
leaving the good bits for us permies?
Andy
tanix
>tanix wrote:
>>
>> 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!
>>
>
>Fascinating. I'm in England, and it doesn't seem to be like that over
>here. I've heard tales of things like this, but never seen them.
Well, it is as vicious in the Silicon Valley as it gets.
I can comprehend that things are different in Europe,
and thanx to God for the fact that there are at least SOME places
on this planet left that are still not inhuman, not as sick and
vicious as it is in the States.
The most vicious example of it was Silicong Graphics (SGI),
the Mountain View world headquarters.
They had several buildings about 10 in toto.
Basically their own small town not far from downtown.
When I did my first contract with them, it was beyond obscene.
The arrogance and viciousness and "perfectionism" was something
out of this world. You could hardly get some time to take a piss.
They loaded you so bad, that it was not just some stress,
it was superstress.
Not only that, but not a single person I had to deal with
would cooperate. It was nearly a scandal when I just started
on that job. Because I had to do something that had some very
subtle kernel configuration issues. If a single thing was not
configred properly in the kernel, I'd have to have ALL sorts of
problems. And there was one bitch, a funking hore, that knew
all the configuration parameters. But when I asked her to provide
it to me, she raised such a stink, that my manager had to work
things out with her manager, just to allow me to do my job,
which is totally insane. It costed these suckers several thousand
bux just to get this simpliest thing there is, which takes seconds
to get done without making ANY fuss about it.
And the most mind blowing thing was when I came to do my job,
on the first day, my manager just gave me a hard disk and said:
here is your job. Go figure it out.
Can you imagine THAT kind of job specification?
The funken hard disk was loaded up the hilt.
How do you even know what to look for?
He did not even tell me what do they need to get done!
Jesus funken Christ!
Then, whenever I needed anything from other people and asked
ANY question that really needed to be asked, those sickos,
that think they are some kind of software kings, looked at me
like I am from a planet Mars, a total moron, that is stoopid
enough to ask the questions.
The most disgusting thing about it, that I could stuff most
of those suckers under my belt without winking an eye.
There were mostly morons that just graduated from school
with engineering degree. At that time, I had about 15 years
in the industry and hand experience and knowledge of all sorts
of theories down to electron level. Not that I am a physicist.
And these funken gorillas behaved like they are messangers
of nothing less than God itself and their mission here is
something like to save the world and teach it something so
revolutionary that it will change forever.
God. What a disgusting trip that was.
I did my job just fine and everything was nice and dandy
at the end. All on time. All in tip top condition.
My manager knew more about his project than any other manager
in the whole company I bet. So noone could even attempt
to discredit him or create ANY kinds of problems for him.
Because that is all they do all day long, forever trying
to get on the top of the heap.
Brrrrr.
It even disgusts me to even recall that stuff.
But...
When I did a second contract with them a couple of years later,
you could not recognize the SGI any more. They had to sell
all their business park real estate and move into 2 buildings
and not 10 as they used to have, and the whole atmosphere
in the company was a total decay, a dying dinasaur level.
And you know what, it was MUCh easier to work, even it was
still a disgusting SGI atmosphere, basically any place you
look.
Good, suckers. THAT is what you trully deserve.
If you don't listen to what people of my caliber have to say,
than you are BOUND to loose your skin.
>Perhaps you should point out to your colleagues that if they wrote
>maintainable code someone else could maintain it (which everyone IME
>hates) leaving them free to write the interesting new stuff!
If you knew what Silicon Valley is, you would simply laugh at a fool
that says things like that.
They could care less if you are dead or alive.
ALL they care is their own trips.
Their own lil stinking egos.
Their own stinking holier than thou trips.
These suckers are simply inhuman for the most part.
I can hardly remember a SINGLE one of them that is human
and I could relate to. Probably about 3 to 5 people in toto
during tens of years of my experience in the valley.
Basically, you just sit in your cubicle and don't even try
to relate to ANYONE except your manager. Because you have to.
You are on your own. If you EVER ask ANY question from ANYONE,
that is a BIG minus in your "reputation".
If you suggest ANYTHING that rocks the boat and their stinky
and rotten "environment", it is 2 minuses in your reputation.
If you EVER screw up only ONCE,
you are fired.
ON THE SPOT.
Maan. That whole stinky silicon valley deserves to be burned
down to ashes, so vicious, so sick and so inhuman it is.
I do have to recognise the fact that quite a few of my managers
were really great people to work with.
Because the way I do interviews.
I NEVER lick their arse.
I NEVER smile with a plastic smile.
I NEVER try to please ANYONE on ANY interviews.
I just tell them what I know and how it is in my view.
You like it, you take it. You don't like it, go to hell,
lil do I care if you even exist.
So... As a result, only the most ingelligent people would
hire me and only those that really needed someone they can
rely upon to save their sorry tootoo.
>Or perhaps it is just that as a contractor you get given the s**** jobs
>leaving the good bits for us permies?
Well. It is true to some extent.
When they hire contractors, they need their arse saved
and in a hurry.
And you get some of the most critical things on their list.
Trust me, if they hire a CONTRACTER to do the job,
that means they are TOTALLY screwed and can not find anyone
in house to do it. Otherwise, they'd just hire a full timer.
Most of the time, it is their house is burning down or is
about to get burned down.
Because they have to pay you at least 50% more than they pay
their full timers. The amount of money I used to make doing
this crap was enough for me to work about 6 months a year
and drive the Cadillac Seville. The other 6 months of the year
I enjoyed doing my own projects at home, doing a music
recording and composition on my studio and investingating
ALL sorts of things.
>Andy
Enjoy the trip.
James Kanze
> tanix wrote:
> > 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!
> Fascinating. I'm in England, and it doesn't seem to be like
> that over here. I've heard tales of things like this, but
> never seen them.
It depends on the organization, but if some one can't (or
doesn't) communicate, he's not competent. (Since Sun was
mentionned: a large part of what I know about C++, I learned
from people at Sun. Who weren't even collegues---they still
took the time to answer my questions by email or in the news
groups.)
> Perhaps you should point out to your colleagues that if they
> wrote maintainable code someone else could maintain it (which
> everyone IME hates) leaving them free to write the interesting
> new stuff!
> Or perhaps it is just that as a contractor you get given the
> s**** jobs leaving the good bits for us permies?
That happens:-). But not necessarily as much as one might
think: I've just switched to being a permy after 25 years of
contracting, and I can say that I've seen a lot of interesting
things when contracting. (I learned C, C++, Java and Unix as a
contractor. Hired in places which used the language, and were
willing to train me, or at least help me get up to speed.)
--
James Kanze
James Kanze
> James Kanze wrote:
> > 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 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.
I don't think playing an instrument is enough. Or even
essential -- it just indicates one particular skill that is
needed. Programming requires a lot of different skills. (I
ended up programming because I got a job with a computer
manufacturer. And I got that job because they needed someone
who could understand digital logic, and I'd learned symbolic
logic in a philosophy course.)
--
James Kanze
James Kanze
> James Kanze <james.ka...@gmail.com> writes:
> >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/musicians_use_both_sides_of_their_brains_...
> 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.
I think you're reading more than I meant into what I wrote.
First, it's something I've heard---it's not an absolute rule
that I would practice. And playing a musical instrument takes a
number of different skills, some of which (manual dexterity) are
largely irrelevant to programming. But the "ability to be
creative in a structured environment" is common to both, and
it's one that's hard to test for.
> See also:
> http://scienceblogs.com/cognitivedaily/2009/07/music_participation_do...
> >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-p...
Interestingly, one of the best programmers I ever worked with
was an English lit major. At one point, he blew my mind,
because he didn't know binary representation (and didn't
understand why I had written (x + 7) & ~ 0x0f to force a value
up to the next multiple of 8). But he sure knew how to learn.
(A day after having asked me about my code, he was using similar
tricks himself.) And as you said, he very definitely understood
how to express his ideas lucidly. Both in English and in C.
(This was before we'd gotten C++.)
Of course, he also knew how to reason well, and I'm not sure
that this is true of all English lit majors.
[...]
> 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.
The problem is that even when you know that the code will never
be reused, you might be wrong. (Both Unix and MS-DOS started
out as quick and dirty solutions to an immediate problem, with
the authors knowing quite well that the code would never be
reused.)
--
James Kanze
James Kanze
> James Kanze wrote:
> <snip>> 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...
> </snip>
> The comment I make on comments is: Don't write what you are doing,
> write why you are doing it. And best of all, write why you aren't doing
> something else.
Exactly. Except that there are a lot of cases where you can use
the obvious solution, and then, no comments are necessary.
In the code, of course: it is imperative that every function
have its interface fully documented: pre- and post-conditions,
etc. Otherwise, no one can use it. (And even that statement
requires some nuancing, at least with regards to local
functions.)
--
James Kanze
James Kanze
> In article <96e36a6a-ae39-4fe6-9369-8cdc4adc5...@p8g2000yqb.googlegroups.com>, James Kanze <james.ka...@gmail.com> wrote:
[...]
> 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 writes extremely well. And it shows in his code.
> 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.
This has been more or less standard procedure in most places
I've worked. In several cases, we haven't even had debuggers
available.
--
James Kanze
tanix
>On 20 Dec, 12:09, Andy Champ <no....@nospam.invalid> wrote:
>> tanix wrote:
>
>> > 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!
>
>> Fascinating. I'm in England, and it doesn't seem to be like
>> that over here. I've heard tales of things like this, but
>> never seen them.
>
>It depends on the organization, but if some one can't (or
>doesn't) communicate, he's not competent.
One more time: unless you appreciate beauty and music.
you are just a lamer to me.
That is why you make these kinds of statement.
Competence has NOTHING to do with this sucky
"ability to communicate". This is simply disgusting.
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"?
Could Dostoyevski "communicate"?
Could MOST of other brightest stars "communicate"?
What do you MEAN by "communicating"?
You mean YOUR dumbness of not being able to see the light of day?
They "communicate" to you via presenting the very result
of their life, and not bullshit you peddle all day long.
You see, you can be a smart "philosopher" that talks many
"smart" things. But can you TRANSLATE all that "smart" talk
into reality by manifesting it into a physical object,
somethign tangible, and not just words, signifying nothing
at the end?
Do you want Van Gogh or Modigliani "explain" to you what
their works mean?
If you are blind, there is no hope for you.
You can go study to ANY "university" and it is all just a
royal waste of time at the end.
> (Since Sun was
>mentionned: a large part of what I know about C++, I learned
>from people at Sun. Who weren't even collegues---they still
>took the time to answer my questions by email or in the news
>groups.)
I know, I know.
Is it the Sun at their world headquarters in Mountain View,
California, USA?
Cause I know THOSE guys.
Maaan. They suck even worse than those vicious sharks
from SGI. Probably the 2nd most disgusting place I ever
had to deal with.
>> Perhaps you should point out to your colleagues that if they
>> wrote maintainable code someone else could maintain it (which
>> everyone IME hates) leaving them free to write the interesting
>> new stuff!
>
>> Or perhaps it is just that as a contractor you get given the
>> s**** jobs leaving the good bits for us permies?
We already covered that one in a previous post.
Let us see here an insightful reponse below...
>That happens:-). But not necessarily as much as one might
>think: I've just switched to being a permy after 25 years of
>contracting, and I can say that I've seen a lot of interesting
>things when contracting. (I learned C, C++, Java and Unix as a
>contractor.
Wow. I feel jealous!
> Hired in places which used the language, and were
>willing to train me, or at least help me get up to speed.)
Wow. I am impressed.
To see the fools that would PAY contracters to LEARN
something?
Never head of such a thing. Sorry.
tanix
Oh, great insights here again?
Well, first of all, dear expert, do you realize that by stripping
the posts and stripping the context damages the integrity of
the material?
Tell you one thing. One of the most upsetting aspects of
presenting your articles, and I do not mean you PERSONALY,
is that some of the people do not realize that if they strip
the article they are following upon, they are often
stripping the context, to the point it is not even possible
to read some code they are following up on.
My personal suggestion is: keep the ENTIRE article intact.
The > markers are used when regenerating articles in web
format and can be reformatted in any number of ways.
But if you strip things down, quite a few things become
unclear because all the context is gone.
I usually see this used by the conmen and dishonest people,
trying to distort the entire picture and make it look like
something else.
Let READER decide what he wants to read.
After all, you are not exactly a Jesus Christ, or ARE you?
tanix
>On 19 Dec, 21:56, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>> James Kanze <james.ka...@gmail.com> writes:
>> >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/musicians_use_both_sides_of_their_brains_...
>
>> 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.
>
>I think you're reading more than I meant into what I wrote.
>First, it's something I've heard---it's not an absolute rule
>that I would practice. And playing a musical instrument takes a
>number of different skills, some of which (manual dexterity) are
>largely irrelevant to programming.
WRONG.
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.
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.
To you realize what imporvisation is?
Well, it is running your mind at a rate where the biggest
and baddest supercomputers simply lock up.
It is such and immense TRUST to existance.
It is such an ORGASM with life,
that all your blabber of "holier than thou" here,
and all your "scientific" goubledy gook,
is nothing more than a tale told by an idiot
signifying NOTHING at the end.
Enough.
This disgusts me.
Yes, you CAN forge the issues with memory deallocation,
which is ALREADY a stretch I do not accept,
but when you start blabbering about THESE kinds of things,
I literally want to throw up.
I have to just leave this crap alone and get back
to things I really need to do instead of talking
to a wall of dumbness bordering on numbness.
> But the "ability to be
>creative in a structured environment" is common to both, and
>it's one that's hard to test for.
>
>> See also:
>
>> http://scienceblogs.com/cognitivedaily/2009/07/music_participation_do...
>
>> >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.
>
>> =BBI'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.=AB
>
>> http://praisecurseandrecurse.blogspot.com/2007/03/english-majors-as-p...
>
>Interestingly, one of the best programmers I ever worked with
>was an English lit major. At one point, he blew my mind,
>because he didn't know binary representation (and didn't
>understand why I had written (x + 7) & ~ 0x0f to force a value
>up to the next multiple of 8). But he sure knew how to learn.
>(A day after having asked me about my code, he was using similar
>tricks himself.) And as you said, he very definitely understood
>how to express his ideas lucidly. Both in English and in C.
>(This was before we'd gotten C++.)
>
>Of course, he also knew how to reason well, and I'm not sure
>that this is true of all English lit majors.
>
> [...]
>> You just need to know, /when/ to write this =BBQ&D=AB 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.
>
>The problem is that even when you know that the code will never
>be reused, you might be wrong. (Both Unix and MS-DOS started
>out as quick and dirty solutions to an immediate problem, with
>the authors knowing quite well that the code would never be
>reused.)
>
--
stan
I've found that a call home saying you're finishing up and WILL be
home in time to eat is pretty effective also, but you're method is probably
a slightly higher probability. You can slightly improve the odds if
you promise to stop and pick up some critical item on the way home.
Kaz Kylheku
> In article <7p3lqh...@mid.individual.net>, er...@boese-wolf.eu (Eric =?utf-8?Q?B=C3=B6se-Wolf?=) wrote:
>>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.
>
>
> what is beauty. Yep, BEAUTY. Believe it or not.
Bahahaha.
> Then get into music. Believe it or not.
Bahahaha.
> Music will teach you the structures unlike anything you are
> likely to read in any so calles software book.
Most musicians are idiots. Only /accomplished/ musicianship conceivably
has any bearing on the possibility of a latent software talent.
Just turn on your radio and listen to the repetitive, boring crap
full of cliche harmonic, melodic and rhythmic devices.
> 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.
You sound so naive, that you can't possibly be employed somewhere
as an actual developer.
> Every proggram has millions of logical conditions,
> every one of which must EXACTLY fit with all others.
You've never seen any real program. Firstly, some programs don't have
anywhere near that many conditions. In ones that do, the conditions are
not all dove-tailed into each other. If that is the case, the
program, in all probability, is ridiculously ill-designed.
Do you honestly think that, for instance, the state of a SCSI device
must fit exactly with the current state xon/xoff flag of TTY number 3?
Are you a moron?
> Never EVER ignore errors. Handle ALL exception conditioins,
> conceivable or not.
Believe it or not, sometimes it's okay to delegate this by returning an
error indication or throwing. The place in the program where a problem
is discovered is usually not the place where to decide what to do about
it.
Never EVER EVER use ALL CAPS in every sentence because it makes you LOOK
like a TWIT.
Kaz Kylheku
It's something that most musicians don't do, or cannot do well.
> Well, it is running your mind at a rate where the biggest
> and baddest supercomputers simply lock up.
Not really. 99.99% of all improvisation you hear is simply a
regurgitation of the musician's favorite ``licks'' which that musician
has rehearsed all his life. He can play them against that music,
because the music is also regurtited. He's improvised against that
kind of cliche chord progression countless times before.
There is probably less total content in the average improviser's
personal vocabulary than in one composition from Bach.
Most improvised guitar solos in pop, rock some kind of ``box''; the
wailers play what is convenient under the fingers. Improvisation in
jazz is more demanding, but not much. Most jazz improvisation that you
actually hear is actually worse than improvisation in pop and rock; just
mindless noodling junk by someone who has no clue how to actually match
the more altered chord structure and is merely trying to avoid hitting
too many diatonic notes in hopes that the result sounds ``jazzy''.
The brilliant few improvisers are the worshipped exception.
Most improvised music of any kind sounds like crap, compared to the
hard work of a competent composer.
Improvisation is pitifully /easy/ compared to writing down. Most
rabid improvisers, if they have to sit down and write something
beautiful, coherent, and unified, will find that they are stumped.
It's much easier to just noodle on your instrument in a blank-mind
auto-pilot mode, than to actually learn notes, or sit down and compose
something.
> I literally want to throw up.
That's fine; just kindly use a mop to clean away the results---not
your NNTP software's post command.
tanix
The same thing for just about anything else under the Sun.
Anything else?
>> Well, it is running your mind at a rate where the biggest
>> and baddest supercomputers simply lock up.
>
>Not really. 99.99% of all improvisation you hear is simply a
>regurgitation of the musician's favorite ``licks'' which that musician
>has rehearsed all his life.
True and interesting point that I personally know.
But...
Why don't you trust?
And I mean trust YOURSELF?
Is it THAT hard to do?
Sure you can not trust ME.
But can you trust YOURSELF?
Then...
Tadaaaam!
You don't have that problem.
And I wasted YEARS on making my fingers fly like Paganini.
And I wasted YEARS to make sure I can improvise with
the baddest of them all, like Chick Corea or John McLaughlin
and you name it.
And I DID see the stoopidity of it.
What does it matter how "fast" you play
and how fast are your fingers?
My own finding was: it is just a complex of inferiority,
expressing itself in a perverted way.
Since then, I have some notes I play that may be several
bars long.
The interesting thing about it is this:
When I was just starting out with a band and we had
the most respected band in the city, one drummer came
to listen to us and when we had a break, he came up
to me and said: Oh, I see. I understand what you are
playing. You are playing a silence. Right?
That simply blew my mind. I myself was not realizing
it at a time. Well, that drummer happened to be the
number 2 drummer in the whole city and he had golden
ears.
What a joy to meet someone of THIS caliber.
Yes, they DO regurgitate what they were zombified with,
or, rather, what they did zombify themselves with
as a result of complex of inferiority that runs their
life.
But that does not mean YOU have to be like them.
Enough.
> He can play them against that music,
>because the music is also regurtited. He's improvised against that
>kind of cliche chord progression countless times before.
>
>There is probably less total content in the average improviser's
>personal vocabulary than in one composition from Bach.
>
>Most improvised guitar solos in pop, rock some kind of ``box''; the
>wailers play what is convenient under the fingers. Improvisation in
>jazz is more demanding, but not much. Most jazz improvisation that you
>actually hear is actually worse than improvisation in pop and rock; just
>mindless noodling junk by someone who has no clue how to actually match
>the more altered chord structure and is merely trying to avoid hitting
>too many diatonic notes in hopes that the result sounds ``jazzy''.
>The brilliant few improvisers are the worshipped exception.
>
>Most improvised music of any kind sounds like crap, compared to the
>hard work of a competent composer.
>
>Improvisation is pitifully /easy/ compared to writing down. Most
>rabid improvisers, if they have to sit down and write something
>beautiful, coherent, and unified, will find that they are stumped.
>
>It's much easier to just noodle on your instrument in a blank-mind
>auto-pilot mode, than to actually learn notes, or sit down and compose
>something.
>
>> I literally want to throw up.
>
>That's fine; just kindly use a mop to clean away the results---not
>your NNTP software's post command.
--
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.
tanix
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.
:--}
Michael Doubez
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 :)
--
Michael
Vladimir Jovic
>>>> [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
> Michael Doubez wrote:
> > On 21 d c, 09:59, Vladimir Jovic <vladasp...@gmail.com> 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 ?
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.
> > 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) :
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.
--
Michael
Vladimir Jovic
> On 21 d�c, 11:25, Vladimir Jovic <vladasp...@gmail.com> wrote:
>> Michael Doubez wrote:
>>> On 21 d c, 09:59, Vladimir Jovic <vladasp...@gmail.com> 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
>
> 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.
>
>>> 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) :
>
> 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.
>> 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.
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
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 fuck 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 fuck with me.
Deal?
tanix
>On 21 d=E9c, 11:25, Vladimir Jovic <vladasp...@gmail.com> wrote:
>> Michael Doubez wrote:
>> > On 21 d c, 09:59, Vladimir Jovic <vladasp...@gmail.com> wrote:
>> >> Andy Champ wrote:
>> >>> Eric B se-Wolf wrote:
>> >>>> [lots of sarcasm snipped]
>> >>>> So it all depends on experience?
>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.
>
>> > 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) :
>
>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.
>
--
tanix
>Michael Doubez wrote:
>> On 21 d�c, 11:25, Vladimir Jovic <vladasp...@gmail.com> wrote:
>>> Michael Doubez wrote:
>>>> On 21 d c, 09:59, Vladimir Jovic <vladasp...@gmail.com> 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.
>> 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 ;)
:--}
Ok, good enough for now.
>> The answer would then be: if all else fail, see how others fish and do
>> the same.
>>
>>>> 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) :
>>
>> 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.
>
>>> 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.
>
>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/
--
Jorgen Grahn
> In article <7p3lqh...@mid.individual.net>, er...@boese-wolf.eu
> (Eric =?utf-8?Q?B=C3=B6se-Wolf?=) wrote:
>>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.
>
>
> likely to read in any so calles software book.
>
> A program is a SYSTEM, a highly complex interactions,
> a higly complex structure, and immensely complex logic.
>
> every one of which must EXACTLY fit with all others.
>
> 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.
>
> 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 <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jorgen Grahn
> er...@boese-wolf.eu (Eric =?utf-8?Q?B=C3=B6se-Wolf?=) writes:
>>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://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
Constantine
Stefan Ram wrote:
> 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.
>
tanix
> 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.
>
--
tanix
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
James Kanze
> James Kanze <james.ka...@gmail.com> wrote:
> >On 20 Dec, 12:09, Andy Champ <no....@nospam.invalid> wrote:
> >> tanix wrote:
[...]
> >It depends on the organization, but if some one can't (or
> >doesn't) communicate, he's not competent.
> 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.
[...]
> >Hired in places which used the language, and were willing to
> >train me, or at least help me get up to speed.)
> 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
James Kanze
> Michael Doubez wrote:
> > On 21 d c, 09:59, Vladimir Jovic <vladasp...@gmail.com> 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.
A lot of big companies understand this. At least in theory.
> > 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.
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
James Kanze
> James Kanze <james.ka...@gmail.com> wrote:
> >On 19 Dec, 21:56, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> >> James Kanze <james.ka...@gmail.com> writes:
> >> >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/musicians_use_both_sides_of_their_brains_...
> >> 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.
> >I think you're reading more than I meant into what I wrote.
> >First, it's something I've heard---it's not an absolute rule
> >that I would practice. And playing a musical instrument
> >takes a number of different skills, some of which (manual
> >dexterity) are largely irrelevant to programming.
> WRONG.
> 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.
--
James Kanze
Michael Doubez
> >> Michael Doubez wrote:
> >>> On 21 d c, 09:59, Vladimir Jovic <vladasp...@gmail.com> 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
> On 21 déc, 12:48, Vladimir Jovic <vladasp...@gmail.com> wrote:
> > Michael Doubez wrote:
> > > On 21 déc, 11:25, Vladimir Jovic <vladasp...@gmail.com> wrote:
> > >> Michael Doubez wrote:
> > >>> On 21 d c, 09:59, Vladimir Jovic <vladasp...@gmail.com> 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 :).
--
Michael
tanix
>On 22 d=E9c, 09:21, Michael Doubez <michael.dou...@free.fr> wrote:
>> > >> Michael Doubez wrote:
>> > >>> On 21 d c, 09:59, Vladimir Jovic <vladasp...@gmail.com> wrote:
>> > >>>> Andy Champ wrote:
>> > >>>>> Eric B se-Wolf wrote:
>> > >>>>>> [lots of sarcasm snipped]
>> > >>>>>> So it all depends on experience?
> 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.
>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.
>>
>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 :).
--
tanix
>:--}
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?
tanix
Here is something you, great software designers better know about:
"We need a program of psychosurgery and
political control of our society. The purpose is
physical control of the mind. Everyone who
deviates from the given norm can be surgically
mutilated.
The individual may think that the most important
reality is his own existence, but this is only his
personal point of view. This lacks historical perspective.
Man does not have the right to develop his own
mind. This kind of liberal orientation has great
appeal. We must electrically control the brain.
Some day armies and generals will be controlled
by electrical stimulation of the brain."
-- Dr. Jose Delgado
(MKULTRA experimenter who demonstrated a
radio-controlled bull on CNN in 1985)
Director of Neuropsychiatry, Yale University
Medical School.
Congressional Record No. 26, Vol. 118, February 24, 1974
Dig?
Michael Doubez
Please spare us the cheap spirituality: the act of creation is very
rare and doesn't have its root in the self as you claim it. Otherwise
there would be more poets and artists.
While you can influence your environment, the first step is always to
adapt to its current state, otherwise your actions will miss the
point.
I think your are mistaken in the various levels of being.
> You CREATE your wold as you go.
There is a name in psychology for that specific pathology.
> 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.
I recognize the gap between my internal world which is infinite and
timeless and the external world which is bound by time, matter and
energy.
I adapt to this gap and align my energies with the current state of
the world, as I perceive it, to reach my goals.
> [snip blather]
> You need more?
More words ? Certainly not, you've drowned us with them already.
> Or it would be enough to activate some latent neurons
> in your cockpit?
Yes. I come to my sense and won't waste more time on this thread.
--
Michael
dragan
"Pete Becker" <pe...@versatilecoding.com> wrote in message
news:vs2dnc3GxOL6pLDW...@giganews.com...
> James Kanze wrote:
>>
>> 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.
>>
>
> 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.
>
Both allude to what I think are very relevant concepts and not just
folklore: that the larger scope of someone's experience and knowledge is
very important in graduating to an advanced level of designing/architecting
capability.
dragan
"Eric "B�se-Wolf"" <er...@boese-wolf.eu> wrote in message
news:7p3lqh...@mid.individual.net...
>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.
>
> to some sort of software architecture.
Many approaches are possible of course. Fundamental knowledge is the
starting point IMO: read the pattern books and such, study existing systems
and software from a high level (rather than doing something like loading GCC
source code in your IDE), use Doxygen to analyze source code at a high
level, pay attention to how things interact (the "interfaces") rather than
the things themselves, avoid large team development roles if you can (you'll
get buried in the details rather than gain high-level perspective), create
entire application programs but do start with the pen and paper and circles
and arrows and such, way before writing any code. Do not write a whole book
of documentation before doing some iteration and feasibility studies, but do
write important things down in additon to your "circles, boxes and arrows"
or you will forget your decision-making path come implementation time.
"Jumping in with both feet" is OK, but some amount of study and THINKING
(design is more thinking than annotating) is prudent. Don't OVER-study the
commonly tauted "principles" either: you'll get to know the trade-offs and
when they apply by doing (designing and architecting, that is). Most of the
"principles" are not documented or available to read about, realize, as
experienced designers/architects draw from the larger wealth of knowledge
and experience rather than the much smaller scope that is Information
Technology.
(This is the most key point IMO: designers/architects are born, not made or
taught. If you are asking how to be one, maybe that is a sign). Know
yourself: designers find it natural to design. They create the patterns
rather than go out and look for them. Are you "a picture person"? Or do you
prefer to read/listen? Some people, perhaps most, are better at filling in
the details of a good design/architecture. Then again, some people are so
high level that their designs are not practical (cannot be implemented).
Practicality vs. extremism seems to be a big problem in SW engineering (I
think STL is the latter, for example).
Distinguish between "high-level" design and "low-level" design. The former
should be pretty much devoid of programming language peculiarities.
Build small systems and application programs first. Large systems have
specialized skill requirements but they are IN ADDITION to the stuff you
learn from building complete small systems/programs thoroughly. Taking
programs that you have already developed and "rearchitecting" or
"refactoring" them is a good starting point, for you are already have a lot
of useful information about the domains (plural).
Avoid the formal methods and stick with pen and paper (or an appropriate
graphics program). The programming-specific tools and methods are for
low-level design the ill-fated attempts at creating the proverbial "software
factory" on-the-fly (read, project work/"general SW dev").
Designing/architecting is a creative process and as such it is not conducive
to highly-structured "methods" or management (those things stifle
creativity). Your rate and patterns of creativity are just that: highly
personal: you probably can't turn it on and off like a light switch all the
time. Some days you will be highly motivated and creative and other days you
will plod along drudgerously.
Architecting the system doesn't qualify one to manage the project, realize.
Realize too that it doesn't preclude that: "ownership is nine-tenths of the
law". I've never seen a project run by someone from a business background
devoid of technical background be nearly as successful as it could have been
if someone with an engineering background was running the show (requisite
management skill are still required of course). Business rule implementation
sits on top of architectural technical foundation, NOT the other way around.
Finally, don't do it my way, do you your way! Good luck.
Mick
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>> "dragan" <spamb...@prodigy.net> writes:
>>> Finally, don't do it my way, do you your way! Good luck.
>
> The idea to do an �up-front design� and then implement
> this, actually is the waterfall method.
>
> It is not totally broken, but only works sometimes for
>
> - small or simple projects with a fixed set of requirements or
>
> - projects of the kind one has already done very often
> (here �experience� comes in).
>
While literally correct that Waterfall is one good SDLC method. I
suspect the OP was looking for: "How do I convert this application
concept/idea into working code?".
Rather than "How do I design the entire development process for this
company?".
tanix
Very good. Not far from being right on the money.
> If you are asking how to be one, maybe that is a sign).
People think that sw design is like a skill you aquire in some school,
like a plumber or machist.
Yes, you CAN aquire plenty of knowle, but the whole art of it
will be missing.
> Know
>yourself: designers find it natural to design.
Yep. In fact it is not a "job" to them. It is something they get the
kicks out of. It is some necessity to them, like an oxygen.
> They create the patterns
>rather than go out and look for them.
Correct. When someone talks to me about "design patterns".
I tell them: I CREATE them and I created plenty. So far, did not
see an area where I would not feel comfortable with.
Sure, you can read the patterns from some book and blindly apply
them anywhere you can find a place to stick them on. But all of
it is artificial. It won't necessary be that, which is truly
requiered by your situation.
There are ALL sorts if issues with patterns, down to issues of
debugging. Some time ago, I needed the web crawler. So I found
some nice piece of code that looked promising. It did do most
of what I wanted. But it did have some pretty bad shortcomings.
It was using the visitor pattern.
The code was totally undocumented and I spend WEEKS trying
to understand all the intricacies. When I was debugging it,
it was a nightmare. You are totally event driven and the
environment is totally async. You don't even know where
to set the breakpoints, and even if you single step through
the whole thing, it is such a major headache, that it takes
you at least 10 times more time and effort.
And THAT is the reason I suspect that powerful and beautiful
piece of code was eventually abandoned and author stopped
maintaining and improving it. Becaues we got overloaded with
the complexities of it to the point that it was ubearable.
So, the visitor patern in the async, event driven state machine
is a disaster. And so I saw with other patterns.
People think that patterns is some kind of paradise.
Nowadays, about the fist question you are asked on the
interview is: do you know design patterns?
And if you don't, you are some kind of clueless idiot to them.
You won't have a chance in most places.
What a joke.
> Are you "a picture person"? Or do you
>prefer to read/listen? Some people, perhaps most, are better at filling in
>the details of a good design/architecture. Then again, some people are so
>high level that their designs are not practical (cannot be implemented).
>Practicality vs. extremism seems to be a big problem in SW engineering (I
>think STL is the latter, for example).
Yep, plenty of new "technologies" in the sw business could be classified
as extremism. The overkill and overload with complexities probably not
helps anything at the end, but creates more problems than it solves.
To me, your code should be readable like a news article.
You should be able to understand ANY piece of code within seconds,
and not sit there for hours, trying to comprehend all the nasty
details, going as far as spending minutes if not hours just to
understand the parameters of some method. I saw some code that is
basically unreadable, unless you are willing to spend HOURS,
and even there it is not clear you will see all the intricacies
of it.
People do not have that time nowadays.
On the top of it, those complications essentially do not buy
you anything. The bang for the buck is as low as it gets, and
the costs of code maintenace and expanstion is immense.
Quite often, people create overly complicated things just to
show others how "great" they are, which is basically the result
of complex of inferiority.
>Distinguish between "high-level" design and "low-level" design. The former
>should be pretty much devoid of programming language peculiarities.
One of the things I remember from my early days of programming
was this recepie:
Top down design and bottom up implementation.
That is probably the most valuable overall rule for sw development.
I intuitively use it more often than not.
Once you have your low level stuff worked out and working,
it makes it a breaze to hang higher level stuff on the top of it.
>Build small systems and application programs first. Large systems have
>specialized skill requirements but they are IN ADDITION to the stuff you
>learn from building complete small systems/programs thoroughly. Taking
>programs that you have already developed and "rearchitecting" or
>"refactoring" them is a good starting point, for you are already have a lot
>of useful information about the domains (plural).
Basically, I consider it the issue of modelling.
By creating a model, you will be able to test it and see all sorts
of things that you could not even expect before you started.
And I mean MOST of it, no matter who says what.
Then you can SCULPT your project. I do not program, I SCULPT it
like a sculpture.
From the first days on a project, this thing becomes alive.
So, you never end with doing ALL sorts of things without even
knowing if your entire concept is correct and your house does
not end up "being built on sand", and quite literallly at that.
From the first days, your creation should be alive.
So you can see its freakingess, its weakenesses, its beauty.
It should sing or hum as Rolls Royce, every step of the way.
>Avoid the formal methods
I do agree with this one.
> and stick with pen and paper (or an appropriate
>graphics program). The programming-specific tools and methods are for
>low-level design the ill-fated attempts at creating the proverbial "software
>factory"
Correct. Those "factories" are some of the biggest pain on the
neck that do not necessarily buy you anything, but give you ALL sorts
of headaches and make it more difficult even for you to understand
your code.
> on-the-fly (read, project work/"general SW dev").
>Designing/architecting is a creative process and as such it is not conducive
>to highly-structured "methods" or management (those things stifle
>creativity).
Correct. They simply eat MOST of your energy on constanly worrying
about things, that you never have to worry about.
I can produce immence improvements in my projects in a matter
of days. In few days, I sometimes add some much new functionality,
that it becomes a problem to even verify it all, even thogh it
all works pretty much out of the box.
And debugging and making it more robust becomes more or less
an idle excersize because it flows by itself. No headaches.
That is when you can take a break and take it easy.
Debugging mostly becomes a verification procedure to make sure
ALL the error conditions have been handled without being lazy
or sloppy about something that "can not happen in 'REALITY'".
> Your rate and patterns of creativity are just that: highly
>personal:
Correct.
> you probably can't turn it on and off like a light switch all the
>time. Some days you will be highly motivated and creative and other days you
>will plod along drudgerously.
Well, for me, for MAJOR architectural decistions and design
"patterns", it is a process of MATURING.
This process sometimes takes MONTHS untill it all finally
falls into place. I never try to write a piece of code that I can
put a final dot on it. So, no need to overstress yourself perfecting
something, that is not totally clear from the standpoint of
system as such and ALL sorts of most subtle interactions,
the issues of efficiency, compactness, robustness and you name it.
>Architecting the system doesn't qualify one to manage the project, realize.
>Realize too that it doesn't preclude that: "ownership is nine-tenths of the
>law". I've never seen a project run by someone from a business background
>devoid of technical background be nearly as successful as it could have been
>if someone with an engineering background was running the show (requisite
>management skill are still required of course). Business rule implementation
>sits on top of architectural technical foundation, NOT the other way around.
>
>Finally, don't do it my way, do you your way! Good luck.
--
tanix
One of things you learn with music is to deal with abstractions.
Second thing you learn is to trust yourself with improvisation.
That gives you a subconscious hint that things are still possible
even if you don't "know" which note to play next, how long and
loud, with what accentuation, with what sustain and decation,
with what tone and according to what rythm, manifest or implied.
This an immense amount of "information processing".
It is like walking on a mine field, never knowing what your next
step is going to be, a step to life or the end of your trip.
And, some people, miraculously still can walk on the mind field.
In fact it is a daily job for them.
With music, you learn now to construct objects.
It is forever a process of construction.
You also learn the principles of harmony and principles of
melody (the equivalent of sequential logic).
Plus, you learn to be a PART of the whole orchestra
and see how your playing fits into the whole piece of music.
And the grandest thing of all, you learn EXTACY.
Extacy with existance. An orgasmic feeling with life.
Something that feeds your very soul,
gives you a taste of the very JUICE of life.
Without it, you are like a machine, more or less,
programmed with knowlege to follow someone elses path,
but not your own. You never learn the very joy of existence.
In fact, you don't even have time to even recognize it
when it comes, being forever busy, trying to forever jump
higher than your own weanie, without realizing it is simply
an impossibility. Thus frustration. The grandest frustration
of all - not being able to express yourself, accept yourself
as you are and trust yourself as something PERFECTLY valid,
no matter what who says what and no matter how much you
yourself doubt your own validity.
Cool, eh?
:--}
James Kanze
> In article <hgoo4v$lk...@news.eternal-september.org>,
> ta...@mongo.net (tanix) wrote:
[...]
> Real programmers are those, who DON'T ship!!!
The actual quote is "real programmers don't eat quiche".
But of course, programmers how don't ship are quickly
unemployed.
> Those, who "ship" write the crappiest code there is.
That's perfect nonsense. All professionals deliver code.
> 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.
And that's also nonsense. Release dates are only established
after discussion with the programmers, and take issues like code
quality into consideration.
> Their documentation sucks. It does not tell you anything
> useful.
Then the product doesn't get through review, and doesn't get
released.
> 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?
Obviously, you've never worked at any professional companies.
--
James Kanze
tanix
>On Dec 22, 9:26 am, ta...@mongo.net (tanix) wrote:
>> In article <hgoo4v$lk...@news.eternal-september.org>,
>> ta...@mongo.net (tanix) wrote:
>
> [...]
>> Real programmers are those, who DON'T ship!!!
>
>The actual quote is "real programmers don't eat quiche".
>
>But of course, programmers how don't ship are quickly
>unemployed.
>
>> Those, who "ship" write the crappiest code there is.
>
>That's perfect nonsense. All professionals deliver code.
True, and that creates the whole industry to hire other
"professionals" that forever fix that stauff.
So, everybody remains gainfully employed.
And that helps. You need a few bux in your pocket once
in a while.
:--}
>> 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.
>
>And that's also nonsense. Release dates are only established
>after discussion with the programmers, and take issues like code
>quality into consideration.
I know, I know.
Heard those "discussions" before.
The way they usually go is:
"we have 3 months to release this thing"
and not a single person on the whole team does even know
what is involved and what kind of nasty details are going
to popup.
Pretty often, when they tell me their "dead" lines,
I say, oh shitski, this is going to be a trip!
>> Their documentation sucks. It does not tell you anything
>> useful.
>Then the product doesn't get through review, and doesn't get
>released.
Not necessarily.
You think there is some kind of "panel" from God,
omniscient that produces the objective and realistic deadlines
and specifications? Never seen anything like that.
In about 90% of all cases, just to be safe,
what I saw is either UTTER abscence of documentation
or such arrogant and such useless inline statements,
that most of it is just an insult and has no practical use.
>> 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?
>Obviously, you've never worked at any professional companies.
Well, I gave you a list already. One more time:
Intel.
HP.
SGI.
Amdahl.
Hal Computers (Fujitsu)
and a few others, right smack in the middle of silicon valley.
You've got something MORE "professional" that that?
Who are you kidding?
James Kanze
> James Kanze <james.ka...@gmail.com> wrote:
> >On Dec 22, 9:26 am, ta...@mongo.net (tanix) wrote:
> >> In article <hgoo4v$lk...@news.eternal-september.org>,
> >> ta...@mongo.net (tanix) wrote:
> > [...]
> >> 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.
> >And that's also nonsense. Release dates are only established
> >after discussion with the programmers, and take issues like code
> >quality into consideration.
> I know, I know.
> Heard those "discussions" before.
> The way they usually go is:
> "we have 3 months to release this thing"
> and not a single person on the whole team does even know
> what is involved and what kind of nasty details are going
> to popup.
If that's the way it goes, then it's time to change jobs. I
have seen one case of that, but it's rather the exception.
Managers who run their division like that end up on a dead end
siding very quickly.
> >> Their documentation sucks. It does not tell you anything
> >> useful.
> >Then the product doesn't get through review, and doesn't get
> >released.
> Not necessarily.
> You think there is some kind of "panel" from God,
> omniscient that produces the objective and realistic deadlines
> and specifications? Never seen anything like that.
Not from God. Deadlines are negotiated with the implementers,
at least in any well run shop.
--
James Kanze