No long agendas, no boring announcements – just food, music, a speaker and their ideas.
You're guaranteed to learn something interesting whatever your background.
The job title is "software engineer", but you seem to live in meetings. You'd like to have time to code, but nobody else is onboarding the junior engineers, updating the roadmap, talking to the users, noticing the things that got dropped, asking questions on design documents, and making sure that everyone's going roughly in the same direction. Without those things, the team won't be as successful.
But now someone's suggesting that you might be happier in a "less technical" role. If I just described you, congratulations: you're the glue! If it's not, have you thought about who is filling this role on your team?
"It's just semantics." How many conversations about philosophy, politics and programming are derailed by this thought-stopping comment?
Semantics is all about meaning. If there is one thing we struggle with and need to get better at, it is the search for and clarification of meaning. The world in which a software system lives is filled with meaning. The structure, concepts and names that inform the code, its changes and the mental models held by developers and others business roles are expressions of meaning. The very act of development is an exercise in meaning — its discovery, its formulation, its communication. Paradigms, processes and practices are anchored in different ways of thinking about and arriving at meaning.
But just because we are immersed in concepts of meaning from an early age, and just because the daily work of software development is about wrangling meaning, and just because it's just semantics, that doesn't mean we're necessarily good at it. It takes effort and insight. Let's talk about what we mean.
The perception of data science is like this: You have some nice, tidy data, you use the latest, coolest algorithm, and you get some super clever results. You know it’s good ‘cause your r-squared value is through the roof, and you could play checkers on your confusion matrix.
But the reality is different. That nice, tidy dataset has to be wrangled out of a big, nasty production system. Those cool results have to somehow be translated into a user interface. And in front of that production system, entering that data, clicking on that user interface, is a data scientist’s worst nightmare: People.
As much as we might want to believe that data science is a pure “hard” science, about writing greek letters on chalkboards and stroking our chins, the truth is that what we do is more usefully thought of as a social science. Data science is a lens for understanding human behaviour. It is a tool for communicating with people. This talk is about how my background in Social Anthropology gave me a different approach to doing data science. Data science problems, I believe, are mostly about how to understand humans. Data is a soft science.
In 1903, Guglielmo Marconi prepared to unveil his world-first, long-distance wireless communication technology to the Royal Institution in London. He was looking forward to roaring success, scientific acclaim, and a string of wealthy new customers - but he didn’t count upon falling victim to the first hack in history.
This is a tale of business secrets, flame wars, stage magic, and magnificent sideburns, direct from the records of Edwardian England.
The talk highlights several of the lessons that the FLOSS and information security communities can still learn from the fateful events of 1903. Marconi’s tale is a master class in the necessity of open source technology, as well as being a delightful introduction to the art of vulnerability reporting.
The industry wide shift to agile has increased velocity and let us build software faster and get more immediate feedback, but maybe there is something we lost shifting from the waterfall model. James Ross covers tools and techniques that you can use to to help keep business analysis lightweight enough to avoid slowing you down but rigorous enough to make sure you are still heading in the right direction.
Through its first 40 years, the field of "Software Engineering" produced little that was useful to the software practitioner. That has led to a very peculiar situation: we have a field where the set of practices referred to as "engineering" simply doesn’t work well, and are deliberately avoided by the vast majority of skilled practitioners in the field. The situation is odd because, in other fields, the term "engineering" is reserved for practices that lead to success. As a result, the idea is spreading that perhaps software development is simply incompatible with engineering; that software developers are not, and never will be, real engineers.
Any field that mass-produces useful artifacts for people must take its practices seriously, and must approach them with an engineer's sense of responsibility. It's time to take a fresh look at what that really should mean for our field. With an extra 45 years of experience about the task of programming, and a broad survey of the varied different engineering disciplines, can we envision a future for a field of "software engineering" that is worthy of the name?
No matter if we're software developers, designers, product owners, managers, or work on software in any other way: our work has impact. But how is this impact constituted? What does it look like in practice? And which consequences does this have for our work on software today?
This talk takes you on a journey from the early days of computing, to debugging, to the technology industry, to our roles in all of this. It shows why we need to care about the social and ethical implications of our work, and highlights ways for us to approach these topics – by ourselves, and together with the people we work with. This talk wants to encourage you to think about your own role, your power, and your responsibilities as a person working on technology. You’ll learn what you can do to live up to them – and how you can help debug the tech industry.
Knitting and computing may seem completely unconnected, but they're very similar. Every beginning knitter learns that there are only two stitches - knit and purl. So knitting is inherently binary, and that opens up a world of possibilities for a coder.
Knitted fabric can be used to encode data in a number of ways, from QR code mittens to a fluffy red virus scarf. Patterns themselves become algorithms, and new syntax proposals allow for automated testing, compilers, and even visualisers. Crafters and programmers are working together in the burgeoning Maker scene to hack hardware, create innovative e-textiles, and push the computational limits of sticks and string.
Come along and see knitting in a new light, as a model of computing.
While the world is all VUCA (volatile, uncertain, complex, and ambiguous) often the project we’re working on or the people we’re collaborating with are just as VUCA!
Sensemaking tools help you deal with uncertainty and complexity in a practical and day-to-day environment. You could set up a framework instead, but how would you use it to lead a meeting or facilitate a discussion? How do you help others understand your environment so you can make decisions together?
Lynne Cazaly presents an entertaining and instructional session on the power of visual tools for sensemaking. You might have seen Lynne's visuals on Simon Sinek's 'Start with Why' or the popular 'Modern Agile' or 'Visual Agile Manifesto'. These tools help people digest complex information in a time where getting and holding people’s attention is challenging.
In this experiential session, Lynne will take you through practical skills for sensemaking and build your capability in visual thinking, facilitation, and helping people connect the dots through a short practical session. Leverage these skills to be one of those people that help get shit done!
Dave has been challenging management for years with ideas from Complex Adaptive Systems. More recently, he's been engaging with the Agile software development community.
Knowledge management is critical to software development. Applications evolve through the interaction between technological capabilities and unarticulated user requirements. This presentation will use insights from complex adaptive systems theory and the cognitive sciences to lay a foundation for a new method of thinking.
Are we really being Agile, or are we just stuck in our old ways?