May 15, 2012 at 6:50 pm
The key thing here is (pace Steve) we don't actually "do the same work for decades". Come to think of it, really good carpenters don't either.
Carpenters' tools from the time of Jesus have been unearthed in the Holy Land - and what is striking about them is that they are tools modern carpenters would still recognise.
Plus ça change, plus c'est la même chose ... and our trade is not terribly different. A bit is still a bit. A byte is still a bite. And a computer is still a computer.
May 15, 2012 at 9:55 pm
Jeff, Craig, you've misread. I quoted Steve accurately and, in his response, he shows that he understands the distinction between "job" and "work". I'm sure you do, too.
Yes. They have been doing the same job. Yes. They have been using the same tools.
No. They have not been doing the same work. The work they do now is significantly better than the work they did when they started.
Yes. A byte is still a byte. Yes. A computer is still a computer.
No. We don't approach them the same way as we used to. Our approach to them changes with maturity and experience.
I think the same is true of a carpenter; after a while he knows more about keeping his tools perfectly in shape, and can size up a piece of wood before cutting into it.
This is a major reason *why* it can be rewarding (both to ourselves and our employeers/clients) for us to stay in the same job as opposed to "growing our career into management positions".
Also, yes, this is a matter of opinion. But I think you'll find that you both actually agree with me ;-).
BTW -- I brought up elaborators and abstractors because I personally find it a useful way to express how developers grow and improve. It's not a big deal. But... FWIW... I'll continue with it here:
Both types use the same tools as developers, with varying degrees of facility. When a developer has experience both as an elaborator *and* as an abstractor, s/he tends to use *all* the available tools (some old, some recently acquired) better. The more varied your perspective, the better you use everything you have. It's interesting to watch.
>L<
May 15, 2012 at 10:10 pm
I think you'll find that you both actually agree with me ...
Not really. Not for the sake of being obstinate, but for reason of simply not understanding your point.
I just hope they don't make a movie with Meryl Streep playing a carpenter, or I'll get even more confused.
May 15, 2012 at 10:21 pm
I believe it depends.
Based on resource- skills, time-budget you can decide what kind of engineering you can do. Knowledge of tools and committment is required.
May 15, 2012 at 10:22 pm
Craig-315134 (5/15/2012)
I just hope they don't make a movie with Meryl Streep playing a carpenter, or I'll get even more confused.
<rofl> Now that you mention it, there *is* something expert developers and great actors have in common: a disdain for excessive type-casting.
Over and out.
>L<
May 16, 2012 at 6:57 am
Lisa Slater Nicholls (5/15/2012)
The work they do now is significantly better than the work they did when they started....{snip}...
We don't approach them the same way as we used to. Our approach to them changes with maturity and experience.
Ah... in that vein, agreed! Well, mostly. There are tricks of the trade in the world of computers that I've been using since I first learned how to program in the '60s and that includes the "wire punch boards" that I used to "program" with. A lot of people never learn these tricks because they're considered to be "out of date", unstylish, slow, or even "backwards", and they've actually been "out of date" long enough where we're on the 3 or 4th "generation" of "programmers" that haven't even heard of the techniques never mind understand or use them.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 16, 2012 at 7:30 am
What Jeff said.
The minis I first worked on in the late '80s had 8K of memory for programs and 8K of memory for data and we were writing in a pseudo-compiled form of BASIC. Working on them taught me the most valuable lessons: never waste cycles or memory space. Always code as cleanly and elegantly as possible. Use lots of remarks. Know the weak points and error trap them.
Reminiscences aside, my point is that I'm still using those habits today. I wish some of my younger colleagues did...
I also wanted to say that I found Lisa's remarks about elaborators and abstractors fascinating. It's a way of looking at the business of coding that I'd never heard before, but the more I think about it, it keeps ringing true. I keep remembering people who were examples of each type.
Lisa, how about expanding your thoughts on the two types into a larger article?
Sigerson
"No pressure, no diamonds." - Thomas Carlyle
May 16, 2012 at 9:09 am
I also wanted to say that I found Lisa's remarks about elaborators and abstractors fascinating.
I didn't follow them at all. I wouldn't mind (no pun intended) an elaboration, or perhaps a simplification. Or even a reiteration (maybe if I read her words enough, they'll sink it).
May 16, 2012 at 9:24 am
Capt. Sigerson (5/16/2012)
What Jeff said.The minis I first worked on in the late '80s had 8K of memory for programs and 8K of memory for data and we were writing in a pseudo-compiled form of BASIC. Working on them taught me the most valuable lessons: never waste cycles or memory space. Always code as cleanly and elegantly as possible. Use lots of remarks. Know the weak points and error trap them.
Reminiscences aside, my point is that I'm still using those habits today. I wish some of my younger colleagues did...
. . .
Absolutely. I think that one of the most important reasons why I have noit become a dinosaur is that I learned the craft of development when I had to squeeze processing of bills of material onto an IBM 360/40 mainframe that had 128 KB of memory and 60 MB of disk space.
It really forced me to think the entire design through before I wrote the first line of code. That seems to be something lost in today's Agile precept "one l;ine of code at a time, and a test after each change." (Yes, that does not apply to writing T-SQL or SSIS scripts...)
May 16, 2012 at 9:40 am
Revenant (5/16/2012)
Capt. Sigerson (5/16/2012)
What Jeff said.The minis I first worked on in the late '80s had 8K of memory for programs and 8K of memory for data and we were writing in a pseudo-compiled form of BASIC. Working on them taught me the most valuable lessons: never waste cycles or memory space. Always code as cleanly and elegantly as possible. Use lots of remarks. Know the weak points and error trap them.
Reminiscences aside, my point is that I'm still using those habits today. I wish some of my younger colleagues did...
. . .
Absolutely. I think that one of the most important reasons why I have noit become a dinosaur is that I learned the craft of development when I had to squeeze processing of bills of material onto an IBM 360/40 mainframe that had 128 KB of memory and 60 MB of disk space.
It really forced me to think the entire design through before I wrote the first line of code. That seems to be something lost in today's Agile precept "one l;ine of code at a time, and a test after each change." (Yes, that does not apply to writing T-SQL or SSIS scripts...)
Before you can do Agile or Scrum type development, there still needs to be a period of time up front to develop the system requirements. There needs to be a consensus on what the system should do so that the features that need to be designed and implemented can be identified and prioritized. Not all of them need to be full fleshed out initially, but the first core functions should be. A business analyst and databaae Analyst/Architect should then been fleshing out the more detailed requirements for the first 3 or 4 sprints while the project team works on Sprint 0, getting the development and test environments setup and ready. The Business Analyst and Database Analyst/Architect then continue to work forward fleshing out the additional requirements for each future Sprint, staying 3 or 4 Sprints ahead of the development team, as well as working with them at the beginning of each Sprint during the Sprint Planning session helping to make sure that the development team understands the requirements of each task they agree to work on for that sprint.
The problem I have seen is the lack of the Business Analyst and Database Analyst/Architect working on the project in this fashion, at least on the projects I have been involved in so far.
May 16, 2012 at 9:53 am
Capt. Sigerson (5/16/2012)
Lisa, how about expanding your thoughts on the two types into a larger article?
Well, as all of us oldsters probably know, the concept isn't original with me. One of the advantages of experience is having read Dr. Dobbs etc for a long time <s>. (If memory serves... yep, Kent Beck's writings were probably the first time I heard the terms although I don't know that he originated them. See http://www.drdobbs.com/mobile/184409176 .)
I just use this division to try to organize my thoughts at times. Evidently my thoughts are not well organized even so, or Craig would be happier with my expression of them! I think I was mostly thinking out loud, trying to find a way to indicate happiness at being in this occupation for all its warts.
FWIW I used to express my thoughts more clearly, and I used to write a lot. More than a year as a monthly columnist for Databased Advisor, articles for many other magazines, 7 books, and a long stint as a an editor later, I don't often enjoy it any more. I write really good user docs as well as tech specs and developer documentation at work, and I blog to help the folks who write to ask me questions, and that's about it.
I do enjoy this forum, and SQLServerCentral.com in general, a lot, though. My credentials as a writer and a software developer (and an online forum contributor -- I was a wizop on CompuServe before there *was* an internet) are more-or-less impeccable, but I've only come lately to the world of DBAs. I mostly come here to learn. I want to say "thank you" to everybody here.
>L<
May 16, 2012 at 9:55 am
Lynn Pettis (5/16/2012)
The problem I have seen is the lack of the Business Analyst and Database Analyst/Architect working on the project in this fashion, at least on the projects I have been involved in so far.
I think this is a common problem. Very few managers have the technical skill or aptitude to really visualize a complete solution top to bottom, but they see developers turn out miracles every day. They conclude that preliminary analysis is a waste of their time and a design on a cocktail napkin is all we need. It ends up wasting the developers' time because you know they'll be back inevitably at testing time with a raft of additional changes they'd forgotten to mention because they cut off the analysis period too early.
Sigerson
"No pressure, no diamonds." - Thomas Carlyle
May 16, 2012 at 10:04 am
I just use this division to try to organize my thoughts at times. Evidently my thoughts are not well organized even so, or Craig would be happier with my expression of them! I think I was mostly thinking out loud, trying to find a way to indicate happiness at being in this occupation for all its warts.
Like you, I come here to learn (although the occasional pontification is enjoyable, too). I hope you did not take offence at my words, as I simply didn't understand your division between - what were they? Abstractors and emulators? Homogenators and emulsifiers? Drat, I can't remember now!
Anyway, I'm a simple man, who works best with simple English. Which is not surprising, as I'm also a simple Englishman. And I do get the impression you are an accomplished author. Just keep your writings at a third grade level, and I'll be fine. 😀
May 16, 2012 at 10:08 am
Lynn Pettis (5/16/2012)
Revenant (5/16/2012)
Capt. Sigerson (5/16/2012)
It really forced me to think the entire design through before I wrote the first line of code. That seems to be something lost in today's Agile precept "one l;ine of code at a time, and a test after each change." (Yes, that does not apply to writing T-SQL or SSIS scripts...)
Before you can do Agile or Scrum type development, there still needs to be a period of time up front to develop the system requirements. [..] The problem I have seen is the lack of the Business Analyst and Database Analyst/Architect working on the project in this fashion, at least on the projects I have been involved in so far.
Forgive me if I've messed up the brackets and quotes above, but... Amen to all of this. FWIW I think the that good parts of Agile existed under other names that new folks either don't know or diss without understanding, speaking of old tools that are still useful. I used to teach a combination of RAD/JAD and AFAICS it still works fine for me. The JAD part gives you that BA + DBA/A part you're otherwise missing, and tempers the parts of RAD that otherwise can get a little silly.
Don't get me started on the parts of *any* of these methodologies that I *don't* like, though <s>.
What we always need to remember is that it's the practitioners, not the methodology *or* the patterns, that are going to make the critical difference between success or failure.
FWIW Grady Booch is considered one of the seminal OOP thinkers but, when I read his books, I end up thinking "yeah, Grady, that worked because *you* were the architect on the project. Not because the practice you're recommending is universally perfect or even do-able." He's a great architect and (I bet) a great leader.
May 16, 2012 at 10:16 am
What we always need to remember is that it's the practitioners, not the methodology *or* the patterns, that are going to make the critical difference between success or failure.
Very well put indeed.
I've discovered that, just as there are ideologues in politics, there are ideologues in methodologies as well. Sometimes us practical sorts are shouted down or out of the conversation, and expected to make an unwieldy methodology perform to some unreasonable standard.
What matters is what works, and the workers must be able to make it work.
Viewing 15 posts - 61 through 75 (of 94 total)
You must be logged in to reply to this topic. Login to reply