I was lucky enough to win a ticket to this year’s YOW Conference, thanks to Girl Geek Dinners Sydney (http://www.girlgeeksydney.com/)!
I thought I would post up a quick summary of the sessions I attended before I forget, so here’s my summary for YOW 2012, the Sydney version.
Keynote – The Practical Science of Batch Size – Don Reinersen
I was a little late to this one, but the guts of the presentation was about optimising the size and timing of when you deliver ‘chunks’ of code, or features, or stories, or whatever you call a block of work. An example I saw that seemed to best explain this one was the production of a set of drawings. The example compared a delivery of 200 drawings every 10 weeks compared to 10 drawings every week – the designers would get faster feedback from the reviews and be able to better remember what they were doing/thinking at the time of creation, rather than trying to recall 2 months later what it is they did and why. Additionally, putting in place a weekly review meeting also means less overhead (transactional cost) of scheduling the meeting and reviewing each drawing. The weekly meeting could just be a meeting every Wednesday at 2pm.
He also mentioned “Slack” in a production system (mentioned a book called Slack too) – when there’s slack in the production line, that time can be used by the developers to improve and lessen the bottleneck that is causing the slack (for example this could be the tester in the case where there are more developers delivering stories than there are testers who are able to test them). Slack is usually the direct result of a bottleneck in the process and that time should be used wisely to fix the bottlenecks, or at least widen them so things flow better.
Zach Holman – How GitHub Works
- GitHub employees have a lot of trust, they can work from anywhere
- No managers
- Travel is important, you learn, and expand your mind in ways that allow you to think differently
- Pull Requests are used as a trigger for code reviews, instead of interrupting someone to get them to check your code, the pull request can be reviewed asynchronously once that person has time
- IM’ing is asynchronous communication – you respond when you aren’t in the middle of something so your flow isn’t interrupted
- Face to face meetings result in a loss of information – it’s not recorded anywhere and only the people in the room know what the meeting was about, whereas if the communication takes place over IRC or chat, then it’s recorded for posterity and is searchable
Dan North – Embracing Uncertainty
If you say you’re scared, you’re looked down upon in business. But if you say that you think something is risky, you’re considered a good manager or employee. They are basically the same thing though. Humans are fearful, and we don’t like uncertainty.
Dan spoke about “Three Ages – A Model of Growth” with regards to learning new things. The first stage is called “Explore” – this is where you’re trying to get your head around something and maximise your discovery by experimenting. The second stage is called “Stabilise” where your goal is to minimise variance – in a build process this would be, for example. producing the same binary each time you run a build. The third stage is called “Commoditize” where your goal is to maximise your efficiency (maybe script it all up and make it reusable, or create a library other people can use).
He mentioned BBRT.org which relates to a story he was telling about a company that allowed everyone in the company to spend money on whatever they thought they needed to get their job done (so long as they could justify it), and were told to spend money like it was their own, this empowers people to make decisions.
Aaron Bedra – Ready Set Clojure!
I think this talk started off well, but when he skipped over to explaining a number of functions and language syntax, a lot of the audience seemed lost. The example was interesting – writing a library to connect and send commands to Redis.
Keynote – Cool Code by Kevlin Henney
Great presenter, very engaging and funny, he had the crowd laughing a lot. He basically went through a bunch of interesting/cool code examples. I think the one I liked best was a piece of self-modifying code written by Yusuke Endoh which would print a map of the world out, using the characters of the program itself, and every time the code was run, it would rotate the map by a certain number of degrees. He also mentioned the Practice of Programming book and talked a little about mutual recursion.
I found this talk pretty boring, the presenter wasn’t particularly engaging and was quite flat unfortunately. I only got a couple of things out of the talk:
- Conway’s law: the structure of your codebase will reflect the organisation structure and how it works
- Logging should be an outcome of purposeful design, it should be clear what an when things should be logged.
Bjorn Freeman-Benson – Some Considerations for Scaling: What We Did At New Relic
Bjorn is a great presenter and you can tell he really knows his stuff. One of the things I picked up from this talk was around the way they ‘roll-up’ their masses of stored data in the database – they basically have a table for each hour of the day, so at the end of each hour, all they have to do is select all the data, process it, and then drop the table (or delete from it). This was done to overcome problems they had when data was stored in a single table – they found that the delete SQL command would lock the entire table, resulting in a bottleneck because there were still writes that needed to be done at the same time.
The other thing I found interesting, and is something I am planning to implement in my own screen scraping application which is currently under development, is what I’ve called ‘compute caching’, which means running computations across the stored data in a background process and caching the result in a table, so instead of customers requesting the information and being slowed down by the time it takes to run these computationally expensive calculations, the calculations are already sitting there cached and ready to display. Of course this depends on how fresh the data needs to be, but is quite useful when the calculations don’t have to be accurate to the current second/minute.
Bjorn also spoke about how they use a relational database like a NO-SQL database – essentially creating a B-Tree index. He also mentioned determining whether random read/writes or sequential read/writes best suited the way their applications worked – this also depended on whether they were using SSDs or not. He also talked about sharding and that they used direct access storage (as opposed to networked) which apparently resulted in a significant performance improvement.
Eric Meijer and Brian Beckman – The Story of the Teapot in HTML
Keynote – The Most Important Minute of Your Life – Mike Lee
I think I expected this talk to be confronting/emotional, but it had quite a big impact on me. Things that stood out most:
- Do something that matters to you, if you’re not doing something that’s important to you and/or the world then you’re wasting your time.
- What is your purpose in life? Can you explain it to someone in 60 seconds or less? Remind yourself of your purpose and have this focus every day. Be able to sum up succinctly who you are and what you do
- If you died tomorrow, what would people say about you ‘she was an engineer, she was a wife’ – is that how you want to be remembered?
- If you were to die tomorrow, would you be able to look back over your life and feel happy with it, or would you have regrets?
- What are you doing to make the world a better place?
- “I’m just doing my job” is not an excuse, it’s not good enough, don’t sit there and watch your life go by, avoiding responsibility.
- Remind yourself what you’re doing with your life, in your company, with your day
- Being able to speak in public is important, you need to be able to communicate to others why you are worth being paid for.
- You can’t think about something you don’t know about. If you don’t know what something is, you can’t think about it, i.e. – you don’t know what you don’t know.
I think the most important question Mike asked was: “What is your purpose?“. This is something I believe we all need to find the answer to.