Recomendados
Mais conteúdo relacionado
Semelhante a Becoming better a two year journey
Semelhante a Becoming better a two year journey (17)
Último
Último (20)
Becoming better a two year journey
- 1. Becoming better... A look back at the last two years.
- 4. © Lucasfilm
- 5. return;
- 10. © Scott Adams
- 13. © Lucasfilm
- 15. • www.becomingbetter.co.uk • @welshboy2008 • egwilliams2002@googlemail.com
- 16. Image Credits • Silde 2 – © Melissa Brandts : http://intelligenttravel.nationalgeographic.com/2009/08/12/ground_squirrel_photo_crasher/ • Slide 3- The Matrix: https://gdblogs.shu.ac.uk/b1022831/2013/11/18/the-matrix-images/ • Slide 4 – Star Wars - Darth Vader © Lucasfilm : www.techhive.com/article/215415/Darth_Vader_to_make_CES_announcement.html • Slide 6 – The A-Team: http://iqtell.com/2014/05/10-reasons-why-the-a-team-is-better-than-your-team/ • Slide 7 – The ACC Library: http://acclibraries.tumblr.com/ • Slide 8 – The Thinking Man: http://deacondance.com/understanding-discernment/thinking-man-rodin/ • Slide 9- I have no idea what I’m doing: http://knowyourmeme.com/memes/i-have-no-idea-what-im-doing • Slide 10 – Dilbert © Scott Adams : http://funnysalescartoons.com/photo/dilbert-as-a-sales-engineer-on?context=latest • Slide 11 – © Randall Smith : http://randalldsmith.com/god-on-the-move-the-long-and-winding-road-acts-23/#prettyPhoto/0/ • Slide 12 – The Big Bang Theory – © Warner Brothers : http://www.sickchirpse.com/the-big-bang-theory-sucks/ • Slide 13 – Star Wars Attack of the Clones – © Lucasfilm : http://goo.gl/WnQ1nI • Slide 14 – Robin Wililams : http://informazioneconsapevole.blogspot.co.uk/2015/04/robin-williams-nel-testamento-ha.html
Notas do Editor
- Background… So a little bit about me, I’ve been a software developer for the last six years, three of which I’ve been coding in C++, before that I developed in Java mainly, but always wanted to do C++ because it was considered a “real” language. I’ve dabbled in many other languages over the years as well, such as Basic, C#, Java, Python, Bash, php, Javascript making use of Jquery. So this journey began in April 2012 when Pete Goodliffe gave a talk on becoming a better programmer, and he had a panel of experts with him who each gave their opinions on how to become a better programmer. At the time it was something that I’d been thinking about for a while, but Pete’s talk gave it some substance and a framework around which my own ideas began to form. And so two years on, here I am.
- Realise where you are now, and where you want to get to… Pete spoke about the models of competency during that talk, and one of the first things I did was take a good long hard look at myself and work out where I was on the ladder, and I think it’s fair to say I was fairly low on the ladder, so had to start from there. I have the privilege of working with some very bright programmers, who’ve worked at the company I work for quite a long time. And for a time I made the mistake of trying to compare myself to them, but there were a couple of issues with that approach. Firstly, they’d been doing this gig a lot longer than I have, so of course they knew more than me. That’s not exactly a surprise, there would be something very wrong if that wasn’t the case. Secondly, they’d put in countless hours in to get that experience. How could I hope to compare to them? Especially as I’d only been coding in C++ for four weeks at that point?!? Thankfully, I learned from my mistake, but it’s an easy trap to fall in to isn’t it. I had to build that experience up, and like it or not, that takes time. How much would we love it to be like the Matrix, where you jack something in to the back of your head and everything is uploaded instantly. But it’s not like that, it takes effort and strain and training to get to that stage.
- Give yourself a break… The other thing I had to untangle from my psyche is that it’s OK to fail. Now, I’m sure Darth Vader needs no introduction, he’s one of the most iconic bad guys in film today, and the price of failure when working for him was pretty high, in fact, terminal. Just watch him go through the original trilogy, and he was busy choking people, indeed it’s one of the first things he’s seen doing in the first film! So in the Empire, failure was never an option! But that’s not the case in software. Unless you’re working on very niche products in very niche fields, then failure is always an option. ESPECIALLY when you’re starting out and learning how to be a better programmer. And if I asked you guys how you felt when you made a mistake or something failed, how would you answer that? I know full well how I answered it, I was embarrassed, I felt like an idiot. Felt like an imposter, how many of us feel like that? Let’s face it, we’re all going to make mistakes. And a word here for any team leaders, or scrum masters. Factor in some slip for new developers. They need that slack, trust me. I totally agree that the slippage can’t continue indefinately, but if you start reducing the slip factor as the developer gets more experience they will thank you for it. Trust me.
- For example. On a software system I used to work on, there was this chap who was a developer, and he’d been assigned to fix some code that was seg-faulting when certain things happened. Let’s call him George… Now, he went through the code, and drilled down to where he thought the seg-fault was being caused. And he popped in what you see on the slide. Now what do you suppose he did next? Did he remove that return, and move it a line down so as to find the EXACT line that was causing the issue? Nope. Did he run the system through GDB and generated those events so that this function would be called? Sadly not. What he did do, was check it in as it was, with the return where it was, and then he pushed it in to the branch. Now, he didn’t do this deliberately, but it did cause much mirth amongst the team. So mistakes can happen!
- Have a Plan We all know who these guys are right? And we know what Hannibal’s favourite phrase was? “There’s a plan in everything, and I love it when a plan comes together.” Before you start any sort of journey, you make a plan right? I’m willing to bet that the delegates who flew over from various countries had to plan their flights, in some cases book their holidays, taxis, trains and hotel rooms in order to come to the conference. Why shouldn’t our careers and our learning not be subjected to the same sort planning? I learned that I needed to have a SPECIFIC plan to get to where I wanted to be. If it’s a general statement, then it’s not really a plan, you need something that’s solid, and more importantly, achievable, tangible and possible. Without these factors, it won’t motivate you to keep going when the times are tough. So becoming better, is a great general headline statement, but becoming better at what? Being a programmer, that’s a bit more specific, but that covers a very broad range of things, so we need to be more specific still. So I decided that I want to be a better C++ programmer, knowing more about the core of the language and be able to hold a technical discourse with a C++ expert and be able to keep up with what they’re saying. Sounds cheesy, but it’s certainly kept me going. (Show bullet journal at this point) I’ve planned my reading for the rest of this year, I have an ambitious (some say) target of read four technical books and four discipline books over the next year. I’ve jotted them down and committed to doing this. So next year you can ask me if I’ve read any of them. (I’ll pop them on the blog after this)
- Learn Wisely. Like Pete Goodliffe said in his keynote, predicting the future is hard! In fact it’s damn near impossible. Granted, you can make some educated guesses, having chatted to Pete last night over a curry you can also up to a point observe trends and have a good idea of what COULD be coming next. So what are you going to learn? For me, it was relatively easy as I knew that I wanted to learn C++, but C++ is a vast language. I was chatting with Bjarne Stroustrup when he was here in 2013 and he commented that even HE didn’t know every facet and corner of C++, and I’m willing to bet if you asked Jon Wakely, I can imagine he’d give the same answer. So we have to be selective about what we learn. We should know the core features of our chosen language, I think that goes without saying, however the other bits and bobs, which ones do we allow to have a surface knowledge of? And which ones do we do a deep dive with? It’s an important question to ask. Also factor in the time to learn! This is critical! I’ve taken to blocking hours in my calendar out for learning and reading. It’s generally frowned upon on my team sadly, as some individuals seem to think that if there isn’t smoke bellowing out of your keyboard like Les Dawson, then you’re not working hard enough. And frankly, you’ve got to ignore them! You’re already ahead of them in the game, because you’re making the effort to keep abreast of current technology and techniques. So you mustn’t let them put you down! The biggest problem with technology is that there is such a vast sphere of topics to choose from! How do you possibly make a wise choice? Sadly, I’m not sure, I’ve not worked this out yet myself. I’m learning what I need right now, oh sure I’m reading blogs and stuff, but even then it’s very tricky as if you’re anything like me, I want to do all of it!! And there isn’t enough time in the day for us to do that. Sadly.
- I also had to learn what the best way was for me to learn? For some it’s reading a book, some it’s just playing and doing. For some it’s watching Videos on Pluralsight or Udemy. There’s a brilliant book on this called Pragmatic Thinking and Learning which is written by Andy Hunt. It’s well worth a read, and it helps you to understand how the brain works, and it may lead you to work out the learning “language” that suits you best. For me, I learned that I enjoy pair coding, and working with another developer as they write code, and I get the chance to observe and ask questions. It would seem that I’m a people person. Now don’t get me wrong, I still read books as well, but I do like learning with other people writing code. Yet paradoxically, when I’m actually writing production code, then I prefer to be left to it. I like to have peace and quite when I code, so I have a set of noise cancelling headphones when I’m coding, and in our office we have rubber ducks we place on our monitors to display that we’re busy, and don’t wish to be disturbed.
- It’s ok to say that you don’t know. In fact, it’s often the first step to becoming a better developer. I had to learn that it was perfectly OK to say “I don’t know.” I was giving a presentation a few months back to a software team that we partner with on why we should move to C++ 11, and it was going well. But I feared the question that I couldn’t answer. It was there lurking in the bushes. And of course it duly turned up, and I admitted to the whole room that I wasn’t sure about the answer to that, and I wasn’t going to try and blag it. So I promised to off and look it up and send them an e-mail with some notes on the questions asked. And I found that they appreciated that! It’s unprofessional in the extreme to try and bullshit people, ESPECIALLY when there’s other techies in the room! Because as sure as eggs are eggs, they’ll call you on it. For instance if I was giving a talk on the gcc compiler, and said something that was wrong, I’d fully expect Jon Wakely to correct me! Now, there IS a distinction to draw here. If you say something wrong out of innocence and ignorance, and you honestly believed you were correct and it came across in the right way, then the response would be positive. You will be given a mild and polite correction. And the end result is, you’ll be better informed (be sure to thank the person for correcting you too!! Very Important!!) But if you try and bullshit your way through, then I reckon the response wouldn’t be quite so polite…. For example….
- Sales, can spout a load of crap as long as they wish. They can promise the customer anything they like! They don’t have to deliver, they’ve got the sale so their job is done. But as a techie, talking to other techies? You try and blag it with an expert in the room? It certainly keeps me honest. And it’s something we should strive to be.
- It’s ok to take your time! It’s a marathon, not a sprint. Pete mentioned in his keynote about it taking 10,000 hours of deliberate practice to be excellent at something! (Look this up) And that is a lot of time! I found myself reading much more than I’ve ever done before. I’ve also found myself becoming a mentor, which brings it’s own unique challenges. So my mentee asked me to explain Stack Unwinding by our next meeting! So that’s something I’m looking up at the moment for her. And I’ll tell you what, it’s great being a mentor. I e-mailed someone who does mentoring, and is rather well known for it and he advised that as a mentor, I’ll learn a great deal in doing the mentoring as well! And that’s certainly the case. I’m finding my self diving in to the depths of the language to get the answers that my mentee is asking me, and as a consequence, I’m becoming a better programmer, by teaching someone else what I know! It’s a win-win in my book. So get out there, help school kids, do mentoring. Sure it’s scary, and it takes time and energy, but the benefits for yourself are awesome!
- Theory is one thing… The thing is though, we can talk about the theory until the cows come home! And I know, I’ve done it. For about a year, I talked a good game. Then I attended Pete’s talk in 2012, and it shook me out of it. I was making the right noises about wanting to be a better programmer, but I felt that Pete’s talk called my bluff, and gave me the kick up the backend I needed to get on with it! You can read all the programming books in the world, but until you put finger to keyboard, then it’s just stuff in your head. I’ve got to exercise just like I exercise my body…(sort of….) That’s why I use the cyber-dojo, because it means I don’t have to fire up an IDE and I can write some code quickly, and have a play and some fun with it. And it’s what I plan to use with my mentee.
- Surround yourself with great people. Trust me it helps! I wonder how many have you been inspired by the various talks, and just doing community this week? If you surround yourself with good people, then it’ll make the job a lot easier, and it will inspire you to become better as well. However if you are surrounded by people who don’t give a crap, then that makes it 10 times harder. If you find yourself in that situation, then I’d recommend either instigating the change, and hope that others follow. If that doesn’t happen, and it does, then consider leaving the team. I’ve just done that, I’m currently on a team where folk don’t care, and sadly I’ve got to move on.
- Robin Williams said “You were only given a spark of madness, you mustn’t lose it” It’s vitally important to good off and take a break from time to time. I can’t do serious all the time, as the inner comedian (who isn’t that good…) keeps trying to get out, so you need to fins a fun way to blow off some steam!!
- Feel free to get in touch