Seriously, I'm asking. I had this discussion with a colleague the other day, and it left me feeling unanswered, so I'm curious to hear some anecdotes.
I assume that since it's 2014, we are all using some kind of source control repository. One of the main reasons we have repositories is to keep our code safe in case something happens to our dev machine. If you didn't have a saved copy somewhere, having a hard drive failure would be catastrophic to your organization.
One of the ancillary features that comes with source code control is incremental history. As source code files are added, deleted, or changed, source control repositories dutifully keep a history of all changes, and they keep that information indefinitely. I have always assumed that was a good thing to have an indefinitely long history of all code changes since inception.
Now I'm not so sure.
At face value, the code history is about finding how things were in the ago, some indeterminate time in the past. They don't represent the production codebase of today (especially if you release features frequently). In a lot of agile shops, the code in them is stale after only a few weeks.
Some companies have processes that theoretically allow you to pick any date in the past and redeploy the entire system as of that date. You have to have code history to enable this. Unfortunately, despite unlimited rollback being cited to do any number of things in the software industry, it's rare that rolling back is actually plausible. DB changes, business processes, bug fixes that have been made since that date - those can all torpedo the idea of rolling back to some generic past date.
Maybe there's a legal case for keeping code indefinitely. I'm not aware of such requirements, but I can imagine that maybe certain industries/entities may require it. If it's a requirement for you, I give it a pass, although I still question what the actual benefit of digital hoarding is.
When I think about the uses I've had for code history, it's almost always been to research something that the team is certain was working at some point, and we have a new bug reported. The purpose of the research is to look at the history of the file and find out not only what change was made who made the change.
Why does who made the change matter? The only thing that you should really care about as a team (assuming you're all competent developers) is whether the code works, right? Something is broken, and we want to fix the problem.
One reason you might want to know who made a breaking change is to ask what the thought process was behind the change, and whether they have a reason that the change wasn't made differently. I've never seen this reasoning hold up in practice. Most often, the person responsible has implemented dozens of features since the one that's broken and doesn't have the slightest idea why something was done a particular way. Also, frequently, the person making mistakes can feel checked up on or targeted. Making team members defensive or concerned about not being valued or thought less of will not help the team.
Also, figuring out who made the breaking change has the effect of personalizing the code, when it's actually the team and the team dynamic that allowed the change to be made. We want to keep things as ego-free as possible.
So is it all about blame, then? Is that the only reason you would want to know who made a change? I'm on the fence about that. Modern development shops all have some kind of automated testing associated with their development cycle. While it is not impossible to introduce breaking changes into well-tested code, it should certainly be difficult. When implementing a new feature, if the code you're changing isn't already tested, it's your responsibility to get current behavior under test, and then introduce new tests for the new behavior.
Strong teams hold each other accountable for not mistakes, which are unavoidable, but for process. If there is an indication that, say, testing process was subverted, it's useful for a team lead to pull a person aside and say something like, "Hey, I just fixed a production bug, and it looks like you may have been involved with this code in the past. I noticed that we could have had better test coverage of the feature, so let's check out what I did to test this code. I'd value your insight, in case I'm missing something." It could be that the feature was urgent and the developer on the story was too afraid to ask for help testing. Turn the problem into a teachable moment without belittling or threatening and the team member levels up without fear.
I'm curious to hear what y'all think. Could you live without your source control history? Why or why not? What other uses have you had for digging into the ago?
Friday, October 3, 2014
Tuesday, September 16, 2014
Embrace the Joy in Simplifying
Today, I'm dropping about a dozen tables from our database. The tables are holdovers from a legacy bit of the previous system that were needed as scaffolding to get the new system in place, but are no longer necessary. They are not used for anything, and the data are not useful in any way or needed for audit. Then again, they were not really in the way or costing us anything, right?
And yet I feel a great deal of joy getting rid of them.
Thing is, all team members knew that we needed to do this maintenance, and no one disagreed that these appendix-like structures were no longer needed, but getting priority to clean them up was difficult. The general feeling was that the unused code, data structures, etc. weren't really hurting anything.
There's been a good deal of study around clutter and anxiety, and the internet is awash in articles that link the two. A system that has a lot of old code and data structures is akin to a hoarder's house full of clutter. It causes anxiety. And there are very serious parallels between code clutter and home clutter.
So let me be clear: cleaning up your messes is a priority. You don't generally think about it, but every time you want to go look something up in the database, your eye has to scan over those legacy entities. There's friction there. Do a code search for a class? You find more entries than you need to. There's visual clutter there that takes time to scan.
Yes, you may not use those classes anymore, but they have references to your framework and other classes, right? If you make a change, there are more changes you have to make to get things to compile, more places you have to make sure you don't make a mistake.
Having all these extra classes and structures lying around creates a death by 1,000 tiny little cuts. Deal with this infinitesimal time waste enough times a day, and it adds up to real time wasted and real productivity impacts.
So clean up your codebase. Make it a priority to remove outdated structures that are either legacy or the result of overengineering (which I define as ignoring YAGNI). Minimizing the number of tables, objects, views, whatever in your system makes the system leaner and more easy to deal with. It minimizes cruft and code clutter and makes future coding easier by reducing friction.
Better still, removing old untested code increases your test coverage metrics for free!
So please take some time and load some of these stories into your backlog today.
And yet I feel a great deal of joy getting rid of them.
Thing is, all team members knew that we needed to do this maintenance, and no one disagreed that these appendix-like structures were no longer needed, but getting priority to clean them up was difficult. The general feeling was that the unused code, data structures, etc. weren't really hurting anything.
There's been a good deal of study around clutter and anxiety, and the internet is awash in articles that link the two. A system that has a lot of old code and data structures is akin to a hoarder's house full of clutter. It causes anxiety. And there are very serious parallels between code clutter and home clutter.
So let me be clear: cleaning up your messes is a priority. You don't generally think about it, but every time you want to go look something up in the database, your eye has to scan over those legacy entities. There's friction there. Do a code search for a class? You find more entries than you need to. There's visual clutter there that takes time to scan.
Yes, you may not use those classes anymore, but they have references to your framework and other classes, right? If you make a change, there are more changes you have to make to get things to compile, more places you have to make sure you don't make a mistake.
Having all these extra classes and structures lying around creates a death by 1,000 tiny little cuts. Deal with this infinitesimal time waste enough times a day, and it adds up to real time wasted and real productivity impacts.
So clean up your codebase. Make it a priority to remove outdated structures that are either legacy or the result of overengineering (which I define as ignoring YAGNI). Minimizing the number of tables, objects, views, whatever in your system makes the system leaner and more easy to deal with. It minimizes cruft and code clutter and makes future coding easier by reducing friction.
Better still, removing old untested code increases your test coverage metrics for free!
So please take some time and load some of these stories into your backlog today.
Tuesday, September 9, 2014
Monday Morning Motivation
Monday mornings are kind of a drag, right? Garfield hates Mondays. "Looks like someone's got a case of the Mondays." You've just come off enjoying your weekend of relaxation, sleeping in, home repair, family togetherness, or whatever else makes you happy, and now that's over.
If you have trouble with Mondays, it could be that you're not happy with your job. Having a job that you're excited to go to is a good way to get motivated and not actually dread the end of the weekend. If you aren't that happy with your current gig, you should quit your job.
If you do love your job, but still the idea of waking up early and getting all duded up to commute to your place of work has you dragging a bit, here's one tip to make that Monday morning a little easier.
When you're finishing up your work on Friday afternoon, figure out what you want to work on early Monday morning and leave yourself a breadcrumb to it. In the development world, my favorite mechanism for this is to pick the next story off the board and write a unit test for it.
Write a failing unit test. Leave it failing locally. Monday morning, you'll come in and see your little NCrunch indicator telling you that you have a failing test, and you'll know exactly what you need to start with. Get that test to pass.
This is also pretty good for keeping yourself focused, too. Instead of diving into email in the morning, start out by getting that story done. You'll feel great about having something accomplished under your belt, and it sets a great vibe for the week.
If you have trouble with Mondays, it could be that you're not happy with your job. Having a job that you're excited to go to is a good way to get motivated and not actually dread the end of the weekend. If you aren't that happy with your current gig, you should quit your job.
If you do love your job, but still the idea of waking up early and getting all duded up to commute to your place of work has you dragging a bit, here's one tip to make that Monday morning a little easier.
When you're finishing up your work on Friday afternoon, figure out what you want to work on early Monday morning and leave yourself a breadcrumb to it. In the development world, my favorite mechanism for this is to pick the next story off the board and write a unit test for it.
Write a failing unit test. Leave it failing locally. Monday morning, you'll come in and see your little NCrunch indicator telling you that you have a failing test, and you'll know exactly what you need to start with. Get that test to pass.
This is also pretty good for keeping yourself focused, too. Instead of diving into email in the morning, start out by getting that story done. You'll feel great about having something accomplished under your belt, and it sets a great vibe for the week.
Sunday, September 7, 2014
Creating an Ego-Free Environment
For years I've been talking to my teams about "ego-less development". I don't remember where or when I heard about the concept, but I thought I'd take a couple minutes to talk about what that means to me.
For me, ego-less development starts with the recognition that not everything is about me. All of this code we write daily is code written by us on behalf of and for the organization that employs us, and for which we are paid a (hopefully) fair wage. When we are done writing it, we do not own it. It is not who we are. The idea behind an ego-free environment is that you check your ego at the door, and do your best to produce the best software for the company the best way you know how.
You can think of software as commissioned art. Not every piece is perfect, but when the project is over, the piece sits in the living room of the commissioning person to be enjoyed by that person, not taken home.
When you take the perspective that the code that you write is not yours, it becomes a lot easier to decouple yourself from the code you write. Many people take criticism of their code as a criticism of their own person. While criticism on your code can include a criticism of your skill set, it's should not be intended to suggest anything wrong with you as a person, even though your mind might translate the criticism.
The translation works like this: What's said is "Well, I see something wrong in this code here." What is heard is "You wrote this code. Something is wrong with it. So something is wrong with YOU! STUPID!"
If you're a team lead, you need to make sure that the culture changes so the message comes across correctly. Here's a couple things I've found really helpful in cultures I've been part of:
Freely admit your own mistakes: Everyone makes them. It's no fun to make them, and worse to have things blow up because of something you did. When things do explode, fess up. No excuses. "I did that. I'm really sorry." You're looking to demonstrate the correct approach that you're looking for. Lead by example.
Let people know it's okay to screw up: While habitual bad performance has to be addressed, not every little failure is something team members should feel like they have to fret over. Be honest. Don't gloss over it by saying it's okay. "Yes, you screwed up. We've all been there. We'll do what we need to fix it."
Don't map ownership of specific code to people: If there's a bug found in the system, there's a tendency to say something like, "Oh, looks like a bug in your code. Guess you better get in there and fix it." Once the code is integrated, it's company code. You don't own that code. Anyone can go fix it. Throw the bug in the backlog and let the next available dev snag it.
Use positive language, even when disagreeing: Yes, this is software, and at some point you've got to ship. Sometimes there are differences of opinion, but you lose the instant you say something like "Well, the smart thing to do is..." That's another way of calling someone stupid, if they legitimately disagree with you. Language and communication sets the tone. Make sure that you phrase the argument in terms of risks, rewards, costs, or benefits. "The problem I see with approach A is that X, whereas this other approach [note: not "my approach"] avoids that problem."
Let's say you even get to Nerdvana and have an ego-free environment. Never forget that there are scores of cognitive biases out there and that at any point, you may be falling prey to them. Keep an eye on your own communication to ensure that you're truly communicating the way you would like. Even in an ego-free environment, people still can be defensive.
Not many environments work as one-person bands. Great work takes great teams. Great teams are formed by trust. Check your egos at the door, and build that trust in your environment today!
For me, ego-less development starts with the recognition that not everything is about me. All of this code we write daily is code written by us on behalf of and for the organization that employs us, and for which we are paid a (hopefully) fair wage. When we are done writing it, we do not own it. It is not who we are. The idea behind an ego-free environment is that you check your ego at the door, and do your best to produce the best software for the company the best way you know how.
You can think of software as commissioned art. Not every piece is perfect, but when the project is over, the piece sits in the living room of the commissioning person to be enjoyed by that person, not taken home.
When you take the perspective that the code that you write is not yours, it becomes a lot easier to decouple yourself from the code you write. Many people take criticism of their code as a criticism of their own person. While criticism on your code can include a criticism of your skill set, it's should not be intended to suggest anything wrong with you as a person, even though your mind might translate the criticism.
The translation works like this: What's said is "Well, I see something wrong in this code here." What is heard is "You wrote this code. Something is wrong with it. So something is wrong with YOU! STUPID!"
If you're a team lead, you need to make sure that the culture changes so the message comes across correctly. Here's a couple things I've found really helpful in cultures I've been part of:
Freely admit your own mistakes: Everyone makes them. It's no fun to make them, and worse to have things blow up because of something you did. When things do explode, fess up. No excuses. "I did that. I'm really sorry." You're looking to demonstrate the correct approach that you're looking for. Lead by example.
Let people know it's okay to screw up: While habitual bad performance has to be addressed, not every little failure is something team members should feel like they have to fret over. Be honest. Don't gloss over it by saying it's okay. "Yes, you screwed up. We've all been there. We'll do what we need to fix it."
Don't map ownership of specific code to people: If there's a bug found in the system, there's a tendency to say something like, "Oh, looks like a bug in your code. Guess you better get in there and fix it." Once the code is integrated, it's company code. You don't own that code. Anyone can go fix it. Throw the bug in the backlog and let the next available dev snag it.
Use positive language, even when disagreeing: Yes, this is software, and at some point you've got to ship. Sometimes there are differences of opinion, but you lose the instant you say something like "Well, the smart thing to do is..." That's another way of calling someone stupid, if they legitimately disagree with you. Language and communication sets the tone. Make sure that you phrase the argument in terms of risks, rewards, costs, or benefits. "The problem I see with approach A is that X, whereas this other approach [note: not "my approach"] avoids that problem."
Let's say you even get to Nerdvana and have an ego-free environment. Never forget that there are scores of cognitive biases out there and that at any point, you may be falling prey to them. Keep an eye on your own communication to ensure that you're truly communicating the way you would like. Even in an ego-free environment, people still can be defensive.
Not many environments work as one-person bands. Great work takes great teams. Great teams are formed by trust. Check your egos at the door, and build that trust in your environment today!
Sunday, July 20, 2014
Why I'm Giving Up on Windows Phone
I love Windows Phones. I really do. I picked up the Lumia 900 a couple years ago, and replaced it with a Lumia 925 when that one broke after two years. But I think I have to leave Windows behind, and here's why.
In the ago:
I've never been what you'd call a "gadget guy". Sure, I like the cool toys of every generation, but generally don't want to make it priority to buy gadgets as an early adopter. I've got two kids and not a butt-ton of income I'm willing to consider disposable enough to stay at the forefront of the technology adoption curve.
Cell phones had been out for years before I got one. I'm still not sure I did the right thing. It's an expensive thing that tethers you to the beck and call of both work and home in ways that were impossible before. I love and crave asynchronous communication in my life, and telephone calls just aren't that.
But I did it, because peer pressure in the workplace, and all the cool kids were doing it. And I ended up with the most modest little brick phone I could find. It took me years just to adopt the "cool" phones you could flip closed to hang up on someone when you were angry.
I can't even remember what year it was that I got my first smart phone. One of my buddies had been extolling its virtues for a while, and I eventually caved. And in that moment, my life changed.
iPhone era:
I think it was the iPhone 3G. It was many, many versions ago, but boy, was it handy. It took a relatively resourceful individual and made him into "problem solving man"! Stuck on the road and didn't know where to go? Shoot, I got GPS, y'all! I could get my email via phone! I could search the internet to find anything! I could look up movie times!
And everything was great. For a while.
Compared to the desktop, the application model seemed so limited. I didn't like having to close one app to open another. I didn't like the app store experience all that much, and I despised iTunes, with its huge PC-slowing bloatware (I haven't ever owned a Mac - I hear that integration is better). Battery life just wasn't that great, and a phone without a solid battery becomes a useless brick when the charge is low.
But the last straw came when my wife's iPhone was stole while she was out and about. Someone snatched it right out of her purse (this was back when digital devices were apparently worth something on the black market). We called AT&T. We called Apple. According to them, nothing they could do to brick the device when stolen. Nothing they could do to protect the information on the device. Nothing they could do to even help us restore the information, because iTunes supposedly stored all the useful information for a backup in a binary format that couldn't be read, except to restore the file onto a new iDevice.
We did not want another iDevice. The whole experience left a bad taste in our mouths, and we decided to try the new OS on the block: Android.
Android era:
So we did our research and decided that for our next his/hers phones, we'd each go for the Motorola Droid X, the media darling of the day. And we liked Android. Both of us, which is pretty rare when we can agree on a technology.
Android was slick. The app store worked. Everything synched to our gmail, our contacts, it ran all the apps we wanted (well, not really, because Android wasn't the big player it is today back then, but enough of them). It all felt slick and non-proprietary and easy to use.
But ultimately it wasn't for me. It seemed that the battery drained way too fast. Over the course of the couple years I owned the Droid X, the performance seemed to get worse and worse, like a Windows PC all loaded up with background cruft. You'd tap an icon and nothing would happen, so you'd tap it again, and wait and then two taps would register and who knows what the effect was going to be? Cloud apps weren't quite there yet, and to try to figure out how to get all my disparate information off and refresh the whole phone seemed ridiculous to me. There just had to be a better device.
Enter Windows Phone:
I think it was at Codemash 2012 that I was expressing this displeasure to Clark Sell, Min Maung, and Lwin Maung. They were all talking about the new Lumia flagship device that was launching or had just launched. This was the Lumia 900, and it was going to be great. I think they all had Lumia 800 and in playing with the phones, the whole OS just felt right. It felt intuitive, easy to use.
I did my reading. This phone was optimized for usability. The OS gave priority to touch, so that even if something was processing heavy, if I tapped the phone, by gum it was gonna respond. I was in control, not the currently active thread, and it felt like it. The OS managed threads ruthlessly, and if I'd not been back to an app in a while, it would hibernate the thread and keep the resources running clean.
The phone also seemed optimized for battery life, too. Black screen was the default. You don't think much of it, but a black pixel is off. A white pixel is on. It does affect power consumption for an OLED screen, like the Lumia 900 was going to have. Further, the Windows Phone has a lot of nice features about degrading services gracefully as power gets lower. It extends the battery life for seamlessly turning off services for you.
Overall, the phone just worked.
So I got one, and it was amazing. It was quite literally everything I wanted a phone to be. Great battery life, great threading model, meaning it was always responsive. Uploaded pictures to the cloud. Pretty great camera for a phone.
Upgrading to the Lumia 925:
I eventually upgraded from the 900 to the 925. The 900 didn't support the push to Windows Phone 8 or whatever the release was called, and that had some features that I thought I wanted. I put it off for a while, but ended up with an issue with the headphone jack that would have required a repair or refurb, so I figured, "Why not?"
And things were good again. Migrated my data over to my new phone, got the Windows Phone 8 OS, and all was hunky dory.
Now, one thing should be noted. All this time that I'm loving my Windows Phone, I'm not loving some of the choices it's forcing me to make. I like to listen to podcasts, and a lot of podcasts simply aren't available on the Windows Store. I made do, because I only have so much time, but it sure made it hard some days to find something to listen to.
On top of that, RunKeeper, a popular program for GPS tracking my runs, dropped support for Windows Phone. Broke my heart, really, because it's not as if they didn't support Windows Phone. They stopped supporting Windows Phone. They betrayed me.
Then there were all the apps that I liked that never supported Windows Phone. Sure, there were alternatives you could find, or maybe someone would release a dumbed down version of the app you liked, but it was never the iTunes or Google Play store. But given the positives, I still wasn't really willing to go back to those models I didn't like so much.
The straw that broke the camel's back:
This past week I went down to North Carolina. The family piled in the Kia and drove down, I mean. And when it's my turn to drive, I need my podcasts, while everyone else is sleeping or otherwise occupied. So I fire them up, plug the aux cable into the headphone jack and start listening.
About a minute in, the podcast cuts out mid-sentence. That's strange, so I have to look at the phone and figure out why. Oh, looks like it's paused. Well that's weird. Ok, so press play and back to listening. And it does it again. And again.
It is a nice feature that when the headphone plug is unplugged, the music or other media stops playing. In this case however, it seemed like bumping the headphone plug or cord in a particular way would cause the audio to pause. And because we were on the road jostling, this happened every few minutes or so. For hours on end.
Of course the headphone jack issues with both Nokias could be a coincidence. But they were both out of warranty when it happened. Feels like shoddy work, or even planned obsolescence. After hours in the car driving back, knowing full well I can't use this device now to run with either, it's decision time.
And I pull through the Walgreen's drive-through to pick up prescriptions today on the way home and what do I see?
There's even an obvious little space where to put the "Available for Windows" logo. But it's not to be.
So now I'm torn. I need to move off this Windows thing and admit that it's simply not going to happen for Microsoft. Wouldn't be the first time a really good product didn't make it, so I am not too unhappy, but now I'm wondering where to go next.
Now taking suggestions:
So, I've seen the iPhone 5 and used its camera. It's pretty fast, but I don't know much else about it. My wife never took the Windows plunge and has a Galaxy S3, but that phone is acting weird now, too, and she's ready to chuck that, too.
So seriously asking... What phone next, and why?
Thursday, July 10, 2014
Inspire the Troops
Ok, so today I want to talk to the team leads, the tech leads, and the tech managers out there, the people that other developers and software engineers look to when they want answers, the people whose job involves technology thought leadership.
One of your biggest challenges at your job is motivation. Not yours, obviously. No, you're the kind of go-getter who gets up in the morning and eats a big bowl of "I can do it" for breakfast. You read blogs. You watch your favorite speakers on Twitter. Your motivation is beyond reproach.
But you've got folks on your team who have been doing this whole development thing awhile. Maybe they've been working on that document management subsystem for two years and are really coasting. Maybe they've been stuck on the same platform or same language so long that you see them not being able to think outside the box for a solution. Maybe they are sitting around waiting for direction instead of proactively looking for improvements the way they used to. That doesn't make them bad employees. Life sometimes happens.
As a team lead, you need to get their enthusiasm up. You need to generate in them a lust for coding. Not so they'll code for you 12 hours a day. Don't do that. Burnout is as bad as or worse than a lack of enthusiasm. No, you need your folks to enjoy coding, to enjoy solving problems, to think about their work critically and try to find and suggest new ways of doing things.
But that's a slippery and elusive thing to go looking for. Team motivation might as well be your white whale. You've tried lunch and learns, brown bags, watching team internet videos, and that seemed to help, but you're only one person, and you can't do your job and also manage an inspirational team calendar. Or maybe you can and it's just not enough.
So here's what helped me. That Conference. I've made it no secret that community conferences changed my life. That's just me. But you're not me. You're a successful team lead. You've got the motivation. So don't come to That Conference. Send your team. Here's why.
See, if you want them trained on a particular topic, send them to Pluralsight (I'm not a shill, and they're not a sponsor, but I've had good luck with them). Send them to a class. There are lots of good training programs. Sometimes those programs inspire, to be sure. But I've seen so many people sit through a dull class and come out bored. That's if they were even happy to be there or paying attention to begin with.
What about big conferences, like TechEd, or Google I/O, or one of the huge $2500/ticket conferences (never mind the per diem, the hotel stay, the air fare => maybe you're looking at a $5k total)? They have value, sure, and employees may be motivated by the fact that you've given them a perq. There's value in that , too. But motivation to code and get things done may not be the value there. Maybe it's too marketing-speak. Maybe it's too specific. Maybe it's too platform-limiting.
That Conference, and polyglot community conferences in general, are designed to inspire. By getting attendees into a place where the boss has no presence and giving them a buffet of technologies to feast at, you allow them to rediscover why they came to that field to begin with. You offer them a chance to see different approaches, try different platforms, or understand a different technology culture.
August 11-13, we're hosting the biggest, baddest community-led technology conference/summer camp at the Kalahari Resort up in the Wisconsin Dells. 150 sessions on a glorious and dizzying array of technologies are available to attendees. Encourage them to go to sessions outside their comfort zone, and they may amaze you with what they learn. Even if they stay near to their platform of choice, however, they will find their ideas challenged, and their techniques extended with everything from overview sessions to deep dives.
Of course, it's not just about the technologies. At the end of the day, we're all people interested in similar things. Many of the Speakers (err... Camp Counselors) are industry leaders, but they don't fly in and fly out without interacting. They hang out, meet people, share war stories, and in general are available. I have chatted to people on Twitter forever and then met them for the first time in person at community conferences. Meeting inspirational people is just another way to get motivated. Heck, just meeting a new colleague at another company who is doing similar types of development can be rewarding.
All that would be totally invaluable at the price of one of the bigger conferences. Inspiration and motivation are hard to create, but they seriously affect your team's productivity. That Conference tickets come in at $399.99. With easy travel by auto for anyone in IL, WI, and MN, and most meals included with the ticket, you're talking about more enthusiasm and motivation for potentially south of $1k. Such a deal, really.
So send your teams. Let them bring back their enthusiasm to you. Let them share with you what they learn. Tickets on sale now.
Hey wait, before you go, remember how I said not to come to That Conference? I lied. We totally want you to come, too. We value that leadership and enthusiasm. Speakers for the main sessions are already set, but there are dozens of Open Spaces slots over three days where you can share what you know and maybe even get a little inspired yourself. Come out and meet me. I hope to see you there.
One of your biggest challenges at your job is motivation. Not yours, obviously. No, you're the kind of go-getter who gets up in the morning and eats a big bowl of "I can do it" for breakfast. You read blogs. You watch your favorite speakers on Twitter. Your motivation is beyond reproach.
But you've got folks on your team who have been doing this whole development thing awhile. Maybe they've been working on that document management subsystem for two years and are really coasting. Maybe they've been stuck on the same platform or same language so long that you see them not being able to think outside the box for a solution. Maybe they are sitting around waiting for direction instead of proactively looking for improvements the way they used to. That doesn't make them bad employees. Life sometimes happens.
As a team lead, you need to get their enthusiasm up. You need to generate in them a lust for coding. Not so they'll code for you 12 hours a day. Don't do that. Burnout is as bad as or worse than a lack of enthusiasm. No, you need your folks to enjoy coding, to enjoy solving problems, to think about their work critically and try to find and suggest new ways of doing things.
But that's a slippery and elusive thing to go looking for. Team motivation might as well be your white whale. You've tried lunch and learns, brown bags, watching team internet videos, and that seemed to help, but you're only one person, and you can't do your job and also manage an inspirational team calendar. Or maybe you can and it's just not enough.
So here's what helped me. That Conference. I've made it no secret that community conferences changed my life. That's just me. But you're not me. You're a successful team lead. You've got the motivation. So don't come to That Conference. Send your team. Here's why.
See, if you want them trained on a particular topic, send them to Pluralsight (I'm not a shill, and they're not a sponsor, but I've had good luck with them). Send them to a class. There are lots of good training programs. Sometimes those programs inspire, to be sure. But I've seen so many people sit through a dull class and come out bored. That's if they were even happy to be there or paying attention to begin with.
What about big conferences, like TechEd, or Google I/O, or one of the huge $2500/ticket conferences (never mind the per diem, the hotel stay, the air fare => maybe you're looking at a $5k total)? They have value, sure, and employees may be motivated by the fact that you've given them a perq. There's value in that , too. But motivation to code and get things done may not be the value there. Maybe it's too marketing-speak. Maybe it's too specific. Maybe it's too platform-limiting.
That Conference, and polyglot community conferences in general, are designed to inspire. By getting attendees into a place where the boss has no presence and giving them a buffet of technologies to feast at, you allow them to rediscover why they came to that field to begin with. You offer them a chance to see different approaches, try different platforms, or understand a different technology culture.
August 11-13, we're hosting the biggest, baddest community-led technology conference/summer camp at the Kalahari Resort up in the Wisconsin Dells. 150 sessions on a glorious and dizzying array of technologies are available to attendees. Encourage them to go to sessions outside their comfort zone, and they may amaze you with what they learn. Even if they stay near to their platform of choice, however, they will find their ideas challenged, and their techniques extended with everything from overview sessions to deep dives.
Of course, it's not just about the technologies. At the end of the day, we're all people interested in similar things. Many of the Speakers (err... Camp Counselors) are industry leaders, but they don't fly in and fly out without interacting. They hang out, meet people, share war stories, and in general are available. I have chatted to people on Twitter forever and then met them for the first time in person at community conferences. Meeting inspirational people is just another way to get motivated. Heck, just meeting a new colleague at another company who is doing similar types of development can be rewarding.
All that would be totally invaluable at the price of one of the bigger conferences. Inspiration and motivation are hard to create, but they seriously affect your team's productivity. That Conference tickets come in at $399.99. With easy travel by auto for anyone in IL, WI, and MN, and most meals included with the ticket, you're talking about more enthusiasm and motivation for potentially south of $1k. Such a deal, really.
So send your teams. Let them bring back their enthusiasm to you. Let them share with you what they learn. Tickets on sale now.
Hey wait, before you go, remember how I said not to come to That Conference? I lied. We totally want you to come, too. We value that leadership and enthusiasm. Speakers for the main sessions are already set, but there are dozens of Open Spaces slots over three days where you can share what you know and maybe even get a little inspired yourself. Come out and meet me. I hope to see you there.
Thursday, June 19, 2014
What is a Community Conference?
I know I post a lot about community conferences, but I never really talked about what a community conference is. Like with a lot of things, there may be many definitions out there, but this is how I think about them.
For me, a community conference is community-driven. It's grass-roots. A few people in a certain geographic area, passionate about a particular thing, get together and decide that there have to be other people like them. People that want to get together and talk about things. People who want to learn and teach and communicate and network.
Probably some of those people already do this stuff at industry conferences. Conferences like Build and DevConnections and TechEd for the Microsofties out there are a big deal. Except not everyone can attend those conferences. The price tag on them is simply too high. At a couple grand for a ticket, maybe another grand for the hotel room, air fare, transportation, per diem for food? It all adds up to a fairly expensive prospect for small to midsize companies when it comes to training.
And what do you get for that? Sure you get the national platform, and some of them give out pretty nice goodie-bags with expensive tech-gifts in them (which is basically a way for you to get your company to buy you something you wouldn't buy for yourself), but you also generally get only the broadest of pictures. In the case of Tech Ed, you get broad strokes and marketing spiels. Many people who are there were sent, and may not be all that into it. You have lots of managers and senior folks there who may not be getting much out of it, but are there as a perk for their job.
In contrast, a community conference is organic and attended by people who really want to be there. It is truly of the people, by the people, and for the people. The conference is set up as a not-for-profit, so the ticket cost can be as low as possible. This allows just about anyone to attend, even if they have to do it on their own dime.
Because anyone can afford to attend, it truly means that anyone with a passion for the conference material can be there, and those are the people you want to be there, both as attendees and speakers. People who are enthusiastic about the subject matter and won't wander off mid-conference to play golf.
Because it's not-for-profit, community conferences tend to be run by organizers in their spare time. In my experience, however, that doesn't necessarily mean that things are thrown together or that there's no attention to detail, but I think you do lose some of the polish you'd get if you were paying people an annual salary to set up a conference.
In a lot of ways, however, that's part of the fun, knowing that the conference is as good as the community wants it to be, because they have to pitch in to make it special. It's the difference between consuming and making. It's possible to consume an industry conference, but you get to make your community conference. You don't get the high-priced goodie bags, but you get a very professional conference, with solid information, delivered by some of the most outgoing technologists you're likely to meet.
Of course I've said that community conferences changed my life, and I truly mean that. Codemash is particularly well run, but it's pretty far away for me. That's why I work to run That Conference. If I can help make that change in other people that happened in me, every second I volunteer to putting on a great conference is worth it. In case you didn't know, That Conference is a polyglot (any platform, any language) technology conference held in late summer at the Kalahari Resort in the Wisconsin Dells. Check it out!
That Conference embraces all folks with a love of technology with open arms. Hardware? Software? InfoSec? Data? We have sessions on all things tech. With a ticket price of around $400, it's way cheaper than the big conferences, and for those of you in the Illinois, Wisconsin, Minnesota areas, it's only a short drive away. And if you stay at the hotel, bring your family and they can enjoy the waterpark as part of the room deal. Better still, pick up a family ticket and teach the little ones your love of technology.
I would love to see you there. If you do manage to make it out, come find me! I'd love to meet more folks in this area that share a passion for technology.
For me, a community conference is community-driven. It's grass-roots. A few people in a certain geographic area, passionate about a particular thing, get together and decide that there have to be other people like them. People that want to get together and talk about things. People who want to learn and teach and communicate and network.
Probably some of those people already do this stuff at industry conferences. Conferences like Build and DevConnections and TechEd for the Microsofties out there are a big deal. Except not everyone can attend those conferences. The price tag on them is simply too high. At a couple grand for a ticket, maybe another grand for the hotel room, air fare, transportation, per diem for food? It all adds up to a fairly expensive prospect for small to midsize companies when it comes to training.
And what do you get for that? Sure you get the national platform, and some of them give out pretty nice goodie-bags with expensive tech-gifts in them (which is basically a way for you to get your company to buy you something you wouldn't buy for yourself), but you also generally get only the broadest of pictures. In the case of Tech Ed, you get broad strokes and marketing spiels. Many people who are there were sent, and may not be all that into it. You have lots of managers and senior folks there who may not be getting much out of it, but are there as a perk for their job.
In contrast, a community conference is organic and attended by people who really want to be there. It is truly of the people, by the people, and for the people. The conference is set up as a not-for-profit, so the ticket cost can be as low as possible. This allows just about anyone to attend, even if they have to do it on their own dime.
Because anyone can afford to attend, it truly means that anyone with a passion for the conference material can be there, and those are the people you want to be there, both as attendees and speakers. People who are enthusiastic about the subject matter and won't wander off mid-conference to play golf.
Because it's not-for-profit, community conferences tend to be run by organizers in their spare time. In my experience, however, that doesn't necessarily mean that things are thrown together or that there's no attention to detail, but I think you do lose some of the polish you'd get if you were paying people an annual salary to set up a conference.
In a lot of ways, however, that's part of the fun, knowing that the conference is as good as the community wants it to be, because they have to pitch in to make it special. It's the difference between consuming and making. It's possible to consume an industry conference, but you get to make your community conference. You don't get the high-priced goodie bags, but you get a very professional conference, with solid information, delivered by some of the most outgoing technologists you're likely to meet.
Of course I've said that community conferences changed my life, and I truly mean that. Codemash is particularly well run, but it's pretty far away for me. That's why I work to run That Conference. If I can help make that change in other people that happened in me, every second I volunteer to putting on a great conference is worth it. In case you didn't know, That Conference is a polyglot (any platform, any language) technology conference held in late summer at the Kalahari Resort in the Wisconsin Dells. Check it out!
That Conference embraces all folks with a love of technology with open arms. Hardware? Software? InfoSec? Data? We have sessions on all things tech. With a ticket price of around $400, it's way cheaper than the big conferences, and for those of you in the Illinois, Wisconsin, Minnesota areas, it's only a short drive away. And if you stay at the hotel, bring your family and they can enjoy the waterpark as part of the room deal. Better still, pick up a family ticket and teach the little ones your love of technology.
I would love to see you there. If you do manage to make it out, come find me! I'd love to meet more folks in this area that share a passion for technology.
Subscribe to:
Posts (Atom)