Lotus Notes / Domino Sonstiges > Aus- und Weiterbildung

Suche dringend Bücher von Nadine Ebel

<< < (4/4)

Gandhi:
Ich kaufe überwiegend zwei Sorten von Büchern:
-Einführungen in bestimmte Themen - oder auch konzeptionelle (sehr allgemeine) Bücher (was weiss ich - zum Thema Algorithmen oder Datenstrukturen oder...)
-sog. Kochbücher - für Dinge, die ich ab und zu mal brauche - aber in denen ich kein Experte sein muss (im Moment z.B. JavaScript - das ich ziemlich selten bis gar nicht brauche - im Moment). Ausserdem lernt man meiner Meinung nach aus Beispielen am schnellsten.

Was ich mir wünsche wären Bücher/Poster, in denen die grundlegenden Sprachkonstrukte aufgeschrieben sind - und dann eine brauchbare Klassenreferenz. Davon gibts meiner Meinung nach zu wenige. Wie ein Programm läuft  habe ich - für meinen Bereich - ganz gut verstanden.
Mich nervt daher dann, wenn ich in einem Buch lesen muss, was Vererbung ist. Ich besitze wenigstens 20 Bücher, in denen steht, was Vererbung ist. Brauche ich echt nicht mehr. Trotzdem: in jedem neuen Buch stehts drin - was die Verwertbarkeit von neuen Büchern auf unter gefühlte 10% senkt.

Dann lieber wirklich konkreteres - wo drin steht, wie ich etwas umsetze. Mit Beispielen.  Sowas gibts dann auch im Internet - auch wenn ich Gedrucktes vorziehe.
Pattern Bücher brauche ich nicht - im Moment - ich glaube nicht, dass solche Themen für meinen Job zur Zeit relevanz haben. Eigentlich schade, dass es so wenige konzeptionelle Bücher im Notes Bereich gibt (ich habe noch keines gefunden) - wo drinstehen sollte, wie man bestimmte Aufgaben am Besten erledigt - worauf zu achten ist etc.

Was mich wirklich nervt sind unkritische Feature Auflistungen - wie auch z.B. in der Notesbible. Da steht dann zwar drin, wie J2LS funktioniert - aber nicht, dass man das besser sein lässt (hierfür nochmal Danke Axel - hat mir vermutlich SEHR viel Ärger erspart). Ehrliche Bücher gibt es ohnehin eher selten...

Zum Thema anspruchsvoll: Es gibt gute und schlechte Entwickler/Admins/.... wobei das dann oft auch nur für den Kontext gilt. Ich bewundere ja z.B. Leute, die in 3 Betriebssystemen 2 Datenbankensystemen und 4 Sprachen Kenntnisse haben. Für meinen Kontext wäre das allerdings weniger nützlich - da ich es ohnehin nicht nutzen könnte. In meinem Bereich bilde ich mir ein mit allen Erfordernissen des Alltags klarzukommen - was vor allem auch bedeutet, mit den Anwendern kommunizieren zu können. Ich glaube da müssten auch noch ein Paar Bücher geschrieben werden. In meinem Job ist die Technik ganz klar nicht das Problem - das Problem ist für mich zu verstehen, was meine Anwender wollen - und auch wie ich ihnen erkläre, dass sie bestimmte Dinge nicht wirklich wollen - oder wie sie mehr Nutzen erreichen können. Allerdings bin ich ja auch im 'Brot und Butter' Geschäft tätig.

flaite:
Es gibt schon eine Menge Bücher zu Requirement-Gathering, Requirement Management, usw.
Gib mal bei Amazon Requirement ein.
Oder Use Cases.
Oder Bücher über Unified Process, agile bzw. xTreme Programming behandeln das Thema auch.

Solche Leute wie dieser freundliche Kanadier: http://www.ambysoft.com/scottAmbler.html wollen ja keine supertheoretischen Abhandlungen schreiben, sondern praktische Hilfen für solche Dinge wie Kommunikation mit dem Endanwender, Prozessmanagement, usw.
Wird das nächste sein, dass ich mir kaufe:
http://www.ambysoft.com/enterpriseUnifiedProcess.html
Er geht auch auf diese Disziplinen ein:
    *  Chapter 4: The Production Phase
    * Chapter 5: The Retirement Phase
    *  Chapter 6: The Operations and Support Discipline

Dein Landsmann hier reviewed manchmal solche Bücher:
http://radio.javaranch.com/val/2005/06.html
oder auch im Mai.
Diesen Monat ein teures Marketing Buch.
Oder das ist vielleicht auch interessant:
http://www.amazon.com/exec/obidos/tg/detail/-/0131407287/002-0196898-1435204?v=glance

Ansonsten:
Man muß schauen, dass man die Anwender nicht überfordert und sich v.a. auch Mühe machen jeden Schritt zu erklären, wenn man Anleitungen herausgibt. Und immer am Ende der Satz: Wenn Sie etwas nicht verstanden haben, bitte rufen Sie mich an.

Und den Anwender nicht von vornerein für blöd halten sondern ihn ernst nehmen.
In größeren Projekten:
- sich Rückmeldungen einholen.
- fitte Leute finden und sich mit denen über bestehende Anliegen informieren

Ich hab auch öfters mit Endanwendern zu tun (zum Glück). Ich trenne aber die Zeiten zwischen für mich komplexerer Entwicklung und reden mit Endanwendern. Für schwierigere Entwicklung braucht man eine gewisse Konzentrationstiefe, die durch telefonieren sehr gestört wird.

Gruß Axel

Navigation

[0] Themen-Index

[*] Vorherige Sete