Πως σας δίνουν τι απαιτήσεις; Να σκεφτώ να αλλάξω επάγγελμα ή χώρο εργασίας;

[PC_MAGAS]

Καλησπέρα συνάδελφοι συνdevelopers,
Ευτυχώς είμαι σε μια αρκετά μικρή εταιρεία (Το μόνιμο προσωπικό είναι 2-3 άτομα και απασχολεί ΠΟΛΟΥΣ πρακτικάριους κατα καιρούς) και βγάζω το ψωμί μου δια μέσω development.

 

Έχω μια απορία, στον χώρο εργασίας πως σας έρχονται οι απαιτήσεις σας σκάνε η μια πίσω από την άλλη ειδικά στο UI. Δηλαδή για να γίνω ποιο κατανοητός κάνετε ένα κομμάτι κώδικα ειδικά HTML CSS και JS και εφόσον ξεσκιστήκατε και το δείξατε σας είπε ότι δεν το θέλει ενώ πολλές φορές δεν έχει ιδέα ο πελάτης το πως θέλει το UI και το αφεντικό (που δεν έχει ΙΔΕΑ από dfevelopment) να πει ξήλωσέ το δεν το θέλω.

 

Ακόμη οι ρυθμός που δίνονται οι απαιτήσεις που πρέπει να υλοποιήσω που μου σκάνε σε απροσδόκητο χρόνο ακόμη και όταν κάνω development και έτσι μου τρώει χρόνο από το να υλοποιώ την εφαρμογή του πελάτη.

 

Θέλω να ξέρω αν αυτά εφαρμόζονται όχι μόνο στο μαγαζάκι στην γωνιά που κάνει σελίδες αλλά και σε μεγάλη εταιρεία στο Εξωτερικό. Σε εταιρίες όπως Mozilla, Red Hat, Novell πως σερβίρονται οι απαιτήσεις και ποιο workflow ακολουθάτε, δηλαδή ποια βήματα ακολουθούνται από την καταγραφή της απαίτησης μέχρι την υλοποίηση σε κώδικα; Πως καταγράφονται οι απαιτήσεις σας δίνονται με το σταγονόμετρο ή ξοδεύςεται ένα Χ χρόνο για καταγραφή ταξινόμηση των απαιτήσεων και δημιουργία μακετών για UI. Γιατί εκεί που έποιασα δουλειά απλά κάνω κάτι το παρουσιάζει και μου λέει να υλοποιήσω χ-ψ αλλαγές και τις κάνω αλλά είναι ΕΚΝΕΥΡΙΣΤΙΚΟ δηλαδή ουσιαστικά σκάνε αλλαγές και απαιτήσεις να υλοποιήσω και δεν έχω χρόνο να εκπαιδευτώ σε θέματα όπως Desighn Patterns και Unit Testing.

 

Ακόμη πως θα ξέρω αν αυτό που κάνω είναι καλή ποιότητα και από άποψη κώδικα αλλά και από άποψη ότι είναι ασφαλές και robust εφαρμόζοντας unit testing (που έχω 0 εμπειρία σε αυτό). Να πω την αλήθεια χρειάζεται Unit Testing πάντα δηλαδή είναι αναγκαίο να κάνεις σε ένα κομμάτι κώδικα Unit testing ανεξάρτητα αν είναι μεγάλο η μικρό project και βοηθάει στο να παράγεις ένα quality Product.

 

Γι αυτό αξίζει να ξενιτευτώ για να ποιάσω μια ενδιαφέρουσα και λαυλωτική δουλειά σε Novel, RedHat, Canonical αλλά ξητάνε κυριώς senior δεν είδα θέση Junior ή και σε μια non-developer θέση εργασίας πχ. να αρθογράφω tutorials σε blog ή περιοδικό εξάλου έχω γράψει ένα χ όγκο άρθρων περί τεχνολογίας στο blog μου: http://pcmagas.wordpress.com

[Papakaliati]

Καλησπέρα συνάδελφοι συνdevelopers,

Ευτυχώς είμαι σε μια αρκετά μικρή εταιρεία (Το μόνιμο προσωπικό είναι 2-3 άτομα και απασχολεί ΠΟΛΟΥΣ πρακτικάριους κατα καιρούς) και βγάζω το ψωμί μου δια μέσω development.

 

Έχω μια απορία, στον χώρο εργασίας πως σας έρχονται οι απαιτήσεις σας σκάνε η μια πίσω από την άλλη ειδικά στο UI. Δηλαδή για να γίνω ποιο κατανοητός κάνετε ένα κομμάτι κώδικα ειδικά HTML CSS και JS και εφόσον ξεσκιστήκατε και το δείξατε σας είπε ότι δεν το θέλει ενώ πολλές φορές δεν έχει ιδέα ο πελάτης το πως θέλει το UI και το αφεντικό (που δεν έχει ΙΔΕΑ από dfevelopment) να πει ξήλωσέ το δεν το θέλω.

 

Ακόμη οι ρυθμός που δίνονται οι απαιτήσεις που πρέπει να υλοποιήσω που μου σκάνε σε απροσδόκητο χρόνο ακόμη και όταν κάνω development και έτσι μου τρώει χρόνο από το να υλοποιώ την εφαρμογή του πελάτη.

 

Θέλω να ξέρω αν αυτά εφαρμόζονται όχι μόνο στο μαγαζάκι στην γωνιά που κάνει σελίδες αλλά και σε μεγάλη εταιρεία στο Εξωτερικό. Σε εταιρίες όπως Mozilla, Red Hat, Novell πως σερβίρονται οι απαιτήσεις και ποιο workflow ακολουθάτε, δηλαδή ποια βήματα ακολουθούνται από την καταγραφή της απαίτησης μέχρι την υλοποίηση σε κώδικα; Πως καταγράφονται οι απαιτήσεις σας δίνονται με το σταγονόμετρο ή ξοδεύςεται ένα Χ χρόνο για καταγραφή ταξινόμηση των απαιτήσεων και δημιουργία μακετών για UI. Γιατί εκεί που έποιασα δουλειά απλά κάνω κάτι το παρουσιάζει και μου λέει να υλοποιήσω χ-ψ αλλαγές και τις κάνω αλλά είναι ΕΚΝΕΥΡΙΣΤΙΚΟ δηλαδή ουσιαστικά σκάνε αλλαγές και απαιτήσεις να υλοποιήσω και δεν έχω χρόνο να εκπαιδευτώ σε θέματα όπως Desighn Patterns και Unit Testing.

 

Ακόμη πως θα ξέρω αν αυτό που κάνω είναι καλή ποιότητα και από άποψη κώδικα αλλά και από άποψη ότι είναι ασφαλές και robust εφαρμόζοντας unit testing (που έχω 0 εμπειρία σε αυτό). Να πω την αλήθεια χρειάζεται Unit Testing πάντα δηλαδή είναι αναγκαίο να κάνεις σε ένα κομμάτι κώδικα Unit testing ανεξάρτητα αν είναι μεγάλο η μικρό project και βοηθάει στο να παράγεις ένα quality Product.

 

Γι αυτό αξίζει να ξενιτευτώ για να ποιάσω μια ενδιαφέρουσα και λαυλωτική δουλειά σε Novel, RedHat, Canonical αλλά ξητάνε κυριώς senior δεν είδα θέση Junior ή και σε μια non-developer θέση εργασίας πχ. να αρθογράφω tutorials σε blog ή περιοδικό εξάλου έχω γράψει ένα χ όγκο άρθρων περί τεχνολογίας στο blog μου: http://pcmagas.wordpress.com

   Οσο περναει ο καιρος , τοσο καλυτερος θα γινεσαι στο να σχεδιαζεις οσο abstract γινεται τα applications σου. Απο εκει και περα, δεν ειναι δικια σου εννοια αμα τα requirements αλλαζουνε η οχι, η αμα αφιερωσεις χρονο και σχεδιασεις κατι και τελικα ΔΕΝ χρησιμοποιηθει. Μεσα στους κανονες του παιχνιδιου ειναι.

   Εφοσον φανταζομαι δεν πληρωνεσαι ανα εφαρμογη, δεν θα πρεπει να σε απασχολει και πολυ. Και μετα απο λιγους μηνες δεν θα σε απασχολει.

 

    Ειναι το αντιστοιχο με το να εισαι πωλητης σε καταστημα, να δοκιμαζει καποιος 5 ρουχα και τελικα να μην αγοραζει κανενα. Ε δεν σκεφτεσαι να σταματησεις την δουλεια σου για κατι τετοιο. Ξεκαβαλα λιγο το αλογο σου , junior developer εισαι , και κανε την δουλεια που στην τελικη σε πληρωνουνε.

  Οταν θα γινεις senior να απαιτησεις διαφορετικες συνθηκες, αλλα οχι τωρα.  

[PC_MAGAS]

   Οσο περναει ο καιρος , τοσο καλυτερος θα γινεσαι στο να σχεδιαζεις οσο abstract γινεται τα applications σου. Απο εκει και περα, δεν ειναι δικια σου εννοια αμα τα requirements αλλαζουνε η οχι, η αμα αφιερωσεις χρονο και σχεδιασεις κατι και τελικα ΔΕΝ χρησιμοποιηθει. Μεσα στους κανονες του παιχνιδιου ειναι.

   Εφοσον φανταζομαι δεν πληρωνεσαι ανα εφαρμογη, δεν θα πρεπει να σε απασχολει και πολυ. Και μετα απο λιγους μηνες δεν θα σε απασχολει.

 

    Ειναι το αντιστοιχο με το να εισαι πωλητης σε καταστημα, να δοκιμαζει καποιος 5 ρουχα και τελικα να μην αγοραζει κανενα. Ε δεν σκεφτεσαι να σταματησεις την δουλεια σου για κατι τετοιο. Ξεκαβαλα λιγο το αλογο σου , junior developer εισαι , και κανε την δουλεια που στην τελικη σε πληρωνουνε.

  Οταν θα γινεις senior να απαιτησεις διαφορετικες συνθηκες, αλλα οχι τωρα.  

Ναι αλλά δεν θα βόλευε να έχεις και τον μαθουσάλα Senior να σου πει 5 - 10 πράγματα να τα κάνεις σωστά. Ακόμη σε ανάπτυξη εφαρμογών δεν ε'ιναι απαραίτητο το Unit testing;

[ParhsG]

Οταν είναι μικρή η εταιρία συνήθως αυτος που ξέρει περισσότερα κάνει και τα περισσότερα. Προσωπικά εαν δεν είναι δική μου θα απεφευγα να δουλεψω σε μικρή ελληνική εταιρία αν και κανω συνεργασίες αλλά άλλο να πουλάς ένα Χ λογισμικό και άλλο να κάνεις κατι διαφορετικό για κάθε πελάτη!.

 

Οταν είναι μικρή εταιρία μπορεί να μην υπάρχει καν project manager να κάνει το μπλα μπλα με το πελάτη και να κρατήσει τα χρήσιμα / να τα οργανώσει οπότε είναι πιο δύσκολα τα πραγματα. Και σε μεγάλες εταιρίες είναι πιεστικά τα πράγματα αλλά είναι πιο συγκεκριμένη η δουλειά που κάνεις. Πχ για να φτιάξουν το κώδικα για το σύστημα εκτυπωτών στα windows ήταν χωριστή ομάδα με ιεραρχία / είχαν σε ράφια εκτυπωτές και τεστάραν , άλλοι γραφαν κώδικα άλλοι ήταν manager και όλα αυτά μονο για αυτο το κομμάτι.

[PC_MAGAS]

Λοιπόν πρέπει απλά να το χωνέψω ότι έτσι θα είναι και δεν αλλάζει και ο κώδικας μου θα είναι σκ@τα μέχρι να πάω σε εταιρεία όπως Canonical ή Novel. Μάλλον να κάνω κανα cotribute και σε κάνα άλλο project για να με πάρουν.

[paparovic]

Μια μικρή εταιρία δεν μπορεί να έχει ούτε Αναλυτή ούτε Αρχιτέκτονα (τι μεταφράσεις ορολογίας κάνω ο π*υστης  ). Οπότε η δουλειά που θα έκαναν αυτοί πέφτει στους προγραμματιστές ή απλώς καταλήγει στο να κάνουν κύκλους με ράβε-ξήλωνε. 

 

Από την άλλη, το γεγονός ότι δεν υπάρχουν, σου δίνει την ευκαιρία να πάρεις πρωτοβουλίες και να μάθεις. Όπως καταλαβαίνεις, ένα τέτοιο skill θα σου είναι πολύτιμο.

[PC_MAGAS]

Μια μικρή εταιρία δεν μπορεί να έχει ούτε Αναλυτή ούτε Αρχιτέκτονα (τι μεταφράσεις ορολογίας κάνω ο π*υστης  ). Οπότε η δουλειά που θα έκαναν αυτοί πέφτει στους προγραμματιστές ή απλώς καταλήγει στο να κάνουν κύκλους με ράβε-ξήλωνε. 

 

Από την άλλη, το γεγονός ότι δεν υπάρχουν, σου δίνει την ευκαιρία να πάρεις πρωτοβουλίες και να μάθεις. Όπως καταλαβαίνεις, ένα τέτοιο skill θα σου είναι πολύτιμο.

Σε απλάΕλληνικά το ΣΚ εκαπιδεύομαι σε πράγματα για να εφαρμόζω στην δουλειά πχ. Unit testing.

[Papakaliati]

Μια μικρή εταιρία δεν μπορεί να έχει ούτε Αναλυτή ούτε Αρχιτέκτονα (τι μεταφράσεις ορολογίας κάνω ο π*υστης  ). Οπότε η δουλειά που θα έκαναν αυτοί πέφτει στους προγραμματιστές ή απλώς καταλήγει στο να κάνουν κύκλους με ράβε-ξήλωνε. 

 

Από την άλλη, το γεγονός ότι δεν υπάρχουν, σου δίνει την ευκαιρία να πάρεις πρωτοβουλίες και να μάθεις. Όπως καταλαβαίνεις, ένα τέτοιο skill θα σου είναι πολύτιμο.

 Καλε μου φιλε υπαρχουν 2 τροποι να μαθεις. Ειτε να σου δειξει καποιος τον σωστοτερο τροπο στο πιατο, ειτε μονος σου προγραμματιζοντας, και μεσα απο καθε προτζεκτ να βελτιωνεις και κατι. Μετα απο λιγο καιρο θα δεις οτι μπορεις πλεον μονος σου να καταλαβεις ποιος ειναι ο σωστος τροπος να οργανωνεις ενα προγραμμα, με τετοιο τροπο ωστε και τα requirements να αλλαξουνε, εσυ θα μπορεις να το προσαρμοσεις ευκολα σχετικα. 

 

 Οχι δεν χρειαζεται να πας στην google για να μαθεις να προγραμματιζεις, εδω αλλοι το κανανε μονοι τους απο το σπιτι τους για χομπι, και εσυ που πληρωνεσαι κιολας να το κανεις εχεις και προβλημα;

 

Σε απλάΕλληνικά το ΣΚ εκαπιδεύομαι σε πράγματα για να εφαρμόζω στην δουλειά πχ. Unit testing.

 

 Και μαθαινεις κατι (Unit testing) που στο μελλον θα προσμετρησει στην αξια σου σαν προγραμμιστης. 

[we_will_rise]

Τελικά είναι δίκοπο μαχαίρι αυτό το επάγγελμα. Υπό σωστές συνθήκες είναι το πιο ευχάριστο επάγγελμα του κόσμου, υπό τις λάθος είναι σύγχρονα κάτεργα..

[paparovic]

Τελικά είναι δίκοπο μαχαίρι αυτό το επάγγελμα. Υπό σωστές συνθήκες είναι το πιο ευχάριστο επάγγελμα του κόσμου, υπό τις λάθος είναι σύγχρονα κάτεργα..

 

Το τερμάτησες στην υπερβολή. 

[MeTaXaS4]

βασικά δεν παίζει να πας κάπου και να μην αλλάξουν οι απαιτήσεις κατά την διάρκεια του project, μου έτυχε σε project σε παράδοση demo 2 φορές να αλλάξω σχεδόν όλο το σχεδιασμό.

[PC_MAGAS]

Τελικά είναι δίκοπο μαχαίρι αυτό το επάγγελμα. Υπό σωστές συνθήκες είναι το πιο ευχάριστο επάγγελμα του κόσμου, υπό τις λάθος είναι σύγχρονα κάτεργα..

Το τελίκιασες και συ το πρόβλημα είναι αν αυτό πυο κάνω είναι κάτι επαγγελματικο και σωστό η όχι και πως θα αποκτήσω τεχνογνωσία με τον σωστό τρόπο.

 

Απλά με το που σκάνε οι απαιτήσεις νιώθε έναν ελαφρύ εκνευρισμό και δεν ξέρω γιατί και αν μαθαίνω κάτι πως θα το εφαρμόζω στην πράξη.

[defacer]

Δε γίνεται να αναλυθεί αυτό το θέμα εν συντομία, αλλά here goes.

 

Έχω μια απορία, στον χώρο εργασίας πως σας έρχονται οι απαιτήσεις σας σκάνε η μια πίσω από την άλλη ειδικά στο UI. Δηλαδή για να γίνω ποιο κατανοητός κάνετε ένα κομμάτι κώδικα ειδικά HTML CSS και JS και εφόσον ξεσκιστήκατε και το δείξατε σας είπε ότι δεν το θέλει ενώ πολλές φορές δεν έχει ιδέα ο πελάτης το πως θέλει το UI και το αφεντικό (που δεν έχει ΙΔΕΑ από dfevelopment) να πει ξήλωσέ το δεν το θέλω.

Δύο πράγματα: πρώτον, αυτό που υλοποιήθηκε είναι όντως "χρήσιμο" με την έννοια ότι το θέλει (το ήθελε) ο πελάτης; Και δεύτερον, σε κάποιο (όσο πιο οργανωμένα τόσο μικρότερο) βαθμό αυτό συμβαίνει πάντα.

 

Και για τα δύο πράγματα ο ρόλος που έχει την αρμοδιότητα να βάλει γραμμές για να ελαχιστοποιούνται αυτά τα προβλήματα είναι ο product owner/product manager (PM). Αυτός είναι που παίρνει την απόφαση τι ακριβώς θα πρέπει να υλοποιηθεί και με ποιά προτεραιότητα.

 

Σε περιβάλλοντα καφενείου ή μικρές εταιρίες αυτός ο ρόλος δεν καλύπτεται (ή δεν καλύπτεται σωστά) από κανέναν. Στη δική σου περίπτωση τον καλύπτει είτε το αφεντικό σου είτε κανένας απολύτως, με ο,τι αυτό συνεπάγεται. Εσύ δεν μπορείς να κάνεις κάτι σωστό εδώ -- για να μπορείς θα έπρεπε να έχεις τη δυνατότητα να πάρεις τελικές αποφάσεις όπως "αυτό δεν θα το κάνουμε γιατί δεν είναι αρκετά σημαντικό".

 

Οπότε το καλύτερο που ίσως μπορείς να κάνεις είναι να μιλήσεις στο αφεντικό και να τους πεις ότι καταστάσεις τύπου ΧΥ δημιουργούν προβλήματα ΑΒ και αν θα μπορούσαμε σε κάποιο βαθμό να το αποφύγουμε προσπαθώντας να κάνουμε ΓΔ, αυτό θα μας βοηθούσε να έχουμε το αποτέλεσμα που θέλει ο πελάτης πιο γρήγορα. Πρέπει να μιλήσεις με τους όρους που τον ενδιαφέρουν.

 

Ακόμη οι ρυθμός που δίνονται οι απαιτήσεις που πρέπει να υλοποιήσω που μου σκάνε σε απροσδόκητο χρόνο ακόμη και όταν κάνω development και έτσι μου τρώει χρόνο από το να υλοποιώ την εφαρμογή του πελάτη.

Αυτό όπως το ακούω δε θα έπρεπε να έχει σημασία (παρόλο που δεν είναι "σωστό"). Πας να υλοποιήσεις Χ, μετά από αυτό προκύπτει ότι πρέπει να υλοποιήσεις Υ, αυτό σημαίνει ότι ένα μέρος του Χ πρέπει να ξαναγίνει, that's life.

 

Πάντως σα φαινόμενο είναι ανεπιθύμητο και είναι δουλειά άλλων (PM/team lead) να σε προστατέψουν από αυτά για να μπορείς να κάνεις τη δουλειά που πρέπει να κάνεις. "Προστατέψουν" δεν εννοώ βέβαια πως θα ρίχνουν συνέχεια άκυρα, απλά ότι αυτό που θα φτάνει σε σένα θα πρέπει να είναι μια δις φιλτραρισμένη εκδοχή αυτού που βγήκε από το στόμα του πελάτη.

 

Επίσης είναι σούπερ σημαντικό να καταλάβεις ότι εφόσον μιλάμε για κάτι φυσιολογικό και αναπόφευκτο είναι και δικό σου προσωπικό ζήτημα το να μάθεις να διαχειρίζεσαι ανώδυνα πράγματα που τώρα θεωρείς εκνευριστικά, δυσάρεστα, κλπ.

 

Θέλω να ξέρω αν αυτά εφαρμόζονται όχι μόνο στο μαγαζάκι στην γωνιά που κάνει σελίδες αλλά και σε μεγάλη εταιρεία στο Εξωτερικό. Σε εταιρίες όπως Mozilla, Red Hat, Novell πως σερβίρονται οι απαιτήσεις και ποιο workflow ακολουθάτε, δηλαδή ποια βήματα ακολουθούνται από την καταγραφή της απαίτησης μέχρι την υλοποίηση σε κώδικα;

Δεν απαντιέται αυτή η ερώτηση, μεθοδολογίες και workflows υπάρχουν "άπειρες" και τίποτα δεν είναι σκαλισμένο σε μάρμαρο. Αλλά φυσικά όσο πας σε ποιο οργανωμένες καταστάσεις τέτοια ερασιτεχνικά πράγματα (γιατί αν δεις π.χ. τη Mozilla και ονομάσεις το περιβάλλον "επαγγελματικό", μετά δε μπορείς να ονομάσεις το ίδιο και το μαγαζάκι της γωνιάς) δεν τα συναντάς.

 

Πως καταγράφονται οι απαιτήσεις σας δίνονται με το σταγονόμετρο ή ξοδεύςεται ένα Χ χρόνο για καταγραφή ταξινόμηση των απαιτήσεων και δημιουργία μακετών για UI.

Ναι, καταγραφή και μακέτες.

 

Γιατί εκεί που έποιασα δουλειά απλά κάνω κάτι το παρουσιάζει και μου λέει να υλοποιήσω χ-ψ αλλαγές και τις κάνω αλλά είναι ΕΚΝΕΥΡΙΣΤΙΚΟ δηλαδή ουσιαστικά σκάνε αλλαγές και απαιτήσεις να υλοποιήσω

Δηλαδή δουλεύεις χωρίς να ξέρεις τι ακριβώς πρέπει να υλοποιήσεις, αφού το έχουν αφήσει στα χέρια σου και δεν το έχουν καθορίσει απο πριν.

 

Σ' αυτή την κατάσταση το μόνο που μπορείς να κάνεις είναι να αποκτήσεις καλύτερη αίσθηση για το τι χρειάζεται ο πελάτης, καθώς βέβαια και να συνεννοηθείς με τον πελάτη (ή τουλάχιστον το αφεντικό) πριν αρχίσεις να φτιάχνεις αυτό που πιστεύεις ότι σου ζήτησαν. Και πάλι, δεν είναι αυτός ο ρόλος σου (δεν παίρνεις εσύ τις αποφάσεις) οπότε μπορείς να βελτιώσεις κάπως τα πράγματα αλλά όχι να φέρεις τα πάνω κάτω.

 

και δεν έχω χρόνο να εκπαιδευτώ σε θέματα όπως Desighn Patterns και Unit Testing.

Εφόσον δεν υπάρχει τέτοια πρόβλεψη εκ μέρους του εργοδότη σου (lol στην προκειμένη) οι επιλογές σου είναι τρεις: α) άλλος εργοδότης, β) στον προσωπικό σου χρόνο, γ) είσαι αρκετά αποδοτικός στη δουλειά σου ώστε να σου περισσεύει χρόνος να τον ξοδέψεις σε τέτοια πράγματα.

 

Ακόμη πως θα ξέρω αν αυτό που κάνω είναι καλή ποιότητα και από άποψη κώδικα αλλά και από άποψη ότι είναι ασφαλές και robust εφαρμόζοντας unit testing (που έχω 0 εμπειρία σε αυτό).

Ο μόνος τρόπος να ξέρεις είναι να έχεις δει (και να έχεις καταλάβει!) τι είναι καλή ποιότητα. Εφόσον έχεις μέτρο σύγκρισης η ερώτηση απαντάται αυτόματα.

 

Για να μάθεις τι είναι καλή ποιότητα μπορείς να κάνεις διάφορα πράγματα

 

- να δουλέψεις με συνεργάτες που είναι ήδη σε ανώτερο επίπεδο και να μάθεις απ' αυτούς -- μακράν ο πιο αποδοτικός τρόπος

- να διαβάσεις κώδικα τρίτων και να τον συγκρίνεις αντικειμενικά με τον δικό σου, αφομοιώνωντας τα συμπεράσματα της σύγκρισης

- να μαθαίνεις πώς κάνουμε ή δεν κάνουμε πράγματα και γιατί, σε σημείο που να μπορείς με τη σειρά σου να τα μεταδώσεις σε κάποιον που δεν τα ξέρει (αν δε φτάσεις σ' αυτό το σημείο, δεν τα έμαθες)

 

Προσωπικά ένα από τα πράγματα που μου αρέσουν στο StackOverflow και σία είναι ότι πολλές φορές συγκεντρώνεται απίστευτα μεγάλο συνολικό βάρος εμπειρίας σε ένα μικρού βεληνεκούς ζήτημα, οπότε ο λόγος "μέγεθος εν δυνάμει νέας γνώσης προς πράγματα που πρέπει να ξέρεις απο πριν για να την εκμεταλλευτείς" είναι αντίστοιχα πολύ μεγάλος.

 

Να πω την αλήθεια χρειάζεται Unit Testing πάντα δηλαδή είναι αναγκαίο να κάνεις σε ένα κομμάτι κώδικα Unit testing ανεξάρτητα αν είναι μεγάλο η μικρό project και βοηθάει στο να παράγεις ένα quality Product.

Για το unit testing ειδικά πιστεύω ότι μέχρι να το μάθεις στη δουλειά από άλλους η γνώση σου πάνω στο αντικείμενο θα είναι πάντα ελλιπής γιατί είναι αντικείμενο όπου δεν υπάρχουν εύκολες και μοναδικές απαντήσεις.

 

Γι αυτό αξίζει να ξενιτευτώ για να ποιάσω μια ενδιαφέρουσα και λαυλωτική δουλειά σε Novel, RedHat, Canonical αλλά ξητάνε κυριώς senior δεν είδα θέση Junior

Το αν αξίζει συνολικά το ξέρεις μόνο εσύ. Το μόνο βέβαιο είναι πως αν καταφέρεις να ανταπεξέλθεις (γιατί μιλάμε τώρα για αλλαγή επιπέδου από τοπικό πρωτάθλημα πάμε να παίξουμε Bundesliga) θα έχεις τη δυνατότητα να βελτιωθείς και να εξελιχθείς με υπερηχητικούς για τα τωρινά σου δεδομένα ρυθμούς.

 

Αλλά μη κάνεις το λάθος να νομίσεις ότι το να καταφέρεις να ανταπεξέλθεις είναι δεδομένο (στατιστικά μιλώντας). Πρέπει να είσαι έτοιμος να ανεβάσεις ρυθμούς πολύ.

 

ή και σε μια non-developer θέση εργασίας πχ. να αρθογράφω tutorials σε blog ή περιοδικό εξάλου έχω γράψει ένα χ όγκο άρθρων περί τεχνολογίας στο blog μου: http://pcmagas.wordpress.com

Δε βλέπω ούτε πώς θα σε βοηθήσει αυτό στο να εξελιχθείς σα developer. Επίσης αυτά που έχεις γράψει εφόσον είναι στα ελληνικά δε μετράνε καν.

[ZAKKWYLDE]

Σε μια μεσαία-μεγάλη εταιρεία είναι δουλειά του P.M. ο οποίος είναι συνήθως veteran developer να διασφαλίσει αυτα τα πράγματα. Όπως τί ακριβώς θα κάνεις, τι ΔΕΝ θα κάνεις και γιατί, και όλα αυτά καταγράφονται σε official documents.

 

Αυτός βγάζει το φίδι απο τη τρύπα όταν λεει ο πελάτης "δεν καταλάβατε, μαζί με αυτά τα 2 ήθελα και άλλα 10", και επειδή είναι veteran developer συνήθως έχει και κανα 2 συμβουλες να σου πει για design decisions κτλ.

 

Αλλά training κτλ στην Ελλάδα ξέχασέ το. Ευτυχώς υπάρχει πληθώρα πηγών στο Internet. Γνώμη μου είναι ότι δύσκολα θα βρείς κάποιον Senior να σε δασκαλέψει. Όπου έχω πάει είμαι συνήθως στο ίδιο επίπεδο...η φτάνω όλους τους άλλους σε 2 μήνες. Οι "καλύτεροι" συνήθως θα ψάξουν και κάτι καλύτερο (για τη τσέπη τους).

 

Τώρα εντάξει...design patterns θα πρέπει να τα μάθεις μόνος σου, δηλαδή να αναγνωρίσεις τι προβλήματα υπάρχουν στον κώδικα, και με ποιό design pattern μπορείς να τα λύσεις και να προσπαθήσεις να το εφαρμόσεις. Tα Unit Tests δεν είναι τίποτα, απλά πρέπει να κάτσει ένας 2-3 μέρες να σου πει 5 πράγματα.

[PC_MAGAS]

Οπότε το καλύτερο που ίσως μπορείς να κάνεις είναι να μιλήσεις στο αφεντικό και να τους πεις ότι καταστάσεις τύπου ΧΥ δημιουργούν προβλήματα ΑΒ και αν θα μπορούσαμε σε κάποιο βαθμό να το αποφύγουμε προσπαθώντας να κάνουμε ΓΔ, αυτό θα μας βοηθούσε να έχουμε το αποτέλεσμα που θέλει ο πελάτης πιο γρήγορα. Πρέπει να μιλήσεις με τους όρους που τον ενδιαφέρουν.

 

Δεν απαντιέται αυτή η ερώτηση, μεθοδολογίες και workflows υπάρχουν "άπειρες" και τίποτα δεν είναι σκαλισμένο σε μάρμαρο. Αλλά φυσικά όσο πας σε ποιο οργανωμένες καταστάσεις τέτοια ερασιτεχνικά πράγματα (γιατί αν δεις π.χ. τη Mozilla και ονομάσεις το περιβάλλον "επαγγελματικό", μετά δε μπορείς να ονομάσεις το ίδιο και το μαγαζάκι της γωνιάς) δεν τα συναντάς.

 

Δηλαδή δουλεύεις χωρίς να ξέρεις τι ακριβώς πρέπει να υλοποιήσεις, αφού το έχουν αφήσει στα χέρια σου και δεν το έχουν καθορίσει απο πριν.

 

Σ' αυτή την κατάσταση το μόνο που μπορείς να κάνεις είναι να αποκτήσεις καλύτερη αίσθηση για το τι χρειάζεται ο πελάτης, καθώς βέβαια και να συνεννοηθείς με τον πελάτη (ή τουλάχιστον το αφεντικό) πριν αρχίσεις να φτιάχνεις αυτό που πιστεύεις ότι σου ζήτησαν. Και πάλι, δεν είναι αυτός ο ρόλος σου (δεν παίρνεις εσύ τις αποφάσεις) οπότε μπορείς να βελτιώσεις κάπως τα πράγματα αλλά όχι να φέρεις τα πάνω κάτω.

 

 

Εφόσον δεν υπάρχει τέτοια πρόβλεψη εκ μέρους του εργοδότη σου (lol στην προκειμένη) οι επιλογές σου είναι τρεις: α) άλλος εργοδότης, β) στον προσωπικό σου χρόνο, γ) είσαι αρκετά αποδοτικός στη δουλειά σου ώστε να σου περισσεύει χρόνος να τον ξοδέψεις σε τέτοια πράγματα.

 

 

Ο μόνος τρόπος να ξέρεις είναι να έχεις δει (και να έχεις καταλάβει!) τι είναι καλή ποιότητα. Εφόσον έχεις μέτρο σύγκρισης η ερώτηση απαντάται αυτόματα.

 

Για να μάθεις τι είναι καλή ποιότητα μπορείς να κάνεις διάφορα πράγματα

 

- να δουλέψεις με συνεργάτες που είναι ήδη σε ανώτερο επίπεδο και να μάθεις απ' αυτούς -- μακράν ο πιο αποδοτικός τρόπος

- να διαβάσεις κώδικα τρίτων και να τον συγκρίνεις αντικειμενικά με τον δικό σου, αφομοιώνωντας τα συμπεράσματα της σύγκρισης

- να μαθαίνεις πώς κάνουμε ή δεν κάνουμε πράγματα και γιατί, σε σημείο που να μπορείς με τη σειρά σου να τα μεταδώσεις σε κάποιον που δεν τα ξέρει (αν δε φτάσεις σ' αυτό το σημείο, δεν τα έμαθες)

 

 

Για το unit testing ειδικά πιστεύω ότι μέχρι να το μάθεις στη δουλειά από άλλους η γνώση σου πάνω στο αντικείμενο θα είναι πάντα ελλιπής γιατί είναι αντικείμενο όπου δεν υπάρχουν εύκολες και μοναδικές απαντήσεις.

 

 

Το αν αξίζει συνολικά το ξέρεις μόνο εσύ. Το μόνο βέβαιο είναι πως αν καταφέρεις να ανταπεξέλθεις (γιατί μιλάμε τώρα για αλλαγή επιπέδου από τοπικό πρωτάθλημα πάμε να παίξουμε Bundesliga) θα έχεις τη δυνατότητα να βελτιωθείς και να εξελιχθείς με υπερηχητικούς για τα τωρινά σου δεδομένα ρυθμούς.

 

Αλλά μη κάνεις το λάθος να νομίσεις ότι το να καταφέρεις να ανταπεξέλθεις είναι δεδομένο (στατιστικά μιλώντας). Πρέπει να είσαι έτοιμος να ανεβάσεις ρυθμούς πολύ.

A όταν μίλησα να έχω κάτι ποιο συγγεκριμένο αντικείμενο εργασίας είπε ότι "Δεν μπορώ να σου το προσφέρω δεν παίζουμε έτσι. Θέλουμε Killers"

 

Δηλαδή θέλει το παιδί για όλα;

 

Επίσεις αν έχεις εμπειρίες από τέτοιες εργασίες (Εργασία σε Canonical η RedHat) τι ρυθμούς λέμε δηλαδή θέλω ένα παράδειγμα από προσωπικές σας εμπειρίες σε ανάλωγες εταιρείες, για να το εμπεδώσω όσο βαθειά γίνεται. Πχ. Δουλειά 4 μερών σε μια εταιρεία μικρού βελινεκούς θα πρέπει να την βγάλω σε 1 ώρα, ή να δουλεύω από τισ 8 το πρωϊ μέχρι τισ 8 το μεθεπόμενοι πρωϊ για να βγάλω μια απαίτηση;

 

Ακόμη είπες να διαβάσω κώδικα έχεις κάποια projects που να είναι αρκετα ενδεικτικά για ανάγνωση; Ακόμη όταν διαβάζω κώδικα τι πρέπει να προσέχω έτσι να κατανοήσω το ποιόν του Κώδικα και να τον συγκρίνω με τον δικό μου (Αν αίναι παραπάνω από 10 Γραμμές δώσε links); Ακόμη μπορώ να πάρω τέτοιου είδους εμπειρίες δουλεύοντας ταυτόχρονα (πχ. το ΣΚ) σε Projects ελευθέρου λογισμικού, πχ. εργασία με "μαθουσάλες" στον προγραμματισμό;