Hey, everyone! Welcome to the Unhandled Exception podcast. I'm Dan Clark, and this is Episode
Number 16. And today I'm joined by James World, who co-founded Azure Oxford User Group
with me, and pretty much every time I chat with James, I learn something new. He's a walking
tech en psychopédia, and hopefully we'll get a few hints today on how he does this, because
the topic of today is all about learning. So a massive welcome to the show, James.
Thanks, Dan. It's great to be here, and yeah, it's been fantastic seeing the podcast come
on, so you had some really good episodes. I hope I can live up to the history.
Of that, I have no doubt. So before we start, could you give us a quick intro into your
background and what it is you're up to nowadays?
Sure. I'm a solution architect. I've been doing that role now for probably the best part of a good
five or six years. Before that, I've been contracting, working mostly for finance companies in
the city. The most sort of, I guess, most interesting part of my career was at Microsoft. I spent 10
years there working with a wonderful team, the application development consulting team,
and my role there was working for a large number of different clients across all sorts
of fields, companies of all different sizes, and with, I think, probably some of the best people
I've ever had the opportunity to work with, and they really sort of honed my skills. It was
quite a humbling place to work, being able to know that the guy sat next to you was probably
just the best at something. I learnt so much there, but I guess most importantly,
I had the opportunity to see so many different clients with such a wide array of problems and
challenges. I learned a phenomenal amount, and it's really sort of, I think, carried me through
the rest of my career. But it was also a job where it was really understood that you need to pay
attention to how technology is evolving. You need to learn. You need to have time to learn,
to grow. So we got given a lot of time in that role to train ourselves, and it's something that
I've, again, I've kept with me ever since. I think it's all too easy to stop paying attention
to your skill set in the right way, and that's something that's always fascinated me,
is just how do you keep up when the landscape is changing so quickly?
I think the other thing that has been a real advantage for me is I got into competing at a
really, really early age. So I was like six when my mum bought my dad a ZX Spectrum, and you can
see it's, you probably see behind me the listens can't, you can see I've got a ZX Spectrum on the
shelf behind me. I fell in love with it then. It ended up in my bedroom after three weeks because
my dad wanted a study bag, and I never left it alone since. But things have changed so much,
in like the 40 years since I got that computer. You know, if I'd ever sort of stopped learning
along the way, then, you know, I'd be useless to the industry now.
Speaking of like continuously learning, I saw on Twitter yesterday that you've now got a shiny new
Azure Solutions Architect Expert certification.
I have, yes, yeah. I'm currently taking a short break in between jobs, starting a new job next
week. I thought I put that time to good use. It's one of those things I think a lot of us keep on
to the saying we need to go and get that certification. But yeah, I finally did it.
It's actually not the first Microsoft certification I've done. Back when I was working at Microsoft,
you could, as an employee, one of the nice benefits was on a Friday lunchtime, you could go
down to building three on the UK campus and sit at one of the Microsoft exams. So I picked up a few
back then. But yeah, looking at my transcripts, I can see the last time I'd done a Microsoft
certification was back in 2008. So yeah, been a while, but it was quite satisfying to do it.
And I think it does, when you do these, I think it does make you question what's the value of a
certification. And it's something that I can, I think about a lot. I do a lot of interviewing
in my job. And when I see credentials on CVs like that, I always had the same sort of thoughts
running through my mind. Is this a case of somebody who has just studied to get that particular
certification, doesn't really have the experience to back it up? Because to be honest, I think
pretty much any sort of vendor certification like this, you can do that. There's so many study
guides out there, which are sort of kind of drilling you to pass that particular exam.
And then you've got the person where they've got sort of broad and genuine experience in the topic.
And the studying for them is kind of just more making sure that they've got a rounded view of
the syllabus. And I think, I think the exams have certainly improved a lot. They're much better
now at testing that you do have the experience. But it's still something at the end of the day
that you can drill to pass. So somebody with my experience, I'm not really looking at these
certifications as a way to prove that I know this material to a potential employer. I think,
when you've got some 20 plus years of professional experience, your value to a potential employer
is demonstrating the value that you've brought to other employers that you've had. So I look at
More as a learning tool. For me, it forces you to fully explore the offering, the product,
the tool, whatever it is that the certification is covering. And Azure is massive and growing
all the time. So this certification, which covers a broad range of topics, is just a really
useful way to see what's moved on from the stuff that you've been using for a long period
of time. It's a great way of just checkpointing your knowledge and catching up.
I'm just starting to go through this journey now at the very beginning. So I've used Azure for
a few years now, so no a reasonable amount. Obviously, definitely not as much as you,
but I've actually not done any certifications. So I'm just planning on starting at the very
beginning with the Azure fundamentals just to get a feel for how the whole exams work.
I don't know, then I'll probably do the developer one. I think that's the AZ204, I think.
But yeah, so completely new tool for all this certification stuff.
Yeah, I noticed as well that Microsoft have really been pushing the exams recently. I mean,
obviously, from a vendor's perspective, it's a great marketing device. They want people to take
those exams because they want to increase the knowledge of their offering in the market.
I don't have a problem with that. Everyone wins when you take that approach.
It's always good to start at the beginning. The AZ900, I think it is, the fundamentals exam,
is going to give you confidence that you can be successful at the exam and it gives you
some familiarity in how they work. They are predominantly multi-choice questions.
And I think when you hear multi-choice, you think, oh, this is some sort of dumb down exam.
But really, they're not. I think they do a good job. I actually had a company,
I started a while back, called the Test Factory, which offered technical tests for developers
to use during the interview process, that kind of thing. So I know firsthand just how challenging
it is to write a good question that tests knowledge. And it's actually the wrong answers
that are the hardest ones to come up with. The idea of these questions is not to catch you out.
It's there to test your understanding. And I think they do a pretty good job of that.
Some of the questions in the exam seem really specific. And I think it's very easy to sort
of say, well, if I needed to know the exact criteria that are required for as your disc
encryption to better work, then I'd just go look it up at the time that I needed it.
And I think that's a fair reaction. But if you have genuinely worked with these tools,
and if you have got that broad level of experience, then even though the questions seem
sometimes very, very specific, they are actually genuinely sort of testing that you have an
understanding of how the technology works. And they're not just sort of pick A, B, C, or D.
They're kind of cunning. They'll have picked the right value from this dropdown,
which is a whole host of options, or pick the three from these seven things that are right.
So there's lots of, there's enough combinations in there that you're not going to be able to
sort of pass by being the gorilla randomly hitting the right answer.
Yeah, one thing I do like about the Z900, the fundamentals one, is just the breadth of it,
though, because even though it's fundamentals, that there's some really obvious questions,
like I'm sure lots of people at USASHA know the difference between PAS and IRs and all this
kind of stuff. But then it's also, as well as that, it goes into things like networking and
just there's some really obvious stuff that anyone using the cloud will know.
But there's stuff that I'm guessing that a lot of people that have used Azure for years,
that if they don't do any studying at all, probably wouldn't get right, even on the fundamentals
ago. Yeah, absolutely. And actually, I think sometimes the fundamentals are very easy to skip over.
If you look at, I think AZ900, for example, spends some time looking at things like
subscriptions and management groups and role-based access control and resource groups,
those kinds of organizing tools. I can't tell you how many times I've seen an
just an absolute chaos within our customers as your subscription, resource groups with
1000 ressources in them, mixed environments,
between, you know, all sat alongside each other in the same subscriptions.
Actually, it's, you know, understanding those basic principles can really help you
keep a clean and tidy house, which is so important as your real estate grows.
Taking your example of management groups, that's fairly new.
So if you've been using Azure for years and you've not been keeping up,
then you might not even know that that exists.
Yeah, and they do keep changing the exams as well to reflect the progress.
So something to be aware of is the solution architect qualification.
I think has a two year lifespan.
That's how long it's valid for, and then you'll need to reset.
So I definitely view it as a checkpoint.
I will be revisiting regularly just to keep up to date with what's new and you're an interesting.
Haven't they changed it recently?
Well, you don't have to reset the whole thing,
but you can do like a refresher where it's less, it's a much smaller,
I think, every year or something.
I didn't know that if they've done that, that certainly sounds good.
It would be good to keep up with what's new.
But to be honest, I don't think I would mind be sort of redoing the full thing.
I mean, the exams are sort of two and a half, three hours,
and that time flies by.
And it does, I think it would force me to sort of go over the areas again
that I don't use so often.
And there were certainly sort of parts of the syllabus where I thought,
I know that stuff, I don't need to spend too much time on it,
but then digging into the syllabus a bit and uncovering it,
I found a whole load of sort of changes and improvements
that probably would have caught me out, but genuinely useful to know.
This just seems to be such a good gap analysis of your knowledge as well.
Yeah, absolutely, absolutely.
With this learning thing, I wonder what your thoughts are on
like having schedules and goals as part of your learning.
Parce que je dois boucher cet examen pour que je sois un goal et une ligne de délire
pour me donner un focus.
Vous avez fait un point au numéro un, le top tip que je voudrais vous donner.
C'est intéressant, en fait, de la certification.
J'ai eu beaucoup de commentaires sur les lines de...
Je l'ai regardé en faisant ce que je dois faire.
Mais pour être honnête, je pense que vous avez besoin de goals.
C'est important de avoir un goal et d'avoir un temps de scale.
Donc mon conseil serait de aller au website Microsoft Learn,
qui est une bonne ressource.
Regardez les passées de certification qui sont disponibles.
Decidez de la manière dont vous pensez que c'est correct pour vous.
Pouvez un temps, mais pas trop.
Vous ne besoinz pas beaucoup plus que peut-être,
en demi-deux, pour les browse au syllabus.
Et juste faites votre meilleur guess de combien de temps vous pensez que vous allez avoir besoin de préparer.
Et le prochain que vous devez faire, c'est de vous évoquer l'exam.
Parce que ça va être une fête de mouvement dans votre diary.
Ça va vous permettre de travailler contre ce goal.
Et ça va me aider à prioriser et faire sure que je fais le right amount de études pour le service.
D'accord, quand on termine la recording, je vais évoquer mon Z900.
Vous pouvez le tenir sur ça.
Je ne sais pas, peut-être deux semaines, je pense que ça devrait être bien.
Parce que je pense que je sais beaucoup de choses.
Je veux juste aller en fait sur ça, mais oui, je vais avoir ce livre.
Oui, ça me fait bouger à quelque chose d'autre.
Une des choses que les certifications sont souvent en conversation,
c'est de voir comment vous travaillez pour improvement les gens sur votre équipe,
les gens que vous êtes responsables pour, les gens techniques,
qu'ils veulent créer et développer.
Je pense que les certifications peuvent être une partie utile pour cette route.
Je me souviens souvent d'être frustré par les titres qui existent dans notre profession.
Vous voyez la phrase « senior developer » sur la CV, et honnêtement,
vous n'avez pas l'idée de ce que ça veut dire de la tâche de la salle.
Vous avez des places qui vont déterminer le tâche de la salle « senior developer »
parce que vous avez été là un certain nombre de temps.
Ou, en lieu de la paix,
c'est une des professions les plus structureuses
quand il s'agit de progresser les gens.
C'est fascinant pour moi.
Je suis un modèle qui utilise un moyen de penser sur ce que ça veut dire « senior developer ».
Je pense que je vais avoir vu cela dans trois zones
qui sont tout en déterminant à un certain extent.
Le premier de ces zones est la capacité technique.
C'est quelque chose que nous avons parlé un peu.
C'est un des meilleurs que je pense en termes de développement.
Mais c'est aussi l'un des zones qui est probablement plus agressif.
Si vous vous interviendrez un peu plus,
vous avez besoin d'une curiosité,
d'une passion,
d'une passion proactive,
d'une passion qui veut savoir comment les choses travaillent.
Vous avez besoin d'une personne qui peut développer
une bonne attention aux détails et des rigotes.
Ils vont soumettre de la qualité de travail.
Ils vont faire sure qu'ils ont de bonnes coverages.
Vous voulez une personne qui veut
avoir leur travail terminé,
ne pas procrastiner,
ils peuvent compromise.
Ils ne doivent pas avoir la solution perfecte.
Ils savent ce que c'est bon enough
pour les gens à sortir de la porte.
Ils ont un degré de courage.
Ils sont capables de faire des changements signifiaires
quand ça fait du sens.
C'est souvent que vous voyez des bases de code
où vous avez été affaire à la détails,
à faire des factures plus grandes.
Vous avez le contrôle de la source.
Si vous avez délégué le mauvais,
c'est facile de le mettre en bas.
Mais si vous ne faites pas les changements,
ce tech-debt va continuer à monter.
Donc, quand vous mérisez ça,
la certification est une bonne façon
de donner des objectifs.
C'est quelque chose que
la personne qui a pris la certification
va se sentir bien et bénéficier.
C'est un objectif très clair et visible
que vous pouvez achever.
Je pense que parfois les entreprises
se préventent de ça.
C'est une bonne quote.
Je ne peux pas me rappeler
qui a dit que c'est une conversation
entre un CEO et un CTO.
Et je pense que le CEO est en train de dire
qu'est-ce que nous donnerons à tous
toutes ces certifications
et qu'ils se mettent en place.
Et ce CTO se tourne et dit
qu'est-ce que nous ne le fais pas
et qu'ils restent.
J'adore ça.
Oui, je suis un peu
un peu nerveux
sur les goals smarts
qui sont en train de
faire des histoires complétées
pour la production.
Parce que c'est le travail de la cour.
Mais tout ce qui
peut démarrer la grossesse
et l'understand
est valable.
J'ai étaté des courses de travail
sur le terrain de la course,
par exemple, sur le site pluriel
où j'ai travaillé.
Donc, en regardant les
zones techniques
que les développeurs ont travaillé
et en regardant les courses
qui peuvent aider
et faire des expériments
et en étatant de cette façon.
Qu'est-ce que ce serait
quand vous vous intervievez
des indications importantes
que vous avez en regardées ?
Pour l'exemple de ça,
je vais couvrir
les deux autres zones
parce que vous avez juste parlé
de la capacité technique.
Donc, les deux autres
grosses facettes
que je suis en regardant
et que je suis achetée
sont, secondément,
un sens de connecté.
Donc, la connecté
est tout à fait
réalisé
que vous n'êtes pas
l'une seule personne
dans le monde.
Vous avez un équipe autour de vous
et que vous n'êtes pas
l'un des deux meilleurs
dans le monde.
Et il y a un vaste
extérieur
qu'il y a d'autres
que vous pouvez apprendre
et partager.
Donc, une personne
qui a un sens de connecté
qui a un désir
pour contribuer,
un désir
pour apprendre à d'autres.
Et ici, je suis en regardant
pour évidence
de aller à des groupes de utilisateurs
en travaillant sur les projets
d'open source.
Si vous êtes plus senior
en établissant
et en appuyant à d'autres gens,
peut-être en déliver des talks
dans votre compagnie,
en code-pairing.
Et un sens de l'empathie
avec d'autres,
très rarement,
n'importe comment vous êtes senior,
vous allez avoir la meilleure
solution à un problème
avec de l'impact de la connecté.
Vous pouvez avoir les meilleures idées
par entendre
ce que tout le monde
dans la team
a offert
et prendre les meilleures de eux
et former une solution
qui fait que tout le monde
ressent que ils ont été inclus
dans la conversation.
Et la décision
qui s'est faite
n'est pas votre idée,
mais vous ressentez
que vous avez été écoutés.
Et si vous vous êtes

vous allez se sentir bien
sur la décision
qui a été faite.
Il y a un livre
vraiment brillant
que je l'ai entendu.
C'est inaudible.
Je l'ai entendu.
Il y a quelques années
qui décrivent exactement
ce que vous dites.
Je ne sais pas
si vous avez lu
les cinq dysfunctions
de la team.
Je l'ai.
Oui.
Un excellent livre.
Très bien.
Je recommande ça.
Je pense qu'on va
re-listener ça.
Oui.
Et je pense que
l'un des messages importants
sur ce livre
est de vraiment
avoir cette emboute
et de listening
à des gens
et ne pas être
l'un des voix
dans le salle.
En termes de
les doigts que vous pouvez donner
à des gens
en développant leur connecteur,
vous pouvez voir
l'évidence
d'attendre des
meetups,
des présentations techniques.
Je pense que ça peut être
assez d'intention
pour certains gens.
Il y a beaucoup
de moyens
d'apprécier
à des gens
de leur voix.
C'est un des
incroyablement nerveux
de leur voix.
Vous pouvez commencer
à vous dire

des idées
pour vous

dans les stand-ups
ou juste
vous demander des questions
en faisant
des démonstration
dans les
vidéos
et des
tels
pour
faire plus de
parler
dans leurs
groupes
et
des
groupes
d'utilisation.
Il y a un path
pour
avoir une voix.
Mais aussi,
en faisant des meetings
et en
être un
éclairant,
en enversant la communauté,
si vous utilisez
une technologie particulière,
il y a certainement
d'être un groupe d'utilisation
pour cette technologie.
Donc,
allez en apprendre
ce que vous pouvez faire,
ce que vous pouvez
faire pour les équipes.
Je l'ai
souvent trouvé
que,
parce que
je fais des
parler.
Parce que
je les fais
internait
en partie
de la team.
Je trouve que
les équipes
veulent
faire des parler internaites
aussi.
Et puis,
comme plus de gens le font,
il commence
à s'y séparer
sur la team.
Et c'est vraiment
satisfait de
voir ça se passer.
Oui,
je l'ai absolument apprécié.
Je pense que les
choses
qui sont en train de jouer
dans le cadre de la
connecté,
c'est
juste de résolver
les progrès
pour les groupes
et
de
payer des codes
de temps.
Même
l'évidence de
produire
une grande documentation
technique,
c'est un autre
point.
Je
j'aime vraiment
le
programme de paire.
Pas
le projet
qui
je travaille
sur,
mais
j'ai
fait
des programmes de paire
tous les jours.
Et ça me


beaucoup
de paire.
Parce que
je sais que
beaucoup de gens
pensent que
c'est double
les ressources.
Donc,
on ne peut pas
faire ça.
Mais en fait,
je suis sûr que vous avez entendu
le terme
de Rubaduc Debugging.
Pour les
listeners, c'est
si vous avez un problème
et que vous expliquez
à quelqu'un
et le acteur
explique
en parlant,
vous vous solvez
la probleme
vous-même.
Et je
j'ai trouvé
avec la paire
programme
que c'est
Rubaduc
de développement
tout le temps.
Parce que vous
vous parlez
tout le temps.
Absolument,
absolument.
Oui,
et je pense
que le tout connecteur
c'est évidemment
que je suis pris
à un niveau tout nouveau
durant la pandémie.
Je me souviens
que
la pandémie
a été
en train
de se faire
une grande vitesse.
Nous étions
en train de faire
une propre lockdown.
Je
changeais
les équipes
dans la
compagnie
où je travaillais.
Et
la première
salarité que je suis allé
dans la nouvelle équipe,
personne n'a pas
eu leurs caméras.
Et
je suis allé
dans un équipe
où nous avons
un sens
de communauté
et de camaraderie.
Et
il n'y avait
aucune énergie
dans ce stand-up.
Et c'est le premier
qui m'a dit
que c'était correct.
Fais votre make-up
et le dresser
et le mettre sur les caméras.
Vous
avez mis votre make-up
dans le
chien, James?
Bien sûr.
Oui, bien sûr.
Mais
instantanément,
l'énergie
qui
se dévouait
dans le zoom
était
puissante.
Ça fait
une différence

Je ne m'en souviens pas
que
l'équipe qui est
bandée
autour de ça
peut être
80% de communication
visuelle
plutôt que
les mots actuels
que vous dites.
Et c'est
vraiment vrai.
C'est important
de voir
comment
les gens
réactent
à ce que vous vous dites.
C'est
magique.
Je veux
même essayer
de l'exercice.
Juste
essayer de
faire une rencontre
sans les caméras
et puis
les mettre sur les caméras.
C'est
comme un magique
spécifique.
Et
la
partie
aussi,
c'est important
de ne pas
juste aller
en business.
J'ai
mis
un
défi
pour
la pandémie.
Et
la première
chose que je
toujours
fais
est de
parler
de ce que le
temps est
et de
parler de quelque chose
qui a été
en train de

sur la
news.
On

de

ce qu'ils ont fait
pendant
la semaine.
Nous
sommes tous
des gens.
Nous
avons des
vies.
Et je pense que
il faut
respecter
cela.

ça
m'a



Et






















c'est

Je



important.





les
rangs.
Et
je pense
que
je vais
en

la
question.
Et
je
pense
que


gitu.
Je pense.
Elle
est

ших qu過
they're
okay.
Pete
into
C'est un mindset très important.
La personne avec des skills de leadership
va savoir comment développer,
comment suivre un sens de purpose.
Ils sont contents de rappeler
et de faire des choses qui sont débrouillées,
pas seulement les choses qui sont faites,
mais aussi la culture, les tracts de la vie.
Ils ont une responsabilité,
ils ont un mindset de l'aider.
Ils savent que les gens
vont être personnellement en ligne
pour déliver des solutions de travail.
Évidemment, la communication et la persuasion
sont importants,
d'être capable d'effectiver et d'agir des idées
pour assurer que la team
soit informée de façons rélevées.
Ils comprennent et contribuent
à une stratégie de travail
et à assurer que le développement
est aligné à cela.
Ils peuvent faire des décisions
basées sur le valeur de travail.
Ils savent que le prochain
le droit de faire.
Ils peuvent prendre une stratégie
et débrouiller la stratégie
pour les séquentiales.
Je pense que ce sera plus difficile
pour les gens.
Mais, encore,
les petits stepes
d'increaser
le niveau de responsabilité.
Si vous avez une solution complexe,
peut-être donner l'ownership
d'une particularité
ou d'une responsabilité
pour une technologie
que vous utilisez.
Vous pouvez gradually
évoluer le niveau de responsabilité
que vous donnez à les gens.
C'est un aspect

Vous avez dit que
quand il s'agit d'interview,
c'est important
de vous dire
que vous devez être
vraiment clair
ce que vous avez à faire
de la part de la part
et de la raison
pour laquelle quelqu'un
veut se faire
et de se faire
ce genre de choses.
C'est incroyable
de voir comment ça se passe.
On doit avoir 3 plus de développeurs.
Pourquoi?
Qu'est-ce qu'ils vont faire?
Pourquoi ils vont faire ça?
Pourquoi ils veulent faire ça?
La chose importante
à l'internet
est de vendre le travail.
C'est incroyable.
Les gens ne font pas ça.
Ils vont en faire
à l'internet.
Je vais parler de ça
et de ce que vous avez
pour les interviewer
et de convaincre
que vous avez quelque chose
qu'ils vont en faire
et qu'ils vont en faire.
Ils ne vont pas
en faire.
Ils vont en faire
une fois.
Qu'est-ce que vous avez dit?
Qu'est-ce que vous avez dit?
Qu'est-ce que le développeur?
Il peut être tout de même
quelque chose qui se fait
pour le rôle.
Si vous avez des gens

vous avez une GT
pour expliquer
quel est votre company?
Qu'est-ce que vous êtes en train
de faire?
Pourquoi ils vont en faire
pour les prospects de leur vie?
Je me demande

les interviews
même si c'est pas le premier interview
qu'ils ont eu.
Parce que
peut-être qu'ils ont eu le premier interview
avec le manager de la haute.
Le manager de la haute a eu un perspective différent.
La personne va avoir eu
une opportunité de penser
sur ce qui a été dit.
Donc, juste vérifier que nous sommes tous
sur la même page et que c'est quelque chose
qui est bien.
Je pense que, d'un point de vue
de l'interview, c'est très important
de se rappeler que, comme vous l'avez dit
c'est un interview de deux manières
et de poser des questions.
Ne vous affairez pas les questions
de la même manière.
Oui, et c'est encore quelque chose
que je vais dire dans le premier part.
Je vais demander si ils ont des questions
mais je vais aussi dire que
peut-être qu'ils n'ont pas eu la chance de formuler les questions que vous voulez.
Vous avez juste eu un whole bunch de informations.
Donc, vous pouvez vous dire que je vais vous dire
que je vais vous dire que je vais vous dire
que je vais vous donner un moment
pour vous demander quelque chose qui peut
s'occuper de vous durant l'interview.
Donc, évidemment, on doit
parler de la candidate.
Je pense que je dois vous dire
que, d'un point de vue de technologie
technologique,
je ne vais pas nécessairement
regarder pour quelqu'un
qui a précisément les skills
que nous avons besoin pour le travail.
Je pense
que vous devez être très heureux
de trouver quelqu'un qui a un bon
kit techniquement avec ce que vous êtes en train de regarder.
Même si vous utilisez la même technologie,
beaucoup de technologies peuvent être utilisées
dans des diverses différentes manières.
Vous pensez au terrain de la surface,
comme les Kubernetes, par exemple.
Il y a beaucoup de principes communs
mais vous pouvez l'élever dans
de nombreux diverses manières.
Je suis le plus intéressé
dans ce que quelqu'un a dit
d'avoir
l'expérience et l'expertise
parce que je peux utiliser ça
comme un arbre.
Si quelqu'un décide d'être un expert
dans C-Sharp
mais il n'est pas capable de me dire
ce qui se passe dans le landscape de C-Sharp,
ce que les nouvelles features sont
qui sont en train de parler
effectivement de ce qu'il y a dans la langue,
ça va évoluer
un peu de belles mouches.
Si c'est pas un expert
dans C-Sharp,
qu'est-ce qu'ils veulent faire
pour qu'ils soient en train de parler
?
Ne vous faites pas attention
de ce que vous faites
pour que vous connaissez.
La surface est tellement grande
qu'il est juste inondable
d'exprimer les gens
pour savoir ce que vous savez.
Vous ne devriez pas être mesurés
d'un autre personne
pour savoir ce qu'il y a
pour savoir
ce qu'il y a pour le travail.
Qu'il y a pour être étrangers
d'un grand nombre
d'essais de retraite
qui peut évoluer quelqu'un
qui, si quelqu'un a démontré
qu'ils peuvent avoir des expériments
dans un langage de programme,
ils peuvent probablement être étrangers
d'un niveau équal de l'experiment
dans un autre langage de programme
ou dans une technologie qui est une même.
Donc, vraiment, je suis en train de
dire que c'est bon
pour les gens qui disent qu'ils sont bons.
Ça fait le sens.
Je peux imaginer beaucoup de
interviewers qui sont peut-être
les développeurs,
à l'heure où je vais
faire un contest.
Oui.
Peut-être pas assez,
mais c'est ce que je voulais,
que je l'ai fait.
Oui, non,
je ne le vois pas.
Je pense
que c'est un bon point de dire
que je dois toujours
dire des questions
des questions des questions
pour les gens d'une opportunité
pour me dire de leur propre manière.
Et je me couvre
en 5 différentes catégories.
Donc, la première
catégorie réellement à ce que j'ai dit
c'est de la culture.
Et j'adore cette expression.
On parle souvent de
faire surement que quelqu'un soit un bon
culturel.
Et je pense que c'est dangereux
parce que
souvent,
on a tendance à faire le mistake
d'y acheter dans notre propre image.
Vous pensez que ce qui est bon est quelqu'un
qui est comme vous.
Et c'est une attitude assez arrogante
pour vous.
Je pense que c'est un ad culturel,
parce que, au lieu de regarder quelqu'un
qui peut complémenter les skills
que vous avez déjà dans votre équipe,
qui peut vous donner
quelque chose de nouveau pour votre équipe,
vous donner une nouvelle perspective.
Je regarde
l'explorer
ce que quelqu'un a fait
qui est unique pour eux.
Comment peut-je
bénéficier de travailler avec cette personne
comme si c'était un de leurs équipes?
Je leur ai demandé
de leur dire
comment quelqu'un d'autre a
résolu le problème,
ou d'autres d'autres de leur perspective
qui ont aidé à accomplir quelque chose dans leur rôle.
Et puis, en répondant à cette question,
les gens souvent
parlent de
des solutions techniques
qui ont été employées dans un problème.
Et puis vous avez l'opportunité
d'aller en question de la technologie.
Mais vous vous invitez à un moment
où ils se sentent confortables en parlant
de quelque chose.
Donc, l'un des deux zones
est l'innovation.
Donc, c'est tout pour
explorer la créativité des gens,
l'opportunité de venir avec de nouvelles idées
et de nouvelles manières de faire des choses.
C'est une opportunité de voir
ce qu'ils sachent de la technologie
dans le landscape,
de nouvelles manières que ils peuvent déployer
une technologie pour résoudre les problèmes.
La troisième
est l'obligation
d'obligation de leur décision
sur l'évidence.
Donc, un bon exemple
est de vous faire surement
que vous devez mettre un certain SLA
ou un certain score de performance.
Comment pouvez-vous en faire
l'évidence ?
Est-ce que vous pouvez analyser les loges ?
Est-ce que vous pouvez regarder les plans d'exécution
dans un database et figurez
les choses qui sont les plus correctes
pour optimiser ?
Si vous regardez un nouveau
feature pour un produit,
comment savez-vous que c'est le right feature
pour regarder ?
Est-ce que vous pouvez collecter le data
sur les features que vous utilisez
et utilisez-les pour faire des décisions
sur le prochain feature
ou le right way pour enlever le feature ?
Est-ce que vous pouvez
utiliser le data
pour dire si le travail que vous avez fait
a été valable ?
Si vous avez mis un nouveau feature,
avez-vous mis le right métro ?
Est-ce que vous avez mis le right

les gens qui utilisent le feature
et le manière dont vous avez voulu
les bénéfices que vous avez voulu ?
Je pense que ça
matchs sur le tout.
Dans les jours où j'ai vécu
les produits et j'ai pensé
que les gens de la chaîne
ne m'ont pas oublié
d'avoir des plus modernes teams
qui ont des bonnes conditions
en production,
et que les métros et la télématrie
sont des développeurs
plus conscients
de les conséquences si vous ne faites pas ça.
Oui, absolument.
Je pense que c'est quelque chose
qui est souvent overlooké.
Je pense que, comme un problème,
cela commence vraiment très rapidement
dans le processus.
On est souvent assez en train
de faire des business.
Vous fallez dans ce trap
peut-être un manager
ou peut-être un personne sales
de vous demander
votre équipe de développement
que votre client vous a demandé
et que vous avez entendu.
Et ce que vous faites effectivement
c'est de mettre en place une solution
plutôt que un problème
pour votre équipe créative.
Et si vous avez le droit
à ce niveau, vous avez ce type
de l'effet de la snowball.
Ce que j'aime vraiment
c'est que les objectifs business
sont expériments
comme problèmes.
Donc, pour exemple,
un bon objectif peut-être
que je veux réduire le temps
qui prendra des nouveaux clients
pour remborder notre produit
à 50%.
Tout d'abord, cela va vous ouvrir
pour toutes les types
de créativité,
de la créativité technique
pour se solider ce problème.
Vous avez un bon measurement
d'un certain nombre de temps
qui prendra des clients pour remborder.
Les développeurs peuvent commencer à penser
que ce que nous pouvons faire,
quand est-ce que la remborder est en train?
Quels médecins peuvent-ils mettre
dans les features qui permettent de remborder
ce temps?
Par exemple, je vais vous raconter
un autre jour sur le code
pour une extension
dans le code visual studio
qui vous aide à remborder
un code base.
Cela peut être utilisé pour réduire
le temps qui prendra des développeurs
pour remborder un point de vue technique.
C'est un moyen de approcher
le problème de remborder le développeur.
Mais si vous avez été
offert un feature
pour créer une image de machine virtual
qui est installée par les tools de développeurs,
ou faire des constructions
de documentation pour remborder,
peut-être que vous avez perdu l'opportunité
d'avoir une solution créative
pour ce problème.
Mais, je pense que le plus important
de retourner au début de ce problème,
c'est que, avec les médecins
dans le cas de place, vous avez
l'obligation de tester
une toute variety de solutions
pour ce problème et choisir le plus efficace.
C'est donc important
de ne pas être en train de
impliquer des features de la backlog,
mais d'être capable de comprendre
si ces solutions sont effectivement
solides au problème de la cour
qu'elles ont été créées pour s'adresser.
Je pense que beaucoup de développeurs
pensent des médecins et de
la mesure de la performance
ou des choses très techniques
et ne pensent pas
aux médecins et des médecins.
Oui, et vous devez m'en rappeler
que la raison pour laquelle vous êtes
en train de s'y prendre
est pour faire du ménage pour la compagnie.
Si vous êtes en train de coster
la compagnie, plus que
vous ne faites pas de vous,
vous êtes, en définition,
plus utile pour eux.
C'est-à-dire que vous êtes plus utile, plus liébile.
Et surtout pour les jeunes seniors,
c'est important
d'avoir un sens
qu'ils sont là pour cette raison.
Et je pense que c'est particulièrement
difficile
d'avoir un liste de la logique
qui fait que c'est tellement intangible
que si vous avez des problèmes
qui ont été créés par le business
et que vous entendez clairement
les problèmes de la rationale
c'est tellement plus facile
de se tourner et prouver
à ce business que vous êtes
plus élevé que de la paix, par exemple.
Donc, le next area
que je vais regarder est la collaboration.
Et ça va retourner
dans ce cercle que nous avons parlé de avant.
C'est que, peut-on participer
en partage de la équipe?
Vous pouvez explorer ça
par en me dire que quand vous étiez
en train de travailler closely avec les collègues
pour atteindre un objectif.
Qu'est-ce que vous avez fait pour votre équipe?
Qu'est-ce que vous avez acheté?
Ou vous avez demandé à quelqu'un
d'avoir une désagrément
avec quelqu'un de la équipe?
Qu'est-ce que vous avez désagrément?
Et c'est incroyable comment beaucoup de gens
m'ont dit
qu'il y avait un argument plus grand
et qu'ils avaient fallu sortir
avec quelqu'un.
C'est l'empathie, l'understand
qu'il y a des différentes views.
Il y a un point que je fais
pour pouvoir considérer
toutes les options et faire la choice
de la bonne façon de aller.
Ça fait que tout le monde sent que
ils l'ont été écoutés.
Mais vous ne vous en êtes pas
en analyse pour Alice.
Avec le tout argument,
les interviewees qui disent
pourquoi ils ont fait le travail précédent
et ils commencent à les léger.
C'est comme si c'était pas vraiment
vous en achetez comme individuel.
C'est une autre chose pour être careful
de l'interviewee.
Je pense que
en argumentant le sens propre
de la parole,
ne pas avoir un match de l'attention
mais pouvoir mettre en place
une proposition et examiner
et trouver la meilleure solution.
C'est important.
Et c'est en plus
d'être un art perdu.
L'univers moderne semble être
un endroit d'incréément des opinions polarisées.
On doit être très attentionnés
pour être responsables.
Il s'applique absolument
dans le développement
et pour essayer de lever
toute l'expérience pour avoir la meilleure
solution.
Ce n'est pas en train de choisir
votre solution ou ma solution.
C'est en train de s'améliorer
quelque chose de plus grand que
l'autre des parts.
Le final est
en train de gritter la termination.
C'est là que la question classique
est de savoir comment vous l'avez appris.
Je suis en train de
poursuivre à l'admiration
quand il est le temps
ou quand il ne connaît pas quelque chose.
Et vous pouvez apprendre
de ça.
Comment vous l'avez compensé
pour le problème que vous avez appris?
Tout le monde a leur histoire.
Tout le monde a leur histoire.
Je peux vous dire
que j'ai déclaré
dans un database de production
que j'avais à
prendre des heures frantices
pour rébuilder le data.
Fortunatement, c'est des logs de transaction
qui sont disponibles.
Mais que l'ai-je appris
pour l'importance
de ne pas faire un code
que vous avez écrit dans la window
contre le database de production?
Mais en essayant de tester
le code en un stage
et en plus.
Et je pense que vous ne l'avez pas fait.
Je n'ai jamais fait ça.
Je ne vais pas le faire
dans le futur.
C'est aussi en vous demandant
que vous avez des goals que vous avez travaillé
et comment vous allez.
Vous pouvez voir les aspects positifs
comme les certifications que quelqu'un a été
proractif pour lesquels vous avez
appris leurs skills, pour vous
démontrer que ça peut être un bon moyen
de vous faire croire.
Toutes ces questions, tous ces areas
que nous avons parlé,
la chose importante pour moi
dans l'interview est que vous vous donnez
l'opportunité de vous dire leur histoire
et ensuite vous pouvez
prendre les détails techniques
pour vous faire croire leurs skills techniques.
J'ai vu
quelques de vos talks,
à l'expertise d'Adraxford,
des conferences d'ADD
et je pense que mon préféré
a été votre talk en books et en reading.
C'était super motivatif.
Je le read tous les jours
mais c'est pas si près que je l'aime.
Et chaque fois que nous parlons,
vous avez déjà lu 10 books.
Comment vous le faites ?
Je peux définitivement
l'adresser. Je vais le construire.
C'est bien de vous dire
que je suis
passionnant
des books. Ils sont très bons.
Mais ce n'est pas le seul moyen de apprendre.
C'est un moyen de réveiller.
Les meilleurs moyens de apprendre
aujourd'hui,
beaucoup de nous ont suffisamment de
aller à l'université
et faire un cours
de vocation relevant,
comme un degree de sciences de compétence.
C'est toujours amusant.
Les gens ont de
des batailles
incompréhensibles,
c'est un profession très open.
Je pense que c'est un grand nombre de choses.
Il y a beaucoup d'opportunités
et souvent,
les barrières de l'entrée sont
très bas.
Je pense que c'était Uncle Bob
qui dit que le profession
est double de nombreuses
développeurs, chaque 5 ans.
C'est à quoi que, à un moment,
les développeurs de l'université
ont moins de 5 ans d'expérience.
Mais la technologie,
c'est toujours en train de bouger.
Les recherches académiques
sont en train de bouger.
Je paye attention
à ce qui se passe
dans les cercles académiques
et de essayer de prendre un temps
de regarder des papiers académiques,
ce qui est quelque chose que les gens
ont souvent de l'invente.
La science de compétence ne s'arrête pas
quand vous allez à l'université.
Si vous n'avez jamais vécu,
c'est plus important de regarder
des textes académiques
qui sont là-bas.
Ne l'oubliez pas,
c'est un peu important de regarder

Il y a beaucoup de gens
qui me disent
que je read des blogs.
Je me suis toujours crinché
quand je vois ça.
Comment vous le savez ?
Les blogs sont un mix-bag.
Il y a des blogs
d'aménages
qui sont là-bas.
Mais il y a aussi beaucoup de blogs
de marketing
qui sont là-bas.
Les blogs sont clairement
des brandes personnelles
qui peuvent être
des notes.
Ce n'est pas un bon
de la façon structurelle
de développer votre appareil.
Vous pouvez mettre un blog qui
solide tout le problème
que vous essayez de solider
ou que ça vous donne le bon niveau
d'intérêt sur la technologie.
Mais ils ne peuvent pas être
l'entrée de votre étude.
On peut donc
faire des tools structurels
comme PluralSight, Udemy et vide-based
qui sont extensivement utilisés
et c'est un bon moyen
d'apprendre des groupes d'utilisation
et de faire des confrances.
Surtout maintenant,
avec des confrances virtuelles,
c'est génial que beaucoup
d'entre eux sont vide-élevé.
Vous avez l'accessoire de regarder
ces podcasts.
Les podcasts sont un moyen fantastique
d'apprendre, bien sûr.
Je tend
à regarder des podcasts
comme des programmes
pour me garder abre de ce qui
se passe plus généralement
dans l'industrie. Je ne pense pas que vous
allez avoir de la technique de la podcast.
Mais il va vous donner un peu de
d'idées sur
les points de bulletin pour étudier.
Et puis, évidemment, juste parler
avec les gens, parler avec les gars
et votre équipe, et voir ce qu'ils ont trouvé
pour vous donner des choses à regarder.
Mais
toutes ces choses,
surtout les solutions techniques,
comme avancées,
ne sont pas
les bonnes
habilités techniques
que les livres ont toujours eu.
Les livres viennent avec ce feature.
Je sais ce qui s'est passé.
Les livres viennent avec ce feature
que aucune autre technologie n'a pu cracker.
C'est appelé le pause automatique.
Les livres sont morts.
Ils savent
quand vous ne payez pas attention.
Et ils automatiquement pausent.
Je ne peux pas vous dire combien de fois
je regarde une vidéo de confrétation
ou je écoute un tour de tour
quand le speaker dit quelque chose
et il me dérange
sur un tangent.
5, 10 minutes peuvent passer.
Et je n'ai pas perdu la tour
parce que j'ai perdu la version mentale.
Et même si vous êtes en train de faire un tour
de tour de tour,
vous avez toujours de réwinder
et de rélécouter les choses.
Mais avec les livres, vous ne vous en avez pas.
Les livres, ils vont rester
exactement où ils étaient
et vous pouvez aller en arrière
et aller en arrière.
Je l'aime.
Les livres sont souvent
un travail de passion.
Il y a quelqu'un qui a une idée
qu'ils veulent s'éteindre.
Ou qu'ils aiment vraiment
l'amour de la technologie
et le sens qu'ils ont quelque chose à dire.
Il y a beaucoup de travail
pour écrire un livre.
Les gens ne write pas des livres techniques
pour le monnaie.
Les livres peuvent être réveillants,
ils peuvent être des développeurs
sur leurs livres.
Mais il y a beaucoup plus de travail de passion.
Vous allez avoir
beaucoup plus de care et attention
dans un livre que vous allez voir
dans d'autres formes de médias.
Ils viennent
avec un éditor technique
et des reviews pierres.
Toutes ces choses servent à élever la qualité.
Often times,
they are written by multiple authors.
Ça me
brings me on
to how you should go about
reading technical books
and how you can read a lot of technical books
and do it quite quickly.
When I pick up a book
or when I hear about a book,
the first thing I'll do is walk through this little process.
Very simple.
I'll look at the title and I'll decide
is it interesting.
And I'll flip it over and look at the back of the book.
Read the blurb, the description there.
Ask the question again, is this still interesting?
Then look at the table of contents.
Asking the same question.
Then I'll look, if it's the kind of book
that lends itself to this, not all do,
but often you'll be able to read
the first and last chapter of every paragraph
where they give you the intro and the summary
and find out if there's something in there
that's still interesting that you want to know more about.
I think it's important to remember
that books aren't written in order.
Most of the time, there'll be one
message that is the most important
message that an author wants to get across.
And that's often where they'll start.
And you can have a great message
buried in a book that's otherwise,
frankly, quite a lot of padding.
So by going through the books this way,
you can really quickly zero in
on the part that is going to be
most valuable to you.
And again, especially when
books have more than one author as well,
you see this even more.
They're just not written in order.
And so you need to
get away from the idea that you have to
start at the beginning and follow every page
in order. As developers, we
have this very sort of rule-based
mindset and it can be a
really tough habit to break
that you almost feel dirty
when you start doing this.
You're jumping into a book and not reading
a significant chunk of it.
But you'll get the essence of the book
really quickly and you'll be able to make
the right exit decision on a book
that isn't right for you much more quickly.
And there are great tools out there
to help you do this as well.
So I have an Aralee subscription,
for example, they used to be called
Safari Books Sunlight. You pay an annual fee,
you get access to a vast library
of technical books from all sorts of publishers,
not just O'Reilly.
And they also have video-based training
and live webinars and all sorts.
But the feature I love most is that I can put
a particular topic in
and I'll get results which give me
not just books
and webinars and so on that will talk
about that particular topic, but even the
individual chapters in books that will cover
a particular topic.
And you can learn so much more
by reading four or five different
authors' take on the same topic
than reading one opinionated viewpoint
that may leave out
key areas at the top.
But you get a much more rounded view
of the tools that can help. I'm a huge fan
of Manning.
I love the fact that they make all of their books
available early, the Early Access Programme
and that you can also download them
as PDFs. I use a tool called Good Reader
on my iPad
which
has a great feature which enables you
to bring up a tree of the structure of the book
and that can be really good for helping you
walk through a book quickly in the way that I
described previously.
The Early Access feature on Manning
gives you an opportunity to influence
the book. There is an active
forum where you can engage
with other readers of the book, you can see
the challenges that they've been having
and yeah, you can actually influence
the way that particular chapters are written
and can often get a lot more out of the book
that way.
So, use technology to
advantage. I now have my entire library
of, I haven't counted
but it must be hundreds
if not thousands of books
all sat on my iPad
either literally in there as
PDFs or available
through an online subscription.
But I guess the key question is
with all of those books out there
what books should
you read? And the way that I tend
to approach this is I think
about books in
four different categories.
So, the first category
I call Know Your Tools.

this is about
sort of not, don't fail
at the basics. As a developer
or as a UX guy, whatever it is
that you happen to be into
you're going to be using
a core set of tools every day
perhaps it's C-Sharp for example
you're a C-Sharp developer or insert
the language of your choice here. So, do you
know your language? Do you know
what Visual Studio Code can do? Do you know
what Visual Studio can do? Do you know how the compiler
works? These are the things that you
use day in, day out, every day
and they change
all the time. So, keeping up
to date on the specific tools
that you are using is so important.
You know, if you're a C-Sharp developer
things like, you know, if you've not
read John Skeet's book on
C-Sharp in depth then
what's wrong? You absolutely
should know that. But, even
books that sort of go into
the CLR in a bit more detail, Jeff Richter's
book, CLR via C-Sharp
it's a joy to read
and it will tell you fundamentally how
the .NET framework operates.
And even though the last edition of that
is now going back quite a few years, it's still
just as relevant for
the modern .NET core as it was
for the .NET framework.
So, yeah, for me that's
kind of table stakes. You need
to know that stuff and you need to keep up to speed with it.
So, the next category
I bring up is Know Your Theory.
Having said that the tools
the everyday stuff that you use is really
important, there is an element
to which that's going to have
sort of an expiry date on it
because technology changes all the time.
And I think we so often
overemphasise knowing
the latest
framework, you know, Angular
React
View, for example, on the front end
that we forget to
really focus on
what's underneath, what holds all these things together.
So, this area is Know Your Theory.
And, you know, I think I'm
really fortunate because I entered the profession
at a time where, you know, I had my spectrum.
This is a simple device.
You could pretty much
learn every aspect
of how that thing worked.
I
really feel for people entering the profession
today, when you look at a modern PC
you couldn't hope
to understand every aspect of how
that thing works today.
They're so big and so complicated now.
So, I feel really blessed
that I came in, it came into it
at a time when I could do that.
So, for people that
haven't had that opportunity
there's a book I would recommend, The Elements
of Computing Systems and every book I mention, by the way,
I'm going to give Dan a link to
a list of all the books, so you can
look at these afterwards. But this is a great book
because it takes
a very, very simple model
of a computer and throughout
the book starting from
simple logic gates, from NAND chips
and nothing else you build
through simulated software
and then eventually actual software you build
with all of the chips, like CPU,
the early, you build up, you know, sort of memory, the bus,
up to building an operating system,
a compiler and a programming language
and writing a game at the end of it all,
that is just, you feel that you
built every single aspect of that machine.
And it's a very simplified ideal machine,
but, yeah, those principles apply
against, you know, modern sort of
Windows and Linux based operating systems
and they're going to help you
make sense of that exception
or that crash and be able to get under
the covers of the language that you're using.

Other aspects of theory, things like
unit testing,
how to refactor code,
principles like dependency injection,
for example dependency inversion principle
or the single responsibility principle
and so on, how to produce
clean code,
how to produce threat models
for attack surface areas
of your code, design patterns
that you can use. All of these things
will transcend
any particular set of tools that you
happen to be using today.
If you have a good approach to unit
testing, you can take that and apply it
to any framework
or language that you happen to be using.
A good example of this,
for example in the testing space.
Something called approval testing,
it doesn't come up that often in articles
and podcasts.
So this is a great tool, you can read about it.
I think the URL is approvaltests.com
but it's a testing approach
that I've used multiple times
during my career.
The idea is this, is that you have
some test output
that by most means
would take an enormous
amount of work
to produce a set of passing tests.
So something like
maybe an HTML based report or a PDF output.
So
approval testing
takes the approach of we are going to create some output
and then
we're going to look at that
and decide if it's what we were expecting.
So we use our human eyes to go and look at this output
and decide if we approve
of that result.
And if you do approve of that result
then that becomes
the standard for all future executions
of the test.
So is this the same as snapshot testing?
Yes, basically it's very similar.
I think it's another word for the same concept.
So you take your approved version
and then every subsequent run of the test
is going to take the output that the test generates
and then do a comparison
to make sure it's the same as the previously approved version.
The really nice thing about
the approval testing libraries
and it's been sort of extended
to quite a large number of languages
now.
It will make use of the typical
different tools, so things like beyond compare,
tortoise diff, the visual studio
baked in diff for example.
And
if there is no match, it will fire up
that tool as long as you're running interactively
and highlight the thing that's changed.
So I think
I find that you can, in extreme cases
you can substitute what would have been
hundreds if not thousands of test cases
with one all-encompassing test
that yet still leads you
directly to the problem
should you have introduced
should you have introduced a bug.
Now it's not a panacea, obviously
it's one thing to have in your toolbox
and you will find that there will be times when it's
absolutely ideal for the matter at hand.
The principle, I've applied
to domains that have been using
lots of different programming languages.
So that's the kind of thing that I mean
by theory, things that are
reusable across a wide range
of technical domains.
Do you find that fits more with
front-end testing
or where do you find
that that fits? It's quite interesting
all these different types, you've got
unit test integration tests.
I'm doing
an episode next month
about this, is
mutation testing and
there's all these different types of testing
and so many different scenarios
and places where
each of these types of testing
work much better than other places.
Yeah, and so you kind of need
to have an appreciation of the full
suite of options available to you.
There's never going to be a one-size-fits-all.
To your original question
I think it does have broader applications
beyond just the front-end.
So just reaching through
my mind for a couple of examples,
I actually used it one time
when I created a
DSL, it was working for a place
that had, that did time sheet billing
and had some really, really complicated
time sheet rules.
You wouldn't believe how complex
it can get to work out somebody's pay.
But we created a DSL
to describe that and
it had a, you know
it was a writing
compiler, we had a fairly complex abstract syntax tree.
We were able to spit it out
in JSON to produce the output for an approval test.
We had very little time
to achieve this and
I think you could have gone down that road of testing
every single possible combination
of cases but writing some
exemplar programs
in this DSL, we were able to produce
a small number of outputs
of the AST and really
quickly verify that they were right.
And the disc comparison
to highlight lines of the JSON tree
where there were problems
was absolutely perfect way for us
to spot problems. I think we had
maybe five tests and if I had gone down
a sort of more typical unit testing approach
it would definitely have been hundreds of
hundreds of tests required.
Interesting with the last episode
where we had Jason Bock talking about
C-Sharp 9, source generators.
That feels like a perfect case
where you're actually generating code.
Does the generator code much
the expected snapshot?
Yeah, absolutely, absolutely.
But it is a technique that is often
very useful in the front end,
especially where you're using it to test
to save the output for a web page.
Because the challenge you have there
is that
a change in a component
that's used in a lot of places can end up
breaking large
numbers of tests.
But if you've got a small number of approval tests,
snapshot tests, it can be very quick to run
through and go, ah yeah, that's the
difference that I was expecting.
So the next
of the four catch, I think one number three now.
One of my favorite ones actually, because
again, this is one that is so often overlooked
by technical people
and that is know your business.
And there's two aspects
to this as well. So whatever
company you're working for, it's going to be
operating in some
particular business domain.
I've recently been working for a company
that, a maritime company, for example,
shipping is an absolutely
fascinating domain.
And it was so useful and so
important for me going as an architect
to understand how does
chartering work, how do you
manage a shipping company.
So I read a lot of books around that
topic, from sort of, you know, technical
books that talk specifically about how the
maritime industry operates to
actually, a book I just recommend to anybody,
because it's just a fascinating
book. It's a book called Deep
Sea and the Foreign Going, which
follows, written by Rose George.
It follows her
trip on a container ship
across the world. Absolutely
fascinating insight into
I think something that very
rarely has a torch shined
on to it.
So that's the first aspect, is do you know
the business of your business?
How does it work? And that can be
if you're doing any kind of, for example,
domain driven design, clearly
it's invaluable to be able to speak the
language of your business and
your customers and really know it well.
The other aspect is
that part of business that
applies whatever the business that you're in.
Are you able to speak
the language of the board?
Do you know how to read a company
balance sheet? Do you know the basics
of accounting? Do you know why
your company's share price is so
closely tied to EBITDA,
for example?
These are table stakes for having
a meaningful conversation
with the business. If you think that
a particular technology choice is going
to have a beneficial aspect to the business
you need to know how to be able to sell
that appropriately. So you need to
be able to talk in terms of
the business is going to understand.
The other aspect of this
comes into sort of knowing
the right kind of metrics
that you need to pay attention to
when you're running a team, a
DevOps process for example. Do you
understand the value stream
in your business? Do you know key
metrics like lead time and
cycle time and failure rate
and meantime to repair and why
they are important to a
business?
Having that lingo, it's
just going to make you so much more valuable
and approachable and meaningful to the
organisation where you're working.
So yeah, know your business.
I would love to see your
one note. Six months after you've worked
for a company.
It's
especially
the first 90 days
within a business where
you come in,
all you've really been able to glean
is what you've been able to do, sort of research
from the company's website and
you really don't know anything about them.
Those first 90 days, it's so
important to
absolutely immerse yourself
in what makes that business tick
and how they make their money
and what they're doing it for.
So the final category, I think possibly
the most fun one, is
I call it know something different.
So this is all about
expanding your horizons,
stepping outside of your comfort zone.
So that could be as simple
as learning a programming language
that is as far removed and is different
from the one that you're currently working
with. For a C-Sharp developer
an example I often come up with
is Haskell.
I can tell you that learning
Haskell
probably did more to improve
my C-Sharp
than any C-Sharp book I had ever read.
It gives you a different perspective
and I think people are often
so precious
about the language that they have chosen
to focus on.
How many Twitter storms have basically been
a bunch of C-Sharp guys saying
C-Sharp is the best, it's awesome. Java sucks
and the Java guy is doing the exact
reverse. It's so awesome. You advocate
for what you know.
This is a really
it's really important to step
outside your comfort zone and to understand
what else is out there and why
why other programming languages exist.
I couldn't pick up
Haskell compiler and write Haskell
programme off the top of my head now.
That's not what it's about.
If you're not using something day in day out every day
then you're going to get rusty.
It's just about getting your neurons
to fire in a different way
and understand different approaches
to the ones you're comfortable with.
I guess just experiencing different paradigms.
Absolutely.
C-Sharp has grown so much
as a language by embracing some of the ideas
in other paradigms
particularly obviously recently in functional programming.
But it's not and is never going to be
a way of taking a
pure approach to functional programming.
There is a reason why
F-Sharp, Haskell,
other functional programming languages exist
and C-Sharp is never going to replace them.
If you look at Go for example
I mean Go has taken the approach
of trying to take a very stripped down
simplistic approach and be a very
sort of bare bones language that has just
enough functionality.
That solves the problem
that I think is increasingly going to be a challenge
in C-Sharp where you have
any number of ways
of solving the same problem.
So you start to get into real challenges
of getting consistency in your code base.
If all of your developers
have to understand every possible way
of solving the same problem, that's going to
add cognitive load which is going to slow you down
when it comes to maintaining code.
So now you have to spend time
in C-Sharp code bases
making sure that you have a consistent approach.
If you choose a simple programming language
where there's only one way of solving a particular
problem that makes sense, then you're going to
end up with a much more
maintainable code base.
But that's not going to be right for every situation.
I notice for example that Go
is now introducing generics
into the language and I wonder if that's
the thin end of the wedge.
It'll be interesting to see
how effective they are at maintaining
that simplicity.
I keep on seeing on Twitter
people I know other to C-Sharp developers
slowly getting into Go
and I need to have a play.
I've looked at the syntax but I've not
looked deeply into it.
Equally, I've heard of people
that have gone into it, got very excited about it
and then ended up getting frustrated
when they end up having to do a lot of
repetitive coding because they aren't able
to create the nuanced abstractions
that you can create in a more
capable, feature-rich
language like C++ or SCAR
or C-Sharp or something like that.
Another good language that's completely
different, be Erlang
or sort of slightly more modern Incarnation
Nilexia, which is a language that
is very much based on
the actor programming model.
I took time out to spend
a lot of time playing with Erlang
and that really helps to solidify my
understanding of frameworks like
Aka or Orleans
which embrace the actor programming model.
But it doesn't have to be programming languages.
Si,
for example, you are frustrated
by the way that
your team currently approaches
agile development,
then
maybe looking into
agile techniques
that are out there, maybe really understanding
how to do SCRAM or Canvan
well, understanding
more about tools like
planning poker or user story
mapping or getting into
user experience design.
Just do something different, open your mind a little bit.
So that's the last
of my four categories.
So hopefully that gives you some ideas
and some inspiration of
different ways to in which you're learning.
But as I said, there's so many ideas
out there. I've developed
a created list of books
that have been interesting to me over the years
and I'll make sure that
then you have that for the show notes.
You're touching on that last point
that you just mentioned about
different paradigms,
even if you don't go to the extent of
something like elixir, that kind of thing.
Just if
most developers now are full stack
if you are solely a back end developer
or solely a front end developer
having a play around with
the other side or
do front end, back end, database
try some mobile desktop web
even within the modern
not modern, the more
popular ways of doing development
you've still got so many different streams
you can take and learn from.
Yeah, absolutely.
I just recently been playing with
Svelte. It's been around for quite a while now
but that's a fascinating
new direction
for front end frameworks where
the heavy lifting is all done
at the compilation stage
which means that it has
performance metrics
that are just below
the likes of React
and Angular away
because they've sort of compiled everything down
to simple code.
I remember a few years ago you did the talk, is it Elk?
What was the front end?
Elm.
Elm, that was it.
Yeah, that sounded like zero bugs
functional front end programming.
Yeah, fascinating.
Again, Elm
is kind of like the go approach
to functional programming. It's an extremely
striped down
functional programming language
which embraces the Model View Update
pattern
et yeah,
the selling point is that you have zero exceptions
from your JavaScript
and it pretty much holds up to reality
as well.
That's a fascinating take and requires you to think
a little bit differently about how you approach
software but actually Elm
very much informed
frameworks like React, I think, have taken
some great ideas.
This is a really good example of where
reading around other ways of approaching
problems can help improve
the space where you happen to work.
The React guys freely admit
to taking inspiration from Elm
and the development of that framework.
You can definitely see the MV
pattern just spreading out, as you say, React
taking on board that and even some .NET
stuff, like Microsoft is starting
to look at this MV pattern
as well with that stuff.
Right, so we are probably
probably running out of time.
So shall we do dev tips?
Sounds good.
So I have a dev tip for you.
This is one of my favourites
and this one is very simple.
When you have an exception
crop up, read the exception.
And I can't tell you how many times
I've sort of been sat there with somebody
and they've hit start
and the application is blown up.
And the first thing that they've done
is run the application up again.
And there's one of two things
that's going to happen there.
Most of the time
they'll get exactly the same error coming up again.
In a small percentage of cases
it will work.
And they've just thrown away
the opportunity to get the evidence
of that nasty race condition that's hard to reproduce.
They've thrown away gold.
But also, you know, if you've got bugs
being reported, often you'll find
in app insights or whatever logging tool
you happen to be using, you'll find
the exception.
Read the exception.
It usually tells you what the problem is.
And it's amazing to me how often we can just
overlook
because we are making a snap
guess at what the actual problem is
and end up wasting time
going down a completely blind alley
when the exception actually tells you
what the problem was,
where it occurred in the code
and even sometimes how to solve it
if it's a very well written library
de ce genre de exception.
Je me souviens de la dév-tippe
à Donnerd Oxford, il y a quelques années
et ça a été très utile
beaucoup de fois pour moi.
Une chose que je fais
et que beaucoup de développeurs
peuvent rappeler de ça
c'est que si je vois un error
mais je suis juste travaillé sur quelque chose
que je pense que je sais que c'est
je peux juste s'ignorer
l'erreur et aller au code
et voir le code et essayer
il doit être ça
et essayer de l'enlever
quand, comme vous le dites, si je l'ai juste arrêté
regarder l'erreur et le message
serait confirmé ou je ne pensais pas que c'était
ce que je pensais
juste se serrer
et il y a quelques fois
depuis que vous avez été de la dév-tippe il y a quelques années
parce que je l'ai arrêté
et c'est
vraiment valable
oui, ça peut bien
se passer
mais il faut que
la exception
soit causée
par un état qui a été créé
dans un autre processus qui a été passé
d'une autre fois et qui a été créé
et que vous n'avez pas de l'évidement
mais en fait
c'est par far le moins de cas
à la fois que vous avez l'information
que vous avez besoin de se solider
et que vous avez besoin de le faire
cool
donc mon dev-tip est
un tool de command line
qui s'appelle FZF
je n'ai pas vraiment été existé
comme James est nommé
mais je n'ai pas été existé
il y a un épisode
qui a été réalisé
par Patrick Spanson
qui était en train de parler de son
Spectre console library
qui était l'épisode 14
où mon dev-tip à la fin
était la toute
de notre histoire
en pauchel en bas
et
dans cette tweet
je vais réveiller son nom
mais je n'ai pas apologisé
mais il s'appelle Tommy
Lilhe Hargan
il est à TommyLiL
sur Twitter
et il a répondu à ce épisode
qui a vraiment apprécié
par le fait que vous avez regardé
votre conversation en utilisant le contrôle R
pour accéder à la histoire de command line
a-t-il essayé FZF ?
donc je n'en avais pas
mais j'en ai fait
et c'est assez cool
c'est une command line
Fuzzy Finder
et c'est la même chose
qui vous permet de piper le texte
d'autres commandes
et puis vous vous en portez
dans un mode interactif
où vous pouvez juste piper
ce que vous voulez chercher
dans ce texte
et il filtrera les lines
pour que vous puissiez chercher
donc si j'ai fait, exemple, ls, pipe, FZF
je peux très rapidement
aller sur le file
et quand je clique
l'output est
ce que je suis en train de filtrer
et ça fonctionne avec
d'autres textes d'input
file, ls, process
git command, tout ça
l'une chose que je trouve qu'il y a beaucoup de choses
c'est que je peux faire
quelque chose comme command, ls, pipe
FZF
pipe, clip
qui est un autre très utile
command line tool
et si je fais le save ls
ça interactuellement
me fait filtrer
en faisant le search FZF
et quand je clique
il va faire le dump
et je trouve ça utile
dans beaucoup de différents cas de utilisation
et je ne sais pas où j'explique
mais je peux vous dire
que je vais faire ça très bien
parce que c'est seulement audio
mais je peux inclure un lien
dans les notes de la show
qui a beaucoup d'examples dans un vidéo
et basé sur votre nodding James
il me semble que vous avez entendu
je peux le dire, knowing you, this will be something you would love
c'est impressionnant
comment le travail va faire
avec indexing, votre file system
c'est bien pointé aussi
que ça fonctionne sur windows et on Linux
mon conseil pour votre conseil
est de le installer deux fois
et le mettre dans les windows
mais aussi le mettre dans votre WSL
distro de choice
parce que ça interagira vraiment bien
avec amiz shell ou bash
des tools comme ça
pour donner une meilleure expérience de Linux
mais c'est vraiment bien
pour ces temps
où vous ne vous souvenez pas exactement
exactement ce que l'a fait
mais vous pouvez le remercier pour ce que c'était
le aspect de fuzzy match est
c'est détaillé
oui
je vais inclure le lien dans la show notes
je pense que c'est beaucoup de extensions
il y a des extensions vim
donc il interagira très bien avec vim
si vous êtes un vim usur
avec les shells Linux
il y a un script team
qui va ensuite mettre ça dans un autre panel
sur les résultats de la search
il y a juste que vous connaissez
quelque chose différent, juste là-bas
vous pouvez aller faire ça
des tools de file finding
et peut-être
un peu de Linux
si vous n'avez pas encore été dans ça
oui, c'est la même command line
je sais que les deux ou les uns sont des grands fans
mais il y a beaucoup de développeurs
qui ne touchent pas la command line
et ça, c'est un autre pari
et ils ne savent pas que les command lines
sont mieux que les goûts
mais vous avez
différents tools dans les deux
et par exclutant un
vous exclutant
des tools de productivité
qui peuvent vous aider
oui, je pense que maintenant
il y a beaucoup de fois
où les command lines sont les mêmes
donc je l'ai investi
dans le temps de la vim
et personne ne prétend
que ça requise un investissement
signifiant
il y a un curve de la vim
c'est assez bas
mais mon Dieu, ça s'applique
quand vous pouvez
aller dans une command line
sur un ssh
pour faire un pod dans votre
Kubernetes cluster
et pouvoir éditer les files
sans avoir un tool riche
je sais que c'est un autre moyen
mais c'est juste aussi rapide
je pense que c'est comme ça
avant de commencer la chute
on avait déjà parlé de Git
c'est probablement une conversation typique
mais c'est un autre moyen
je sais que vous êtes un avocat
de apprendre
sur la command line
peut-être avant que vous touchez de Gooye
mais vous pouvez vous retrouver
dans des scenarios où vous êtes
chelouant dans quelque chose
c'est tout que vous avez
oui, absolument, je sais que c'est un command line
c'est un bon tip
donc avant de la chute
vous avez d'autres choses que vous voulez mentionner?
je pense pas
je pense que vous avez tout le temps
on a probablement parlé pour aujourd'hui
je pense que nous avons réussi à aller
à beaucoup de choses
c'est un bon chac d'en
merci d'avoir invité
c'est ok, on a découvert beaucoup de choses
j'ai vraiment, vraiment, vraiment enjoyed
c'est été génial de vous
merci d'avoir regardé
et je vais vous entendre
avec intérêt
pour votre podcast de futur
c'est vraiment
vraiment été une bonne sélection
de guests que vous avez eu à la date
donc tout le best pour le futur
merci, je ne peux pas prendre la croix
c'est juste un grand guest que nous avons eu
j'ai juste le luck que l'industrie de développement de software
a eu une communauté superbe
et les gens sont tellement proches
de parler de technologie
oui, une chose que je voudrais dire
si quelqu'un a des bonnes recommandations
qui ne sont pas sur ma liste
s'il vous plaît, connectez-vous
à LinkedIn
ou envoyez-moi un tweet
et je vais les ajouter à la liste
on va définitivement faire ça
et merci tout le monde
pour l'entraînement
je vous remercie de ce podcast qui est sponsorisé par Everstack
qui est mon propre company
de software de développement et de services de consultation
pour plus d'informations visite Everstack.com
et si vous avez aimé le podcast
s'il vous plait, vous pouvez me séparer le mot
sur les réseaux sociaux
je n'ai pas utilisé le hashtag
et je peux trouver sur Twitter
appdraqueum
d-r-a-c-a-n
et mes DMs sont en train
et mon blog d'enclos.com
a des liens sur mon site social
et nous allons bien sûr
inclure les liens sur tout le monde
qui est mentionné aujourd'hui
qui sera une longue liste dans les notes de la show
qui peuvent être trouvées sur
UnhandledException
podcast.com
Sous-titres réalisés par la communauté d'Amara.org