Being new to blogging, I may be a little late to the game as far as blogging tools go. However, a colleague of mine introduced me to Windows Live Writer and I have to say that I'm impressed.
Prior to Live Writer I was using the web-based editor in our blogging site. It worked okay but still had all the common issues associated with web-based editors. They WYSIWYG capabilities were limited; it didn't offer auto-save so occasionally it was possible to lose your post before it posted; it relied on an IESpell plugin for any spell checking (which meant that it didn't spell check in any browser except IE); and it didn't handle embedded objects like photos, maps, etc. very well.
Live Writer does a fantastic job of making blogging easy. It works with nearly any blog provider and has built in spell checking; the ability to insert embedded objects easily; downloads your blog's styles and provides a "preview" and "edit" mode using those; and has a ton of other helpful plugins to make everything from entering code snippets to screen captures easier.
Overall it's a really solid product with a lot of great features that I would recommend to any blogger.
One of the questions I often get asked when I tell people I work for Rapidparts is, "... and what do they do there at Rapidparts?" Once I tell them that we sell competitive forklift parts to Cat Lift Truck and Mitsubishi Forklift Truck dealers, they wonder why in the world I work there and why the company would need even one web developer much less a team of nine.
Admittedly, I have occasionally caught myself asking a related question: Why the heck AM I working for a forklift parts company!? I mean, of all the places on the planet to work, why would I stay at a company who distributes forklift parts? I'm a developer at heart (though my developers would probably argue with that) and now in charge of a team of them. Why wouldn't I look for some cool Web 2.0 shop to work in, or go look for employment within a more glamorous industry? It only takes me a fraction of a second to remember the reason -- I LOVE THIS PLACE! This place isn't about parts at all -- it's about people.
I love that when I walk in the door every morning, I can just feel a positive energy. People are happy here, they get along, they laugh, they talk. I remember when I was a new employee we had an employee opinion survey that we filled out. I wrote on there that one of the things I loved was that the company felt like a big family all working towards a common goal. I know that sounds so cliche but it's honestly true and it's definitely still the case today.
My previous employer was not like this at all. There was always some fight going on. Whether it was first shift against third shift or management against employees, it seemed like there was always some sabotage happening. That gets very old and demotivating quickly. I like being part of a company that seems to always be moving as one entity in the same direction.
Aside from that, we have an outstanding benefits package including vision and dental; YMCA membership reimbursement; usually one or two parties a year; birthday cakes on the first Friday of each month; various reward and recognition programs; a stable and capable management team; and a strong focus on the employee as a person.
From a web development standpoint, we get to work on industry-leading applications; we get to hear from our customers and we get to know them; often we're doing things in the industry that haven't been done before; we get to try out new technologies; the company and our customers love using our applications; we all like to work together and come up with creative ideas. We just really enjoy coming in to work each day.
As you can see it quickly becomes clear why I work here. Rapidparts is a People company, not a Parts company. So now when people ask me, "why do you work there?" I just tell them, "...because I'm lucky."
Whenever I have the opportunity to visit other companies or talk to other developers, I am always amazed at the number of developers using machines 3+ years old. I know of one developer who was not only using an older machine, but that machine only had one GB of RAM! He was using Visual Studio 2008, SQL server management studio, and ReSharper among other products, and was waiting on his machine more than he was coding.
One of the things I'm proud of here is that our development environment and equipment isn't a hindrance to our productivity. Developers receive new machines every two years, work on laptops equipped with docking stations with dual 20" external monitors, and have wireless keyboards and mice. I've been asked a few questions about this setup before:
I have a feeling there are other managers and developers out there who might need help justifying some new machines and better equipment. I have found a few blog posts on the topic and, in an effort to help, I have bulleted some of the reasons that I think justify this investment.
For this one, I'll simply refer you to Darrell Norton's excellent post on the topic.
I strongly believe that there is a direct relationship between the caliber of equipment your developers use to their productivity and job enjoyment. These two things are critical to team and company success so go ahead, invest a little money in the team. You're sure to reap the rewards.
From a development standpoint, nobody really likes to work on maintenance. It's more fun to work on the cool new Web 2.0 stuff than it is to drudge through old code following logic that may not be so logical. It's definately more fun to create than it is fix. That being said however, it is inevitable that applications will need changes as the business evolves and grows. So, from a management standpoint, I had struggled for a while figuring out how to keep up on maintenance while also dedicating a majority of our time to new development.
My first attempt at this was a "Friday Folder." Throughout the week, any requests that came in that I felt confident could be completed within one day would get put into a manilla folder. Typically these came to me via emailed or printed screenshots with some notes scribbled on them: "change this to display xyz instead of pdq." I'd collect all of these requests throughout the week and then would hand them to the developers on Friday. The developers liked it better since they all got to work on project work for nearly the entire week and could then do a bunch of "no brainer" work on Friday. I would usually give a developer a "friday item" for whatever project he was most familiar with. So, if I had someone was really familiar with an old application, that developer would get any Friday Items for that project. This system seemed to work well for a little while and did help to bring some structure to our maintenance requests. However, there were a few flaws with the system.
One obvious trouble spot with this system is that it didn't work well when a Friday request took longer than 1 day. Sometimes our Friday requests would carry over into the next week and could even become a week's worth of work. That disrupted our regular project work and became irritating to the development team. A second problem was that all the knowledge for each project tended to stay with the developer who knew the most about it. From a corporate standpoint, this wasn't good. Though this system typically allowed for each request to get completed quickly, it didn't allow any other developer to gain the necessary experience required for him to maintain the application. Another problem with this "friday item" system was the business people had to wait until Friday for any work to get done. The only exception I allowed was if something was broken and needed to be fixed immediately. So, seeing all of these flaws I began to look for a different way to handle our maintenance requests. What I have settled on at this point seems to be working nicely.
Today we handle maintenance requests with a "fire fighter" role. One developer per week is the "fire fighter." They take all the web help calls, answer all the emails, and work on clearing out our "fire fighter" work item queue. These work items can now be several days long and, if necessary, can actually span weeks. However, I tend to like to keep the requests to about 16 hours of work. Anything too far outside of this needs to go down a more official change request process and get prioritized by The Business. With nine developers on the team, each developer gets 2 full months of uninterrupted project work in exchange for one week of maintenance work. This system works really well and addresses most of the problems of our "friday item" system. The developers actually look forward to their fire fighter weeks (at least more so than the friday items) because they see it as a nice break from their project. To incentivize that further, the fire fighter developer can work on anything he wants as soon as the work queue is empty. If he wants to work on building a coffee robot, go right ahead! Finally, the Business gets to have their requests completed quickly -- usually within the same week of the request. And every developer has an equal opportunity to work on applications with which they may not be familiar.
So, after a lot of trial and error, this is how we handle maintenance requests at Rapidparts. I'm curious to know how others handle these type of requests and if there are systems out there that work better.
Home
© Rapidparts, Inc 2008 | 2950 Walkent Ct. NW, Grand Rapids, MI 49544 | Phone 616.647.2500 | info@rpionline.com