ITG Work Experience Week

This week, I had the opportunity to visit TeamITG’s Birmingham office for a week-long work experience placement. There was another work experience program going on concurrently to mine with more people, but this was completely unrelated to that one as I set this up before that one had opened up. Mine was a week’s worth of shadowing people, while they had other stuff to get on with at more of ITG’s offices in Birmingham & London.

The Devs⌗

Day 1⌗

After being checked-in by the receptionist, I was met by the current Operations Director. I didn’t spend much time with her, but she gave me a quick tour of the office & introduced me to the 2 devs who had the misfortune of being with me all day instead of working from home. One of them was a full-stack developer but with a main focus in frontend development with PHP (Laravel) & the standard web malarkey. The other was another frontend-oriented full-stack developer focussed on WordPress. My first task of the day was to get a Mac sit in on the daily standup. Not too much was gained except the experience of listening to elite-level yappers and the knowledge that JESUS CHRIST THEY HAVE A LOT OF PROJECTS. The full-stack developer explained to me that his team is somewhat unique in that regard - they don’t have a specific product they focus on so they have to context-switch a lot & have a pretty wide variety of skills. Other teams though have “their thing” and so all of their tasks tend to be related to that. Whether this is a good or bad thing is entirely up to preference, but I personally think it’s quite cool - keeps things from getting boring & makes it more exciting.

Next on the chopping block was another meeting!

This one was coming up with a quote for a client for a project they wanted done. It was simpler than most as this particular job had actually been done before with minor differences, so a good amount of code could just be reused. This is not normal. Making good not terrible estimates is something that can really only be learnt by doing it. A lot.

Other than this & chatting with some other people, I did have a couple tasks to get on with - given to me by another frontend dev who has the more niche skill of being really good at HTML emails. My first task was to create an HTML email. I got a finished product and a partially complete file, and had to try my best to recreate the final email from what I had. Considering that HTML emails are stuck in the stone age, it was a fun exercise in working around weird constraints! Doing everything with tables is possibly the least intuitive thing imaginable but it’s actually pretty cool to see how shit still (mostly) Just Works™.

The second task was much more straightforward - just normal HTML & CSS things. I was given a landing page for a client and had to make certain edits to it such as adding buttons & iframes to new pages. All in all nothing was really out of the ordinary about this task. One iframe linked to an external site which refused to load, but such is life - it’s not my fault anyways.

Day 2⌗

This day I was with just one person - the Lead Developer of the UKDX (UK Digital Experience) team with just one (quite large) client to focus on. They aren’t the only team at ITG assigned to this client, but what they are is an entirely internal team that can act independently of other people this client may go to for other things. This 3rd party does get veto power but still - it’s the thought that counts

It was a less eventful day, mostly filled with meetings just by pure coincidence, but there were still interesting takeaways from it. From sitting in on the meetings, I got a taste of how the team carries out agile development. It is different from how most teams do it (to align with the client), but not to the point that it’s no longer good experience.

First there was standup. This wasn’t much different from the last one except that it was noticeably more targeted, probably thanks to these guys only having one client to worry about, and the fact that they were at the end of a sprint. This meant that they were planning the next one in this meeting. They give tickets ‘story points’ which correlate to how complex the ticket is to solve.

Their scale for these points is the fibonacci numbers so that the difficulty increases exponentially, but mostly only 3s & under are seen. This is because whenever something larger is seen, it can usually be split up into smaller, less complex tasks and thus will have those component tasks scored individually. The way they score tasks was interesting too, as they do it through a game of poker! This actually makes sense when you think about it though - nobody’s scoring can affect anyone else’s so it’s more representative of what people really think about a ticket’s complexity.

Next, I sat in on a client demo of what they had done this sprint. Most of the improvements had been background things like improved test coverage so the demo wasn’t the most interesting thing in the world, but it was still good to see how they explain things like this to a non-dev.

The last thing I sat in on for this day was retro. This is the meeting at the very end of a sprint in which the team evaluates their performance - finding things to start/stop/continue doing, which changes they’ve made have been successful, and which team members have done things well or poorly. I’m told that these retros can sometimes get a little heated just from the nature of what’s being spoken about, but this one wasn’t. It came at the end of a pretty boring sprint, so there wasn’t too much that could actually be evaluated - most everything was deferred to next sprint to be evaluated.

Additionally, throughout the day I was intermittently making progress on the day’s CSSBattle target, which the lead developer had introduced me too. It was certainly a challenge for me considering I’m very much not a frontend dev, but it’s useful experience and a good way for me to improve on my CSS skills by just attempting the challenges daily even if I don’t end up completing them.

The Configurators⌗

For the rest of the week, I was with the configuration team, primarily with two Senior Configurators and two Implementation Consultants. I’m grouping the whole 3 days together since not much actually separates them other than the changing calendar.

The job of configurators is to set up backend asset & project management sites for clients using Canopy, ITG’s own WordPress-esque solution, with a backend in Luma, a system written in Java that was sold to ITG by its original developers. This part of my time was almost entirely spent learning how to actually use Luma in order to create a Canopy site, with some meeting breaks in between.

Starting with the meetings, on the second day I sat in on the full team meeting in the morning and the configurator team meeting in the afternoon. The full team meeting gave updates on different clients, leavers & joiners to the team, and updates on the training resources which were available. Additionally, there was a task in which the team was split into groups and given an open-ended brief based around an asset review system which they were to plan a solution for. I wasn’t able to help in this for obvious reasons, but it was very informative to see how they plan out solutions as a group and the different considerations that have to be made. Using LucidChart, they had to decide on affiliates, review actors, and different review stages.

Seeing the way in which they approached the problem and the questions they asked each other was quite eye-opening to say the least. Also interesting is that, despite the brief being intentionally open to interpretation, the groups all arrived at roughly the same conclusion with only minor differences between them - most of which were simply because not every team chose to limit themselves to current functionality available in their tools and made use of planned improvements.

The config team meeting was similar a developer standup, where each member of the team shared what they had been working on and suggestions were made for improvements as to what to do next. Basically everything from the developer meetings applies here too, so I won’t go super in-depth on it.

As for the Luma training, this was a super unique experience! Everything in Luma is linked together via types, and these types can inherit from each other in a very Java way. Everything is grouped into domains which separate parts of the backend, and user-facing webpages are sites. Each domain can have users on it and these users can be part of permission groups where different permissions are known as services which a user can execute. You use schemas to link processes/resources to types, and each process is basically just a FSM - with some starting state and a set of transitions between states - that does something in each state which is usually granting or revoking some permission. Taxonomies can be created to classify assets by grouped keywords, and these taxonomies can be filtered using lenses. Lastly, you can use transforms in order to convert assets into different formats, for example for download.

Birmingham is a City⌗

Lastly, I want to talk a little bit about the city I was in, as this was my first time being in Birmingham.

The first thing I noticed is that there are not very many black people at all there. This could just be a quirk of where I was staying (I did see more when I travelled out of that area), but it was a pretty weird experience coming from London - we’re absolutely everywhere where I live.

The second thing I noticed is that TFL is a fucking godsend. Buses over there can be as infrequent as thrice per day and live tracking is absolutely abysmal. I also had to pay for them, which is not ideal.

If you didn’t know, London students get free bus travel with the most innovative invention to ever exist - the oyster card.

There is seemingly only one bus in the entire city that displays what stop is next, so Citymapper was very overworked all week as I tried not to miss my stop in a city I had never visited in my life. On a related note, Birmingham is not very nice for walking. You definitely can walk, but you really can’t get anywhere in a reasonable time; I was 20mins away from the nearest convenience store on either side, with one of them requiring my to walk across a bridge with just about no pavement! So that was fun. Really the only things that work there are cars & cycling - because everything within the city is very car-centric. Never before have I experienced navigating a shopping center that’s more parking space than shops and I absolutely hate it. Doesn’t help that there was construction work going on while I was there so I had to walk along the road, but that’s beside the point - I just wanna have good public transport that can save me from horrible walks.

General Notes⌗

First of all, the office is very nice! It’s pretty quiet so not too hard to focus, and it definitely feels like the offices of a large company. I didn’t get to see too much of it as I was too busy shadowing, but what I did see was quite impressive.

Throughout all the teams I was a part of, the general atmosphere was much more casual than I expected. Obviously everyone was still respectful to each other, but they spoke to each other more just as friends - I really couldn’t guess what the company hierarchy was just from seeing how everyone interacted with each other. This casualness extended to me as well; I was treated more like just a new cooker than a student, especially in the config team.

Conclusion of Sorts⌗

The only thing I can really say to wrap everything up is thanks to everyone involved! Thank you to the people coordinator for helping me actually set everything up & suggesting the config team so I didn’t only have 2 days there, and thanks to everyone I met for being super nice to me while I was there - even those whose names I didn’t manage to get.