Sympathy, or smack me
-
or both. So, as you probably know, I gave my notice. The expected and gratifying panic ensued, resulting in lots of "we need to understand how your code works" meetings. During these meetings, various warts are exposed, warts I knew about and for the most part had
// TODO: Cleanupcomments around. Why the warts? Because in the two years I've worked on this project, off and on, sometimes with a good several months "off" because management kept shifting my priorities, the project has evolved from basically a simple "read in the XML data and serialize it out into a fixed length delimited flat file" to a complex beast that has to handle numerous variations of the string-based XML data, numerous rules on how additional records need to be inserted, or excluded, or massaged, etc. etc. etc. Basically, what I have implemented should for the most part be considered at this point a throw-away prototype given the learning that has occurred over the 2 years on just how freaking complicated it is to take denormalized data (as XML strings of all things, so there's no consistency in the naming of lookup values), handle all the variations spit out by the processes that create the XML...point being, I learned a ton of stuff as I went along, and I wouldn't have written the program the way I did had I known all this stuff up front. Stuff that only a couple people in the IT department actually understand. So, during the code walkthroughs, I keep getting frowning faces and questions like "where did this requirement come from?" Given that the project had a one line requirement "convert XML and report it to the third party agency" (the spec for that is a 200 page tome with a separate addendum), I laugh when I hear the phrase "requirement." And so this morass is being handed to a junior dev that isn't comfortable yet with what I consider basic C# features -- generics, LINQ, lambda expressions, abstract classes, etc. Management says I'm the only senior developer that the IT department has ever hired. :sigh: I can see the argument for "code for the junior developers" - ie, lots of cut and paste. This poor guy, who is inheriting my project, is who really deserves sympathy. So much for the sympathy. Here's the part where I'm smacking myself. There's only one person qualified to do the code walkthrough -- this person is really quite smart. It's actually a pleasure (in a painful way) to have someone that knows C# well enough go through the code with me. However, her main job is DB admin stuff, notI think you should give yourself more credit. Here's an example of why. I had a project that needed to be completed -- a tool for internal use -- but their tech leads said they needed more functionality. I said, "Ok, let's hammer out exactly what you need and we'll do it in an Agile fashion. I will take each one, develop it, turn it back to you and we'll iterate to make those last items exactly as you want them." We went in and they only had four medium sized pieces of functionality that they wanted. I had them confirm numerous times that is all they needed. I then went into dev mode and did the first one. I placed the working code that ran against prod in a location where they could try it out. I created a 1 minute video to show them how it worked. Please take a look, said I. Oh, we will, said they. We iterated through each of those items just like that. Two or three weeks later, I sent out the last piece of functionality and said, "That's it. I'm done. You have everything you have asked for." "Wait a minute..." they squealed. "What about...?" "Well, I showed you that and it is X," I said. "No, it doesn't look right," the tech lead said. "I sent that one out two weeks ago and ZZ on your team who you gave authority redesigned it. I didn't even design that piece. It is exactly as ZZ asked for it and he signed off on it and you supposedly saw it already." "Ok, well..." said tech lead. The point here is that I walked these users through the exact functionality of 4 smallish items of functionality and I sent them video snapshots of the functionality in action and provided them with a working copy, but only at the end of the entire thing when I said I'm done could they then begin to think of something that isn't right or needed something more. My point: they don't know what they want, they cannot communicate it and anything you give them will be wrong anyways. That may sound cynical, but it is simply the truth of the situation. My other point: give yourself a break here. Everything placed under a microscope looks so different than when people just look at it normally.
-
or both. So, as you probably know, I gave my notice. The expected and gratifying panic ensued, resulting in lots of "we need to understand how your code works" meetings. During these meetings, various warts are exposed, warts I knew about and for the most part had
// TODO: Cleanupcomments around. Why the warts? Because in the two years I've worked on this project, off and on, sometimes with a good several months "off" because management kept shifting my priorities, the project has evolved from basically a simple "read in the XML data and serialize it out into a fixed length delimited flat file" to a complex beast that has to handle numerous variations of the string-based XML data, numerous rules on how additional records need to be inserted, or excluded, or massaged, etc. etc. etc. Basically, what I have implemented should for the most part be considered at this point a throw-away prototype given the learning that has occurred over the 2 years on just how freaking complicated it is to take denormalized data (as XML strings of all things, so there's no consistency in the naming of lookup values), handle all the variations spit out by the processes that create the XML...point being, I learned a ton of stuff as I went along, and I wouldn't have written the program the way I did had I known all this stuff up front. Stuff that only a couple people in the IT department actually understand. So, during the code walkthroughs, I keep getting frowning faces and questions like "where did this requirement come from?" Given that the project had a one line requirement "convert XML and report it to the third party agency" (the spec for that is a 200 page tome with a separate addendum), I laugh when I hear the phrase "requirement." And so this morass is being handed to a junior dev that isn't comfortable yet with what I consider basic C# features -- generics, LINQ, lambda expressions, abstract classes, etc. Management says I'm the only senior developer that the IT department has ever hired. :sigh: I can see the argument for "code for the junior developers" - ie, lots of cut and paste. This poor guy, who is inheriting my project, is who really deserves sympathy. So much for the sympathy. Here's the part where I'm smacking myself. There's only one person qualified to do the code walkthrough -- this person is really quite smart. It's actually a pleasure (in a painful way) to have someone that knows C# well enough go through the code with me. However, her main job is DB admin stuff, notIn summary, you should have left earlier :) My takeaway from reading your post...it sounds like your management doesn't value its people and (probably) never will. Trust me, I've been there. I stayed waaay too long and tried to fix the problems...predictably, without a successful outcome. Of course, you could have done the same...tried all the fixes and work-arounds in your post. My guess, nothing would have changed there either. You'd simply have wasted more of your time and left (possibly) more frustrated. So, instead, congrats on getting out and finding a new job! No looking back, look forward and enjoy the new job instead :)
-
or both. So, as you probably know, I gave my notice. The expected and gratifying panic ensued, resulting in lots of "we need to understand how your code works" meetings. During these meetings, various warts are exposed, warts I knew about and for the most part had
// TODO: Cleanupcomments around. Why the warts? Because in the two years I've worked on this project, off and on, sometimes with a good several months "off" because management kept shifting my priorities, the project has evolved from basically a simple "read in the XML data and serialize it out into a fixed length delimited flat file" to a complex beast that has to handle numerous variations of the string-based XML data, numerous rules on how additional records need to be inserted, or excluded, or massaged, etc. etc. etc. Basically, what I have implemented should for the most part be considered at this point a throw-away prototype given the learning that has occurred over the 2 years on just how freaking complicated it is to take denormalized data (as XML strings of all things, so there's no consistency in the naming of lookup values), handle all the variations spit out by the processes that create the XML...point being, I learned a ton of stuff as I went along, and I wouldn't have written the program the way I did had I known all this stuff up front. Stuff that only a couple people in the IT department actually understand. So, during the code walkthroughs, I keep getting frowning faces and questions like "where did this requirement come from?" Given that the project had a one line requirement "convert XML and report it to the third party agency" (the spec for that is a 200 page tome with a separate addendum), I laugh when I hear the phrase "requirement." And so this morass is being handed to a junior dev that isn't comfortable yet with what I consider basic C# features -- generics, LINQ, lambda expressions, abstract classes, etc. Management says I'm the only senior developer that the IT department has ever hired. :sigh: I can see the argument for "code for the junior developers" - ie, lots of cut and paste. This poor guy, who is inheriting my project, is who really deserves sympathy. So much for the sympathy. Here's the part where I'm smacking myself. There's only one person qualified to do the code walkthrough -- this person is really quite smart. It's actually a pleasure (in a painful way) to have someone that knows C# well enough go through the code with me. However, her main job is DB admin stuff, notMarc Clifton wrote:
Given that the project had a one line requirement "convert XML and report it to the third party agency" (the spec for that is a 200 page tome with a separate addendum), I laugh when I hear the phrase "requirement."
Back in the day I worked at a Building Society (equivalent to a "Savings and Loans" in the US??). I was a new hire at the place, and the person I was supposed to be working with insisted we had "full business requirements" before he'd allow our boss to start work. I was put on looking at Enterprise Application Blocks, until my colleague was happy. After a month I was getting really bored, so I decided to by-pass my co-worker and convinced my boss to show me the requirements as they stand so I could at least see the scope of the system I'd been initially hired to produce. There was the usual business scope and flannel, once that was out of the way, the actual spec part was about 8 pages. It was really curious what the Business Analysts thought were the important points. They's spent two pages each specifiying the Loan-To-Value ration and Loan to Income ratio. About six pages in, in the midst of a spectacularly waffle-y bit was a remarkable sentence: "The system will be able to process mortgages for multiple providers with flexible processing requirements for each provider". It wasn't mentioned again anywhere. After talking to some people I confirmed my suspicion. They'd Analysts had spent four pages specifying in intricate detail the meaning of two simple ratios, but had hidden an entire highly-configurable multi-tenant workflow system inside one sentence.I have felt your pain, to some extent.
KeithBarrow.net[^] - It might not be very good, but at least it is free!
-
Marc Clifton wrote:
Given that the project had a one line requirement "convert XML and report it to the third party agency" (the spec for that is a 200 page tome with a separate addendum), I laugh when I hear the phrase "requirement."
Back in the day I worked at a Building Society (equivalent to a "Savings and Loans" in the US??). I was a new hire at the place, and the person I was supposed to be working with insisted we had "full business requirements" before he'd allow our boss to start work. I was put on looking at Enterprise Application Blocks, until my colleague was happy. After a month I was getting really bored, so I decided to by-pass my co-worker and convinced my boss to show me the requirements as they stand so I could at least see the scope of the system I'd been initially hired to produce. There was the usual business scope and flannel, once that was out of the way, the actual spec part was about 8 pages. It was really curious what the Business Analysts thought were the important points. They's spent two pages each specifiying the Loan-To-Value ration and Loan to Income ratio. About six pages in, in the midst of a spectacularly waffle-y bit was a remarkable sentence: "The system will be able to process mortgages for multiple providers with flexible processing requirements for each provider". It wasn't mentioned again anywhere. After talking to some people I confirmed my suspicion. They'd Analysts had spent four pages specifying in intricate detail the meaning of two simple ratios, but had hidden an entire highly-configurable multi-tenant workflow system inside one sentence.I have felt your pain, to some extent.
KeithBarrow.net[^] - It might not be very good, but at least it is free!
Keith Barrow wrote:
Analysts had spent four pages specifying in intricate detail the meaning of two simple ratios, but had hidden an entire highly-configurable multi-tenant workflow system inside one sentence
:thumbsup: That's a perfect explanation of the challenge and problem of how requirements are gathered and analyzed. Too much focus on small details. Too little focus on extremely important things. It's often based on what the analyst understood thoroughly and did not (thoroughly) understand. We tend to spend time with things we understand.
-
Keith Barrow wrote:
Analysts had spent four pages specifying in intricate detail the meaning of two simple ratios, but had hidden an entire highly-configurable multi-tenant workflow system inside one sentence
:thumbsup: That's a perfect explanation of the challenge and problem of how requirements are gathered and analyzed. Too much focus on small details. Too little focus on extremely important things. It's often based on what the analyst understood thoroughly and did not (thoroughly) understand. We tend to spend time with things we understand.
I so miss the days of "requirements"! Now, we simply sit around the table, tell stories, and assign story points :)
-
or both. So, as you probably know, I gave my notice. The expected and gratifying panic ensued, resulting in lots of "we need to understand how your code works" meetings. During these meetings, various warts are exposed, warts I knew about and for the most part had
// TODO: Cleanupcomments around. Why the warts? Because in the two years I've worked on this project, off and on, sometimes with a good several months "off" because management kept shifting my priorities, the project has evolved from basically a simple "read in the XML data and serialize it out into a fixed length delimited flat file" to a complex beast that has to handle numerous variations of the string-based XML data, numerous rules on how additional records need to be inserted, or excluded, or massaged, etc. etc. etc. Basically, what I have implemented should for the most part be considered at this point a throw-away prototype given the learning that has occurred over the 2 years on just how freaking complicated it is to take denormalized data (as XML strings of all things, so there's no consistency in the naming of lookup values), handle all the variations spit out by the processes that create the XML...point being, I learned a ton of stuff as I went along, and I wouldn't have written the program the way I did had I known all this stuff up front. Stuff that only a couple people in the IT department actually understand. So, during the code walkthroughs, I keep getting frowning faces and questions like "where did this requirement come from?" Given that the project had a one line requirement "convert XML and report it to the third party agency" (the spec for that is a 200 page tome with a separate addendum), I laugh when I hear the phrase "requirement." And so this morass is being handed to a junior dev that isn't comfortable yet with what I consider basic C# features -- generics, LINQ, lambda expressions, abstract classes, etc. Management says I'm the only senior developer that the IT department has ever hired. :sigh: I can see the argument for "code for the junior developers" - ie, lots of cut and paste. This poor guy, who is inheriting my project, is who really deserves sympathy. So much for the sympathy. Here's the part where I'm smacking myself. There's only one person qualified to do the code walkthrough -- this person is really quite smart. It's actually a pleasure (in a painful way) to have someone that knows C# well enough go through the code with me. However, her main job is DB admin stuff, notTotally OT: I never cease to be amazed at how frequently some of you folks change jobs. I think that would drive me absolutely bat shit crazy. I'm 55 years old and would not relish being in the job market again - even in today's market. At nearly 33 years at one company I realize that I'm on the opposite end of the spectrum. However, it does make me think and work in a much longer term sense. Nearly all of our projects (machine tools) take 1-2 years before the product is shipped and then are expected to be manufactured for a decade. Once in the field the expectation is these machines run for multiple decades.
-
or both. So, as you probably know, I gave my notice. The expected and gratifying panic ensued, resulting in lots of "we need to understand how your code works" meetings. During these meetings, various warts are exposed, warts I knew about and for the most part had
// TODO: Cleanupcomments around. Why the warts? Because in the two years I've worked on this project, off and on, sometimes with a good several months "off" because management kept shifting my priorities, the project has evolved from basically a simple "read in the XML data and serialize it out into a fixed length delimited flat file" to a complex beast that has to handle numerous variations of the string-based XML data, numerous rules on how additional records need to be inserted, or excluded, or massaged, etc. etc. etc. Basically, what I have implemented should for the most part be considered at this point a throw-away prototype given the learning that has occurred over the 2 years on just how freaking complicated it is to take denormalized data (as XML strings of all things, so there's no consistency in the naming of lookup values), handle all the variations spit out by the processes that create the XML...point being, I learned a ton of stuff as I went along, and I wouldn't have written the program the way I did had I known all this stuff up front. Stuff that only a couple people in the IT department actually understand. So, during the code walkthroughs, I keep getting frowning faces and questions like "where did this requirement come from?" Given that the project had a one line requirement "convert XML and report it to the third party agency" (the spec for that is a 200 page tome with a separate addendum), I laugh when I hear the phrase "requirement." And so this morass is being handed to a junior dev that isn't comfortable yet with what I consider basic C# features -- generics, LINQ, lambda expressions, abstract classes, etc. Management says I'm the only senior developer that the IT department has ever hired. :sigh: I can see the argument for "code for the junior developers" - ie, lots of cut and paste. This poor guy, who is inheriting my project, is who really deserves sympathy. So much for the sympathy. Here's the part where I'm smacking myself. There's only one person qualified to do the code walkthrough -- this person is really quite smart. It's actually a pleasure (in a painful way) to have someone that knows C# well enough go through the code with me. However, her main job is DB admin stuff, not -
If you don't look back and ask "Why didn't I do x, y, or z?", then you didn't learn anything from the experience. So at least there's that.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
Nathan Minier wrote:
So at least there's that.
Quite so! And as others have said and I agree with, it really wouldn't have changed anything.
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
Well, it is always easier to judge the situation afterwards, when you do not have the tip of the nose touching the screen... It is a great skill to be able to pose judgment on oneself, though. If that could reassure you, I once was in a similar position with no process, no requirements, no nothing, and I tried to be professional about my work disregarding the management (who also lied to me during the interview) - this only lasted two more months before I left -> Even with good will, it is almost impossible to bend the organisation in such a manner that it suits you then. If that were so easy to change things or do them better, then the organisation would not have come that low first place. All that to say : do not be harsh to yourself, there was only little chance that behaving "ideally" as you mentioned it in your post would have changed anything anyway.
Rage wrote:
there was only little chance that behaving "ideally" as you mentioned it in your post would have changed anything anyway.
That was the final nail in the coffin, when I realized that.
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
I think you should give yourself more credit. Here's an example of why. I had a project that needed to be completed -- a tool for internal use -- but their tech leads said they needed more functionality. I said, "Ok, let's hammer out exactly what you need and we'll do it in an Agile fashion. I will take each one, develop it, turn it back to you and we'll iterate to make those last items exactly as you want them." We went in and they only had four medium sized pieces of functionality that they wanted. I had them confirm numerous times that is all they needed. I then went into dev mode and did the first one. I placed the working code that ran against prod in a location where they could try it out. I created a 1 minute video to show them how it worked. Please take a look, said I. Oh, we will, said they. We iterated through each of those items just like that. Two or three weeks later, I sent out the last piece of functionality and said, "That's it. I'm done. You have everything you have asked for." "Wait a minute..." they squealed. "What about...?" "Well, I showed you that and it is X," I said. "No, it doesn't look right," the tech lead said. "I sent that one out two weeks ago and ZZ on your team who you gave authority redesigned it. I didn't even design that piece. It is exactly as ZZ asked for it and he signed off on it and you supposedly saw it already." "Ok, well..." said tech lead. The point here is that I walked these users through the exact functionality of 4 smallish items of functionality and I sent them video snapshots of the functionality in action and provided them with a working copy, but only at the end of the entire thing when I said I'm done could they then begin to think of something that isn't right or needed something more. My point: they don't know what they want, they cannot communicate it and anything you give them will be wrong anyways. That may sound cynical, but it is simply the truth of the situation. My other point: give yourself a break here. Everything placed under a microscope looks so different than when people just look at it normally.
raddevus wrote:
Everything placed under a microscope looks so different than when people just look at it normally.
Not just different but unrecognizable! :laugh:
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
In summary, you should have left earlier :) My takeaway from reading your post...it sounds like your management doesn't value its people and (probably) never will. Trust me, I've been there. I stayed waaay too long and tried to fix the problems...predictably, without a successful outcome. Of course, you could have done the same...tried all the fixes and work-arounds in your post. My guess, nothing would have changed there either. You'd simply have wasted more of your time and left (possibly) more frustrated. So, instead, congrats on getting out and finding a new job! No looking back, look forward and enjoy the new job instead :)
Eric Lynch wrote:
In summary, you should have left earlier
Yup!
Eric Lynch wrote:
t sounds like your management doesn't value its people and (probably) never will.
Bingo! It's bizarre pathetic being hired as a senior and being "used" effectively as a junior.
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
Marc Clifton wrote:
Given that the project had a one line requirement "convert XML and report it to the third party agency" (the spec for that is a 200 page tome with a separate addendum), I laugh when I hear the phrase "requirement."
Back in the day I worked at a Building Society (equivalent to a "Savings and Loans" in the US??). I was a new hire at the place, and the person I was supposed to be working with insisted we had "full business requirements" before he'd allow our boss to start work. I was put on looking at Enterprise Application Blocks, until my colleague was happy. After a month I was getting really bored, so I decided to by-pass my co-worker and convinced my boss to show me the requirements as they stand so I could at least see the scope of the system I'd been initially hired to produce. There was the usual business scope and flannel, once that was out of the way, the actual spec part was about 8 pages. It was really curious what the Business Analysts thought were the important points. They's spent two pages each specifiying the Loan-To-Value ration and Loan to Income ratio. About six pages in, in the midst of a spectacularly waffle-y bit was a remarkable sentence: "The system will be able to process mortgages for multiple providers with flexible processing requirements for each provider". It wasn't mentioned again anywhere. After talking to some people I confirmed my suspicion. They'd Analysts had spent four pages specifying in intricate detail the meaning of two simple ratios, but had hidden an entire highly-configurable multi-tenant workflow system inside one sentence.I have felt your pain, to some extent.
KeithBarrow.net[^] - It might not be very good, but at least it is free!
Keith Barrow wrote:
the actual spec part was about 8 pages
Heck, even 8 pages would have been an improvement, even if it focused on the wrong stuff. The project was entered into SDLC with the following one line service request description (sanitized): > Implement Foo for Bar reporting for Fiz in Bin That covered the entire scope of a 2 year project including utilities, unit tests, UAT data, and on and on and on.
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
Keith Barrow wrote:
Analysts had spent four pages specifying in intricate detail the meaning of two simple ratios, but had hidden an entire highly-configurable multi-tenant workflow system inside one sentence
:thumbsup: That's a perfect explanation of the challenge and problem of how requirements are gathered and analyzed. Too much focus on small details. Too little focus on extremely important things. It's often based on what the analyst understood thoroughly and did not (thoroughly) understand. We tend to spend time with things we understand.
I have learned that what you consider important and what office drones consider important never match and rarely overlap. We consider network impacts, efficient CPU utilization, and database read times while they are focused on how many more/less times they have to hit the tab key, use the mouse, and frickin font sizes. Even worse, I swear some people think that all desktop applications should behave like web browsers. X|
if (Object.DividedByZero == true) { Universe.Implode(); }
-
Totally OT: I never cease to be amazed at how frequently some of you folks change jobs. I think that would drive me absolutely bat shit crazy. I'm 55 years old and would not relish being in the job market again - even in today's market. At nearly 33 years at one company I realize that I'm on the opposite end of the spectrum. However, it does make me think and work in a much longer term sense. Nearly all of our projects (machine tools) take 1-2 years before the product is shipped and then are expected to be manufactured for a decade. Once in the field the expectation is these machines run for multiple decades.
-
Totally OT: I never cease to be amazed at how frequently some of you folks change jobs. I think that would drive me absolutely bat shit crazy. I'm 55 years old and would not relish being in the job market again - even in today's market. At nearly 33 years at one company I realize that I'm on the opposite end of the spectrum. However, it does make me think and work in a much longer term sense. Nearly all of our projects (machine tools) take 1-2 years before the product is shipped and then are expected to be manufactured for a decade. Once in the field the expectation is these machines run for multiple decades.
Mike Mullikin wrote:
I never cease to be amazed at how frequently some of you folks change jobs.
I was pondering that last night. Most of my professional life has been as a contractor, so I go more or less where the wind blows. I have a client I've worked with for 25 years, but the work is sporadic, sometimes a couple years between projects. Another long term client went through bankruptcy, dumped their contractors (and some employees), the process took years, then they brought me back, only to be dumped after a couple years because a couple high level managers came in from completely different industries that had a bee in their bonnet regarding contractors. The last two W2 jobs I've held (including this one) I've left because of what I would call toxic management. I would love to stay somewhere long term, and my #1 goal with this new job is to accomplish exactly that.
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
Sympathy For The Devil (Live) - YouTube[^]
"If we don't change direction, we'll end up where we're going"
Another reason I'm glad to be leaving -- blocked site!!!
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
Totally OT: I never cease to be amazed at how frequently some of you folks change jobs. I think that would drive me absolutely bat shit crazy. I'm 55 years old and would not relish being in the job market again - even in today's market. At nearly 33 years at one company I realize that I'm on the opposite end of the spectrum. However, it does make me think and work in a much longer term sense. Nearly all of our projects (machine tools) take 1-2 years before the product is shipped and then are expected to be manufactured for a decade. Once in the field the expectation is these machines run for multiple decades.
Regrettably, the software industry seldom values that sort of long-term thinking. More often, companies toss crap over the fence every month or so, hope it works, and then fix it when it (inevitably) doesn't. This process has a tendency to chew people up. Though, it wasn't always that way. It used to be a tremendous amount of fun! My longest run, to date, was a bit over 10 years. It was a great company that had a long-term vision and treated its employees well. The companies success was rewarded by making it an attractive buy out target. They got taken over, in an LBO, by a company seeking short term gains. A couple of years, a few corporate name changes, a record-breaking bankruptcy (which made international news), a few jail sentences (for a couple of execs), and minus much of my life savings, I found myself seeking new employment. It was a long time ago, so I can look back and laugh now (almost). It gave me a much different view on what a company owes me and what I owe a company. Since then, I've probably averaged about a 3 year tenure. Each company benefits with someone who's eager to work, has a broader range of skills, and brings a new vision. I get to learn new skills and avoid boredom. This way, everyone wins and no one gets hurt! OK, not entirely true. Between jobs, like now, my savings account sometimes takes a hit :)
-
Eric Lynch wrote:
In summary, you should have left earlier
Yup!
Eric Lynch wrote:
t sounds like your management doesn't value its people and (probably) never will.
Bingo! It's bizarre pathetic being hired as a senior and being "used" effectively as a junior.
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
I hear you. Immodestly, I'm a damned good engineer. Despite that, inevitably, companies try to "reward" my work by using me as a manager. That's usually about when I switch jobs. At best, I'm a competent manager...maybe its my white hair that misleads them :)
-
or both. So, as you probably know, I gave my notice. The expected and gratifying panic ensued, resulting in lots of "we need to understand how your code works" meetings. During these meetings, various warts are exposed, warts I knew about and for the most part had
// TODO: Cleanupcomments around. Why the warts? Because in the two years I've worked on this project, off and on, sometimes with a good several months "off" because management kept shifting my priorities, the project has evolved from basically a simple "read in the XML data and serialize it out into a fixed length delimited flat file" to a complex beast that has to handle numerous variations of the string-based XML data, numerous rules on how additional records need to be inserted, or excluded, or massaged, etc. etc. etc. Basically, what I have implemented should for the most part be considered at this point a throw-away prototype given the learning that has occurred over the 2 years on just how freaking complicated it is to take denormalized data (as XML strings of all things, so there's no consistency in the naming of lookup values), handle all the variations spit out by the processes that create the XML...point being, I learned a ton of stuff as I went along, and I wouldn't have written the program the way I did had I known all this stuff up front. Stuff that only a couple people in the IT department actually understand. So, during the code walkthroughs, I keep getting frowning faces and questions like "where did this requirement come from?" Given that the project had a one line requirement "convert XML and report it to the third party agency" (the spec for that is a 200 page tome with a separate addendum), I laugh when I hear the phrase "requirement." And so this morass is being handed to a junior dev that isn't comfortable yet with what I consider basic C# features -- generics, LINQ, lambda expressions, abstract classes, etc. Management says I'm the only senior developer that the IT department has ever hired. :sigh: I can see the argument for "code for the junior developers" - ie, lots of cut and paste. This poor guy, who is inheriting my project, is who really deserves sympathy. So much for the sympathy. Here's the part where I'm smacking myself. There's only one person qualified to do the code walkthrough -- this person is really quite smart. It's actually a pleasure (in a painful way) to have someone that knows C# well enough go through the code with me. However, her main job is DB admin stuff, not -
Another reason I'm glad to be leaving -- blocked site!!!
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802