We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

5 Things I Wish Someone Had Told Me About Programming Before I Started

00:00

Formale Metadaten

Titel
5 Things I Wish Someone Had Told Me About Programming Before I Started
Serientitel
Anzahl der Teile
65
Autor
Lizenz
CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache
Produzent

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
There's more to being a successful developer than simply being great at programming. The gotchas that slow us down or trip us up are often outside of the code we write, manifesting instead in our process or how we work with our peers. Whether you're new to programming or a veteran of many projects, these 5 things can improve your code, your career, and your team, and is a refresher course on what goes into the day-to-day, reminding us to have some empathy for individuals new to our community.
39
SoftwareentwicklungSoftwareSoftwareentwicklerQuantenzustand
SoftwareentwicklerProzess <Informatik>MultiplikationsoperatorSoftwareentwicklungWellenpaketBenutzerbeteiligungLesen <Datenverarbeitung>BootenSoftwareentwicklert-TestComputeranimation
Endliche ModelltheorieBootenSoftwareentwicklungt-TestBesprechung/InterviewComputeranimation
Metropolitan area networkMereologieFormale Sprachet-TestKlasse <Mathematik>FrequenzProjektive EbeneSoftwareentwicklerRechter WinkelQuick-SortDemoszene <Programmierung>Geometrische FrustrationMusterspracheSoftwareentwicklungComputeranimation
MultiplikationsoperatorSoftwareSoftwareentwicklungIntelExogene VariableProzess <Informatik>SondierungSoftwareentwicklerComputeranimation
NP-hartes ProblemFlächentheorieNichtlinearer OperatorSoftwareFormale SpracheSchnelltasteNeuroinformatikKurvenanpassungVererbungshierarchieGraphProzess <Informatik>Rechter WinkelSchreiben <Datenverarbeitung>Vorlesung/Konferenz
KurvenanpassungGraphProzess <Informatik>Quick-SortRechter WinkelPerspektiveSchnittmengeDiagramm
SoftwareentwicklungSoftwareSurjektivitätGeometrische FrustrationElektronischer ProgrammführerMereologieMultiplikationsoperatorThreadSoftwareProzess <Informatik>DatenparallelitätDifferenteSchnittmengeRechter WinkelAlgebraisch abgeschlossener KörperSoftwareentwicklerErwartungswertHackerVorlesung/KonferenzComputeranimation
SoftwareCompilerKette <Mathematik>Bildgebendes VerfahrenMultiplikationsoperatorErwartungswertFamilie <Mathematik>HackerRechter WinkelMereologieSoftwareentwicklerComputeranimation
Prozess <Informatik>Ordnung <Mathematik>Güte der AnpassungMereologieMultiplikationsoperatorComputerspielRechter WinkelComputeranimation
NeuroinformatikSkriptspracheRechter WinkelAggregatzustandKonditionszahlAblaufverfolgungApplett-TestFehlermeldungComputeranimation
SoftwaretestCompilerTeilbarkeitFehlermeldungNeuroinformatikEinfache GenauigkeitRechter WinkelMereologieFunktion <Mathematik>MatrizenrechnungSprachsyntheseTotal <Mathematik>Computeranimation
DatenverarbeitungssystemGamecontrollerEuler-WinkelCodeE-MailSoftwareRechter WinkelMultiplikationsoperatorProgrammfehlerProzess <Informatik>Computeranimation
Quick-SortGenerator <Informatik>AnnulatorAdditionNeuroinformatikSoftwareZirkel <Instrument>GruppenoperationMomentenproblemRechter WinkelComputeranimation
AppletSkriptspracheDefaultPunktMAPChord <Kommunikationsprotokoll>Quick-SortMetropolitan area networkSkriptspracheFitnessfunktionAggregatzustandIdentitätsverwaltungMultiplikationsoperatorComputeranimation
Einfach zusammenhängender RaumVektorpotenzialServerDifferenteQuick-SortAkustikkopplerMultiplikationsoperatorLochkarteSpieltheorieInteraktives FernsehenProzess <Informatik>PerspektiveKorrelationsfunktionRechter WinkelKommandospracheDickeHierarchische StrukturDialektVirtuelle Maschine
VersionsverwaltungSoftwareentwicklungLokales MinimumSchreiben <Datenverarbeitung>Notebook-ComputerChirurgie <Mathematik>DruckverlaufBitTypentheorieSoftwareentwicklerAuswahlaxiomRechter WinkelCodeMomentenproblemQuick-SortNeuroinformatikeCosDynamisches SystemMathematikVersionsverwaltungSchwebungHackerComputeranimation
DigitaltechnikCodeMereologieCracker <Computerkriminalität>DifferenteGruppenoperationPhysikalisches SystemKonstanteTeilbarkeitDatenfeldKlasse <Mathematik>SoftwareComputeranimation
Prozess <Informatik>MinimalgradTrennschärfe <Statistik>BitSoftwareentwicklerRechter WinkelProzess <Informatik>Differente
MultiplikationsoperatorGradientFormation <Mathematik>E-Mail
GraphTropfenBereichsschätzungDialektFormale SpracheTreiber <Programm>RandwertFunktionalGradientBitProdukt <Mathematik>MultiplikationsoperatorComputeranimation
Softwareentwicklungt-TestHeegaard-ZerlegungSoftwareMathematikProzess <Informatik>BitSampler <Musikinstrument>InformatikRuhmasseMultiplikationsoperatorRechter WinkelComputeranimation
Rechter WinkelVertauschungsrelationAdditionGreen-FunktionEntscheidungstheorieKurvenanpassungWeb-DesignerMaßerweiterungWeb-ApplikationSoftwareentwicklerBitrateMathematikGraphVerzweigendes ProgrammLoopGüte der AnpassungInternetworkingRechenschieberSoftwareentwicklungOrdnung <Mathematik>Prozess <Informatik>BenutzerbeteiligungKonditionszahl
MultiplikationsoperatorAlgebraisch abgeschlossener KörperBlackboxQuellcodeGüte der AnpassungEinfach zusammenhängender RaumQuick-SortQuaderExpertensystemOrdnung <Mathematik>Prozess <Informatik>InternetworkingServerVerzweigendes ProgrammOrakel <Informatik>Rechter WinkelComputeranimation
Prozess <Informatik>Rechter WinkelSchnittmengeGeradeFokalpunktQuick-SortSoundverarbeitungMinimalgradComputerspielSprachsyntheseQuaderSoftwareentwicklungProzess <Informatik>Computeranimation
Bridge <Kommunikationstechnik>Shape <Informatik>GoogolLoopRechter WinkelComputeranimation
RandwertSoftwareZentralisatorSchreiben <Datenverarbeitung>Rechter WinkelKartesische KoordinatenPunktDatenstrukturSoftware EngineeringComputeranimation
Software EngineeringMereologieQuaderSoftwareMinkowski-MetrikMultiplikationsoperatorSpieltheorieUnternehmensarchitekturProgrammierumgebungEinsDatenparallelitätTypentheorieRelativitätstheorieHydrostatikStörungstheorieDialektDynamisches SystemMAPEinfügungsdämpfungIntegralGrundsätze ordnungsmäßiger DatenverarbeitungAlgebraisch abgeschlossener KörperComputerspielComputeranimation
Elektronische PublikationSoftwareentwicklungFormale Sprachet-TestAnnulatorSphäreComputervirusFormale SpracheTypentheorieInterpretiererBildschirmmaskeAuswahlaxiomExistenzsatzRichtungSoftwareentwicklungSoftwareStörungstheoriePrimzahlzwillingeRechter WinkelEinsMomentenproblemPhysikalisches SystemMultiplikationsoperatorAlgebraisch abgeschlossener KörperCodeSchreiben <Datenverarbeitung>Computeranimation
SkriptspracheLikelihood-FunktionProzess <Informatik>MultiplikationsoperatorMetropolitan area networkAbschattungFehlermeldungRechter WinkelGruppenoperationArithmetisches MittelEinfache GenauigkeitTabelleVersionsverwaltungHackerFormale SpracheMailing-Liste
SoftwareentwicklerDesign by ContractRechter WinkelGrundsätze ordnungsmäßiger DatenverarbeitungComputeranimation
Prozess <Informatik>Web logGüte der AnpassungGemeinsamer SpeicherHilfesystemTabelleRechter WinkelRückkopplungTwitter <Softwareplattform>Computeranimation
Bridge <Kommunikationstechnik>GruppenkeimBeobachtungsstudieWeb logWeb logRechter WinkelTwitter <Softwareplattform>Bridge <Kommunikationstechnik>Weg <Topologie>BeobachtungsstudieGruppenoperationKlasse <Mathematik>Algebraisch abgeschlossener KörperGraphOffice-PaketPunktGemeinsamer SpeicherMultiplikationsoperatorBereichsschätzungLesen <Datenverarbeitung>Computeranimation
RandwertTelekommunikationSoftwareentwicklungMereologieDatenmodellKlasse <Mathematik>Inhalt <Mathematik>MultiplikationsoperatorProzess <Informatik>SoftwareSprachsyntheseTelekommunikationNP-hartes Problem
Fortsetzung <Mathematik>WechselsprungRechter WinkelFaserbündelComputeranimation
Framework <Informatik>TexteditorFormale SprachePerfekte GruppeProtokoll <Datenverarbeitungssystem>ProgrammbibliothekRoboterComputeranimation
NP-hartes ProblemSummierbarkeitWeb logCodeSchreiben <Datenverarbeitung>MultiplikationsoperatorLesen <Datenverarbeitung>StellenringBitKorrelationsfunktion
KraftfahrzeugmechatronikerSoftwareentwicklerSoftwareGRASS <Programm>SpieltheorieRechenwerkEreignishorizontVideokonferenzMultiplikationsoperatorZahlenbereichProzess <Informatik>ComputeranimationTafelbild
Transkript: Englisch(automatisch erzeugt)
have ponies, so let's do it. My name is Kerry Miller. I'm a heavy metal software developer
for LivingSocial. I like to say I'm heavy metal software developer because my title is Lead Software Development Engineer. Which means I think very weighty thoughts and I can protect you from x-rays. Also, we're hiring. I think I have to say that contractually.
But before I was a lead engineer at LivingSocial, I was actually a teacher, Ada Developers Academy. Anybody besides these three or four people know about Ada Developers Academy? Okay, that's not a bad crowd. Okay. Ada Developers Academy, let me see if I can get this, is a 12-month
educational program for women who are transitioning into STEM, specifically with a six-month classroom training program educating them on Ruby and Rails and modern web development, followed by a six-month internship at a sponsoring company, which hopefully then turns into a job offer at the end of that time. Did I nail it? Anyone time that? Was that an elevator
pitch? Yes. Yeah. And the wonderful thing I love about this program is unlike other boot camp programs, we actually don't even charge, we don't charge the students. We actually charge the companies. And in fact, the cost is even less than zero because all the students receive a monthly stipend for as long as they're actually in the program.
So it kind of is a really, really interesting model. We just graduated 15, our first cohort, a few weeks ago, and we're starting a new cohort of 24 about two months ago, kind of asynchronously there. And so to them, you know, I'd like to say, hey, welcome.
Welcome. You are much loved. Does anybody not like ponies? Man, I'm sorry. Your day just got ruined. But seriously, welcome to the industry and welcome to RubyConf. One of the things I do love about the AIDA program, especially
is because we get to work with the students for such a long period of time, more than just like nine weeks, you know, in and out. You know, we really get to see people go from, you know, maybe a class or two in college, they worked on a side project once or did a rails bridge up to their fully fledged software developers. And part of that
is understanding what a career in software development looks like, right, and changing people's story from I'm a student or I'm learning to embracing and saying and defining themselves as a software developer and using that language to talk about themselves. And getting to see a lot of women sort of work through the same sorts of struggles
and confusions and frustrations. You know, I started to see a lot of patterns. And, you know, like a good scientist, I decided the best way to explore any sort of sociological phenomenon is to take a survey and do a questionnaire. And so I posted a little questionnaire about, hey, what should I tell these women who are in this program?
What do you wish you could go back in time in a metaphorical DeLorean and tell past you about software development? And I got over 150 responses, tons of great people and quotes, and some people were angry and typing out all the horrible things about their current job,
and some people were super happy. But there were a lot of common things. And so I picked five that kind of appealed to me, kind of resonated with my own experiences. And that's what I'm going to talk about today. So without further ado, let's get started.
So one thing we don't talk about in software very often is that this stuff is supposed to be hard. It is very, very difficult discipline. And there are shortcuts and metaphors that we use to try to wrap our brains around it, but we're not talking, it doesn't like learning another spoken language, right? When you learn another spoken language, you're trying to communicate
with another human. And you can assume that there's some commonality about the human experience, right, that we love and we're afraid and we're sad and we're angry and we're happy and we rejoice in some things and some things terrify us. But computers don't care, right? They're like, right? Computers are super dumb things that only do exactly what
we tell them to do. And so as we're learning to do that, the learning curve really comes into play and sort of understanding where we are. And so we have to think abstractly about what our process of learning is. And so has everybody kind of seen a learning curve graph like this? Yeah, like this is a super abstract way of thinking about learning
because when you're actually, I mean, we're standing off to the side and watching somebody else's path on the learning curve, right? But when you're actually on the learning curve, I mean, it feels so bloody horrible. You know, it's really a matter of perspective on like where we are. We can't really tell where on that curve we necessarily are.
And so when you're standing off to the side and you're watching someone struggle with something, you're like, you want to tell them just like, one more semicolon. Just add another semicolon and it'll all work, I promise. But you kind of, you have to hold back a little bit, you know. It's hard to convince people that you're right at the edge of the cliff, just one more pull and you're over the top. And it's hard for people
instinctually to understand that. And part of that is that some of the things that are really difficult about software that give you a hard time are things that other people seem to do just super easy. You know, I struggled for a long time to really understand concurrency when other people just seemed like, oh yeah, concurrency threads, forks, blah, blah, blah.
And that's just that, for me, that's something that I didn't get. It's not a deficiency in who I am or my abilities as a software developer, but it was really just, we had a different set of experiences that we were both bringing to that problem. And their experiences were enabling them to think differently about the problem than I was. And it made it easier for them. And conversely, there are things that
I'm really, really good at that other people just don't seem to get. And I have a hard time sometimes understanding like why somebody doesn't understand a piece of technology that I get very, you know, it makes a lot of sense to me. I'm really, I do a lot of work with asynchronous processes. That's really easy for me to grok. It's not everybody's cup of tea, though.
But this is sometimes a blocker, especially for people who are learning things. And even those of us who are experienced, when we're used to having easy successes, and all of a sudden, we've come across something that's really hard. I'm learning Clojure right now. Any other
Clojureistas? Clojureitis? I don't know. A couple of people who don't really want to admit to it at a Ruby conference. I understand. Well, the problem is, is that a lot of the times we have this like expectation about who we're supposed to be as hackers, you know? We're supposed to like jack in and hack the planet, right? Like, oh, I'm hacking the Gibson.
You know, and like we're supposed to all get this reference from a 1980s movie starring Angelina Jolie. So much fun. So much fun. If you ever want a completely horrible example of what it's like to be a software developer, to show your family, show them hackers, and say, yeah, that's me. That's me. So, I mean, and sometimes it's hard just to get
like hello world to print out sometimes in some things, right? You have to set the whole tool chain and compiler and then LVM and like, oh, there's a new Xcode out in the middle of it and it breaks everything. And that's just my world, though. So, you know, how can we possibly live up to this image that we have of what it means to be a hacker, right?
And we have to remember that, you know, if this stuff was easy, everyone would do it. Every single person in the world would jump at the chance to do what we do and quite frankly get paid what we get paid. And so just keep that in mind, that this stuff is supposed to be hard and part of the compensation that we get for it and the freedoms that we get through
employment through, you know, flexible time off or getting to go to conferences and getting two kinds of beer. Most people have to suffer through one kind of beer, you know. Come on. Come on. Don't get upset when you run out. So, most people who if you see them and everything is going really, really easy for them,
they're just really good at pretending. They're good at not getting frustrated, right? I like to say that most of the time we spend most of our time working in the darkness at the very edge of our experience because this is my life every single day. Does anyone recognize this?
Anyone not recognize this? I don't want to assume. I don't know who's in the room, right? So this is a stack trace from something that blew up on me. And whenever I see these come up, I feel like my computer is just like taunting me. It's just like, you suck. And you know what that makes me feel like? It makes me feel very sad, very, very sad.
You know, and I'll pour over it and I try to find the problem, right? And you find the problem and you're like, sweet, I fixed it. Reload. Same error. Wow. So I look some more and like, oh, I forgot that other semi-colon. Oh, JavaScript. And so you fix that, right? And it still
doesn't work. And then you go, oh, you pour over it and you find this like really subtle mistake, right? It's a super subtle like race condition that you hadn't considered. You fix that and it still gives you the error. And then you realize you didn't re-diva migrate.
That's my daily. That's probably yours too. So whenever I'm helping a student and like MRI like barfs up one of these stack traces, you know, like to them it's magic, right? That I can look at a stack trace and I'm like, oh yeah, it's such and such a thing, right? Or it's, you know, you missed a comma or something. But for them it's like looking at the frigging matrix,
right? It's just like. And sometimes I feel like that character in the matrix is like, yeah, I don't even see it anymore. Like that's a hamburger and that's, you know, I don't remember the quote. But so one of the things I always try to emphasize to people, right, is like do yourself a favor and like read the error. I'm actually working on a gem for people just in funsies to take the output of the error, that part that says like,
you know, could not do this thing. And just like have it pipe that to the text to speech on my Mac. So it actually like tells me exactly what the problem is instead of like, so I don't see this panic wall of text like flying at my face. Because an error like this is the computer's way of saying like, help, I need an adult over here. Please help me. Somebody bail me out
of this problem. And it's really important to remember that one of the things that we have to keep in mind is that we are the adult in this relationship, right. The computer is a dumb, totally logical child and all it does is exactly what we tell it.
It's the most obedient child ever. You know, if we tell it to subtract zero from zero, it will try to do it. If we try to divide something by zero, it will try to do it. But then it'll complain because it doesn't understand. It's not proactive enough to understand that we're asking it to do something completely illogical.
So don't feel helpless because you're going to feel like this every single day otherwise. Because you're going to write bad code, I guarantee. And it's not because you're dumb. It's not because you're not capable. It's not because you're not experienced. Even the most experienced people write bugs all day long. And that's why, you know, we all have
jobs, fixing and maintaining stuff. The thing is, what do you do when you've broken everything? What's the next step? And it's your reaction to that, that you really are, that's what you're in control of. You're not in control of the fact that you're going to make mistakes.
You're not in control of many, many things in this. But you are in control of how you address problems and what your attitude towards it is. And you can panic when you see the wall of text fly at you or the emails and the pagers start going off. Or you can say, hey, there's
a problem. You have to have faith. You have to have faith that everything we do here can be understood, that software was written by humans who thought this up, right? Computers just didn't fall out of the sky, right, and washed up on the shore, and then we're like, oh, computers. Right? We invented these. We humans. You know, people from the
previous generation and the generation before that, yes, some of them were very, very smart, but most of them weren't. Most of them were just as smart as you or I, and they came up with these things, and they worked with them, and so can we. We're all capable of this. What's really important is, in addition to having the faith that you can do that, is the courage to take the step towards doing that, right? That courage
is faith in action in many ways, right? So you have to be able to admit that sometimes I'm going to look dumb, and I'm going to ask dumb questions, and I'm going to look foolish, but that's just pride, you know? And other people, we don't see other people looking foolish or asking dumb questions, but they do. They do. We have to accept
that, that we're going to do it, that they're going to do it, and have that sort of humility and compassion for each other, if you'll pardon the touchy-feely for a moment. We have to have that sort of compassion for each other, that we're all just human, and that we're in this together. That's one. So you do you, which is kind
of a nice way of saying be yourself. But every conference I go to, including this one, at some point a speaker gets up on stage and makes an assumption about who Rubyists are and
what we like and what we do. And I'm pretty sure that none of these things are true for everybody in this room. Does anybody fit all of this? Who fits like three? Oh, well, okay, you like JavaScript. Man. Yeah, I'm three of the four. Anybody just two? A couple people?
See me afterwards, you get a prize. It's a key chord for your Emacs setup. So it's really important that you sort of question these assumptions. It's not just enough to sort of be yourself and be wacky and wear rainbows, right? You have to also sort
of look at the culture that you live in and the people that you surround yourselves with and the assumptions that you make about the tools that we all use and who we are, what our identities are. We waste a lot of time trying to figure out where we are in the hierarchy of other nerds. There's a lot of like, oh, yeah, well, I did the dial-up with the acoustic coupler and like, oh, I used to work on a punch card machine,
like all that kind of business. It's whatever. That's just people who are trying to figure each other out because they're human. And humans, we tend to be prone to hierarchical social interactions that way. And it's a waste of time, ultimately, because it doesn't matter. It doesn't matter. Things are moving forwards too fast to be worried about
what other people did in the past. It gives you a certain amount of perspective sometimes, but don't fall into that trap. Don't fall in that game and watch for yourself and like not pushing other people away by those games that you want to play to figure out where you are just be confident that you are where you are. Because there's absolutely zero connection between
your ability to quote Monty Python and your ability to set up a server. There is no correlation whatsoever between the length of your beard or the tightness of your pants to your ability to use Node. Actually, now that I think about it, love you, Node. Love you,
Node. But seriously, there really isn't any connection to your ability to fit into this community of people and your ability to do the work. And so respect those differences and respect people for the work that they do and celebrate those sorts of differences because they're
bringing vitality to our community. They're making us a much more interesting place and less of these assumptions about what the tools and the processes that we should be using. And they bring in the next potential person who's going to disrupt our community and the
community against DHH for, you know, huh, he says whoopsie all the time. Well, then that's kind of ridiculous. We wouldn't have had Rails. Anyway, walk your own path. Because it's really important that you are on a path and you're always going to be constantly moving.
Sandy Metz always says that, you know, you're never going to be, you're never going to know less than you do right now. I'm actually a little more pessimistic. I've always said like I'm never going to be. But basically, right, you make the best choice you can at the moment that you do with the resources and tools you have at hand. And so you have to sort of give other people that latitude that, you know what, like you don't understand why they wrote this crappy code
this way. But they did it for a reason, right. They made a conscious choice. Nobody sets out and says I'm going to write the worst code possible. Actually, well, you write Perl though. JK. What's that? Sorry, folks. Sorry, Confreaks. So ultimately, like be nice to others, but be nice
to yourself here, okay. Don't beat yourself up. If you don't know something, you're supposed to make mistakes. It always comes back to this. You're on a journey. So be nice to yourself. And
be nice to future you, right. Write code that's easy to understand, easy to change, all those good things that we're trying for. Make them happen for yourself. It's also really important to take care of your personal health. We have, like I said, this hacker ethos that we all drink Surge and eat Cheetahs and stay up until 2 a.m. And although that's a little bit ridiculous, and we all kind of know that, right, we still live
with that sort of stereotype from the larger culture that we work in. Sometimes not just the wide culture of our societies as we like walk around town and say, yeah, I'm a computer developer. But like the people we directly work with who don't do our work, accountants, business people, sales folks, they have certain assumptions about who we are based
on the larger cultural dynamic. And that can be a struggle sometimes. So you want to take care of yourself and your body and your mind and your heart. We do a lot of sitting around programming, and there's a lot of people making the change to standing desks for health. Go for walks. Do these sorts of things. You don't have to
buy an exercise bike and set up your laptop and be programming when you're on the exercise bike or anything like that. But just pay attention to the lifestyle habits that you're making and how they affect your body and your mind, your ability to do what is effectively very difficult mental work. For me, I have a lot of hobbies, as a lot of people here know,
everyone here knows me. I do glass work. I went to cooking school for a while. I was a professional poker player. I play poker like two or three nights a week. I like to work on Vespas, like vintage engines and things like that, just things that are physical and mechanical and are not computerized. They're not virtual. And this is actually a huge boon to me personally,
because I'm a very tactile learner, and I've learned that about myself over the years. So being able to take an engine apart and think critically about it and put it back together again has directly translated into how I look at code, because I can look at it like an engine or like an electrical circuit. And my understanding of how code gets refactored
feels to different parts of my brain the same way that glass feels as it melts and solidifies and cracks under different temperatures. And I wouldn't have that understanding, that very intuitive understanding, if I wasn't doing things that was engaging different parts of my entire limbic system, my brain and my heart, getting my hands involved
with things. And so I encourage people always to sort of like, go get a hobby, do something else. You know, meet new people that aren't also nerds who work on software so that you can like see how other groups and populations of people deal with their problems and their interpersonal struggles. You know, bring a lot back to the job, and that actually improves
your higher ability in the long run. Excuse me. So we've talked a lot about imposter syndrome the last year and a half. I feel like it's been like a constant refrain.
And everybody seems to feel this to some degree. I don't know if it's a little bit of selection bias for who talks about it, or selection bias like people who tend to be have a little bit more of imposter syndrome tend to gravitate towards software development. But everybody kind of feels this, right? And we don't really know what we're doing. But I love this quote. If you're hired for the job, you could do it, right? Like if you
struggle and you get through a rigorous interview process and they offer to pay you money, you can do this job, right? And if you can't, well, take the money, right? Like don't worry
about it. Don't doubt yourself. It's easy to say like, oh, don't doubt yourself. You're really good. But really, if you have done this professionally, you can do the job. It's that simple, for better or worse. So being yourself looks really different sometimes, because it's tough
to stand out in a crowd. I know a lot about standing out in a crowd. And I didn't like that for a long time. I used to wear a lot of black. And I would tell people, oh, yeah, I wear blacks and grays because I used to be a stagehand. And I go to the Merc and like listen to sad
music and blah, blah, blah. But that wasn't true. No, I really didn't want to stand out. I'm six feet tall and I'm a little chubby. And, you know, I kind of stand out. I didn't like that. And I started wearing rainbow bandanas. And then people were like, hey,
you seem like a fun person because you wear rainbow bandanas. That's pretty cool. So I was like, you know, I'm going to stand out. I'm going to stand out. I'm going to be fun because I really like talking to people. I really like people. So I embraced that because, you know, haters are going to hate, right? You can't, you've got to deal with it. So you're going to encounter people that are like, oh, you don't know what the RFC 1103
for email is? Ugh. You know, people, come on. Come on. Don't worry about that stuff. You do what you have to do and keep pushing forward. Let the haters hate.
There's no magic whatsoever to what we do. Not a drop of it. It seems like magic. But there's none whatsoever. Has anyone seen this kind of graph before? I first encountered this in like seventh grade IFL, Introduction to Foreign Language.
Someone was trying to explain to me why I couldn't learn French and Spanish at the same time. I was very ambitious. I still am. We started out with unconscious incompetence where we just simply don't know what we don't know. We know nothing. And then we move, we become more conscious of what we don't know because we start learning things. We realize there's this huge,
huge world out there that we don't know. And then as we gain more competence, we're still aware of what we know. But we start to identify these big regions of things. And we're aware now of what we don't know very clearly. And we understand where those boundaries are. And then finally, we finally move into this unconscious competence, this idea that
if your driver is a common example, where you can drive for hours and not even realize you're driving because you're just doing it subconsciously almost. You're so competent that your brain, you don't have to use the higher functions to be aware of what you're doing. And software is a little bit like that sometimes. But it's not really in a lot of ways.
How many people are math majors? I always like to do this. Like, how many math majors, people who did math, like a minor, anything like that? What about comp sci? CS degrees? Everybody else doesn't have a CS degree? Okay. That's about the normal split. Like,
Ruby is a weird community, right? It's about 50-50. People who came through math or computer science and everyone else is like artists and crazy hippies and a few musicians. And that's so cool. That's so cool, right? But we don't do a really good job about having different ways of explaining how software is. We don't teach it very, very well.
So I'd like to give you an example of what would happen if we taught math the same way we teach software. Let's imagine we have a pony. Everyone agree this is one pony? Now I give you another pony. We now have two ponies. One pony equals two ponies. One plus one
equals two. Does everyone agree that it's a true fact? Great. We'll do this exercise for homework. This is just a simple extension of what we've already done, folks.
We don't teach math this way, but pick up a programming book, man. It's like, here's how you do Hello World. Here's how you do a loop. Here's an if-else conditional. Go make Rails. Have you ever seen this chart, the Rails competency chart? This is amazing. It's so big. I can't even fit it on this slide so you can read it.
Everything on the left side is the stuff, the generic stuff you quote-unquote have to know as a web developer or someone who's writing web applications, and everything on the right is all the competencies you need to be a Rails developer in addition to the stuff on the left, right? This is an amazing,
amazing, insane amount of stuff to know. So if you only know a quarter of this, where are you on that original chart? Do you have conscious competence? Conscious uncompetence? Like, where are you on the learning curve of being a Rails developer? Is anybody 10 out of 10 on all these things? How do you rate yourself?
Because I'll guarantee you, there are huge chunks of this graph I don't know, I really am not very good with, like JavaScript. But you know what the coolest thing is? You do not have to learn it all at once. You don't have to do it. You don't have to know every single
one of those branches in order to do a passable to good job at things because the entire internet is at our disposal to answer questions, and we have a community of people that we can reach out to. Your job is to learn one thing on your first day and then learn a second thing and
then a third thing and see the connections between those three things and then go on and learn a fourth thing, right? Nobody just sits down and reads a book and is an expert at all of this stuff. It takes time, so give yourself the time to understand and learn this stuff because it's all just code. There's no magic. There is nowhere where there is a black box where wires
go in and wires come out and no one has ever looked in the box because it's magic. Oracle servers aside, there really is no magic, right? We can like look at the source code or we can look at the APIs and it can all be reasoned about and understood and it feels like hell. It feels like climbing that cliff some days. Hello, closure docs, but you can do it.
I swear to God, you can do it. I did it and who am I? You know, I'm not special. I'm no more special than anyone else in this room. So the underlying theme of all this sort of stuff,
right, is that you need to learn how to learn. And the interesting thing about how we teach in America is we have a set of finish lines, right? We focus on graduation. You graduate from sixth grade, which really isn't a graduation. I mean, come on, right? So now you go into junior high and that's a couple years and you graduate. You get another diploma. That's not
really graduating, right? So now you go into high school and you graduate and it's so amazing, right? And there's valedictorian speeches and homecoming games, but that's not the finish line either. So then you go into school or college. That's not it. Master's degree programs, right? There is no finish line. Education is a process. It is not
a destination. And especially with the amount of stuff that you could learn and the amount of stuff that you can learn, education is an ongoing thing throughout your entire life. One of Leonardo da Vinci, towards the end of his life, wrote down something to the effect of I am upset about dying because there's so much left to learn.
You can't know it all and so you have to pace yourself and understand how you learn and what your approach should be, what your relationship with discovery is. So imagine this is Ruby. This is everything you can ever learn about Ruby contained in this box, right? Will everyone agree
that that is in fact everything you could learn about Ruby? So you learn one thing, right? You learn one thing. That's your first day. Maybe you went to a rails bridge or you you read the first chapter of learn Ruby the hard way. You learn one thing.
And then you learn a few more things, right? Because you're googling for how to do a loop and you come over and you go, oh, innumerable. I saw a great talk at RubyConf 2014 about how to do innumerable, that hurdle guy. And you start to see how these things relate to each other, right? They start to describe a shape. And so that shape is knowledge and wisdom.
It's going to get put together. And you can start to define the centrality of your knowledge, right? So things get pushed further, these boundaries get pushed further and further back to the darker corners of the thing you're trying to learn. And the interesting thing with software, right? Software works together with other pieces of software. That's where
really interesting stuff starts to happen, right? So if we're like a rails application, right? Like you start to learn things and there's some overlap between these. So now think about these. These are data points within a larger conceptual structure of software engineering, all those things you could learn. And so you're always going
to be pushing back against what the edge of what you know is, against that darkness, and making less and less darkness and more and more light as you learn things. Because we have no idea what the next thing we're going to have to learn is, or what its relationship is. But it's going to be outside of this box by definition.
And so you need to be comfortable with working outside of the box of what you already know in those dark spaces. Things changing all the time. Two years ago, RubyConf Denver, when I gave one of my first conference talks, everybody was talking about how do we get Ruby
into the enterprise environment? People were still talking about that. I haven't seen a talk like that this year. No one's talking about that anymore because we did it, right? We figured that thing out. But now we're talking about Ember and how do we do concurrency and static versus dynamic typing and should we use closure? Is Elixir the next hot thing? We're talking about
new things. And so being able to learn, learning how to learn, how to acquire knowledge and really understand things quickly and integrate it and see where it falls on that map in relation to the other things that you know so you can define regions of knowledge is a critical skill to acquire. And you can do it. I mean, you've done it. You're alive. Everyone here alive?
Yeah, you're actually a pretty responsive audience. I really appreciate that. You're alive. You can acquire knowledge, right? You can learn. You are not fixed in stone forever. And so I actually want to show you all something that I got really excited about last
night. And I went on IRC and I was just like, oh my God, this is the best thing ever. This exists. For those in the back who can't read it, this is friendship is magic plus plus. It is an imperative dynamically typed interpretive language that takes the form of the pony of your choice writing a letter to Princess Celestia.
I wrote hello world in it last night. This is a program. This runs. Who wants to write code like this? Okay, I got two, three people. All right, that's good. Look, I get it. Okay,
friendship is magic plus plus is not going to be the hot new language, right? We're not going to write some like accounting software system in this. But what are we going to write it in? Yeah, I thought so. Nobody wants to tell me, right? Like I feel exceptionally lucky,
right? Like I learned Ruby. I won the jackpot lottery, right? Like this is an awesome language with awesome people and I get to have fun and like, you know, hang out with you and wear whatever I want. This is super cool. But we just got lucky, some of us. And so you have to kind of keep looking for your career to always be looking to acquire new skills
because you never know what direction things are going to go. I'm learning closure at work. I'm also playing around with rust when no one's looking because I don't know what the next thing is going to be, but it's not always going to be Ruby. And I hate that. I hate that this is an ephemeral moment in time, the awesomeness of Ruby. But
if we're all awesome, we can then go to the next language and bring that awesomeness with us. Like that's super cool. I like that. So let's do that. But I don't know where we're going. So I don't know. This is kind of a let's all go there together, but you all lead.
And I guarantee you, unfortunately, that no matter who you are and no matter what you're struggling with, the likelihood that you are the first person to ever struggle with that, to ever cry and swear and bleed and flip a table, that's probably not true. You are almost never the first person. Every single time I hear about a cool new idea,
like on Hacker News or something, like the very next post is like, oh, Dykstra wrote about that in 73. But that seriously happens all the time. Like every cool new language that comes along, someone says, oh, yeah, they tried that in 78, or oh, there's a list version of that somewhere. We're all kind of like standing on the
shoulders of giants. And we also stand in their shadow. The work that other people have done have got us to where we are today. And it's our job now to step forward and lift the next group of people up. But we also stand in the shadow of those giants that they cast. They cast very long shadows because they did some really revolutionary stuff. That doesn't mean
that we can't do revolutionary stuff. We have to understand what their influences are and where it comes from. Because we're not alone in this. For every single person who's tried to get JavaScript to work in IE6, man, I couldn't find a screenshot. I couldn't bear to put a screenshot of that error in this talk, and I'm sorry. I really wish I had now. But you are not the first person to struggle
with that horrible, horrible thing. So take some strength from that. So I hate to break it to you, but no matter who you are, there's someone out there who's
exactly like you, almost exactly like you. They might not look like you, but they probably think like you and struggle with the same things and have the same hopes and dreams and aspirations. And I can say this because I worked for five years on the Amazon personalization team, looking at what you people buy, and you're all horrible people. I think I can
say that. I'm no longer under contract. So it's kind of horrible, right? We all want to be special snowflakes, but oh my God, it's so great. It's so great because I can go find those people who have struggled with these same things and find out how they solve it, right? And talk to them about what I struggle with and what I rejoice in. And so it's really important that we build communities around ourselves to be successful
as developers, right? We're not supposed to be sitting up in our addicts programming all night. Go to meetups and things. Everyone says go find a mentor, and I'm saying it again too, but you should find more than a mentor. You should find coaches. You should
find people that give you good feedback, that are able to give you advice about your career. Is this a good job offer? Are they paying me enough? Should I take this job? What should I be learning that I don't already know? What should I be working on so that I'll be employable next year? How can I help you? You want to bring something to that table, not just take
things away. And so building these communities I think is awesome. I think Ruby is an amazing thing that we've all done, you know? Like I could say that's the front of this crowd, right? We all agree, right? Ruby's pretty good. It's not bad. It's not bad. It's not bad. But where would we be without conferences and meetups and blog posts and Twitter,
right? Ruby would not be where it is today. So be involved. Go share the learning. I love teaching, and I think teaching, if you're at all good at it at all, you know you're kind of bad at it. It's an amazing way to solidify what you know.
Really interesting things happen in our brain when we teach, and I'd love to talk to other people about it. I won't take up any time without doing entire talks about what happens when we're teaching. But it supercharges our ability to retain knowledge. So go teach a class, go volunteer, go to Railsbridge or Rails Girls. Closure Bridge is really cool.
Start a study group or a book club at your office. Like if you've always wanted to read SICP but you never could bear to do it, find somebody else at your office who wants to do it. Go online. Just say on Twitter, like, hey, I want to read Sandy Metz's book, but I don't want to do it alone. Who's with me? And then just do a Google Hangout every week or two and talk about it. Book clubs don't have to be just for Oprah.
And this is why we tell people write a blog post or do lightning talks, right? Because it's like, once you're involved in the community, it gives you so much more confidence and your ability to feel good about the strides you're making. You're able to start to track where you are in that graph of confidence and confidence.
So who here is going to sign up for a lightning talk? A bunch of people. If you want to do, if you didn't raise your hand and you want to do a lightning talk, come see me and I will help you. I will do anything. I will help vet your idea. I will help you with Keynote. I will let you borrow my cool thing. Look at this. Look.
Super cool. It's got fresh batteries. Totally cool. I will totally help you do a lightning talk. If you want to do a blog post, I will help. I will edit your blog post, right? And this is a standing offer for anybody forever. I'm there to help you. Just come see me. I'm pretty easy to find.
Pay attention to people around you and how you communicate with them. Communication skills are super key. I've told a lot of people, like, go take a relationship skills class. Like, we're just like, why would I want to learn how to date? Like, why is that important to my job? But it's not about that. It's about understanding other people and listening to their needs and desires and whatever.
But, I mean, as far as the pitch goes, but the actual content of it is understanding that other people have fears and hopes and dreams and goals and desires and things that they want to do. What do they want to accomplish, right? And taking a class on that is super great because we're making it up all the time. And learning to understand other people
and how they're making it up at the same time, like, that's gold. So speaking of things being hard, you know there's hard problems in software, right? There's two hard problems. One of them happened to me. But seriously,
this is actually a really, really critical thing that I wish someone had come to me, maybe myself and a DeLorean and said, get started. Don't wait.
I fretted. I love telling this story. I fretted for about a year and a half and didn't get into Ruby because I couldn't get the MySQL gem to install correctly. Really? Really? Has anybody else done that? You ever, like, done something like that where you just put it off and you put it off because of something stupid and trivial like that?
Yeah, a lot of people have. It's important to get started and just get in there and do things, right? It doesn't matter if it's silly and ridiculous. The act of doing makes you right, which is one of the tenets of the DUN Manifesto, which is came up with by Brie Pettis, who's the
CEO of MakerBot that make the cool 3D printers, and his partner Keo Stark, who wrote an awesome book called Don't Go Back to School. These are just three of the things that are on the DUN Manifesto, but it's this idea of if you sit and fret all day long about being perfect, you're never going to start. And you can never be perfect, so why worry about being perfect?
Don't worry about the perfect framework. Don't worry about the perfect transport protocol, the perfect language, the perfect editor. Those are refinements. It's only through the act of doing that you become correct. Worrying and not getting started doesn't get you any closer to being done. Okay, so that was a lot. There's a lot of ponies. There's a lot of things, so I'm
going to just kind of sum up here because you really shouldn't be afraid of things that scare you. The five things that I wish that I knew, that this is supposed to be hard. There's a reason we're well compensated for it. There's a reason why we're all a little
bit crazy. It's hard. We're not unusual because we find it hard. Be yourself. You do you. Whatever it is, don't worry about other people's perceptions about your skills and abilities, and so much as it means a thing, your ability to fit in is zero correlation to your ability to do this job. There's absolutely no magic in what we do.
It is all just code that we can think about, that we can reason about, that we can write blog posts about, and someone could explain to us we're very capable, intelligent apes using tools made by other apes. Learn how to learn. Take some time to understand how you
approach new things and what your reactions are and how you take them in and retain them best. Find your communities, and if you can't find that community, build that community. There's a guy up in Chilliwack, BC who didn't want to drive the two hours
every week to Vancouver, BC to go to their local Ruby meetup, so he started his own. Does anybody know about Chilliwack, BC? A couple of people from Seattle, I think. Yeah, it's a nothing little town. It's like 5,000 people, but he found one other person who did Ruby, and they get together every week at a local community center, and they do Ruby,
and those two people became three, became four, and they've got, I think, like six or eight people. He built his own community, and I think that's an awesome story. And finally, number six, go and get started. Go today. When you leave here and you go home, if you're not excited to do this thing, get excited to do it because this is an awesome job,
and we deserve it because we're putting in the time and the effort and making this happen. Go do it. Thank you.