As my current program is coming to a close I've been evaluating alternative programs that my current employer has to offer. In terms of interest, it's pretty slim pickings.
As a result, I've took part in my first phone interview in 3+ years. Things went quite well, the closing question from the HR rep was concerning compensation. Now I'm not currently hitting 6 figures, but I'm charging hard toward the hoop.
Growing up blue collar I know what hard work is; I've shoveled grain, tossed bales, and picked my share of rock for less than $2 / hour. I've spent my share of days working in 90+ degree heat with a gallon of water for the day and little more than a warm bologna and cheese sandwich (oftentimes with mayo.....warmed in the afternoon sun). I've busted hump 'til my back ached, shoulders gave out, and feet grew a crop of blisters from heel to toe. I know what it feels to suffer serious dehydration, and my share of hangovers cured by the recommended dosage of sweating it out with outdoor manual labor. I know what hard work is, and I know what salary you can expect for this type of labor.
I try to keep this in mind time-n-time-again, took keep things in check. I approached an initial salary that competed with my fathers maximum salary he'd been working toward his entire life. Less than 10 years have passed since, and my salary has more than doubled. Rates of change will slow from here on, but still....we are incredibly fortunate in the field that we are in. If you are even moderately competent, you'll demand a salary that will surpass most dual family incomes. Chances are that you'll go home to your well furnished apartment, or quite likely single family home where you'll relax in your easy chair quietly decompressing to the drone of central air. Your reminder of a hard day....a migraine, or perhaps an armful of paperwork/techwork you need to complete before morning. The only joint or muscle issues you'll likely face is a mild case of carpal tunnel.
Just try to remember how easy we have it the next time you find yourself complaining about work. Better yet, keep this in mind on a good day; remembering how well you're paid to do something you truly love.
Cheers.
Showing posts with label software engineering. Show all posts
Showing posts with label software engineering. Show all posts
14 March, 2008
17 June, 2007
Software Programming Paradigms
Oh, what did we do before Wikipedia!
My wife is defining some software development training materials focusing on the object-oriented programming paradigm. One of the slides presents the idea that object-oriented programming is _a_ programming technique, not _the_ programming technique.
Far too often I think we get caught up with a new technology and believe that it is the end-all of software development. Object-oriented programming, agile development, Ruby-on-rails, . . . I think we all too often jump on the new technology bandwagon. It is worth a lunch-hour to investigate some of the other programming paradigms.
http://en.wikipedia.org/wiki/Programming_paradigm
My wife is defining some software development training materials focusing on the object-oriented programming paradigm. One of the slides presents the idea that object-oriented programming is _a_ programming technique, not _the_ programming technique.
Far too often I think we get caught up with a new technology and believe that it is the end-all of software development. Object-oriented programming, agile development, Ruby-on-rails, . . . I think we all too often jump on the new technology bandwagon. It is worth a lunch-hour to investigate some of the other programming paradigms.
http://en.wikipedia.org/wiki/Programming_paradigm
15 April, 2007
Minnesota Bound
I am currently en route from Orlando, FL on my way back from an SPIE conference where a colleague authored and presented a paper. I tagged along as a result of my co-author status.....senor' coat-tails has been the title that comes to mind.
A number of interesting topics were presented, primarily concerned with wireless communications and fields of study concerning sensors. An observation worth noting was the evident differences in the disciplines of the presenters and how it affected the detail of the topic and the presentation style.
As I've said in the past, I am a software engineer by trade, having a BS and MS degree in Computer Science. Both school and industry alike, I've been surrounded by individuals both in Comp Sci as well as other engineering disciplines such as physics, electrical as well as mechanical engineering and the differences in the disciplines are very evident.
As much as a person wishes not to admit it....computer science is still a 'soft' science. Sure, it is far more disciplined than the likes of some other engineering persuasions, but is still far less structured as the likes of pure mathematics, physics, optics, electrical or mechanical engineering. The majority of the presentations were conducted by doctorates of physics, electrical or optical engineering, but every once in a while you'd get a computer science major up there and the presentation took a different tone. The best way I can say it is that the logic was softer or more fuzzy. Most presentations from more formal disciplines would be followed with mathematical description of the technology. Computer science presentations rarely had such formality, with the occasional exception to a presenter that had an undergrad degree in a more disciplined major and a PhD in computer science.
Am I knocking Comp Sci...to a degree I am doing just that. With the minor exception to those that pursue theoretical computer science focuses which are more in line with formal mathematics the majority of us still groan in the presence of a formal proof, a detailed description of the fundamental technology in the only pure language...mathematics. As a result, I think we give up the things that could make our discipline more successful. I can, for one, say that if we took a more structured look at proving techniques on paper rather than jump in and start coding we may have less error-prone technologies.
I'm not touting that we should all begin doing formal proofs on the effectiveness and efficiency of our authored algorithms. Instead, I'm saying that perhaps it's worth a 1/2 a day investigation on paper before firing up your trusty editor out of the gate.
A number of interesting topics were presented, primarily concerned with wireless communications and fields of study concerning sensors. An observation worth noting was the evident differences in the disciplines of the presenters and how it affected the detail of the topic and the presentation style.
As I've said in the past, I am a software engineer by trade, having a BS and MS degree in Computer Science. Both school and industry alike, I've been surrounded by individuals both in Comp Sci as well as other engineering disciplines such as physics, electrical as well as mechanical engineering and the differences in the disciplines are very evident.
As much as a person wishes not to admit it....computer science is still a 'soft' science. Sure, it is far more disciplined than the likes of some other engineering persuasions, but is still far less structured as the likes of pure mathematics, physics, optics, electrical or mechanical engineering. The majority of the presentations were conducted by doctorates of physics, electrical or optical engineering, but every once in a while you'd get a computer science major up there and the presentation took a different tone. The best way I can say it is that the logic was softer or more fuzzy. Most presentations from more formal disciplines would be followed with mathematical description of the technology. Computer science presentations rarely had such formality, with the occasional exception to a presenter that had an undergrad degree in a more disciplined major and a PhD in computer science.
Am I knocking Comp Sci...to a degree I am doing just that. With the minor exception to those that pursue theoretical computer science focuses which are more in line with formal mathematics the majority of us still groan in the presence of a formal proof, a detailed description of the fundamental technology in the only pure language...mathematics. As a result, I think we give up the things that could make our discipline more successful. I can, for one, say that if we took a more structured look at proving techniques on paper rather than jump in and start coding we may have less error-prone technologies.
I'm not touting that we should all begin doing formal proofs on the effectiveness and efficiency of our authored algorithms. Instead, I'm saying that perhaps it's worth a 1/2 a day investigation on paper before firing up your trusty editor out of the gate.
06 January, 2007
I am the Victim of a Drive-By Coding
I've been a software developer for the past 9 years for various defense organizations.
A common practice, in times of need, is to employ temporary assets in the form of contractor engineers. This practice has time and time again proven to aid in the development of programs that have an aggressive schedule and a budget to accomodate the extensive salaries for contractors.
The typical role of a contractor is that of being brought in at a time of need and after that need has been eliminated the contractor(s) are shortly let go. The loftly salaries of these contractors is justifyable when you consider that they are brought in and placed immediately on 'critical path', and the understanding that they will be eliminated shortly after they are no longer needed. I've worked with dozens of contractors over the years and my opinion of the majority of them is quite positive. Most of them are not what I'd consider to be extraordinarily talented; the majority of contractors are pretty average. This coming from a software engineer that rates himself...average. Besides, on average....people are average. The reason I even mention this is to disolve any delusion that contractors are extraordinarily efficient, knowledgeable or brilliant. No, most are just like you or I.
I notable observation that I've made over these years is a typical side effect of contracted work. Note that typical contractors are involved with a project for a matter of months. Most often, they come in at the preliminary or detailed design phase and are responsible for designing and coding of some defined task(s). Keeping the short duration of involvement in mind, a common side-effect of contractor work is minimal or non-existant documentation in detailed design or the implementation phases of development. I don't necessarily fault contractors for failing to document their design or code. Over the years of playing revolving doors with companies they are never around long enough to see the pain and suffering resulting from updating a design or code that contains no documentation. One of my most recent sorrows entailed reviewing a design for a radio component from a contractor engineer. The majority of the minimal documentation was of the nature of 'do good things here'. I suffered through a code review of this product, and after a numbing 16 hours of reviewing I was near tears. One method in particular spanned approximately 3 pages (or ~120 lines since hardcopy is dead). It took better than an hour studying some of the most complicated code on the planet I finally realized that the method was responsible for scheduling message delivery with a priority scheme where messages intended for a single destination are given priority to those messages intended for multiple destinations. How was I suppose to know of this scheme.....well, not from the non-existent comments, nor from the radio interface control document (the priority scheme wasn't dictated by the hardware)...no, the only way to become enlightened to this design was to read the code.....the hundreds of lines of code....the code that rivals in complexity that of the Apollo space program. Days from now this contractor will be gone and some sap will be responsible for his product. This sap has become me on more than one occasion and I suspect it will once again be me. I look forward to the days of being bombarded with questions about this software component, followed by hours of diving into the code producing the answer and returning for a fresh set of questions. Better yet, fielding the software component will undoubtedly identify errors which will involve hours and hours of unpaid overtime.
I'll end this post with another plea. For God's sake, document your damn code!!
A common practice, in times of need, is to employ temporary assets in the form of contractor engineers. This practice has time and time again proven to aid in the development of programs that have an aggressive schedule and a budget to accomodate the extensive salaries for contractors.
The typical role of a contractor is that of being brought in at a time of need and after that need has been eliminated the contractor(s) are shortly let go. The loftly salaries of these contractors is justifyable when you consider that they are brought in and placed immediately on 'critical path', and the understanding that they will be eliminated shortly after they are no longer needed. I've worked with dozens of contractors over the years and my opinion of the majority of them is quite positive. Most of them are not what I'd consider to be extraordinarily talented; the majority of contractors are pretty average. This coming from a software engineer that rates himself...average. Besides, on average....people are average. The reason I even mention this is to disolve any delusion that contractors are extraordinarily efficient, knowledgeable or brilliant. No, most are just like you or I.
I notable observation that I've made over these years is a typical side effect of contracted work. Note that typical contractors are involved with a project for a matter of months. Most often, they come in at the preliminary or detailed design phase and are responsible for designing and coding of some defined task(s). Keeping the short duration of involvement in mind, a common side-effect of contractor work is minimal or non-existant documentation in detailed design or the implementation phases of development. I don't necessarily fault contractors for failing to document their design or code. Over the years of playing revolving doors with companies they are never around long enough to see the pain and suffering resulting from updating a design or code that contains no documentation. One of my most recent sorrows entailed reviewing a design for a radio component from a contractor engineer. The majority of the minimal documentation was of the nature of 'do good things here'. I suffered through a code review of this product, and after a numbing 16 hours of reviewing I was near tears. One method in particular spanned approximately 3 pages (or ~120 lines since hardcopy is dead). It took better than an hour studying some of the most complicated code on the planet I finally realized that the method was responsible for scheduling message delivery with a priority scheme where messages intended for a single destination are given priority to those messages intended for multiple destinations. How was I suppose to know of this scheme.....well, not from the non-existent comments, nor from the radio interface control document (the priority scheme wasn't dictated by the hardware)...no, the only way to become enlightened to this design was to read the code.....the hundreds of lines of code....the code that rivals in complexity that of the Apollo space program. Days from now this contractor will be gone and some sap will be responsible for his product. This sap has become me on more than one occasion and I suspect it will once again be me. I look forward to the days of being bombarded with questions about this software component, followed by hours of diving into the code producing the answer and returning for a fresh set of questions. Better yet, fielding the software component will undoubtedly identify errors which will involve hours and hours of unpaid overtime.
I'll end this post with another plea. For God's sake, document your damn code!!
Subscribe to:
Posts (Atom)