Wie sieht euer Alltag aus?

Hallo zusammen,

mich interessiert, wie euer beruflicher Alltag als Entwickler aussieht. Wie weit fahrt ihr zur Arbeit, arbeitet ihr eigenverantwortlich, wie sieht euer Team aus, wie lange arbeitet ihr (Überstunden?)

Wie oft habt ihr Meetings usw. freue mich auf eure Antworten. Starte ab 1.11. als Junior, habt ihr Tipps die ihr auf den Weg geben könnt?

Mein Altag? Um 8:00 klingelt der Wecker. Hau den 2-3mal aus und beweg mich dann Richtung Bad. Danach verabschiede ich mich von meiner Freundin und geh aus der Wohnung. Hab etwa 5min Laufweg bis zur Arbeit. In unserem Büro angekommen beleidige ich erstmal unsere QA (wenn die nicht erster sind) und setz mich an meinen Platz. Unser Team is mehr oder weniger eigenverantwortlich. Teamlead gibt es nicht. PO, QA, DEV und ScrumMaster sind alle im selben Büro (bei einer Teamgröße von derzeit 7 Leuten gut machbar ohne Lärm). Zum Mittagessen geh ich heim - meistens wartet da dann auch meine Freundin schon mit irgendwas gekochtem auf mich. Meine Arbeit läuft auf Vertrauen - ich buche meine Stunden auf Tickets und bin selber verantwortlich - wie und wann ich arbeite. Überstunden sind möglich, liegt dann bei mir diese abzubauen. Ich baue meistens unter der Woche ein paar auf und geh dafür freitags zeitlich heim.

Meetings sind immer so ein Thema. Hab etliche im Kalender stehen, aber gehen tu ich nur zu denen, die in meinen Augen wichtigen sind. Ich empfinde Meetings diese eher als störend. Vor allem wenn sie das ganze Team binden (meistens ist ein Meeting mit weniger Leuten effektiver). Wenn du in einem Scrum-Team arbeitest, dann wirst du vermutlich folgende Meetings haben (mind.):
Planning 1 & 2 (Darin wird festgelegt, was das Team in den nächsten X-Wochen [Sprint] erreichen will)
Grooming (Aufgaben durchsprechen)
Retro (Besprechen wie der Sprint gelaufen ist - Verbesserung ausfinding machen).
Show&Tell (zeigen was man im Sprint gemacht hat)
Daily: man spricht über die aktuellen Fortschritte.

Daily ist täglich, Planning ist am Sprint-anfang, Retro + Show&Tell am ende und Grooming mind. 1x die Woche (so zumindest bei uns).

Sei Lernbereit & Kritikfähig. Du kannst viel von deinen Kollegen lernen und ich gehe mal von aus, dass sie sich auch darauf einstellen, dir einiges beibringen zu dürfen (zumindest würde ich das tun, wenn wir einen junior einstellen würden).

1 „Gefällt mir“

Mich nervt nichts mehr als Berufsanfänger die glauben, sie haben die Weisheit mit Löffeln gefressen. Nichts gegen gute Ideen und Vorschläge aber meistens ist Reden (und vor allem ohne vorher zu denken) noch nicht mal Silber. Die Routine bestimmte Dinge zu durchblicken kommt schon noch. Zuhören, lernen und sich selbst hinterfragen zu können sind meine Tips. Blender die laut ihre Meinung verkünden gibt es nämlich zu Hauf. Leider werden die auch noch teilweise belohnt.

1 „Gefällt mir“

Danke euch. Lernfähig und- willig bin ich, kritikfähig in wie fern? Dass man mit einer Kritik umgeht statt direkt versucht sich rauszuwinden oder gegen schießen? Wenn mich jemand vernünftig kritisiert hab ich kein Problem, aber der Ton macht die Musik.

Hab ein bissl Bammel, dass meine Erfahrung nicht reicht. Aber als Junior kann es sein, dass man noch gar nicht programmiert hat außer im Studium oder? Also Solche gibts oder? Da bin ich schon etwas weiter als ein frisch Ausstudierter.

Ist mein erster Jobwechsel nach 13 Jahren, hoffe ich bin nicht zu festgefahren, muss mich sicherlich auf vieles neues einlassen.

Lass dir keine Vorwürfe machen, das sollte wohl eine, was wäre wenn oder hätte hätte, sein. Keine direkte Unterstellung, nehme ich einfach mal an. Aber, was stimmt, ist, dass zu wenig fragen, ist genauso schlimm wie zu viel fragen.

Was ich als Tipp mitgeben kann: Die Netiquette im Projektmanagement immer einhalten! :slight_smile:

Selbst mit vernünftiger Kritik können nicht immer alle umgehen. Vor allem wenn es halt mal mehr am Code auszusetzen gibt oder Erfahrungen in Frage gestellt werden, die man selber für richtig hält.

Titel (Junior, Senior) sind wenig Aussagekräftig. Ich hab hier schon Lebensläufe vor mir gehabt wo die Person frisch von der Uni kam und direkt als Senior eingesetellt wurde (was für mich ein Junior wäre). Aber ich denke im allgemeinen dürfte die Erwartungen beim Junior (im Gegensatz zum Senior) recht gleich sein: letztendlich ein besserer Azubi.

Falsch! Von einem Junior würde ich viele Fragen erwarten. Das wäre für mich niemand, der selbstständig am Projekt mitarbeitet (außer vllt kleinere Tasks). Du solltest auch keine Angst vor fragen haben. Warum ist einfach erklärt: die bringen dich voran und dein Team weiß, wo es dich unterstützen kann. Das liegt in eurem beider Interesse, denn als Junior bist du - krass gesagt - erstmal ne Belastung fürs Team. Das Team muss Ressourcen aufwenden um dich zu trainieren.
Nur solltest du auch fähig sein google zu benutzen! Es ist nervig, wenn man aus seiner Arbeit rausgerissen wird - wenn google dir die antwort direkt liefern kann. Ansonsten gibt es mehr als genug Themen die dir Google nur schwer/schlecht oder überhaupt nicht beantworten kann, wenn es zu Firmen-intern wird. Was natürlich auch nicht gut kommt, ist wenn man immer wieder die selben Fragen beantworten darf.
Könnte jetzt vllt etwas abschreckend klingen - aber so schlimm ist es nicht. Selbst wenn man mal kacke gegoogelt hat. Wenn mir die Person sagt, wie sie google verwendet hat, dann kann ich vllt auch im Umgang mit Google helfen.

Dazu bemerkt: Bei mir kommt es immer ganz schlecht an, wenn jemand die selben Dinge immer wieder und wieder fragt. Schreib es dir auf!

Aber damit das nicht nur so ein negativer „Tu das bloß nicht“ Thread wird: Generell keine Panik, bei den wenigsten Betrieben gibt es Leute die Juniors rund machen, wenn mal etwas nicht funktioniert.

[quote=„NicoDeluxe, post:1, topic:19556“]
mich interessiert, wie euer beruflicher Alltag als Entwickler aussieht. Wie weit fahrt ihr zur Arbeit, [/quote]

40km

[quote]arbeitet ihr eigenverantwortlich,[/quote] So einigermaßen. Manchmal machen wir Pairprogramming. Fertiger Code muss immer durch das Code Review.

1 Frontend-Entwickler (sollten eigentlich 2 sein, wird wohl auch wieder aufgefüllt), 4 Backend-Entwickler, 1 Product Owner, 1 Product Manager, 1 QA. Also agile und Scrum, relativ normal. Und international (1 Ukrainer und 1 Südafrikaner) - wie die Firma insgesamt (Hauptsitz in San Francisco), deshalb viel Englisch.

Überstunden habe ich kaum, werden auch schnell ausgeglichen. Arbeitszeiteinteilung ist sowieso recht frei, Homeoffice möglich…

Zu oft, vielleicht 4 pro Woche.

Fragen, zuhören, lernen. Es gibt Dinge, die man an der Uni nicht lernen kann, für die man ein Gefühl entwickeln muss, also ruhig mal den alten Hasen vertrauen. Andererseits nicht vergessen, dass die anderen auch nur mit Wasser kochen, also auch nicht in Ehrfurcht erstarren.

Zum Thema Alltag:
spätestens 7:00 Uhr steht ich auf und dann gehts entweder mit Öffis (ca. 45Minuten) oder mit Auto (ca.15 Minuten in Fahrgemeinschaft) zur Arbeit.
ca. 8:00 Uhr bin ich im Büro, erstmal werden alle begrüßt die schon anwesend sind. Dann PC anschalten und mir einen Tee machen.
ca. 8:15 Uhr: erstmal Mails checken, ob irgendwas in der Dringlichkeit gestiegen ist und mein Kanban-Board anpassen.
ca. 8:30 Uhr: anfang mit der tatsächlichen Arbeit.
ca. 11:00 Uhr Daily Standup im Anschluss gehts zum Supermarkt oder Imbiss in der Mittagspause
ca. 16:30 Uhr geplanter Feierabend

Zur Zeit ist bei uns Mittwochs der Besprechungstag. Vormittags gibt es eine interne Runde um uns auf dem Kunden-Termin am Nachmittag vorzubereiten. Mit dem Kunden werden dann nacheinander 5 Projekte besprochen, was eine Vorbereitung notwendig macht.

Zum Thema Team:
Aktuell bearbeite ich ein Projekt als Entwicklerin alleine, ich habe nur Unterstützung vom Projektleiter was Abstimmungen mit dem Kunden angeht. Dabei programmiere ich nicht nur sondern erstelle auch mal erst ein Konzept oder entwerfe die Architektur. Das ist aber immer abhängig vom Projekt. Zu meinen Aufgaben gehört aber auch das Projekt zu dokumentieren für Entwickler und Supporter. Anwender-Doku wird von anderen kollegen geschrieben.
Normalerweise sind aber 2-5 Entwickler in einem Projekt beschäftigt, dazu kommen dann noch 1-2 Tester und Anwendungsbetreuer.

Bei uns wird aktuell vom Wasserfallmodell auf agile Entwicklung umgestellt. Deswegen nehme ich am Standup teil habe aber sonst keinerlei Scrum-typische Meetings.

Tipps zum Start
Eigentlich nur das, was viele vor mir schon gesagt haben: Stelle Fragen!

Ist bei uns nicht anders. Hauptsitz ist zwar Malta aber ich sitz hier in unserem Büro in Karlsruhe. Dennoch auch hier sehr international (alleine unser Team: Katalonien, England, Indien, Russland, Finnland, Badenzer). Glaub bei so jeder größeren Firma auch in DE verlagert sich die Amtssprache (langsam) Richtung Englisch.

Ach krass, d.h. du bist kein Studiabgänger etc sondern hast schon Arbeitserfahrung? Woher kommst du denn? Lässt vieles vll. leichter beantworten.

Dieses Senior/Junior sehe ich auch kritisch. Hatte die Chance bei ner Big4 Unternehmensberatung anzufangen und sollte den Bereich IT Security in einem relativ großen Geschäftsfeld von denen komplett von 0 an aufbauen. Einstufung sollte aber Junior sein, da ich die ganzen Seminare ja machen müsste. Inklusive Berufsanfängergehalt.

@anon94273153 wohne ca 50 km von Dresden, also ossi:stuck_out_tongue: Ja ich hab ursprünglich in der Logistik Kaufmann gelernt, wusste aber schon seit meinem ersten v tech Lern Computer, mit 10 Jahren :stuck_out_tongue: dass ich was mit Computern machen wollte. Hat sich aber leider nicht ergeben, weil ich mit 15 von der Schule bin (reslschulabschluss mit abiberechtigung) wollte aber was lernen und Geld verdienen. Computerfirmen hab es da bei uns in der Gegend keine. Hab dann ein Fernstudium Java Entwicklung gemacht und mein erstes kommerzielles Projekt auf die Beine gestellt um Erfahrungen zu sammeln. Das Projekt läuft bis heute und wird immer mal wieder verbessert. Meinen Logistikerjob hab ich nun nach 13 Jahren aufgegeben.

Hab mich dann auf eine Stelle beworben und Zack, hat geklappt. Die Kollegen waren von meinem Ehrgeiz und Kreativität beeindruckt dass ich das selber erlernt hab etc. Sollte im Gespräch auch etwas Code erklären, halt ganz simpel schleifen erklären oder erklären ob die for schleife anders als normal geschrieben werden kann. Da haben Sie zwar gemerkt, dass ich nicht alles kann wie ajax etc, waren uns aber ziemlich einig, dass ich das lernen werde wenn mir was fehlt.

Frag mich nur wie man in ein Projekt rein kommen soll, dass geht ja nur durch fragen stellen. Wird schon hart werden, auch für die Kollegen :wink:

Achso zum Thema google, das beherrsche ich aus dem FF:smiley: hatte in meinem Projekt niemanden außer google & Stackoverflow. Im Gespräch wurde mir gesagt, dass das Team die erste Anlaufstelle ist bei Fragen. Wird bestimmt spannend in einem professionellem Team zu arbeiten

Ja klingt doch cool deine Entwicklung. Fragen sind wirklich kein Problem aber es darf sich tatsächlich nicht doppeln (daher immer notieren) und man muss erkennen, dass du dich an Google etc versucht hast. Auf der anderen Seite auf keinen Fall zu selbstständig zu sein und alles alleine machen wollen. Geht nämlich manchmal/meistens schief, gerade am Anfang, weil man einfach etwas falsch verstanden hat oder dein Chef/Kollege was anderes gemeint hat. Ich würde mich da wirklich nicht bekloppt machen. Was du schreibst klingt realistisch genug um eine gute Zeit zu haben.

1 „Gefällt mir“

Das beruhigt mich Danke :slight_smile: ich frage sowieso immer lieber nach. Da ich in meiner bisherigen Arbeit auch immer mal neue Leute einlernen musste, weiß ich zu gut dass doppelte fragen nerven! Oder gewisse Sachen wie Irgendwelche Funktionen in einer Software nicht notiert werden und ich weiß in 1 Stunde kommt die Frage wo das und das zu finden ist, da könnte man dezent ausrasten :smiley:

Das mit den doppelten Fragen kann,wirklich nerven, solange man nicht nach weitere Klarifikation eines Problems fragt und dabei es sich nicht um die vorherige Frage handelt. Selbst als Student fühlt man sich leicht genervt, wenn jemand in der vorherigen Vorlesung nicht da war und den Stoff der letzten Vorlesung einzelnen Fragen erfragt. Es wäre wahrscheinlich sinnvoller direkt eine Zusammenfassung der letzten Vorlesung fragen, damit der Dozent in seinem Redefluss weniger unterbrochen wird. Oder wenn dann halt nach der Vorlesung noch gefragt wird.

Guten Morgen,

Aber nicht ohne den strafenden Blick seiner Mitstudierenden. :thinking: Mich stört’s nicht so, aber es gibt natürlich auch komischere Sachen, die dann evtl doch stören:

Youtube voll damit, jetzt nur ein paar rausgesucht, die ca 1 Mio. Aufrufe habn.

Hallo ihr lieben, ersten Tag überstanden. Wahr sehr spannnend, das Team wirklich nett! Nun muss ich blos irgendwie in den Code kommen, fängt schon an dass eine xhtml ein ui:include hatten wo eine andere Datei, mit einem relativen Pfad eigebunden wird. Zb /Core/bla/bla/Datei.xhtml Diese eingebundene Datei find ich blos nirgendwo :man_facepalming: Gibts in eclipse ne suche nach Dateien? Ich vermute dass wir etwas nicht ausgechecked haben.

Wie steigt ihr in Code ein? Ich finde das ist die größte Schwierigkeit aktuell

Hi :wink:

GZ zum (neuen/ersten?) Job.

Früher dachte ich, dass ich niemals durch fremden Code durchsteigen könnte. Weil man in den hunderttausenden Codezeilen einfach keinen Überblick hat.

Heute gehe ich das anders an. Statt durch den Code zu navigieren lasse ich mir zunächst die Architektur beschreiben. Kann man die einzelenen Code Fragmente bestimmten Modulen zuweisen und kennt dabei die angrenzenden, dann sind schon die Brocken, die man verstehen muss nur noch ein 1/1000 groß :wink:

Schöne Grüße

Martin

Fluchend und schreiend und die Firma, von der der Code kommt den Untergang wünschend.

Und wenn das nicht hilft: Kollegen fragen. Gerade wenn jemand neu bei uns anfängt, dann bekommt derjenige einen Mentor an die Seite, welcher auch dann meistens Pair-Programming mit dem neuen macht.
Wenn du da Schwierigkeiten hast, bei etwas durchzusteigen, dann frag. Je nach Firma gibt es ja auch unterschiedliche Guidelines was den Code angeht. Da kann dir dann ein Kollege auch bei helfen diese einzuhalten und ggf. zu erklären wenn etwas unklar ist.