There's a question that had been with me for a long time: am I a mediocre developer?
The world of software development is populated by a motley fauna, and over time I have learned to recognize the people who cross my footsteps. And it is also thanks (or through their fault) that this state of mind has matured.
I decided to share what I discovered in order to put myself in a mirror, made with other people, in order to verify if someone else has lived the same vicissitudes as me, and maybe to be able to find an answer to this question thanks to them.
Every developer experiences Imposter Syndrome, which can be summed up as "feelings of inadequacy in face of plenty of prior experience". This presentation will help you identify, avoid, and combat bouts of Imposter Syndrome in you and your co-workers or employees.
Imposter Syndrome is a condition in which one feels like they aren't qualified to do what they've been tasked to do or have gotten to where they are through sheer luck. Not only have I personally experienced this and continue to almost 20 years into my career, but almost every developer I've ever met has dealt with it.
When developing/designing/managing/cooking, do you ever feel like:
- You are faking your skills
- You are only where you are due to circumstances and/or luck
- Anyone could do what you're doing
- You don't understand why you're being trusted with the task
- At any moment, someone is going to discover how bad you are at your job
If you answered yes to any of these questions, then you may be suffering from Imposter Syndrome. Congratulations. Acceptance is the first step to recovery.
In my presentation, I'll talk about common ways that Imposter Syndrome expresses itself and some concrete tips & tricks on how to deal with it, both for yourself and coworkers or employees.
Every developer experiences Imposter Syndrome, which can be summed up as "feelings of inadequacy in face of plenty of prior experience". This presentation will help you identify, avoid, and combat bouts of Imposter Syndrome in you and your co-workers or employees.
Imposter Syndrome is a condition in which one feels like they aren't qualified to do what they've been tasked to do or have gotten to where they are through sheer luck. Not only have I personally experienced this and continue to almost 20 years into my career, but almost every developer I've ever met has dealt with it.
When developing/designing/managing/cooking, do you ever feel like:
- You are faking your skills
- You are only where you are due to circumstances and/or luck
- Anyone could do what you're doing
- You don't understand why you're being trusted with the task
- At any moment, someone is going to discover how bad you are at your job
If you answered yes to any of these questions, then you may be suffering from Imposter Syndrome. Congratulations. Acceptance is the first step to recovery.
In my presentation, I'll talk about common ways that Imposter Syndrome expresses itself and some concrete tips & tricks on how to deal with it, both for yourself and coworkers or employees.
Cognition as Material: personality prostheses and other storiesAlan Dix
Keynote at ECCE 2019 - European Conference on Cognitive Ergonomics, Belfast, UK, 10-13 September 2019
https://alandix.com/academic/talks/ECCE2019/
The golden rule of design is 'understand your materials'. For human activities and human science those materials include the physical and mental abilities of people and their individual personalities and cognitive styles. Within our own academic or design endeavours those people may be the subject of our studies, but also include ourselves. If we wish to design for people we need to understand them, and if we wish to do this effectively, we need to understand ourselves. In this talk I will analyse examples of processes and tools based on such understanding including some that foster technical creativity, even amongst those who would not consider themselves creative, and some that help in the difficult process of academic writing. Crucially, I will discuss personality prosthesis: taking seriously our differences in personality and seeing how each individual can surround themselves with structures and scaffolding that enables them to achieve their goals given who they are.
Thinking about giving a talk about something you love? Possibly at Skepticamp? No? Why not? Here are some reassurances, planning tips, and dos and do-nots to get you up there sharing your expertise with the world.
Still No Eye Deer (or things to do when your imaginary friends refuse to talk...Hannah Smith
Do you struggle to come up with ideas? Almost everyone experiences the feeling of being "stuck" from time to time, but how do you get yourself unstuck?
Hannah explores various types of creative sticking points, and share tips on how to overcome them.
In questa sessione io ed il collega Gianni Bombelli abbiamo presentato la demo di un progetto di Continuous Integration (CI) dove mostriamo come sia possibile continuare a fare CI usando i feature branch.
Il tutto è reso possibile dalle Multi Branch Pipeline di Jenkins.
Le slide della sessione tenuta all'Agile Venture di Milano, 1 febbraio 2020, presso gli IBM Studios.
Abstract
Come sviluppatore, nel tempo ho appreso ed applicato diverse tecniche per costruire software in grado di evolversi armonicamente su solide basi. Ora mi sto rendendo conto che, per analogia, alcune pratiche possono essere utilizzate efficacemente per far evolvere team di sviluppo.
In questa sessione condividerò riflessioni e spunti per far crescere i team e le persone che lo compongono.
Testare l'intestabile
Per me il codice legacy è tutto quel codice che genera business ma che abbiamo paura di modificare: pochi o nessun test, forte accoppiamento, if come se piovesse...
Vi è mai capitato di avere a che fare con codebase di questo genere? E magari di voler iniziare a scrivere dei test, ma questo è risultato pressoché impossibile a causa del codice stesso?
Prima di pensare al "Big Rewrite", ci sono alcune tecniche che possono venirci in aiuto, permettendoci di far evolvere il nostro prodotto poco alla volta, migliorandolo senza per forza buttarlo via tutto e subito.
In questo workshop useremo alcuni approcci ai test di caratterizzazione, come il Golden Master e i test di approvazione; queste tecniche consentono di ottenere una buona copertura in tempi ragionevoli, abilitando il refactoring e di conseguenza la successiva modifica ed estensione delle funzionalità.
L'agilità è oramai sulla bocca di tutti.
La sua diffusione non conosce confini, e oggi non è raro vederla applicata in ambiti ben lontani dalla produzione di beni e servizi software.
In questa sessione vorrei riportare l'attenzione sul prodotto finale, sulla sua qualità e sulla sua capacità di rispondere ai bisogni degli utenti: questo secondo me il vero Nord a cui la bussola dell'agilista deve sempre puntare.
Questa sessione è aperta a tutti, non solo a chi bazzica il mondo del software.
Per mezzo di un workshop pratico e divertente, esploreremo insieme valori e principi del manifesto senza citarli, bensì, applicandoli.
Al termine della sessione rifletteremo insieme sulle dinamiche emerse, cercando di ragionare sul processo di creazione del prodotto e sui fattori chiave del successo.
Slide usate in questo meetup: https://www.meetup.com/it-IT/Agile-Reloaded-Meetup/events/256500686/
I personally know some developers who are very talented and can create great pieces of software with no or little struggle.
Because of these gifted individuals, our industry is full of high expectations. But the sad truth is: not everyone is a ninja/guru/rockstar developer.
And that's exactly who I am: a mediocre developer.
In this talk I shared some thoughts and tips for surviving in the industry if you are not a genius.
MiniIAD201, Savona, 16/04/2016
Il breve racconto dell'esperienza maturata in questa piccola-grande pratica del lavoro di un programmatore: dietro ciò che sembra una mera prassi, si cela la chiave di volta dell'agilità.
Attraverso un suo uso consapevole, è possibile migliorare sia come professionista (ad es. imparando a suddividere il lavoro in piccoli task al fine di confezionare commit piccoli e significativi, oppure usando branch locali per sperimentare e di conseguenza imparare), sia come membro di un team (ad es. usando le pull-request come modo per condividere il codice ed eventualmente promuovere le code review).
Servono impegno e disciplina, come in tutte le cose importanti, ma alla fine si ottengono dei grossi risultati, sia in termini di crescita professionale che di consapevolezza rispetto ai princìpi delle metodologie agili.
Nella presentazione verrà menzionato Git, ma tutto il discorso prescinde dallo specifico strumento; inoltre non è previsto l'uso o la conoscenza di codice o comandi complessi, ma l'intera discussione cercherà di far leva sulle possibilità che abbiamo di migliorare l'efficacia e la collaborazione all'interno di un team partendo da un uso più “filantropico” di questi potenti strumenti.
Cognition as Material: personality prostheses and other storiesAlan Dix
Keynote at ECCE 2019 - European Conference on Cognitive Ergonomics, Belfast, UK, 10-13 September 2019
https://alandix.com/academic/talks/ECCE2019/
The golden rule of design is 'understand your materials'. For human activities and human science those materials include the physical and mental abilities of people and their individual personalities and cognitive styles. Within our own academic or design endeavours those people may be the subject of our studies, but also include ourselves. If we wish to design for people we need to understand them, and if we wish to do this effectively, we need to understand ourselves. In this talk I will analyse examples of processes and tools based on such understanding including some that foster technical creativity, even amongst those who would not consider themselves creative, and some that help in the difficult process of academic writing. Crucially, I will discuss personality prosthesis: taking seriously our differences in personality and seeing how each individual can surround themselves with structures and scaffolding that enables them to achieve their goals given who they are.
Thinking about giving a talk about something you love? Possibly at Skepticamp? No? Why not? Here are some reassurances, planning tips, and dos and do-nots to get you up there sharing your expertise with the world.
Still No Eye Deer (or things to do when your imaginary friends refuse to talk...Hannah Smith
Do you struggle to come up with ideas? Almost everyone experiences the feeling of being "stuck" from time to time, but how do you get yourself unstuck?
Hannah explores various types of creative sticking points, and share tips on how to overcome them.
In questa sessione io ed il collega Gianni Bombelli abbiamo presentato la demo di un progetto di Continuous Integration (CI) dove mostriamo come sia possibile continuare a fare CI usando i feature branch.
Il tutto è reso possibile dalle Multi Branch Pipeline di Jenkins.
Le slide della sessione tenuta all'Agile Venture di Milano, 1 febbraio 2020, presso gli IBM Studios.
Abstract
Come sviluppatore, nel tempo ho appreso ed applicato diverse tecniche per costruire software in grado di evolversi armonicamente su solide basi. Ora mi sto rendendo conto che, per analogia, alcune pratiche possono essere utilizzate efficacemente per far evolvere team di sviluppo.
In questa sessione condividerò riflessioni e spunti per far crescere i team e le persone che lo compongono.
Testare l'intestabile
Per me il codice legacy è tutto quel codice che genera business ma che abbiamo paura di modificare: pochi o nessun test, forte accoppiamento, if come se piovesse...
Vi è mai capitato di avere a che fare con codebase di questo genere? E magari di voler iniziare a scrivere dei test, ma questo è risultato pressoché impossibile a causa del codice stesso?
Prima di pensare al "Big Rewrite", ci sono alcune tecniche che possono venirci in aiuto, permettendoci di far evolvere il nostro prodotto poco alla volta, migliorandolo senza per forza buttarlo via tutto e subito.
In questo workshop useremo alcuni approcci ai test di caratterizzazione, come il Golden Master e i test di approvazione; queste tecniche consentono di ottenere una buona copertura in tempi ragionevoli, abilitando il refactoring e di conseguenza la successiva modifica ed estensione delle funzionalità.
L'agilità è oramai sulla bocca di tutti.
La sua diffusione non conosce confini, e oggi non è raro vederla applicata in ambiti ben lontani dalla produzione di beni e servizi software.
In questa sessione vorrei riportare l'attenzione sul prodotto finale, sulla sua qualità e sulla sua capacità di rispondere ai bisogni degli utenti: questo secondo me il vero Nord a cui la bussola dell'agilista deve sempre puntare.
Questa sessione è aperta a tutti, non solo a chi bazzica il mondo del software.
Per mezzo di un workshop pratico e divertente, esploreremo insieme valori e principi del manifesto senza citarli, bensì, applicandoli.
Al termine della sessione rifletteremo insieme sulle dinamiche emerse, cercando di ragionare sul processo di creazione del prodotto e sui fattori chiave del successo.
Slide usate in questo meetup: https://www.meetup.com/it-IT/Agile-Reloaded-Meetup/events/256500686/
I personally know some developers who are very talented and can create great pieces of software with no or little struggle.
Because of these gifted individuals, our industry is full of high expectations. But the sad truth is: not everyone is a ninja/guru/rockstar developer.
And that's exactly who I am: a mediocre developer.
In this talk I shared some thoughts and tips for surviving in the industry if you are not a genius.
MiniIAD201, Savona, 16/04/2016
Il breve racconto dell'esperienza maturata in questa piccola-grande pratica del lavoro di un programmatore: dietro ciò che sembra una mera prassi, si cela la chiave di volta dell'agilità.
Attraverso un suo uso consapevole, è possibile migliorare sia come professionista (ad es. imparando a suddividere il lavoro in piccoli task al fine di confezionare commit piccoli e significativi, oppure usando branch locali per sperimentare e di conseguenza imparare), sia come membro di un team (ad es. usando le pull-request come modo per condividere il codice ed eventualmente promuovere le code review).
Servono impegno e disciplina, come in tutte le cose importanti, ma alla fine si ottengono dei grossi risultati, sia in termini di crescita professionale che di consapevolezza rispetto ai princìpi delle metodologie agili.
Nella presentazione verrà menzionato Git, ma tutto il discorso prescinde dallo specifico strumento; inoltre non è previsto l'uso o la conoscenza di codice o comandi complessi, ma l'intera discussione cercherà di far leva sulle possibilità che abbiamo di migliorare l'efficacia e la collaborazione all'interno di un team partendo da un uso più “filantropico” di questi potenti strumenti.
4. A small premise
* It's about my experience, my history
* They're almost all personal opinions
I expect you don't agree, that you feel bored, annoyed or
that you think I'm really a loser...
And that's okay! : )
Just a courtesy: don't keep it for you, let’s talk about it!
@jesuswasrasta #AVBZ
5. My mediocrity, real or presumed
The way I perceive other people,
especially the “good ones”
There are two issues that concerns me:
11. Some time ago, I used to think I was good at it
@jesuswasrasta #AVBZ
12. Then I changed job and realized that I wasn't...
@jesuswasrasta #AVBZ
13. Dunning-Kruger effect
When you're so incompetent, you don't even
know how incompetent you are.
Wikipedia — Dunning-Kruger effect
@jesuswasrasta #AVBZ
18. Real good ones
* 👍 Those to welcome with open arms: intelligent, prepared,
persevering, generous, brilliant
* 👎 Those to be wary of: individualistic, impatient, toxic
The good ones but only ‘cause…
* They works in the same company since decades
* They prevent anyone from approaching their "castle"
* They sacrifice themselves for the cause
* Maybe they don't have a private life…
26. They’re in the same place since years
* They know the domain
* They know all the secrets, caveats, details
* Jealous holders of tacit knowledge
* Outside their world, they are in trouble
@jesuswasrasta #AVBZ
29. The good ones by contract
* Analysts, solution architects, and other mythological
figures imposed by someone
Let's be clear: there are
people with those titles
who are really good at it,
but I just think these
imposed figures are
more often than not a
dysfunction within the
team.
35. The 4 knowledge categories
* Things I know that I know
* Things I know that I don't know
* Things I don't know that I know
* Things I don't know that I don't know
Bonuses
* things you think you know, but you don't...
36. * Dunning-Kruger effect
* Imposter syndrome
How good you really are
How good
you think
you are *
*
*
*
@jesuswasrasta #AVBZ
37. Think well about how to invest your resources
* You can't learn everything...
* Choose the things with the highest value
* Learn what you can't easily search on the
internet
* Learn the basics
* Keep it simple
@jesuswasrasta #AVBZ
38. Be a T
«I-shaped»
Expert at one thing
«Generalist»
Capable in a lot of things,
Expert at any
«T-shaped»
Capable in a lot of things,
Expert in one of them
@jesuswasrasta #AVBZ
42. Empty silos
* Work with them, learn, involve, empty them
or at worst knock them down
* Talk to the people who run the company (they’re a problem!)
@jesuswasrasta #AVBZ
43. Defeat the guardians
See «I terribili “guardiani della codebase” - Paolo D’Incau» https://vimeo.com/259162101
44. Save the heroes
* Heroes usually dies in battle...
* If you are always in emergency, nothing is an emergency
anymore
@jesuswasrasta #AVBZ
47. And those who work more
than they have to?
I have a secret for you…
Working long hours
is CHEATING
48. But if these people are not a
problem for the company...
* If these situations are not perceived and addressed
* If they're not a problem for the company's managers, on the
contrary, "it's a good thing that there’s <put your name here>
that always saves us!"
Get a new job!
55. They're a gift.
Enjoy them!
* Work with them, look for confrontation,
try to learn as much as possible
* Ask them all the questions you can
* Explain the things you know to them.
You'll understand what you really know.