-
Notifications
You must be signed in to change notification settings - Fork 14
Session Incubation
Got an idea or want to contribute to someone else's? Put it on this page, and put your session at the top of the following list, separated by horizontal bars (use --- in Markdown).
Hosted by Your Name
In this session we will be working on some amazing things. And talking a lot. You should be there.
Interested: A Pretty Cool Person, And Another, …
Hosted by Tom Oram
How will methodologies like TDD evolve with the likes of CoPilot and ChatGPT. A lot of the value from TDD comes from the process of doing, but there is no denying that "write the tests for this" can be a lot faster.
Interested:
Hosted by Tom Oram
Many of us put lots of effort in developing skills to find the right thing to build and to deliver the most value our users. So why have we not all created successful start ups? More seriously, how can we develop the capability to use our skills to build successful businesses for ourselves?
Interested:
Hosted by Tom Oram
Has the industry out-grown the expert crafters and does it just want competent production line workers? What is our purpose?
Interested:
Hosted by Chris Simon
Since Ward Cunningham famously introduced the Technical Debt Metaphor (a metaphor chosen not for its aptness but for its relevance to the project he happened to be working on at the time) it has been used and abused by technical and non-technical folk alike - to justify shortcuts, explain delays, to gripe, groan and grieve, sometimes all at once. Although he has attempted to clarify it is still a source of great confusion & frustration for many devs and businesses.
Martin Fowler's Technical Debt Quadrant is a helpful framing for encouraging folk to avoid 'reckless' debt, and to quickly pay down 'prudent' debt (deliberate or inadvertant), but despite his efforts the industry seems rife with 'loans' that will never be paid down, often so much debt that it seems impossible to deal with - and so it never is.
I propose a radical reframe of the situation - rather than 'debt' (which can be borrowed to gain leverage/speed), we should think of it in terms of health & wellness - or alternatively sickness, illness and disease. One can get sick due to bad hygiene (Fowler's reckless debt), but one can even get sick when taking precautions (prudent/inadvertant). One would never deliberately get sick in order to get somewhere faster, but one might take the risks of getting sick to do so (e.g. not wearing a mask) (prudent/deliberate). This changes the conversation from taking on debt to taking on risk of illness - with potentially disastrous & uncontrollable consequences.
I'd like to facilitate a brainstorming session to explore this metaphor further and see if it resonates and if we can start changing the conversation about this debilitating condition.
Interested:
Hosted by Chris Simon
Inspired by the concept of the Ubiquitous Language from Domain-Driven Design, I've been working for a while on an open source project called Contextive to embed domain definitions in all the places we work. It's started with the IDE (VSCode), offering auto-complete and hover wherever the terms are found (in code, comments, documentation, etc.) and am expanding to the places we have conversations - e.g. a slackbot that replies periodically with reminders of what domain words mean in a given context.
I'd like to demo this tool, explain its rationale, canvas ideas for future direction/features and invite collaborators to join me in building an ecosystem of tooling that supports this goal of helping developers better understand the domains they're working in.
Interested:
Hosted by Tom Westmacott
To some of us programming comes relatively easily. However others find it extremely difficult to get to grips with the basics of programming. In a world where the ability to write code is increasingly relevant and more and more people are interested in learning, this raises questions about the accessibility of programming and how it could be increased.
I have coached a number of colleagues new to programming, and am aware of my struggles to teach and some of their struggles to learn, hence my interest in these questions:
What are the best ways to teach programming to a newcomer?
- What order to introduce concepts
- Individual vs group tuition
- Supporting a student's 'eccentric' approach vs encouraging a more conventional style
What are the 'hard parts' of programming, and how could we ameliorate them?
- Use of '=' to assign a new value to a variable, statements like
a = a + 1 - [] and ()
- Pass by value vs pass by reference
- Expression evaluation order
- Calling a method for effect vs to receive a return value
- Loops and local scope
There is a possible follow-on activity to try to create a language/environment that implements some fixes to the identified stumbling blocks.
Interested:
Hosted by Amélie
I'd like more open space in my life and in the world. In this session we will look at an existing week-long open space conference in Finland: CodeFreeze and how the balance work between indoor and outdoor sessions.
We can then explore how one in the UK would look like (for example, Scotland? :) ) and what could be the shape of an edition 0.
Interested:
--> Next idea goes here <--