my first Software Engineering project

a bit of background:

~7 months ago, I started working for a cool startup in Old St. I joined as a ‘Data Researcher’ (somewhat akin to a Data Scientist) but recently moved to the Engineering team. I now sit on the Core Platform team, and my first project involves building a ‘CLI tool’ for Business Intelligence. Honestly, just being able to write this makes me so happy because it has been quite a journey to get here, and get my foot in the door of programming.

CL..what?!

CLI = Command Line Interface. Soo, basically..every computer (yes, even yours!) has this thing called a ‘terminal’. When you picture a programmer, you probably imagine them coding away on some big, black screen, with lots of lines of colourful code (think Matrix). Everyone has access to this ‘black screen’ aka the terminal 🔮 and you can talk to your computer through there! You can do all sorts of things, like navigate about your directories (like using Finder in Mac, for example but all written through code) and you can also run programs etc… it’s v useful 🙂 the ‘command line‘ is what we use to write our commands into the terminal.

But it’s not just about the code – something I did not anticipate was the sheer amount of concepts behind the code e.g. TDD = Test Driven Development. So it’s not just about writing lots of lines of beautiful code (or actually, writing less if you’re following DRY or KISS principles 😂).

TDD

As a concept (before ever practising it), I always found Test Driven Development difficult to get my head around – how on Earth could you write code driven by tests? I.e. write tests before your code?! There’s nothing to test, surely! Thanks to the super awesome guidance of my mentor, and doing something called ‘pair programming’, I finally understood 🙏

The whole idea is that you write a test with what you want to return, and then firstly you make that test pass with the minimum amount of code possible. This might mean writing something as simple as ‘return 1’ (which could be your simplest test case). It is only when you start testing more cases (e.g. return {1} and {2}; return {1}, {2} and {1, 2}) that your code develops and you actually need to write logical code, rather than just returning stuff. Then you ‘refactor’ i.e. make your code ‘clean’ 😀 because it might be a bit messy, seeing as you just wanted to make that test pass!!

Btw, those test cases are based on a v. complicated and difficult coding dojo that I did with my mentor, to do with subsets if you’re interested…

🦇

Tests come in lots of different layers: you have low-level stuff called ‘unit tests’ that literally test the little, individual units of your code. It was using unit tests that I practised TDD and started building the CLI tool. Then, at a much higher level, you can test the program itself. I did this using BATS, or Bash Automated Testing System. 🦇🦇🦇

Bash?! I hear you say..well, we are back to that terminal. Bash is the ‘language’ that the terminal understands, and BATS lets you write tests in the language of bash!

So, what on earth does this ‘CLI tool’ actually do?! I think it might be easy to get obsessed with the technical details and lose sight of what the actual purpose of the project is..Anyway, like I said, this is for the Business Intelligence team, which integrates with all the different services in the company, and gives them literally, insight/intelligence into their services. Currently, if a service wants to integrate with BI, it is mainly a manual process, and this CLI tool represents the first step in automating. For example, what I built using TDD was something that returns the types and versions of a service to a user (from the command line, hence CLI tool!)

Final thoughts…

Something else that is still fairly new to me is this whole idea of architecture.. for example, it’s not just about building the tool but thinking how it will ‘talk’/communicate with servers etc…it’s fascinating.