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.
Showing posts with label Productivity. Show all posts
Showing posts with label Productivity. Show all posts
Tuesday, September 16, 2014
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!
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.
Monday, May 5, 2014
Upgrade to the Walking Desk
So I have been using the walking desk for a few hours every few days. I noticed that one big issue was that I was looking down at the monitor, even with the riser on the walking treadmill desk. That was definitely a strain on my neck. But any higher, and I wouldn't be able to type.
Solution? I need a monitor in front of me. One I can look at without looking down. As a touch typist, this isn't a big deal, and would be really handy.
How do you do that, though? A laptop monitor is connected to the laptop. Aha, I thought, I'll hang a TV from the ceiling!
So I picked up a new TV for the loft (the current one was a bit too small for the space), and appropriated that 32" set as a new monitor. Then I picked up a ceiling mount for the TV on Amazon and put it up.
I also moved the treadmill to a different corner of the basement. Here it is in all its glory:
My full setup for when I'm working. Chat window on the left laptop, and active windows on the Yoga and the TV. Coffee or water on the ledge to the right, remote on the ledge to the left.
It works remarkably well. Time to get back on it!
Solution? I need a monitor in front of me. One I can look at without looking down. As a touch typist, this isn't a big deal, and would be really handy.
How do you do that, though? A laptop monitor is connected to the laptop. Aha, I thought, I'll hang a TV from the ceiling!
So I picked up a new TV for the loft (the current one was a bit too small for the space), and appropriated that 32" set as a new monitor. Then I picked up a ceiling mount for the TV on Amazon and put it up.
I also moved the treadmill to a different corner of the basement. Here it is in all its glory:
 |
| The invisible man walks again! |
 |
| Set productivity to 9999! |
Sunday, May 4, 2014
Working from Home, Two Months In
Ok, before this milestone slips away from me, I've got to write up my findings. Because that's what I do.
Granted, this blog has posts about everything from travel to technology, from Team Foundation Server to personal enrichment, from corporate motivation to Chicago traffic.
One overarching theme I'd like to think is interwoven through all these posts is the importance of being happy and productive in your life. Living for the things that you value, and making the most of your time and passion.
I've long theorized about what working from home would be like. I've talked to dozens of people about it, hosted a Codemash Open Spaces session about it, watched endless presentations on the topic, and read books on the topic. From the Why Work Sucks and How to Fix It, to the Four-Hour Work Week, to The Year Without Pants, to Remote, I've read a lot on the topic.
I thought enough about it to at least want to give it a shot.
A year ago, I got my opportunity to give it a trial run: a part-time coding gig with a cool company out of California. The interview was remote, the coding sample was remote, and the onboarding process was remote. I spent hours working for them sitting on the couch, in the basement, or on my front porch. I'd work in the evenings after my 9-5, or in the mornings on the weekends, or while waiting for my son during his scout meeting.
And it was fun. I really enjoyed the focus I got from working remotely. So when it came time to leave my previous employer, I knew that the ability to work remotely was going to be one of my base criteria for what a new job would have to look like for me to even be interested.
Note: remote work is harder to find than I thought it would be. Of the many companies I talked to, a very small fraction of them enabled remote work. Given the benefits that can accrue to an employer, not the least of which is more engaged and enthusiastic employees, I was shocked. Butt-in-seats management is still firmly entrenched within organizations.
But persistence paid off. I had time, and I spent it finding the right opportunity. On March 3, I started at my latest gig. My new organization has an office downtown Chicago that I've driven to a few times, but for many weeks, I've done my work from the basement of my house.
I have to admit. It's the greatest thing ever.
Full disclosure, there's more than remote work contributing to my excitement. I'm working for a much smaller organization. They know exactly what we need to do, and have pretty awesome processes either in place or in flight. On top of that, my new colleagues are all brilliant, and I can learn a lot from each of them. And am learning a lot. In all these regards, it's very different from where I came from.
As such, I can't necessarily attribute how awesome things are to the remote work. So I thought I'd try to take a balanced look at my experience with being remote a couple months in:
Pros
More exercise: Right out of the gate, there is more time available to exercise. Between having built a treadmill desk for walking as I work and doing things with my colleagues like the squat challenge, there's more of a focus on getting moving than I had before.
More work: Maybe I mean "more productivity" here, but I feel as if I get so much more work done. When you're not faffing about in the office getting stopped in the hall about ten different things, you can really get stuff done. With nothing distracting you, it's amazing how in the zone you can get.
More family: I'm putting this one in the more theoretical category, since I joined a team in full-barrel crunch mode moving toward a product launch, but I'm confident that in the weeks ahead, now that we're calming down, I'll be able to spend more time doing things like getting the kids off to school and having coffee and lunch with my wife. I'm looking forward to that.
More freedom: At home, you don't have the same level of scrutiny over your internets as you do at an office. If I want to stream trance music over the speakers or listen to talk radio in the background, I can do that. I'm not restricted to only receiving corporate mail over Outlook, and don't have to worry that all of a sudden GitHub.com or Knockoutjs.com will suddenly be blocked by the Corporate Nanny-Wall (both of which have happened to me).
More flexibility and fewer clothes: The school also called me to come pick up my daughter, who had strep. I went over to get her and was back coding in about 10 minutes. And she was upstairs resting while I was there. That is some flexibility right there. That was also the first time I've ever had to say, "Shoot, I need to run out. Where are my pants?" (I often work in running shorts because I use the treadmill desk on and off.)
Smaller environmental footprint: This doesn't appeal to everyone, but I like to try to reduce my environmental footprint. Not because I'm an environmentalist, but because I am resource-conservative at heart, in the sense that I only like to use what I need and use what I do need efficiently. When two weeks went by without having to put gas in the car, a little part of me did a happy dance.
Email: Working with my team, we depend on chat, and are in direct communication all day, every day. As such, the need for email is basically nil. We use it for broader, more consistent and more persistent topics, although for real stuff, we tot it up in Google docs and throw it in the cloud. I can't tell you how little I miss having a life run by Outlook. I've been moving away from it mentally for a while, but to finally get away from it is so lovely.
Dress code: My whole working life I've been biz-cazh. High school was shirt/tie. I always felt that I got more in the spirit of working when dressed up. Like formality was learning. Sure, when I was in grad school, I wore shorts and T-shirts to teach labs, but that was Tucson, and no one wears a lot of clothes there. But I did have the aforementioned "pants" epiphany. I often wear running shorts so I can walk while working, or even wear jammies up until lunch because they're comfy to walk in, too. Don't judge.
Cons
Diligence: I don't know that it's a con, really, but diligence is a key requirement of having the right personality to work remotely. It's been written about endlessly, that there's a real need to physically separate from the rest of the home to enable you to retain focus on your work. Also, being diligent and focusing on your work can be really exhausting. Being extraordinarily productive from home is well more difficult than being in the office.
Balance: This is kinda the flip side of diligence. I'm struggling a little bit because I'm an early riser, but the business hours for my org are 9-6. What that means practically is that I am often up early, and since I'm up early, I jump online and start working, sometimes at 7:30. Also, while I totally believe in the need for breaks, folks all take lunches at different times, so I hear the siren song of the chat window. I find myself in the basement and working longer hours that I probably need to, and certainly longer than is sustainable, but I'm enjoying what I do.
Chat: So the way we communicate on my team is through a chat app. This is very nice in that it is always open and on. Once you get the hang of it, you can see what's going on peripherally and it's not really different from overhearing chatter in the office. But sometimes... Sometimes you look at what someone's typed in the chat window and go "huh?" because what they've chatted makes no sense. At least out of the context of sound and expression. Another thing that can be burdensome about chat is that when there's a flurry of conversation that you don't want to be part of, you may need to turn off the notifications or sounds.
Cleaning service: One of the things I didn't realize was that my work area in the office didn't stay clean on its own. In the office, we had a cleaning service. If I dropped a Dorito on the floor, no worries. Gone the next day. In a home office, if you spill your coffee, guess who's mopping that up. I hadn't thought about that. Not that I have a lot of coffee-soaked corn chips on the floor, but I noted the need to be a lot more careful when eating around the work space.
Miscellany
Costs: You'd think that costs would be basically a pro. I haven't really analyzed the data, but I think I'm net #winning for the cost side of things. I don't pay for dry cleaning anymore. I wear fewer outfits per day. I'm paying less in gas. Car insurance has dropped. I have to pay for food, but since I generally eat up leftovers that were getting thrown away anyhow, I think I'm doing it for free most days. That said, I have to have and maintain my own office, and any associated costs.
Loneliness and isolation:
I was warned very sternly about this. The idea of being in my basement, not interacting physically with many people, is supposed to somehow be a drag, but I find it kinda the opposite. I mean, with the chat and video and voice calls, I interact with my team at a rapid fire pace. The rest of the time, I sit here by the window, lost in my head and the code and the issues I'm dealing with. For me, it's a great mix. So far, but I hear that like traveling, it can get old. If it does, I'll be sure to post about it when that day comes.
Shoot, those are my thoughts on remote work so far. I'd love to hear from you, though, on what your experience has been. Hit me up on twitter or in the comments.
Granted, this blog has posts about everything from travel to technology, from Team Foundation Server to personal enrichment, from corporate motivation to Chicago traffic.
One overarching theme I'd like to think is interwoven through all these posts is the importance of being happy and productive in your life. Living for the things that you value, and making the most of your time and passion.
I've long theorized about what working from home would be like. I've talked to dozens of people about it, hosted a Codemash Open Spaces session about it, watched endless presentations on the topic, and read books on the topic. From the Why Work Sucks and How to Fix It, to the Four-Hour Work Week, to The Year Without Pants, to Remote, I've read a lot on the topic.
I thought enough about it to at least want to give it a shot.
A year ago, I got my opportunity to give it a trial run: a part-time coding gig with a cool company out of California. The interview was remote, the coding sample was remote, and the onboarding process was remote. I spent hours working for them sitting on the couch, in the basement, or on my front porch. I'd work in the evenings after my 9-5, or in the mornings on the weekends, or while waiting for my son during his scout meeting.
And it was fun. I really enjoyed the focus I got from working remotely. So when it came time to leave my previous employer, I knew that the ability to work remotely was going to be one of my base criteria for what a new job would have to look like for me to even be interested.
Note: remote work is harder to find than I thought it would be. Of the many companies I talked to, a very small fraction of them enabled remote work. Given the benefits that can accrue to an employer, not the least of which is more engaged and enthusiastic employees, I was shocked. Butt-in-seats management is still firmly entrenched within organizations.
But persistence paid off. I had time, and I spent it finding the right opportunity. On March 3, I started at my latest gig. My new organization has an office downtown Chicago that I've driven to a few times, but for many weeks, I've done my work from the basement of my house.
I have to admit. It's the greatest thing ever.
Full disclosure, there's more than remote work contributing to my excitement. I'm working for a much smaller organization. They know exactly what we need to do, and have pretty awesome processes either in place or in flight. On top of that, my new colleagues are all brilliant, and I can learn a lot from each of them. And am learning a lot. In all these regards, it's very different from where I came from.
As such, I can't necessarily attribute how awesome things are to the remote work. So I thought I'd try to take a balanced look at my experience with being remote a couple months in:
Pros
More exercise: Right out of the gate, there is more time available to exercise. Between having built a treadmill desk for walking as I work and doing things with my colleagues like the squat challenge, there's more of a focus on getting moving than I had before.
More work: Maybe I mean "more productivity" here, but I feel as if I get so much more work done. When you're not faffing about in the office getting stopped in the hall about ten different things, you can really get stuff done. With nothing distracting you, it's amazing how in the zone you can get.
More family: I'm putting this one in the more theoretical category, since I joined a team in full-barrel crunch mode moving toward a product launch, but I'm confident that in the weeks ahead, now that we're calming down, I'll be able to spend more time doing things like getting the kids off to school and having coffee and lunch with my wife. I'm looking forward to that.
More freedom: At home, you don't have the same level of scrutiny over your internets as you do at an office. If I want to stream trance music over the speakers or listen to talk radio in the background, I can do that. I'm not restricted to only receiving corporate mail over Outlook, and don't have to worry that all of a sudden GitHub.com or Knockoutjs.com will suddenly be blocked by the Corporate Nanny-Wall (both of which have happened to me).
More flexibility and fewer clothes: The school also called me to come pick up my daughter, who had strep. I went over to get her and was back coding in about 10 minutes. And she was upstairs resting while I was there. That is some flexibility right there. That was also the first time I've ever had to say, "Shoot, I need to run out. Where are my pants?" (I often work in running shorts because I use the treadmill desk on and off.)
Smaller environmental footprint: This doesn't appeal to everyone, but I like to try to reduce my environmental footprint. Not because I'm an environmentalist, but because I am resource-conservative at heart, in the sense that I only like to use what I need and use what I do need efficiently. When two weeks went by without having to put gas in the car, a little part of me did a happy dance.
Email: Working with my team, we depend on chat, and are in direct communication all day, every day. As such, the need for email is basically nil. We use it for broader, more consistent and more persistent topics, although for real stuff, we tot it up in Google docs and throw it in the cloud. I can't tell you how little I miss having a life run by Outlook. I've been moving away from it mentally for a while, but to finally get away from it is so lovely.
Dress code: My whole working life I've been biz-cazh. High school was shirt/tie. I always felt that I got more in the spirit of working when dressed up. Like formality was learning. Sure, when I was in grad school, I wore shorts and T-shirts to teach labs, but that was Tucson, and no one wears a lot of clothes there. But I did have the aforementioned "pants" epiphany. I often wear running shorts so I can walk while working, or even wear jammies up until lunch because they're comfy to walk in, too. Don't judge.
Cons
Diligence: I don't know that it's a con, really, but diligence is a key requirement of having the right personality to work remotely. It's been written about endlessly, that there's a real need to physically separate from the rest of the home to enable you to retain focus on your work. Also, being diligent and focusing on your work can be really exhausting. Being extraordinarily productive from home is well more difficult than being in the office.
Balance: This is kinda the flip side of diligence. I'm struggling a little bit because I'm an early riser, but the business hours for my org are 9-6. What that means practically is that I am often up early, and since I'm up early, I jump online and start working, sometimes at 7:30. Also, while I totally believe in the need for breaks, folks all take lunches at different times, so I hear the siren song of the chat window. I find myself in the basement and working longer hours that I probably need to, and certainly longer than is sustainable, but I'm enjoying what I do.
Chat: So the way we communicate on my team is through a chat app. This is very nice in that it is always open and on. Once you get the hang of it, you can see what's going on peripherally and it's not really different from overhearing chatter in the office. But sometimes... Sometimes you look at what someone's typed in the chat window and go "huh?" because what they've chatted makes no sense. At least out of the context of sound and expression. Another thing that can be burdensome about chat is that when there's a flurry of conversation that you don't want to be part of, you may need to turn off the notifications or sounds.
Cleaning service: One of the things I didn't realize was that my work area in the office didn't stay clean on its own. In the office, we had a cleaning service. If I dropped a Dorito on the floor, no worries. Gone the next day. In a home office, if you spill your coffee, guess who's mopping that up. I hadn't thought about that. Not that I have a lot of coffee-soaked corn chips on the floor, but I noted the need to be a lot more careful when eating around the work space.
Miscellany
Costs: You'd think that costs would be basically a pro. I haven't really analyzed the data, but I think I'm net #winning for the cost side of things. I don't pay for dry cleaning anymore. I wear fewer outfits per day. I'm paying less in gas. Car insurance has dropped. I have to pay for food, but since I generally eat up leftovers that were getting thrown away anyhow, I think I'm doing it for free most days. That said, I have to have and maintain my own office, and any associated costs.
Loneliness and isolation:
I was warned very sternly about this. The idea of being in my basement, not interacting physically with many people, is supposed to somehow be a drag, but I find it kinda the opposite. I mean, with the chat and video and voice calls, I interact with my team at a rapid fire pace. The rest of the time, I sit here by the window, lost in my head and the code and the issues I'm dealing with. For me, it's a great mix. So far, but I hear that like traveling, it can get old. If it does, I'll be sure to post about it when that day comes.
Wednesday, April 30, 2014
Pain-Driven Prioritization
How do you decide what's top on the priority list?
There's lots of methods, to be fair. I've always been a big fan of looking for the items with the largest Return on Investment (ROI). The idea with this method of prioritization is that you have a portfolio of possible projects, and you figure out how much each will cost and what dollar value you could assign to the benefits of doing the project.
In the CFA curriculum, this is all discussed in the context of investments. You want to figure out what a project is worth, so you make a few assumptions about the benefits, tot up what you know about the costs, net them out and project them back into today's dollars. You end up either calculating the Net Present Value, or the Internal Rate of Return on investment, sort by that, and then make the biggest one your priority (to first order). The discussion of these concepts is bigger than this little blog, but let me simplify.
All these things come down to always doing projects first that will give you the biggest bang for your buck.
And that's all good. Figure out which project is the best spend of today's dollar to net you solid expected returns. Some projects fold, estimations can be off, but if you have a diverse portfolio of projects and you're honest about your costs and benefits, these techniques can really work for you in the long run.
But what if you can't do that? Some companies can't do this. They either lack the talent of estimation, or the future is too murky to do projections, or all projects they look at have the same return, or even the organization is such a mess that any form of planning never really happens. What can an organization like that do?
Well, one tech department I've worked with used, in part at least, a technique I always called Pain-Driven Prioritization. Let's take the case of a very manual development process. If you have three things that might possibly help the process along and only finite resources, what do you do?
You figure out what hurts the most and fix that. If you can spend a few hours automating your build process, or your deployment mechanism, or how you manage tickets, it's time that will be saved down the road. Sometimes it's not the time savings, it's the friction savings. If you can cost your developers fewer packet drops due to context switching and keep them focused on adding the business value that matters, you come out ahead.
You may be correctly thinking, "Well, this is still nothing more than bang for your buck, right?"
Precisely.
So why does this work, and why does it feel like such a different perspective to me? Because it allows you to interview people and say, "Okay, this process is painful. Where does it hurt?" I've found, that if confronted with a question about how to improve their day, the response is usually about removal of roadblocks, or getting rid of annoyances. It's hard for me to overestimate the power of improving people's days by removing the annoyances they face.
Ask any team, "Where is your pain?" They can tell you. Why have they not done what it takes to be out of pain? Because they have goals, deadlines, business requirements to implement. And they're not automatically wrong in doing this.
You can't sharpen your saw after every stroke, but you can't let it dull for years either. Somewhere in there is the right responsible moment to pull out the rasp.
So take an assessment with your team. Or extend it beyond the team to the business customers you serve. Where is the pain? Let the pain be your guide.
I guess there's another name for this type of prioritization. It's triage, and maybe we should begin using that term more in our communities when it comes to setting priorities.
There's lots of methods, to be fair. I've always been a big fan of looking for the items with the largest Return on Investment (ROI). The idea with this method of prioritization is that you have a portfolio of possible projects, and you figure out how much each will cost and what dollar value you could assign to the benefits of doing the project.
In the CFA curriculum, this is all discussed in the context of investments. You want to figure out what a project is worth, so you make a few assumptions about the benefits, tot up what you know about the costs, net them out and project them back into today's dollars. You end up either calculating the Net Present Value, or the Internal Rate of Return on investment, sort by that, and then make the biggest one your priority (to first order). The discussion of these concepts is bigger than this little blog, but let me simplify.
All these things come down to always doing projects first that will give you the biggest bang for your buck.
And that's all good. Figure out which project is the best spend of today's dollar to net you solid expected returns. Some projects fold, estimations can be off, but if you have a diverse portfolio of projects and you're honest about your costs and benefits, these techniques can really work for you in the long run.
But what if you can't do that? Some companies can't do this. They either lack the talent of estimation, or the future is too murky to do projections, or all projects they look at have the same return, or even the organization is such a mess that any form of planning never really happens. What can an organization like that do?
Well, one tech department I've worked with used, in part at least, a technique I always called Pain-Driven Prioritization. Let's take the case of a very manual development process. If you have three things that might possibly help the process along and only finite resources, what do you do?
You figure out what hurts the most and fix that. If you can spend a few hours automating your build process, or your deployment mechanism, or how you manage tickets, it's time that will be saved down the road. Sometimes it's not the time savings, it's the friction savings. If you can cost your developers fewer packet drops due to context switching and keep them focused on adding the business value that matters, you come out ahead.
You may be correctly thinking, "Well, this is still nothing more than bang for your buck, right?"
Precisely.
So why does this work, and why does it feel like such a different perspective to me? Because it allows you to interview people and say, "Okay, this process is painful. Where does it hurt?" I've found, that if confronted with a question about how to improve their day, the response is usually about removal of roadblocks, or getting rid of annoyances. It's hard for me to overestimate the power of improving people's days by removing the annoyances they face.
Ask any team, "Where is your pain?" They can tell you. Why have they not done what it takes to be out of pain? Because they have goals, deadlines, business requirements to implement. And they're not automatically wrong in doing this.
You can't sharpen your saw after every stroke, but you can't let it dull for years either. Somewhere in there is the right responsible moment to pull out the rasp.
So take an assessment with your team. Or extend it beyond the team to the business customers you serve. Where is the pain? Let the pain be your guide.
I guess there's another name for this type of prioritization. It's triage, and maybe we should begin using that term more in our communities when it comes to setting priorities.
Monday, April 14, 2014
Get Rid of Useless Keys
Oh, I suppose we all do it. Struggle with little stupid things that bug me, without even thinking about ways to solve them. They are little problems in daily life whose frustrations don't even compound enough to make you think twice about them.
While trying to get something done this morning, I realized that I had accidentally hit the insert and caps lock key more than once this morning. I'm a touch typist, so it didn't occur to me that something was amiss until I looked up at the screen to see that there was an issue.
I realized that in my entire adult life, I have never hit one of those keys intentionally. Not once. To the point that I wondered who still used these abominations and why they were still on the keyboard. I wondered if there was an easy way to disable them. Google gave me several answers, some of which were very outdated, but one that hit me as an industry standard way was to use AutoHotKey (AHK).
You can read about AHK at their site, but it basically is a little script that runs in the background and intercepts keystrokes, allowing you to do something when a certain hotkey is pressed. On Windows-P, run some program, let's say.
So I downloaded it and with the following snippets I got from the AHK forums, I disabled both the Insert and the Caps Lock key.
While trying to get something done this morning, I realized that I had accidentally hit the insert and caps lock key more than once this morning. I'm a touch typist, so it didn't occur to me that something was amiss until I looked up at the screen to see that there was an issue.
I realized that in my entire adult life, I have never hit one of those keys intentionally. Not once. To the point that I wondered who still used these abominations and why they were still on the keyboard. I wondered if there was an easy way to disable them. Google gave me several answers, some of which were very outdated, but one that hit me as an industry standard way was to use AutoHotKey (AHK).
You can read about AHK at their site, but it basically is a little script that runs in the background and intercepts keystrokes, allowing you to do something when a certain hotkey is pressed. On Windows-P, run some program, let's say.
So I downloaded it and with the following snippets I got from the AHK forums, I disabled both the Insert and the Caps Lock key.
CapsLock::SetCapsLockState, alwaysoff
!CapsLock::SetCapslockState, On
$Insert::return
!Insert::Send, {Insert} ; Alt+Insert toggles 'Insert mode'
Friday, April 4, 2014
DVCS and the Pinocchio Test
I also know that there are some folks out there still using VSS. Stop. Do you not listen to your architects? Do you like having to deal with exclusive check-in/check-out locks? What's the matter with you?
Even TFS, with its central hub, seems a bit quaint to anyone not stuck in a Corporate IT gig where you're forced to go with an on prem solution. Sheez, at least move that stuff to TFS online. But whatever. At least you can merge and have simultaneous editing.
Yeah, I feel all the cool kids tell me they're using DVCS systems. Cori Drew got me excited about git (though I don't use the powershell command line personally), and I've since used it for both part time work and my personal projects. In my new organization, we're using Mercurial, so I'm getting to see this side of things now. My only personal regret is that I missed the Subversion era.
And for the most part, these DVCS systems are awesome. There are some hassles, and you can get yourself in a real twist if you're not careful with branches, but overall, I quite like the experience.
One of the biggest issues I have with using DVCS systems (doesn't matter, Git and Hg have the exact same issues) with .NET is that the .csproj files are so fragile. Two people want to add files and/or references to the project at the same time, and Visual Studio seems less than consistent about where it puts stuff, often leading to merge conflicts. And get that merge wrong, and whoo, you are in for some rollbacks.
So here's my recipe on how to handle this.
- if you're going to add a file or reference, do that first. Add the empty file and the reference and check that in immediately. You're adding an empty file or reference, so generally you're not going to break the build. The point is to keep that .csproj file change open and out there for the minimum amount of time.
- I like to make sure that my tests are picked up and running, so I'll often write a Pinocchio test. What's that? Goes like this:
namespace MyNamespace
{
[TestFixture]
class MyTests
{
[Test]
public void PinocchioTest()
{
//I wish I were a real test
}
}
}
Sunday, March 9, 2014
You Should Leave Your Job
Here we are again. I'm talking to you. It's just us here, and no one is listening. Clear your mind. Take all your preconceived notions about what you were going to do today and toss them out the window. What I'm going to say may shock you.
You should leave your job. Soon. I mean it. Start looking today.
Look, you know and I know that life is too short to hate your workday. Let's make a huge assumption: 8 hrs of work a day + 30 minutes lunch + 30 minutes * 2 for commute = 9.5 hrs of your 16 hour day. That is 60% of your useful day. If you eat or work longer or are further away from work, the numbers get worse. The numbers get better if you're willing to skimp on sleep for a longer useful day.
You know that every keystroke you give someone is a gift, right? In this great presentation, Scott Hanselman suggests you check this out. Are you giving the gift of your limited keystrokes to the right people? For the right reasons? Do those keystrokes match up with your values? Are you giving gifts that others want and only you can provide or are you buying generic gifts that the recipient will ooze with "meh" over.
I've seen your situation before. You're dark matter. You're a 5:01 developer. When you got to the organization you're in, you loved the first project you were put on. You were hired specifically for that project, so it met your idea of what you'd be doing when you signed on. You put in lots of time learning, showing people you were excited, showing you could be counted on to deliver.
You were enthusiastic.
But that was years ago. That was a couple CTOs ago. That was a couple technology strategy direction changes ago. The organization has moved on and you've adapted to provide it value, but maybe your day-to-day is not what you wanted to do. Shoot, it's a convenient commute. The compensation's right. Family health matters made it inconvenient to take on a change at that time.
You like what you did at the organization in the past, but now there's very little to do. You're in maintenance mode for the product you were hired to build. Management appetite for new development is nil because of cost cutting. You've been told to keep the lights on. Leadership doesn't want to spend time adding new features because they would rather buy a replacement system, but never seem to actually complete the research to buy that replacement, resulting in continued use of subpar tools, and missing opportunities to sharpen developer chops.
You're a developer, but because of "budgetary constraints", the organization is not allowed to staff a team that develops software appropriately. So you are doing business analysis or QA, because there's no one in those roles. In agile teams that's something that's expected of everyone, but your projects aren't agile. You spend a lot of time writing up documentation that never gets used or read.
The excellent team you signed on with? Excellent teams are an unstable equilibrium. If you were on a tiger team of development that does everything right, did your organization split it up to "seed" the talent in multiple places, not realizing that it's the team that did things right, not the individuals? Great people working on excellent teams get recruited to join other excellent teams. So maybe your team fell victim to entropy.
So that team is no longer. Maybe that was many reorganizations ago, before many different sets of leadership came in and tried to optimize output of a fixed group of resources.
Maybe your organization favors butt-in-seat over other productivity metrics. For that reason, you can't work from home, contributing to that feeling of wasted commute time. Collaborative technology is discussed, and maybe even experimented with, but because not enough people are using it, it's never optimized. Time-shifting is not allowed to enable you to work at your most productive times.
Maybe you're on a support rotation. That wasn't in the original sign-on agreement, but "You know... We all have to be team players", and you don't really mind since it's not all that often. Although when it does, even though comp time should be an expectation, it's never discussed.
Yeah, maybe this describes your situation. Maybe only some of it does. If it does, however, you should leave your job.
But maybe you're not convinced to move. You're too complacent. You're comfy. This job thing is a solved problem and you don't think you'll ever really need to look for another one. You can coast out your career on your current skill set.
Maybe, but I've put together a few signs that it might be time to consider moving on.
Signs
Symptoms
If all of this resonates with you, call a recruiter today. Shoot, call me. I know enough recruiters and folks at good places to be a good resource, and I'm happy to help you find your passion. If you just want to talk, I'm here too. You'd do well to find yourself a mentor, too.
And if you're happy with your gig, good on you. Come on out and be part of the community.
I just want you to be happy. Yes you.
You should leave your job. Soon. I mean it. Start looking today.
Look, you know and I know that life is too short to hate your workday. Let's make a huge assumption: 8 hrs of work a day + 30 minutes lunch + 30 minutes * 2 for commute = 9.5 hrs of your 16 hour day. That is 60% of your useful day. If you eat or work longer or are further away from work, the numbers get worse. The numbers get better if you're willing to skimp on sleep for a longer useful day.
You know that every keystroke you give someone is a gift, right? In this great presentation, Scott Hanselman suggests you check this out. Are you giving the gift of your limited keystrokes to the right people? For the right reasons? Do those keystrokes match up with your values? Are you giving gifts that others want and only you can provide or are you buying generic gifts that the recipient will ooze with "meh" over.
I've seen your situation before. You're dark matter. You're a 5:01 developer. When you got to the organization you're in, you loved the first project you were put on. You were hired specifically for that project, so it met your idea of what you'd be doing when you signed on. You put in lots of time learning, showing people you were excited, showing you could be counted on to deliver.
You were enthusiastic.
But that was years ago. That was a couple CTOs ago. That was a couple technology strategy direction changes ago. The organization has moved on and you've adapted to provide it value, but maybe your day-to-day is not what you wanted to do. Shoot, it's a convenient commute. The compensation's right. Family health matters made it inconvenient to take on a change at that time.
You like what you did at the organization in the past, but now there's very little to do. You're in maintenance mode for the product you were hired to build. Management appetite for new development is nil because of cost cutting. You've been told to keep the lights on. Leadership doesn't want to spend time adding new features because they would rather buy a replacement system, but never seem to actually complete the research to buy that replacement, resulting in continued use of subpar tools, and missing opportunities to sharpen developer chops.
You're a developer, but because of "budgetary constraints", the organization is not allowed to staff a team that develops software appropriately. So you are doing business analysis or QA, because there's no one in those roles. In agile teams that's something that's expected of everyone, but your projects aren't agile. You spend a lot of time writing up documentation that never gets used or read.
The excellent team you signed on with? Excellent teams are an unstable equilibrium. If you were on a tiger team of development that does everything right, did your organization split it up to "seed" the talent in multiple places, not realizing that it's the team that did things right, not the individuals? Great people working on excellent teams get recruited to join other excellent teams. So maybe your team fell victim to entropy.
So that team is no longer. Maybe that was many reorganizations ago, before many different sets of leadership came in and tried to optimize output of a fixed group of resources.
Maybe your organization favors butt-in-seat over other productivity metrics. For that reason, you can't work from home, contributing to that feeling of wasted commute time. Collaborative technology is discussed, and maybe even experimented with, but because not enough people are using it, it's never optimized. Time-shifting is not allowed to enable you to work at your most productive times.
Maybe you're on a support rotation. That wasn't in the original sign-on agreement, but "You know... We all have to be team players", and you don't really mind since it's not all that often. Although when it does, even though comp time should be an expectation, it's never discussed.
Yeah, maybe this describes your situation. Maybe only some of it does. If it does, however, you should leave your job.
But maybe you're not convinced to move. You're too complacent. You're comfy. This job thing is a solved problem and you don't think you'll ever really need to look for another one. You can coast out your career on your current skill set.
Maybe, but I've put together a few signs that it might be time to consider moving on.
Signs
- Don't like working on what you're working on
- Don't like who you're working with
- Don't like your immediate manager
- Don't feel as if the discourse is civil or nonconfrontational
- Don't believe in management's vision or goals
- Don't believe in your management's ability to make good decisions
- Don't feel valued for your contributions
- Don't feel the tasks in front of you are very exciting
- Don't feel focused enough on any one thing
- Don't have clear reporting structures; have overmatrixed teams
- Don't feel like your organization can prioritize
- Don't feel like productivity is as important as appearance
- Don't feel like the organization is moving forward quickly
- Don't feel like the organization makes data-based decisions
Symptoms
- Very peaked/deep org structures indicate a problem with reporting. Need a low ratio of managers/doers.
- Lack of information flow
- Lack of recognition
- Lack of celebration for hires or promotions
- Lack of visible employee enthusiasm
- Lack of unity of processes across divisions
- Too many junk drawers
- Too much reliance on transition plans (which don't work)
- Lots of Not Invented Here silos of experience
- Headcount is kept flat regardless of technical investment or debt reduction
If all of this resonates with you, call a recruiter today. Shoot, call me. I know enough recruiters and folks at good places to be a good resource, and I'm happy to help you find your passion. If you just want to talk, I'm here too. You'd do well to find yourself a mentor, too.
And if you're happy with your gig, good on you. Come on out and be part of the community.
I just want you to be happy. Yes you.
Tuesday, January 7, 2014
Walking Desk
I'm always looking for new ways to work. I have never hidden my opinion that the cube farm is the worst of all possible worlds, lacking the productivity of the war room/pit, and lacking the privacy and clarity of mind of the office. And cube farms almost never offer the whiteboard capability of either of those.
But my criticisms do not end with the workspace. It's widely noted that a sedentary lifestyle, lived by most tech and knowledge workers, is devastating to health in the workplace. (Check out Get Up and Code for some more motivation than I can muster.) So many developers and other cube-dwellers do nothing but sit for 8 hours a day, using barely-if-at-all ergonomic equipment, most of the time with crappy posture.
So anything that gets a knowledge worker up and out of their seat is a good thing in my book. I love the idea of walking meetings, and I've often had many productive business conversations while walking on the office walking trail. Companies that have walking trails should promote their positive use more and encourage people to do their business in a very healthy way.
So it should come as no surprise that I have been following the trend in the tech culture of hacking your workspace to include those sit-balls, standing desks, and even treadmill desks. Stand while typing? Walk while typing? Walk while coding? Is this uber-productive and healthy, or multi-tasking gone mad?
Hanselman suggests in one of my favorite presentations of all time that one way to make more hours in the day is to do things while exercising. Netflix + treadmill FTW, for example. So it sure makes sense that those of us that work at computers all day should be able to make some use of a standing or treadmill desk.
Walking and standing desks are not really even that novel by now. This experiment has been tried and written about. Over and over and over again, to be sure. I wouldn't call the concept mainstream, by any means, but it's not really new.
For example, I talked to someone at the office that wanted to try a standing desk as maybe being a little easier on the back. I think that's a reasonable request to make, but the individual I spoke to offered that they didn't want to stick out and be the lone person with one-off or weird equipment. It's a little sad to me that someone I know is afraid to ask for something that will physically help them because the culture doesn't encourage them to find the best way to work for them.
So score another one for remote work. In your home office, you have the freedom to set it up the way you want. I recently talked to a company whose entire tech staff all had some form of walking desk, and they all worked from a home office. They suggested that I at least give it a try.
Sounds good. I like to try things.
I have a treadmill that has pretty solid arms on it for support, so I thought I could probably fashion a temporary desk to try it out. I happened to have an 8 ft scrap plank that was just the width of these arms, and some old scrap 2x4 for stabilization. Here's what I came up with...
The Buildout
It starts with the bare treadmill. You can see the arms that I'm going to place the plank on.
Nothing more than a strip of plywood cut to length with a couple 2x4s deck-screwed onto it. The 2x4s sit just outside the rails so that the whole thing won't move left to right.
I placed the support over the beams. It fit perfectly. Here it is with the laptop sitting on it. Trouble is, those bars are around waist level. That means that my arms would be almost fully extended to type. It was not comfortable to either look at the laptop or type.
So we dreamed up a little top extension. A platform on the platform, as it were. This was made from the rest of the sheet of plywood from the platform itself and a couple scraps of 3/4" particle board we had remaining from one of our prior years' Halloween projects.
And once we put it in place, we saw a couple things. One, the height was perfect. Two, the support sides for the top extension hit the front handrest/heart rate sensors (I never use these, so I don't mind covering them). I was going to have to notch those out.
I build a lot of stupid little things around my house out of plywood and 2x4, when a rough construction will fit the bill, but I really don't like the look of unfinished wood. I also don't have a lot of patience for stain, and don't like the cleanup of painting, but spray paint, spray paint I can do. I took out a can of leftover black, and Gamble and I painted the pieces.
Then we waited for the paint to dry. It took forever, like watching paint dry. Then we screwed the top to the bottom, and put it up on the treadmill:
Here's the final product. When not using a laptop, you can still see the stats fine, and it's only a bit of a reach to hit the numbers. With a laptop, however, you can see precisely nothing. That's kinda good, because as anyone who uses a treadmill can tell you, sometimes it's more motivating if you forget how far you've gone (see throw yourself at the treadmill and miss).
The Verdict
I can't give you a full verdict just yet, since I only used it for a couple days before heading to Codemash. Once I had this built, I got on the treadmill. What I can say is that starting out, it's hard to get used to. The first thing I tried to do was read articles on my feedreader, and I found that the side to side motion of my head and body made it a little tough to concentrate on the screen.
I also didn't really know what speed to start at. Some people that use a walking desk recommend 2 mph, so that's where I started. I usually warm up at a walking pace of 3 mph and go from there, but given that this is meant for long periods of time, I figure I'll go slow. My treadmill doesn't really like speeds slower than 2 mph, so this seemed like a good place to start.
After 20 minutes, though, I found that sensation had gone away enough to try typing. I opened up Webmatrix and pulled open the source to www.kevinpdavis.com, I pulled down a NuGet package and included it in a sample page, just to get the feel of coding. It's a little distracting, and I didn't feel that I was super quick. It felt like each thing I did took extra time, but maybe that was just self conscious.
After I got down, I felt a little sore in my back and hips. It's been a while since I've been on regular exercise, so this isn't a huge surprise, but definitely unwelcome (that said, this is why I'm looking at using a treadmill desk, after all).
So this morning, I tried again. I've written this entire article while standing, and it's been relatively comfortable the whole time. I got right up to speed and started typing right away, and haven't really felt weird about it (well, maybe a couple times, but only for a minute or so). It's been roughly an hour, however, and I'm starting to get tight in the hips and back, so it's probably time to stop for now, right at the hour mark.
Another Attempt
For us coders, a big question is whether it's possible to get into the zone while walking. Can you concentrate on a difficult problem, using whatever tools you like, while walking. I very much wanted to figure it out, so I made another attempt, this time with some work I needed to get done.
And it turns out yes, it's totally possible to code. You eventually just kinda forget you're walking. Until you get tired, or you get a little thirsty (the shelf is big and sturdy enough, however, to handle a beverage on it, but remembering to keep hydrated isn't obvious).
One thing I did notice is that after I got off, I had sea legs, where it was almost weird to not be walking. I'd heard similar things from people who use walking desks, so it didn't surprise me that much.
If you have any feedback, recommendations, or experiences, I'd love to hear about them in the comments or on twitter @kevinpdavis.
But my criticisms do not end with the workspace. It's widely noted that a sedentary lifestyle, lived by most tech and knowledge workers, is devastating to health in the workplace. (Check out Get Up and Code for some more motivation than I can muster.) So many developers and other cube-dwellers do nothing but sit for 8 hours a day, using barely-if-at-all ergonomic equipment, most of the time with crappy posture.
So anything that gets a knowledge worker up and out of their seat is a good thing in my book. I love the idea of walking meetings, and I've often had many productive business conversations while walking on the office walking trail. Companies that have walking trails should promote their positive use more and encourage people to do their business in a very healthy way.
So it should come as no surprise that I have been following the trend in the tech culture of hacking your workspace to include those sit-balls, standing desks, and even treadmill desks. Stand while typing? Walk while typing? Walk while coding? Is this uber-productive and healthy, or multi-tasking gone mad?
Hanselman suggests in one of my favorite presentations of all time that one way to make more hours in the day is to do things while exercising. Netflix + treadmill FTW, for example. So it sure makes sense that those of us that work at computers all day should be able to make some use of a standing or treadmill desk.
Walking and standing desks are not really even that novel by now. This experiment has been tried and written about. Over and over and over again, to be sure. I wouldn't call the concept mainstream, by any means, but it's not really new.
For example, I talked to someone at the office that wanted to try a standing desk as maybe being a little easier on the back. I think that's a reasonable request to make, but the individual I spoke to offered that they didn't want to stick out and be the lone person with one-off or weird equipment. It's a little sad to me that someone I know is afraid to ask for something that will physically help them because the culture doesn't encourage them to find the best way to work for them.
So score another one for remote work. In your home office, you have the freedom to set it up the way you want. I recently talked to a company whose entire tech staff all had some form of walking desk, and they all worked from a home office. They suggested that I at least give it a try.
Sounds good. I like to try things.
I have a treadmill that has pretty solid arms on it for support, so I thought I could probably fashion a temporary desk to try it out. I happened to have an 8 ft scrap plank that was just the width of these arms, and some old scrap 2x4 for stabilization. Here's what I came up with...
The Buildout
It starts with the bare treadmill. You can see the arms that I'm going to place the plank on.
 |
| The invisible man went for a walk. Naked. In my shoes! |
Nothing more than a strip of plywood cut to length with a couple 2x4s deck-screwed onto it. The 2x4s sit just outside the rails so that the whole thing won't move left to right.
 |
| A very simple construction. |
 |
| The Invisible Man is now hanging out at the treadmill desk. Still naked, that perv! |
 |
| Here, Gamble helps me put together a top extension to the platform. |
 |
| Much better, but not perfect. |
 |
| Taggin'. |
 |
| Here you can see the finished piece. It's at the perfect height, and you can see the angle I cut the back of the top extension to fit. Note also, the Invisible Man has finished his workout. |
 |
| Sweet. The finished product. The paint is dry to the touch, but looks wet around the edges still. |
I can't give you a full verdict just yet, since I only used it for a couple days before heading to Codemash. Once I had this built, I got on the treadmill. What I can say is that starting out, it's hard to get used to. The first thing I tried to do was read articles on my feedreader, and I found that the side to side motion of my head and body made it a little tough to concentrate on the screen.
I also didn't really know what speed to start at. Some people that use a walking desk recommend 2 mph, so that's where I started. I usually warm up at a walking pace of 3 mph and go from there, but given that this is meant for long periods of time, I figure I'll go slow. My treadmill doesn't really like speeds slower than 2 mph, so this seemed like a good place to start.
After 20 minutes, though, I found that sensation had gone away enough to try typing. I opened up Webmatrix and pulled open the source to www.kevinpdavis.com, I pulled down a NuGet package and included it in a sample page, just to get the feel of coding. It's a little distracting, and I didn't feel that I was super quick. It felt like each thing I did took extra time, but maybe that was just self conscious.
After I got down, I felt a little sore in my back and hips. It's been a while since I've been on regular exercise, so this isn't a huge surprise, but definitely unwelcome (that said, this is why I'm looking at using a treadmill desk, after all).
So this morning, I tried again. I've written this entire article while standing, and it's been relatively comfortable the whole time. I got right up to speed and started typing right away, and haven't really felt weird about it (well, maybe a couple times, but only for a minute or so). It's been roughly an hour, however, and I'm starting to get tight in the hips and back, so it's probably time to stop for now, right at the hour mark.
Another Attempt
For us coders, a big question is whether it's possible to get into the zone while walking. Can you concentrate on a difficult problem, using whatever tools you like, while walking. I very much wanted to figure it out, so I made another attempt, this time with some work I needed to get done.
And it turns out yes, it's totally possible to code. You eventually just kinda forget you're walking. Until you get tired, or you get a little thirsty (the shelf is big and sturdy enough, however, to handle a beverage on it, but remembering to keep hydrated isn't obvious).
One thing I did notice is that after I got off, I had sea legs, where it was almost weird to not be walking. I'd heard similar things from people who use walking desks, so it didn't surprise me that much.
If you have any feedback, recommendations, or experiences, I'd love to hear about them in the comments or on twitter @kevinpdavis.
Friday, August 16, 2013
Bachelor Blitz
I’m not a bachelor, but a couple times a year, my lovely wife takes the kids to go visit remote family for a week. This leaves me as essentially a bachelor.
And when they’re gone, some of those bachelor tendencies creep in.
If I have a meal, it’s just one plate, fork, and glass. Into the sink they go! Load the dishwasher? Not likely!
Laundry? Heck it’s not building up quickly! Why do that? Take off your socks? Do they really need to make it upstairs to the hamper? Nope. On the floor by the couch they go.
Got packages from Amazon? Empty boxes pile up by the garage. Cats play with the packing materials and drag it around.
Painting the bathroom (my current project)? Between coats, the extra rollers, paint pans, and even the bathroom hardware off the walls sits on the kitchen island.
Playing video games between home improvement tasks? The controllers and remotes end up wherever they end up when you last left off.
So basically, it looks like a place under maintenance, crossed with a college dorm room.
But by the time the family comes home, this place has to be spotless. All hardware and home repair stuff stowed safely back in the basement or the garage. The dishes done and the sink clean. The laundry done and in baskets.
And I’ve done it every time. Did I have to spend the final 24 hours of every trip cleaning like a madman? Not at all. I manage this lifestyle with the periodic Bachelor Blitz.
Originally, I started “blitzing” with my kids. Like most kids, they hate to spend time cleaning up. But when Mommie’s out on a photoshoot, instead of telling them they have chores, I’ll tell them it’s time for a 15 minute blitz.
During the 15 minutes of the time-boxed blitz, we run around and find things that need to be done. Socks on the floor? Gather them up. Put the dishes in the dishwasher. Run the accumulated stuff to the basement. Run the vacuum through a couple rooms.
Sure, the purists would say that it’s better to take care of things as you go. That you should pick up after yourself as you go. I don’t really disagree, but for me that’s not always been practical. The 15 minute blitz done every couple hours is a solution I can live with
And when the family is gone, I actually schedule half-hour or hour long blitzes. I wash down surfaces, run the vacuum over the whole house, do several loads of laundry. During this time, I also do any very short repair tasks that might need attention. Sand a rough spot. Spackle a wall and touch up the paint when dry. Change light bulbs, spray down the house. Whatever it takes.
Blitzing is a great way to get things done, and is another great example of the adage that "small efforts, repeated over time, will almost always surprise you."
Saturday, May 11, 2013
How to Learn Even Faster
AHA! I figured out how to cram even more into a day, lunch hour, etc. Y’all may have known this - and if so, shame on you for not sharing – but Windows Media Player allows you to speed up playback up to x2, meaning that 20 minute tekpub video you’ve been meaning to watch will only take 10 minutes! Here’s the steps:
For easy use, right-click the play button and select Fast Playback (ctrl shift g) (which is 1.4 x speed)
Or bring up the main right-click context menu and select Enhancements > Play speed settings
That will bring up a dialog that will allow you to fine tune the speed all the way up to 2x (I’ve found that to be like dialing up to 11, so I generally just settle on the easy approach).
Now, no excuse not to learn that new framework you’ve been thinking about.
Subscribe to:
Posts (Atom)