Midweek; past the halfway mark (in time, anyway) of teaching Sun's SL-275 "Java Programming Language" course. I wonder how many times I've taught this course over the past 12 years... I still love it! Even though its just the basics, there's something just plain fun about introducing Java to new minds.
This one is interesting; 5 of the students have flown from Stockholm, Sweden all the way to Cape Town, especially to attend this course! Wow! (Of course they might pick up some sunshine in the middle of the Northern Winter. I guess that may help. ;-)
The trouble is that Java has grown so large over the years that there's a hard choice: cover (mostly) everything in a shallow way? or leave a lot out to get more depth?
Add to that, Sun punt the course as "the" prerequisite for writing the Java Programmer Certification Exam. Frankly, I shudder at the thought! Programmers would need a lot more than just this course to be in a position to tackle the exam. And programmers who are in a good position to tackle the exam don't really need this course!
As it currently stands, the course is inadequate for students attending it in order to prepare for the Certification Exam. There's very little I can teach them and still remain reasonably close to the course materials. The course is pretty good as an intro to Java for experienced developers, but pressure from more experienced developers in the class -- especially when they are in a significant majority -- could, if I'm not careful and strong in controlling it, leave the less-well-versed-in-Java students stranded. (I assure you that I don't let this happen.)
The solution is to split the course in two. One would be a truly introductory course aimed at otherwise-experienced developers. And the second would avoid all basic material -- syntax of if statements, declaring classes and interfaces -- in favour of homing-in on the deeper, less well known details of Java execution that the Certification Exam aims to test.
I sure wish Sun would do it soon! It would make life so much easier for us trainers, and would deliver a much better focussed value to customers.
26 March 2009
18 January 2009
Open Course Development
It strikes me that, whilst I am deep into the design of a number of programming-related courses, I am making a terrible mistake. The mistake of not talking about what I'm up to. The mistake of assuming the entire burden of course development.
Instead I ought to be employing Open Source development principles. At least some of them. Seems to me that (at least) the Thousand Eyeballs principle applies quite well, at least to the course structure, content and sequencing.
Right now I'm in the thick of codesigning three courses that I (with good reason!) believe are served very poorly by the corporate training world, and I think I can design courses that deliver much, much better value for money. The three I'm busy with right now are "Elements of Object Oriented Programming", "OO Analysis and Design" and "Patterns of Software Design".
"Elements" is intended as an introductory foundation course for programmers coming from a non-OO background who want/need to learn the OO concepts quite quickly. Nobody in their right minds would believe that a 3-day "Elements"-style course is going to turn any Natural programmer into an OO expert... we all know that the process of learning to Think Objects takes 9 months. But I do believe that it is possible to teach the foundation concepts really well.
"OO A&D" seeks to demystify the analysis and design process -- to the degree that it is possible to demystify an essentially creative process.
And, finally, the "Design Patterns" course aims to teach something useful about... well... design patterns. I've taught variations on this one numerous times over the years, but never really been satisfied with the value I was able to deliver, so I've completely rethought the approach from the ground up, and -- I think -- come up with something Just a Bit Different. A whole lot of the Design Patterns courses I've seen offered seem to add up to nothing more than a whole lot of droning through the GoF patterns catalogue. I think there's a whole bunch more to the topic than that, and I plan to use the course to explore that.
I've also outlined a whole bunch of other courses that I want to develop over the next year or so, but developing even these three is a daunting enough task for now.
I'm openly stealing some of the concepts -- the approach to teaching -- exemplified by the Head First books, and I'm really interested to see that O'Reilly are themselves developing a bunch of courses -- I gather they'll be web-based courses -- under the Head First brand. Good for them! It's about time we saw a better approach to teaching technical stuff.
So I'm aiming to make the courses colourful, interactive and fun. I'm trying to build in lots of of pictures, music, video, games, practical exercises, movement. (Trying to figure out how to include flavours and smells... ;-)
I've also been breaking away -- especially for the "Elements" course -- from linearity in the course sequencing. Essentially I'm developing using a Spiral Model. First introduce a concept, then go on to related concepts, etc., in time spiralling round to repeat the discussion of the topic in greater depth, and so on. I've long known that it is too easy to give too much detail all at once, so for my own course material, I'm explicitly shying away from that. I think it equates -- somewhat -- to the concept of Progressive Disclosure in user-interface design. As luck would have it, after several weeks working on this stuff, I tripped across this article just today, and went "Aha! Somebody else who Gets It!"
Right now I am stuck. Struggling to come up with good great practical ways of exploring the topic of "Encapsulation" in a way that doesn't stray too far from the way it's meant in OO programming, whilst remaining vaguely interesting.
As soon as I get the relevant bits of machinery up and running, I'll post the course outlines. (Will take a while: I am unexpectedly and suddenly off to London for a week for a spot of consulting work.)
Instead I ought to be employing Open Source development principles. At least some of them. Seems to me that (at least) the Thousand Eyeballs principle applies quite well, at least to the course structure, content and sequencing.
Right now I'm in the thick of codesigning three courses that I (with good reason!) believe are served very poorly by the corporate training world, and I think I can design courses that deliver much, much better value for money. The three I'm busy with right now are "Elements of Object Oriented Programming", "OO Analysis and Design" and "Patterns of Software Design".
"Elements" is intended as an introductory foundation course for programmers coming from a non-OO background who want/need to learn the OO concepts quite quickly. Nobody in their right minds would believe that a 3-day "Elements"-style course is going to turn any Natural programmer into an OO expert... we all know that the process of learning to Think Objects takes 9 months. But I do believe that it is possible to teach the foundation concepts really well.
"OO A&D" seeks to demystify the analysis and design process -- to the degree that it is possible to demystify an essentially creative process.
And, finally, the "Design Patterns" course aims to teach something useful about... well... design patterns. I've taught variations on this one numerous times over the years, but never really been satisfied with the value I was able to deliver, so I've completely rethought the approach from the ground up, and -- I think -- come up with something Just a Bit Different. A whole lot of the Design Patterns courses I've seen offered seem to add up to nothing more than a whole lot of droning through the GoF patterns catalogue. I think there's a whole bunch more to the topic than that, and I plan to use the course to explore that.
I've also outlined a whole bunch of other courses that I want to develop over the next year or so, but developing even these three is a daunting enough task for now.
I'm openly stealing some of the concepts -- the approach to teaching -- exemplified by the Head First books, and I'm really interested to see that O'Reilly are themselves developing a bunch of courses -- I gather they'll be web-based courses -- under the Head First brand. Good for them! It's about time we saw a better approach to teaching technical stuff.
So I'm aiming to make the courses colourful, interactive and fun. I'm trying to build in lots of of pictures, music, video, games, practical exercises, movement. (Trying to figure out how to include flavours and smells... ;-)
I've also been breaking away -- especially for the "Elements" course -- from linearity in the course sequencing. Essentially I'm developing using a Spiral Model. First introduce a concept, then go on to related concepts, etc., in time spiralling round to repeat the discussion of the topic in greater depth, and so on. I've long known that it is too easy to give too much detail all at once, so for my own course material, I'm explicitly shying away from that. I think it equates -- somewhat -- to the concept of Progressive Disclosure in user-interface design. As luck would have it, after several weeks working on this stuff, I tripped across this article just today, and went "Aha! Somebody else who Gets It!"
Right now I am stuck. Struggling to come up with good great practical ways of exploring the topic of "Encapsulation" in a way that doesn't stray too far from the way it's meant in OO programming, whilst remaining vaguely interesting.
As soon as I get the relevant bits of machinery up and running, I'll post the course outlines. (Will take a while: I am unexpectedly and suddenly off to London for a week for a spot of consulting work.)
30 December 2008
Teaching Servlets and JSP
It's the end of a week teaching Sun's SL-314 course -- "Web Component Development with Servlets and JSP" in Cape Town. It's been challenging and demanding, but, above all, fun! I had a great bunch of participants on the course, a couple of whom were old friends from an "Intro to Java" course (Sun's SL-275 course) some months ago.
The course materials are pretty good, although with a couple of misfeatures -- in my ever-so-humble opinion, as always -- and one glaring omission! (Never mind the details; I won't bite the hand that feeds me. This time. Rest assured that I've passed my thoughts on to the good people at Sun Education.) However, the whole sequencing and structure of the course has set me thinking, "How would I go about structuring such a course? What examples and challenges would I use for lab work?"
I take this teaching stuff pretty seriously1. So I'm always looking for ways to add value above and beyond what is offered by the course materials. Of course, the most valuable thing a trainer can bring into these sorts of skills-oriented technical courses is one's own experience actually using the technology on real-world projects. But beyond that, a lot of value can be added (or subtracted) by the sequence, timing and manner in which the material is presented. In a 5-day course time is terribly limited, so practical examples and labwork are necessarily very constrained, so it is very hard to work-up really good examples.
Setting examples and lab-work for courses is actually a very hard problem. You don't want to restrict the work to toy problems -- students pick up on that very quickly, and, even more quickly, lose interest in the course material, and, more importantly and with longer-term consequences for the remainder of the course, they lose respect for the course (and sometimes for the instructor, too.) On the other hand, time is very limited -- perhaps a couple of hours for any given issue, so extensive examples take too long to implement.
Then, too, one is in the position of trying to illustrate and/or reinforce key points in the course material, and developing actual code always involves a measure of extraneous detail -- housekeeping code. It adds nothing to the teaching purpose of the exercise, but it certainly chews into the time available!
And -- not to be neglected -- I think it is important that examples be at least a little bit entertaining. After all, we can do order-entry at work anytime... But there's a borderline across which "entertaining" becomes "irrelevant". (Much the same can be said of micro-benchmarks.)
Relevance? You wanted relevance from a blog post? As opposed to rambling?
OK.
I'm starting to put together my own material for a number of courses, centring around the gaps in the corporate professional training space (OO and Java technical matters, of course.) that I've been seeing over the past decade.
(Of course, now is a brilliant time to be putting my own course-material together. In times of economic downturn, the very first thing to get the axe is training! How short-sighted is that?)
[1] As with most things, the more you put into it, the more you get out of it!
The course materials are pretty good, although with a couple of misfeatures -- in my ever-so-humble opinion, as always -- and one glaring omission! (Never mind the details; I won't bite the hand that feeds me. This time. Rest assured that I've passed my thoughts on to the good people at Sun Education.) However, the whole sequencing and structure of the course has set me thinking, "How would I go about structuring such a course? What examples and challenges would I use for lab work?"
I take this teaching stuff pretty seriously1. So I'm always looking for ways to add value above and beyond what is offered by the course materials. Of course, the most valuable thing a trainer can bring into these sorts of skills-oriented technical courses is one's own experience actually using the technology on real-world projects. But beyond that, a lot of value can be added (or subtracted) by the sequence, timing and manner in which the material is presented. In a 5-day course time is terribly limited, so practical examples and labwork are necessarily very constrained, so it is very hard to work-up really good examples.
Setting examples and lab-work for courses is actually a very hard problem. You don't want to restrict the work to toy problems -- students pick up on that very quickly, and, even more quickly, lose interest in the course material, and, more importantly and with longer-term consequences for the remainder of the course, they lose respect for the course (and sometimes for the instructor, too.) On the other hand, time is very limited -- perhaps a couple of hours for any given issue, so extensive examples take too long to implement.
Then, too, one is in the position of trying to illustrate and/or reinforce key points in the course material, and developing actual code always involves a measure of extraneous detail -- housekeeping code. It adds nothing to the teaching purpose of the exercise, but it certainly chews into the time available!
And -- not to be neglected -- I think it is important that examples be at least a little bit entertaining. After all, we can do order-entry at work anytime... But there's a borderline across which "entertaining" becomes "irrelevant". (Much the same can be said of micro-benchmarks.)
Relevance? You wanted relevance from a blog post? As opposed to rambling?
OK.
I'm starting to put together my own material for a number of courses, centring around the gaps in the corporate professional training space (OO and Java technical matters, of course.) that I've been seeing over the past decade.
(Of course, now is a brilliant time to be putting my own course-material together. In times of economic downturn, the very first thing to get the axe is training! How short-sighted is that?)
[1] As with most things, the more you put into it, the more you get out of it!
15 November 2008
Brain Delayed - In Transit
On my way down to Cape Town -- yet again -- for a Java Intro course -- yet again...
On arrival at the checking-desk, get told that I'm not booked to go to Cape Town, but am eventually found to be on my way to George from Cape Town. Returning to Cape Town on Friday. Wow! What happened here? OK, so off to the booking office where I have to fork out an extra R700 to cover the ticket change. Fortunately the SAA staff at George and I know each other by first name. (As a result I seldom have to produce ID to check in -- most of the staff can ID me by sight. Beat that for personal service! ;-)
Sudden thought: Let's check the car rental reservation. Sure enough! I'm booked to pick up a car in George. Get that one changed. Things are so screwed up at this point that I called the B&B where I'm allegedly booked to stay in CT. Yes, indeed, they DO have a reservation for me.
WTF was somebody at the travel agency thinking? This guy is going to fly from Cape Town to George, pick up a car there, and then stay 5 nights in Cape Town before reversing the journey?
Now I only have to waste an extra hour-and-a-half in the airport. I just love hanging about in airports, don't you?
On arrival at the checking-desk, get told that I'm not booked to go to Cape Town, but am eventually found to be on my way to George from Cape Town. Returning to Cape Town on Friday. Wow! What happened here? OK, so off to the booking office where I have to fork out an extra R700 to cover the ticket change. Fortunately the SAA staff at George and I know each other by first name. (As a result I seldom have to produce ID to check in -- most of the staff can ID me by sight. Beat that for personal service! ;-)
Sudden thought: Let's check the car rental reservation. Sure enough! I'm booked to pick up a car in George. Get that one changed. Things are so screwed up at this point that I called the B&B where I'm allegedly booked to stay in CT. Yes, indeed, they DO have a reservation for me.
WTF was somebody at the travel agency thinking? This guy is going to fly from Cape Town to George, pick up a car there, and then stay 5 nights in Cape Town before reversing the journey?
Now I only have to waste an extra hour-and-a-half in the airport. I just love hanging about in airports, don't you?
25 September 2008
Back in the Saddle: Java 101
Interesting to be back in the Training Game. It is a Java 101 (Introduction to Java Programming for Programmers) course. With some differences.
Its all for one corporate client. My God, its been a long time since I had to deal with Corporate IT Thinking. There's some of it that exists for good reason. And then there's a whole lot of crap. Stuff that's more to do with politics, staking out of turf, ass-covering... The real downside for a Java 101 course is not so huge, but still... everybody is from the same organisation, though they might well be from different planets, considering the departments they're drawn from... But, there's still not a lot of cross-pollination of ideas. The whiff of groupthink.
I've taken the format of the "usual" 5-day course and adapted it somewhat to a 6-day format split over two 3-day sessions a couple of weeks apart, so there's a lot more breathing room, but, for any "Intro to X" course there is a certain body of knowledge that has to be covered, and there's a certain Logic to the order in which material has to be presented, so there's no escaping... There's just a bunch of stuff that has to get taught before people can realistically handle a tutorial (a.k.a. "homework".) All resulting in a pretty heavy First Three Days. I've just finished Day 3 ("Subscriber Trunk Dialing".) I'm exhausted.
Differences: In the usual "5-day" format I'd have to be really winding up my energy to stay the pace for Day 4. This time around I get a week-long break, and get to start fresh. Mmmmm... Gooooood!
Happily I have a fairly bright bunch. Quite a mix of backgrounds, all the way from a university graduates to "just-a-programmer-can-I-google-a-solution-and-cut-n-paste-the-code". The usual chirpy heckler who borders, at times, on irritating, but helps keep things alive. The usual "deeply tech" who catches all my mistakes and omissions, and keeps me on my toes.
I'll confess that I'm having a ball!
Its all for one corporate client. My God, its been a long time since I had to deal with Corporate IT Thinking. There's some of it that exists for good reason. And then there's a whole lot of crap. Stuff that's more to do with politics, staking out of turf, ass-covering... The real downside for a Java 101 course is not so huge, but still... everybody is from the same organisation, though they might well be from different planets, considering the departments they're drawn from... But, there's still not a lot of cross-pollination of ideas. The whiff of groupthink.
I've taken the format of the "usual" 5-day course and adapted it somewhat to a 6-day format split over two 3-day sessions a couple of weeks apart, so there's a lot more breathing room, but, for any "Intro to X" course there is a certain body of knowledge that has to be covered, and there's a certain Logic to the order in which material has to be presented, so there's no escaping... There's just a bunch of stuff that has to get taught before people can realistically handle a tutorial (a.k.a. "homework".) All resulting in a pretty heavy First Three Days. I've just finished Day 3 ("Subscriber Trunk Dialing".) I'm exhausted.
Differences: In the usual "5-day" format I'd have to be really winding up my energy to stay the pace for Day 4. This time around I get a week-long break, and get to start fresh. Mmmmm... Gooooood!
Happily I have a fairly bright bunch. Quite a mix of backgrounds, all the way from a university graduates to "just-a-programmer-can-I-google-a-solution-and-cut-n-paste-the-code". The usual chirpy heckler who borders, at times, on irritating, but helps keep things alive. The usual "deeply tech" who catches all my mistakes and omissions, and keeps me on my toes.
I'll confess that I'm having a ball!
11 September 2008
Infrastructure Fix
Finally! Took a day off from preparing for the (Advanced Architecture and Design) course I'm hosting next week, and spent the time getting my local infrastructure back on its feet after a breakdown some weeks ago. Basically the LAN server died... motherboard or CPU. Suddenly we realised just how much we've come to depend on that little machine! DNS caching, plus names for all the machine on our farm-LAN1, HTTP proxy, local Subversion server, file-share, music streaming, and not to mention supplying the base-infrastructure for some Jini services that come and go as we play around with Jini and JavaSpaces.
So now that we've beefed-up the CPU and disk a bit, it was "just" a case of getting all the bits of server software installed and cleanly configured. Nothing difficult, but it all takes time! Especially when you're a bit.... fastidious?... about getting the config "right", as opposed to "just poking things until they work". I truly despise "voodoo config" where people don't really make the effort to understand the impact and effects of what they're doing, and fuck it up royally as a result. "Oh, well, I'll install mod_disk_cache and mod_mem_cache... after all, two caches must be better than one, mustn't they?" Ding! You Do Not Win The Lounge Suite!
Well, its been fun! And finally I can forget all about it again until the next hardware failure. The only thing I really would like to achieve is to get the server quiet2, and get its power-consumption way, way down! And maybe have a few more tiny-little servers...
[1] The term "server farm" takes on a whole new significance ;-)
[2] Yeah, I'm a complete arsehole about noise. I really, really, really hate noise...
So now that we've beefed-up the CPU and disk a bit, it was "just" a case of getting all the bits of server software installed and cleanly configured. Nothing difficult, but it all takes time! Especially when you're a bit.... fastidious?... about getting the config "right", as opposed to "just poking things until they work". I truly despise "voodoo config" where people don't really make the effort to understand the impact and effects of what they're doing, and fuck it up royally as a result. "Oh, well, I'll install mod_disk_cache and mod_mem_cache... after all, two caches must be better than one, mustn't they?" Ding! You Do Not Win The Lounge Suite!
Well, its been fun! And finally I can forget all about it again until the next hardware failure. The only thing I really would like to achieve is to get the server quiet2, and get its power-consumption way, way down! And maybe have a few more tiny-little servers...
[1] The term "server farm" takes on a whole new significance ;-)
[2] Yeah, I'm a complete arsehole about noise. I really, really, really hate noise...
22 August 2008
Courseware: The Next Step
Just received my Instructor's Manual (only a week late!) for Sun's SL-425 "Architecting and Designing J2EE Applications"1 and I'm very happy to see that it is basically the same course as the old "Architecture and Design" course I taught several times lo' those many years ago when I was so frequently on my feet as "Herr Instructor".
This is easily the best2 course I ever "taught"! It is aimed a senior, experienced designers and developers3, and confronts head-on the sticky few-good-answers stuff, the ill-defined and the fuzzy grey areas. I have always run the course in a round-table "workshop" format. When you get 8 or 10 senior developers into a room, each with a decade or two of experience, you're not going to be their Teacher. And you sure as hell better not have a tender ego. "I don't know" is a frequent answer. The job is much more one of facilitation: Keeping discussion on-track, drawing quieter participants into the discussion, acknowledging expertise and encouraging people to share their (often vast!) experience. I found it hugely enjoyable to engage with seriously expert people, and to facilitate drawing out their expertise. And I learned a lot!
It has been a very long time that I have wanted to run this course again, so I'm looking forward to it hugely!
So: I have a couple of weeks to catch-up on the changes since last it taught facilitated this course. Mainly the technology has caught up with the tech: Where there was only CORBA or RMI a decade ago, there are now a host of J2EE technologies, and the course now includes them. Where a decade ago the whole idea of enterprise-architecture patterns was pretty new and unheard-of, now there's the J2EE Blueprints Catalogue (even if those yanks can't spell "Catalogue"!)
Of course I'll probably be unable to resist the temptation fo slipping in a few sly teasers about Jini and Javaspaces -- but Hey! Sun seem to encourage instructors to go beyond the boundaries of the course material, and encourage us to bring our own experience into the classroom. Or workshop in this case.
I am still thinking about floating my own version of this course, perhaps a little less attached to Java tech, so that more people might engage. The absolutely best runs of the course were when we had many people from different organisations and backgrounds. Cross-pollination really works. Ask plants!
----
[1] Is there such a word as "Architecting"? My spelling-chequer doesn't seam to think sew.
[2] "Best" from my point of view, anyway. Though, I can honestly report that every participant I've ever had on this course reported exactly the same sentiment!
[3] I don't believe the term/job-title "Architect" had any currency back then. Whilst it had certainly been invented4 it was certainly not popular. In fact there still was no such Job Title as "Software Designer" back then. My boss had to invent it for me!
[4] I believe that I was one of the (probably many) inventors of "Software Architect"a s a job title. Certainly not unique in that, though! Back in 1989 a technical career-path looked much like "Junior Programmer - Programmer - SeniorProgramer - Junior Systems Analyst - Systems Analyst - Senior Systems Analyst - Business Analyst..." I rejected the whole deal5 stating "Analysis is The Art of Taking Things Apart. I don't want to do that. I want to put things together, and that's called Design (and, at the high-end, Architecture)."
[5] ... in a bi-annual merit-assessment that became (in)famous as the one where I told my Manager, "If you want loyalty, get a dog! This is a business relationship; didn't you understand that?" Needless to say I got no increase that year. ;-)
This is easily the best2 course I ever "taught"! It is aimed a senior, experienced designers and developers3, and confronts head-on the sticky few-good-answers stuff, the ill-defined and the fuzzy grey areas. I have always run the course in a round-table "workshop" format. When you get 8 or 10 senior developers into a room, each with a decade or two of experience, you're not going to be their Teacher. And you sure as hell better not have a tender ego. "I don't know" is a frequent answer. The job is much more one of facilitation: Keeping discussion on-track, drawing quieter participants into the discussion, acknowledging expertise and encouraging people to share their (often vast!) experience. I found it hugely enjoyable to engage with seriously expert people, and to facilitate drawing out their expertise. And I learned a lot!
It has been a very long time that I have wanted to run this course again, so I'm looking forward to it hugely!
So: I have a couple of weeks to catch-up on the changes since last it taught facilitated this course. Mainly the technology has caught up with the tech: Where there was only CORBA or RMI a decade ago, there are now a host of J2EE technologies, and the course now includes them. Where a decade ago the whole idea of enterprise-architecture patterns was pretty new and unheard-of, now there's the J2EE Blueprints Catalogue (even if those yanks can't spell "Catalogue"!)
Of course I'll probably be unable to resist the temptation fo slipping in a few sly teasers about Jini and Javaspaces -- but Hey! Sun seem to encourage instructors to go beyond the boundaries of the course material, and encourage us to bring our own experience into the classroom. Or workshop in this case.
I am still thinking about floating my own version of this course, perhaps a little less attached to Java tech, so that more people might engage. The absolutely best runs of the course were when we had many people from different organisations and backgrounds. Cross-pollination really works. Ask plants!
----
[1] Is there such a word as "Architecting"? My spelling-chequer doesn't seam to think sew.
[2] "Best" from my point of view, anyway. Though, I can honestly report that every participant I've ever had on this course reported exactly the same sentiment!
[3] I don't believe the term/job-title "Architect" had any currency back then. Whilst it had certainly been invented4 it was certainly not popular. In fact there still was no such Job Title as "Software Designer" back then. My boss had to invent it for me!
[4] I believe that I was one of the (probably many) inventors of "Software Architect"a s a job title. Certainly not unique in that, though! Back in 1989 a technical career-path looked much like "Junior Programmer - Programmer - SeniorProgramer - Junior Systems Analyst - Systems Analyst - Senior Systems Analyst - Business Analyst..." I rejected the whole deal5 stating "Analysis is The Art of Taking Things Apart. I don't want to do that. I want to put things together, and that's called Design (and, at the high-end, Architecture)."
[5] ... in a bi-annual merit-assessment that became (in)famous as the one where I told my Manager, "If you want loyalty, get a dog! This is a business relationship; didn't you understand that?" Needless to say I got no increase that year. ;-)
Subscribe to:
Posts (Atom)
