The GIANT CAP approach to coding for journalists.

There are lots of approaches to coding and software development. Methodologies like Agile, Scrum, Lean, Spiral and Deathfist* are even becoming the norm in newsrooms. But I have a suggestion for a quick and easy methodology for journalist’s getting to grips with coding.

Coding for journalists is contentious topic. Despite what anyone tells you, if you’ve never touched a programming language, its not straightforward. I’m not a coder/programmer/hacker at all; I like to tinker. But like many, I sit down with the best intentions — I’m going to learn x or y properly. I sit down with the tutorials and work my way through the first few until I get board or can’t get stuff to work like the tutorial and give up.

The best results I’ve had are when I’ve had a problem. Something I know code can do but no idea how. Knowing what it is I want is enough to get me started. I can’t honestly say I’ve ‘learned to code’ but I’ve learned enough to get the job done.

As a result I’ve settled into a methodology for working with code that works for me and I think also might work if you’re a journalist and want to try coding. It’s called GIANT CAP.

In a nutshell its this:

Google It And Then Cut And Paste

Breaking down the method in more detail, there are six main things to consider.

  • Pseudo code your ideas
  • Ask Google
  • Try examples
  • Cut and paste errors into Google
  • Attribute the solutions by saving links to your sources.
  • Comment the backside off your code.

Pseudo code your ideas.

1. Load the data file from a folder
2. Tell me how many rows there are
3. Look rows that match a value NHS
4. Tell me which rows they are.
5. Work out the average value from those rows
6. Save those to a new spreadsheet.

Breaking down the job this way helps identify the block of code you’ll need. Many programming languages are designed with an eye on mirroring ‘normal language’ so in principle it shouldn’t be a huge leap to begin to make it look more like code as we progress. At this point though, try and look at one task per line but try not to be too specific. As your experience grows you can even start to throw in more code like ideas.

Here’s an example of that from something I kludged together the other day. I wanted to work out how many rows I needed to show 60 images per row based on a number of images in a folder.**

# Count how many files are in a folder. num_files
# Work out how many minutes that is. minutes = num_files/60
# Round that number up so we get full minutes

At the end of each line I’ve added a variable like num_files or a bit of ‘maths’ to work something out like minutes = num_files/60. That last equation worked directly in python — it was actual code!

Ask Google

This is the bit where you need to take a deep breath and dive in. Things can get quite hard-tech quickly. But if it looks daunting, my advice is ‘don’t step away too quickly’. Scan through pages and tutorials, even if you don’t understand them completely. You’ll be surprised how quickly you can join the dots just by immersing yourself in the language.

One site that pops up a lot and I guarantee will become a regular haunt, is Stack Overflow. It’s the best and worst site on the web for coding advice. There are loads of examples and lots of advice. But again, be prepared to grit your teeth and wade through some stuff that might not immediately make sense. The key thing is there is lots of code to cut and paste.

You’ll also come across sites that seem to cover loads of what you need — those sites that people lovingly curate over time. One I’ve found really handy is data scientist Chris Albon’s site. It has loads of great tutorials including working with Python from the basics to more data journalism friendly things like PANDAS.

Try examples

If you don’t have a coding environment or just want to tinker, there are plenty of places you can try code out. If you’re playing with Javascript then ‘sandboxes’ like Codepen are great fun. If you want to try python or R (very common in data journalism) then try Jupyter

Trying code out in blocks is not only a good way to learn by doing, it’s also a good way to build a library of code to use. Taking our example above, having a working block of code that takes a file from a folder or filters some data, is something we can use again and again.

Cut and paste errors into Google

  • You’re missing something the code needs to work — code often relies on third party code that comes as a package or library
  • You’ve put the code in the wrong place — often there’s an order to the way things are done.
  • It’s the wrong version of the language — code differs between versions of the same language. E.g Look at this comparison of python 2 and python 3

If there’s one thing that programming languages do well its give you errors. They are also really bad at telling you what they mean. But most will have some things in common:

  • They’ll tell you which line in your code caused the error (or at least where it started to go wrong)
  • They will tell you the general type or effect of the error.

Here’s an example from Python:

File "", line 112, in <module>
print ("We've got "+len(npath)+" frames to work with ")
TypeError: must be str, not int

It tells us that at line 112 something that should be str is an int! Copying the error and putting it in google gives us plenty to go at. Again, it is helpful to stick the name of the language at the end too. e.g “TypeError: must be str, not int python”. The problem here is I’m trying to do something with a number (int) when python was expecting text (str).

Attribute the solutions by saving links.

Comment the backside off your code.

There’s a debate in coding circles about comments and the general feeling is that you should keep comments to a minimum — the code should be descriptive enough. I can see the sense in that, especially if you’re working with others. Comments might mean something to you but might confuse others. But in GIANTCAP you’re commenting for you so be as cryptic or wordy as you like.

Good enough to move to the next step

The code I write is never pretty. It isn’t efficient. It is often slow and very rarely works first time. I don’t think I’d show some of it to anyone let alone a coder. But it works. Eventually.

I would guess that for most journalists, that’s enough. Code just needs to do a job, deliver a result we recognize and can work with. Then we can move on. Maybe a few days or months later you’ll need to do it again, or something similar, and it will all be there waiting to remind you. All the info about the way you kludged your way through last time will make the next time a bit easier and maybe remind you how much you enjoyed it when it finally worked.

If you want to see an example of some code written using the GIANT CAP method take a look at some code I wrote to sample a video file.

* Ok I made that one up.

** You’ll notice it starts with the hash symbol, that’s because I wrote the code in Python and # is how you start a comment.

Online Journalism Lecturer and geek. More at

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store