Back from Conference
Sep. 15th, 2006 03:01 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
bethlakshmiBack at work.
Lots of food for thought. I really ought to parse it a bit... and maybe here is a decent place to start.
To start, I took classes from a bunch of tracks, because I am a massive generalist. I took requirements classes, testing classes, user interface design classes and project managment classes. I might have even taken one development class. I find it rather surprising that I didn't take more development classes - I suppose it's the final confirmation that I am no longer a coder. I haven't written a line of code in the last 2 years, I think it may be time to stop calling myself a "Software Developer" and stick with "Computer Engineer". Sigh.
So... Starting with Requirements - took a class called "Get the Right Stuff, Fast: Jogging with the User Requirements Roadmap" - the key point being that it can be much easier to start with "business events" that trigger interaction with a system rather than with traditional use cases. Frequently events lead to use cases fairly easily.
Also took a class on Requirements Management case studies - a guy who works as a Requirements Analyst at Exxon Mobile. He had some general good practice advice on how to best manage requirements. I think my favorite idea was that big, big requirements documents are hard to read and very geeky. You shouldn't expect everyone to read them, and for many users, you need a really high level abstract of no more than a page.
Took quite a few classes on people & project management. I do so like warm & fuzzy classes. I found 2 presenters who I really liked - Naomi Karten and Johanna Rothman. The fact that I hit both of them on the first day contributed alot to my love of the conference. Both were great speakers, but one is an intense introvert and one is an intense extrovert. It was really need to see so clearly how their personalities made for very different, but equally effective methods of presenting material. Naomi did a Keynote called "Tales of Whoa and Customer Satifaction" where she talked about addressing customers with what she jokingly called "psychicology" - the task of figuring out how to make customers happy when they won't tell you. The stuff she outlines were often common sense, but the stories she brought about the topics showed that while it seems straightforward, it often isn't. The one I remember most was 1 - listening. Sometimes just listening to their gripes goes a long way towards getting customer buy-in, even when you don't do anything about the issue. 2 - Figure out how/when/why the customer wants feedback. Every customer would say "in a timely and frequent manner" - but what exactly does that mean? Some like reports, some like phone calls, some like meetings, some want different things in reports... it's best to ask AND to tune in to whether your feedback is helping. She mentioned working with a group that had 4 user groups - and each user group wanted to "involved in the process" in a different way. 3 - consider the customer's context - sometimes you can't make a customer happy, consider when they have stresses outside your sphere and cut them slack.
Johanna was someone I would readily take out to lunch. She's a hoot. She's funny, energetic, and she reminds me of two people - Sheila - a manager I've followed through three companies, who I often choose as a personal mentor because I like and respect her so much, and Patricia - a friend of my family who is a psychiatric nurse, who looks and sounds like Johanna. I ended up attending a number of her sessions, partly cause I like listening to her so much. I took =
- Coaching Your Peers/Team - "coaching" meaning a process of helping *those who want to be helped* to find, evaluate, choose and monitor solutions to their problems. It's harder than it sounds. To be a good coach, you are supposed to stand back and be detached - you can offer solutions, but only after you've really tried to help the person come up with their own, and you have to not put the person or their solutions down. Now... I'm a painfully positive person, but this was really, really, really hard in practice.
- Project Completion Estimation - some nice human-oriented ways to estimate when a project will be done, figure out when things are going wrong, and work on some of the typical problems with status reporting and estimation. I think we often get so caught up with models and analysis tricks, we forget that basically asking people - dude, when will you get done? and if that's too hard a question - asking "what do you have to do to get from here to here... ok, what will take to each of those steps?" is a good point. And... in the end... it's an estimate. If you knew exactly how long it would take... it wouldn't be an estimate.
- 15 Lessons Learned - 15 good ideas for project management, some seemed common sense, some seemed an antithesis to "the right way to do things" -- but I see her side. One of the most interesting was "set a weekly status meeting with each employee individually for 1/2 an hour" it may not take 1/2 an hour, but set aside 1/2 an hour. And avoid status meetings. At first this seemed like madness (madness I tell you), but thinking as an employee - I would have *killed* for half an hour a week with a good manager. And if you can inspire your employees to kill for you, you're probably on the right track.
On testing, I took - "When 2 + 2 = 4 is Wrong" - a class on how testing can go beyond pre-conceived expectations - both with customer-relations/expectations and with technical occurences. The instructor, Micheal Bolton, manages to make testing dicussions interesting, fun and not dry at all - a far cry from most test-oriented classes I've taken.
To recognize the fact that I work for a huge DoD contractor, I took - DoDAF Enterprise Architectures in UML - a govt. spec for architecture description development. I hate to say it, but the spec mostly seems to be yet another over-specification, govt. time wasting exercise. There are probably a few nuggets with good ideas attached to them, but mostly it seems to be so very "meta" that few people will get good use out of it, while standards weenies will have a festival. Maybe I'm just grim. I felt kinda bad for the presenter - he obviously cared about the topic, was a decent technical speaker and certainly knew his stuff... but the topic was nearly vampyric in its ability to suck the life out of all attendees.
On the UI side, I took 2 from Larry Constantine - a paid consultant with an unholy love of fancy powerpoint presentations. The fact that he clearly loved making them made the wacky, funky slightly cutsey presentations OK - because it was clearly coming from a truly geeky place. Also took a class from Elliotte Rusty Harold - who clearly knows his stuff, but has enough of the smart geek affectations that he came across as ever so slightly arrogant. The fact that he really knew his stuff, and could readily justify and elaborate on his opinions made me think well of him, but unfortunately dissuaded me from taking other classes from him.
Elliotte's class was "User Interface Principles in API Design" - he started with the differences between libraries and APIs which had me a little concerned, because my main focus is really libraries, but I think his thoughts on APIs apply just as readily to libraries. Lots of good stuff in his presentation and when I consider the API situations I've been involved in, his principles line up well with my practical experience. I will definitely review my notes when designing an API... in fact it may play well into some of the integration documents I have to review today...
Larry's first class was "Usability by Inspection" - improving Usability with Peer Reviews. Oooo! This is a neat trick. Since we are peer-review oriented as a company (oh, we love them so much, I just can't tell you) - this has some really powerful applicability - even more so if I can get customers and users in the mix. It's a way of finding UI issues by evaluation wireframes or prototypes - the earlier the better - and the meeting is structured in such a way that it generates the most issues in the least time - with no evaluation or judgements whatsoever.
The second class was "Users, Roles and Personas" - a way to develop concepts of operations based on various user models. In UML use case design, you need to specify "Actors" who are defined by how they interact with the system. But in the new "Persona" system that is being touted in many circles (Microsoft uses it) you start with actual user groups and detail not just their system interaction, but also various softer aspects to what type of users you have - for example, my LJ user persona might include the fact that I am a hip, youngish adult who owns a home but lives alone. I like wierd subcultures, and spend many of my evenings doing artistic projects alone or with groups. That I'm an outgoing person who likes meeting new people and is only shy in very large parties where there is no group activity. Now... that may or may not impact how I use a system. Larry advocates a third concept - roles - where you focus on user groups, and think a bit about the user's skills and background - but mostly you work on their goals in using the system. And if you have one or two key roles - you might study the personas within those roles. It was pretty common sense, and I may play with the idea informally the next time I write use cases.
Took "Telling your Design Story" by Rebecca Wirfs-Brook - she's a huge name in the Software Design field, advocating a lot of best practices. Sadly, I don't know whether she had a bad day or what, but she didn't come across well in a class that was mostly (to me) about presenting. She seemed to have a lot of the geek uncomfortable presenting problems - and it was hard to hear from her how to present something. I also felt a little lost in her talking - I've had real trouble with telling my design story - which diagrams to include, where to go with the presentation, how to get the best information out of a peer review... And I didn't feel like I had any great nugget of information... it may be that I need Design Stories Advanced, because I'm already a better presenter than most geeks.
Another keynote - "Quick or Dead - Organizational Velocity for an Impatient Age" - was kind of neat - Tom Demarco's posit is that we spend way, way too much time in meetings and emails - rather than actually making decisions and doing work. He suggests a number of ways to limit overhead by imposing some rather dramatic rules. While I respect his ideas, I was little teed of by his non-answer answer to my question - all his advice was to management, who can make up some of these rules. How exactly does one do anything when they are not management powerful enough to dictate the rules? He suggested waiting until you are management. That's not an answer. If I wait for that to happen, there's a strong chance that there won't be a company to manage.
Was particularly inspired by the Software Security keynote by Gary McGraw. The topic didn't do much for me - he basically points out how very much at risk we are in our current ways of implementing software, and suggests a number of key ways to improve security - particularly automated code review and architectural analysis. That's great, I get it. Not hard. But what really impressed me was his ability to grab the audience about a topic which could be preachy, and could be boring. He really knew how to speak to a bunch of software geeks. I couldn't help but think ... wow... this guy would be fun to work for.
Took Per Kroll's class - Process Improvement via Best Practices. Now... by Wed afternoon I was exhausted, so I know I sucked as an audience, but this one really failed my attention span. I accientally fell asleep in it, and had real trouble understanding his points as anything but "duh... that's obvious?". I get the feeling there might be something deeper, but I failed to grasp much of anything.
I was, in fact, so turned off that I almost didn't take Susan Burke's "Practical Best Practice". I'm very glad I did. She talked about some of what she's found that you MUST do to have a project that meets its goals - but pointed out that it didn't matter how you did it. In going along, she talks about some ways to do it, and she pointed out some ways where companies didn't do the "right thing" by the official process but where it turned out to be the right thing for the company. It was inspiring and englightening. I took away the idea that it's not always about doing the right process correctly as it is taking the tools and resources you've got and making them work for you as well as you can.
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
jducouer got me to go to "Making Software Self-Reliant" by pointing out that it was really an application security class. I'm glad he did. Although about half was kinda boring cause it was a run at security basics - the other half was some great ideas. Software integrity maintenance can get very funky and raises a whole field of interesting problems. I may not ever do any of these, but it's good to have them stashed away in my memory. At the end of the class, the instructor targeted jducouer and I as the best question askers in class. I was flattered.
All that stuff has me thinking "boy, I wish presenting at professional conferences was part of my career". Yeah, it sounds really hard, but fun. I think I might want to work towards that. I've enjoyed SCA classes, and Arisia classes - and I wish I got to spend the time in class prep doing something that was career enhancing and not just kinda fun.
My first thought for a class was a "how to attend conferences" class. There's two types of conferences, as I see it - hobbyist conferences and professional conferences. Arisia and Intercon would be hobbyist. SDExpo, Comdex, RSA would be professional conferences. Some of the hacker conferences and the Burlesque conferences get a little muddy - and I think the muddiness adds a real potential for dissatisfaction on the part of the conference attendees.
I think that in either case - there's a plethora of reasons people want to attend conferences - the least of which is the amusing but essentially useless toys at the vendor stations. And there's a number of ways to be more or less effective at that. And it happens on all levels - physical, mental, polictical, emotional - there's a number of things a smart person can do to prevent conference burnout and make a conference fun...
Not sure if such an idea would fly at a professional conference, although I ponder test running it at Arisia, where you can fly alot of wacky ideas, and I'll at least get some interesting feedback.
Lots of food for thought. I really ought to parse it a bit... and maybe here is a decent place to start.
To start, I took classes from a bunch of tracks, because I am a massive generalist. I took requirements classes, testing classes, user interface design classes and project managment classes. I might have even taken one development class. I find it rather surprising that I didn't take more development classes - I suppose it's the final confirmation that I am no longer a coder. I haven't written a line of code in the last 2 years, I think it may be time to stop calling myself a "Software Developer" and stick with "Computer Engineer". Sigh.
So... Starting with Requirements - took a class called "Get the Right Stuff, Fast: Jogging with the User Requirements Roadmap" - the key point being that it can be much easier to start with "business events" that trigger interaction with a system rather than with traditional use cases. Frequently events lead to use cases fairly easily.
Also took a class on Requirements Management case studies - a guy who works as a Requirements Analyst at Exxon Mobile. He had some general good practice advice on how to best manage requirements. I think my favorite idea was that big, big requirements documents are hard to read and very geeky. You shouldn't expect everyone to read them, and for many users, you need a really high level abstract of no more than a page.
Took quite a few classes on people & project management. I do so like warm & fuzzy classes. I found 2 presenters who I really liked - Naomi Karten and Johanna Rothman. The fact that I hit both of them on the first day contributed alot to my love of the conference. Both were great speakers, but one is an intense introvert and one is an intense extrovert. It was really need to see so clearly how their personalities made for very different, but equally effective methods of presenting material. Naomi did a Keynote called "Tales of Whoa and Customer Satifaction" where she talked about addressing customers with what she jokingly called "psychicology" - the task of figuring out how to make customers happy when they won't tell you. The stuff she outlines were often common sense, but the stories she brought about the topics showed that while it seems straightforward, it often isn't. The one I remember most was 1 - listening. Sometimes just listening to their gripes goes a long way towards getting customer buy-in, even when you don't do anything about the issue. 2 - Figure out how/when/why the customer wants feedback. Every customer would say "in a timely and frequent manner" - but what exactly does that mean? Some like reports, some like phone calls, some like meetings, some want different things in reports... it's best to ask AND to tune in to whether your feedback is helping. She mentioned working with a group that had 4 user groups - and each user group wanted to "involved in the process" in a different way. 3 - consider the customer's context - sometimes you can't make a customer happy, consider when they have stresses outside your sphere and cut them slack.
Johanna was someone I would readily take out to lunch. She's a hoot. She's funny, energetic, and she reminds me of two people - Sheila - a manager I've followed through three companies, who I often choose as a personal mentor because I like and respect her so much, and Patricia - a friend of my family who is a psychiatric nurse, who looks and sounds like Johanna. I ended up attending a number of her sessions, partly cause I like listening to her so much. I took =
- Coaching Your Peers/Team - "coaching" meaning a process of helping *those who want to be helped* to find, evaluate, choose and monitor solutions to their problems. It's harder than it sounds. To be a good coach, you are supposed to stand back and be detached - you can offer solutions, but only after you've really tried to help the person come up with their own, and you have to not put the person or their solutions down. Now... I'm a painfully positive person, but this was really, really, really hard in practice.
- Project Completion Estimation - some nice human-oriented ways to estimate when a project will be done, figure out when things are going wrong, and work on some of the typical problems with status reporting and estimation. I think we often get so caught up with models and analysis tricks, we forget that basically asking people - dude, when will you get done? and if that's too hard a question - asking "what do you have to do to get from here to here... ok, what will take to each of those steps?" is a good point. And... in the end... it's an estimate. If you knew exactly how long it would take... it wouldn't be an estimate.
- 15 Lessons Learned - 15 good ideas for project management, some seemed common sense, some seemed an antithesis to "the right way to do things" -- but I see her side. One of the most interesting was "set a weekly status meeting with each employee individually for 1/2 an hour" it may not take 1/2 an hour, but set aside 1/2 an hour. And avoid status meetings. At first this seemed like madness (madness I tell you), but thinking as an employee - I would have *killed* for half an hour a week with a good manager. And if you can inspire your employees to kill for you, you're probably on the right track.
On testing, I took - "When 2 + 2 = 4 is Wrong" - a class on how testing can go beyond pre-conceived expectations - both with customer-relations/expectations and with technical occurences. The instructor, Micheal Bolton, manages to make testing dicussions interesting, fun and not dry at all - a far cry from most test-oriented classes I've taken.
To recognize the fact that I work for a huge DoD contractor, I took - DoDAF Enterprise Architectures in UML - a govt. spec for architecture description development. I hate to say it, but the spec mostly seems to be yet another over-specification, govt. time wasting exercise. There are probably a few nuggets with good ideas attached to them, but mostly it seems to be so very "meta" that few people will get good use out of it, while standards weenies will have a festival. Maybe I'm just grim. I felt kinda bad for the presenter - he obviously cared about the topic, was a decent technical speaker and certainly knew his stuff... but the topic was nearly vampyric in its ability to suck the life out of all attendees.
On the UI side, I took 2 from Larry Constantine - a paid consultant with an unholy love of fancy powerpoint presentations. The fact that he clearly loved making them made the wacky, funky slightly cutsey presentations OK - because it was clearly coming from a truly geeky place. Also took a class from Elliotte Rusty Harold - who clearly knows his stuff, but has enough of the smart geek affectations that he came across as ever so slightly arrogant. The fact that he really knew his stuff, and could readily justify and elaborate on his opinions made me think well of him, but unfortunately dissuaded me from taking other classes from him.
Elliotte's class was "User Interface Principles in API Design" - he started with the differences between libraries and APIs which had me a little concerned, because my main focus is really libraries, but I think his thoughts on APIs apply just as readily to libraries. Lots of good stuff in his presentation and when I consider the API situations I've been involved in, his principles line up well with my practical experience. I will definitely review my notes when designing an API... in fact it may play well into some of the integration documents I have to review today...
Larry's first class was "Usability by Inspection" - improving Usability with Peer Reviews. Oooo! This is a neat trick. Since we are peer-review oriented as a company (oh, we love them so much, I just can't tell you) - this has some really powerful applicability - even more so if I can get customers and users in the mix. It's a way of finding UI issues by evaluation wireframes or prototypes - the earlier the better - and the meeting is structured in such a way that it generates the most issues in the least time - with no evaluation or judgements whatsoever.
The second class was "Users, Roles and Personas" - a way to develop concepts of operations based on various user models. In UML use case design, you need to specify "Actors" who are defined by how they interact with the system. But in the new "Persona" system that is being touted in many circles (Microsoft uses it) you start with actual user groups and detail not just their system interaction, but also various softer aspects to what type of users you have - for example, my LJ user persona might include the fact that I am a hip, youngish adult who owns a home but lives alone. I like wierd subcultures, and spend many of my evenings doing artistic projects alone or with groups. That I'm an outgoing person who likes meeting new people and is only shy in very large parties where there is no group activity. Now... that may or may not impact how I use a system. Larry advocates a third concept - roles - where you focus on user groups, and think a bit about the user's skills and background - but mostly you work on their goals in using the system. And if you have one or two key roles - you might study the personas within those roles. It was pretty common sense, and I may play with the idea informally the next time I write use cases.
Took "Telling your Design Story" by Rebecca Wirfs-Brook - she's a huge name in the Software Design field, advocating a lot of best practices. Sadly, I don't know whether she had a bad day or what, but she didn't come across well in a class that was mostly (to me) about presenting. She seemed to have a lot of the geek uncomfortable presenting problems - and it was hard to hear from her how to present something. I also felt a little lost in her talking - I've had real trouble with telling my design story - which diagrams to include, where to go with the presentation, how to get the best information out of a peer review... And I didn't feel like I had any great nugget of information... it may be that I need Design Stories Advanced, because I'm already a better presenter than most geeks.
Another keynote - "Quick or Dead - Organizational Velocity for an Impatient Age" - was kind of neat - Tom Demarco's posit is that we spend way, way too much time in meetings and emails - rather than actually making decisions and doing work. He suggests a number of ways to limit overhead by imposing some rather dramatic rules. While I respect his ideas, I was little teed of by his non-answer answer to my question - all his advice was to management, who can make up some of these rules. How exactly does one do anything when they are not management powerful enough to dictate the rules? He suggested waiting until you are management. That's not an answer. If I wait for that to happen, there's a strong chance that there won't be a company to manage.
Was particularly inspired by the Software Security keynote by Gary McGraw. The topic didn't do much for me - he basically points out how very much at risk we are in our current ways of implementing software, and suggests a number of key ways to improve security - particularly automated code review and architectural analysis. That's great, I get it. Not hard. But what really impressed me was his ability to grab the audience about a topic which could be preachy, and could be boring. He really knew how to speak to a bunch of software geeks. I couldn't help but think ... wow... this guy would be fun to work for.
Took Per Kroll's class - Process Improvement via Best Practices. Now... by Wed afternoon I was exhausted, so I know I sucked as an audience, but this one really failed my attention span. I accientally fell asleep in it, and had real trouble understanding his points as anything but "duh... that's obvious?". I get the feeling there might be something deeper, but I failed to grasp much of anything.
I was, in fact, so turned off that I almost didn't take Susan Burke's "Practical Best Practice". I'm very glad I did. She talked about some of what she's found that you MUST do to have a project that meets its goals - but pointed out that it didn't matter how you did it. In going along, she talks about some ways to do it, and she pointed out some ways where companies didn't do the "right thing" by the official process but where it turned out to be the right thing for the company. It was inspiring and englightening. I took away the idea that it's not always about doing the right process correctly as it is taking the tools and resources you've got and making them work for you as well as you can.
jducouer got me to go to "Making Software Self-Reliant" by pointing out that it was really an application security class. I'm glad he did. Although about half was kinda boring cause it was a run at security basics - the other half was some great ideas. Software integrity maintenance can get very funky and raises a whole field of interesting problems. I may not ever do any of these, but it's good to have them stashed away in my memory. At the end of the class, the instructor targeted jducouer and I as the best question askers in class. I was flattered.All that stuff has me thinking "boy, I wish presenting at professional conferences was part of my career". Yeah, it sounds really hard, but fun. I think I might want to work towards that. I've enjoyed SCA classes, and Arisia classes - and I wish I got to spend the time in class prep doing something that was career enhancing and not just kinda fun.
My first thought for a class was a "how to attend conferences" class. There's two types of conferences, as I see it - hobbyist conferences and professional conferences. Arisia and Intercon would be hobbyist. SDExpo, Comdex, RSA would be professional conferences. Some of the hacker conferences and the Burlesque conferences get a little muddy - and I think the muddiness adds a real potential for dissatisfaction on the part of the conference attendees.
I think that in either case - there's a plethora of reasons people want to attend conferences - the least of which is the amusing but essentially useless toys at the vendor stations. And there's a number of ways to be more or less effective at that. And it happens on all levels - physical, mental, polictical, emotional - there's a number of things a smart person can do to prevent conference burnout and make a conference fun...
Not sure if such an idea would fly at a professional conference, although I ponder test running it at Arisia, where you can fly alot of wacky ideas, and I'll at least get some interesting feedback.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2006-09-15 08:00 pm (UTC)I think for me not going to conferences it's about 1. the large groups of folks that know much more than me. I'm not always confident in my knowledge, until someone asks me a question, I'm caught off guard and answer it w/out thinking. 2. finding the good ones. 3. getting my companies to pay for them.
I really need to start attending some. But time where is the time?
no subject
Date: 2006-09-22 09:55 pm (UTC)To be fair, that wasn't how I took DeMarco's answer. My read of what he said was the inverse: "People always tell me that only managers can make these changes. That's not true -- everyone can make these changes, and you can do it, too." The problem was that he completely ducked the actual point of your question, which was *how* to start the process of making these changes if you aren't a manager. IMO, he wasn't really listening to what you asked, and instead answered the boilerplate question that he *assumed* you were asking. At least, that's the way I heard it...
At the end of the class, the instructor targeted [info]jducouer and I as the best question askers in class.
Really, I think he targeted you, and I got pulled in simply because I seemed to be there with you. (Did I actually ask any questions in that one? I don't think I did.)
no subject
Date: 2006-09-25 02:00 pm (UTC)You could be right. Of course, I had assumed that I *could* make changes - it was the how that was my problem. So having him tell me what I already knew could have gotten discarded by my "not new info" filter, while I waited for the useful information.
Interestingly, Johanna Rothman and I talked about precisely that topic after her last presentation. She, too, discourages status meeting rituals. So I did walk away with some good ideas on how to optimize communication.
And I have been reading Naomi Karten's book on managing customer expectations, where she says to be careful that you answer the question asked, not expound withouth really thinking and listening. It's so easy to do.
Security Presentation
Maybe. I couldn't tell, cause I was sitting next to you, whether you were providing body-language dialogue, and I couldn't precisely remember if you asked a question, or not... since he did ask about both of us, I figured I wouldn't presume that it was All Me. :)
Sometimes I've had profs respond to me simply because I was the one person in class who looked alive from the neck up. So commentary doesn't have to be verbal to get noticed.