Category Archives: accu

An Interview With Kate Gregory

Kate Gregory is a C++ expert, who has been using C++ for nearly four decades. She is the author of a number of books, and is an in-demand speaker who’s given talks at the ACCU, CppCon, TechEd and TechDays among many others. She is a Pluralsight author, a Microsoft Regional Director, and a C++ Microsoft Valued Professional, and despite her hectic schedule she still manages to write code every week.

  1. How did you get in to computer programming? Was it a sudden interest? Or was it a slow process?

I did my undergrad work at the University of Waterloo. I started in the Faculty of Mathematics and they taught us algorithms and Fortran as a first year course. I didn’t choose it, but I had to do it. Other such courses followed, and when I transferred to engineering I discovered this was a useful and in-demand skill. I got opportunities to program on my co-op jobs, and it kind of grew from there.

  1. What was the first program you ever wrote? And in what language was it written in?

I don’t actually remember, but it’s a good bet it was assignment 1 in that first year Algorithms/Fortran course. And yes, punch cards were involved. My first program for money was a simulation of the way scale grows inside a pipe – in the piping of steam turbines scale forms in layers that can spall off and cause tremendous damage, so understanding that is an important problem. It led to a published paper for the researcher who hired me, and an award-winning co-op work term report for me. I probably should have demanded credit in the paper.

  1. What would you say is the best piece of advice you’ve been given as a programmer?

Sleep when the baby sleeps. It’s the best advice ever, and I pass it on whenever I can. Second best: the smaller the problem is, the more ridiculous it will be when you finally find it, the harder it is to find. Don’t feel bad about that. Laugh when you finally find the one character typo or the wrong kind of bracket or whatever the tiny thing is that has kept you aggravated for hours.

  1. How did you get in to C++? What was it that drew you to the language?

In the late 80s, I needed to write some numerical integration programs for these multiple partial differential equations I was tackling for my PhD work on blood coagulation. Fortran, PL/1, COBOL, MARKIV and the like were just not going to work for me. My partner was doing some C++ at the time and it seemed like it was going to be much better. Turns out, it was! I had experienced the misery that was the Fortran “common block” so I didn’t want to use Fortran any more, and the other languages were mostly about manipulating text and records, turning input into output. C++ was a better fit for working with numbers, for implementing an algorithm, for giving me what I needed to show some properties of those equations.

  1. Since 2004, you have been a Microsoft Valued Professional in Visual C++, how did that come about? That must feel pretty awesome?

MVPs are chosen primarily for their generosity. You can be a complete and utter expert on the C++ language or on Microsoft’s products, but if you don’t share that and help people with those tools, you won’t get the award. Mine I believe was triggered by my books, and more recently my activities on Stack Exchange sites, backed up of course by conference speaking. It’s nice to have that effort recognized. What I like best about the MVP program is the access it gives us to the team. I can reach just the right person if I have some issue with the Microsoft tools, and get advice or an explanation or “we’ll fix that in the next release.” Of course, the award certificates look good on my “bookshelf of showing off” as well.

  1. You hold an incredibly busy schedule between speaking at conferences, travelling, and doing Pluralsight courses, how do you keep your skills up to date?

It’s part of my job to stay current. If I spend an hour (or an afternoon) swearing at a development environment on a platform I don’t normally use, well that counts as work. It’s as valuable work as preparing a talk or doing something billable for a client. So is reading long documents about what’s new in C++ or trying out a new library someone has released. What’s nice for me is that once I’ve put that learning time in, I can use it in many different ways – as the backbone of a talk, a blog post, to help a client going through the same thing, as part of a course, and so on.

  1. If you were to start your career again now, what would you do differently? Or if you could go back to when you started programming what would you say to yourself?

I came up through a sort of golden age. You had to teach yourself things, or find someone to teach them to you, because there wasn’t a lot of training available. But then again, people didn’t demand credentials or challenge your background. If you said you could do something, the general response was to let you go ahead and show that you could. I think I would just reassure myself that my somewhat unusual path was going to work out to be amazing. I really only had a traditional job for two years after I finished my undergrad work. By the time my grad work was done I had a business with my partner, and we have made our own path for three decades now. It’s had some ups and downs, but I don’t think I would actually change any of it.

  1. If there is such a term, what would an average working day look like for you?

Oh there are most definitely no average days. I have routines when I’m home – swimming in the morning, coffee and email before I get out of bed – but I do so many different kinds of work that it’s hard to characterize. I try to react to my moods if I can – some days are better for writing a lot of code, others are better for big picture design whether of code, a course, or something I’m writing, and still others are the days when you have to catch up on emails, phone calls, paperwork, and buying things. Some days I might be elbow-deep in code when it’s time for my evening meal and I just keep right on working well past when I should have gone to bed. Other days I stop in the afternoon and for the rest of the day I just do something – anything – that isn’t work. It’s nice to be able to work according to my own rhythms. I have to be diligent about deadlines and promises, and some days I have to do things that are a little suboptimal because I have no more room to rearrange, but for the most part I do things I like from when I get up until when I go to bed, I do them side by side with my partner (my husband is my business partner) and I get paid for it, so that’s a pretty nice life, isn’t it?

  1. What would you say is the best book/blog you’ve read as a developer?

The Mythical Man Month got me thinking about the big picture of managing teams and people, managing projects, instead of just writing code. And it showed me that people can disagree and best practices can change. While I rarely draw on specific facts or quote from it, it changed the way I thought about creating software.

  1. Do you mentor other developers? Or did you ever have a mentor when you started programming?

Yes, I mentor others – I’ve done so as part of a paid engagement and I occasionally just offer unsolicited advice to those I think need it. People ask me to help them and if I can, I do. That doesn’t mean I’m going to write half their application pro bono, but I answer questions and suggest things to learn or try. I’ve been the happy recipient of a great deal of marvellous advice from friends and peers, folks who were a little further ahead on one aspect of all the huge difficulty that is being a developer, and would tell me things I needed to know or introduce me to the right people. I try to do the same for others as often as I can.

    1. If you do mentor others, how did that come about? Do you do face to face mentoring, or do you do electronic mentoring?

Because I live in the middle of nowhere, most of my advising is not in person. I have had regular Skype calls with those who I am advising, and that works really well. Sometimes people email me their questions, or even message my public Facebook page, but the nice thing about Skype is I can see their screen, or show mine, while we’re talking live. That’s generally a lot better than email or other kinds of asynchronous messaging.

Then again, some of my most valuable advice has been given in restaurants and pubs. There’s no need to be in the same place if I’m explaining C++ syntax or architecture or “good design”, but career advice, soft skills things like dealing with difficult people or knowing if you’re charging enough for your time – that works better when we’re in the same place and relaxed. It’s one of the great things about conferences and other in-person get-togethers – a chance to give and get advice, or to listen to other people’s advice sessions.

  1. Finally, what advice would you give to someone is looking to start a career as a programmer?

Be prepared to keep learning your whole life. Be prepared to spend a long time learning something, to use it for a while, and then to see it become useless. Don’t fight that, move to the next thing. Watch for the big architectural and people lessons that still apply even when you don’t work on that platform, in that language, or for that kind of business any more. Hold onto the wisdom you build up, while realizing you still need to learn new knowledge (language syntax, tool use, platform idiosyncrasies) every day.

You can learn from online courses, from working on a project on your own time, on the job if you’re lucky, from just trying things and then frantically Googling when they don’t work. You can combine dozens of different ways of learning things, getting unstuck when you’re stuck, and realizing when to give up and start over. We all feel stupid from time to time, that doesn’t mean we really are. (If you’re working with the pre-release of something, you may have found a bug – I’ve done it and most of my friends have too. It isn’t always you who’s wrong.) And we all have to start over – new languages, new tools, new teams, new platforms – from time to time. If you know how to learn, how to start at something and recognize where you can use things you know from before, how to ask the right questions and how to make sure you don’t have to ask the same question twice – you’ll be doing very well indeed.

Oh, and sleep when the baby sleeps. Do not forget that. In the larger sense, that advice applies even for people who never raise a baby. There are times in your life when there just isn’t time to do everything, so you have to do the most important thing whenever you get the chance. Don’t waste time doing the second most important thing if there’s a good chance you won’t get another opportunity to do the most important thing. When you have a new baby, that means you don’t tidy during naps – your most important thing is sleeping and you do it whenever you can. When you’re writing software, there’s never enough time for everything. If you spend time doing less important things, you may never get to do the most important ones. That’s a disaster. Know your priorities and don’t skimp on what’s most important when there isn’t enough time to go around – which is most of the time, to be honest.

Advertisements

When a talk goes badly…and a lesson from the Space Station…

A month or so ago, I gave a talk at the ACCU Oxford user group on unit testing threaded code. And a long story short, it didn’t go all that well. Initially, I was quite disappointed, and frankly felt like an idiot. The drive home in the car was quite a solemn affair, my friends who’d come with me were being supportive, but that didn’t change the fact that I’d basically delivered a turkey.

I’ve been mulling this over for the last month, and one of the books that helped me a lot was Chris Hadfield’s An Astronaut’s Guide to Life on Earth. And one of the points he makes in the book is to view negative things as an opportunity to learn.

Until recently, I didn’t cope will with negativity. My friends will agree that I’m very harsh on myself and I take things to heart far too easily. So having read Chris Hadfield’s book, I was sufficiently challenged, and decided to take a different approach to this. 

So whereas before, I’d have not quite imploded but being glum about it, I decided to view this as a chance to learn. So here we go.

Lesson 1 – Know your subject matter inside out.

Sounds like a no-brainer doesn’t it?  But I’d chosen a very complex topic. Probably too complex if I’m completely honest with myself, and what’s worse is that I said it in jest and all of a sudden I was committed to doing it.  So lesson 1a, is don’t jest Winking smile 

But I digress.  I’m passionate about writing unit tests for code, I think it’s something we should do as developers, no matter what the language we’re coding in. For example at this moment, I’m researching using a PHP unit testing framework. 

But unit testing threaded code is hard.  VERY hard as a matter of fact. And there was a perfectly good reason Google didn’t return much results, and that’s because it’s not something a lot of people do. 

But worse than that, I wasn’t all that familiar with threads either. Sure I have a rudimentary understanding of them, and know enough to be dangerous.  And frankly when presenting to a room full of experts, that’s not good enough. It’s bordering on disrespect, so to those who did attend and read this, I’m sorry.

But if you’re going to give a talk on something, make sure that you are fully versed and confident in what you’re going to say. I wasn’t and it showed. Badly.

Lesson 2 – Don’t use an IDE.

Another mistake I made was to have my code in an editor. Not so bad maybe, but unless you plan on doing live coding demo’s then put it on a slide. That way you’re facing your code, rather than craning your neck around to see what you’re doing on the projector.

I found I was doing this a lot, and lost my place a few times because of it. It also involved me dropping out of the presentation software, and in to the code window, which meant a lot of fiddling and faffing about.

So put your code on the slides unless you are doing a live coding demo, or doing a practical workshop or something like that.

Lesson 3 – Keep it simple

We all like to look cool don’t we with our snazzy slides and clickers. But having chatted with Hubert who is a veteran speaker and trainer. He advised that I simply put my slides in PDF. 

And that’s good advice. Imagine, you turn up to give your talk, and your laptop goes bang. What if the laptop you borrow doesn’t have PowerPoint?  That’s when a PDF is damn handy, especially when you have it on a USB stick.  You can give the talk on virtually any computer with a PDF file.

Also Hubert advised that rather than use expensive clickers, I should use my mouse to travel through the slides which is just as effective.

Basically keep it as simple as possible so that nothing overly complicated won’t break things.

Lesson 4 – Seek feedback, the good the bad and the ugly…

After the talk, I felt quite embarrassed, but I knew that if I wanted to get better, I needed to hear the feedback, no matter how bad it was. And I was given it. (Hence this blog post)

Sometimes the feedback you get isn’t what you want to hear. And I’d argue that sort of feedback is the best type.  But it’s VITAL that you don’t take that personally. It’s not a personal attack! It’s an observation, and after all if you’ve asked for feedback whether good or bad, then you’ve got to have the stones to be willing to receive the bad as well as the good.

And it’s vital you act on it. Otherwise you’ve wasted the time of the person who was kind enough to give you that feedback. The further consequences then would be that they’ll notice you didn’t act on it, and they’ll refuse to give you feedback in future.  And in doing so you’ve cut yourself off from a chance of improving.

Lesson 5 – It happens…

Sometimes, talks just don’t seem to go that well. You could have an off day or something which caused you to lose focus when giving the talk.

And sometimes, that’s how it is. A thousand and one things can cause a talk to nose-dive. The important thing is to recognise this, and not let it get you down.

Lesson 6 – There’s always next time.

You’ve delivered one bad talk. In the grand scheme of things, so what? It’s not life and death.

When Chris Hadfield went up to install the CanadaArm2 to the International Space Station in 1995, he had an irritation in his eye while he was carrying out a space walk to install the arm. His eye starting watering and stinging pretty badly, and in space there’s no gravity for the tears to run away from the eye, it just stays there building up. Right up until it goes over the bridge of your nose and starts messing around with your other eye.  On earth that’s no big deal, but in space that’s pretty serious.  You can’t exactly open the visor and give your eyes a rub as that’ll end badly for you.  Eventually his eyes cleared up, and he finished his work.

But my point is, that one bad talk doesn’t mean the end of your career or anything that dramatic. Sometimes it just doesn’t work out the way you’d hoped.  And that’s ok. 

As long as you learn where you went wrong, then you can smack it out of the park at the next talk you give.

Lesson 7 – Attitude…

Something Chris mentions in his book (I’m not on commission, honest, but it is a great book!!).  When the Soyuz is in orbit, or any solar panelled space vehicle for that matter, it has to turn it’s solar panels towards the sun.  This is known as the vehicle’s attitude.

And the same is true for us too. Our attitude dictates how we respond to certain events.

I’ll admit my confidence did take a knock after this talk.  But that was a matter of attitude on my part. I could chose to let this crush me, which is what usually happens, or I could decide to use this as a learning experience. 

That gave me a fresher perspective and the chance to learn from my errors, rather than risk repeating them again. I can’t recall who said it, but “those who fail to learn from the mistakes of the past, are doomed to repeat them.”

Lesson 8 – There are positives in there somewhere too..

So my talk bombed, badly frankly. But what it did do, was spark an interesting discussion on how we could go about writing unit tests for threaded code, and the techniques that could be utilised.

So even if the talk doesn’t go well, some good can come out of it. And we should remember that as well.

Conclusions

So there we go. I’ve learned a lot from things going wrong, and often times that’s when we learn the most. I have to say that the people at the meeting were very kind and supportive in their feedback, even if it wasn’t what I wanted to hear.  (They were far too nice!!) But they were also willing to give support and encouragement.

Initially I wasn’t going to do another talk this year after that one bombed so badly, but I’ve since been encouraged to do another lightning talk, so we’ll see if I’ve really learned my lessons.  So watch this space.

ACCU Conference Retrospective

I did plan to write a series of blog posts at the end of each day of the ACCU Conference in Bristol, but between having far too much fun learning, and having zero energy by the time I got home, never mind zero brain power, I thought I’d do a write up in one big posts with some “Match of the Day” style highlights.

Day 2 (Tutorial was day 1 for me…)

Day 2 kicked off with the ever energetic and lime-green nail coloured Pete Goodliffe bouncing around the stage giving a talk on how to become a better programmer. He covered various aspects of becoming a better programmer, but the main point I think he made was attitude. Our approach to becoming better. This challenged me (yet again! Thanks Pete (: ) because while I’d been moving forwards to becoming better, my attitude at times sucked!  Frankly.

Pete also issued a challenge to us all.  We were dared NOT to go to the stuff we’d be comfortable with, but to stretch ourselves and head off for talks that were way outside our comfort zones, and attend as novices. (Wasn’t hard for me, I was a novice at most talks!)  That way everyone would leave the conference having learned something they didn’t know before.

After being filled with coffee and all sorts of pastries and such, it was on to Seb Rose’s talk on Low fidelity approaches to software development. He spoke about how we tend to bite off more than we can chew, working on something that’s almost ready and will stay like that, and never get delivered.  He made a quick point on the waterfall and the biggest issue with it, was that everything feels ok until all of a sudden bang!

Seb also made the point that feedback is a very important thing to make use of, because it allows us to see where we’re at at the moment. It also gives us a chance to take stock of what we’ve done, and what our customers think. And pointed out that the Military use the Plan – Do- Check – Act which gives feedback that allows us to change the next part of the plan.

He quoted Father Ted, the scene involving Ted explaining perspective to Dougal making use of a toy cow to explain that this one was close, but the ones outside were far away.  And it’s the same with software projects.  Until we start working on something, we can’t understand the full scope of the problem we’re working on.

From there it was on to Mike Long’s talk on How To Talk To Suits, where I learned a great deal about speaking to business managers. And I thought I already did this pretty well, as I don’t like bamboozling people with technical jargon. This also included a practical workshop to work through which was good fun.

Mike spoke excellently on this, and talked us through a bunch of business clichés, such as a Business Case, where we need to present to someone for an allocation of resources for the stuff we want to do. Time is money, Mike pointed out that from a business perspective, Time matters more than money, indeed, I’ve often come across this in my career up to a point, “we don’t care how much it costs (within reason) but we must have it by tomorrow”.

Mike also used real world examples to explain that money comes in many flavours.  That is to say that if we wanted a new server for example, and our hardware budget was fully allocated, then we could STILL get the money but from another budget, such as an innovation budget for example.  Hence the term that money comes in many flavours.

There were some great lightning talks as well, and Chris Oldwood did some stand up which was great fun, and it’s a shame it wasn’t recorded, as there were some belters, who knows he may pop them on Twitter.

Day 3

Day three kicked off with frankly an amazing keynote talk from Axel Naumann on how CERN use C++. And it was awesome to hear how C++ was used to process data from the Large Hadron Collider. But what was epic for me, was to see some of the stuff that the LHC produced, and the fact that it was all completely open.  Axel also spoke about an experiment they’d carried out where they fired neutrons at nuclear waste that shortened it’s half-life but also generated energy!

Then there was an interesting talk from Kate Gregory and James McNellis on Modernising Legacy C++ in which they raised some excellent points. They made the point that we should compile C code as C++ as we’ll get better type checking.  They also made an excellent point that the warning you ignore isn’t a warning.  So Kate and James suggested that what we can do to modernise legacy C++ code is to do the following:

  • Increase the warning level and compile as C++
  • Rid yourself of the pre-processor.
  • Learn to love RAII (Resource Acquisition Is Initialisation)
  • Introduce Exceptions but carefull.
  • Embrace Const
  • Cast correctly

After that, there was an excellent talk by Chris Smith and Mark Upton from Redgate on what’s wrong with sprint retrospectives and how to fix them. This was a very practical talk, where we there was a fair bit of user interaction where we shared our experiences of working using retrospectives. They shared their experiences at Redgate in improving their retrospectives and had a lot of good ideas I plan to put in place at work.

Day 4

We were treated to a great opening talk where Alison Lloyd went through some case studies of various mistakes made in industry and what we could learn from them. I was scared that there’d be photos of Therac 25 victims initially, however there wasn’t anything like that.  Alison started her talk with a sobering discussion about diarrhea and how it caused so many deaths. It was quite educational and challenging to hear the devastating effect that this had on humans, and HOW it caused so many deaths as well.

This talk was running through my mind for most of the day if I’m honest, and I’m pretty sure I’m not the only one who was challenged and moved by what I heard in those opening 15 minutes.

Day 5

I had the unfortunate experience of turning up to a talk, and needing the loo, popped out for a second or two.  When I came back the door magnet engaged, so I couldn’t get back in. I didn’t want to knock either as I didn’t want to disturb the chap giving the talk.

However, Anthony Williams’ talk on C++ Atomics was very good.  I didn’t understand all of it, but I certainly got the gist of what was being said.  Essentially, don’t use atomics unless you have to.  You should only use them if you REALLY need the performance gains it will give you, and even then you should only use the memory_order_seq_cs (Sequential Constant) as the others are horribly complex, and you should only use them if you REALLY know what you’re doing.

There was a spare slot on the Saturday, so I volunteered to fill half of it with another chap, the only issue was, Roger and Kevlin were also speaking, so I knew that most if not everyone would be at one of those two talks, so I expected nobody to turn up to the talk I gave. But two guys who’d turned up to the previous talk stayed.  So rather than me stand up and do a talk, I made it more informal and turned it in to a chat with slides which I think quite well. I’ll be honest, I knew there wasn’t going to be many folks at this one, but it was a good way to see if I could do this conference talking thing.

The End-note was Chandler Carruth from Google talking about how they’ve made C++ safer, easier and faster with their use of Clang. It was a great talk with some live code demoes as well. He told us how Google had a completely unified codebase which allows for a single unified build system.  Chandler also spoke of the things that made C++ safe and quicker as well but I wasn’t quick enough to grab these as notes, the slides should be available though.

Conclusion

I’m not sure if it was me or not, but this conference felt different to me. It felt like I connected more with the material and the topics, and that could well be due to the fact that I’ve developed as a programmer since the last conference. But there was a pleasing and friendly atmosphere this year, not that there wasn’t one before but it felt more tangible this year at least for me.

I also had the chance to make new connections as well as catch up with those I made connections with last year, and a lot of people came up expressing an interest to be interviewed for the CVu magazine, and those I approached to ask were equally as nice.

I was sad to hear that Jon Jagger who’d been conference chair for the last four years had stepped down. I’m certain that I’m not alone in saying that Jon’s arranged an amazing conference this year as he has done for the last four years, and the fact he got a full minute of applauds and cheers speaks volumes for how good a job he’s done. I do look forward to hearing him speak next year though (:

However Russel Winder is the new conference chair, and I know that the conference is in safe hands.  So I’m excited to hear of what’s going to come in 2016, I may even put in a paper this time Winking smile

If you want to see what went on and who said what, the slides are available at the ACCU website, which can be found at http://www.accu.org and if you like what you see, then consider becoming a member 🙂