August 2007 - Posts

• How to Self-Study for a Computer Programming Job

  Readers will sometimes ask me, "I don't have a college degree in computer science. How can I study for a computer programming job?" Both my company in general and I personally have put a lot of work into answering that particular question over the past 10 years. The specific answer is based on a few questions that each individual must first answer for himself or herself:   1. Do you want to go back to school, or do you want to self study? 2. Are you more interested in doing software development or in studying computer science?   If you're able/willing to go back to school ...    If you are interested in computer science (the study of computers--more research oriented), then you could look at http://www.acm.org/education/curricula.html, which gives recommendations for how universities should teach computer science. You might have to look through a few documents to find exactly what you are looking for. You could also look at university programs and see what progression of classes they recommend. This hasn't been my area of professional focus, so I can't offer any more on this point.   If you are more interested in becoming a software developer yourself, I suggest that you look at the recommended software engineering curriculum guidelines (as opposed to computer science curriculum guidelines), here: http://sites.computer.org/ccse/#_Release_of_SE2004. In this area, too, you could look at university programs and see the progression of classes they recommend. My company maintains a list of accredited software engineering programs here: http://www.construx.com/Page.aspx?hid=940.     If you're not interested in going back to school and want to self study, the recommendations are different. This is what most people who contact me are asking about, which is not surprising considering that only about 40% of people working as programmers originally got a CS degree or equivalent, and only about 60% of people working as programmers ever got a computer-related degree.   My company has put together several sample professional development plans (PDPs). Each of these plans describes a progression of work experience, reading, and classes that a person should take to achieve what we call "competency" and "leadership" levels in software development, testing, or project management. We originally developed these plans about 10 years ago for Construx's internal use. Programmer's PDP (you'll have to log in to our website to view these) Tester's PDP Project Manager's PDP   For example, here's an excerpt from the sample Programmer's PDP:   Activity Type Details     Work Experience Act as a developer on at least one project Act as a backup construction lead on at least one project Act as a backup design lead on at least one project Develop unit or module level test cases for a project Write one or more designs Participate in the release process of a project Perform personal planning and tracking on a project Participate in a code review Participate in a design review Participate in an informal review Participate in an inspection Review a project's documentation including the quality plan, test plans, test cases, project plans, schedules, and work breakdown structures     Reading Code Complete, 2nd Ed, Steve McConnell Programming Pearls 2nd Ed, Jon Bentley Applying UML & Patterns 2nd Ed, Craig Larman Conceptual Blockbusting, James Adams Software Creativity, Version 2.0, Robert Glass Rapid Development, Steve McConnell Software Project Survival Guide, Steve McConnell UML Distilled, Martin Fowler et al     Classes Code Complete Object Oriented Analysis and Design using the UML Peer Reviews for Higher Quality and Productivity   This table describes the work need to get a developer to Level 10 on our PDL. (We consider Level 12 to be full professional standing). See our website for descriptions of the work needed to attain Level 11 and Level 12.   It's important to recognize that the PDPs on the website are samples. In practice, employees normally work with a mentor to define the exact details of their PDPs. Our practice allows substitution of books, classes, and experience as long as the substitions collectively are approximately equivalent to the sample. The main purpose of the sample is to provide a starting point so that an employee can create a PDP based on something more helpful than a blank piece of paper.   Sample plans like these are often sufficient for an individual's use. But they are not the full story. They are one of many outputs of our much more comprehensive Professional Development Ladder (PDL). You can see an overview of our PDL here, and you can also download our PDL whitepaper.   Organizational Support for Professional Development   After a few years we found that some of our client companies were interested in providing better career pathing for their technical professionals, and it turned out that the way we had designed our PDL made it easily adaptable for other companies' use.   The basic idea is that we started with the SWEBOK (software engineering body of knowledge) as an organizing framework. We customized each of the SWEBOK's 10 knowledge areas into more practically focused knowledge areas that we called Construx Knowledge Areas (CKAs). The knowledge areas are things like requirements, design, construction, testing, and so on.   We then defined Capability Levels within each of the 10 CKAs. The capability levels are   Introductory -- performs basic work in an area, usually under supervision Competence - performs independent work in an area, largely self-supervised Leadership - performs exemplary work in an area; serves as a role model for others; regularly coaches others Mastery - performs reference work in an area; work has not just company visibility, but industry visibility; provides leadership both within Construx and to the industry at large   Our PDL defines specific steps that a technical professional can take to achieve Introductory, Competence, and Leadership capability within each of the 10 CKAs. Consequently we end up with a matrix of 10 CKAs crossed with 3 Capability levels -- i..e, a 10x3 = 30 box matrix -- which in total has several hundred entries for work experience, reading, and classes that are needed to attain each level.   The 10x3 matrix structure can be easily applied to provide a simple way of defining consistent and structured career progression, including guidance for professional development and promotion criteria. For example, within Construx we've said that to attain what we call "Level 12" (also known as Professional Software Engineer status at Construx), a professional must achieve Introductory capability in all 10 CKAs, Competency level in 8 of the 10, and Leadership level in 3 of the 10.   Thus someone who has a development focus might go for leadership in Design, Construction, and Tools & Methods. Someone who has a test focus could go for leadership in Testing, Quality, and Tools and Methods. Someone with a project management focus could go for leadership in Engineering Management, Quality, and Requirements. The cool thing about our PDL is that it provides consistency across these disciplines and level-sets the amount of work that anyone will need to do to achieve full professional status regardless of whether they choose to specialize in development, testing, management, QA, requirements, or another discipline. It's also has the advantage of being aligned with the industry-standard SWEBOK, which makes it easier for companies to create customized versions of our PDL if they choose to do that.   Question for You   We originally created our PDL because we had noticed that most companies provided little or no career guidance to their software professionals. I thought that software professionals deserved better and would appreciate a clearer roadmap to advance their professional capabilities and their careers.   What do you think? Have you been satisfied with the career guidance provided by the companies you've worked for? What guidance have they provided? Has it been enough? What's been missing. I'd love to hear your thoughts. Posted Aug 12 2007, 09:30 AM by Steve McConnell with 16 comment(s) Filed under: Professional Development

• Best Companies to Work For, Part 2

  Construx Employee Perspective As I mentioned in an earlier post, at the end of June I was very pleased to learn that Construx Software (my company) had been recognized as the Best Small Company to Work For in Washington state. Getting the outside validation was gratifying, but what does the inside view look like? What do Construx's employees think makes Construx a good company to work for? We held an all company lunch discussion in July to talk about that question, and here's what people said. Participatory Decision Making. We don't make very many decisions behind closed doors, or at least not without getting input from some, most, or all employees. We survey employees regularly. We do a big employee satisfaction survey once a year. We survey on other issues as needed, on topics like when we should hold our holiday dinner, which new benefits employees would value more, and so on. The Washington CEO article also commented on the degree to which we involved employees during our rocky period in 2001-2002, which our employees brought up again during our lunch discussion. Make Your Own Job. Our technical service providers (TSPs) essentially define their own jobs within three broad parameters. First, their work needs to support our mission (Advancing the art and science of commercial software engineering). Second, they need to hit their billable revenue target (which isn't a problem since most of our TSPs beat their target at least 50%). Third, their work needs to meet our service quality targets -- we reserve the right to pull the plug on offerings that aren't delighting our clients. As long as the work they want to do meets those criteria, each TSP has a lot of latitude. A TSP can develop a new course more or less according to his/her interests. A TSP can work on a new consulting offering, spend time blogging, write a book, etc. The people who like this approach, love it. A couple people have seemed to want more direction. In any case, the decision about what to work on is made collaborative (see point #1, above), so people who want more direction get that, and people who have a strong feeling about a direction they want to pursue normally get that, too. The flip side of this is that employees become highly responsible for service quality. This is fine for us as we want to hire people who seek out responsibility. Lack of Competitiveness/Helping Each Other. Our environment is very cooperative. TSPs help each other; sales personnel help each other; TSPs help sales staff, and sales staff helps the TSPs. We’ve worked hard to replace “us vs. them” thinking with “we” thinking, and I think that’s pretty deeply engrained in our culture at this point. We understand that we’re all in this together, and people act accordingly. This can go to fairly extreme degrees, with one TSP pitching in and teaching a class in a remote city to help out another TSP. Flexibility.  We offer a lot of flexibility in terms of hours and days worked, subject to the three criteria mentioned at the top of the post. Profitability. We believe strongly that we can be good to our employees and still be profitable – furthermore, that being good to our employees will actually help profitability in the long run. Easy going culture. There isn’t much yelling here. It’s pretty relaxed. We wear business casual clothing (even on the casual side of “business casual”), including shorts in the summer. If we have client meetings we expect people to dress appropriate for the client. In the software business, that’s usually business casual, but probably not shorts and t-shirts for most of our clients. Treating Employees as Humans First, Employees Second. We had a rough patch this spring during which we had 3 employees lose parents in a 60-day period. Losing a parent is a major life event, and work needs to take a back seat for awhile when that happens. Our employees were appreciative that we recognized that. I have to admit that I am surprised that people appreciate this, mostly because I simply can’t imagine a manager being so heartless as to not recognize the significance of that kind of major event. At a more day-to-day level, we’re also pretty understanding of people needing to leave to pick up their kids from daycare, attend school plays, ball games, etc. Sometimes work has to take precedence, but usually work life and home life can be kept in balance. Overall. Our lunch discussion didn’t turn out to be a very comprehensive or systematic discussion. I think we mostly just hit points that the Washington CEO writeup missed, or that seemed underemphasized in that article. I’ll write up what I think makes us a best company to work for in a future blog entry. Posted Aug 06 2007, 03:35 PM by Steve McConnell with 4 comment(s) Filed under: Best Companies to Work For, Construx Software