In a move that is known technically as Continuous Professional Development, but which I prefer to call Learning About Some New Stuff I Find Quite Interesting, I recently went on a QlikView Developer course. This is to help me move beyond building pretty (and pretty useful) little objects in the user interface which people see in the reporting software I write with, and into writing code for what is known unironically throughout the field of IT as ‘the back end’. You could think of the distinction between the user interface and the back end as the difference between the stage where the actors go, and backstage where all the wiring and machinery lives. That’s my preferred metaphor–it’s a good one for many reasons, but there are others that help me think about the nature of my work.

As we delved into increasingly technical and precise coding tasks, I was reminded that the deeper I go into programming the more it reminds me of crochet. At the end of the day they are both series of algorithms based on iterations of precise instructions that can build pretty amazing things if done correctly, and if you screw up one tiny little element the whole thing breaks. And sometimes you can’t fix it. Or even know where you went wrong. But sometimes you create something even more amazing than what you were trying for in the first place.

There are examples of algorithms all around us, not all of which are represented mathematically or in code form. I think being familiar with crochet has actually helped my coding skills immensely, because it made algorithms seem less alien or intimidating. (Though it’s the other way around, really: I learned to crochet after I took my first computer science class, which was algorithm-tastic). I’m not saying that every coder should go out and learn to crochet (though the scarves do make nice Christmas presents) but I think that if more examples of the algorithms that surround us in daily life had been presented to me early in my education, I would have found it much easier to picture myself in a coding career, and to make more informed decisions about what that could entail and how I could prepare myself.

Why, I hear you saying, is this important? With women accounting for less than 20% of the workforce in ICT jobs in the UK (and most OECD countries), anything that can be done to try to make coding a more attractive career option is pretty vital right now. Luckily there are a lot of Top Brains looking into this–but that doesn’t mean we can rest on our laurels. I would be really interested in hearing from other women in technology about how they became interested in coding or ICT work, and which aspects of getting into the workforce they perceived as most challenging. And perhaps most of all, what they think could be done or what they are doing to combat some of those difficulties.

While I was at this course, I also got into a really interesting conversation with one of my colleagues about the nature of data representation. This person and I agreed that, for people who are not Data Wizards, it is absolutely vital to present information in a digestible format. (This is actually also true for Data Wizards, but what we consider digestible is not always the same as other people.) I firmly believe that, no matter how good your data is, if you can’t present it in a format that the recipients understand, it’s it’s like you’ve said nothing at all. If the goal of information is to affect decisions or behavior, that goal can be helped with better data–but it can only be REACHED if the data is digested and understood.

My colleague and I agreed that often the biggest naysayers of more effective data presentation are the Data Wizards themselves. They are used to numbers. They like spreadsheets. They want tables. Everyone else in the business is all excited about little charts in the shape of flowers, or wookies, or turkeys in Pilgrim hats, or whatever data they’re working on that week, but the Data Wizards are digging in their heels and grumbling mightily about the whole thing. It can take a while to convince the Data Wizards that data presentation is not a bunch of fluffy gumph designed to hide the numbers. In fact other people (‘business stakeholders’) will actually be interested and will want to listen to the Data Wizards more if they present information in a way that allows people to intuitively grasp what the numbers are saying. If you can get the Data Wizards on board with this idea, you can create some very powerful Data Wizards indeed.

(PS: you can ignore everything I said in my previous post about relational databases and not storing everything in one GIANT table, because, unlike most other data querying structures, as I learned on my course that’s exactly what QlikView DOES want.)