I’ve been using Linux/UNIX for about 20 years. I am also Assistant Director of the Boston Linux and UNIX Group, and have contributed to several open source products. In general, I find open source software more flexible, more transparent (no security through obscurity), and more focused on what’s needed instead of what marketing says would be cool. I like that open source software is usually developed modularly, with separate components each doing what they do well, each designed to be combined with other component, each with its inputs and outputs documented for fitting Tab A into Slot B. Open source’s community support model (with a sufficiently large community) is often far superior to calling tech support. All that said, I still believe very strongly in “the right tool for the job”. Sometimes open source is not the answer.
Just like commercial software, it’s important to evaluate not only how well the software suits your need, but the “health” of the product and its creators. Just because it’s still available doesn’t mean it’s still supported, updated, and in common use. That may not be a deal-breaker for you, but it does need to be factored in to the decision.
In my last post, I talked about tools for tracking Agile projects. Whatever too you use, you have to know what to do with the information. It’s not just about the project being ahead or behind schedule, it’s about using the information to improve the software development process and its implementation. One optimization which has been part of many Agile schools from the beginning, back to the Toyota days, is minimizing work in process. In fact, it’s the major focus of Kanban.
Work In Process isn’t just code sitting in your editor. It’s any task that’s not done, done, done. In other words, if it hasn’t made it all the way through your software process, it’s still work in process.
Read on…
I admit it, I’m a bit of a geek. OK, I am an Alpha Geek. And yes, I sometimes go with the slightly more computerized solution that others might. I just don’t get Agile’s fascination with sticking hundreds of pieces of paper on the wall, though. Agile teams need a mechanism to share knowledge about stories and tasks. They often do this by using whiteboards with sticky notes (so they can be moved) or cork boards with push pins and index cards. There are columns for the stages (waiting, in process, in QA, done done done) and rows for each story. This article shows an example of one.
I talked about it with an Agile coach friend of mine, Nancy Van Schooenderwoert of Lean Agile Partners, and she made a good point that the paper system makes the whole process easier to learn. She also pointed out that all software has limitations, and it’s important to start out with the index cards or sticky notes so you don’t get the impression that any limitations in the software are a limitation in the Agile practices. I get that. But once the team is passed that point, it’s time to use software-based collaborative tools. Why?
Read on…
It’s easy to say that many skills are like riding a bicycle; that you never forget them, and can just start using them again after a long period of disuse. It’s a lot harder to actually do it. This is especially true when you try to keep track of several closely related skills. For instance, I’ve learned so many computer programming languages, that when I need to learn a new one, it’s faster to see how it’s different than one I already know than to try to learn the language itself. I’m sure the same is true of other fields.
When “Jacks of all trades” (I hate the term “generalist”) like myself job hunt, there’s usually a list of possible technologies and environments we’re willing to work in, so we can’t afford to just keep up on Java, or Perl, or PHP, or .NET. We not only need to keep sharp on all of these, but we need to keep track in our heads which is which (after all many programming languages are very similar). No matter how long you’ve used a skill, a few months of unemployment can blur the details. In this post I plan to cover some helpful techniques for being ready for the technical interview or test without flipping through 300-page books each time. I will not be addressing mastering new skills, because that is an entirely different activity. Some of them may be specific to software development, but I hope there are parallels in other areas.
Like many job hunting activities, you shouldn’t wait until you’re job hunting to start doing them. After all, you want to keep marketable on skills you’re not currently using at your current job, right?
Read on…
Last week I started my new job as a Principal Software Engineer at Workscape. I’m back in another Agile position, working on Java (and starting work on Flex, too), which are the two things I was looking for. I would have settled for a position at a company that wasn’t Agile, but it would have been hard, knowing the benefits of it. I was waiting to post this until I got my first paycheck or did my first commit of fixed issues, whichever came first. Thursday and Friday I fixed three issues, so now it’s official.
Workscape offers HR services to other companies and their employees.
I came across this blog post on the Developer Art blog on preserving and sharing project knowledge. I found both the articles and the comments insightful, offering several good suggestions for persisting and disseminating project knowledge.
This is a topic near and dear to my heart. Anyone who has worked with me on a project knows I take endless notes, and I have been saved by them many times. They can lead to information overload, but to me, it’s worth the risk. You can’t go back in time and take notes at a meeting that already happened any more than you can reshoot your vacation pictures once you’re back home and notice that they all have your thumb in them. I would rather record information and throw it away later if I don’t need it, than try to reconstruct an undocumented conversation after the fact. The act of recording the information also helps me remember it.
Read on…