Jay Fields's Blog, page 7
June 12, 2012
scheduling, travelling to, and dining at speakerconf
Convincing 20 industry leaders to set aside 4-5 weekdays to come to a conference is not an easy thing, especially when said conference is also very hard to describe to the person (or people) who are approving the time off, travel, & expenses. With this in mind, Josh and I designed speakerconf to appeal to programmers who work very hard, and are often on the road.
Weekdays. I strongly hold the opinion that conferences should not be on weekends [more info]. Most of the people who attend speakerconf work very hard on an average week, and I don't want take a weekend away from them, their friends, or their family. I'm a very firm believer in work / life balance, and I don't want to be part of tipping the scales even farther in the 'work' direction. Additionally, it makes sense as a conference organizer. I want people showing up to speakerconf rested, refreshed, and ready for several days of intense collaboration. It's not enough to give a great presentation at speakerconf, you need to be on your game for 10-12 hours a day and you need to be able to do it for 3-5 straight days.
My opinion is not universally held - some people can't or don't want to be away from the office for that many days. While I see their point of view and note the benefits of switching to starting on Sunday, I simply don't believe that the trade-offs are a net win for speakerconf. Therefore, the best thing that Josh and I can do is ensure that speakerconf is such a "don't miss" event that people believe it is unquestionably worth being out of the office for a week.
Select an easily accessible location. Easily accessible has always been a requirement of mine for speakerconf. Like I mentioned, speakerconf presenters are often on the road - the last thing I want to do is require an additional connection or an extended drive. Aruba is a direct flight from many cities in the US, and the speakerconf hotel is a 15 minute drive from the airport. Aruba was great for the first few speakerconf events; however, when Josh and I created speakerconf we never anticipated that we would draw so much interest from people in Europe as well. Sticking with our ideals about easy accessibility, speakerconf now rotates between a location that is a direct flight from most US airport hubs and a location that is a direct flight from most EU airports.
Select an isolated location. Running a speakerconf in Rome really drove this point home - last February I asked if 2013 should be in Austin, SF, NYC, or Aruba. The majority preferred Aruba, and, more importantly, those that preferred Aruba were also the ones who were most excited about returning in 2013. Many presenters pointed out that if we were in an actual city they would be more likely to be distracted. The final dinner in Aruba proved their point. In Rome in 2011, 1/3 of the presenters went out to dinner* on the final night. Conversely, in Aruba 17/18 presenters went to dinner and all 17 continued their discussions at the hotel bar for many hours following dinner. The isolated location provided fewer distractions, and seemed to facilitate much deeper interactions.
Select a location with a concentration of restaurants. speakerconf takes a very different approach to dining. Josh and I aim to not only host an amazingly educational event, but to also provide the best dining experience of any conference. We don't provide conference center food for breakfast or lunch, instead we select hotels that are near great local restaurants that serve reasonably priced breakfast and lunch options. Dinners are done at some of the highest rated local restaurants - and we require the ability to select from several different options.
Dine well. Josh and I love food & wine, and our preferences definitely show in our dinner selections. The conference sponsored dinners at speakerconf are generally at restaurants that I prefer to take my wife to when we visit those cities on vacation. The dinner wine selections are usually done based on what Josh has loved drinking in the past. As an example, the conference dinners in Munich are at Boettners & Vue Maximilian, the number 1 & number 3 rated restaurants in Munich according to zagat.com. I could go on and on about the type meals that we aim to provide at speakerconf, but sometimes a picture truly is worth a thousand words - here are the 1,000 that describe a dinner at speakerconf.
Group dinners are better if you split to tables of 3-5. Many people loved being part of a large, group dinner table, but the conversations did suffer a bit. In 2011 we began making dinner reservations for "a party of 20, but we would like 5 tables of 4", and the conversations became longer, deeper, and more productive. As a side benefit, the restaurant staff seems to find this easier to manage as well - which means less issues with 19 people having their food, and awkwardly waiting for the 1 meal that didn't come out right.
On the surface it may look like speakerconf is a week off work, in a vacation location, dining like a king; however, if you look closely, each of those choices is based on a practical choice. The scheduling is a net win for everyone involved. The location facilitates distraction free, deep collaboration. The dining enhances the event by allowing the attendees to focus on collaboration while Josh and I worry about location selection, providing food that meets all dietary restrictions, and ensuring that the cost of dinner doesn't deter attendance. The result (or sum) is also greater than the parts - we provide an easily accessible, deeply educational, & enjoyable experience, which encourages some of the best of the industry leaders to attend, who's attendance encourages more of the industries leaders to attend.
* The final dinner is neither required, nor sponsored - thus it's completely fine for people to opt-out.
© Jay Fields - www.jayfields.com
Weekdays. I strongly hold the opinion that conferences should not be on weekends [more info]. Most of the people who attend speakerconf work very hard on an average week, and I don't want take a weekend away from them, their friends, or their family. I'm a very firm believer in work / life balance, and I don't want to be part of tipping the scales even farther in the 'work' direction. Additionally, it makes sense as a conference organizer. I want people showing up to speakerconf rested, refreshed, and ready for several days of intense collaboration. It's not enough to give a great presentation at speakerconf, you need to be on your game for 10-12 hours a day and you need to be able to do it for 3-5 straight days.
My opinion is not universally held - some people can't or don't want to be away from the office for that many days. While I see their point of view and note the benefits of switching to starting on Sunday, I simply don't believe that the trade-offs are a net win for speakerconf. Therefore, the best thing that Josh and I can do is ensure that speakerconf is such a "don't miss" event that people believe it is unquestionably worth being out of the office for a week.
Select an easily accessible location. Easily accessible has always been a requirement of mine for speakerconf. Like I mentioned, speakerconf presenters are often on the road - the last thing I want to do is require an additional connection or an extended drive. Aruba is a direct flight from many cities in the US, and the speakerconf hotel is a 15 minute drive from the airport. Aruba was great for the first few speakerconf events; however, when Josh and I created speakerconf we never anticipated that we would draw so much interest from people in Europe as well. Sticking with our ideals about easy accessibility, speakerconf now rotates between a location that is a direct flight from most US airport hubs and a location that is a direct flight from most EU airports.
Select an isolated location. Running a speakerconf in Rome really drove this point home - last February I asked if 2013 should be in Austin, SF, NYC, or Aruba. The majority preferred Aruba, and, more importantly, those that preferred Aruba were also the ones who were most excited about returning in 2013. Many presenters pointed out that if we were in an actual city they would be more likely to be distracted. The final dinner in Aruba proved their point. In Rome in 2011, 1/3 of the presenters went out to dinner* on the final night. Conversely, in Aruba 17/18 presenters went to dinner and all 17 continued their discussions at the hotel bar for many hours following dinner. The isolated location provided fewer distractions, and seemed to facilitate much deeper interactions.
Select a location with a concentration of restaurants. speakerconf takes a very different approach to dining. Josh and I aim to not only host an amazingly educational event, but to also provide the best dining experience of any conference. We don't provide conference center food for breakfast or lunch, instead we select hotels that are near great local restaurants that serve reasonably priced breakfast and lunch options. Dinners are done at some of the highest rated local restaurants - and we require the ability to select from several different options.
Dine well. Josh and I love food & wine, and our preferences definitely show in our dinner selections. The conference sponsored dinners at speakerconf are generally at restaurants that I prefer to take my wife to when we visit those cities on vacation. The dinner wine selections are usually done based on what Josh has loved drinking in the past. As an example, the conference dinners in Munich are at Boettners & Vue Maximilian, the number 1 & number 3 rated restaurants in Munich according to zagat.com. I could go on and on about the type meals that we aim to provide at speakerconf, but sometimes a picture truly is worth a thousand words - here are the 1,000 that describe a dinner at speakerconf.
Group dinners are better if you split to tables of 3-5. Many people loved being part of a large, group dinner table, but the conversations did suffer a bit. In 2011 we began making dinner reservations for "a party of 20, but we would like 5 tables of 4", and the conversations became longer, deeper, and more productive. As a side benefit, the restaurant staff seems to find this easier to manage as well - which means less issues with 19 people having their food, and awkwardly waiting for the 1 meal that didn't come out right.
On the surface it may look like speakerconf is a week off work, in a vacation location, dining like a king; however, if you look closely, each of those choices is based on a practical choice. The scheduling is a net win for everyone involved. The location facilitates distraction free, deep collaboration. The dining enhances the event by allowing the attendees to focus on collaboration while Josh and I worry about location selection, providing food that meets all dietary restrictions, and ensuring that the cost of dinner doesn't deter attendance. The result (or sum) is also greater than the parts - we provide an easily accessible, deeply educational, & enjoyable experience, which encourages some of the best of the industry leaders to attend, who's attendance encourages more of the industries leaders to attend.
* The final dinner is neither required, nor sponsored - thus it's completely fine for people to opt-out.
© Jay Fields - www.jayfields.com
June 11, 2012
Clojure: name function
The 'name' function is a clojure function that returns the string for a keyword, symbol, or string.
At first glace this might not seem that interesting; however, it's good to know 'name' if you've ever been surprised by (str :foo) => ":foo". If you have a ruby background (as I do), you probably expected the result to be "foo", spent a bit of time looking, and found that (name :foo) was actually what you were looking for.
That's helpful, but not particularly exciting. Perhaps a more interesting application of name is the ability to normalize all keys as strings and destructure. For example, say you're designing a library that monitors threads and you want to be able to pass in warning and error thresholds. Usage of your functions may look like the following examples
(monitored-threads/create :warn-threshold 100 :error-threshold 200)
(monitored-threads/create "warn-threshold" 100 "error-threshold" 200)
Assuming a simple function that updates keys:
(defn update-keys [m f]
(reduce (fn [r [k v]] (assoc r (f k) v)) {} m))
You can now write your create function as:
(defn create [& {:as m}]
(let [{:strs [warn-threshold error-threshold]} (update-keys m name)]
; do work, son
))
© Jay Fields - www.jayfields.com
name - function
Usage: (name x)
Returns the name String of a string, symbol or keyword.
At first glace this might not seem that interesting; however, it's good to know 'name' if you've ever been surprised by (str :foo) => ":foo". If you have a ruby background (as I do), you probably expected the result to be "foo", spent a bit of time looking, and found that (name :foo) was actually what you were looking for.
That's helpful, but not particularly exciting. Perhaps a more interesting application of name is the ability to normalize all keys as strings and destructure. For example, say you're designing a library that monitors threads and you want to be able to pass in warning and error thresholds. Usage of your functions may look like the following examples
(monitored-threads/create :warn-threshold 100 :error-threshold 200)
(monitored-threads/create "warn-threshold" 100 "error-threshold" 200)
Assuming a simple function that updates keys:
(defn update-keys [m f]
(reduce (fn [r [k v]] (assoc r (f k) v)) {} m))
You can now write your create function as:
(defn create [& {:as m}]
(let [{:strs [warn-threshold error-threshold]} (update-keys m name)]
; do work, son
))
© Jay Fields - www.jayfields.com
June 7, 2012
speaking at speakerconf
Speaking at speakerconf is nothing like speaking at a traditional conference. It took us a few years to tweak our ideas around presentations - and this blog post is about what we've come to consider 'the speakerconf way' (with respect to speaking)
There are no abstracts or pre-announced talks. From the beginning Josh and I have believed that we want people to be able to speak about whatever is most interesting to them. Too many times in my career I have had a talk accepted to a conference, and by the time the conference comes around I'm on to something new. I honor my commitment and give a talk on the accepted abstract, but I always feel a bit guilty for presenting information that's already somewhat dated. speakerconf completely avoids this issue by neither requesting nor accepting abstracts. In fact, many presenters prepare a few different presentations and just-in-time choose whichever presentation they believe will be better received.
Prepare only 10 minutes of content. speakerconf began with 20 minute time-slots exclusively. Over the following few years we toyed with 5, 15, & 30 minute talks. In general, the 5 minute talks turned out very well, the 15 minute talks turned out well most of the time, and the 30 minute talks always seemed to stretch far too long. Each year Dave Thomas recommended that we give each presenter 10 minutes. We finally made the 10 minutes of content rule change in 2011 and have never looked back. 10 minute talks are perfect for speakerconf. If people are into a topic then the questions end up stretching the session out to 30 (deeply engaged) minutes, if people aren't into a topic then you're off stage before people get bored. Since we've made this rule change, people have been generally happy with the presentations as a whole, and we've yet to have a presenter give a presentation that wasn't enjoyed by the majority of the audience.
Presentations go on as long as they have to. John Hughes inspired this one. Like I mentioned in the last paragraph, we give everyone 10 minutes for content, but let the audience drive the actual length of the presentation with their questions. The speakerconf audiences are inquisitive, so we still need to put an upper bound of 30 minutes on a talk. Still, most talks manage to create plenty of deep discussion in their 30 minute windows.
Presentations first, unstructured conversation second. A few years ago we switched things up by splitting up the presentations, and it didn't work well - people couldn't get back in the mood for presentations. Now, each day starts with presentations that spark ideas and then goes to unstructured conversation about those ideas.
Alumni speak first. Originally, we allowed speakers to request their speaking slots. In the 2nd year Matt Deiters requested and spoke in the 2nd speaking spot, and quickly regretted it. Speaking at speakerconf requires a bit of calibration. The audience at speakerconf isn't like the vast majority of conferences, and you do need to alter your presentation style a bit - go faster, take out filler or elementary slides, expect frequent interruptions. After a few days of speakerconf it's easy to fall in the groove; however, Matt didn't get that luxury. Based on his suggestion, each speakerconf since then has scheduled all alumni ahead of new-comer presentations.
Dynamic speaking order. Each speakerconf does have a suggested schedule; however, we also offer the opportunity to 'get next' at any time. At speakerconf Rome 2011, Francesco Cesarini noticed that his presentation would go very well if it followed Scott Farquhar's. Unbeknownst to the presenters and organizers, some people end up presenting on very similar ideas. Once the audience gets into a subject, it makes sense to allow presentations with complementary ideas topics to be grouped together. Therefore, at speakerconf any presenter that believes their presentation will nicely expand on the current presentation can simply let the organizers know that they've 'got next' and they'll be moved into the next speaking time-slot.
Everyone speaks. For the first few years we had attendees and presenters; however, we found that there were a few issues with non-speaking audience members. First of all, when you speak everyone knows a bit about who you are and what you do; conversely, the non-speaking attendees were always a mystery. Additionally, speaking audience members always participated significantly more, as they had given people a topic to approach them about. Lastly, we often had non-speaking attendees who the other speakers actually wanted to hear from. In the end it just didn't make sense to invite very talented people who were only participating in the open discussions. Now, and in the future, there are no attendees, if you attend speakerconf, you present.
The speakerconf way is very nimble. We don't know what people are going to talk about, how long they're going to talk, or when they're going to give their presentation. In fact, the only thing we do know is that you are eventually going to speak about something. Obviously this isn't something that every conference could adopt, but we've found that it greatly enriches the speakerconf experience. The speakerconf way provides a quick exit for anyone who's idea isn't going over quite as smoothly as they'd anticipated, but, more importantly, it allows the good presentations to reach their full potential.
© Jay Fields - www.jayfields.com
There are no abstracts or pre-announced talks. From the beginning Josh and I have believed that we want people to be able to speak about whatever is most interesting to them. Too many times in my career I have had a talk accepted to a conference, and by the time the conference comes around I'm on to something new. I honor my commitment and give a talk on the accepted abstract, but I always feel a bit guilty for presenting information that's already somewhat dated. speakerconf completely avoids this issue by neither requesting nor accepting abstracts. In fact, many presenters prepare a few different presentations and just-in-time choose whichever presentation they believe will be better received.
Prepare only 10 minutes of content. speakerconf began with 20 minute time-slots exclusively. Over the following few years we toyed with 5, 15, & 30 minute talks. In general, the 5 minute talks turned out very well, the 15 minute talks turned out well most of the time, and the 30 minute talks always seemed to stretch far too long. Each year Dave Thomas recommended that we give each presenter 10 minutes. We finally made the 10 minutes of content rule change in 2011 and have never looked back. 10 minute talks are perfect for speakerconf. If people are into a topic then the questions end up stretching the session out to 30 (deeply engaged) minutes, if people aren't into a topic then you're off stage before people get bored. Since we've made this rule change, people have been generally happy with the presentations as a whole, and we've yet to have a presenter give a presentation that wasn't enjoyed by the majority of the audience.
Presentations go on as long as they have to. John Hughes inspired this one. Like I mentioned in the last paragraph, we give everyone 10 minutes for content, but let the audience drive the actual length of the presentation with their questions. The speakerconf audiences are inquisitive, so we still need to put an upper bound of 30 minutes on a talk. Still, most talks manage to create plenty of deep discussion in their 30 minute windows.
Presentations first, unstructured conversation second. A few years ago we switched things up by splitting up the presentations, and it didn't work well - people couldn't get back in the mood for presentations. Now, each day starts with presentations that spark ideas and then goes to unstructured conversation about those ideas.
Alumni speak first. Originally, we allowed speakers to request their speaking slots. In the 2nd year Matt Deiters requested and spoke in the 2nd speaking spot, and quickly regretted it. Speaking at speakerconf requires a bit of calibration. The audience at speakerconf isn't like the vast majority of conferences, and you do need to alter your presentation style a bit - go faster, take out filler or elementary slides, expect frequent interruptions. After a few days of speakerconf it's easy to fall in the groove; however, Matt didn't get that luxury. Based on his suggestion, each speakerconf since then has scheduled all alumni ahead of new-comer presentations.
Dynamic speaking order. Each speakerconf does have a suggested schedule; however, we also offer the opportunity to 'get next' at any time. At speakerconf Rome 2011, Francesco Cesarini noticed that his presentation would go very well if it followed Scott Farquhar's. Unbeknownst to the presenters and organizers, some people end up presenting on very similar ideas. Once the audience gets into a subject, it makes sense to allow presentations with complementary ideas topics to be grouped together. Therefore, at speakerconf any presenter that believes their presentation will nicely expand on the current presentation can simply let the organizers know that they've 'got next' and they'll be moved into the next speaking time-slot.
Everyone speaks. For the first few years we had attendees and presenters; however, we found that there were a few issues with non-speaking audience members. First of all, when you speak everyone knows a bit about who you are and what you do; conversely, the non-speaking attendees were always a mystery. Additionally, speaking audience members always participated significantly more, as they had given people a topic to approach them about. Lastly, we often had non-speaking attendees who the other speakers actually wanted to hear from. In the end it just didn't make sense to invite very talented people who were only participating in the open discussions. Now, and in the future, there are no attendees, if you attend speakerconf, you present.
The speakerconf way is very nimble. We don't know what people are going to talk about, how long they're going to talk, or when they're going to give their presentation. In fact, the only thing we do know is that you are eventually going to speak about something. Obviously this isn't something that every conference could adopt, but we've found that it greatly enriches the speakerconf experience. The speakerconf way provides a quick exit for anyone who's idea isn't going over quite as smoothly as they'd anticipated, but, more importantly, it allows the good presentations to reach their full potential.
© Jay Fields - www.jayfields.com
June 6, 2012
a typical day at speakerconf
At this point, speakerconf has run 5 times in 4 years - in Aruba and Italy. Josh and I are happy with what we've created, and a few follow up entires will list the attributes of speakerconf that make it a unique and successful event. This post, however, should serve as a quick view into what a typical day is like at speakerconf.
the morning
Each day begins unofficially at breakfast. There's no assigned meeting time, but people generally start appearing around 9:00am. There are no assigned tables, and people usually just break off into small, ad hoc groups of 3 or 4. It's rare to find one of these tables not talking about what interested them from the day before, or what they're looking forward to discussing that day. Following breakfast, people begin filling into the conference room, and presentations begin at 10:00am sharp. Each presentation generally takes between 10 and 30 minutes. There's usually a ton of questions that go with each presentation, thus the variable talk time-slot. We attempt to get 4 presentations done each morning, and usually end up leaving 'late' for lunch.
the afternoon
Lunch generally lasts an hour, and is done at one of the local restaurants (not in the conference room). Attendees break into small groups and go to different restaurants. Most often, people go to lunch with someone they want to discuss a specific idea with, or someone they haven't previously dined with. After lunch everyone makes their way back to the conference room for 4 more presentations. On a good day, we'll be done with presentations by 3pm; however, (due to the q&a for each presentation) we're usually done with presentations between 3:30pm and 4:00pm.
Once the presentations end we move out of the conference room and into a space that allows us to have many smaller discussions. The split is ad hoc once again, and, just like lunch, is often based on digging further into a presented topic or meeting a new person. These discussions often begin with most of the presenters in attendance, and people only seem to leave if they have personal or business matters to attend to. These smaller discussions end (or rather, are put on hold) at 6:45pm at the latest.
the evening
Dinner is always at a local restaurant (outside of the hotel), and usually begins around 7:00pm. Just like every other meal, attendees break up into unassigned, smaller groups of 3-6 people. Dinners are usually at least 3 courses, and offer plenty of time to dig deep into whatever subject drove you to select your dinner companions. Once dinner is complete everyone heads back to the hotel, and those that still have the energy to have further discussions generally make their way to the hotel bar. It's not uncommon for those that have already completed their presentations to stay out past 2am - and still get themselves to the 9:00am breakfast the following morning.
That's a pretty typical day at speakerconf. If it doesn't sound exhausting, then I haven't done a very good job of describing it. However, it's equally exhausting as it is inspiring, and the days at speakerconf are some of my favorite days of the year.
© Jay Fields - www.jayfields.com
the morning
Each day begins unofficially at breakfast. There's no assigned meeting time, but people generally start appearing around 9:00am. There are no assigned tables, and people usually just break off into small, ad hoc groups of 3 or 4. It's rare to find one of these tables not talking about what interested them from the day before, or what they're looking forward to discussing that day. Following breakfast, people begin filling into the conference room, and presentations begin at 10:00am sharp. Each presentation generally takes between 10 and 30 minutes. There's usually a ton of questions that go with each presentation, thus the variable talk time-slot. We attempt to get 4 presentations done each morning, and usually end up leaving 'late' for lunch.
the afternoon
Lunch generally lasts an hour, and is done at one of the local restaurants (not in the conference room). Attendees break into small groups and go to different restaurants. Most often, people go to lunch with someone they want to discuss a specific idea with, or someone they haven't previously dined with. After lunch everyone makes their way back to the conference room for 4 more presentations. On a good day, we'll be done with presentations by 3pm; however, (due to the q&a for each presentation) we're usually done with presentations between 3:30pm and 4:00pm.
Once the presentations end we move out of the conference room and into a space that allows us to have many smaller discussions. The split is ad hoc once again, and, just like lunch, is often based on digging further into a presented topic or meeting a new person. These discussions often begin with most of the presenters in attendance, and people only seem to leave if they have personal or business matters to attend to. These smaller discussions end (or rather, are put on hold) at 6:45pm at the latest.
the evening
Dinner is always at a local restaurant (outside of the hotel), and usually begins around 7:00pm. Just like every other meal, attendees break up into unassigned, smaller groups of 3-6 people. Dinners are usually at least 3 courses, and offer plenty of time to dig deep into whatever subject drove you to select your dinner companions. Once dinner is complete everyone heads back to the hotel, and those that still have the energy to have further discussions generally make their way to the hotel bar. It's not uncommon for those that have already completed their presentations to stay out past 2am - and still get themselves to the 9:00am breakfast the following morning.
That's a pretty typical day at speakerconf. If it doesn't sound exhausting, then I haven't done a very good job of describing it. However, it's equally exhausting as it is inspiring, and the days at speakerconf are some of my favorite days of the year.
© Jay Fields - www.jayfields.com
June 5, 2012
Clojure: expectations & with-redefs
In general, when I'm writing tests, the pure functions end up as bare expects and the impure functions end up as scenarios. The following contrived namespace keeps a list of users and allows you to get the full name of each user.
The tests for this namespace would often look something like the following code:
It feels natural to put the with-redefs in a scenario, since scenarios also support (and often make use of) stubbing, localize-state, & freeze-time. However, there's really no reason that you need to use a scenario if you're simply looking to redef a var.
The following test provides the same level of functionality verification, without needing to use expectations.scenarios:
scenarios are great, but these days I try to keep things simple with bare expectations whenever possible.
© Jay Fields - www.jayfields.com
The tests for this namespace would often look something like the following code:
It feels natural to put the with-redefs in a scenario, since scenarios also support (and often make use of) stubbing, localize-state, & freeze-time. However, there's really no reason that you need to use a scenario if you're simply looking to redef a var.
The following test provides the same level of functionality verification, without needing to use expectations.scenarios:
scenarios are great, but these days I try to keep things simple with bare expectations whenever possible.
© Jay Fields - www.jayfields.com
May 31, 2012
The Single Best Thing For My Career
In 2004 I was working at nelnet - for one of the best bosses I've ever had. I was the lone developer working on NextGen projects, our customers were happy, I was paid well, & I had plenty of vacation - things were good. Truthfully, I felt like I was on top of the world. However, I couldn't help but feel like something was missing. I'd seen a bit of 'how things could be' by reading Refactoring & Extreme Programming Explained. I was 24 years old, and I felt like my current situation wasn't going to allow me to grow much. I'm convinced that if I were older I wouldn't have changed a thing, but I was young, and I dove into the deep-end of consulting.
Like I mentioned, I'd seen a bit of the light before I made the jump. I had read a few good books, I was using Test Driven Development (TDD) and Continuous Integration at work, and I'd seen the (successful) results of my efforts. Before I joined the NextGen team I was working with a larger group of developers, and at one point we were in the middle of delivering a huge release. While everyone else was working weekends I was either not in the office or I was at my desk reading about poker theory. My component of the release worked, 100% of the time. My tests prevented regressions even as the release evolved. Through the many month ordeal, I never once had an issue. I had seen the benefits of TDD, there was no turning back, and I wanted to mature my skills even further.
I joined ThoughtWorks in early 2005. From the moment I walked into the office I felt like I was drinking from a fire-hose. What's firefox? Better than IE, okay then. What's DI? Inject the dependencies so you can use mocks or stubs in the tests, got it. Ruby on Rails, PostgreSQL, I'm on it. Then there's all the other things that aren't technology related, but are still worth knowing: international travel, frequent flyer programs, points credit cards, car rentals, etc etc. In my first year with ThoughtWorks I grew more as a person than I had in the previous 3 years combined.
Obviously, it's not all roses. In my orientation class I remember everyone admitting that they were going to put in 2 years for the experience and get out - I had the same plan. The guy with the most experience made it 6 months, two other guys made it a year, and I stayed for 3. The constant travel can wear on you, but it's worth doing it for as long as you possibly can.
There's three reasons that consulting was like steroids for my career:
diversity of experience
building my network
focus on my craft
Each project of my consulting career was very different: C# in the Travel Industry, VB.net in Insurance, Ruby (& DSLs) in Credit Cards, Ruby on Rails (RoR) in VoIP, RoR in Auctions, RoR in Advertising. Projects often used different operating systems (ms, linux, apple) and databases (mysql, postgres, oracle, sql server). Naturally, I couldn't become an expert in everything I touched, but the exposure gave me views into each world. Additionally, I was able to meet experts from each of those worlds. When I joined ThoughtWorks I was a C# developer carrying a Dell, when I walked out I was carrying a MacBook Air and I was best known in the Ruby space - consulting completely changed the trajectory of my career path.
As I mentioned, I often got the opportunity to meet with various experts. I don't know Oracle well, but if I have a problem, I know I can email Pramod. Even though he never worked there, I met Stu Halloway while working for ThoughtWorks. Stu introduced me to Rich Hickey, which is pretty nice, since I spend the majority of my time working with Clojure these days. I met Martin Fowler and eventually wrote a book with him. My network gets me invited to conferences, allows me to co-organize speakerconf, and when I joined DRW, I brought 13 friends with me. If you believe that "your network determines your net-worth", then the majority of my net-worth is due to what I built while I was consulting.
At speakerconf 2011 I noted that everyone involved in the Software Craftsmanship movement was either a consultant or had very recently left consulting. The question of why this was the case was sent to the twitterverse. Brian Guthrie's response rang very true (it was something along the lines of): as a consultant, our craft is the only thing we own. Consultants hone their craft endlessly. I'm convinced that's the reason that consultants are almost always ahead of the technology curve. As a consultant, to invest in your business is to invest in yourself. If you work for a consultancy you'll not only have the time to focus on your craft, you'll also likely be surrounded by a group of people who have been doing the same - and are happy to show you what they've learned.
These days, I'm no longer at ThoughtWorks, and I don't miss it. In the end, I couldn't deal with the travel or the business model. However, that doesn't change the fact that it was the single best thing that has ever happened to my career. I would highly recommend consulting to everyone who is truly serious about maturing their software development skills.
note: Not all consultancies seem to require as much travel, Relevance, for example, requires very little travel - from what I hear. I also hear that it's an amazing place to work. It would be near the top of my list if I were to get back into consulting.
© Jay Fields - www.jayfields.com
Like I mentioned, I'd seen a bit of the light before I made the jump. I had read a few good books, I was using Test Driven Development (TDD) and Continuous Integration at work, and I'd seen the (successful) results of my efforts. Before I joined the NextGen team I was working with a larger group of developers, and at one point we were in the middle of delivering a huge release. While everyone else was working weekends I was either not in the office or I was at my desk reading about poker theory. My component of the release worked, 100% of the time. My tests prevented regressions even as the release evolved. Through the many month ordeal, I never once had an issue. I had seen the benefits of TDD, there was no turning back, and I wanted to mature my skills even further.
I joined ThoughtWorks in early 2005. From the moment I walked into the office I felt like I was drinking from a fire-hose. What's firefox? Better than IE, okay then. What's DI? Inject the dependencies so you can use mocks or stubs in the tests, got it. Ruby on Rails, PostgreSQL, I'm on it. Then there's all the other things that aren't technology related, but are still worth knowing: international travel, frequent flyer programs, points credit cards, car rentals, etc etc. In my first year with ThoughtWorks I grew more as a person than I had in the previous 3 years combined.
Obviously, it's not all roses. In my orientation class I remember everyone admitting that they were going to put in 2 years for the experience and get out - I had the same plan. The guy with the most experience made it 6 months, two other guys made it a year, and I stayed for 3. The constant travel can wear on you, but it's worth doing it for as long as you possibly can.
There's three reasons that consulting was like steroids for my career:
diversity of experience
building my network
focus on my craft
Each project of my consulting career was very different: C# in the Travel Industry, VB.net in Insurance, Ruby (& DSLs) in Credit Cards, Ruby on Rails (RoR) in VoIP, RoR in Auctions, RoR in Advertising. Projects often used different operating systems (ms, linux, apple) and databases (mysql, postgres, oracle, sql server). Naturally, I couldn't become an expert in everything I touched, but the exposure gave me views into each world. Additionally, I was able to meet experts from each of those worlds. When I joined ThoughtWorks I was a C# developer carrying a Dell, when I walked out I was carrying a MacBook Air and I was best known in the Ruby space - consulting completely changed the trajectory of my career path.
As I mentioned, I often got the opportunity to meet with various experts. I don't know Oracle well, but if I have a problem, I know I can email Pramod. Even though he never worked there, I met Stu Halloway while working for ThoughtWorks. Stu introduced me to Rich Hickey, which is pretty nice, since I spend the majority of my time working with Clojure these days. I met Martin Fowler and eventually wrote a book with him. My network gets me invited to conferences, allows me to co-organize speakerconf, and when I joined DRW, I brought 13 friends with me. If you believe that "your network determines your net-worth", then the majority of my net-worth is due to what I built while I was consulting.
At speakerconf 2011 I noted that everyone involved in the Software Craftsmanship movement was either a consultant or had very recently left consulting. The question of why this was the case was sent to the twitterverse. Brian Guthrie's response rang very true (it was something along the lines of): as a consultant, our craft is the only thing we own. Consultants hone their craft endlessly. I'm convinced that's the reason that consultants are almost always ahead of the technology curve. As a consultant, to invest in your business is to invest in yourself. If you work for a consultancy you'll not only have the time to focus on your craft, you'll also likely be surrounded by a group of people who have been doing the same - and are happy to show you what they've learned.
These days, I'm no longer at ThoughtWorks, and I don't miss it. In the end, I couldn't deal with the travel or the business model. However, that doesn't change the fact that it was the single best thing that has ever happened to my career. I would highly recommend consulting to everyone who is truly serious about maturing their software development skills.
note: Not all consultancies seem to require as much travel, Relevance, for example, requires very little travel - from what I hear. I also hear that it's an amazing place to work. It would be near the top of my list if I were to get back into consulting.
© Jay Fields - www.jayfields.com
May 30, 2012
Is Productivity Killing Your Creativity?
I listen to audio books while I work out. I've been known to leave earworms 'Rapid Italian' on while trying to go to sleep. I read books on trains. I answer emails while eating dinner. I clear out my Google Reader while watching TV with my wife. I wanted to learn Ruby and Blackjack perfect strategy, so I wrote a perfect strategy simulator in Ruby. I'm a multi-tasking machine. I am the worlds most productive man, or so I liked to pretend.
About 4 years ago at a conference in São Paulo, Chad Fowler told the audience to delete every feed in their blog reader if they wanted to gain an incredible amount of productivity. I was appalled. I already believe that engineers don't spend nearly enough time staying current, and Chad was telling the audience to spend even less time reading about current events. I had (and have) way too much respect for Chad to call bullshit, but I definitely didn't agree. Then again, I'm aggressive about removing noise from my subscription list, so I chalked up the disagreement to him recommending that the audience remove what were likely very noisy subscription lists anyway - probably a net positive act.
A few years later I found myself on a train from NYC to Greenwich, CT - listening to the Zen and the Art of Motorcycle Maintenance audiobook. The book changed my perspective greatly, and I'll never forget the line: I haven't really had a new idea in years. The following paragraph haunted me as well.
If you listen to the people around you, they are saying the same things - whether they know it or not. I'm sure at one time you read an article where a CEO swore they were most productive while they were on a plane, unreachable. Just last week a story made the rounds about a company that moved to Hawaii temporarily. In that story they describe how walks on the beach brought a greater understanding, something that probably couldn't have happened while they were all distracted by the day-to-day activities of living in Silicon Valley. And, I now believe that Chad was talking about the same issue - distractions (masked as productive tasks) stealing your creativity.
I'm convinced that my iPhone was the root of my creativity issues. Life is full of 'waiting time' - waiting for the subway, waiting to see your doctor, waiting in the elevator, waiting in line at airport/grocery store/coffee shop, and waiting at the bar to meet your friends. Pre-iPhone I would spend this waiting time pondering anything that was troubling me. Now, I open Safari on my iPhone to see who is the latest injury on the Knicks, who is the lastest football player to sign with FSU, or who's tweeting about what (seems like it's mostly sponsorship requests these days). I don't spend that time thinking about anything, I spend that time reading - reading about things that have very little impact on my life, but seem to always more than fill my waiting time.
At least, that's what I used to do. Now, I've moved anything that can steal my waiting time to the 2nd page on my iPhone. It's no longer taunting me to check twitter, facebook, sports scores, or anything else. My main page allows me to get things done if I need to do them, but it doesn't offer me anything to fill my 'waiting time'. Those apps are just a page away, but not having them staring at me when I instinctually unlock my phone reminds me that I need that time to think, even if it's not deep thinking, I need to 'do' less and 'think' more.
Even this small step has led to better organization in my mind. Now that I'm not 'productive' 100% of the time, I find myself solving issues with more innovation and greater efficiency. The small step and the noticeable improvement have led me to make larger changes - I still multitask as much as I can, but I also set aside time to stare out the window. No agenda, no priorities, just stare and let my mind go wherever it needs to go. After making these changes, I feel better. I have more mental energy to produce innovative solutions at work, and I find that I'm getting things done in a way that leads to greater long-term productivity. My priorities feel right, if you will.
This isn't the kind of thing I usually produce on this blog, but the impact that my changes have made on my life compelled me to share. And, as I already said, if you listen, more and more people are saying the same thing, even if they aren't using the same words. Technology has driven us to greater 'productivity', but often at the cost of deep concentration and thought. Not everyone is okay with that, and more and more people are beginning to push back in their own ways.
© Jay Fields - www.jayfields.com
About 4 years ago at a conference in São Paulo, Chad Fowler told the audience to delete every feed in their blog reader if they wanted to gain an incredible amount of productivity. I was appalled. I already believe that engineers don't spend nearly enough time staying current, and Chad was telling the audience to spend even less time reading about current events. I had (and have) way too much respect for Chad to call bullshit, but I definitely didn't agree. Then again, I'm aggressive about removing noise from my subscription list, so I chalked up the disagreement to him recommending that the audience remove what were likely very noisy subscription lists anyway - probably a net positive act.
A few years later I found myself on a train from NYC to Greenwich, CT - listening to the Zen and the Art of Motorcycle Maintenance audiobook. The book changed my perspective greatly, and I'll never forget the line: I haven't really had a new idea in years. The following paragraph haunted me as well.
What is in mind is a sort of Chautauqua...that’s the only name I can think of for it...like the traveling tent-show Chautauquas that used to move across America, this America, the one that we are now in, an old-time series of popular talks intended to edify and entertain, improve the mind and bring culture and enlightenment to the ears and thoughts of the hearer. The Chautauquas were pushed aside by faster-paced radio, movies and TV, and it seems to me the change was not entirely an improvement. Perhaps because of these changes the stream of national consciousness moves faster now, and is broader, but it seems to run less deep. The old channels cannot contain it and in its search for new ones there seems to be growing havoc and destruction along its banks. In this Chautauqua I would like not to cut any new channels of consciousness but simply dig deeper into old ones that have become silted in with the debris of thoughts grown stale and platitudes too often repeated. "What’s new?" is an interesting and broadening eternal question, but one which, if pursued exclusively, results only in an endless parade of trivia and fashion, the silt of tomorrow. I would like, instead, to be concerned with the question "What is best?," a question which cuts deeply rather than broadly, a question whose answers tend to move the silt downstream. There are eras of human history in which the channels of thought have been too deeply cut and no change was possible, and nothing new ever happened, and "best" was a matter of dogma, but that is not the situation now. Now the stream of our common consciousness seems to be obliterating its own banks, losing its central direction and purpose, flooding the lowlands, disconnecting and isolating the highlands and to no particular purpose other than the wasteful fulfillment of its own internal momentum. Some channel deepening seems called for.As I said, Zen and the Art of Motorcycle Maintenance changed my perspective. I began to look back at the last few years of my life, and I felt like my creativity had been stunted. At one point in my life I would stare out the window of a plane for several hours a week pondering whatever technical problem that was troubling me. But, for the last several years I've been being 'productive' by listening to an audiobook or reading something on my iPad. I've been listening, but I haven't been thinking, not deeply.
If you listen to the people around you, they are saying the same things - whether they know it or not. I'm sure at one time you read an article where a CEO swore they were most productive while they were on a plane, unreachable. Just last week a story made the rounds about a company that moved to Hawaii temporarily. In that story they describe how walks on the beach brought a greater understanding, something that probably couldn't have happened while they were all distracted by the day-to-day activities of living in Silicon Valley. And, I now believe that Chad was talking about the same issue - distractions (masked as productive tasks) stealing your creativity.
I'm convinced that my iPhone was the root of my creativity issues. Life is full of 'waiting time' - waiting for the subway, waiting to see your doctor, waiting in the elevator, waiting in line at airport/grocery store/coffee shop, and waiting at the bar to meet your friends. Pre-iPhone I would spend this waiting time pondering anything that was troubling me. Now, I open Safari on my iPhone to see who is the latest injury on the Knicks, who is the lastest football player to sign with FSU, or who's tweeting about what (seems like it's mostly sponsorship requests these days). I don't spend that time thinking about anything, I spend that time reading - reading about things that have very little impact on my life, but seem to always more than fill my waiting time.
At least, that's what I used to do. Now, I've moved anything that can steal my waiting time to the 2nd page on my iPhone. It's no longer taunting me to check twitter, facebook, sports scores, or anything else. My main page allows me to get things done if I need to do them, but it doesn't offer me anything to fill my 'waiting time'. Those apps are just a page away, but not having them staring at me when I instinctually unlock my phone reminds me that I need that time to think, even if it's not deep thinking, I need to 'do' less and 'think' more.
Even this small step has led to better organization in my mind. Now that I'm not 'productive' 100% of the time, I find myself solving issues with more innovation and greater efficiency. The small step and the noticeable improvement have led me to make larger changes - I still multitask as much as I can, but I also set aside time to stare out the window. No agenda, no priorities, just stare and let my mind go wherever it needs to go. After making these changes, I feel better. I have more mental energy to produce innovative solutions at work, and I find that I'm getting things done in a way that leads to greater long-term productivity. My priorities feel right, if you will.
This isn't the kind of thing I usually produce on this blog, but the impact that my changes have made on my life compelled me to share. And, as I already said, if you listen, more and more people are saying the same thing, even if they aren't using the same words. Technology has driven us to greater 'productivity', but often at the cost of deep concentration and thought. Not everyone is okay with that, and more and more people are beginning to push back in their own ways.
© Jay Fields - www.jayfields.com
May 29, 2012
Clojure: Freezing Time in expectations
The current version of expectations (1.4.3) contains support for freezing time within an expectations scenario. I already put this information out in a previous blog entry, and I'm going to use the same examples here.
The following code is a test I was working on at work:
(scenario
(handle-fill (build PartialFill))
(expect {:px 10 :size 33 :time 1335758400000} (first @fills)))
The test builds a PartialFill domain object, and passes it to handle-fill. The handle-fill fn converts the domain object to a map and conj's the new map onto the fills vector (which is an atom). The above test would fail due to the time not being frozen, and the traditional way to deal with this issue was to change the test to use (in ..) and ignore the :time key-value pair.
The following code would have resulted in a passing test:
(scenario
(handle-fill (build PartialFill))
(expect {:px 10 :size 33} (in (first @fills))))
The above code is fine, as long as you're not interested in verifying the time; however, things get a lot uglier if you do want to verify time. The following code freezes (joda) time, allowing for time verification:
(scenario
(DateTimeUtils/setCurrentMillisFixed 100)
(handle-fill (build PartialFill))
(expect {:px 10 :size 33 :time 100} (first @fills))
(DateTimeUtils/setCurrentMillisSystem))
While the above code does result in a passing test, it would cause unexpected issues if expect ever failed. In expectations a failure throws an exception (to terminate scenario execution) and the time reset would never occur. Even if that wasn't the case, the time related code takes away from the actual focus of the test.
Therefore, expectations has been modified to take a :freeze-time parameter as part of a scenario definition. The :freeze-time parameter can be a string or a boolean - when specifying a string, anything parse-able by Joda will do; if you specify a boolean time will simply be stopped at the moment of execution.
With :freeze-time available we can rewrite the above test in the following way:
(scenario
:freeze-time "2012-4-30"
(handle-fill (build PartialFill))
(expect {:px 10 :size 33 :time 1335758400000} (first @fills)))
The resulting code is easier to work with, while still allowing verification of time.
I believe the domain related code does a better job of demonstrating the point; however, the following examples are available if you'd like something simplified.
(scenario
:freeze-time true
(expect (DateTime.) (do (Thread/sleep 10) (DateTime.))))
(scenario
:freeze-time "2012-4-30TZ"
(expect (.getMillis (DateTime.)) 1335744000000))
© Jay Fields - www.jayfields.com
The following code is a test I was working on at work:
(scenario
(handle-fill (build PartialFill))
(expect {:px 10 :size 33 :time 1335758400000} (first @fills)))
The test builds a PartialFill domain object, and passes it to handle-fill. The handle-fill fn converts the domain object to a map and conj's the new map onto the fills vector (which is an atom). The above test would fail due to the time not being frozen, and the traditional way to deal with this issue was to change the test to use (in ..) and ignore the :time key-value pair.
The following code would have resulted in a passing test:
(scenario
(handle-fill (build PartialFill))
(expect {:px 10 :size 33} (in (first @fills))))
The above code is fine, as long as you're not interested in verifying the time; however, things get a lot uglier if you do want to verify time. The following code freezes (joda) time, allowing for time verification:
(scenario
(DateTimeUtils/setCurrentMillisFixed 100)
(handle-fill (build PartialFill))
(expect {:px 10 :size 33 :time 100} (first @fills))
(DateTimeUtils/setCurrentMillisSystem))
While the above code does result in a passing test, it would cause unexpected issues if expect ever failed. In expectations a failure throws an exception (to terminate scenario execution) and the time reset would never occur. Even if that wasn't the case, the time related code takes away from the actual focus of the test.
Therefore, expectations has been modified to take a :freeze-time parameter as part of a scenario definition. The :freeze-time parameter can be a string or a boolean - when specifying a string, anything parse-able by Joda will do; if you specify a boolean time will simply be stopped at the moment of execution.
With :freeze-time available we can rewrite the above test in the following way:
(scenario
:freeze-time "2012-4-30"
(handle-fill (build PartialFill))
(expect {:px 10 :size 33 :time 1335758400000} (first @fills)))
The resulting code is easier to work with, while still allowing verification of time.
I believe the domain related code does a better job of demonstrating the point; however, the following examples are available if you'd like something simplified.
(scenario
:freeze-time true
(expect (DateTime.) (do (Thread/sleep 10) (DateTime.))))
(scenario
:freeze-time "2012-4-30TZ"
(expect (.getMillis (DateTime.)) 1335744000000))
© Jay Fields - www.jayfields.com
May 24, 2012
Clojure: expectations, colorized
The current version of expectations (1.4.3) prints colorized results by default on non-windows boxes.
The following screenshot is an example of the output when no tests are failing:
And, the following screenshot is an example of the output when there are failures or errors:
Colorized output is one of those small things that is easy to de-prioritize, but once it's done you can't figure out why you didn't do it earlier. The code to colorize your results is very simple, and there's even a lib, colorize, if you prefer to simply include a dependency instead.
Of course, if you prefer to stick with non-colorized results that's possible as well - simply set the environment variable EXPECTATIONS_COLORIZE to 'false'.
© Jay Fields - www.jayfields.com
The following screenshot is an example of the output when no tests are failing:
And, the following screenshot is an example of the output when there are failures or errors:
Colorized output is one of those small things that is easy to de-prioritize, but once it's done you can't figure out why you didn't do it earlier. The code to colorize your results is very simple, and there's even a lib, colorize, if you prefer to simply include a dependency instead.
Of course, if you prefer to stick with non-colorized results that's possible as well - simply set the environment variable EXPECTATIONS_COLORIZE to 'false'.
© Jay Fields - www.jayfields.com
May 23, 2012
Killing IntelliJ Launched Processes
I often use IntelliJ to run applications, and on occasion things go wrong. For example, a thread that wont terminate can cause a running application to become unstoppable via the IntelliJ UI. Usually when this happens I end up running ps aux | grep java and following up with a kill -9 for each process that looks like it might be the one I'm looking for. On good days there's only a few processes; however, things are more complicated when I have several to look through.
Last week I noticed that the command used to launch the process printed in the Console window, and, more importantly, the idea.launcher.port is part of that command: e.g. idea.launcher.port=7538. Assuming the port is unique, or even almost unique it's much easier to ps aux | grep for than java.
© Jay Fields - www.jayfields.com
Last week I noticed that the command used to launch the process printed in the Console window, and, more importantly, the idea.launcher.port is part of that command: e.g. idea.launcher.port=7538. Assuming the port is unique, or even almost unique it's much easier to ps aux | grep for than java.
© Jay Fields - www.jayfields.com
