Tag: Programming

  • Career Planning

    Barney had the distinct feeling that his career as "the girl's best friend" was over before it had really begun. He sincerely hoped that the girl's mum would continue to look after him.
    Credit: flickr / David Blackwell

    The other week I had a phone interview for what I thought was my dream job. In the days before, I realized that was the kind of thing I’d been doing. And then, I waited.

    Meanwhile, work was going so-so. My computer broke – again – so I lost a day and a half on my Most Important Task (nothing remains of my original machine) plus the time it took me to reinstall everything I needed, and the MBA and I had an argument.

    Aside from the awesome technical support, something that’s really amazing about Extreme Blue is how much support we get. So the organizers of the program sat us down for what became a 3-hour angsting session, explaining that our group had been put together knowing that we would end up in this place, and discussing personality quadrants.

    My dominant quadrant is definitely my logic quadrant, so that conversation formed into an equation that frankly made my head explode. However, I tend to communicate from my relational quadrant – and as our MBA is detail-process oriented, with nothing in the relational… this had been causing problems. I thought he was being really rude and disrespectful, and I guess I just didn’t make any sense at all to him.

    By Sunday, I had an equation that worked – our MBA is on the spectrum (you can take an online test to discover where you lie). And of course, as a compsci, I know and have known a lot of people who are. And so I know how to deal with it – in fact, I can’t believe I didn’t realize sooner but I guess I saw him as an MBA rather than a techie – so this week we’ve been getting on fine. I’m consciously communicating from my logic quadrant, and I’m now seeing that my input is considered, and also I’m getting the information I need out of him. He is also making a real effort to take constructive criticism.

    The point of this histoire, is over the last week I’ve been having more and more of a hankering to code. And my other takeaway from this conversation on Friday, was a worry that I wasn’t seen as technical.

    So when the results of the phone interview came back and I’m wasn’t through to the next round, I was disappointed. Especially because the woman who interviewed me had really strongly given the impression that she couldn’t be bothered with the whole thing. But I talked to my friend Dig, who was great, and I moved on to the next phase of what I’m doing at work – where I finally get to code – and ran into a roadblock so I got no further than a “hello world” test to verify my IDE was working.

    So frustrating. But – it has made me glad I didn’t go further with this non-technical role – in fact, almost grateful to this woman. This job was probably the only non-coding job I would have applied for, or taken. And I applied because I think it’s a route to where I will end up – but what I’m realizing is, I don’t have to go there now.

    In fact, I’m not ready to.

    I have an on-site interview for an awesome software engineer job in July. And when I spoke to the EB guy (in fact, the one from Friday’s meeting) about who I should list on my resume he started a conversation about whether I wanted to progress to a proper job with IBM. And so I told him I’d spoken with one of my personal mentors (Sacha is amazingly helpful and supportive) and she’d given me some resources, so I was working on that too, but that I wanted something more technical than what I was currently doing. And he committed to helping me find the kind of opportunity that I want.

    Wow. I don’t know what will happen next, but I have to tell you – right now I feel really lucky.

  • Processing Workshop

    Pretty Web

    I’ve been a little quieter than usual for a number of reasons, one of which is that I’ve been working on a workshop for the University. It’s aimed at getting 17-18 year olds interested in taking Computer Science, and I’m using Processing for that.

    I’m experimenting with what I’m calling an Activity Based Curriculum. I.e. rather than deciding to teach a concept like types, or conditional logic, or loops, I work with an example of something that you might actually want to do, and the concept is a side-effect. As I’m using Processing, it’s completely visual. The workshop is just 3 hours long, so I’m aiming to send the students away with an understanding of why it’s cool to be able to program, rather than with the basics of doing so.

    As part of my contract, I specified that the course content be licensed under Creative Commons and the code will be released under GPL.

    If you’re interested, you can find it here. As ever – let me know what you think.

  • What Makes a Programmer Great?

    This is a post I co-wrote with Douglas Gresham. Douglas is a software engineer at Google, who blogs at www.douglasgresham.co.uk (less often than he should, go bug him for updates).

    Credit: flickr / stevehdc

    I’m a graduate student, though I firmly believe that great programmers are not the result of university courses in programming. But university courses take us in, with no idea of what we’re doing and eventually spit us out, mediocre or – hopefully – competent, programmers. And then we’ll go out into the world, where we really master our art. Hopefully.

    Going in to university knowing a little bit of C, I came out knowing a moderate amount of Java, some Python, some Haskell, some more C, a little of ML, Prolog and javascript, and very little (though more than I think anyone should have to know) of Tcl. Coming out of grad school, I think I’m a better programmer. Not because I’ve learnt more languages, or because anyone’s sat me down and taught me anything new, although reading Effective Java definitely helped, but because I’m more confident.

    For some reason, I’ve ended up doing a lot of teaching over the past 4 years or so. And I’ve come to think that the difference between the mediocre and the competent programmer is confidence. When we take an assignment, a clearly defined task with a definite solution, believing that we can work out the answer is the most crucial thing to succeeding. I wonder if this is related to there being fewer women in computer science, as women are often less confident (also this article).

    I’ve seen this not just with my students, who sometimes email me checking their correct answer because they are shocked they happened upon it, but with my own experience. If there was one thing that stopped me achieving my potential during the first years of my undergrad, it was my lack of confidence in my own abilities. I felt that I was at the bottom of the pack, but since I’ve come to realize that that was mostly in terms of arrogance.

    Not that I advocate being arrogant – but having a little more faith in yourself might make a big difference, it has for me at least. If it takes 10 years to learn to program, by my calculations I’m less than half way there. Now, I can’t wait to go out into the real world so that I can make the progression from competant to good, and I hope eventually – great.

    My friend Dig makes me believe this is possible, and his thoughts on what makes programmers great are below.

    Credit: flickr / Don Solo

    Having been living in the Real World(tm) for a couple of years now, I’m acutely aware that the rules are somewhat different than at university.  You’re not working on self-contained projects for your own grades any more, and you’re almost certainly working with people who are smarter and more experienced than you are (at least to start with).  Out here, confidence still matters, but you have to ground it in something – it’s not for nothing that the Dunning-Kruger Effect is reflected in new grad CVs more than those of seasoned vets (you are not a Java expert if your name isn’t Josh Bloch, I’m afraid!).

    I’m firmly of the opinion that programming confidence should come only from working with great programmers. The reason for this is pretty simple: programming – or more accurately, software engineering – is about putting together complex interactions based on a whole heap of assumptions you have, be they about users, the type of input you’re going to get, the systems you’re interacting with, the performance of the hardware you’re running on, and so forth.  Assumptions have a nasty habit of being completely wrong, but non-obviously such that they come back to bite you much later on.

    Working with other programmers means having to justify your assumptions or revise them in light of others’ opinions.  Working with great programmers means you have to do a damn good job of that justification, and that the revisions you make are going to be of a higher quality and frequency.  As you do this, with any luck the ratio of justification to revision improves, and with it comes deserved confidence.  It should never go to 1:0 though, that would be terrible both for personal development and humility.  If it does, seek out more great programmers to disagree with pronto!

    I say ‘working’ with other programmers, although I should really say ‘interacting’.  Manipulating the same codebase, having to use each others’ designs and – if you get the chance – pair programming are definitely the best ways to achieve this, but the discussion over a mailing list or around a table (coffee in hand, naturally) are equally worthy, especially since you can balance the daily make-it-work hackery with the conceptual ‘ideal world’ solution.  One of the best programmers I know is completely addicted to Stack Overflow – I’m sure the two factors feed into each other hugely.

    I’d also qualify ‘programmers’ as being explicitly plural.  One other opinion is never enough, particularly given the predisposition of compscis to get over-enthusiastic about the One True Path to code nirvana.  It’s the same with design patterns, IDEs, languages and so on (every object-oriented coder should be made to write some functional code), but vital with others’ opinions.  Many inputs makes it easier to spot the zealots and avoid becoming one yourself – or at least being able to justify it more competently!

    Finally, there’s the bootstrap – you can’t sit anyone next to a great programmer and expect greatness to transmit via osmosis.  This is probably worth a whole book in itself, but I’d say solid core computer science (especially algorithms and data structures, but I would say that as it’s my thing), a flair for design and an ability to break down your assumptions, both technically and psychologically, are all key (try Test Driven Development, even if you don’t stick with it long-term as it teaches you those).

    Of course, this is all one opinion from someone a long way off of greatness, so by my own logic you should ignore me.  Ah well.

  • Why Aren’t You Testing Your Code?

    Break it open
    Credit: flickr / Bindaas Madhavi

    On Tuesday, I told the lab of first years I TA that they were going to test their code.

    Then one of them started asking me about a quiz.

    Erm? No clue. So I said, no we’re going to test your code. And he talks about a quiz some more. It’s all very confusing, but eventually I (helped by several students who joined in) managed to explain that there is a test suite that’s been coded which is going to run their code and see if it works.

    OK, these are first years. But in the graduate course I’m taking on testing, I’ve been baffled by the blank incomprehension of graduate students about the concept of testing their code. Bored by the step by step basic instructions the prof is giving. Horrified by the questions that ensue – this level of detail is clearly necessary.

    Even more horrified by comments outside the classroom, “I don’t need to know how to test my code, I don’t intend to be a software engineer”. Another guy told me that he had no clue about testing code until his boss asked him to do it one day, saying “someone has to”.

    What I told my students: You have to test your code, no-one is that good. People who think they don’t need to test their code are stupid.

    Bad code has killed people and cost billions of dollars.

    In this same lab, I misunderstood part of the specification of the assignment. What made it clear? The test suite. Code is invariably clearer than prose. The test suite is your specification.

    I’ve lost count of the number of times I’ve heard “My [Masters/PhD] took [time frame – no less than 6 months] longer because I had to work with this guy’s terrible code”.

    Oh really? Did they not test? Did they not document? How about you, though? Are you testing? Are you documenting?

    Once you eventually graduate and pass the project on to someone else, will someone be complaining about your code?

    We need to test. We need to document. This should not be a question any more, and honestly, I don’t understand why it is! Even if you don’t want to be a software engineer, if you’re going to write code you should know how to test it.

    I know, there are no rewards for testing in graduate school. Apart from – better code that it’s easier to do stuff with. And I know, time can be an issue and refusing to deliver to your supervisor because you need to run tests probably won’t go down well, but let’s at least be aware of what the ideal to live up to is, and why, rather than just writing it off as a waste of time.

    So even if you don’t buy in to test-driven-development, here’s a suggestion:

    The next time your code is broken, don’t debug – test. The next time you are given code that makes no sense, don’t debug – test. The next time you want to complain about the code you’re working with, don’t complain – test. If the tests fail, you’ve proven their code sucks. Good for you. Now you can do better.

    Incidentally, the class, although dull, has not been a complete waste of time – in JUnit 4 you can have parametrized tests. Awesome!

  • Holiday Science Lecture Presentation: Art, Life and Programming

    Here’s the slidedeck! Because I’m presenting in French I’ve kept text to a minimum:

    Posts with detailed notes about what I’ll be covering and the videos (which won’t work from Slideshare – boo!):

    Part 1: Introduction

    Part 2: Art

    Part 3: Life

    Part 4: Programming

  • Thinking Like a Programmer

    I see this problem continually in the first years I TA – they’re so overwhelmed by syntax they don’t know how to start to write the program. VB (in Excel) is especially mean about this, as if a line of code won’t compile it won’t let you go to the next one.

    So, having given the same explanation 10+ times I’ve made it into a presentation – I hope if you’re a beginner programmer you’ll find it useful. Let me know what you think!

  • Explaining Pass by Reference and Pass by Value

    MMMM an Iced Cap from Timmys
    Credit: flickr / feistygalkmc

    Yesterday I had to teach the distinction between pass-by-reference and pass-by-value to my first year non-CS students. There are second and third year CS students that don’t grasp this concept. But there you go.

    And so I explained it, to a sea of blank faces. They understood what I was saying (I think) but it made no sense to them. Trying to explain that the same thing can have different names, but sometimes it’s a different thing and sometimes it’s just the same value as the other thing but… yeah. It’s a little mystifying.

    So I hit upon a better way to explain this (the slight temperature from the swine flu vaccine I’d had the previous day and the copious amounts of Tylenol probably helped), using Ice-Caps, which one of my students keeps telling me I should be drinking (I know, instead of tea – horrifying!). Lets call her Student A.

    So Student A can have an ice-cap, which she calls delicious. Then she can pass it to me as a parameter, and I can call it disgusting-like-poutine. Then I can pass it to Student B, and she can call it n’apporte quoi. If we give it back to Student A, she can continue calling it delicious.

    If we’re passing by reference then it’s always the same Ice Cap. Student A might have a full one, drink a bit, give it to me, I might pour some away, then my function exits and Student A has the Ice Cap again (in some sense Student A always has it, but let’s just assume that we as a group are running in a single thread), which has whatever was left when I finished pouring it away.

    If we pass by value then each of us has our own Ice Cap. When Student A gives me the Ice Cap, it’s like she gives me a clone of hers. If she passes me a full one, and I pour all mine out, she still has a full one when I exit. My actions to the Ice Cap do not affect her Ice Cap.

    Make more sense? The problem with teaching programming is that everything seems very abstract. I find adding real world examples (and humor) really helps.

  • Java Workshop in Wave

    Tonight, I ran my first workshop in Wave. It was nice to have a space to discuss things, and unlike in a chat client it’s easy to indicate what you’re replying to. What I did was create a slide deck and make it available the day before. Then on the day, I was available to trouble shoot. The slide deck was fairly comprehensive (see it here) so I encouraged people to work through it at their own pace, whilst I clarified and helped with issues that arose.

    Screenshot below shows mutiple threads of conversation happening simultaniously:

    Multiple Conversations
    Multiple Conversations

    It’s also really easy to drag and drop screenshots, so that can help me see where people are at, and what could be going wrong.

    Drag and Drop Screenshots
    Drag and Drop Screenshots

    Wave has nice indentations (kind of like we indent in Java!) that show a diversion:

    Indentation shows the flow of the conversation
    Indentation shows the flow of the conversation

    Finally, trying to schedule when everyone can make the next session can be difficult – but Widgets sure make it easier!

    Widgets help with scheduling
    Widgets help with scheduling

    So, all in all, wish Wave was faster but I think it was a success. Hopefully as people build up more knowledge they’ll discuss amongst themselves more. We will leave this wave going as people work their way through the rest of the slides (and I can help if necessary) and move to a new wave for the next session.

    I’ll keep you posted about when that will be – and will put the slides up here soon!

    Thanks to everyone who participated.

  • Java: Building Blocks

    Tomorrow I’m running an introduction to Java via Wave. Because I’ve had a degree of interest from non-complete beginners in learning Processing, I’ve split the content so that one session will be Java: Building Blocks which will teach the very basics of Java but does not introduce Processing, and the other session will be An Introduction to Processing.

    Java: Building Blocks covers the very very basics of Java – writing your first program, primitive types, conditions, and loops. At the end, we should be able to make a simple Hangman game using a framework I will provide.

    An Introduction to Processing will cover getting started with Processing and be suitable for beginners who have gone through Java: Building Blocks but hopefully won’t be too dull for more advanced programmers. It will take you through creating your first little Java applet in Processing.

    I’m taking suggestions for Topics, but things I’m contemplating are:

    • Java: Next Steps – covering arrays, multidimensional arrays, Objects, more on functions (passing arguments etc). Finishing with a TicTacToe or Pacman game (I have frameworks for both of these).
    • Test Driven Development and Exceptions – throwing and handling exceptions, writing code to pass test cases. Working on a Blackjack game.
    • Creating games in Processing – detecting key presses etc.
    • New Since Java 5 – Generics, enum, for each, etc.

    Slides for Java: Building Blocks can be found below. As ever, I really welcome feedback!