The first thing that can’t that needs to be mentioned is the attention to detail that must have gone into organising. When we signed in we got given a little notebook to write all our ideas from the day in, and a really well designed name badge.
Best designed name badge!
Having attended Droidcon London for the previous two days, where their name badges were plastic, hard, and pointy and caused much accidental pain if your arms weren’t clothed. This was a welcome relief!
Inside the name tag there was a place where we could write down which talks we were planning to go to, and where we needed to be. No more mass congregations at the session list board to check where to go next!
On the other side was a bingo board. The idea was simple, you had to find someone else who could sign off a square. Some were definitely harder to fill than others, but it was great in that it got different groups of people talking to each other!
Turns out everyone can imitate Christopher Walken on a various scale of terrible :)
Kicking off the day
The idea for an unconference, is there are no pre-determined sessions. Anyone who wants to run something, comes on the day, pitches their idea to everyone, and then picks a slot and room size based on interest.
I was really impressed by how many people pitched good ideas. Nearly every slot for the day had 3 or 4 workshops running, which meant some really difficult decisions on which to actually attend!
Jon)1. IOT puzzle gadgets using Lisp (
One of Jon’s project thats a programmed word game
The first session I went to was about how to program the Internet of Things using Lisp.
Although we didn’t get to see much of how to program the devices in the real world (such is the world of having the first session slot and IoT not working), but it was good to to see how Jon approached the problem, and how his Lisp code actually looked.
Part of the session was Jon explaining how different things are written in Lisp, a question that I apparently started off in the pub once asking about lists in Lisp. So hopefully we can go into more detail one day (for my own benefit) and write a joint blog post about it for beginners.
Finally, I learned that all answers to Lisp questions start with “Oh God”.
Next, I went to talk on Elixir. Another thing I’ve never used or have any prior knowledge on, yay!
Claudio gave a really good introduction into the language, introducing different programming elements by walking us through writing an anagram solver. I learn really well in this way, when what I’m being taught has a real application that I can see. So I learned a lot!
Something I liked with Elixir, is how essentially all you need to do is pipe outputs of functions as inputs to another function.
After a small break I went to a session on how to pair better.
This session started by breaking us up into pairs to discuss pair programming. We mostly spoke about all the problems we face; sometimes you just need time to fix something that you don’t have the time to explain, or maybe that there isn’t the opportunity to pair frequently. We then joined two other pairs to discuss our main themes, before then discussing as a main group.
I really liked this way of running because everyone gets to come up with ideas and speak, if only in their pair group and not feel like their embarrassing themselves in front of a bigger group of people with silly ideas.
Another reason I really super like codebar, is most other people don’t just talk about the problems, they like to find solutions too! So we managed to fill up a good portion of a whiteboard with suggestions on how to pair moar betterer! (Hopefully visible in the picture above.)
After lunch, I went to a talk on Docker.
I’ve been to many talks on Docker over the past year, and I still felt I didn’t “get it”. But for me, this was the session where things clicked. Denise explained well why Docker was useful, how it worked, and gave us good resources for where we could go to learn more.
One of the key benefits for using Docker, is to get around the “it works on my machine”. We could start up a virtual machine, for all the dependicies you might need to develop and then just provide the same container image to all the developers. If you start a new project, you can create a new container to make sure no dependencies clash.
With containers in the cloud it makes the cost of experimenting significantly lower if all the tools and dependencies are handled already!
For the final session of the day, I went to a session on how to give feedback.
This session was super interesting and had another different format to the other sessions. We began by suggesting ideas on the whiteboard with post it notes. After a brief explanation of each post it note, we got to vote on which things we thought mattered most. Each post it note that won the popularity vote got 3 minutes to be discussed on, before as a group we got to decide if we continued the discussion, or moved on to a different post it note.
Something thats been a personally issue for me is how often to ask for feedback; yearly feedback becomes too vague and not really actionable. I think the lesson here was to ask for feedback more regularly, and just send requests asking for feedback as you’d be surprised how willing other people are to help!
Another interesting discussion point was how do you give or take negative feedback when your a minority in the industry. Will that create doubt in the individual that they should even be there, and eventually leave?
After all the main sessions were completed, everyone congregated in main area again to hear from some lightening talks. A couple of people presented but there is only one that stands out to me several days later.
Beverly had remarkable bravery to stand up and give her first talk on her experience becoming a developer. Her talk was really well put together with how she started off in the Code First Girls program, and graduated to getting an internship with The Zooniverse. Which is really inspiring to anyone thinking of taking the jump into tech!
I really had a super awesome day, and I’m so glad I got the experience of uncodebar 2.
Something I kicked myself for not thinking about earlier was giving my own session. I thought about it halfway through the first day of droidcon, which happened the two days previous, and didn’t have any time to action those thoughts.
Something else I would have liked to do was run a workshop, much like how write/speak/code operates in The USA, helping others prepare to give a session. I think this would have been super valuable for people who hadn’t presented before in a supported environment. This will probably be an action point for me to take on next year. And I really hope there is a next year!