Hey everyone, Happy New Year! Hope everyone had an amazing Christmas and New Year's celebration.
And apologies for the lack of episodes in December, I decided to have a short break and we start in the new year.
Et ce premier épisode de l'année est un sujet très passionnant de la production de développeur.
C'est quelque chose que j'ai été vraiment intéressé dans pour beaucoup de temps, donc cette fois que je vais faire un épisode solo et parler de ce sujet,
et les choses que j'ai appris pendant les années qui ont fait une grande différence dans ma production.
C'est toujours sur moi que si vous avez un grand nombre de développeurs, la déviation entre chaque niveau de production de développeurs est énorme.
Et je veux dire, vraiment énorme. Un sujet qui peut prendre une développeur de l'heure et une autre développeur un peu de jours, et la qualité de la solution sera probablement très différente.
Et c'est un sujet qui peut prendre plus de 10 ans.
Pour expliquer, on va voir des facettes différentes qui peuvent faire un développeur plus productive.
Tout d'abord, on va commencer avec une très basique, simple type speed.
Si vous êtes un type fast, vous pouvez physiquement code faster.
Si vous êtes un type très slow, ça va prendre plus de temps pour faire le code.
Maintenant, évidemment, vous pouvez aussi code le truc qui est le plus fast, le plus fast, qui va se passer plus tard.
Mais le point est, si vous êtes un type slow, il est plus important de prendre un peu de temps en appuyant le type touch.
Donc, un autre facette est de l'assurer votre idée.
Si vous comparez un développeur qui sait comment faire l'idée pour faire le truc pour vous,
par exemple, refacteurant automatiquement avec quelques combinations de shortcuts,
en créant un code commun pour vous, et ainsi.
Vous pouvez l'assurer votre idée tout le temps, en codant.
Maintenant, comparez cela avec un développeur qui sait pas que l'idée peut même faire le truc,
et ils tentent de faire tout en général.
En utilisant votre idée plus, ça peut vous faire plus vite, quand en codant.
L'amount de choses que votre idée peut faire pour vous est insain.
Mais ces choses sont juste touchées sur la surface,
et ces choses ne sont qu'à faire physiquement write le code.
Mais même avec ces deux choses,
je dirais qu'après travailler avec beaucoup de différents développeurs,
on est probablement déjà en train de voir une différence de 10x en comparant des devs qui sont des types de passe,
et qui sait vraiment comment élever l'idée vers des devs qui ne sont pas.
Mais c'est plutôt utile d'être un code superfast,
si vous vous faites le truc le même,
ou si vous faites quelque chose qui est vraiment inévitable,
ou inédible, ou boogie,
ou peut-être que vous essayez de faire quelque chose
où il y a déjà un library existant,
que vous pouvez utiliser en fait, de réinventer la voiture.
Est-ce que vous faites quelque chose qui peut être un nightmare
pour les développeurs d'understand et de maintenir?
Réveillez que quand je dis développeur de productivité,
je ne parle pas de la fin de la parole,
comment vite je peux le faire,
sans question de la qualité.
Si vous faites un fonctionnement de la journée,
mais que ce soit le fonctionnement de la réinventation,
que vous pourrez avoir une réinventation de la team,
avec des bugs, de temps en temps,
c'est un fonctionnement très expensif,
et pas très productif,
sans qu'il soit vite que vous n'avez pas fait la version initiale.
Une autre, est-ce que vous faites des tests automatiques?
Si votre fonctionnement n'a pas des tests automatiques,
et que le team de QA a de l'aérosse manual,
tous vos codes,
d'ici ou d'ici, pour des années,
il faut que l'on soit très bien,
que le changement soit fait,
et que ce soit pas très productif.
Sur la partie de l'on,
vous faites trop de tests uniques,
testant tout le classement
et le layout,
si vous faites des codes,
vous avez besoin de rewrite des tests uniques,
mais ce n'est pas très productif.
Personnellement, pour les tests,
je trouve que les tests de integration
qui se couvrent des requises,
sont plus productifs et valibles
que les tests uniques,
tout le layout de la détail d'implementation.
La bonne communication est une autre,
la plupart du temps, vous travaillez
en partie de la team,
que ce soit les autres développeurs,
producteurs, stakeholders,
la productivité n'est pas une activité solide,
et la communication de pauvres
peut baisser toute votre team productivité.
Une autre,
comment vous savez votre plateforme de choice?
Si vous êtes un développeur de réact,
qui sait réact à la frontière,
vous allez être plus productifs
quand vous faites une app de réact,
alors que quelqu'un ne le connait pas
ou c'est juste médiocre avec le réact.
Et cela s'applique
à ce que cette technologie est,
si c'est réact,
ASP.NET, WPF, Xamarin, tout ça.
Le point est,
apprendre votre plateforme de choice
à la frontière.
C'est ce que vous pouvez faire
pour faire attention au problème de la business,
quand vous faites des choses,
et ne pas travailler sur comment faire X ou Y
dans votre texte de currentité.
Donc, prendre tous ces facettes
dans l'account,
et il y a beaucoup plus.
Vous pouvez voir comment,
pour un développeur qui est vraiment bon,
c'est tout ce que vous avez,
le fait de 10X,
ça peut certainement être un ordinateur.
Et vous vous souvenez,
ça ne veut pas dire
que le plus productif de votre développeur
doit travailler plus difficile
ou plus longtemps.
Nous sommes une industrie de connaissance
et par la connaissance et le tournage,
vous pouvez produire
plus de valeur
par travailler plus tard,
pas plus longtemps.
Si vous devez travailler plus tard
ou plus longtemps,
pour augmenter la valeur
que vous produisiez,
vous allez avoir un peu de temps.
Il n'y a que soixante heures
et vous allez se déterminer.
L'un est de gagner le temps,
ne pas perdre le temps,
et ne réduire le stress,
ne pas augmenter.
Ok, donc,
depuis tout ça,
comment nous devons devenir
plus productifs de nos développeurs?
Alors, nous allons commencer
avec le grand,
l'application active.
D'où que je vois,
les développeurs ont des cours
et ils ont des cours.
Donc,
imaginez un développeur de 20 ans
qui a été maintenu
sur le même code base,
repétissant le même jour,
pour 20 ans,
et ne pas en apprendre activement
à tout ce qui est nouveau.
Imaginez un développeur de 2 ans
qui en active,
les étudie tous les jours,
comme les projets hobby,
les livres de reads,
les sites de PlayWall,
les podcasts de développeurs,
et les deux développeurs,
qui sont plus expérientes.
Donc, mon grand tip,
par farce,
est de dédiciter un période
de temps,
tous les jours,
pour apprendre.
L'étudie de la calendar
de 30 minutes a jour
n'est pas beaucoup de temps à chaque jour.
Mais si vous travaillez,
en un an,
c'est l'équivalent de la dépense
d'un mois de étudiant,
en plein temps,
7,5 heures a jour.
Imaginez comment plus vous le savez,
cette fois de l'année,
si vous vous recommettez
à ce que ce soit de 30 minutes a jour,
comparé à ce que vous ne le savez pas.
La prochaine question,
c'est ce que vous apprêtez.
Il y a beaucoup d'outre-de-la,
et ma suggestion est d'apprendre
ce que vous utilisez.
Je vous rappelle
comment je l'ai mentionné
avant de vraiment comprendre
votre texte choqué.
Si vous êtes un développeur de réaction,
faites-vous vraiment réaction.
Mais ne vous arrêtez pas de savoir
juste suffisamment de savoir.
Si c'est votre profession
et votre main texte,
alors venez de savoir le temps

Cela vous permet
de construire des applications
plus vite,
avec moins de stress,
et de vous faire focus
sur les requimages actuales,
ne pas de faire du travail
en travaillant sur les détails d'implementation.
Et aussi des outils.
Un outil est un bon point de focus.
Qu'un que l'idée utilise,
faites-vous vraiment savoir
comment l'utiliser
et sa fonctionnalité,
pour faire le mieux de vous possible.
Ne vous utilisez pas
d'un gros idée,
comme le studio visuel
ou le rideur,
comme un éditeur de texte.
Les idées sont
beaucoup plus puissantes que ça.
Lorsque vous avez appris les shortcuts,
les automatiques,
vous pouvez sauver
un moment ridiculous.
Qu'est-ce que vous pouvez apprendre ?
Je l'ai mentionné
quelques fois
pour apprendre votre propre texte,
mais vous êtes heureux
avec ce texte ?
Est-ce qu'il y a un autre texte
que vous vouliez plutôt travailler ?
Même si ça signifie
de bouger à une autre compagnie,
vous jouez avec ces technologies,
aussi.
Vous avez des projets hobbyiques
et de tinker,
et vous jouez aussi.
Vous pouvez aussi jouer
avec différents paradigmes.
Donc,
si vous êtes un programme objectif,
vous pouvez jouer avec un programme
fonctionnel.
Si vous êtes un développeur desktop,
vous pouvez mettre un web app.
L'application d'autres paradigmes
peut souvent
augmenter la façon dont vous vous encadrez
dans votre propre texte.
J'ai bien entendu
cela en moi-même,
en application fonctionnelle.
C'est bien bien
que vous vous apprêtez.
Il n'y a pas de
ceci pour apprendre.
Donc,
être intentionnel
sur ce que vous avez appris
est important.
C'est pour créer un blog prioritisé
de ce que vous voulez apprendre.
Je trouve que
plus je l'apprends,
plus je le découvre,
je le souviens aussi.
Donc,
faire des notes de choses
que je vois en arrivant
et puis prioritiser
cette liste,
juste comme je vais prioritiser
un blog productif.
Cela fait un grand différence.
En parlant de prendre des notes,
cela
bien s'intéresse
à la prochaine chose
que je veux parler de.
La note.
Comment vous rétablissez
tout ce que vous avez appris?
Il n'y a pas de point
de prendre beaucoup de temps
de la chose à apprendre.
Si vous vous rappelez
seulement une petite fraction
de cela,
et c'est là
que la note est allée,
vous ne voulez évidemment pas
ou besoin de la faire
reproduire le contenu que vous étudiez.
Je trouve que
juste de la pointe bulletin
et
des bits de la marque
que je trouve importants
et que je sais
que je ne sais pas déjà.
Par exemple,
je suis currently
en train de apprendre la laser.
Donc,
je suis créé des secteurs
dans mes notes
sur différents secteurs,
par exemple,
des snippets
de la façon
que le works de la laser,
comment le
lifecycle de la pièce
fonctionne,
ce genre de choses.
Bébé,
une fois que je vous réglise,
je peux regarder
sur les deux
pour réfraîmer mon mémoire
et aussi
utiliser la réference
quand je suis en train de construire
les appels de la laser.
Ces notes sont normalement
vraiment
références succinctes.
Je ne dois pas
répéter
si je le sais déjà.
Je tente de
faire une note
pour que c'est vraiment
puissant
de répéter vous-même.
Donc,
combien de fois
si vous
ré-googles la même chose,
cherchez pour la même
réponse
sur Stack Overflow,
en temps de temps
essayant de travailler
sur comment faire
quelque chose
que vous avez déjà fait
dans le passé,
mais que vous avez

les détails d'implementation.
Donc, mon conseil
est
créer votre propre note
et le library de snippets.
Il y a
beaucoup de tools pour cela.
Une note,
une autre note.
Obsidiement,
j'ai commencé à utiliser
ce que j'aime vraiment,
mais principalement
j'utilise la notion.
Ou même si vous
juste vous portez des textes
et des textes,
la chose importante est
que,
quand vous faites quelque chose,
pensez à
si vous voulez
faire ceci
encore en futur,
et si vous voulez
prendre des notes.
Donc,
ce serait des codes snippets,
un cheat sheet,
des instructions
de la première étape,
des références de la première étape.
Je n'ai pas
tous les trucs en main,
et je trouve
que quand je viens
faire un peu de travail
où je n'ai déjà
pris des notes,
cela
dramatically réduit
le temps
que cela fait
ceci.
Comme cela,
cela devient
un exercice
et un pays.
Cela peut
sauver des jours,
en quelques cas.
Ce prochain point
peut être un peu
controversé,
mais,
évidemment,
le sharing est bien,
et si c'est quelque chose
qui est lié
à votre équipe,
alors,
assurez-vous que
la compagnie
de shared Wiki
est en date,
et beaucoup de choses
sont documentées.
C'est
assez important.
Mais,
ici,
je parle
spécifiquement
de votre propre
personal de shared Wiki,
qui n'est pas
sur votre compagnie
de domaines de business,
mais sur les notes
de la généralité
et des snippets.
Tout le monde
s'en pense,
en fait,
dans différentes manières,
et la façon
que je ferai des notes
pour moi-même,
donc,
moi,
est assez différent
de la façon
que je ferai des notes
pour les autres
personnes à consommer.
Dans mes notes
je peux faire des assumptions
de connaissance
que j'ai déjà.
Je ne veux pas
avoir quelqu'un
pour réveiller quelque chose
ou ne pas avoir
ajouté assez de contexte
pour quelqu'un
qui n'est pas moi.
Je veux être
libre de lait
et refactor
cela
de la manière que je veux
et mettre
ce que je veux dans cela.
Et dès que
ceci est shared
et utilisé
par une personne
plus importante,
tout se fait
plus compliqué.
Aussi,
la vie de votre
libraire
doit être plus grande
que votre company.
C'est votre
et vous avez le droit.
Mais,
comme je le disais,
ce n'est pas
que vous soyez négocié
de la documentation
dans votre workplace
dans un wiki shared.
Ce n'est pas
ce que je parle.
Donc,
pour terminer
cette section de notes,
je veux
highly recommencer
que si vous n'êtes pas
un avid note-taker
de maintenant,
ma suggestion
serait
de devenir un.
La vie de votre
libraire

prendre tant d'informations
et,
sans que vous soyez
extrêmement heureux
et que vous soyez
un membre comme Richard Campbell
de .NET Rocks,
les meilleurs membres
ne sont pas
que récits et organisés.
Et même si,
je crois que Richard
a des notes,
aussi.
Donc,
en utilisant un outil
comme notion,
ou obsédient,
ou une note,
ou un avid note,
en utilisant un outil
comme ça,
comme votre second brain
peut avoir un huge impact
sur votre productivité.
En utilisant notes
comme vous l'avez appris,
en facteurant
et en revues ces notes
en temps.
En passant au next section,
un autre chose
que je trouve très utile,
c'est de
expliquer les choses
en bas.
Et je fais ça
avant que je commence
à travailler sur un outil,
avant que je commence à coder.
Bébé,
je type un liste
de toutes les choses
que je dois faire
pour compléter un outil.
Et je tend aussi
à ajouter des choses
comme je vais en plus,
en plus.
Et cette liste
tend à être
un peu de
points de bulletin
avec une indentation
pour les items groupes,
ensemble.
Je suis un grand fan
de points de bulletin
ou des listes de chèque.
Et je trouve
mentalement
expliquer mon cerveau
dans différents modes,
donc
planer mode
versus
travailler mode
peut faire un grand différence
à mon focus.
Donc, quand je suis
en mode travailler,
je suis juste
travaillé sur un liste
de items
que j'ai déjà écrit.
Ce qui m'a aidé
à rester en train
et à procrastiner moins.
C'est typiquement le cas
de comment vous mangez
un élément
une fois à un moment.
Et je me suis dit
que pendant
l'acte de
écrire cette liste
de choses que je dois faire
pour impliquer un élément,
même avant que je commence
à coder,
cela me fait souvent
souvent de penser
aux autres choses
que je dois faire
comme part de
ce élément
ou peut-être
des problèmes
que je peux avoir
qui signifie
que je dois changer
l'implementation plan
mais maintenant
je réalise ces problèmes
avant que je ne me touche
même pas
d'un code.
Cette pratique
d'une seule fois
m'a aidé beaucoup de temps.
En parlant de listes,
je ne vais pas trop
profiter de cette liste
parce que c'est
en cas de contexte
de productivité de développement
et c'est plus
juste de productivité

Mais je vous recommande
de lire
sur
GTD
« Getting Things Done ».
Il y a un livre
par Dave Allen
qui me inclure un lien
dans les notes de la show
qui parle tout de cette.
Si je travaille
sur un projet de travail,
je tend à utiliser
le tournoi de l'adresse
et le tool de développement
que l'équipe utilise.
Mais au-delà de ça,
je fais beaucoup d'autres trucs
pour que
cet podcast
organise le
.NET Oxford user group
et c'est un peu
un peu comme la m'amuse
de ma compagnie Everstag.
Beaucoup de choses
de maison et de famille.
Tout ce que je dois faire,
je vais faire un
« To Do » list.
Maintenant, je n'ai pas
à utiliser « To Doist ».
Mais cet concept
de « Getting Things Done »
est de
faire tout
de votre tête
et d'un système.
En ce cas,
ce système est
« To Doist » en notion
mais le medium
n'a pas vraiment de mal.
Et organise
ceux de « Do »
par « Tags »
pour donner contexte
et aussi priorité.
Donc,
« Tag » pour moi
peut être
un « Computer »
qui est quelque chose
que je peux faire sur mon
« Computer »
ou « .NET Oxford »
qui est quelque chose
qui est relative à
le « .NET Oxford ».
Mais j'ai un whole bunch
de « Tags ».
Donc, si je sais
que je suis sur mon « Computer »
et que je veux
faire des « .NET Oxford »
« Stuff »
je peux filtrer
par ces deux « Tags »
et aussi
ajouter une priorité
pour ces « To Do »
et
faire tout ça
signifie que je ne
n'ai jamais oublié
de faire quelque chose.
Il aussi signifie
que mon cerveau est libre
de la stress
d'en souvenir tout ce que je dois faire.
Donc, je suis relaxé
dans la connaissance
que tout ce que je dois faire
est capturé
donc je ne les oublie pas.
Je trouve que
grâce à ça,
même si je suis
très busy
c'est assez stressant,
je me sens relaxé
et heureux
mais aussi très productive.
Ce qui ne serait certain
pas le cas
si je n'étais pas
élevé à faire des listes
et de ne pas prendre
trop de temps.
Un autre
plus important
de la productivité
est la faute de la focus
et la procrastination.
Ce qui est
évidemment différent
pour tout le monde,
je trouve que
une chose qui fait
une grosse différence
pour moi
est la « Wapping Big Headphones ».
Je me suis rendu
un grand différence
par comparer
ma productivité
quand je n'ai pas
des headphones
vers les headphones
intérieures
vers les headphones
qui me couvrent
sur mes oreilles.
Il y a quelque chose
qui est en train
d'accompagner
sur les headphones
vers les oreilles.
En tout cas,
ce que je trouve
et une bonne choisi
pour m'amener
mouillée
me permet
d'amener
dans la zone.
Je me suis rendu
en office
quand je me suis rendu
des headphones
j'ai tendu
d'être interrompé
beaucoup moins.
Et si je trouve
que je suis
destructé
et
mentalement procrastiné
je vais peut-être
vérifier mes emails
trop beaucoup
ou tout ça.
Et puis quelque chose
que je trouve
qui m'a aidé
en mettre un temps.
Vous avez probablement
entendu
la technique de la technique
de la POMO d'Oro
où vous vous mettez un temps
pour 25 minutes
et vous vous en avez
seulement la possibilité
de faire attention
à la tâche que vous êtes
supposed à travailler
pendant ces 25 minutes.
Vous ne pouvez pas
vérifier les emails,
les Twitter,
vous devez essayer
d'éviter toutes les interruptions
pour ces 25 minutes.
C'est 25 minutes
de temps en focus.
Et après le temps
il y a un temps de 5 minutes
de break
aussi un temps
et puis vous repetez.
J'ai essayé
ça beaucoup
et je trouve que
pendant ce temps
il y a des
suffisantes angoissances
avec ça
que je n'ai vraiment pas
stické avec ça.
Une grande angoisse
c'est quand le temps
il y a 25 minutes
souvent
cela se débrouille
en itself
et me tient
à la zone
quand je n'ai vraiment
pas voulu être
tiré.
Un autre
temps est que
pendant les 25 minutes
ce n'est pas un temps long
à tout
si je me sens
inutile
et distracté
alors 25 minutes
me sentent
comme une longue temps.
Donc j'ai vécu
une version modifiée
qui
marche mieux pour moi
de toute façon
et ici sont les points de clé.
J'ai pris 10 minutes
pas 25 minutes.
Vous devriez
pouvoir regarder le temps
mais ça ne devrait pas
être dans votre tête
vous devez
explicitement
tourner votre tête
à l'écoute.
Et plus important,
quand le temps
s'arrête
vous ne devriez pas
être alerté
à la fact que c'est passé.
Les idées derrière
ce sont
la partie la plus difficile
de faire quelque chose.
Si vous êtes inutile
c'est normalement
juste de commencer
et d'initialement
de se faire entrer dans la zone.
10 minutes
n'est pas un long
commettement
mais c'est long
pour faire un start
et vous en avoir
dans cette zone.
Et la même ruelle
apprécie
comme la technique
de Pomodoro.
Dans ces 10 minutes
vous ne pouvez pas
faire un email
ou faire quelque chose
d'autre que le
Tascat Hand.
Et le 10 minutes
c'est juste un minimum.
Le temps
n'est pas
ordable de se faire entrer
c'est assez important.
C'est assez souvent
que je commence
ce long commettement
de 10 minutes
et que le temps
soit encore dans la zone
une heure plus tard
et que je produis un ton
de travail dans l'heure.
Et je prends cette technique
de tout autre
comme le tourner
dans la maison
en faisant un workout
en faisant des pratiques
10 minutes
c'est assez long
pour avoir
un très bas commettement

Mais quand je commence
je ne pas vraiment
arrêter de 10 minutes
c'est juste un bon start
pour commencer
quelque chose
et de se faire entrer dans la zone.
La dernière
chose que je veux toucher
c'est de la santé et le fitness.
Nous sommes un industriel
qui se passe
notre temps
satin
pour 7 plus
heures
chaque jour.
En faisant
le développement de la softwa
promote beaucoup de exercices mentales
sans doute
cela fait le
tout le monde
pour le fitness physique
et il y a plein de
conflits de la santé
entre le fitness physique
et le bien-être mentale.
Donc je ne dois pas
dire qu'il faut
aller au marathon
mais tu es obligé
de faire un certain type
d'exercice chaque jour
même si c'est juste
un jour
de fresh air
et aussi
ce que tu es important
pour
l'équipe de la brain
qui est
évidemment
une importante
organe
dans notre ligne de travail
Il y a plein de infos
et je vais inclure
des liens dans les notes

aussi
sur comment le rôle
de nutrition
joue dans la fonction
de la brain
pour les
productivités
mais aussi
le bien-être mentale
aussi.
Et puis
pour le fitness
de la santé
tu as aussi le temps de dormir
Si tu as
valorisé
l'importance de dormir
et penses que c'est
une bête de temps
je vous recommande
de vous
lire un livre
qui s'appelle
« Pourquoi nous sommes
dormus »
de Matthew Walker
Je vais vous le lien
dans les notes de la show
C'est un réveil

et il y a
une décrepition

s'appelle
« Becca



B Heaven



Je trouve que si je ne fais pas ça, ça me fait plus longtemps que de commencer et je tend à procrastiner beaucoup plus.
Un autre point de rencontre, je n'ai pas vraiment parlé beaucoup de rencontres dans cet épisode de podcast,
ce que je peut peut-être faire. Mais pour ça, je vais vraiment essayer et reposer sur autant de rencontres possible.
Vraiment vous inquiétez, est-ce que c'est le meilleur utilisation de votre temps ?
Si vous avez besoin de beaucoup de rencontres, est-ce que vous pouvez
faire de l'intérêt de ces rencontres et de les faire clomper ensemble pour éviter votre temps de devenir
une rencontre, un peu de travail, une autre rencontre, un petit peu de travail, une autre rencontre, un peu de travail.
Pour moi ces types de jours me finissent avec moi être tellement frustrés sur comment je suis arrivé.
Un autre, essayez le meilleur pour augmenter votre développement dans un loop.
Et ça veut dire que le temps d'être en train de faire un change à un code,
pour voir les résultats dans votre application ou sur la web app,
en fonction de votre machine local. Et chaque fois que vous faites un change,
combien d'eux vous en fait pour voir ce change ? Avec beaucoup de technologies modernes,
vous avez une fonctionnalité de refroidage, où nous parlons de fractions de seconde.
Maintenant je me souviens d'un peu plus tard. Ce serait peut-être des minutes.
Et c'était une manière de faire de la productivité, ça a fait très difficile de vous en garder en zone.
Donc si possible, venez avec des moyens de augmenter votre développement,
que ce soit l'élevération de la technologie moderne et des choses comme la refroidage,
que ce soit en utilisant des tests et de la mode de test en votre RDE, il y a beaucoup de
moyens de essayer de diminuer ce loop de temps entre faire un change de code et voir les résultats.
Un autre, si vous êtes heureux de travailler, change de travail.
Je me souviens d'une particular place que j'ai travaillée beaucoup d'animes,
où j'étais assez malheureux, mais je me suis resté là parce que l'idée de la refroidage
a eu l'air trop grande de change ou plus difficile que ça.
Quand j'ai finalement bougé, j'étais tellement heureux et peut-être que je devais faire le
mouvement beaucoup plus tard. Il y a eu des compagnies incroyables pour travailler dans notre industrie
et beaucoup de ces compagnies sont décrites pour les bons développeurs.
Donc si vous n'êtes pas heureux, vous n'en ayez que de la vie. Juste change de travail.
Un autre tip est de faire beaucoup de networking.
Maintenant, ça dépend évidemment de ce que vous voulez de votre carrière,
mais plus vous en faites un connecteur avec les autres, plus les opportunités
seront presque magiques à l'avenir. J'ai eu plusieurs opportunités pour
mettre en place des gens que je savais beaucoup d'animes. Vous ne savez pas vraiment quand
ces chansons à l'adversaire ou la conférence ou quelqu'un que vous vouliez en un rôle passé
pour transmettre à l'opportunité de l'avenir.
Et, ok, le dernier tip est de essayer d'enseigner et de mentorer les autres avec ce que vous avez
appris. Ce n'est pas seulement qui aide aux autres, ce qui est évidemment un bon truc,
mais aussi qui vous aide à vous rappeler plus bas ce que vous avez appris.
Right. Ok, donc c'est assez rabattu pour moi. J'espère que vous avez aimé ce solo épisode
et ne vous inquiétez pas, on va être en retour à la forme normale prochaine fois avec les guests.
Comme je l'ai dit au début, la productivité de développeur est une
question qui me fascinera vraiment et j'aime entendre vos pensées,
ainsi que les conseils que vous avez, que vous avez plus proche.
Donc, n'hésitez pas à laisser des commentaires sur le site qui peut être trouvé sur
UnhandledExceptionPodcast.com. Et, au final, un petit reminder que ce podcast est
sponsorisé par Everstack, qui est mon propre company, qui donne le développement de l'application
et des services de consultation. Pour plus d'informations, visitez Everstac.com.
Et si vous avez aimé le podcast, s'il vous plait, vous pouvez vous envoyer le nom de la
parole sur les médias sociaux. Je n'ai pas utilisé le hashtag UnhandledException,
et je peux être trouvé sur Twitter, à Drakan, D-R-A-C-A-N. Et mes DMs sont
ouvertes sur mon blog dancloch.com, il y a des liens à tous mes trucs sociaux aussi.
Merci d'avoir regardé et à la prochaine.