Work

More things I’ve learned about Jenkins

/ hsoi / 1 Comment

At the day job, I’m still working with Jenkins and our build system. I’ve written about some things I learned at the onset, and now I’d like to add some things I’ve learned since then.

Plugins

Be mindful of them. There’s a great many out there that can help you solve things, but they seem to also bring much risk. For example, Jenkins was going belly-up at least a couple of times a day. I’d look in the system console and see some plugin that I wasn’t even using (just had installed) was somehow causing memory failures, throwing an exception, and Jenkins went stupid and had to be restarted. Once you figure out what plugins you need, uninstall every other plugin. Keep your system as minimal and tight as possible to avoid introducing risk or uncertainty.

Backups

I had to write a lot of custom scripts (some bash, a lot of ruby). These files I can keep in our version control system. But Jenkins files themselves are harder to do. Make sure you have a backup strategy. Make sure you run it often while you work. Working on a Mac and using Time Machine is useful… make a change, screw up, easy to revert.

Updates

Don’t apply an update unless the changelog shows it directly affects you. For example, the git plugin was just updated to fix a regression that prevented using env parameters in the branch name — I need that, so I upgraded that plugin. This goes back to the plugin issues I mentioned above… and if you screw up, it goes back to my backup issue I mention above. 🙂

Planning

Do your best to plan your jobs and pipeline. Figure out the abstract ideal that you want. Then figure what Jenkins can offer to get you there. You might find plugins, but you might also have to write your own scripts and other management.

Then, don’t be afraid to revise and revise again, even starting over if you have to.

DIY

I wanted to use a lot of plugins, because they’re supposed to make it easy, right? Well, it depends. The Xcode plugin is supposed to make it easier to do xcodebuild-based, builds. And in theory it does, but our needs are different and so I just have to get dirty with our own scripts.

The email-ext plugin is really cool, but I couldn’t get it to understand and bring in a bunch of env vars and do other bits of logic processing that we needed. So again, scripting to the rescue. Net::SMTP to the rescue.

CodeSign problems

I noticed from time to time that I’d start a build and eventually xcodebuild or ‘xcrun PackageApplication’ would fail:

“There are no valid public/private key pairs in the default keychain”

It seems this would happen after rebooting the machine (and Jenkins started up via the launchd stuff). I could manually use launchctl to unload then (re)load and things might be back to normal, but that’s annoying.

I found this post at stackoverflow.com, and adding the “SessionCreate = true” key/value to the launchd plist seems to do the trick.

But then further down things failed out. Despite the codesign command line tool being granted special Keychain access, it still hated life:

<path to build output app>: User interaction is not allowed.

Uh…

So I found this and added a:

security unlock-keychain -p "" login.keychain

in the custom ruby script before invoking xcodebuild and PackageApplication.

BTW, I don’t have the passwords encoded into the script. Remember the use of the .netrc file? Use that.

Speaking of .netrc… it seems curl doesn’t like a .netrc where newlines separate entries… it wants everything on one line.

Passing Data to Downstream Jobs

Using Jenkins’ parameterized build mechanism, I was able to pass parameters around. I’d have the main build job, which would then use the promoted builds plugin to allow me to move the build through a pipeline, like to promote to QA, then promote to the App Store, or whatever. But there’s a lot of information from the main build job that I want the downstream jobs to have so the jobs can be properly named, emails can be properly formatted, version control tags set up, whatever. I found the easist way to do this was at the end of the main build job to use a little ruby scripting, create a Hash with all the things I cared to preserve, use YAML to preserve it to file, make sure the build job archived and fingerprinted that .yml file, and moved that “config.yml” file along with the rest of my archives and promotions. Then it’s simple enough to load and look up key/values out of the config.yml file in the later job scripts.

Tagging Git

One of the downstream jobs is a “deploy to the Apple app store” job. Certainly when we do that we want to tag our github-hosted repository with info about the build so we can know what was deployed. Trouble is, at that phase of the build pipeline we don’t have source code. So we can’t just “git tag” then “git push”. What to do? Use the github v3 API. In that config.yml file I was able to preserve the SHA hash of the code we used, so that’s all we need.

At first I thought to use the Tags API, but as I played with that it didn’t work. Even if I could create a tag, it wouldn’t show up in the Tags area of my git GUI app SourceTree. In fact, it started to give errors about refs. So I started to play with the References API and tried things like:

$ curl -XPOST --netrc https://api.github.com/repos/:user/:repos/git/refs \
-d '{"ref":"refs/tags/MyTestTag","sha":"be43262431c7a4b9db67a23d37f51e7901b9845c"}'

and lo… that seemed to work.

Is that enough? Is that correct? I don’t know. I’m not an expert on the low-level plumbing of git. I have contacted github support, but as of this writing have yet to hear back.

The Journey Continues

That’s all that I have for now.

It’s a lot of work to set up a build system, but it’s rather satisfying to do it. I still have a long ways to go. Right now we just have the basics for building and deploying to help our general workflow. It still needs lots of work for validations, testing, continuous integration, and other good stuff like that. One step at a time.

Setting up Jenkins… things I’ve learned so far

/ hsoi / 3 Comments

At the day job I’ve been tasked with setting up an automated build system. This is a Good Thing™ and I actually volunteered to do this task. I’m interested in doing what can help us make our code better, deliver our products faster, and make our lives easier in terms of automating things we don’t necessarily need to be involved in. So a Mac Mini was obtained to be a build machine, and I’ve been working to set things up.

I should note that I’m not a dedicated buildmeister. I know at larger companies they can have a person (or persons) whose full-time job is dealing with builds, but I’ve never been one of those people. I’ve done some build hacking in the past, but it was always homebrewed scripts and systems. This time around, let’s use an established system instead of homebrew.

It seems the modern hotness is Jenkins. Yes there are other options, but all signs via Google searching point to it. As well, it seemed (note the verb tense) like the more Mac-friendly solution. If nothing else, it had a nice Mac OS X installer. 🙂

I’m still far from having our complete build system, and I reckon as I learn more things on this list will change. But I’ve already learned a few useful things and I felt like sharing and adding to the greater knowledge-base out there that, through Google-Fu, helped me get this far. Maybe with my additions, someone else can be helped and maybe with a little less frustration and time sink.

The Project

A little context about the project being built.

Working on Mac OS X, developing iOS apps. Thus we’re using Mac OS X 10.7 Lion as our dev runtime environment. We’re using Xcode 4.3.3. Jenkins is version 1.474. We use git and a mix of private and public repositories on github.com.

First Time Problems

Started with a brand new, fresh from the box Mac Mini. Of course, before attempting any of this CI-specific work, the box was brought up to date with OS updates, Mac App Store updates, and so on. Note! Jenkins is a Java app and Java is NOT installed by default. So after you run the Jenkins installer and it tries to start Jenkins, things will probably fail. The OS will prompt you to install Java, so you’ll have to do that, but then Jenkins should end up running. Not a big hurdle, but it’s there.

Make sure to launch Xcode.app (the GUI app) and get it properly happy. This is mostly ensuring the various downloadable components get downloaded and installed, like command line tools and such.

You will be using command line tools, thus you will have to run xcode-select. But being as this is Xcode 4, things are different.

$ sudo /usr/bin/xcode-select -switch /Applications/Xcode.app/Contents/Developer

This will ensure xcodebuild can be found. And note, the first time you run xcodebuild, it won’t run! While you agreed to the license agreement when you first launched the GUI Xcode.app, that’s not good enough for xcodebuild; you have to agree to it all over again via the command line. Just be aware. It’s not a big deal, it’s a first-time-only occurrence, but it’s there to deal with.

The User (login) Matters

This was the source of much fun and frustration for me.

The first time I installed Jenkins I had no idea what to expect. That it had a proper Mac OS X Installer .pkg was cool, but it was also hiding a secret. Any time there’s a “Customize” button I like to click it and see what options there are. I noticed it provided two options:

  • Start at boot as “daemon”
  • Start at boot as “jenkins”

I had no idea what the relevance of these two options were. The default was “daemon” and “jenkins” was unchecked. I just figured to trust the default installer settings. Ha ha ha…  This actually caused me the most trouble and pain. I won’t recount the many hours spent dealing with this, but I will explain the issues.

I opted to go with the installer’s default of “daemon” but that creates a problem because “daemon” is a special user. When Jenkins needs to do things, it’s going to look in non-typical places, like /var/root for ssh keys or the like. Basically, it’s going to cause you a lot of headache.

When you search around for information about this, everyone starts to talk about using the “dscl” command line tool to create a hidden secret “jenkins” user and run Jenkins that way. This makes sense because it creates a user of restricted ability so it helps to keep the system secure and minimize chance of damage should someone gain access to the system via the Jenkins system or login. But in practice, this turned out to be a big pain in the ass because of what we’re doing. I’m sure there are some projects where this won’t be that problematic. But writing iOS apps brings issues. Apple makes great products, but you find they are great as long as you color within the lines; the lines might be really wide and vast, but still you must color within them. Trying to deal with this secret “jenkins” user created various issues.

For Xcode (or xcodebuild) to do code signing, it needs access to private keys and certificates and other such things. Thus the Keychain is involved, but this hidden “jenkins” user doesn’t have one. Again, more searching will turn up possible solutions, but they are not ideal solutions. In fact, one solution of putting these into the “system” keychain really defeats the purpose doesn’t it? Then there are the .mobileprovision files needed during the signing process, and those must exist somewhere in the “jenkins” user structure. In my case, the provisioning files may be updated fairly often due to the addition of device UDID’s, and setting up the initial .mobileprovision files by downloading to the logged in user then copying it all into the hidden jenkins user locations… it was just turning into a massive pain in the ass. And you’ll have to do this at least once a year, when you renew your iOS account with Apple.

So I fumbled with various permutations of these user setups and it was all just frustrating to me.

In the end, I backed everything out and started over (for the umpteenth time). I created a “jenkins” user via the System Preferences. That is a full-on login-able user named “jenkins”, admin user. I then logged in as the “jenkins” user. I ran the Jenkins installer, customize, and selected the “start at boot as ‘jenkins'” option (and deselected the “start at boot as ‘daemon'” option). I ran the installer. That did not immediately succeed, but the resolution was simple. Stop the daemon (using launchctl). Edit the .plist for the Jenkins launchd job and changed the location of JENKINS_HOME to /Users/Jenkins. Then restarted the machine. Life was good.

I think today I’m going to try doing it “yet again” tho… deleting the Jenkins user and creating it again, then installing again, and this time making a subfolder, like /Users/Jenkins/Jenkins_CI or something like that. That’ll contain all the stuff in one folder and not litter the actual home directory.

Is this the right thing to do? Well, from a pure security standpoint, no. It’s now an admin user that can log in and have all sorts of fun. But my feeling is this machine will be behind our firewall. If this box gets compromised, we have bigger problems anyways.  Could it mean bigger problems for me down the line with Jenkins-CI itself? Maybe. We’ll see. I’m not necessarily advocating taking this approach, but it’s just the one I’ve presently taken. It appears that it will create less long-term hell for me, especially in dealing with Xcode and the OS.

Authentication

Another source of pain was dealing with authentication issues.

Since we use private repositories on github, we need to authenticate. This proved to be more difficult than it should have been.

When I first tried a basic build of our project, I installed the various git plugins within Jenkins, created the new job, set it to obtain the source via the http protocol, and off we go. Well, that failed. The job just hung forever, I reckon waiting for authentication. So how can we authenticate? I saw no configuration options for it. So I started playing with ssh.

ssh would actually be a good thing in many ways, but with all the aforementioned user/login issues, it was becoming a massive pain. The way Mac OS X seems to handle ssh is by launching the ssh-agent on demand. Well… it can’t do that for the secret jenkins user. I tried all sorts of things, but I just could NOT get it working. *sigh*   Another vote for making a fully-realized jenkins users instead of this secret hacked one.

The one thing I had to then do was edit my ssh keys to not have a passphrase, and that would work (no need for ssh-agent, no need for interactive issues). But lacking a passphrase ain’t so hot. But it seemed to work… well, at first.

The next problem? Our git project has submodules. In the .gitmodules list, the “url” for each submodule used http as the protocol. And so, when the Jenkins-CI git plugin tried to obtain the submodules, we were back to the original problem. FML.

I tried fiddling with the repository URL as specified in the “git” section of the Jenkins-CI job to be something like:

https://:@github.com/path/to/repo.git

and while that worked for the top-level repository, the submodules still tripped me up. Plus, I did not like the idea of storing a password in plain text and sight like that.

I was able to solve it tho… through the magic of the .netrc file.

I created the following file in /Users/jenkins/.netrc

machine github.com
login <github username>
password <github password>

Saved it. Did a “chmod 600” on it. And lo…. everything worked. Huzzah!

I think the git plugin should have a way of doing authentication, but I’m still too much of a Jenkins n00b to know really where the fault lies.

More Ahead

At this point, I’m able to clone our git repository and build the app. It’s very basic at this point, with much configuration and fiddling yet to come. But I spent a good deal of time on these matters this past week and tried to sift through a bunch of search engine results to wind up here. So much of the information out there is Linux or Windows based, which is fine for the general but some of the little details aren’t there. And I can’t imagine we’re the first people to need to build in such a way, but I just couldn’t find anything specific to the particulars of our setup. So here’s hoping this helps contribute back.

As well, if you the reader have any information, insight, comment, etc. please share. I’m still learning, and constructive contribution is appreciated.

Trying Trello

/ hsoi / 3 Comments

The new hotness in software development is “agile“. At my prior day job, it was waterfall. Sure they tried to adopt agile processes, but it really wasn’t going to happen. Due to the nature of the products and process, it just can’t be agile, tho they could try to adopt a few things and make some improvements. But at my new day job? Agile can make a LOT of sense. Take home: you can’t impart the process merely because it’s the new hotness or you think if you just adopt X process it’ll solve problems. Like any problem to be solved, you have to understand your problem fully and then apply the right tools to solve it, and that includes what processes you use.

However, it’s tough getting folks on board, so I’ve desire to try to sneak in agile stuff as we can. It’s nothing more than a commentary on human condition — we tend to resist change. If all this change is dropped on folks all at once, we’ll balk. I would too. Massive sudden change, especially when you’ve still got daily chaos and stress to manage, well… the change will be rejected. But if we can make little changes here, little changes there, over time we get there.

One thing I can tell is we all need a way to see the whole picture. We’ve got so many things going on at once, and it changes on a daily and sometimes sub-daily basis. I find myself often making lists and (re)telling my todo lists to my teammates merely to help ensure 1. I know what I’m doing and am on track, 2. that we’re all on the same page. By sharing with them I hope that if there’s a mismatch, they’ll speak up and correct. I’d rather be perceived as over-communicating than under-communicating.

But all this talk doesn’t solve the problem for everyone. The dev team is one thing, testing another, production another, sales another, marketing another… there’s so many things. Sure, we could use our issue tracking system, and there’s a lot of sense in that approach. But the issue tracker doesn’t work as well for non-dev folk PLUS it’s harder to get a 1000′ view. Yes, pictures/diagrams can make a big difference.

One thing from the agile/scrum world is having the daily stand-up meetings at “the wall”. Let’s set aside the meeting for now (again, baby steps), and just focus on the wall. I’ve suggested the wall, because I think that would be useful. Pick a wall in the office, divide it up in whatever way makes sense for us, then start populating it with sticky notes to represent all the tasks to be done. I think that’ll be useful at keeping a somewhat permanent record of the state of things (unlike a whiteboard, which will be erased eventually). Plus it allows anyone to just look at the wall at any time of the day to see where things are. CEO wants to know what’s up with Customer X? Just look at the wall. Did we ship Product Y yet? Just look at the wall.

Alas, one shortcoming is 1. we don’t have a lot of free wall space left in the office, 2. the wall is restricted to the physical. I’ve been searching for a digital wall solution and haven’t found much that thrills me. Something that we could access from any computer via a web browser (or even a platform-based app), and it would look good. But then we could also access from iOS or Android devices. In the office. Out of the office. At 3 AM, during office hours. From my desk, in a meeting on the shared screen. Whatever. Something with power to do what we need, but flexibility to work for anyone, not just the geeks.

So… I recently read this article from Joel Spolsky about “Software Inventory”. While I read it, it sounded like it was talking directly to me and our situation. I went looking at their solution:

Trello

I’ve only just started to play with it, but it seems like it could be the answer to my problems. I could see using this in my personal life, for Hsoi Enterprises, and for the day job stuff. Even if the rest of the office doesn’t buy into it, it could be useful for my own management of my tasks and issues to deal with. Being able to SEE everything instead of sorting through a bunch of text notes and to-do lists is sometimes much more useful, even if it ends up being redundant and a little more maintenance to keep 2 data stores in sync.

It’s still preliminary, but it’s promising.

Speaking as an old fart….

/ hsoi

… yes, we do know how to code.

I turned 45 this month. In many professions that’s the prime age to be – and in others it’s considered young – but in my line of work, some people think middle-aged coders are old farts. That’s especially true when it comes to startups.

The startup culture is similar to professional sports in that it requires a fleet of fresh-out-of-college kids to trade their lives and their health for the potential of short-term glory.

“Old farts” are often excluded from that culture, not because we’re lousy coders but because we won’t put up with that shit. We have lives, we have families, we have other things that are important to us. We’re not about to sleep at our desks and trade watching our kids grow up for the promise of striking it rich. Especially when the people who really strike it rich aren’t the ones writing code.

So many developers my age have had plenty of chances to ditch coding and move into management, but we’ve stuck with coding because it’s what we love to do. We’d earn more in management, but writing software is in our blood. We wouldn’t stop doing it for anything.

And because of the years we’ve spent creating software, we’ve learned what works and what doesn’t, regardless of the language or the platform. Operating systems rise and fall, development tools come and go, but through it all, old farts know how to write solid code.

– Nick Bradbury

 

First day down

/ hsoi / 1 Comment

Don’t worry… I won’t write about work all the time. 🙂

But first day today was pretty cool.

Got right into code, with the project lead explaining the app architecture, which is all pretty sound. Then I dug through the codebase and it’s pretty straightforward. I like it because it’s simple, seems to be well-written, fairly understandable. Not much in the way of documentation or comments, but most is fairly easy to figure out. This is a very pleasant and welcome change compared to some codebases I’ve dealt with in my past.

Lots of process changes too. Using GitHub, Heroku, different bug tracking, different tools (like DropBox), new workflows. Just a lot of new ways to do things. Today was a HUGE dump of information and process, and I know I won’t remember it all. But I’m diving right in… got a few easy bugs assigned to me to help me get my feet wet and start to learn how things work, and in handling those all the process stuff will come to make sense. Slow but sure I’ll get there, and I reckon by the end of the week should start feeling comfortable.

There’s a lot of things I’m going to have to get used to and adapt to, not just in terms of the work itself, but the new people, new environment, new everything. I’m the FNG, and all that comes with that. 🙂

But I can say… I really am liking the people. The other 2 devs that I work directly with, we seem to be hitting it off fairly well already. They’re both wicked smart guys, funny, laid back, and just good geeks. At one point one of them pulled out the old iPhone lightsaber app… and then I pulled out mine, and we geeked out for a bit. In so many ways, the people you work with make all the difference as to whether the job is good or bad… and I think this is going to be good.

I’m debating if I should bring my Nerf Raider in….

To you, my readers, thanx for the support. Things will be different, but I’m just going to enjoy the ride. 🙂

A new journey

/ hsoi / 10 Comments

Today I begin down a new road.

I spent the past (almost) 12 years working for one software company. It started at a small house, which was acquired some years ago. The small house was great. I remember choosing it for the intangibles it offered, because while the pay and some other options were less than some other offers I had, the fact it was so “family” just drew me in. But then, acquisition, and corporate culture changes as it always does. And while all things weren’t bad, the road the company is going down and the road I wish to go down are no longer the same path. So it’s time for me to move on.

I’m joining a small company here in town doing iOS programming. I’m quite happy about that. The future is mobile computing, and I’m happy to be a part of it… especially since I can continue to be an Apple fanboy (been one since I was a kid, with Apple II’s… learned to program on a //e). 🙂

It’s going to be a lot of changes in a lot of ways. I think one of the more interesting ones will be joining a small company. I’ve been part of “large” companies for the majority of my career, companies with at least 3 digits worth of employees. This will be the smallest I’ve ever worked at… maybe 15 employees. It’s going to be different, it’s going to be some adjustment. But I think it will be great to be able to make more impact and not have to fight such a tide of corporate red tape all the time.

This is part of what I was alluding to in a prior post about a big change in my life. Schedule changes… I’m working with people all in my time zone, instead of west and east coasters. Have to adjust to these differences and so yeah… maybe my workout plan will have to change. We’ll see. There’s just much to figure out.

I’m nervous. I’m excited. A little scared too. I’ve had a lot of “known comfort” for many years. Most people I know have changed jobs numerous times while I stayed at the same job for 12 years. In some ways, I just don’t know how to be the “FNG“, other than to shut up, do my work, prove myself, and exceed their expectations. It’s going to be weird in a lot of ways… but I am hoping the changes will all be for the good, even if right now it may not seem it. There’s always something to learn, something to gain, some way to grow. Just have to seek it.

We’ll see where this leg of my journey takes me.

 

Dangers of working from home – and how to fix it

/ hsoi / 1 Comment

A short and sweet article about the “dangers” of working from home and how to fix them. (h/t to… I forget *blush*)

Speaking as someone that’s worked from home for 11+ years, I’ve gained some perspective into the matter. I’d like to add my own input to the author’s 5 points:

1. You don’t feel you are working

The author’s point here is how work life and personal life can blend. True that. To an extent, this is a good thing. You can have a greater flexibility in life, within the constraints the job allows you. For instance, I spent many years working with folks in California, 2 hours behind me. I’m a morning person. These two things together didn’t always allow our schedules to mesh because as I’m winding up my day they’d just be digging into theirs. But I didn’t let THEIR constraints control my life. Instead, I just had to make some accommodations, such as accepting that sometimes I’ll have a meeting that’s very late in the day for me. I also made a point to check my work email in the evenings.

But that said, you really do have to work at keeping work work and personal personal. You cannot let your life become one giant smear of workandpersonallifetogether. It takes discipline and learning to draw lines AND sticking to them. Plus, you have to ensure people at work come to respect those lines. As well, the folks at home also have to respect those lines.

Which brings us to…

2. Your family members won’t understand that you are working

This is simple (but not easy). Draw lines and enforce them. Make sure the lines and rules are clear to everyone, and stick to them. For example, if my door is shut, you don’t come in. If you need me, you knock. Do not expect an answer if I’m in a meeting or perhaps deeply ensconced in a debug session. You must respect it, unless it’s an emergency. Yes, kids will have to be punished if they violate the rules. Spouses too.

But that said, remember that part of the joy of working at home with the family around is that you can be around them. I’ve found that if I’m not truly deeply into something, just flow with the interruptions sometimes. Sometimes the kiddo just wants to show you what they did. It takes 30 seconds of my time (which I probably would have wasted on Facebook or something else), kiddo is happy, I am happy, it’s a win. Don’t shun your family. Just work to manage things. And yes, it will take time, failure, revision, and experimentation to find what works for you.

3. You are slacking off, because your boss is not watching

It’s very easy to slack because you’ll be surrounded by all your favorite things. You have to develop the self-discipline to keep working, because if you don’t, you’re out of a job. Bosses will eventually detect your level of productivity.

Take a little time to blow off steam, break up the day, all that stuff. But you still have to produce. In fact, it’s generally better to work to produce more, because really… you will have fewer distractions than being in the office. You can focus better. You won’t have everyone dropping by your cube. You don’t have a commute. You can be more productive.

And oh, get dressed every day. Just because no one has to look at your or smell you, you should still carry on as if people did. It will affect your psyche.

4. You alienate yourself from work community

This is true. You must work to overcome it. The author goes into the office now and again, but my office is thousands of miles away, so that’s not possible. You must make the extra effort to communicate with folks. IM is good, or maybe set up an IRC channel. Have ways to chat with people. Do pick up the phone now and again, because to hear voices is very warming and personalizing. If you can video chat, even better. Don’t be afraid to start the day with some quick pings to people to just say “hi”. You do have to have some sort of social setup with everyone, else well… you will be overlooked, you will be forgotten, and folks just won’t know much about you. Not always good for the long haul.

5. You work too much

Yup. This goes back to #1. You just have to draw lines and stick to them. Be flexible, but be firm. Don’t check work email in your non-work times. Don’t check messages. Work is work and should be put into that box and kept there. If you do not, everything will smear and work will take over your life. You can’t let it.

It isn’t easy to start working at home. It requires commitment and self-discipline. But I think the benefits are huge, both to myself and to whomever I’m working for. It’s a situation that’s worked well for over a decade for me, and I really can’t see any other way to work.

Working at home isn’t possible for every job. If your job can be done from home, consider it. But as well, know yourself. You just may need the constraints and environment “going to the office” puts on you. There’s nothing wrong with that. It’s better to know yourself, know your limits, and know your capabilities.

Things productive people do

/ hsoi / 1 Comment

This is a short but great article listing 7 things that productive people do.

My experiences with them:

1. Work backwards from goals to milestones to tasks.

That’s pretty much the way you have to do things: figure out where you want to go, then figure out how you’re going to get there, and break it down into small, manageable chunks and even break those chunks into smaller chunks if needed. Not only does it make the work manageable but it also gives you positive feedback and motivation on progress as you whittle down the list.

2. Stop multi-tasking

As much as the world touts this, it’s terrible. We’re just not made for it (maybe you are, but most people aren’t). You get a lot more done if you focus, or at least can selectively multitask across as few a things as possible. But note if you do this, have some way to preserve state when you context switch (pardon my programmer lingo). For example, I might have a few things going at once because they are tasks that take time: need to talk to Fred but he has a lengthy turnaround time, I need to debug this problem and that could take a long time. Trying to do these serially wouldn’t be the best use of my time because they both take a long time. But since Fred could take a while, I’ll go ahead and contact him first thing in the morning, probably by email if I have the choice (see points further down). Then I’ll jot in my notes (I keep a running note log of my day, because I can’t remember it all) that I emailed Fred at 7:00 AM about the thing and awaiting his response. Then I’ll start debugging and let myself focus there because…

3. Be militant about eliminating distractions.

Amen to this. Ever been deep into something and something interrupts you and there you go, blows your train of thought and either you lose the idea or if you’re lucky you can get back into it but it takes you some time and the vibe is lost? That sucks, and is a big waste of time.

I wish some managers actually understood this and enabled it. My current managers are fine, but I had one in the past that was bothered and offended by what I did. I actually closed my door, and even put a note on the door to “knock first, and wait for a response”. I did this so I could manage distractions, but they had a problem with it. Silly me for understanding how I worked and had a desire to be productive. *sigh*

And then there are those that think open cubes and other such “open, collaborative workspaces” somehow lead to productivity… a decision typically made by managers and VP’s that have 6 walls and a door and all the privacy they want. *sigh*

Close your door, ignore the phone, ignore IM, ignore email, and generally turn things off. And yes, don’t check Facebook and Twitter every few minutes — the world goes on even if you don’t keep up with it, and you’ll love. You have to have the self-discipline to say no and deny things so you can get work done.

4. Schedule your email

This was one of the best things I did many years ago. It was all the rage to poll for email every few minutes. But I found it a constant distraction to hear the “ding” of new email, especially because I would feel a pull to check and respond — interrupting my work. So I stopped polling for email and have been very happy. Unfortunately some months ago the day job finally forced me off POP and onto Exchange so my email gets pushed to me the moment I get it. *sigh* What’s worse is culture is so strong around email and this immediate delivery that you’re expected to notice and handle email the second it arrives… or maybe 5 minutes before it actually was written. *sigh*  But I don’t care. Turn it off and people can deal with it if you didn’t get and handle the email the second it got there. Quit the email app, stop polling for mail. Handle email when YOU want to.

5. Use the phone

I will agree that sometimes the phone is the more productive way to get things done, but sometimes email remains better even for longer conversations. If there are a lot of people involved, it may be the best way for everyone to converse (you may have geographic and/or scheduling issues that prevent anything else). If there needs to be a paper trail or ease of recording. As I wrote above, sometimes the delay and control you have over email sending and response works more in your favor in terms of managing your time. What’s important is to not neglect the phone as a communication device (very easy to do these days), just learn when it’s time to use each method of communication.

6. Work on your own agenda.

Yup.

Not always 100% possible, but as much as possible, do so.

7. Work in 60-90 minute intervals

You gotta rest. You have to take breaks and recharge. And that doesn’t mean switch from email or the conference call to checking Facebook. No, you should get up, get a big glass of water, have a small snack, and walk around a bit. It helps, a lot.

In fact, big glasses of water throughout the day are really good for this. Not just because having a lot of water in a day is good for your body, but since it eventually works its way out of your system, the need to go to the bathroom helps force you out of your chair and to walk around. 🙂

Telecommuting visibility

/ hsoi / 4 Comments

IT World has a pretty good article addressing the question “Does telecommuting make you invisible?”

My answer? It can, but you can do something about it.

Some background on me. I’ve been at my day job for over 11 years and have worked it as a telecommuter the entire time. I’ve had different bosses, different projects, different teams, but it was always me that was out of the office. At my prior job, while I worked at the company HQ, the project I worked on was hosted out of Toronto, Ontario; that ended up being an interesting hybrid of “in the office” but yet I was still a “remote” that was for all intents and purposes, telecommuting. At the job prior to that, I worked in the office but most of the people I worked directly with were all full-time telecommuters located elsewhere in the world. I got to see and deal with a lot from “that side’ of the fence. So for quite a number of years throughout my entire career I’ve dealt with telecommuting, so I’d like to think I’ve learned a thing or two about it.

On the whole, I’d say the IT World article was spot on.

  • Your company’s culture and norms regarding telecommuting
  • The percentage of people at your company that work remotely
  • How visible you can be on a day-to-day basis to your boss and others
  • How effectively you can perform your job remotely

Those are things that will matter and affect how well it works. I’ll add a few things.

Regarding company culture, true that culture around telecommuting matters. If you look at what the article lists on this point, it talks about the company being set up for conference calls, remote access, and other “outside the office” work. Consider this. Is your company large enough that it has more than one physical office? If so, then it’s effectively dealing with telecommuting and other issues of being “virtual” or “remote”. It doesn’t even have to be a true office, maybe it’s a contract shop out in India or Russia. Either way, once the company is forced to go outside its 4 walls, it’s effectively dealing with the very same issues. If your company can be successful with multiple offices, it can be successful with telecommuting. I say this because often companies have multiple offices but are down on telecommuting because they view them differently. Sure they aren’t 100% the same, but for the most part in terms of day-to-day operations, they are. But of course, it can vary and depend on numerous factors, including if it’s a job that can be done outside of the office without incurring much problem and expensive.

Percentage of people can matter, especially because I know some people who may not get to work remotely may come to resent you and your ability to work remotely while they’re stuck in the office, dreaming of working from home. But if you have a larger number of people, or if it’s an option available to everyone, it’s not as much of an issue. This issue then blends into the next issue….

… visibility. This matters, and this is where YOU can make the most direct impact. Sure, if the whole team is geographically spread, that will affect process. If not, or even if still, you can and SHOULD make effort to make yourself visible. Call your boss every day or two just to chat. Call co-workers. You don’t have hallways, a photocopy machine, vending machine, water cooler, etc. around which to just congregate and talk, so you have to find ways to have social chatter as well as business chatter. Don’t be annoying, don’t cross norms or cause a problem, but just work to keep yourself in on the loop with things. Don’t be afraid to CC people on emails because you do have to force the communication. Every Friday send a “weekly progress report” to your boss and maybe even the boss’s boss (and the whole team, if appropriate) so people can be aware of what you’ve been doing all week long. Can you use Instant Messaging? If so, get the whole team on IM and use it as another means of chatter and communication during the day. Plus, IM provides a sort of visibility because, so long as you properly manage your IM, they can see if you’re online or not, at your desk, or not, in a meeting, on the phone, do not disturb, or whatever other status that may come along. It’s useful for visibility.

But be aware to not violate company policies or, most of all, lie. Don’t make things up because you will get flushed out sooner or later if you do. So much of telecommuting is based on trust, so everything you can do to foster and build trust in you, that you are responsible, that you can get the job done? That’s key.

And that brings us to the last point about how effective you are at doing your job. You do have to prove yourself. Well first, you do have to see if it is a job that can be worked remotely: someone on an assembly line just has to be there on the line, no avoiding it. As a software developer, so long as I have electricity and an Internet connection, I’m pretty good to go from anywhere in the world. Or you may find that your job can be done sometimes from home, but from time to time you have to go into the office. Whatever you do, you have to do it and find the balance to make that possible. You have to prove that you can do it, that you can have the discipline required to get the job done. A lot of people tell me they could never work from home — perhaps that is good because they know themselves and what they need to be properly motivated. I would also say, don’t sell yourself short. When you know you HAVE to get a job done else you won’t have that job and the income it provides, it tends to be a good motivator. 🙂  Yes it’s hard at first to get into the swing, find your discipline, find your groove, but you can get there. Heck, these days if I went back into an office I’m not sure I could be as productive — too many distractions!

Telecommuting isn’t for everyone, but I’m happy to see more of it. There’s many good things about it, if it can be done. The lack of commute has multiple benefits from less time wasted in a day to less impacts on our roads, our environment, vehicle wear and tear. All good things. Less costs. And ultimately, a higher quality of life.