Dev at work: Starting at Compare the Market Meeting the team, formalities, XP, LEAN, DDD and CQRS

A friend drove me to work on the Monday. I had been so nervous the night before I barely slept and as I was attempting to pour down an energy drink down my throat while the car navigated the tiny streets of Peterborough I felt slightly sick. It somehow reminded me of navigating through the code base in a previous project which my team as fondly referred to as ‘The Project from Hell’. I had seen the code at Compare the Market (CTM) during my half day of pair programming interview (which would have been a full day if Ryan Air had been on time) and knew that I would be taking part of a good codebase which had recently undergone a complete restructuring and had more planned.

Dress to impress

I had a navy blue business dress on me, comfy high heels Crocs, a warm green jacket, conservative makeup and straight platinum blonde hair. Compare the Market belongs to the BGL group which meant a big move from consultancy and touch first software development to finance- more precise insurance. This meant a change in wardrobe so I had decided on taking out my piercings (about 16 of them in my face) and drop the anime stockings and platform shoes, and keep my hair a ‘normal’ color (normal for me is not the same as a natural color) for a while. I had never been asked to do so, nor do I think they would have required that from me- it was a personal choice. At this point in my career I want my personality, my code, and ability to work in a team to define me not the shock factor of an outfit, clothes or piercings. I want to be Iris, not Iris with neon red hair.

Formalities

Matt had to kick me out of the car after 10 minutes in the parking lot. I was too nervous to go. ‘Who do I ask for when I get there?’ I asked. ‘Call Seb and ask him’ ‘I think it’s this Tim guy, Seb DM’ed me about him last week, let me check the surname’. Seb, short for Sebastien, is another developer at CTM, Technical Lead, and a friend I had met at various software development conferences. He has a brilliant mind and inspiringly passionate about software development. He also is quite fab at partying and we had emptied a few bottles the week before as I had called in panic mode over the culture shock moving from a big city in Sweden to a tiny little town in UK.

I awkwardly walked in to the main building and before I had opened my mouth the receptionist enthusiastically burst out, ‘Iris! We have been waiting for you’. In front of her a yellow post-it had my name on it and something scribbled down. She asked me to stand against the wall, and snapped a photo with a digital camera before handing me a temporary staff pass. ‘Tim will be with you in a second’. I spotted the espresso machine and cheekily loaded it with two loads and shot them like tequila. As I worked on my third shot I heard ‘Hi Iris!’ from behind me. I turned around and saw Thula, a CTM software developer. She had called me for a cooking hang out a week before as a part of the CTM effort to help me settle in Peterborough. We chatted a little bit before Tim came down and we had a chat in the cafeteria (where I worked further on my caffeine supply to attain the perfect caffeine to blood ratio). I was told which team I would join, the Home Team. CTM is an insurance aggregator and comparison site and has approx. 6 teams that together build up the site. In Peterborough we are 300 people, with maybe 150-200 of us in IT (majority of that being developer). When I had been in for the pair programming interview I had paired with Stuart (Stu) and he was on the Home team. Our team is responsible for the journey when a user makes a comparison enquiry.

I’ll write a separate post that details the code but let me share some details already now. CTM has a DDD architecture (Domain Driven Design). By the nature of this design a system is divided into areas of responsibility/logical areas that more or less work independently with some shared but clearly defined context boundaries. This is to allow for scalability, define responsibility clearly and to encourage good software design while still allowing for communication where needed.

‘So what can I expect from today? ’I asked Tim. ‘Well, I’ll introduce you to the team, get you set up and find somebody to pair with at some point’. CTM has gone all in on Agile principles and the way we work follow LEAN and XP principles- XP which stands for extreme programming encourages (among other things) pair programming. A way of programming where you work in pairs in different models, for example driver-passenger where the driver types and discusses with the passenger alternating on regular basis. It’s my favorite way of programming, and one preference I had when I was looking for a job. ‘But first, there is a company stand up at 9AM here so let’s stick around for that’. People started pouring in quickly finding their way to tables and chairs. The stand-up was as in good agile style over in 15 minutes after letting us know where we are, where we are going, practicalities and that we had a new person on board (me).

Stand-ups are daily team meetings where within 5-15 minutes (short enough to be actually standing) the team covers what people did yesterday, what they are working on and what they hope to achieve today.

We took the stairs up to second floor where my team had gathered around our stories board, a floor to ceiling white board with swim and stream lanes that had colorful cards on it (stories) that described things we had to take care of, sorted in columns by where in the process the story was (in process, ready to demo, ready for QA, ready for release, released). ‘You are familiar with storyboards?’ ‘I nodded ‘I have one on my fridge I laughed’.

After the stand-up I sat down with Stu and he walked me through a current story he was working on while answering some questions I had about the code base. ‘Do you want to drive?’ he asked. I hesitated with an uhmmm. I admitted to being rather confused and not ready to contribute to codebase yet. It would had been the perfect opportunity for a ‘I don’t have a driver’s license joke’ (which indeed I do not have) but I was a bit intimidated by the code and technologies used and surprised myself by being unusually quiet. Stu has previously worked for ThoughtWorks a company known for rather good consultants/software developers and he happily clicked clacked away on the keyboard fixing two tests before committing the code locally. We do test driven development- something usually used to refer to writing a test first and then the code to make the test pass. We follow this, but not in a strict sense. The tests are unit tests (tests a single behavior) or feature test (tests multiple behaviors) to verify intended behavior. At some point a light above the desks went red and Stu interrupted the team ‘Red build! Who broke the build?’ Everybody paused and looked up. We use Continuous Integration at CTM, which is a process where we continuously commit code to the code base on the build server. A service (in our case a system called GO created by ThoughtsWorks) listens for changes in the code base hosted partly on our Git server and partly on GitHub (as we are moving the code over there). When there is a change build steps are triggered, one of them runs the tests, another builds the solutions and so on. If something breaks the build is stopped and we are notified immediately. Nobody pushes or pulls on a red build until the build is fixed. This allows us to detect unintended behavior early on, obviously saving us costs, QA (the Quality Assurance team) for pain and much more. ‘We just ran the build again, nobody committed’ I heard from the corner. ’It’s green again Stu confirmed and we all went back to working, with Stu committing the code to the master branch. Committing is when you add your code to a codebase, it can be locally or remote.

Here are some blog posts on the topic:

Visual Studio Online setup speed test and guide: Continuous Integration and Deployment pipeline

Setting up a Continuous Integration and Deployment environment with Windows server 2012RC, TeamCity, GitHub, Azure websites, ASP MVC and MSTest for the absolute beginner

A little Continuous Integration Dictionary

Lunch came and went. I had been assigned a buddy, Anja (also software developer) and she had arranged a free lunch for Home Team, which I happily showed down convinced that I was starving beyond savior. After lunch I talked to my line manager Marc briefly, he had been busy all day in meetings and felt bad about it. ‘What do you want to do this afternoon Iris?’ ‘Well, to be honest, there is so much new. Coming from a XAML background, working mainly with native mobile applications, all this is a lot to take in. Would it be possible to get some time on my own to read some code and make sense of the codebase?’ ‘Sure’ He logged me in to his computer as we were still waiting for my login credentials and ran off to a meeting with a ‘don’t stress about it’ and a smile.

So where to start? At this point I was stressing about it. Who wouldn’t? I had no doubts that I would at some point, probably soon, get it- but right then and there my mind was overloaded with information. I decided that reading code and planning an attack plan would be the best way to go. I lowered the seat to tiny person height and pulled the UK keyboard towards me, sighing at the layout, and made quick eye contact with Stu as I was trying to locate the smell of peeled banana (we have free fruit at the office and everywhere you look you see devs happily munching on apples, oranges and the convenience favorite- bananas).

Getting familiar with code

Knowing that we had a DDD approach, used event sourcing, Mesaging and CQRS – three rather opinionated and intricate design concepts/patterns considered to be some of the more difficult ones to understand- I pulled out my notebook and wrote down those three words. Without understanding those three ‘things’ I would struggle to understand the codebase, so those would be apriority.

I opened up object browser and looked at the assemblies we used in our main solution. It was a rather long and intimidating list with few assemblies I had seen before. Going through them one by one I made a list of all the external libraries we used. I looked up the libraries quickly online to confirm that they were external libraries, what they did and to get an understanding of how dominating the library would be in the system. Some got a little question mark next to them indicating that I was unsure what we used them for, such as HTMLAgilityPack (which I knew was a screen scraping tool and I was pretty sure we didn’t do any of that), Nancy (a Sinatra inspired MVC framework) and TinyCMS. In total I had 23 libraries I would have to lookup. Priority libraries where: NEventStore, RabbitMQ, Mongo DB and the GUI tool, and a few more. Marc came back from his 2PM meeting and asked how I was doing as my unreadable notes and proof of raiding the notebooks and sharpies cupboard lay on the desk as evidence. I asked about the libraries, and the screen scraping tool was used by one of the browser testing tools, Nancy was used to simplify testing and TinyCMS was used for an internal part of the system. We agreed to do some more talking the next day as Michael came to the desk and indicated he was ready to go. He had offered to give me a lift so I could make it to the bike store before it closed to pick up my foldable bike (which Seb also had bought one of with the intent of biking to work more or less every day).

In the care we further talked about the code, and I admitted that I was a bit overwhealmed. ‘Don’t worry’ Michael said nearly giving me a heart attack turning left in a roundabout as I hadn’t gotten used to driving on the left side of the road ‘It took us months to get it as well’.

Back home in superman style I quickly changed to my PJ’s and lay flat in bed. I was so tired, mentally, physically, and any other possible way. The bike was shining bright in the living room down stairs, and the smell of old milk reminded me that I had forgotten to drag the grey bin outside for bin-day. I was going to buy food, clean, do laundry, and many more things. ‘Fuck it’ I texted Matt. ‘I’m skipping everything and will just watch some DDD training videos in bed and get some sleep’ ‘Good idea’ he wrote back. I started watching the DDD Fundamentals course by lovely Julie Lerman and Steve Smith. Julie I’ve met on several occasions and consider to be a friend, Steve and I used to work for Telerik and have also met a few times. I quite liked the interaction between the two, and made it one hour in to the course before falling asleep. Once I finish the course I’ll summarize what I’ve learned and share it on the blog.

I slept rather bad. My neighbors from Syria (which I thought was named Jose but it was Hussein) like to talk loud in the middle of the night, and it always sounds like there is 10 or more people in the tiny wall-to-wall brick house. On my shopping list had been new batteries for my noise cancelling headphones so obviously I was screwed. I had some weird dreams about DDD, and entities, with Julies voices in my head saying ‘Entities in DDD aren’t the same as entities in Entity Framework’. Honestly the codebase made more sense as I had watched some online videos and looked at a few diagrams, so after biking in to work with Seb the next day I had plenty of questions for Marc my line manager.

We sat down in the cafeteria after the stand-up meeting had finished and talked. ‘What is expected of me, short term, mid term and long tem?’ I wanted to know. I added that I was unsure at which point I should be actively contributing and how much time I would be given to familiarize myself with the code and how. ‘Usually we pair people up’ he said ‘..and when they are comfortable with driving they drive’. ‘I have a suggestion’ I interrupted ‘ Michael mentioned a new story he was working on where we are integrating an external service and will be more on the front end. He suggested I could pair with him, and I was thinking that I could do that and maybe set aside a little bit of time to make sure I understand our architecture at the same time’. Marc nodded and asked if there was something I was wondering about. I asked about the high level structure of the system. He pulled out a notebook and a pen, and I my surface and the pen, and he drew a diagram while I copied. This is, at a high level, how the Home Team system looks like. I will dedicate a separate post detailing this at a later point, and tie it in with some of the other concepts and design patterns I have mentioned.

After the diagram session I had some practicalities question, one of them was how much I could share on my blog and to others- for example the diagram. ‘Could I for example share the diagram?’ I asked. Marc was fairly sure, but wanted to have this confirmed and did so later. With every question I had he took notes and made little todo’s. The rest of the day before lunch was spent setting up my login credentials. After lunch which ended with an interesting discussion the Ferguson state of war in the US after a teenager was killed by a cop and protestors got teargased and shot at with rubber bullets. I noticed that Michael, another team member I couldn’t remember the name of (Steve?) and Marc had gathered around a third story board discussing a story. A part of the discussion was about the domain language. In DDD the language used is very important, if not center of the concept. Words/terms used should describe the domain not be tech terms. Our challenge was that we were the domain experts (not having a direct client), and we were techies so it’s rather easy to slip into tech terminology. I’ll ask if I can share the particular discussion. I joined the team member I don’t know the name of (I do however know that he bikes, has a wife and two kids, has a supply of painkillers and cookies) as a passenger implementing the feature discussed earlier. He walked me through the code just as Seb turned up ready to bike home. I changed, and did my best to keep up with Seb that was ahead of me in learning how to do turns on a 16’ wheels.

Back home I ran to the store so I wouldn’t have to suffer another morning without food, ironically ran into Seb again, and as I was cooking up some pancakes later (I had biked so I deserved them) I Skyped with my mother and horrified was told that I had forgotten her birthday (4 days ago) before watching another hour of the DDD course and crashing (AKA falling asleep).

Two days. 5 A4 pages. And still it doesn’t quite sum up how the two first days have been. I’m excited, a bit overwhelmed, and tired. Most of all I’m happy. Work has surpassed my expectations and I can’t wait to look back and feel a bit silly for being overwhelmed in the first place. Do you remember my Das Keyboard experiment? I’ve never been a touch typer and always looked down on my keyboard to write. I was annoyed with that and decided to get a keyboard with no prints. I then measured my progress with and without prints. The first few days I could barely write and I was so frustrated. But I kept going, forcing myself to keep going, and soon I had progress, and before I knew it I was typing without looking at the keyboard. When I switched from Swedish layout to US (VERY different) I was worried I would struggle just as much, but I learned faster and quickly had the same type rate and low error rate.

I think it’s the same with learning new tech and getting started in a team. So hopefully these posts will be a way to measure, qualitative rather than quantitative, my journey. And if you are a new developer, somewhat terrified to start a new job- maybe even first job- I hope these long posts help.

Dev at work: Starting at Compare the Market Meeting the team, formalities, XP, LEAN, DDD and CQRS

Setting up a Continuous Integration and Deployment environment with Windows server 2012RC, TeamCity, GitHub, Azure websites, ASP MVC and MSTest for the absolute beginner

A little Continuous Integration Dictionary

Comments