Re: OT: Life in engineerland
Peter, I have two points to make: 1. I haven't met you in person, although I would like that to happen. So, my original claim to mis-fortune still stands. 2. On the/a (?) more serious note, there is much more to engineering than writing code. Just like there is much more to producing cars than constructing the engine or assembling one. And this is where lies the problem, at least from my personal experience. Ask a software engineer to produce estimate. Based on their answer ask for commitment. Ask them to produce technical documentation. Ask them to actually write the design document for their piece of the system and review it against their peers before they write code... All of these activities are very often seen by the people who actually write code as redundant. If you ask them to please produce unit tests, they will smile and send you to foaas.com... I am not even going to think about what is happening when there is pressure and things need to be done in a haste... <-- This sentence, by the way, contains at least 3 big elements that should be questioned with the question mark of a size of a building. Boris On 2/11/2016 22:03, P.J. Alling wrote: I've done actual software engineering. It's not really necessary for the majority of programmers today. optimizing compilers and virtual machines have taken much of the necessary rigor out of precisely designing code for particular machines. I remember writing assembly language and that needed serious math. That needed to fit into very small amounts of memory. I wasn't that good at it being a math phoebe and all. I also remember having to design C code to do operations in the most efficient order, even when not directly accessing memory registers. Because the compiler couldn't be trusted to optimize correctly. C is my favorite programming language, it does exactly what you tell it to do, whether that's a good thing or not is debatable for some. I think I originally saw this in Byte magazine*, (paper), describing various, then current, programming languages, in layman's terms, "...a very fast sports car with no seat belts". *Which officially makes me ancient. On 2/11/2016 1:28 PM, Boris Liberman wrote: This is very fascinating. Indeed, you sounded as if you were compelled to do some optimization no matter what. As well, partial optimization may be considered as no optimization at all... Then whatever the engineer in my story did wasn't optimization by definition :-). I don't have my own definition of engineer. I am yet to work with proper software engineer... Since about two years ago I don't consider myself to be a software engineer. In fact, people who do software, when confronted with the idea of rigorous engineering (such as practiced by other technical disciplines), usually become very non-willing to communicate any further or erupt in some kind of an argument. Software is probably too soft to be engineered. /deep sigh/ Boris On 2/6/2016 21:04, Larry Colen wrote: P.J. Alling wrote: Engineer joke. An Engineer is a person who will spend two months to figure out how to do a 5 minute task he must preform every other week, in two minutes. (It's only funny to people who actually do the math). My definition of a natural born engineer is someone who will spend three hours figuring out how to do a 30 minute job in 20, once. On 2/6/2016 1:57 AM, Boris Liberman wrote: "I'm an engineer, I have to look for any opportunity to optimize. " <-- that's fundamentally wrong. The rest is fun reading. I might have phrased it that I'm compelled to look for any opportunity to optimize. In your story, the engineer didn't optimize the system, he nominally optimized one aspect of performance and in the process pessimized the system. Boris On 2/4/2016 0:27, Larry Colen wrote: I just posted this to my facebook page. I have a strong hunch that at least one or two people on this list will empathize with this. Life in engineer land. A few weeks ago, a friend of mine who worked in engineering in a previous life, got in touch with me. Another friend of hers, also an engineer, was about to get a second broadband connection and needed a network cable run from his phone box to his server room. Sometimes these installations are straightforward and take a few minutes, other times, not so much and it takes someone who knows what they are doing. So the first order of business was for me to head over there, scope out the place and see if I could help, or if it would be wise to refer the job to a friend of mine who owns a network cabling business, and actually knows what he's doing. The evening I was free, I headed over there with another friend who happens to be an engineer, on our way to something else. So, to set the stage. We need to run a 20m (or 60 foot) cable, from the outside wall of the condo, across the ceiling of the garage, and up two floors to the office. In effect, we are throwing fo
Re: OT: Life in engineerland
Ken, honestly, I have no idea. I never worked myself on anything that was directly related to hardware. I also know that things like FPGAs are also basically software, just produced under somewhat different conditions. Same goes about processors - the little I know seems to indicate that good part of it is basically code, again, expressed differently than the stuff I've been doing. Boris On 2/11/2016 23:17, Ken Waller wrote: Software is probably too soft to be engineered. /deep sigh/ So what about Hardware ? Kenneth Waller http://www.pentaxphotogallery.com/kennethwaller - Original Message - From: "Boris Liberman" Subject: Re: OT: Life in engineerland This is very fascinating. Indeed, you sounded as if you were compelled to do some optimization no matter what. As well, partial optimization may be considered as no optimization at all... Then whatever the engineer in my story did wasn't optimization by definition :-). I don't have my own definition of engineer. I am yet to work with proper software engineer... Since about two years ago I don't consider myself to be a software engineer. In fact, people who do software, when confronted with the idea of rigorous engineering (such as practiced by other technical disciplines), usually become very non-willing to communicate any further or erupt in some kind of an argument. Software is probably too soft to be engineered. /deep sigh/ Boris On 2/6/2016 21:04, Larry Colen wrote: P.J. Alling wrote: Engineer joke. An Engineer is a person who will spend two months to figure out how to do a 5 minute task he must preform every other week, in two minutes. (It's only funny to people who actually do the math). My definition of a natural born engineer is someone who will spend three hours figuring out how to do a 30 minute job in 20, once. On 2/6/2016 1:57 AM, Boris Liberman wrote: "I'm an engineer, I have to look for any opportunity to optimize. " <-- that's fundamentally wrong. The rest is fun reading. I might have phrased it that I'm compelled to look for any opportunity to optimize. In your story, the engineer didn't optimize the system, he nominally optimized one aspect of performance and in the process pessimized the system. Boris On 2/4/2016 0:27, Larry Colen wrote: I just posted this to my facebook page. I have a strong hunch that at least one or two people on this list will empathize with this. Life in engineer land. A few weeks ago, a friend of mine who worked in engineering in a previous life, got in touch with me. Another friend of hers, also an engineer, was about to get a second broadband connection and needed a network cable run from his phone box to his server room. Sometimes these installations are straightforward and take a few minutes, other times, not so much and it takes someone who knows what they are doing. So the first order of business was for me to head over there, scope out the place and see if I could help, or if it would be wise to refer the job to a friend of mine who owns a network cabling business, and actually knows what he's doing. The evening I was free, I headed over there with another friend who happens to be an engineer, on our way to something else. So, to set the stage. We need to run a 20m (or 60 foot) cable, from the outside wall of the condo, across the ceiling of the garage, and up two floors to the office. In effect, we are throwing four engineers at the job. In the real world, what would happen would be that a real business would send their installer out, with a box of cable, a fish line, and a drill, who would spend 10-20 minutes tracking down the existing wires, another half hour running the line, and 10-20 minutes terminating the line. But, this isn't the real world, this is engineerland. The first step is to find out where the cable starts, and where it ends, then to figure out if a new cable can be easily run. This process takes something like forty minutes. We determine that it can, indeed be done. But, I'm an engineer, I have to look for any opportunity to optimize. So, I ask the question, "while we're doing this, are there any other lines that it makes sense to run or upgrade?". Now, we start reverse engineering the existing network. Two hours later, we've decided to replace the cat 5 of the existing DSL line with cat 6, move the DSL modem from the downstairs office in the kitchen to the server room, and to upgrade the cat 5 lines from the server room to the wall plates in each of the kitchen office and the dining room. In short, it has taken us about two hours to change the scope of the job from running a single cable from the phone box to the server room, to running two cables, and to replace four cat 5 cables from the server room with an effective 1 gigabit bandwidth, to cat 6 cable with a theoretical 10 gigabit bandwid
Re: OT: Life in engineerland
Software is probably too soft to be engineered. /deep sigh/ So what about Hardware ? Kenneth Waller http://www.pentaxphotogallery.com/kennethwaller - Original Message - From: "Boris Liberman" Subject: Re: OT: Life in engineerland This is very fascinating. Indeed, you sounded as if you were compelled to do some optimization no matter what. As well, partial optimization may be considered as no optimization at all... Then whatever the engineer in my story did wasn't optimization by definition :-). I don't have my own definition of engineer. I am yet to work with proper software engineer... Since about two years ago I don't consider myself to be a software engineer. In fact, people who do software, when confronted with the idea of rigorous engineering (such as practiced by other technical disciplines), usually become very non-willing to communicate any further or erupt in some kind of an argument. Software is probably too soft to be engineered. /deep sigh/ Boris On 2/6/2016 21:04, Larry Colen wrote: P.J. Alling wrote: Engineer joke. An Engineer is a person who will spend two months to figure out how to do a 5 minute task he must preform every other week, in two minutes. (It's only funny to people who actually do the math). My definition of a natural born engineer is someone who will spend three hours figuring out how to do a 30 minute job in 20, once. On 2/6/2016 1:57 AM, Boris Liberman wrote: "I'm an engineer, I have to look for any opportunity to optimize. " <-- that's fundamentally wrong. The rest is fun reading. I might have phrased it that I'm compelled to look for any opportunity to optimize. In your story, the engineer didn't optimize the system, he nominally optimized one aspect of performance and in the process pessimized the system. Boris On 2/4/2016 0:27, Larry Colen wrote: I just posted this to my facebook page. I have a strong hunch that at least one or two people on this list will empathize with this. Life in engineer land. A few weeks ago, a friend of mine who worked in engineering in a previous life, got in touch with me. Another friend of hers, also an engineer, was about to get a second broadband connection and needed a network cable run from his phone box to his server room. Sometimes these installations are straightforward and take a few minutes, other times, not so much and it takes someone who knows what they are doing. So the first order of business was for me to head over there, scope out the place and see if I could help, or if it would be wise to refer the job to a friend of mine who owns a network cabling business, and actually knows what he's doing. The evening I was free, I headed over there with another friend who happens to be an engineer, on our way to something else. So, to set the stage. We need to run a 20m (or 60 foot) cable, from the outside wall of the condo, across the ceiling of the garage, and up two floors to the office. In effect, we are throwing four engineers at the job. In the real world, what would happen would be that a real business would send their installer out, with a box of cable, a fish line, and a drill, who would spend 10-20 minutes tracking down the existing wires, another half hour running the line, and 10-20 minutes terminating the line. But, this isn't the real world, this is engineerland. The first step is to find out where the cable starts, and where it ends, then to figure out if a new cable can be easily run. This process takes something like forty minutes. We determine that it can, indeed be done. But, I'm an engineer, I have to look for any opportunity to optimize. So, I ask the question, "while we're doing this, are there any other lines that it makes sense to run or upgrade?". Now, we start reverse engineering the existing network. Two hours later, we've decided to replace the cat 5 of the existing DSL line with cat 6, move the DSL modem from the downstairs office in the kitchen to the server room, and to upgrade the cat 5 lines from the server room to the wall plates in each of the kitchen office and the dining room. In short, it has taken us about two hours to change the scope of the job from running a single cable from the phone box to the server room, to running two cables, and to replace four cat 5 cables from the server room with an effective 1 gigabit bandwidth, to cat 6 cable with a theoretical 10 gigabit bandwidth. One of the most important things I've learned in my engineering career is to get a good set of job requirements before you start. There are few things more important than being able to know when you have actually finished the job. Yes, the requirements may change while you are working on things, but it's important to note (for billing purposes if nothing else) that they have indeed changed. The next step is for the customer to get a rough estim
Re: OT: Life in engineerland
I've done actual software engineering. It's not really necessary for the majority of programmers today. optimizing compilers and virtual machines have taken much of the necessary rigor out of precisely designing code for particular machines. I remember writing assembly language and that needed serious math. That needed to fit into very small amounts of memory. I wasn't that good at it being a math phoebe and all. I also remember having to design C code to do operations in the most efficient order, even when not directly accessing memory registers. Because the compiler couldn't be trusted to optimize correctly. C is my favorite programming language, it does exactly what you tell it to do, whether that's a good thing or not is debatable for some. I think I originally saw this in Byte magazine*, (paper), describing various, then current, programming languages, in layman's terms, "...a very fast sports car with no seat belts". *Which officially makes me ancient. On 2/11/2016 1:28 PM, Boris Liberman wrote: This is very fascinating. Indeed, you sounded as if you were compelled to do some optimization no matter what. As well, partial optimization may be considered as no optimization at all... Then whatever the engineer in my story did wasn't optimization by definition :-). I don't have my own definition of engineer. I am yet to work with proper software engineer... Since about two years ago I don't consider myself to be a software engineer. In fact, people who do software, when confronted with the idea of rigorous engineering (such as practiced by other technical disciplines), usually become very non-willing to communicate any further or erupt in some kind of an argument. Software is probably too soft to be engineered. /deep sigh/ Boris On 2/6/2016 21:04, Larry Colen wrote: P.J. Alling wrote: Engineer joke. An Engineer is a person who will spend two months to figure out how to do a 5 minute task he must preform every other week, in two minutes. (It's only funny to people who actually do the math). My definition of a natural born engineer is someone who will spend three hours figuring out how to do a 30 minute job in 20, once. On 2/6/2016 1:57 AM, Boris Liberman wrote: "I'm an engineer, I have to look for any opportunity to optimize. " <-- that's fundamentally wrong. The rest is fun reading. I might have phrased it that I'm compelled to look for any opportunity to optimize. In your story, the engineer didn't optimize the system, he nominally optimized one aspect of performance and in the process pessimized the system. Boris On 2/4/2016 0:27, Larry Colen wrote: I just posted this to my facebook page. I have a strong hunch that at least one or two people on this list will empathize with this. Life in engineer land. A few weeks ago, a friend of mine who worked in engineering in a previous life, got in touch with me. Another friend of hers, also an engineer, was about to get a second broadband connection and needed a network cable run from his phone box to his server room. Sometimes these installations are straightforward and take a few minutes, other times, not so much and it takes someone who knows what they are doing. So the first order of business was for me to head over there, scope out the place and see if I could help, or if it would be wise to refer the job to a friend of mine who owns a network cabling business, and actually knows what he's doing. The evening I was free, I headed over there with another friend who happens to be an engineer, on our way to something else. So, to set the stage. We need to run a 20m (or 60 foot) cable, from the outside wall of the condo, across the ceiling of the garage, and up two floors to the office. In effect, we are throwing four engineers at the job. In the real world, what would happen would be that a real business would send their installer out, with a box of cable, a fish line, and a drill, who would spend 10-20 minutes tracking down the existing wires, another half hour running the line, and 10-20 minutes terminating the line. But, this isn't the real world, this is engineerland. The first step is to find out where the cable starts, and where it ends, then to figure out if a new cable can be easily run. This process takes something like forty minutes. We determine that it can, indeed be done. But, I'm an engineer, I have to look for any opportunity to optimize. So, I ask the question, "while we're doing this, are there any other lines that it makes sense to run or upgrade?". Now, we start reverse engineering the existing network. Two hours later, we've decided to replace the cat 5 of the existing DSL line with cat 6, move the DSL modem from the downstairs office in the kitchen to the server room, and to upgrade the cat 5 lines from the server room to the wall plates in each of the kitchen office and the dining room. In short, it has taken us about two hours to change the scope of the job from ru
Re: OT: Life in engineerland
>Software is probably too soft to be engineered. Loved this! Forwarding to my elder son, a Computer&Electronics Engineer by definition and a software engineer by job. Bulent - http://patoloji.gen.tr http://celasun.wordpress.com/ http://www.flickr.com/photos/bc_the_path/ http://photo.net/photodb/user?user_id=2226822 http://www.pentaxphotogallery.com/artists/bulentcelasun 2016-02-11 20:28 GMT+02:00 Boris Liberman : > This is very fascinating. > > Indeed, you sounded as if you were compelled to do some optimization no > matter what. As well, partial optimization may be considered as no > optimization at all... Then whatever the engineer in my story did wasn't > optimization by definition :-). > > I don't have my own definition of engineer. I am yet to work with proper > software engineer... Since about two years ago I don't consider myself to be > a software engineer. In fact, people who do software, when confronted with > the idea of rigorous engineering (such as practiced by other technical > disciplines), usually become very non-willing to communicate any further or > erupt in some kind of an argument. > > Software is probably too soft to be engineered. /deep sigh/ > > Boris > > > On 2/6/2016 21:04, Larry Colen wrote: >> >> >> >> P.J. Alling wrote: >>> >>> Engineer joke. An Engineer is a person who will spend two months to >>> figure out how to do a 5 minute task he must preform every other week, >>> in two minutes. (It's only funny to people who actually do the math). >> >> >> My definition of a natural born engineer is someone who will spend three >> hours figuring out how to do a 30 minute job in 20, once. >> >> >>> >>> On 2/6/2016 1:57 AM, Boris Liberman wrote: "I'm an engineer, I have to look for any opportunity to optimize. " <-- that's fundamentally wrong. The rest is fun reading. >> >> >> I might have phrased it that I'm compelled to look for any opportunity to >> optimize. In your story, the engineer didn't optimize the system, he >> nominally optimized one aspect of performance and in the process pessimized >> the system. >> Boris On 2/4/2016 0:27, Larry Colen wrote: > > I just posted this to my facebook page. I have a strong hunch that at > least one or two people on this list will empathize with this. > > Life in engineer land. > > A few weeks ago, a friend of mine who worked in engineering in a > previous life, got in touch with me. Another friend of hers, also an > engineer, was about to get a second broadband connection and needed a > network cable run from his phone box to his server room. Sometimes > these installations are straightforward and take a few minutes, other > times, not so much and it takes someone who knows what they are > doing. So the first order of business was for me to head over there, > scope out the place and see if I could help, or if it would be wise > to refer the job to a friend of mine who owns a network cabling > business, and actually knows what he's doing. The evening I was free, > I headed over there with another friend who happens to be an > engineer, on our way to something else. > > So, to set the stage. We need to run a 20m (or 60 foot) cable, from > the outside wall of the condo, across the ceiling of the garage, and > up two floors to the office. In effect, we are throwing four > engineers at the job. In the real world, what would happen would be > that a real business would send their installer out, with a box of > cable, a fish line, and a drill, who would spend 10-20 minutes > tracking down the existing wires, another half hour running the line, > and 10-20 minutes terminating the line. > > But, this isn't the real world, this is engineerland. The first step > is to find out where the cable starts, and where it ends, then to > figure out if a new cable can be easily run. This process takes > something like forty minutes. We determine that it can, indeed be > done. But, I'm an engineer, I have to look for any opportunity to > optimize. So, I ask the question, "while we're doing this, are there > any other lines that it makes sense to run or upgrade?". > > Now, we start reverse engineering the existing network. Two hours > later, we've decided to replace the cat 5 of the existing DSL line > with cat 6, move the DSL modem from the downstairs office in the > kitchen to the server room, and to upgrade the cat 5 lines from the > server room to the wall plates in each of the kitchen office and the > dining room. > > In short, it has taken us about two hours to change the scope of the > job from running a single cable from the phone box to the server > room, to running two cables, and to replace four cat 5 cables from > the server room with an effec
Re: OT: Life in engineerland
This is very fascinating. Indeed, you sounded as if you were compelled to do some optimization no matter what. As well, partial optimization may be considered as no optimization at all... Then whatever the engineer in my story did wasn't optimization by definition :-). I don't have my own definition of engineer. I am yet to work with proper software engineer... Since about two years ago I don't consider myself to be a software engineer. In fact, people who do software, when confronted with the idea of rigorous engineering (such as practiced by other technical disciplines), usually become very non-willing to communicate any further or erupt in some kind of an argument. Software is probably too soft to be engineered. /deep sigh/ Boris On 2/6/2016 21:04, Larry Colen wrote: P.J. Alling wrote: Engineer joke. An Engineer is a person who will spend two months to figure out how to do a 5 minute task he must preform every other week, in two minutes. (It's only funny to people who actually do the math). My definition of a natural born engineer is someone who will spend three hours figuring out how to do a 30 minute job in 20, once. On 2/6/2016 1:57 AM, Boris Liberman wrote: "I'm an engineer, I have to look for any opportunity to optimize. " <-- that's fundamentally wrong. The rest is fun reading. I might have phrased it that I'm compelled to look for any opportunity to optimize. In your story, the engineer didn't optimize the system, he nominally optimized one aspect of performance and in the process pessimized the system. Boris On 2/4/2016 0:27, Larry Colen wrote: I just posted this to my facebook page. I have a strong hunch that at least one or two people on this list will empathize with this. Life in engineer land. A few weeks ago, a friend of mine who worked in engineering in a previous life, got in touch with me. Another friend of hers, also an engineer, was about to get a second broadband connection and needed a network cable run from his phone box to his server room. Sometimes these installations are straightforward and take a few minutes, other times, not so much and it takes someone who knows what they are doing. So the first order of business was for me to head over there, scope out the place and see if I could help, or if it would be wise to refer the job to a friend of mine who owns a network cabling business, and actually knows what he's doing. The evening I was free, I headed over there with another friend who happens to be an engineer, on our way to something else. So, to set the stage. We need to run a 20m (or 60 foot) cable, from the outside wall of the condo, across the ceiling of the garage, and up two floors to the office. In effect, we are throwing four engineers at the job. In the real world, what would happen would be that a real business would send their installer out, with a box of cable, a fish line, and a drill, who would spend 10-20 minutes tracking down the existing wires, another half hour running the line, and 10-20 minutes terminating the line. But, this isn't the real world, this is engineerland. The first step is to find out where the cable starts, and where it ends, then to figure out if a new cable can be easily run. This process takes something like forty minutes. We determine that it can, indeed be done. But, I'm an engineer, I have to look for any opportunity to optimize. So, I ask the question, "while we're doing this, are there any other lines that it makes sense to run or upgrade?". Now, we start reverse engineering the existing network. Two hours later, we've decided to replace the cat 5 of the existing DSL line with cat 6, move the DSL modem from the downstairs office in the kitchen to the server room, and to upgrade the cat 5 lines from the server room to the wall plates in each of the kitchen office and the dining room. In short, it has taken us about two hours to change the scope of the job from running a single cable from the phone box to the server room, to running two cables, and to replace four cat 5 cables from the server room with an effective 1 gigabit bandwidth, to cat 6 cable with a theoretical 10 gigabit bandwidth. One of the most important things I've learned in my engineering career is to get a good set of job requirements before you start. There are few things more important than being able to know when you have actually finished the job. Yes, the requirements may change while you are working on things, but it's important to note (for billing purposes if nothing else) that they have indeed changed. The next step is for the customer to get a rough estimate of the distances and send me a note, or spreadsheet, that says: 2 wires from point A to B, approximately 60 feet 2 wires from point B to C, approximately 10 feet 2 wires from point B to D, approximately 40 feet RJ 45 connectors at points B,C, and D. What I received was a PDF diagram with 15 different locations, color coded lines marking each of the dif
Re: OT: Life in engineerland
Ten percent of the job takes ninety percent of the time. The rest of the job takes the other ninety percent of the time. On 2/6/2016 3:34 PM, Ken Waller wrote: An Engineer is a person who will spend two months to figure out how to do a 5 minute task he must perform >every other week, in two minutes. I've experienced something along those lines in my years as an engineer in design & development work when working on issues months & years prior to production. I've also experienced the other side of that coin when I was a resident engineer at an automotive assembly plant. When an assembly issue comes up and you're producing XX vehicles per hour, the pressure is on to find a safe, timely & effective solution with the minimum loss of production. You don't have the luxury of time to kick around all the possible solutions. Kenneth Waller http://www.pentaxphotogallery.com/kennethwaller - Original Message - From: "P.J. Alling" Subject: Re: OT: Life in engineerland Engineer joke. An Engineer is a person who will spend two months to figure out how to do a 5 minute task he must preform every other week, in two minutes. (It's only funny to people who actually do the math). On 2/6/2016 1:57 AM, Boris Liberman wrote: "I'm an engineer, I have to look for any opportunity to optimize. " <-- that's fundamentally wrong. The rest is fun reading. Boris On 2/4/2016 0:27, Larry Colen wrote: I just posted this to my facebook page. I have a strong hunch that at least one or two people on this list will empathize with this. Life in engineer land. A few weeks ago, a friend of mine who worked in engineering in a previous life, got in touch with me. Another friend of hers, also an engineer, was about to get a second broadband connection and needed a network cable run from his phone box to his server room. Sometimes these installations are straightforward and take a few minutes, other times, not so much and it takes someone who knows what they are doing. So the first order of business was for me to head over there, scope out the place and see if I could help, or if it would be wise to refer the job to a friend of mine who owns a network cabling business, and actually knows what he's doing. The evening I was free, I headed over there with another friend who happens to be an engineer, on our way to something else. So, to set the stage. We need to run a 20m (or 60 foot) cable, from the outside wall of the condo, across the ceiling of the garage, and up two floors to the office. In effect, we are throwing four engineers at the job. In the real world, what would happen would be that a real business would send their installer out, with a box of cable, a fish line, and a drill, who would spend 10-20 minutes tracking down the existing wires, another half hour running the line, and 10-20 minutes terminating the line. But, this isn't the real world, this is engineerland. The first step is to find out where the cable starts, and where it ends, then to figure out if a new cable can be easily run. This process takes something like forty minutes. We determine that it can, indeed be done. But, I'm an engineer, I have to look for any opportunity to optimize. So, I ask the question, "while we're doing this, are there any other lines that it makes sense to run or upgrade?". Now, we start reverse engineering the existing network. Two hours later, we've decided to replace the cat 5 of the existing DSL line with cat 6, move the DSL modem from the downstairs office in the kitchen to the server room, and to upgrade the cat 5 lines from the server room to the wall plates in each of the kitchen office and the dining room. In short, it has taken us about two hours to change the scope of the job from running a single cable from the phone box to the server room, to running two cables, and to replace four cat 5 cables from the server room with an effective 1 gigabit bandwidth, to cat 6 cable with a theoretical 10 gigabit bandwidth. One of the most important things I've learned in my engineering career is to get a good set of job requirements before you start. There are few things more important than being able to know when you have actually finished the job. Yes, the requirements may change while you are working on things, but it's important to note (for billing purposes if nothing else) that they have indeed changed. The next step is for the customer to get a rough estimate of the distances and send me a note, or spreadsheet, that says: 2 wires from point A to B, approximately 60 feet 2 wires from point B to C, approximately 10 feet 2 wires from point B to D, approximately 40 feet RJ 45 connectors at points B,C, and D. What I received was a PDF diagram with 15 different locations, color coded lines marking each of the different cables, notes on the distances between each location, and notes as to w
Re: OT: Life in engineerland
On Sun, Feb 7, 2016, at 06:04 AM, Larry Colen wrote: > > > P.J. Alling wrote: > > Engineer joke. An Engineer is a person who will spend two months to > > figure out how to do a 5 minute task he must preform every other week, > > in two minutes. (It's only funny to people who actually do the math). > > My definition of a natural born engineer is someone who will spend three > hours figuring out how to do a 30 minute job in 20, once. I don't see any problem in that logic... (spoken as a former (i.e. retired) engineer) ;-)> Cheers Brian ++ Brian Walters Western Sydney Australia http://lyons-ryan.org/southernlight/ > -- -- -- -- http://www.fastmail.com - IMAP accessible web-mail -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
However, we now have fundamental (as in building foundation that is called "fundament" in Russian) problem in our system. Boris, I never said all engineers are smart ! ;+) Maybe he was seeking job security ! Kenneth Waller http://www.pentaxphotogallery.com/kennethwaller - Original Message - From: "Boris Liberman" Subject: Re: OT: Life in engineerland Ken, I am also an engineer. At least officially. Although if you were to argue that "software engineering" has almost nothing with "true engineering", you wouldn't encounter any opposition from me. I can give you an absolutely immediate example. The system that I am working on right now has certain infrastructure layer. The engineer responsible for that layer has decided that it has to be optimized for performance. And optimized it was. Now, later after the most bulk of the code was written, it became apparent that this code was better optimized for flexibility, extensibility and maintainability. None of these concerned the said engineer. The performance optimization was very low hanging fruit and it was a great opportunity to do fun stuff... However, we now have fundamental (as in building foundation that is called "fundament" in Russian) problem in our system. It is hard to reason about network cables for me, but I was particularly alarmed by your saying "I HAVE to look for ANY opportunity to optimize"... I think of optimization as of extremely sharp razor. And the person who wields that razor has to be extremely careful when they actually put the razor to use. Nothing personal or nothing disrespectful intended here. As well, we can take it off the list, as this is very much off topic. Boris On 2/6/2016 12:29, Bruce Walker wrote: On Sat, Feb 6, 2016 at 2:21 AM, Ken Waller wrote: "I'm an engineer, I have to look for any opportunity to optimize. " <-- that's fundamentally wrong. How's that Boris? I'm also an engineer & while I might not act on those opportunities, I need to at least be aware of them. Agreed, 110%. A very large part of my career was built on optimizing. Cost, size, weight, reliability, appearance, ... something. Especially cost. The fewer lines of code the better, since bugs increase exponentially with complexity. The fewer the components the better since that generally drops the cost and increases MTTF. -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
An Engineer is a person who will spend two months to figure out how to do a 5 minute task he must perform >every other week, in two minutes. I've experienced something along those lines in my years as an engineer in design & development work when working on issues months & years prior to production. I've also experienced the other side of that coin when I was a resident engineer at an automotive assembly plant. When an assembly issue comes up and you're producing XX vehicles per hour, the pressure is on to find a safe, timely & effective solution with the minimum loss of production. You don't have the luxury of time to kick around all the possible solutions. Kenneth Waller http://www.pentaxphotogallery.com/kennethwaller - Original Message - From: "P.J. Alling" Subject: Re: OT: Life in engineerland Engineer joke. An Engineer is a person who will spend two months to figure out how to do a 5 minute task he must preform every other week, in two minutes. (It's only funny to people who actually do the math). On 2/6/2016 1:57 AM, Boris Liberman wrote: "I'm an engineer, I have to look for any opportunity to optimize. " <-- that's fundamentally wrong. The rest is fun reading. Boris On 2/4/2016 0:27, Larry Colen wrote: I just posted this to my facebook page. I have a strong hunch that at least one or two people on this list will empathize with this. Life in engineer land. A few weeks ago, a friend of mine who worked in engineering in a previous life, got in touch with me. Another friend of hers, also an engineer, was about to get a second broadband connection and needed a network cable run from his phone box to his server room. Sometimes these installations are straightforward and take a few minutes, other times, not so much and it takes someone who knows what they are doing. So the first order of business was for me to head over there, scope out the place and see if I could help, or if it would be wise to refer the job to a friend of mine who owns a network cabling business, and actually knows what he's doing. The evening I was free, I headed over there with another friend who happens to be an engineer, on our way to something else. So, to set the stage. We need to run a 20m (or 60 foot) cable, from the outside wall of the condo, across the ceiling of the garage, and up two floors to the office. In effect, we are throwing four engineers at the job. In the real world, what would happen would be that a real business would send their installer out, with a box of cable, a fish line, and a drill, who would spend 10-20 minutes tracking down the existing wires, another half hour running the line, and 10-20 minutes terminating the line. But, this isn't the real world, this is engineerland. The first step is to find out where the cable starts, and where it ends, then to figure out if a new cable can be easily run. This process takes something like forty minutes. We determine that it can, indeed be done. But, I'm an engineer, I have to look for any opportunity to optimize. So, I ask the question, "while we're doing this, are there any other lines that it makes sense to run or upgrade?". Now, we start reverse engineering the existing network. Two hours later, we've decided to replace the cat 5 of the existing DSL line with cat 6, move the DSL modem from the downstairs office in the kitchen to the server room, and to upgrade the cat 5 lines from the server room to the wall plates in each of the kitchen office and the dining room. In short, it has taken us about two hours to change the scope of the job from running a single cable from the phone box to the server room, to running two cables, and to replace four cat 5 cables from the server room with an effective 1 gigabit bandwidth, to cat 6 cable with a theoretical 10 gigabit bandwidth. One of the most important things I've learned in my engineering career is to get a good set of job requirements before you start. There are few things more important than being able to know when you have actually finished the job. Yes, the requirements may change while you are working on things, but it's important to note (for billing purposes if nothing else) that they have indeed changed. The next step is for the customer to get a rough estimate of the distances and send me a note, or spreadsheet, that says: 2 wires from point A to B, approximately 60 feet 2 wires from point B to C, approximately 10 feet 2 wires from point B to D, approximately 40 feet RJ 45 connectors at points B,C, and D. What I received was a PDF diagram with 15 different locations, color coded lines marking each of the different cables, notes on the distances between each location, and notes as to which distances are to be the installed cat 6, and which are to be patch cables. At this point we
Re: OT: Life in engineerland
P.J. Alling wrote: Engineer joke. An Engineer is a person who will spend two months to figure out how to do a 5 minute task he must preform every other week, in two minutes. (It's only funny to people who actually do the math). My definition of a natural born engineer is someone who will spend three hours figuring out how to do a 30 minute job in 20, once. On 2/6/2016 1:57 AM, Boris Liberman wrote: "I'm an engineer, I have to look for any opportunity to optimize. " <-- that's fundamentally wrong. The rest is fun reading. I might have phrased it that I'm compelled to look for any opportunity to optimize. In your story, the engineer didn't optimize the system, he nominally optimized one aspect of performance and in the process pessimized the system. Boris On 2/4/2016 0:27, Larry Colen wrote: I just posted this to my facebook page. I have a strong hunch that at least one or two people on this list will empathize with this. Life in engineer land. A few weeks ago, a friend of mine who worked in engineering in a previous life, got in touch with me. Another friend of hers, also an engineer, was about to get a second broadband connection and needed a network cable run from his phone box to his server room. Sometimes these installations are straightforward and take a few minutes, other times, not so much and it takes someone who knows what they are doing. So the first order of business was for me to head over there, scope out the place and see if I could help, or if it would be wise to refer the job to a friend of mine who owns a network cabling business, and actually knows what he's doing. The evening I was free, I headed over there with another friend who happens to be an engineer, on our way to something else. So, to set the stage. We need to run a 20m (or 60 foot) cable, from the outside wall of the condo, across the ceiling of the garage, and up two floors to the office. In effect, we are throwing four engineers at the job. In the real world, what would happen would be that a real business would send their installer out, with a box of cable, a fish line, and a drill, who would spend 10-20 minutes tracking down the existing wires, another half hour running the line, and 10-20 minutes terminating the line. But, this isn't the real world, this is engineerland. The first step is to find out where the cable starts, and where it ends, then to figure out if a new cable can be easily run. This process takes something like forty minutes. We determine that it can, indeed be done. But, I'm an engineer, I have to look for any opportunity to optimize. So, I ask the question, "while we're doing this, are there any other lines that it makes sense to run or upgrade?". Now, we start reverse engineering the existing network. Two hours later, we've decided to replace the cat 5 of the existing DSL line with cat 6, move the DSL modem from the downstairs office in the kitchen to the server room, and to upgrade the cat 5 lines from the server room to the wall plates in each of the kitchen office and the dining room. In short, it has taken us about two hours to change the scope of the job from running a single cable from the phone box to the server room, to running two cables, and to replace four cat 5 cables from the server room with an effective 1 gigabit bandwidth, to cat 6 cable with a theoretical 10 gigabit bandwidth. One of the most important things I've learned in my engineering career is to get a good set of job requirements before you start. There are few things more important than being able to know when you have actually finished the job. Yes, the requirements may change while you are working on things, but it's important to note (for billing purposes if nothing else) that they have indeed changed. The next step is for the customer to get a rough estimate of the distances and send me a note, or spreadsheet, that says: 2 wires from point A to B, approximately 60 feet 2 wires from point B to C, approximately 10 feet 2 wires from point B to D, approximately 40 feet RJ 45 connectors at points B,C, and D. What I received was a PDF diagram with 15 different locations, color coded lines marking each of the different cables, notes on the distances between each location, and notes as to which distances are to be the installed cat 6, and which are to be patch cables. At this point we start discussing the drawing over email and SMS, considering such vital details as color of the wire, how to mark the wire and jacks, running pull string for future enhancements (already implicit in the plan), where to get the various items, scheduling and just about every other detail except for the color of the electrons in the cable. At this point we have ordered the specially colored jacks, scheduled the work for Monday, and have spent probably close to 15 engineering hours on a task that would take a technician approximately an hour to do. On the other hand, the customer will be able to surf the web from his
Re: OT: Life in engineerland
John wrote: You can keep optimizing forever and never get the job done. But that would be suboptimal. On 2/6/2016 5:49 AM, Boris Liberman wrote: Ken, I am also an engineer. At least officially. Although if you were to argue that "software engineering" has almost nothing with "true engineering", you wouldn't encounter any opposition from me. I can give you an absolutely immediate example. The system that I am working on right now has certain infrastructure layer. The engineer responsible for that layer has decided that it has to be optimized for performance. And optimized it was. Now, later after the most bulk of the code was written, it became apparent that this code was better optimized for flexibility, extensibility and maintainability. None of these concerned the said engineer. The performance optimization was very low hanging fruit and it was a great opportunity to do fun stuff... However, we now have fundamental (as in building foundation that is called "fundament" in Russian) problem in our system. It is hard to reason about network cables for me, but I was particularly alarmed by your saying "I HAVE to look for ANY opportunity to optimize"... I think of optimization as of extremely sharp razor. And the person who wields that razor has to be extremely careful when they actually put the razor to use. Nothing personal or nothing disrespectful intended here. As well, we can take it off the list, as this is very much off topic. Boris On 2/6/2016 12:29, Bruce Walker wrote: On Sat, Feb 6, 2016 at 2:21 AM, Ken Waller wrote: "I'm an engineer, I have to look for any opportunity to optimize. " <-- that's fundamentally wrong. How's that Boris? I'm also an engineer & while I might not act on those opportunities, I need to at least be aware of them. Agreed, 110%. A very large part of my career was built on optimizing. Cost, size, weight, reliability, appearance, ... something. Especially cost. The fewer lines of code the better, since bugs increase exponentially with complexity. The fewer the components the better since that generally drops the cost and increases MTTF. -- Larry Colen l...@red4est.com (postbox on min4est) http://red4est.com/lrc -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
You can keep optimizing forever and never get the job done. On 2/6/2016 5:49 AM, Boris Liberman wrote: Ken, I am also an engineer. At least officially. Although if you were to argue that "software engineering" has almost nothing with "true engineering", you wouldn't encounter any opposition from me. I can give you an absolutely immediate example. The system that I am working on right now has certain infrastructure layer. The engineer responsible for that layer has decided that it has to be optimized for performance. And optimized it was. Now, later after the most bulk of the code was written, it became apparent that this code was better optimized for flexibility, extensibility and maintainability. None of these concerned the said engineer. The performance optimization was very low hanging fruit and it was a great opportunity to do fun stuff... However, we now have fundamental (as in building foundation that is called "fundament" in Russian) problem in our system. It is hard to reason about network cables for me, but I was particularly alarmed by your saying "I HAVE to look for ANY opportunity to optimize"... I think of optimization as of extremely sharp razor. And the person who wields that razor has to be extremely careful when they actually put the razor to use. Nothing personal or nothing disrespectful intended here. As well, we can take it off the list, as this is very much off topic. Boris On 2/6/2016 12:29, Bruce Walker wrote: On Sat, Feb 6, 2016 at 2:21 AM, Ken Waller wrote: "I'm an engineer, I have to look for any opportunity to optimize. " <-- that's fundamentally wrong. How's that Boris? I'm also an engineer & while I might not act on those opportunities, I need to at least be aware of them. Agreed, 110%. A very large part of my career was built on optimizing. Cost, size, weight, reliability, appearance, ... something. Especially cost. The fewer lines of code the better, since bugs increase exponentially with complexity. The fewer the components the better since that generally drops the cost and increases MTTF. -- Science - Questions we may never find answers for. Religion - Answers we must never question. -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
Mark! Sent with AquaMail for Android http://www.aqua-mail.com On 6 February 2016 17:26:34 Bruce Walker wrote: On Sat, Feb 6, 2016 at 5:49 AM, Boris Liberman wrote: As well, we can take it off the list, as this is very much off topic. "that's fundamentally wrong." :) -- -bmw -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions. -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
Engineer joke. An Engineer is a person who will spend two months to figure out how to do a 5 minute task he must preform every other week, in two minutes. (It's only funny to people who actually do the math). On 2/6/2016 1:57 AM, Boris Liberman wrote: "I'm an engineer, I have to look for any opportunity to optimize. " <-- that's fundamentally wrong. The rest is fun reading. Boris On 2/4/2016 0:27, Larry Colen wrote: I just posted this to my facebook page. I have a strong hunch that at least one or two people on this list will empathize with this. Life in engineer land. A few weeks ago, a friend of mine who worked in engineering in a previous life, got in touch with me. Another friend of hers, also an engineer, was about to get a second broadband connection and needed a network cable run from his phone box to his server room. Sometimes these installations are straightforward and take a few minutes, other times, not so much and it takes someone who knows what they are doing. So the first order of business was for me to head over there, scope out the place and see if I could help, or if it would be wise to refer the job to a friend of mine who owns a network cabling business, and actually knows what he's doing. The evening I was free, I headed over there with another friend who happens to be an engineer, on our way to something else. So, to set the stage. We need to run a 20m (or 60 foot) cable, from the outside wall of the condo, across the ceiling of the garage, and up two floors to the office. In effect, we are throwing four engineers at the job. In the real world, what would happen would be that a real business would send their installer out, with a box of cable, a fish line, and a drill, who would spend 10-20 minutes tracking down the existing wires, another half hour running the line, and 10-20 minutes terminating the line. But, this isn't the real world, this is engineerland. The first step is to find out where the cable starts, and where it ends, then to figure out if a new cable can be easily run. This process takes something like forty minutes. We determine that it can, indeed be done. But, I'm an engineer, I have to look for any opportunity to optimize. So, I ask the question, "while we're doing this, are there any other lines that it makes sense to run or upgrade?". Now, we start reverse engineering the existing network. Two hours later, we've decided to replace the cat 5 of the existing DSL line with cat 6, move the DSL modem from the downstairs office in the kitchen to the server room, and to upgrade the cat 5 lines from the server room to the wall plates in each of the kitchen office and the dining room. In short, it has taken us about two hours to change the scope of the job from running a single cable from the phone box to the server room, to running two cables, and to replace four cat 5 cables from the server room with an effective 1 gigabit bandwidth, to cat 6 cable with a theoretical 10 gigabit bandwidth. One of the most important things I've learned in my engineering career is to get a good set of job requirements before you start. There are few things more important than being able to know when you have actually finished the job. Yes, the requirements may change while you are working on things, but it's important to note (for billing purposes if nothing else) that they have indeed changed. The next step is for the customer to get a rough estimate of the distances and send me a note, or spreadsheet, that says: 2 wires from point A to B, approximately 60 feet 2 wires from point B to C, approximately 10 feet 2 wires from point B to D, approximately 40 feet RJ 45 connectors at points B,C, and D. What I received was a PDF diagram with 15 different locations, color coded lines marking each of the different cables, notes on the distances between each location, and notes as to which distances are to be the installed cat 6, and which are to be patch cables. At this point we start discussing the drawing over email and SMS, considering such vital details as color of the wire, how to mark the wire and jacks, running pull string for future enhancements (already implicit in the plan), where to get the various items, scheduling and just about every other detail except for the color of the electrons in the cable. At this point we have ordered the specially colored jacks, scheduled the work for Monday, and have spent probably close to 15 engineering hours on a task that would take a technician approximately an hour to do. On the other hand, the customer will be able to surf the web from his kitchen on a home network that is more finely engineered than the one in an NSA supercomputer lab. -- I don't want to achieve immortality through my work; I want to achieve immortality through not dying. -- Woody Allen -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net
Re: OT: Life in engineerland
On Sat, Feb 6, 2016 at 5:49 AM, Boris Liberman wrote: > > As well, we can take it off the list, as this is very much off topic. "that's fundamentally wrong." :) -- -bmw -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
On 6/2/16, Bob W-PDML, discombobulated, unleashed: >Premature optimisation Yeah I suffer from that too -- Cheers, Cotty ___/\__Broadcast, Corporate, || (O) |Web Video Production -- _ -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
The first rule of optimisation is: don't do it. The second rule is: if you must do it, don't do it yet. Premature optimisation is the root of all evil. Both of these maxims are attributable to Michael Jackson, I believe. https://en.m.wikipedia.org/wiki/Michael_A._Jackson B > On 6 Feb 2016, at 10:53, Boris Liberman wrote: > > Ken, I am also an engineer. At least officially. Although if you were to > argue that "software engineering" has almost nothing with "true engineering", > you wouldn't encounter any opposition from me. > > I can give you an absolutely immediate example. The system that I am working > on right now has certain infrastructure layer. The engineer responsible for > that layer has decided that it has to be optimized for performance. And > optimized it was. Now, later after the most bulk of the code was written, it > became apparent that this code was better optimized for flexibility, > extensibility and maintainability. None of these concerned the said engineer. > The performance optimization was very low hanging fruit and it was a great > opportunity to do fun stuff... However, we now have fundamental (as in > building foundation that is called "fundament" in Russian) problem in our > system. > > It is hard to reason about network cables for me, but I was particularly > alarmed by your saying "I HAVE to look for ANY opportunity to optimize"... I > think of optimization as of extremely sharp razor. And the person who wields > that razor has to be extremely careful when they actually put the razor to > use. > > Nothing personal or nothing disrespectful intended here. As well, we can take > it off the list, as this is very much off topic. > > Boris > >> On 2/6/2016 12:29, Bruce Walker wrote: >> On Sat, Feb 6, 2016 at 2:21 AM, Ken Waller wrote: "I'm an engineer, I have to look for any opportunity to optimize. " <-- that's fundamentally wrong. >>> >>> How's that Boris? >>> I'm also an engineer & while I might not act on those opportunities, I need >>> to at least be aware of them. >> Agreed, 110%. >> >> A very large part of my career was built on optimizing. Cost, size, >> weight, reliability, appearance, ... something. Especially cost. The >> fewer lines of code the better, since bugs increase exponentially with >> complexity. The fewer the components the better since that generally >> drops the cost and increases MTTF. >> > > > -- > PDML Pentax-Discuss Mail List > PDML@pdml.net > http://pdml.net/mailman/listinfo/pdml_pdml.net > to UNSUBSCRIBE from the PDML, please visit the link directly above and follow > the directions. -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
Ken, I am also an engineer. At least officially. Although if you were to argue that "software engineering" has almost nothing with "true engineering", you wouldn't encounter any opposition from me. I can give you an absolutely immediate example. The system that I am working on right now has certain infrastructure layer. The engineer responsible for that layer has decided that it has to be optimized for performance. And optimized it was. Now, later after the most bulk of the code was written, it became apparent that this code was better optimized for flexibility, extensibility and maintainability. None of these concerned the said engineer. The performance optimization was very low hanging fruit and it was a great opportunity to do fun stuff... However, we now have fundamental (as in building foundation that is called "fundament" in Russian) problem in our system. It is hard to reason about network cables for me, but I was particularly alarmed by your saying "I HAVE to look for ANY opportunity to optimize"... I think of optimization as of extremely sharp razor. And the person who wields that razor has to be extremely careful when they actually put the razor to use. Nothing personal or nothing disrespectful intended here. As well, we can take it off the list, as this is very much off topic. Boris On 2/6/2016 12:29, Bruce Walker wrote: On Sat, Feb 6, 2016 at 2:21 AM, Ken Waller wrote: "I'm an engineer, I have to look for any opportunity to optimize. " <-- that's fundamentally wrong. How's that Boris? I'm also an engineer & while I might not act on those opportunities, I need to at least be aware of them. Agreed, 110%. A very large part of my career was built on optimizing. Cost, size, weight, reliability, appearance, ... something. Especially cost. The fewer lines of code the better, since bugs increase exponentially with complexity. The fewer the components the better since that generally drops the cost and increases MTTF. -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
On Sat, Feb 6, 2016 at 2:21 AM, Ken Waller wrote: >> "I'm an engineer, I have to look for any opportunity to optimize. " <-- >> that's fundamentally wrong. > > > How's that Boris? > I'm also an engineer & while I might not act on those opportunities, I need > to at least be aware of them. Agreed, 110%. A very large part of my career was built on optimizing. Cost, size, weight, reliability, appearance, ... something. Especially cost. The fewer lines of code the better, since bugs increase exponentially with complexity. The fewer the components the better since that generally drops the cost and increases MTTF. -- -bmw -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
"I'm an engineer, I have to look for any opportunity to optimize. " <-- that's fundamentally wrong. How's that Boris? I'm also an engineer & while I might not act on those opportunities, I need to at least be aware of them. Kenneth Waller http://www.pentaxphotogallery.com/kennethwaller - Original Message - From: "Boris Liberman" Subject: Re: OT: Life in engineerland "I'm an engineer, I have to look for any opportunity to optimize. " <-- that's fundamentally wrong. The rest is fun reading. Boris On 2/4/2016 0:27, Larry Colen wrote: I just posted this to my facebook page. I have a strong hunch that at least one or two people on this list will empathize with this. Life in engineer land. A few weeks ago, a friend of mine who worked in engineering in a previous life, got in touch with me. Another friend of hers, also an engineer, was about to get a second broadband connection and needed a network cable run from his phone box to his server room. Sometimes these installations are straightforward and take a few minutes, other times, not so much and it takes someone who knows what they are doing. So the first order of business was for me to head over there, scope out the place and see if I could help, or if it would be wise to refer the job to a friend of mine who owns a network cabling business, and actually knows what he's doing. The evening I was free, I headed over there with another friend who happens to be an engineer, on our way to something else. So, to set the stage. We need to run a 20m (or 60 foot) cable, from the outside wall of the condo, across the ceiling of the garage, and up two floors to the office. In effect, we are throwing four engineers at the job. In the real world, what would happen would be that a real business would send their installer out, with a box of cable, a fish line, and a drill, who would spend 10-20 minutes tracking down the existing wires, another half hour running the line, and 10-20 minutes terminating the line. But, this isn't the real world, this is engineerland. The first step is to find out where the cable starts, and where it ends, then to figure out if a new cable can be easily run. This process takes something like forty minutes. We determine that it can, indeed be done. But, I'm an engineer, I have to look for any opportunity to optimize. So, I ask the question, "while we're doing this, are there any other lines that it makes sense to run or upgrade?". Now, we start reverse engineering the existing network. Two hours later, we've decided to replace the cat 5 of the existing DSL line with cat 6, move the DSL modem from the downstairs office in the kitchen to the server room, and to upgrade the cat 5 lines from the server room to the wall plates in each of the kitchen office and the dining room. In short, it has taken us about two hours to change the scope of the job from running a single cable from the phone box to the server room, to running two cables, and to replace four cat 5 cables from the server room with an effective 1 gigabit bandwidth, to cat 6 cable with a theoretical 10 gigabit bandwidth. One of the most important things I've learned in my engineering career is to get a good set of job requirements before you start. There are few things more important than being able to know when you have actually finished the job. Yes, the requirements may change while you are working on things, but it's important to note (for billing purposes if nothing else) that they have indeed changed. The next step is for the customer to get a rough estimate of the distances and send me a note, or spreadsheet, that says: 2 wires from point A to B, approximately 60 feet 2 wires from point B to C, approximately 10 feet 2 wires from point B to D, approximately 40 feet RJ 45 connectors at points B,C, and D. What I received was a PDF diagram with 15 different locations, color coded lines marking each of the different cables, notes on the distances between each location, and notes as to which distances are to be the installed cat 6, and which are to be patch cables. At this point we start discussing the drawing over email and SMS, considering such vital details as color of the wire, how to mark the wire and jacks, running pull string for future enhancements (already implicit in the plan), where to get the various items, scheduling and just about every other detail except for the color of the electrons in the cable. At this point we have ordered the specially colored jacks, scheduled the work for Monday, and have spent probably close to 15 engineering hours on a task that would take a technician approximately an hour to do. On the other hand, the customer will be able to surf the web from his kitchen on a home network that is more finely engineered than the o
Re: OT: Life in engineerland
"I'm an engineer, I have to look for any opportunity to optimize. " <-- that's fundamentally wrong. The rest is fun reading. Boris On 2/4/2016 0:27, Larry Colen wrote: I just posted this to my facebook page. I have a strong hunch that at least one or two people on this list will empathize with this. Life in engineer land. A few weeks ago, a friend of mine who worked in engineering in a previous life, got in touch with me. Another friend of hers, also an engineer, was about to get a second broadband connection and needed a network cable run from his phone box to his server room. Sometimes these installations are straightforward and take a few minutes, other times, not so much and it takes someone who knows what they are doing. So the first order of business was for me to head over there, scope out the place and see if I could help, or if it would be wise to refer the job to a friend of mine who owns a network cabling business, and actually knows what he's doing. The evening I was free, I headed over there with another friend who happens to be an engineer, on our way to something else. So, to set the stage. We need to run a 20m (or 60 foot) cable, from the outside wall of the condo, across the ceiling of the garage, and up two floors to the office. In effect, we are throwing four engineers at the job. In the real world, what would happen would be that a real business would send their installer out, with a box of cable, a fish line, and a drill, who would spend 10-20 minutes tracking down the existing wires, another half hour running the line, and 10-20 minutes terminating the line. But, this isn't the real world, this is engineerland. The first step is to find out where the cable starts, and where it ends, then to figure out if a new cable can be easily run. This process takes something like forty minutes. We determine that it can, indeed be done. But, I'm an engineer, I have to look for any opportunity to optimize. So, I ask the question, "while we're doing this, are there any other lines that it makes sense to run or upgrade?". Now, we start reverse engineering the existing network. Two hours later, we've decided to replace the cat 5 of the existing DSL line with cat 6, move the DSL modem from the downstairs office in the kitchen to the server room, and to upgrade the cat 5 lines from the server room to the wall plates in each of the kitchen office and the dining room. In short, it has taken us about two hours to change the scope of the job from running a single cable from the phone box to the server room, to running two cables, and to replace four cat 5 cables from the server room with an effective 1 gigabit bandwidth, to cat 6 cable with a theoretical 10 gigabit bandwidth. One of the most important things I've learned in my engineering career is to get a good set of job requirements before you start. There are few things more important than being able to know when you have actually finished the job. Yes, the requirements may change while you are working on things, but it's important to note (for billing purposes if nothing else) that they have indeed changed. The next step is for the customer to get a rough estimate of the distances and send me a note, or spreadsheet, that says: 2 wires from point A to B, approximately 60 feet 2 wires from point B to C, approximately 10 feet 2 wires from point B to D, approximately 40 feet RJ 45 connectors at points B,C, and D. What I received was a PDF diagram with 15 different locations, color coded lines marking each of the different cables, notes on the distances between each location, and notes as to which distances are to be the installed cat 6, and which are to be patch cables. At this point we start discussing the drawing over email and SMS, considering such vital details as color of the wire, how to mark the wire and jacks, running pull string for future enhancements (already implicit in the plan), where to get the various items, scheduling and just about every other detail except for the color of the electrons in the cable. At this point we have ordered the specially colored jacks, scheduled the work for Monday, and have spent probably close to 15 engineering hours on a task that would take a technician approximately an hour to do. On the other hand, the customer will be able to surf the web from his kitchen on a home network that is more finely engineered than the one in an NSA supercomputer lab. -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
John wrote: I think he was making a humorous comment. He might have thought so too. But that doesn't mean it wasn't considered in the design. On 2/4/2016 12:47 AM, Larry Colen wrote: P.J. Alling wrote: Requires special installation tools, most individuals probably don't own. I suppose you could always rent them... On 2/3/2016 9:12 PM, Philip Northeast wrote: What's wrong with an optical fibre backbone? Apart from the tools, and training, which I lack, there were good engineering reasons for not spending the money on optical fiber right now. The CAT6 will already outperform the bandwidth of the feed from the FTTN by an order of magnitude or so. All of the servers are already on the same rack, but they don't have fiber inputs anyways. The Cisco SG200-18 18-port gigabit switch for the rack should be arriving sometime between now and Monday. The data rate to and from the atomic clock and ultraprecise GPS units, really isn't even high enough to even fully utilize the existing CAT5 anyways. We will, however, be leaving pull strings in place so that when fiber to the home is available it will be a simple matter to pull it to the rack. -- Larry Colen l...@red4est.com (postbox on min4est) http://red4est.com/lrc -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
On Feb 3, 2016, at 6:12 PM, Philip Northeast wrote: > What's wrong with an optical fibre backbone? With the added pull strings in the cable runs, it's an easy enhancement. -- "Not only is it not right, it's not even wrong!" >From Wolfgang Pauli, perpetrator of the Pauli Exclusion Principle -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
On Feb 3, 2016, at 3:24 PM, Bob W-PDML wrote: > Get wifi. It's available as a layer atop what Larry described.. Just add a wifi router to a hub at the end of one of those copper runs. -- "Not only is it not right, it's not even wrong!" >From Wolfgang Pauli, perpetrator of the Pauli Exclusion Principle -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
On Feb 3, 2016, at 2:57 PM, Larry Colen wrote: > Darren Addy wrote: >> The problem was throwing more than one engineer in there. Once you >> have more than one engineer, you are no longer engineering a solution >> you are playing a game of "Who's the Alpha Engineer". This phenomenon >> is not limited to engineering, of course. > > Nope, the problem is artistic pride. Everyone involved wants to make sure > that this is the very best home network that it is possible to make. First, > we need to define "best". Some guys at DAVID Systems in Sunnyvale had their own home-brew phone switches at home, using step-by-step switching gear salvaged from updating central offices. Others used engineering prototype instances of the DAVID Information Manager product to do the digital version of same, including supporting T-3 spans. -- "Not only is it not right, it's not even wrong!" >From Wolfgang Pauli, perpetrator of the Pauli Exclusion Principle -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
I think he was making a humorous comment. On 2/4/2016 12:47 AM, Larry Colen wrote: P.J. Alling wrote: Requires special installation tools, most individuals probably don't own. I suppose you could always rent them... On 2/3/2016 9:12 PM, Philip Northeast wrote: What's wrong with an optical fibre backbone? Apart from the tools, and training, which I lack, there were good engineering reasons for not spending the money on optical fiber right now. The CAT6 will already outperform the bandwidth of the feed from the FTTN by an order of magnitude or so. All of the servers are already on the same rack, but they don't have fiber inputs anyways. The Cisco SG200-18 18-port gigabit switch for the rack should be arriving sometime between now and Monday. The data rate to and from the atomic clock and ultraprecise GPS units, really isn't even high enough to even fully utilize the existing CAT5 anyways. We will, however, be leaving pull strings in place so that when fiber to the home is available it will be a simple matter to pull it to the rack. -- Science - Questions we may never find answers for. Religion - Answers we must never question. -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
You *NEVER* want to be that installer. Trust me! On 2/3/2016 10:01 PM, Philip Northeast wrote: Hire an installer to implement the engineering plans? Philip Northeast www.aviewfinderdarkly.com.au On 4/02/2016 1:26 PM, P.J. Alling wrote: Requires special installation tools, most individuals probably don't own. I suppose you could always rent them... On 2/3/2016 9:12 PM, Philip Northeast wrote: What's wrong with an optical fibre backbone? Philip Northeast www.aviewfinderdarkly.com.au On 4/02/2016 9:27 AM, Larry Colen wrote: I just posted this to my facebook page. I have a strong hunch that at least one or two people on this list will empathize with this. Life in engineer land. A few weeks ago, a friend of mine who worked in engineering in a previous life, got in touch with me. Another friend of hers, also an engineer, was about to get a second broadband connection and needed a network cable run from his phone box to his server room. Sometimes these installations are straightforward and take a few minutes, other times, not so much and it takes someone who knows what they are doing. So the first order of business was for me to head over there, scope out the place and see if I could help, or if it would be wise to refer the job to a friend of mine who owns a network cabling business, and actually knows what he's doing. The evening I was free, I headed over there with another friend who happens to be an engineer, on our way to something else. So, to set the stage. We need to run a 20m (or 60 foot) cable, from the outside wall of the condo, across the ceiling of the garage, and up two floors to the office. In effect, we are throwing four engineers at the job. In the real world, what would happen would be that a real business would send their installer out, with a box of cable, a fish line, and a drill, who would spend 10-20 minutes tracking down the existing wires, another half hour running the line, and 10-20 minutes terminating the line. But, this isn't the real world, this is engineerland. The first step is to find out where the cable starts, and where it ends, then to figure out if a new cable can be easily run. This process takes something like forty minutes. We determine that it can, indeed be done. But, I'm an engineer, I have to look for any opportunity to optimize. So, I ask the question, "while we're doing this, are there any other lines that it makes sense to run or upgrade?". Now, we start reverse engineering the existing network. Two hours later, we've decided to replace the cat 5 of the existing DSL line with cat 6, move the DSL modem from the downstairs office in the kitchen to the server room, and to upgrade the cat 5 lines from the server room to the wall plates in each of the kitchen office and the dining room. In short, it has taken us about two hours to change the scope of the job from running a single cable from the phone box to the server room, to running two cables, and to replace four cat 5 cables from the server room with an effective 1 gigabit bandwidth, to cat 6 cable with a theoretical 10 gigabit bandwidth. One of the most important things I've learned in my engineering career is to get a good set of job requirements before you start. There are few things more important than being able to know when you have actually finished the job. Yes, the requirements may change while you are working on things, but it's important to note (for billing purposes if nothing else) that they have indeed changed. The next step is for the customer to get a rough estimate of the distances and send me a note, or spreadsheet, that says: 2 wires from point A to B, approximately 60 feet 2 wires from point B to C, approximately 10 feet 2 wires from point B to D, approximately 40 feet RJ 45 connectors at points B,C, and D. What I received was a PDF diagram with 15 different locations, color coded lines marking each of the different cables, notes on the distances between each location, and notes as to which distances are to be the installed cat 6, and which are to be patch cables. At this point we start discussing the drawing over email and SMS, considering such vital details as color of the wire, how to mark the wire and jacks, running pull string for future enhancements (already implicit in the plan), where to get the various items, scheduling and just about every other detail except for the color of the electrons in the cable. At this point we have ordered the specially colored jacks, scheduled the work for Monday, and have spent probably close to 15 engineering hours on a task that would take a technician approximately an hour to do. On the other hand, the customer will be able to surf the web from his kitchen on a home network that is more finely engineered than the one in an NSA supercomputer lab. -- Science - Questions we may never find answers for. Religion - Answers we must never question. -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman
Re: OT: Life in engineerland
Probably a question best addressed to your chiropractor. B > On 4 Feb 2016, at 02:13, Philip Northeast wrote: > > What's wrong with an optical fibre backbone? > > Philip Northeast > > www.aviewfinderdarkly.com.au > >> -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
P.J. Alling wrote: Requires special installation tools, most individuals probably don't own. I suppose you could always rent them... On 2/3/2016 9:12 PM, Philip Northeast wrote: What's wrong with an optical fibre backbone? Apart from the tools, and training, which I lack, there were good engineering reasons for not spending the money on optical fiber right now. The CAT6 will already outperform the bandwidth of the feed from the FTTN by an order of magnitude or so. All of the servers are already on the same rack, but they don't have fiber inputs anyways. The Cisco SG200-18 18-port gigabit switch for the rack should be arriving sometime between now and Monday. The data rate to and from the atomic clock and ultraprecise GPS units, really isn't even high enough to even fully utilize the existing CAT5 anyways. We will, however, be leaving pull strings in place so that when fiber to the home is available it will be a simple matter to pull it to the rack. -- Larry Colen l...@red4est.com (postbox on min4est) http://red4est.com/lrc -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
Hire an installer to implement the engineering plans? Philip Northeast www.aviewfinderdarkly.com.au On 4/02/2016 1:26 PM, P.J. Alling wrote: Requires special installation tools, most individuals probably don't own. I suppose you could always rent them... On 2/3/2016 9:12 PM, Philip Northeast wrote: What's wrong with an optical fibre backbone? Philip Northeast www.aviewfinderdarkly.com.au On 4/02/2016 9:27 AM, Larry Colen wrote: I just posted this to my facebook page. I have a strong hunch that at least one or two people on this list will empathize with this. Life in engineer land. A few weeks ago, a friend of mine who worked in engineering in a previous life, got in touch with me. Another friend of hers, also an engineer, was about to get a second broadband connection and needed a network cable run from his phone box to his server room. Sometimes these installations are straightforward and take a few minutes, other times, not so much and it takes someone who knows what they are doing. So the first order of business was for me to head over there, scope out the place and see if I could help, or if it would be wise to refer the job to a friend of mine who owns a network cabling business, and actually knows what he's doing. The evening I was free, I headed over there with another friend who happens to be an engineer, on our way to something else. So, to set the stage. We need to run a 20m (or 60 foot) cable, from the outside wall of the condo, across the ceiling of the garage, and up two floors to the office. In effect, we are throwing four engineers at the job. In the real world, what would happen would be that a real business would send their installer out, with a box of cable, a fish line, and a drill, who would spend 10-20 minutes tracking down the existing wires, another half hour running the line, and 10-20 minutes terminating the line. But, this isn't the real world, this is engineerland. The first step is to find out where the cable starts, and where it ends, then to figure out if a new cable can be easily run. This process takes something like forty minutes. We determine that it can, indeed be done. But, I'm an engineer, I have to look for any opportunity to optimize. So, I ask the question, "while we're doing this, are there any other lines that it makes sense to run or upgrade?". Now, we start reverse engineering the existing network. Two hours later, we've decided to replace the cat 5 of the existing DSL line with cat 6, move the DSL modem from the downstairs office in the kitchen to the server room, and to upgrade the cat 5 lines from the server room to the wall plates in each of the kitchen office and the dining room. In short, it has taken us about two hours to change the scope of the job from running a single cable from the phone box to the server room, to running two cables, and to replace four cat 5 cables from the server room with an effective 1 gigabit bandwidth, to cat 6 cable with a theoretical 10 gigabit bandwidth. One of the most important things I've learned in my engineering career is to get a good set of job requirements before you start. There are few things more important than being able to know when you have actually finished the job. Yes, the requirements may change while you are working on things, but it's important to note (for billing purposes if nothing else) that they have indeed changed. The next step is for the customer to get a rough estimate of the distances and send me a note, or spreadsheet, that says: 2 wires from point A to B, approximately 60 feet 2 wires from point B to C, approximately 10 feet 2 wires from point B to D, approximately 40 feet RJ 45 connectors at points B,C, and D. What I received was a PDF diagram with 15 different locations, color coded lines marking each of the different cables, notes on the distances between each location, and notes as to which distances are to be the installed cat 6, and which are to be patch cables. At this point we start discussing the drawing over email and SMS, considering such vital details as color of the wire, how to mark the wire and jacks, running pull string for future enhancements (already implicit in the plan), where to get the various items, scheduling and just about every other detail except for the color of the electrons in the cable. At this point we have ordered the specially colored jacks, scheduled the work for Monday, and have spent probably close to 15 engineering hours on a task that would take a technician approximately an hour to do. On the other hand, the customer will be able to surf the web from his kitchen on a home network that is more finely engineered than the one in an NSA supercomputer lab. -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
Requires special installation tools, most individuals probably don't own. I suppose you could always rent them... On 2/3/2016 9:12 PM, Philip Northeast wrote: What's wrong with an optical fibre backbone? Philip Northeast www.aviewfinderdarkly.com.au On 4/02/2016 9:27 AM, Larry Colen wrote: I just posted this to my facebook page. I have a strong hunch that at least one or two people on this list will empathize with this. Life in engineer land. A few weeks ago, a friend of mine who worked in engineering in a previous life, got in touch with me. Another friend of hers, also an engineer, was about to get a second broadband connection and needed a network cable run from his phone box to his server room. Sometimes these installations are straightforward and take a few minutes, other times, not so much and it takes someone who knows what they are doing. So the first order of business was for me to head over there, scope out the place and see if I could help, or if it would be wise to refer the job to a friend of mine who owns a network cabling business, and actually knows what he's doing. The evening I was free, I headed over there with another friend who happens to be an engineer, on our way to something else. So, to set the stage. We need to run a 20m (or 60 foot) cable, from the outside wall of the condo, across the ceiling of the garage, and up two floors to the office. In effect, we are throwing four engineers at the job. In the real world, what would happen would be that a real business would send their installer out, with a box of cable, a fish line, and a drill, who would spend 10-20 minutes tracking down the existing wires, another half hour running the line, and 10-20 minutes terminating the line. But, this isn't the real world, this is engineerland. The first step is to find out where the cable starts, and where it ends, then to figure out if a new cable can be easily run. This process takes something like forty minutes. We determine that it can, indeed be done. But, I'm an engineer, I have to look for any opportunity to optimize. So, I ask the question, "while we're doing this, are there any other lines that it makes sense to run or upgrade?". Now, we start reverse engineering the existing network. Two hours later, we've decided to replace the cat 5 of the existing DSL line with cat 6, move the DSL modem from the downstairs office in the kitchen to the server room, and to upgrade the cat 5 lines from the server room to the wall plates in each of the kitchen office and the dining room. In short, it has taken us about two hours to change the scope of the job from running a single cable from the phone box to the server room, to running two cables, and to replace four cat 5 cables from the server room with an effective 1 gigabit bandwidth, to cat 6 cable with a theoretical 10 gigabit bandwidth. One of the most important things I've learned in my engineering career is to get a good set of job requirements before you start. There are few things more important than being able to know when you have actually finished the job. Yes, the requirements may change while you are working on things, but it's important to note (for billing purposes if nothing else) that they have indeed changed. The next step is for the customer to get a rough estimate of the distances and send me a note, or spreadsheet, that says: 2 wires from point A to B, approximately 60 feet 2 wires from point B to C, approximately 10 feet 2 wires from point B to D, approximately 40 feet RJ 45 connectors at points B,C, and D. What I received was a PDF diagram with 15 different locations, color coded lines marking each of the different cables, notes on the distances between each location, and notes as to which distances are to be the installed cat 6, and which are to be patch cables. At this point we start discussing the drawing over email and SMS, considering such vital details as color of the wire, how to mark the wire and jacks, running pull string for future enhancements (already implicit in the plan), where to get the various items, scheduling and just about every other detail except for the color of the electrons in the cable. At this point we have ordered the specially colored jacks, scheduled the work for Monday, and have spent probably close to 15 engineering hours on a task that would take a technician approximately an hour to do. On the other hand, the customer will be able to surf the web from his kitchen on a home network that is more finely engineered than the one in an NSA supercomputer lab. -- I don't want to achieve immortality through my work; I want to achieve immortality through not dying. -- Woody Allen -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
Alright, was there wine involved? After the determination to upgrade /everything/ was there whiskey or tequila in copious quantities involved. These are important questions in the the estimation of costs. On 2/3/2016 5:27 PM, Larry Colen wrote: I just posted this to my facebook page. I have a strong hunch that at least one or two people on this list will empathize with this. Life in engineer land. A few weeks ago, a friend of mine who worked in engineering in a previous life, got in touch with me. Another friend of hers, also an engineer, was about to get a second broadband connection and needed a network cable run from his phone box to his server room. Sometimes these installations are straightforward and take a few minutes, other times, not so much and it takes someone who knows what they are doing. So the first order of business was for me to head over there, scope out the place and see if I could help, or if it would be wise to refer the job to a friend of mine who owns a network cabling business, and actually knows what he's doing. The evening I was free, I headed over there with another friend who happens to be an engineer, on our way to something else. So, to set the stage. We need to run a 20m (or 60 foot) cable, from the outside wall of the condo, across the ceiling of the garage, and up two floors to the office. In effect, we are throwing four engineers at the job. In the real world, what would happen would be that a real business would send their installer out, with a box of cable, a fish line, and a drill, who would spend 10-20 minutes tracking down the existing wires, another half hour running the line, and 10-20 minutes terminating the line. But, this isn't the real world, this is engineerland. The first step is to find out where the cable starts, and where it ends, then to figure out if a new cable can be easily run. This process takes something like forty minutes. We determine that it can, indeed be done. But, I'm an engineer, I have to look for any opportunity to optimize. So, I ask the question, "while we're doing this, are there any other lines that it makes sense to run or upgrade?". Now, we start reverse engineering the existing network. Two hours later, we've decided to replace the cat 5 of the existing DSL line with cat 6, move the DSL modem from the downstairs office in the kitchen to the server room, and to upgrade the cat 5 lines from the server room to the wall plates in each of the kitchen office and the dining room. In short, it has taken us about two hours to change the scope of the job from running a single cable from the phone box to the server room, to running two cables, and to replace four cat 5 cables from the server room with an effective 1 gigabit bandwidth, to cat 6 cable with a theoretical 10 gigabit bandwidth. One of the most important things I've learned in my engineering career is to get a good set of job requirements before you start. There are few things more important than being able to know when you have actually finished the job. Yes, the requirements may change while you are working on things, but it's important to note (for billing purposes if nothing else) that they have indeed changed. The next step is for the customer to get a rough estimate of the distances and send me a note, or spreadsheet, that says: 2 wires from point A to B, approximately 60 feet 2 wires from point B to C, approximately 10 feet 2 wires from point B to D, approximately 40 feet RJ 45 connectors at points B,C, and D. What I received was a PDF diagram with 15 different locations, color coded lines marking each of the different cables, notes on the distances between each location, and notes as to which distances are to be the installed cat 6, and which are to be patch cables. At this point we start discussing the drawing over email and SMS, considering such vital details as color of the wire, how to mark the wire and jacks, running pull string for future enhancements (already implicit in the plan), where to get the various items, scheduling and just about every other detail except for the color of the electrons in the cable. At this point we have ordered the specially colored jacks, scheduled the work for Monday, and have spent probably close to 15 engineering hours on a task that would take a technician approximately an hour to do. On the other hand, the customer will be able to surf the web from his kitchen on a home network that is more finely engineered than the one in an NSA supercomputer lab. -- I don't want to achieve immortality through my work; I want to achieve immortality through not dying. -- Woody Allen -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
What's wrong with an optical fibre backbone? Philip Northeast www.aviewfinderdarkly.com.au On 4/02/2016 9:27 AM, Larry Colen wrote: I just posted this to my facebook page. I have a strong hunch that at least one or two people on this list will empathize with this. Life in engineer land. A few weeks ago, a friend of mine who worked in engineering in a previous life, got in touch with me. Another friend of hers, also an engineer, was about to get a second broadband connection and needed a network cable run from his phone box to his server room. Sometimes these installations are straightforward and take a few minutes, other times, not so much and it takes someone who knows what they are doing. So the first order of business was for me to head over there, scope out the place and see if I could help, or if it would be wise to refer the job to a friend of mine who owns a network cabling business, and actually knows what he's doing. The evening I was free, I headed over there with another friend who happens to be an engineer, on our way to something else. So, to set the stage. We need to run a 20m (or 60 foot) cable, from the outside wall of the condo, across the ceiling of the garage, and up two floors to the office. In effect, we are throwing four engineers at the job. In the real world, what would happen would be that a real business would send their installer out, with a box of cable, a fish line, and a drill, who would spend 10-20 minutes tracking down the existing wires, another half hour running the line, and 10-20 minutes terminating the line. But, this isn't the real world, this is engineerland. The first step is to find out where the cable starts, and where it ends, then to figure out if a new cable can be easily run. This process takes something like forty minutes. We determine that it can, indeed be done. But, I'm an engineer, I have to look for any opportunity to optimize. So, I ask the question, "while we're doing this, are there any other lines that it makes sense to run or upgrade?". Now, we start reverse engineering the existing network. Two hours later, we've decided to replace the cat 5 of the existing DSL line with cat 6, move the DSL modem from the downstairs office in the kitchen to the server room, and to upgrade the cat 5 lines from the server room to the wall plates in each of the kitchen office and the dining room. In short, it has taken us about two hours to change the scope of the job from running a single cable from the phone box to the server room, to running two cables, and to replace four cat 5 cables from the server room with an effective 1 gigabit bandwidth, to cat 6 cable with a theoretical 10 gigabit bandwidth. One of the most important things I've learned in my engineering career is to get a good set of job requirements before you start. There are few things more important than being able to know when you have actually finished the job. Yes, the requirements may change while you are working on things, but it's important to note (for billing purposes if nothing else) that they have indeed changed. The next step is for the customer to get a rough estimate of the distances and send me a note, or spreadsheet, that says: 2 wires from point A to B, approximately 60 feet 2 wires from point B to C, approximately 10 feet 2 wires from point B to D, approximately 40 feet RJ 45 connectors at points B,C, and D. What I received was a PDF diagram with 15 different locations, color coded lines marking each of the different cables, notes on the distances between each location, and notes as to which distances are to be the installed cat 6, and which are to be patch cables. At this point we start discussing the drawing over email and SMS, considering such vital details as color of the wire, how to mark the wire and jacks, running pull string for future enhancements (already implicit in the plan), where to get the various items, scheduling and just about every other detail except for the color of the electrons in the cable. At this point we have ordered the specially colored jacks, scheduled the work for Monday, and have spent probably close to 15 engineering hours on a task that would take a technician approximately an hour to do. On the other hand, the customer will be able to surf the web from his kitchen on a home network that is more finely engineered than the one in an NSA supercomputer lab. -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
On 3/2/16, Bob W-PDML, discombobulated, unleashed: >Get wifi. Or a life ;-) -- Cheers, Cotty ___/\__Broadcast, Corporate, || (O) |Web Video Production -- _ -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
Get wifi. > On 3 Feb 2016, at 22:28, Larry Colen wrote: > > I just posted this to my facebook page. I have a strong hunch that at least > one or two people on this list will empathize with this. > > Life in engineer land. > > A few weeks ago, a friend of mine who worked in engineering in a previous > life, got in touch with me. Another friend of hers, also an engineer, was > about to get a second broadband connection and needed a network cable run > from his phone box to his server room. Sometimes these installations are > straightforward and take a few minutes, other times, not so much and it takes > someone who knows what they are doing. So the first order of business was for > me to head over there, scope out the place and see if I could help, or if it > would be wise to refer the job to a friend of mine who owns a network cabling > business, and actually knows what he's doing. The evening I was free, I > headed over there with another friend who happens to be an engineer, on our > way to something else. > > So, to set the stage. We need to run a 20m (or 60 foot) cable, from the > outside wall of the condo, across the ceiling of the garage, and up two > floors to the office. In effect, we are throwing four engineers at the job. > In the real world, what would happen would be that a real business would send > their installer out, with a box of cable, a fish line, and a drill, who would > spend 10-20 minutes tracking down the existing wires, another half hour > running the line, and 10-20 minutes terminating the line. > > But, this isn't the real world, this is engineerland. The first step is to > find out where the cable starts, and where it ends, then to figure out if a > new cable can be easily run. This process takes something like forty > minutes. We determine that it can, indeed be done. But, I'm an engineer, I > have to look for any opportunity to optimize. So, I ask the question, "while > we're doing this, are there any other lines that it makes sense to run or > upgrade?". > > Now, we start reverse engineering the existing network. Two hours later, > we've decided to replace the cat 5 of the existing DSL line with cat 6, move > the DSL modem from the downstairs office in the kitchen to the server room, > and to upgrade the cat 5 lines from the server room to the wall plates in > each of the kitchen office and the dining room. > > In short, it has taken us about two hours to change the scope of the job from > running a single cable from the phone box to the server room, to running two > cables, and to replace four cat 5 cables from the server room with an > effective 1 gigabit bandwidth, to cat 6 cable with a theoretical 10 gigabit > bandwidth. > > One of the most important things I've learned in my engineering career is to > get a good set of job requirements before you start. There are few things > more important than being able to know when you have actually finished the > job. Yes, the requirements may change while you are working on things, but > it's important to note (for billing purposes if nothing else) that they have > indeed changed. > > The next step is for the customer to get a rough estimate of the distances > and send me a note, or spreadsheet, that says: > 2 wires from point A to B, approximately 60 feet > 2 wires from point B to C, approximately 10 feet > 2 wires from point B to D, approximately 40 feet > > RJ 45 connectors at points B,C, and D. > > What I received was a PDF diagram with 15 different locations, color coded > lines marking each of the different cables, notes on the distances between > each location, and notes as to which distances are to be the installed cat 6, > and which are to be patch cables. > > At this point we start discussing the drawing over email and SMS, considering > such vital details as color of the wire, how to mark the wire and jacks, > running pull string for future enhancements (already implicit in the plan), > where to get the various items, scheduling and just about every other detail > except for the color of the electrons in the cable. > > At this point we have ordered the specially colored jacks, scheduled the work > for Monday, and have spent probably close to 15 engineering hours on a task > that would take a technician approximately an hour to do. > > On the other hand, the customer will be able to surf the web from his kitchen > on a home network that is more finely engineered than the one in an NSA > supercomputer lab. > -- > Larry Colen l...@red4est.com (postbox on min4est) http://red4est.com/lrc > > > -- > PDML Pentax-Discuss Mail List > PDML@pdml.net > http://pdml.net/mailman/listinfo/pdml_pdml.net > to UNSUBSCRIBE from the PDML, please visit the link directly above and follow > the directions. -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above
Re: OT: Life in engineerland
Funny! That's exactly what I just said except you are putting a positive spin on it. Is it not possible for a single engineer to have artistic pride in their work and want to make sure it could be best? The problem remains that with more than one engineer definitions need to be *agreed upon*. See also: Committee-driven solutions. :) On Wed, Feb 3, 2016 at 4:57 PM, Larry Colen wrote: > > > Darren Addy wrote: >> >> The problem was throwing more than one engineer in there. Once you >> have more than one engineer, you are no longer engineering a solution >> you are playing a game of "Who's the Alpha Engineer". This phenomenon >> is not limited to engineering, of course. > > > Nope, the problem is artistic pride. Everyone involved wants to make sure > that this is the very best home network that it is possible to make. First, > we need to define "best". > > > -- > Larry Colen l...@red4est.com (postbox on min4est) http://red4est.com/lrc > > > -- > PDML Pentax-Discuss Mail List > PDML@pdml.net > http://pdml.net/mailman/listinfo/pdml_pdml.net > to UNSUBSCRIBE from the PDML, please visit the link directly above and > follow the directions. -- “The Earth is Art, The Photographer is only a Witness ” ― Yann Arthus-Bertrand, Earth from Above -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
Darren Addy wrote: The problem was throwing more than one engineer in there. Once you have more than one engineer, you are no longer engineering a solution you are playing a game of "Who's the Alpha Engineer". This phenomenon is not limited to engineering, of course. Nope, the problem is artistic pride. Everyone involved wants to make sure that this is the very best home network that it is possible to make. First, we need to define "best". -- Larry Colen l...@red4est.com (postbox on min4est) http://red4est.com/lrc -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
Re: OT: Life in engineerland
The problem was throwing more than one engineer in there. Once you have more than one engineer, you are no longer engineering a solution you are playing a game of "Who's the Alpha Engineer". This phenomenon is not limited to engineering, of course. On Wed, Feb 3, 2016 at 4:27 PM, Larry Colen wrote: > I just posted this to my facebook page. I have a strong hunch that at least > one or two people on this list will empathize with this. > > Life in engineer land. > > A few weeks ago, a friend of mine who worked in engineering in a previous > life, got in touch with me. Another friend of hers, also an engineer, was > about to get a second broadband connection and needed a network cable run > from his phone box to his server room. Sometimes these installations are > straightforward and take a few minutes, other times, not so much and it > takes someone who knows what they are doing. So the first order of business > was for me to head over there, scope out the place and see if I could help, > or if it would be wise to refer the job to a friend of mine who owns a > network cabling business, and actually knows what he's doing. The evening I > was free, I headed over there with another friend who happens to be an > engineer, on our way to something else. > > So, to set the stage. We need to run a 20m (or 60 foot) cable, from the > outside wall of the condo, across the ceiling of the garage, and up two > floors to the office. In effect, we are throwing four engineers at the job. > In the real world, what would happen would be that a real business would > send their installer out, with a box of cable, a fish line, and a drill, who > would spend 10-20 minutes tracking down the existing wires, another half > hour running the line, and 10-20 minutes terminating the line. > > But, this isn't the real world, this is engineerland. The first step is to > find out where the cable starts, and where it ends, then to figure out if a > new cable can be easily run. This process takes something like forty > minutes. We determine that it can, indeed be done. But, I'm an engineer, I > have to look for any opportunity to optimize. So, I ask the question, "while > we're doing this, are there any other lines that it makes sense to run or > upgrade?". > > Now, we start reverse engineering the existing network. Two hours later, > we've decided to replace the cat 5 of the existing DSL line with cat 6, move > the DSL modem from the downstairs office in the kitchen to the server room, > and to upgrade the cat 5 lines from the server room to the wall plates in > each of the kitchen office and the dining room. > > In short, it has taken us about two hours to change the scope of the job > from running a single cable from the phone box to the server room, to > running two cables, and to replace four cat 5 cables from the server room > with an effective 1 gigabit bandwidth, to cat 6 cable with a theoretical 10 > gigabit bandwidth. > > One of the most important things I've learned in my engineering career is to > get a good set of job requirements before you start. There are few things > more important than being able to know when you have actually finished the > job. Yes, the requirements may change while you are working on things, but > it's important to note (for billing purposes if nothing else) that they have > indeed changed. > > The next step is for the customer to get a rough estimate of the distances > and send me a note, or spreadsheet, that says: > 2 wires from point A to B, approximately 60 feet > 2 wires from point B to C, approximately 10 feet > 2 wires from point B to D, approximately 40 feet > > RJ 45 connectors at points B,C, and D. > > What I received was a PDF diagram with 15 different locations, color coded > lines marking each of the different cables, notes on the distances between > each location, and notes as to which distances are to be the installed cat > 6, and which are to be patch cables. > > At this point we start discussing the drawing over email and SMS, > considering such vital details as color of the wire, how to mark the wire > and jacks, running pull string for future enhancements (already implicit in > the plan), where to get the various items, scheduling and just about every > other detail except for the color of the electrons in the cable. > > At this point we have ordered the specially colored jacks, scheduled the > work for Monday, and have spent probably close to 15 engineering hours on a > task that would take a technician approximately an hour to do. > > On the other hand, the customer will be able to surf the web from his > kitchen on a home network that is more finely engineered than the one in an > NSA supercomputer lab. > -- > Larry Colen l...@red4est.com (postbox on min4est) http://red4est.com/lrc > > > -- > PDML Pentax-Discuss Mail List > PDML@pdml.net > http://pdml.net/mailman/listinfo/pdml_pdml.net > to UNSUBSCRIBE from the PDML, please visit the link directly above and > follow the d
OT: Life in engineerland
I just posted this to my facebook page. I have a strong hunch that at least one or two people on this list will empathize with this. Life in engineer land. A few weeks ago, a friend of mine who worked in engineering in a previous life, got in touch with me. Another friend of hers, also an engineer, was about to get a second broadband connection and needed a network cable run from his phone box to his server room. Sometimes these installations are straightforward and take a few minutes, other times, not so much and it takes someone who knows what they are doing. So the first order of business was for me to head over there, scope out the place and see if I could help, or if it would be wise to refer the job to a friend of mine who owns a network cabling business, and actually knows what he's doing. The evening I was free, I headed over there with another friend who happens to be an engineer, on our way to something else. So, to set the stage. We need to run a 20m (or 60 foot) cable, from the outside wall of the condo, across the ceiling of the garage, and up two floors to the office. In effect, we are throwing four engineers at the job. In the real world, what would happen would be that a real business would send their installer out, with a box of cable, a fish line, and a drill, who would spend 10-20 minutes tracking down the existing wires, another half hour running the line, and 10-20 minutes terminating the line. But, this isn't the real world, this is engineerland. The first step is to find out where the cable starts, and where it ends, then to figure out if a new cable can be easily run. This process takes something like forty minutes. We determine that it can, indeed be done. But, I'm an engineer, I have to look for any opportunity to optimize. So, I ask the question, "while we're doing this, are there any other lines that it makes sense to run or upgrade?". Now, we start reverse engineering the existing network. Two hours later, we've decided to replace the cat 5 of the existing DSL line with cat 6, move the DSL modem from the downstairs office in the kitchen to the server room, and to upgrade the cat 5 lines from the server room to the wall plates in each of the kitchen office and the dining room. In short, it has taken us about two hours to change the scope of the job from running a single cable from the phone box to the server room, to running two cables, and to replace four cat 5 cables from the server room with an effective 1 gigabit bandwidth, to cat 6 cable with a theoretical 10 gigabit bandwidth. One of the most important things I've learned in my engineering career is to get a good set of job requirements before you start. There are few things more important than being able to know when you have actually finished the job. Yes, the requirements may change while you are working on things, but it's important to note (for billing purposes if nothing else) that they have indeed changed. The next step is for the customer to get a rough estimate of the distances and send me a note, or spreadsheet, that says: 2 wires from point A to B, approximately 60 feet 2 wires from point B to C, approximately 10 feet 2 wires from point B to D, approximately 40 feet RJ 45 connectors at points B,C, and D. What I received was a PDF diagram with 15 different locations, color coded lines marking each of the different cables, notes on the distances between each location, and notes as to which distances are to be the installed cat 6, and which are to be patch cables. At this point we start discussing the drawing over email and SMS, considering such vital details as color of the wire, how to mark the wire and jacks, running pull string for future enhancements (already implicit in the plan), where to get the various items, scheduling and just about every other detail except for the color of the electrons in the cable. At this point we have ordered the specially colored jacks, scheduled the work for Monday, and have spent probably close to 15 engineering hours on a task that would take a technician approximately an hour to do. On the other hand, the customer will be able to surf the web from his kitchen on a home network that is more finely engineered than the one in an NSA supercomputer lab. -- Larry Colen l...@red4est.com (postbox on min4est) http://red4est.com/lrc -- PDML Pentax-Discuss Mail List PDML@pdml.net http://pdml.net/mailman/listinfo/pdml_pdml.net to UNSUBSCRIBE from the PDML, please visit the link directly above and follow the directions.
