jpichon.net - Tech

ShipItCon 2024

2024-08-30T21:58:00+01:00

To avoid taking a year again to (fail to) put my notes together, I decide to do it quickly and stick to a few thoughts and highlights. The 2024 edition of ShipItCon happened today. This year's theme was "Flow." Many speakers mentioned ownership when talking about ways to reach flow.

I haven't attended many conferences in the last couple of years, but maybe 90% of the people I talked to were also meeting their co-workers face-to-face for the first time at this event, despite working together for years. At least three different companies. I found it interesting. It doesn't look like there are many opportunities for teams to meet outside of conferences at the moment.

DevOps Topologies 10 years on: what have we learned about silos, collaboration, and flow? (Matthew Skelton)

The speaker kindly summarised his findings both at the start and the end of the talk: decouple teams and tech (not just defining an org structure, something more dynamic), but diffuse learning across the company (that can take the form of Lunch and Learns, blogs, Communities of Practice, guides, etc...)

Reading recs:

Gene Kim's books (the Phoenix Project, Accelerate, ...)
SODOR, the State Of DevOps Reports

Organisation, Flow, and Architecture (Sam Newman)

What an incredibly dynamic and engaging speaker! The theme was generally how to reduce handoffs, which happens particularly when organisation are siloed.

Conway's law: An organisation design systems that replicate the communication structure of that organisation.

So if you have Taylorism-inspired silos with e.g. separate front-end/back-end/DB teams, the system will reproduce that.

The solution is feature-based teams (micro-services are good to enable full ownership). Durable as opposed to initiative-based teams are also better as long-lived teams make better decisions about trade-offs (e.g. incurred tech debt, etc).

Data Driven Decisions to Improve Testing Flows (Heather Reid)

Using data to take risks. Differentiating between reversible and not reversible risks. The speaker used various examples based on her own experiences to illustrate the principle.

For example: closing an old bug to remove noise is easily reversible if it turns out it shouldn't have been closed.

If 1000s of users report a problem, it can feel like millions/all of your users are hitting the problem. But maybe when you look at the data it's 0.6% of the userbase, which is still bad but not world-ending.

Or a really bad bug affecting 6 users using that phone model (out of millions) can probably be closed.

Prioritise accordingly.

Observability 2.0 and other things (Charity Majors)

(The title isn't on the agenda and I forgot to write it down!)

Tip for how to supercharge your career: join a high-performing team.

Engineering should own the code in production.

Observability is a property of complex systems.

Observability-driven development means looking at your dashboards (as opposed to waiting for alerts/paging to bring them up). It's a constant conversation with code (including unstructured logs, not just metrics, because they provide CONTEXT). (Higher level: structured logs with trace ids you can follow end to end.)

Establishing a culture of ownership and observability at Phorest (Paweł Malon and Paul Dailly)

Interestingly, the speakers use Honeycomb which is the observability platform of the previous speaker. It was like seeing practical examples of the concepts detailed in the previous talk.

The theme of engineering owning the code all the way to production came up again.

And also, of linking engineering workflows to observability: deploying a change and seeing what difference it makes, and conversely using the insights gained from observing software behaviour on prod to find new bugs/improvements.

Having a lot of metrics does create issues with the cost of storing all of that data, which is where sampling helps, although the speakers talked about the other problems you then have to deal with when sampling and how to manage them.

Go With The Flow? (Vessy Tasheva)

Play is a component of flow. Venn diagram of Play and Environment with Flow where the circles meet.

Environment: must be safe even if there are constraints/discomfort. E.g. a leader having your back when working on a challenging project.

Play is a way to be more authentic and creative. "Being" (which respects focus time) vs "Reacting" (which breaks flows and creates defensiveness).

Flow-etry in Motion: Navigating Cascades of Threat Data (Claire Burn)

Interesting twist to the talk! When the speaker submitted it, it was supposed to be about how their pivot to using Kubernetes and Google Cloud Platform enabled better flow in the team. But by the time the conference happened, they had reverted back to AWS and EC2!

There was no "peak flow" to be found because Kubernetes wasn't the right tool to solve their problems (they needed finer grained OS control).

Considerations around Learning Curve vs Velocity, especially when working as a smaller team (4 people). The management debt became too much.

They did end up keeping Kotlin from this experiment, good for integration with other Java projects in the company.

The impact of Flow on various aspects of work (Panel discussion)

Beat Saber as a way to get into flow 😂

Distributed teams are good for making the implicit explicit. Managing based on outcomes. The additional flexibility is good for everyone.

Honeycomb has a quarterly "everyone works from home" week, up to the CEO. It's good to get distance from processes, etc. (I thought that was a refreshing contrast to all the Return To Office talk from the last couple of years.)

Many problems are socio-technical: need a combination of tech and people solutions, not just one or the other.

Harnessing Developer Insights to maximise flow (Mihai Paun and Alma Tarfa)

Learned helplessness in companies: "we've always done it this way" "that's never going to work here."

I really liked the picture of the Iceberg of Ignorance, from Corporate Rebels:

Papercuts affecting flow tend not to surface in retrospectives.

Solution: Plan - Do (gather data) - Check (target condition) - Act

For example, they found their dev team struggled to reach flow state because of the number of meetings, so they decided to try setting up two no-meetings day (Monday, Wednesday) then gather data to see if that helped. Everyone involved in the four steps.

Small changes toward reaching the bigger goal.

Leaders: be gardeners, not mechanics.

From MLOps to AI Systems (Jim Dowling)

Most AI systems don't ship. This hasn't changed in the last few years.

MLOps, LLMOps. He explained when he teaches a ML course, his students complete an AI project from scratch in 2 weeks. It doesn't need to be as complicated as 30+ steps diagrams/consultants make it out to be.

While looking for a link to the course, I came across this detailed article that goes into the details of the talk if that is of interest. And includes a link to the students' projects.

Finding personal flow (Patrick Kua)

Personal flow usually comes from:

adding value
learning
having a lot of ownership (with support)
a sense of progress
applying the team's strengths

The speaker used past experiences to illustrate various kind of very different environments that can lead to good flow. This actually linked back nicely to Vessy's earlier talk as well: challenging projects but in a safe environment/with support.

One of the anecdotes I liked was when he was trying to remove himself as a bottleneck in a large project, he broke down the features, and asked if anyone would step up as feature leads for each of those. People had no problem volunteering and that also links back to ownership again. And feature-based teams.

The disadvantage of putting up notes early is that the recordings are not yet available!

ShipItCon 2023

2024-08-28T20:12:00+01:00

With ShipItCon 2024 fast approaching (in 2 days!!), it's time for me to admit I will never finish writing up my notes from last year's and just post what I do have. Perhaps this year my note-taking skills will improve?

ShipItCon is a small non-profit conference in Dublin that focuses on Software Delivery. The conference is a single track on a single day, and the theme in 2023 was "The Unknown" (observability came up A LOT!). Here are of a few of the highlights, from my perspective (and from my very, very partial notes).

The 2023 recordings are available now.

Keynote: Dr Norah Patten

Inspiring journey to become Ireland's first astronaut! Also very impressive and massive amount of outreach work. Including writing a children's book, Shooting for the Stars!

I liked how she broke down several stages of her life into categories: Influences (e.g. teachers, family) / Role models / Peers / Experience (e. g. a visit to NASA as a child), and how each contributed and came together to allow her to come to where she is, now.

Some cool outreach projects I didn't know about:

Using Nanoracks, students plan experiments for astronauts then examine the results.
PoSSUM 13 for researchers, and the microgravity challenge for payload experiments in space/suborbital/microgravity. High school students apply with detailed plans of the science experiment they want to run, and if successful get to build the payload themselves with mentoring, etc.

What's Slowing Your Team Down? (Laura Tacho)

After observing hundreds of teams, the speaker found that every team has the same problems, divided into three categories: projects, processes, people.

The speaker uses thousands of metrics to determine issues. Tracking doesn't solve the problem but it helps with tracking progress as well as "quantify sentiment" which I found really interesting. In general, I found this talk incredibly informative and valuable, and I recommend the recording.

1. Projects

Too much work in progress

This is the biggest problems for most teams. It causes issues with getting things done or finishing things.

Measures that can help: number of projects per person (engineer cognitive load), ...

Lack of prioritisation

No means "not now"; yes means "forever" (with an every increasing maintenance cost).

The goal should be specific enough that teams can easily say no to things.

2. Process

Slow feedback (from people or machines)
Not enough focus time

Length and frequency of focus time chunks, number of meetings where something is actually at stake, ...

3. People

Unclear expectations

Giving expectations vs fear of micromanagement.
Receiving expectations vs fear of seeming incompetent, psychologically unsafe teams.
(How this can set up a negative circle where one lead to the other and back)

Reading recommendations: "Accelerate" (about DORA metrics), the SPACE of Developer Productivity, DevEx: What Actually Drives Productivity (interesting, although at least one of the main author is selling something related).

I imagine the recording is available now, and the slides are also interesting for a more detailed summary with many more examples of measures for each category, and a link to the kind of developer survey they used to "quantify sentiment."

Building scalable GenAI Retrievial Augmented Generation Platforms (Mihai Criveti)

LLM and their limitations. Text generation, doesn't learn from interactions, AI function to predict the next word, doesn't access the Internet.

Models with 70 billions parameters cost $20k/month dedicated GPU instance on Amazon.

Slides with more information on this works and the limitations the speaker found.

How to Make Your Automation a Better Team Player (Laura Nolan)

This felt particularly relevant to my work. The talk was really engaging because the speaker always links every issue back to famous incidents or incidents she personally experienced. The slides also include these examples.

"Joint Cognitive Systems" where computers and humans collaborate on cognitive work.

Paper recommendation: Ironies of Automation by Lisanne Bainbridge. 40yo paper and these problems still haven't been solved!

The problem described is like this:

The easy stuff is automated first
New people only ever learn the hard stuff, and develop a partial mental model of how things work
Life becomes harder for operators because they need to learn both how things work + how the automation works.

We are doing a bad job if the operator can shoot themselves in the foot with our tools.

Two anti-patterns to avoid!

1. Automation surprises

Automation through using a lot of scripts, tools, cronjobs is hard to manage. Centralising into a self-running/autonomous automation helps, where possible.

The behaviour should be as simple and as predictable as possible.

Unattended upgrades are a bad idea, silent and deadly.

Incident examples (although there are many! Linked in the slides, all informative):

A routine GitOps operation (link now defunct :() that caused a namespace to be deleted when ArgoCD system lost visibility on the yaml, bringing down the entire site.
Unattended upgrade disaster at DataDog

2. Recommendation systems (e.g. to assist in troubleshooting.)

They make it harder to generate alternative hypothesis. Using softer language may help, like "in the past, problems like this were caused by X."

Tools as amplifiers: help with understanding systems, as opposed to providing suggestions. They shouldn't hide complexity. Help operators to build a mental model of the system.

The slides include links to more advice and lots of incident examples.

And that's it, because the talks were too interesting and I'm apparently unable to be concise when taking notes. The conference is really excellent at inviting deeply knowledgeable, deeply interesting speakers, and I'm looking forward to the next one. Thankfully I won't have to wait long ;)

Extracting reviews from Goodreads into Markdown pages

2023-05-07T11:00:00+01:00

In early 2020, it became really difficult to read books. I'm slowly starting to get past that at last, but while Goodreads was super fun for a few years, right now tracking and counting and rating just makes reading feel like a chore and Not Fun as a hobby.

I still would like to keep a record of what I read, though. And I used to write book reviews on this blog before getting onto Goodreads. It seems like a nice way to keep a record of what I read without it becoming a number thing. I'll probably still write Goodreads reviews for small authors since I know it can help, but I feel less pressed about having everything there.

I also wanted to save the reviews I wrote only on Goodreads here, and wrote a script to migrate my reviews into Pelican-friendly Markdown pages since that's what powers this blog now. I decided to keep to a single entry per year rather than one entry per book, since I had a few good reading years in there (and others will only a single review!)

Step 1: CSV export of the books

First, if you go to 'My books' and find the 'Tools' menu at the bottom of the leftside menu on Goodreads, you'll find a page to export your library. You may have to try a couple of times: my first export only had a handful a books, the second one looks more comprehensive although the number of books was off by two, but what can you do.

Step 2: Python script to create the Markdown pages

This is the script I wrote to extract only the books I've actually read. I don't really care about DNF (did not finish) and to-read, right now. I also hardcoded the years relevant to me. May someone find something helpful in here!

import csv
from dataclasses import dataclass
from datetime import date, datetime


@dataclass
class Review:
    title: str
    author: str
    date_read: date
    review: str
    rating: int


def get_reviews(year):
    reviews = []

    with open('goodreads_library_export.csv') as csvfile:
        reader = csv.DictReader(csvfile)

        for row in reader:
            try:
                r = Review(row['Title'],
                           row['Author'],
                           row['Date Read'],
                           row['My Review'],
                           int(row['My Rating']))
            except ValueError:
                # When the int() cast fails, usually it means the CSV is
                # corrupted for that line. In my case, it was for a few to-read
                # records so I ignore them rather than attempt to fix the
                # original CSV. You can print the row here if you want to check
                # what's failing.
                pass

            if year is None or year in r.date_read:
                reviews.append(r)

    return reviews


def rating_or_review(review):
    # If I wrote a review, return that
    if review.review:
        return review.review

    # Otherwise, make the rating into words.
    if review.rating >= 4:
        return "I really enjoyed it."
    elif review.rating == 3:
        return "It was fine."
    else:
        return "Wasn't for me."


def format_reviews(reviews, year):
    with open(f'book-reviews-{year}.md', 'w') as f:
        f.write(f"Title: Book reviews: Year {year}\n")
        f.write(f"Date: {datetime.now().isoformat()}\n")
        f.write("tags: book review\n\n")

        for r in reviews:
            # A couple of abandoned books sneaked in with a '0' rating, and I'm
            # not interested in preserving those
            if r.rating != 0:
                f.write(f"## {r.title} by {r.author}\n\n")
                f.write(f"{rating_or_review(r)}\n")
                f.write("\n")


for year in range(2013, 2023):
    reviews = get_reviews(str(year))
    # Chronological order
    reviews = sorted(reviews, key=lambda r: r.date_read)
    format_reviews(reviews, year)

The hardest part was probably to decide what text to convert a rating into, since I didn't want to keep numbers!

Step 3: Checking the output looks right and recalling fond memories

I used the 'Year in Books' pages on Goodreads to compare the results. There was some funkiness sometimes, like a book read in 2011 showing in year in books but without any shelves and a date read showing as 2020, even though I don't remember messing with it. The review also shows as Jan 2020 on the Goodreads UI despite appearing in the correct 'Year in books'. 2020 turned out to be date_added (which is definitely false) while the date_read field is empty. Maybe some data migration funkiness on the Goodreads side at some point during the last 12 years. Otherwise, a duplicate once, and a couple of intra-Goodreads links that didn't work.

I still have to clean up the file for 2022. I was getting annoyed with tracking myself so I didn't write reviews, but if it's for the blog I wouldn't mind adding a few notes. And I need to decide if I want to post my 2023 reviews as I go, or batch them in some way!

Moving to Mastodon

2022-11-22T20:22:00+00:00

Three years since my last post, haha. And a couple of hardware failures in the meantime, too. Let's see if I remember how to get set up with Pelican.

I dropped off Twitter a while back, but Mastodon is giving me hopeful vibes (could just be the "new-to-me site" feeling, of course!). Either way, wanting to add a link to my Mastodon profile and get rid of the Twitter one has motivated me to dust off this repository.

It feels nostalgic to see a RSS feed link in my footer. I suspect I'm not the only one hungering again for a more decentralised web again. Or more like, it never went away but it got a lot less visible.

I've got some notes from EuroPython (it was in Dublin \o/) I'll dust up soon, and maybe I can start publishing my notes on the meetups I go to now that we're all allowed outside again. Get back in the blogging habit... It could happen!!

My apologies to long forgotten Planets this may appear in, haha, remove this blog freely!! Tags have their own RSS feeds as well (open-source, etc).

No plan to add back a commenting section but feel free to chat on Mastodon.

UXDX 2018

2019-10-07T07:24:00+01:00

Whoops! Clearly I'm never going to finish writing up my notes for the conference last year. Better post what I got even if incomplete, before the next one begins :-) I couldn't get a discounted ticket this year and won't be attending. Have fun, everyone there!

I was lucky enough to be able to attend UXDX this year as well, thanks to a discounted ticket and my employer kindly allowing me the day off. The venue was again the RDS, with the lovely room that's lined up with actual real books.

UXDX is an interesting conferences, that aims to bring down barriers between User Experience and Developer Experience people. The conference has expanded this year, now covering two days. I was happy to see some issues I had with the conference last year resolved. For example, although the stated goal is to bring together UX and DX people, improve collaboration, etc, the tracks were completely separate. Worst for the DX-centred talks, the "room" was a stage at the back of the exhibition hall and all the noise that entails. This year, the separation between the two tracks was labelled "Vision" and "Execution" which made it easier to have talks mixing everything together, and also the Execution room had a proper room with doors that close. The room was larger than the section assigned last year too, and always full whenever I peeked in. Both tracks were always busy. The exhibition hall seemed pretty empty outside of the breaks, but there were plenty of those - staggered to lessen the lunch/coffee rush.

There was a handful of talks I was looking forward to, some met my expectations and others turned out different. Many other good surprises. I'll summarise some of the talks I enjoyed the most and only include my key takeaways for others. This doesn't mean any of it was the actual point or meat of the talk, more like the insights that were new to me personally and that I'll be ruminating on.

Day One

Micro Frontend Architecture | Luca Mezzalira (DAZN)

I started the day in the Execution room (it sounds a bit dramatic phrased like this) and didn't really know what to expect with this talk, but it may have ended up being my favourite one. The speaker stated his problem clearly - how to make it work with hundreds of distributed developers/teams - and also noted that the solution he came up with challenges common software development wisdom, but to keep an open mind.

The idea is to share absolutely nothing. Not even a button. Don't create a library of shared components, like headers. Really, how often does your header change anyway? Trust your developers. They can duplicate and maintain this. The goal is to minimise dependencies. Don't centralise.

The rest is structured based on "Domain-Driven Development." Each team has their own domain (e.g. Catalogue, Subscription, Payment, ...) and completely independent technology stack.

The benefits:

Quicker on-boarding, because you only need to understand your own domain deeply
Easier to scale teams
Freedom for developers to innovate and own something end-to-end

He also mentioned the positive impact on turnover. In London, it's apparently not uncommon for developers to change company every year, year and a half. This makes it easy to try new technology which is often the main reason to jump ship.

There are frameworks that enable this nowadays, like single-spa and frint.

Planning your Agile Architecture | Will Demaine (Fat Llama)

This was an excellent talk, and well delivered as well. The speaker described the steps you may want to follow to modernise your application and enable a more agile architecture, from lessons learnt first hand through different companies. If I had to undertake a project like this I think I'd find the slides or recording again to refresh my memory first, but for today my key takeaways would be that this is a long process that you want to tackle iteratively, so that you can continue to deliver business value along the way. No one will let you just take off and deliver nothing new for 8 months while you rewrite the thing from scratch.

Have solid foundations in place (monitoring, feature flags, ...) before starting. Take your time and do it right the first time or they won't let you migrate more services!

Another point I found interesting: create a gateway for the clients, the things that you can't roll back like mobile apps. Even if it's just a proxy to start with.

Embracing empathy | Tim Hudson (Adyen)

Pie charts bad. Bar charts good.

(Also, look into the Design Sprint / Design Sprint 2.0 books.)

Solving Problems to Build a Compelling Product | Deborah Clarke (Cartrawler)

User research is vital but not the only important thing. Combining with other incentives can lead to better focus and great breakthroughs. Innocuous, small moments of delight can increase your conversion rate.

A Journey from Complexity: Reducing Technical Debt | Fabrizio Fortunato (Ryanair)

Interesting to follow the evolution of the RyanAir front page over the decades! Some tidbits I found of interest:

Impact of page load. Any speed increase has a direct impact on revenue.
They use "micro-pages." Concept similar to micro-frontend except it relates to full pages, each page is its own app. So everyone is only responsible for their own page independently, and loosely coupled. Single SPA per page, that can be released independently but still has shared components (interesting contrast with micro-frontend above).
They eventually wrote two different apps for mobile and web, as optimising for one over the other never quite worked and only served in increasing complexity. Now optimised for each flow. Still haven't decided whether to use mobile or web format on tablets.
They use GraphQL, serverless, Brotli.

Design and prototyping | David Hoang (One Medical)

Prototypes should be low cost and provide high insights. The goal is learning. Having a prototype together with a vision/roadmap is powerful.
"Validating" a prototype or design is about gaining insights. About learning. Not about proving something right or wrong.
Design is not magic, it's a rigorous process.
Include User Testing in every sprint.

Prototyping is successful if you get insights that provide value to your user.

The examples related to medical applications were compelling. From paper (e.g. stuck onto a 3d printed watch model, to test for smart watches ahead of releases), to powerpoint, to node-based prototyping, to Figma.

The tools we use: Challenging dogma in the design process | Emmet Connolly (Intercom)

Tools influence output, and can even generate trends.

Use these tools and remain sceptical, don't let the tools push you around and end up with a design monoculture (noticeable in the history of the web).

"Design Ops" - a concept I hadn't heard of.

Ensuring the Success of your Remote Engineering Team | Panel

I really liked that the conference kept the talks to 30 minutes, but I think that's one case where it would have been better to get an extended timeslot, maybe 45 minutes. As it stands even with only two panelists (+ one moderator) we barely had time to scratch beyond the surface.

Keeping a budget for internal face-to-face interactions, some kind of annual get-together has a great impact on morale and engagement and pays for itself.

The cost of saving on office space is not the point (numbers like €17,000/person in Dublin, €11,000/person in Sligo were mentioned). Talent is the point. Working remotely helps to attract and retain people.

Onboarding strategies were briefly touched on. One of the companies hires mainly senior people with 10y+ experience while the other also hires new grads so the strategies are different. It's great if you can get people to HQ for this, makes sure they understand the company's values and culture, and also the tools at their disposal.

To keep people connected, having non-work related communication channels like a #showyourdesk Slash channel or "whose view is better this week?" can help.

Time zones are a challenge for global meetings. Some expectation that you will go the extra mile for the business, since you are not tied to a regular 9 to 5.

There were concerns about working from home and whether people are really working. In general the opposite seemed to be a concern for the panelists: when people work from home you can't see the black bags under their eyes, or if people are stuck. People know working from home is a privilege and work hard to prove themselves. One of the companies measures employee productivity to make sure they don't burn out - though you have to be very careful about how you measure people.

The secret sauce is flexibility. Work is only one part of life.

How about accountability and self-determination? Decisions should be made by the person who needs to. Empower people. Get that right. Measure what you want success to look like.

With regard to people not contributing, teams are tight and it becomes obvious who is and who isn't. You do need to be more proactive in searching for information with remote teams. One-on-one meetings every two weeks to touch base. They are still refining the process. Seven seems to be a magic number, you can see if people are performing for any type of team.

Accessibility | Brian Dalton (Aer Lingus)

I missed the beginning but seeing how a user who relies on accessibility features uses a computer and navigates the Internet is always powerful. Lots of work to be done still.

From keyboard to navigation to simple, silly things like "times shown in red are not available." Label your fields.

Five phrases that shout your agile isn't scaling | Tony Grout (Atlassian)

The Agile manifesto 17 years ago didn't talk about how to scale it! From 17 to 70000 people.

Some interesting suggestions that challenge conventional wisdom. My favourite: it's well-known that smaller teams are more productive. Studies have shown that teams of 9 to 16 people were 6% less productive than teams of 5 to 9. However, if you decide to make 2 teams instead you now have twice the unpredictability because you've added a dependency on another team. Think carefully, run the experiment to see if bigger teams may be better.

Encourage people to think about "teams" over "team." For example, if the UI team is currently the bottleneck, instead of engineering twiddling their thumbs or overengineering something while they wait, perhaps they could create tooling to help the team. That slows them down and helps the other team.

One team working faster can cause everyone else to go slower. For example, a UI team wanting to be pixel perfect.

Those closest to the problem should make the decisions.

Kessel Run: A Digital Transformation Story within the World's Largest Bureaucracy | Adam Furtado (Kessel Run / U.S. Air Force)

An interesting choice for a closing keynote for day one.

The transformation described is absolutely incredible. The speaker spent a fair amount of time at the beginning to explain the current state of things, years/decades of risk aversion leading to becoming unable to adapt to change and thus less safe. Twelve to fifteen years to go from an idea to something in the users' hands, 96% of project behind schedule or over budget, 40% never delivered... They went to Pivotal, who helped them to learn about modern software development practices, devops, etc but more importantly how to change the culture. Now deploying is a non-event and they went from 10 years to 120 days for delivering.

It's truly inspiring and the project they presented as an example showed the real-world benefits: allowing soldiers to stay safe at home and with their family rather than go on months-long refuelling missions around the world, thanks to streamlining the refuelling planning process with software. Definitely a worthy goal.

It was however a bit strange to hear about software described as a differentiator and weapon to cultivate on the battlefield, and how to improve warfare. I suppose keynotes are meant to make you think rather than just give you warm fuzzy feelings, and this talk sure fit the bill!

Day Two

Was just as interesting, too bad I left it too long to get the rest of my notes together.