I’ve pined (or whined) about my current situation to some minor degree in past blog posts. I’m not generally one to just sit back, and complain about a situation though. I’m usually pretty vocal, but at the same time I work towards solving my problems, rather than wallowing in them. As such, I decided that it was in my best interests to look into new opportunities to see what my options were. I ended up with options to go back to Contegix in St. Louis where I formally worked, to work with a company here in Chicago named Medtelligent, or to wait it out longer at my current job to see what the future my end up holding.
Contegix seemed like a really good fit, but involved moving back to St. Louis. With that comes a variety of expenses, and there was some (totally justifiable) concern on their end that I was using them as a meal ticket back to St. Louis. I understand that concern, it makes sense. It’d make more sense if there was anything else in St. Louis worth exploring in the IT sector other than Contegix though :). Ultimately, that actually played a pivotal role in my staying in Chicago. I can fail here, and my potential for finding another job is significantly higher than in St. Louis. I looked a lot at the job market in St. Louis, and was worried that if something did go wrong, that I was out of luck. After all, I’m in Chicago now, because I couldn’t find work in St. Louis originally when I first left Contegix. At the end of the day, I still have a ton of respect for Contegix and what they do. They’re still the best managed Linux host money can buy, and you can’t do that without getting a lot of things right.
Staying at Imaginary Landscape wasn’t a bad option. My biggest concern was that my skill set was going to continue to languish there, as there hasn’t been a lot of work lately. At the end of the day, we just weren’t a great fit for each other in a long term situation. I still have a lot of the Contegix mindset engrained in my work ethics. My desire is to constantly push to be better, and to consistently go above and beyond. That didn’t translate very well to Imaginary Landscape. They’ve been around for awhile, and they have their way of doing things, and there’s nothing wrong with their methods per se. They are a pretty awesome company, and for the most part, really know how to treat their employees.
That leaves the option of Medtelligent, which as of May 3rd will be my new employer. I’m really excited about this opportunity. It really seems like this is the right fit for me finally! It’s a small company, which I prefer. The people there that I’ve talked with/met seem pretty cool. The methods they follow fit my style. They operate in an agile (Scrum) method for developing software, which I love. It just seemed like they “get it”. Obviously, I won’t know that for another month or so, after I’ve had some time to work with them. That’s the chance you take when changing jobs though. I’m excited about having some tougher challenges thrown my way, and learning new (to me) stuff like mongodb and the like.
Anyways, I’m looking forward to this new chapter. Maybe it’ll bring upon some inspiration, and I’ll get myself more active in open source again. This could mean less Django for me though, but that’s not necessarily a bad thing. I love Django, but I’d rather be a true, well-rounded Pythonista, than be pigeon holed solely as a Django developer. No offense to the Django people, because Django’s fantastic, and I plan on using it more in my future. I just don’t want my resume to be Django specific. I’ll be sure to update more as time passes, and I’ll let you know how the transition goes. Can’t wait!
Monday, April 19, 2010
Saturday, April 17, 2010
Zootool.com API Wrapper - pyzootool
I recently came across a site named Zootool, which as far as I can gather is basically like Delicious. My usage of such sites always works out to be basically the same. I think “Oh wow, this will be really useful for when I find sites I like, can’t read right now, but will want to tag to read later on a different PC”. The problem is that it never actually works out that way. I tag things, and never remember tagging them, and never end up actually reading whatever I tag. It boils down to a week of “Wow this is super cool!”, and then I never visit again. It’s not the site’s fault, I’m just inept.
That mini-rant aside, I noticed that the creators of Zootool were kind enough to build a small, but very useful, API on to their site. At the time I realized the only wrapper that had been written for this API was in PHP. Not wanting to see Python under represented, I decided to embark on wrapping their API up in Python. I’m pleased to say that thus far it’s turned out fairly well. I have the entire API wrapped in Python now, and everything seems to work fairly well.
Their API is REST-like, so I used httplib2 to do most of my wrappings. The library allows you to do all of the following:
When I was writing it, I was really trying to model how it functions after tweepy, because I’ve always enjoyed how it functions. Thanks to the maker(s) of tweepy for the inspiration. Hopefully someone finds some uses for pyzootool though, never know when you might need to do some social media data mining against it :) All the code for it can be found at my github repo, and if you just want to install it you should be able to just do “pip install pyzootool”, and enjoy.
If anyone has any feedback, criticisms, or suggestions, please let me know!
That mini-rant aside, I noticed that the creators of Zootool were kind enough to build a small, but very useful, API on to their site. At the time I realized the only wrapper that had been written for this API was in PHP. Not wanting to see Python under represented, I decided to embark on wrapping their API up in Python. I’m pleased to say that thus far it’s turned out fairly well. I have the entire API wrapped in Python now, and everything seems to work fairly well.
Their API is REST-like, so I used httplib2 to do most of my wrappings. The library allows you to do all of the following:
- Retrieve user data
- Retrieve items by their uid
- Retrieve items by popularity in the last week, day, month, or year
- Retrieve personal items (if authenticated)
- Retrieve a user’s friends
- Retrieve a user’s followers
- Add items to your zoo (if authenticated)
When I was writing it, I was really trying to model how it functions after tweepy, because I’ve always enjoyed how it functions. Thanks to the maker(s) of tweepy for the inspiration. Hopefully someone finds some uses for pyzootool though, never know when you might need to do some social media data mining against it :) All the code for it can be found at my github repo, and if you just want to install it you should be able to just do “pip install pyzootool”, and enjoy.
If anyone has any feedback, criticisms, or suggestions, please let me know!
Tuesday, March 30, 2010
Keeping 'Rock Stars': Plausible?
Now, I don’t necessarily consider myself a ‘rock star’ engineer/programmer/developer/code monkey, so this isn’t some arrogant post about how awesome I am. I am awesome though, just sayin’. I recently read an article by Joe Stump, HOWTO: Maintain a Rock Star Culture, which spawned some thoughts of my own. If you haven’t read his post, go do it, it’s a great read. I think it might be better titled: “HOWTO: Keeping Your Rock Stars”, personally.
I think what shocks me a bit is how much of his post seems common sense, yet still needs to be said. Maslow’s Hierarchy of Needs has been around since 1943, makes a lot of sense, and can be applied to just about any profession. Stump’s article mainly expands and focuses that hierarchy of needs specifically for software developers, and not just any developer but ‘rock stars’. Obviously, depending on your field the type of people you will employ will be rather similar, and thus have generally similar goals. Your ‘rock stars’ are going to focus the most on the ‘Self-actualization’ and ‘Esteem’ aspects of the hierarchy of needs. Love and belonging isn’t something as an employer you can always have an impact on, other than creating a friendly environment where you employees can get along and build friendships. Safety, not much of an issue in software development really. Other than some nasty PHP code making my head nearly implode, I generally feel rather safe at a keyboard. Finally, physiological isn’t entirely relevant, you’re paying them well, that covers that.
So, self-actualization and esteem are easily the most important bits with your typical developer. Yet, for some reason, these are so often overlooked. Stump points out a lot of items that helps his developers realize these needs:
Here’s where my curiosity comes in though. All of his tips and tricks make a lot of sense, but how does that work over the long haul? If you truly have ‘rock stars’, then you have head hunters chasing those ‘rock stars’. Some would say that the person quitting is inevitable anyways, which is probably quite true (read: Up or Out: Solving the IT Turnover Crisis). How long can these perks actually keep the employee around? Perhaps the real point is keeping awesome engineers for a couple of years, and then recruiting new ones to replace them, when the original engineer inevitably quits.
Turnover is expensive though, especially when you’re shelling out $3000 to each new developer for them to purchase their own equipment. Hence, you never want your developers to really end up leaving you, which is sort of a no-brainer. I look at my current situation, where when I came on board it felt like there were a lot of awesome perks about working with Imaginary Landscape. To be fair, there are some awesome perks. I have an incredibly cushy situation. However, I also look into the past and see a graveyard of great developers (Ian Bicking, Chris Webber, Tamas CantRememberHisLastName), which has always been a bit of a concern of mine.
I think overall what I’ve learned recently from the two articles previously mentioned is that skilled workers are always going to a quit. It really is just a question of when, not if. The life of a developer is one where the proverbial glass ceiling will always exist. You’ll always reach the point where the company you’re with will eventually run out of challenges to offer you. Really, as a tech company you’re never trying to “keep” engineers, you’re trying to prolong the amount of time that they end up sticking with you.
I think Joe Stump’s idea of building a ‘Rock Star’ culture is a step in the redirection for prolonging the amount of time you get to hang on to a great engineer. I think ultimately though, the key is to never stagnate, always encourage innovation, and constantly move forward. Essentially, all the perks in the world can create temporary happiness, but challenging (reasonable) work always ends up being more important. Perhaps it’s because many developers grow up as introverts, that playing to their ego and making them feel important seems to work so well.
Oh well, enough mindless rambling on this subject. I highly recommend reading the linked articles though. They’re really good, and quite thought-provoking.
I think what shocks me a bit is how much of his post seems common sense, yet still needs to be said. Maslow’s Hierarchy of Needs has been around since 1943, makes a lot of sense, and can be applied to just about any profession. Stump’s article mainly expands and focuses that hierarchy of needs specifically for software developers, and not just any developer but ‘rock stars’. Obviously, depending on your field the type of people you will employ will be rather similar, and thus have generally similar goals. Your ‘rock stars’ are going to focus the most on the ‘Self-actualization’ and ‘Esteem’ aspects of the hierarchy of needs. Love and belonging isn’t something as an employer you can always have an impact on, other than creating a friendly environment where you employees can get along and build friendships. Safety, not much of an issue in software development really. Other than some nasty PHP code making my head nearly implode, I generally feel rather safe at a keyboard. Finally, physiological isn’t entirely relevant, you’re paying them well, that covers that.
So, self-actualization and esteem are easily the most important bits with your typical developer. Yet, for some reason, these are so often overlooked. Stump points out a lot of items that helps his developers realize these needs:
- Engineers should drive feature development
- Allow flexibility on how/when/where your engineers work
- Enforce reasonable hours
- Encourage “I don’t know” as an answer
- Make them comfortable (desk, chair, equipment, etc)
Here’s where my curiosity comes in though. All of his tips and tricks make a lot of sense, but how does that work over the long haul? If you truly have ‘rock stars’, then you have head hunters chasing those ‘rock stars’. Some would say that the person quitting is inevitable anyways, which is probably quite true (read: Up or Out: Solving the IT Turnover Crisis). How long can these perks actually keep the employee around? Perhaps the real point is keeping awesome engineers for a couple of years, and then recruiting new ones to replace them, when the original engineer inevitably quits.
Turnover is expensive though, especially when you’re shelling out $3000 to each new developer for them to purchase their own equipment. Hence, you never want your developers to really end up leaving you, which is sort of a no-brainer. I look at my current situation, where when I came on board it felt like there were a lot of awesome perks about working with Imaginary Landscape. To be fair, there are some awesome perks. I have an incredibly cushy situation. However, I also look into the past and see a graveyard of great developers (Ian Bicking, Chris Webber, Tamas CantRememberHisLastName), which has always been a bit of a concern of mine.
I think overall what I’ve learned recently from the two articles previously mentioned is that skilled workers are always going to a quit. It really is just a question of when, not if. The life of a developer is one where the proverbial glass ceiling will always exist. You’ll always reach the point where the company you’re with will eventually run out of challenges to offer you. Really, as a tech company you’re never trying to “keep” engineers, you’re trying to prolong the amount of time that they end up sticking with you.
I think Joe Stump’s idea of building a ‘Rock Star’ culture is a step in the redirection for prolonging the amount of time you get to hang on to a great engineer. I think ultimately though, the key is to never stagnate, always encourage innovation, and constantly move forward. Essentially, all the perks in the world can create temporary happiness, but challenging (reasonable) work always ends up being more important. Perhaps it’s because many developers grow up as introverts, that playing to their ego and making them feel important seems to work so well.
Oh well, enough mindless rambling on this subject. I highly recommend reading the linked articles though. They’re really good, and quite thought-provoking.
Saturday, March 27, 2010
General Words About General Things
When all your posts start off as "I know it's been awhile...", it's probably time to give up the whole blogging thing. Too bad, not giving up on it quite yet! Lots of stuff going on here though, some things I can talk about, some things I don't have quite enough information on to talk about yet. Our lease is ending at our current apartment in a few short months, and we're pretty dead set on moving to some place else. We rushed into our current apartment in our move from St. Louis, and now we've had a year to learn a bit more about the city. Now we can take a couple of months, and really pick out the place that's best for us. Plus now we have some idea of what neighborhoods are good, which suck, and how to get around the city. Obviously, moving sucks though, but at least we don't have an entire house full of crap to move this time.
One of the reasons I haven't blogged in awhile is I'm on a bit of a programming drought. DjTracker sort of hit a wall when I realized I specifically didn't have a real use for it. I was hoping to some degree that I could get my office to switch issue trackers to something more usable and sane, but that wasn't met with a whole lot of interest. No biggie really, their current issue tracker is working out great for someone, so I suppose that's all that matters. Once I didn't have a use for it though, I didn't really know what else to do with it. YaBa's been 'done' for awhile for a variety of reasons. Then I couldn't really think of something else that I wanted/needed to develop.
Meanwhile at work, I've mainly been doing more maintenance on older applications, or making just some small simple stuff. Some if it's been cool, no doubt, just nothing groundbreaking or even lengthy really. I'm supposed to blog for them on ChicagoDjango, but given that I've done so little actual Django work lately it's been difficult. I keep hoping we'll get some new customer that wants to do something that's just wicked awesome. Ah well, we're still getting customers at least, I have a job, and I do get to make some Django applications on occasion. I'd just like to have a challenge or two thrown my way in the near future to spur some inspiration on my end.
On the upside, since we haven’t had a ton of work lately I’ve been able to learn a bunch more javascript than I previously knew. Normally, when everything’s in full swing, we have a UI guy that does most of the design and javascript, so us Python developers can plug away on the backend stuff. Since we’ve had more time lately, on the last couple of small Django applications that we’ve had I’ve been able to do the javascript myself instead. Nothing exceptionally fancy, but I’m more comfortable with it now than I have been in the past. That’s a plus there. Again, just wish there was *more* to do. We’ve been down a programmer most of this month, and I still haven’t felt actually busy. I think I miss that aspect of Contegix sometimes, where I was always busy. It certainly makes you feel more important, or at least relevant.
Anyways, it’s a fairly pretty day here in Chicago, if not just a bit on the cold side. Kristie and I are currently at Winston’s drinking some coffee. Time to plan out the rest of our day!
Thursday, February 11, 2010
Much Ado About Nothing
It's been an awkward and frustrating couple of weeks lately. Not everything is going quite as we had planned it I suppose you could say. The Wildlife Rehab site is on a bit of a hiatus as we try to work out where we're going to place some new content, and where that content is going to come from. Not to mention a laundry list of tweaks and changes that'll need to be taken care of at some point, but there's a few items blocking progress on that list. Hopefully that'll all come together soon, but it's also not a major rush of any sort either.
Work lately has been a bit on the ho-hum side of things. I've mainly just been doing odds and ends style work on legacy applications and other maintenance style work. I have had a couple of really simplistic and short Django applications to write, but nothing major or thrilling. Nothing exceptional worth really talking about. Oddly, I'm supposed to blog something for Imaginary Landscape, but considering how little I've had to do in terms of actual Python/Django work, I have no idea what to blog about. Hell, I barely know what to put on this blog most of the time. On the upside I am going to PyCon next week, so after I get back from that I'll hopefully have something to blog for them. We'll see I suppose.
Currently though, my main focus at work is developing an iPhone application. I have some pretty mixed feelings over the whole situation. First off, it's a monumental task in my eyes, and I'm not sure that management totally gets that. I'm getting some of my first glimpses ever at Objective C, and I've been pretty clear that I have to learn a new language, and a new development environment. I've played with it a bit thus far, and even though I have C/C++/C# experience to some degree, Objective C just feels so incredibly foreign to me. Obviously, it doesn't help that thus far I've been trying to learn strictly via Apple documentation and online tutorials while hopping between other small issues as well. I know it's something I can do, that's not the question, it's more how long it's going to take. I don't have a personal vested interest in making an iPhone application, it's not something I want to slap on my resume some day really. Thus, I'm not cramming at home in my off time to learn more. I like Python, so in my off time I write my code in Python.
Secondly, I tend to think that making an iPhone web application makes a lot more sense in a lot of ways. Obviously, it's *free* to do so, which is a big plus. It also doesn't require anyone to learn Objective C. You don't have the risk of spending weeks/months of development time, just for Apple to potentially decline your application. We could build it using tools we're familiar with, in a much shorter amount of time. Finally, should anything ever happen to me, they wouldn't have to find someone that knows PHP, Python, bash, AND Objective C. Those people exist, but they're likely to be expensive.
Finally, I see so much else we could be doing to improve our current infrastructure including servers, documentation, issue tracking/management, and quality assurance with the free time we're spending on this random iPhone project. I guess I look at and think that if we improved some various aspects of our infrastructure that down the road we'd have even more time to spend on projects such as this, and be able to do it with less distractions. They have a lot of good things going here, and it'd be nice to bring some legacy items we use up to date.
In the end, the iPhone stuff isn't that big of a deal. I'll do it, and I'll try to enjoy it I suppose. It seems a bit silly to me overall, but that's just how it goes sometimes. I just wish the project we were working on was somewhat more entertaining. If it nets the company a few more customers that's a good thing I suppose. Of course that'd mean I'd have to write more iPhone applications :).
Other than that, not much going on lately. I'll be sure to update with more information after I get back from PyCon, which I am pretty excited about. Just wish it'd hurry up and get here.
Work lately has been a bit on the ho-hum side of things. I've mainly just been doing odds and ends style work on legacy applications and other maintenance style work. I have had a couple of really simplistic and short Django applications to write, but nothing major or thrilling. Nothing exceptional worth really talking about. Oddly, I'm supposed to blog something for Imaginary Landscape, but considering how little I've had to do in terms of actual Python/Django work, I have no idea what to blog about. Hell, I barely know what to put on this blog most of the time. On the upside I am going to PyCon next week, so after I get back from that I'll hopefully have something to blog for them. We'll see I suppose.
Currently though, my main focus at work is developing an iPhone application. I have some pretty mixed feelings over the whole situation. First off, it's a monumental task in my eyes, and I'm not sure that management totally gets that. I'm getting some of my first glimpses ever at Objective C, and I've been pretty clear that I have to learn a new language, and a new development environment. I've played with it a bit thus far, and even though I have C/C++/C# experience to some degree, Objective C just feels so incredibly foreign to me. Obviously, it doesn't help that thus far I've been trying to learn strictly via Apple documentation and online tutorials while hopping between other small issues as well. I know it's something I can do, that's not the question, it's more how long it's going to take. I don't have a personal vested interest in making an iPhone application, it's not something I want to slap on my resume some day really. Thus, I'm not cramming at home in my off time to learn more. I like Python, so in my off time I write my code in Python.
Secondly, I tend to think that making an iPhone web application makes a lot more sense in a lot of ways. Obviously, it's *free* to do so, which is a big plus. It also doesn't require anyone to learn Objective C. You don't have the risk of spending weeks/months of development time, just for Apple to potentially decline your application. We could build it using tools we're familiar with, in a much shorter amount of time. Finally, should anything ever happen to me, they wouldn't have to find someone that knows PHP, Python, bash, AND Objective C. Those people exist, but they're likely to be expensive.
Finally, I see so much else we could be doing to improve our current infrastructure including servers, documentation, issue tracking/management, and quality assurance with the free time we're spending on this random iPhone project. I guess I look at and think that if we improved some various aspects of our infrastructure that down the road we'd have even more time to spend on projects such as this, and be able to do it with less distractions. They have a lot of good things going here, and it'd be nice to bring some legacy items we use up to date.
In the end, the iPhone stuff isn't that big of a deal. I'll do it, and I'll try to enjoy it I suppose. It seems a bit silly to me overall, but that's just how it goes sometimes. I just wish the project we were working on was somewhat more entertaining. If it nets the company a few more customers that's a good thing I suppose. Of course that'd mean I'd have to write more iPhone applications :).
Other than that, not much going on lately. I'll be sure to update with more information after I get back from PyCon, which I am pretty excited about. Just wish it'd hurry up and get here.
Subscribe to:
Posts (Atom)
