Sympathy, or smack me
-
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
-
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.
That was my take-away from the whole thing, hadn't experienced the full force of Business Analysts before then.
KeithBarrow.net[^] - It might not be very good, but at least it is free!
-
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.
Although "long" is relative, I like to think of myself as one of those long-term guys--although I've only been staying for as long as I could. I was at my first dev job (relatively small company) for maybe 5 years before it got acquired by a large multinational that actually didn't understand software and shut down what was, for them, a small and irrelevant remote office a year or two later. That was around the dot-com crash and the parent company was looking at cutting costs even though we were barely a month away from releasing a product that could've made a lot of money. I then joined a group of ex-coworkers at their small startup and stayed for maybe half a dozen years before it got acquired by Microsoft. Everything got moved to Redmond, but I stayed on for an additional year as they needed someone familiar with the product and physically close to our data center while they transitioned everything off-site. I've now been at my current job - another small startup - for 11 years, the longest I've ever been at any company. There's no plan for any acquisition (that I'm aware of), and as far as I'm concerned, I'm ready to stay for another decade or so. The current plan is to retire at 55 although I suspect I'll get more flexible the closer to that I get. I *do* spend a lot of time thinking about the poor sucker who's gonna have to maintain my code, and that's me, so I try to avoid being too clever for my own good. Even though it's harder to stay at the same job in this fast-paced industry, this is something that must run in the family - my dad retired from his job after 41 years at the same employer.
-
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, notThat's odd - all this time and I didn't know you worked here! Right down to the insurance industry reference. How I manage this? By knowing as little as possible about how the company does business. Applications are written so abstractly that don't care and thus, when they once again change their minds, it absorbs it into its not-caring arms. The payback for them is that things get done amazingly quickly. For me - it makes me feel artistic when I can create something so agnostic about how it is applied. Leaving floats in and out of my consciousness. Raises are very few and far between. I can retire whenever I wish. And - there's not even anyone close to a backup. Lesson? Not intending to be political, but this is amongst the failings of capitalism: a short-term outlook. Now that's not actually the fault of that economic system, but add into the mix that it's people making the decision and in a hurry to quickly line their pockets and you have a recipe for frustration and failure. I don't think the outcome would be any better under socialism; the route changed, perhaps, but the destination (for us of the working class) is always the same. Basically, "it's a paycheck" mentality. Bottom line (literally and figuratively) - don't kick yourself - it was done far more to you then you did it to yourself.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
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.
Hmm. I'm 57, and have been at my current job for 28 years.
Mike Mullikin wrote:
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.
That's very similar to our marketplace (commercial ink-jet printers). I am still actively maintaining products that were begun in the late 90's.
Software Zen:
delete this; -
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:
But then I get back to smacking myself -- I know better. I should have taken the initiative to request code reviews. I should have utilized this really smart person's knowledge and skill better.
Probably no call for you to smack yourself. After all, would they have actually had time to do that? If they're any good, their dance card is probably already overflowing.
I live in Oregon, and I'm an engineer.
-
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, notIt really doesn't matter, companies always find a way with their business...or fold... or outsource the work to some other company that has the developers to handle such stuff.Or even throw it away.
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
-
That's odd - all this time and I didn't know you worked here! Right down to the insurance industry reference. How I manage this? By knowing as little as possible about how the company does business. Applications are written so abstractly that don't care and thus, when they once again change their minds, it absorbs it into its not-caring arms. The payback for them is that things get done amazingly quickly. For me - it makes me feel artistic when I can create something so agnostic about how it is applied. Leaving floats in and out of my consciousness. Raises are very few and far between. I can retire whenever I wish. And - there's not even anyone close to a backup. Lesson? Not intending to be political, but this is amongst the failings of capitalism: a short-term outlook. Now that's not actually the fault of that economic system, but add into the mix that it's people making the decision and in a hurry to quickly line their pockets and you have a recipe for frustration and failure. I don't think the outcome would be any better under socialism; the route changed, perhaps, but the destination (for us of the working class) is always the same. Basically, "it's a paycheck" mentality. Bottom line (literally and figuratively) - don't kick yourself - it was done far more to you then you did it to yourself.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
W∴ Balboos wrote:
Raises are very few and far between
I was less than amused to hear that no bonuses were being given out to employees in 2017, yet, there in a public record filing, is a $1.3M bonus for the CEO. Riiiight.
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
-
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 :laugh: and :laugh: and :laugh: I tried for over a decade to get the bank to use a decent bug tracking system, I still get a bug list via excel! I did manage to get them to use TFS if only in a rudimentary fashion. I never did get a testing framework implemented nor code reviews all of these detracted from code production which was the ONLY focus of management. They finally stopped extending my contract (thank Ghu) and I truly do not give a shit. I don't believe it is the job of a senior developer to try and change the management teams priorities. Enjoy your new job!
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
I :laugh: and :laugh: and :laugh: I tried for over a decade to get the bank to use a decent bug tracking system, I still get a bug list via excel! I did manage to get them to use TFS if only in a rudimentary fashion. I never did get a testing framework implemented nor code reviews all of these detracted from code production which was the ONLY focus of management. They finally stopped extending my contract (thank Ghu) and I truly do not give a shit. I don't believe it is the job of a senior developer to try and change the management teams priorities. Enjoy your new job!
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
Mycroft Holmes wrote:
I don't believe it is the job of a senior developer to try and change the management teams priorities.
And yet they would ask me for suggestions on improving processes. All of which was shot down, and of course I'm wise and jaded enough to know that whenever I hear management say "we want to hear from YOU!" that it's really only a way for them to find out who the boat rockers and dissenters are.
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
-
W∴ Balboos wrote:
Raises are very few and far between
I was less than amused to hear that no bonuses were being given out to employees in 2017, yet, there in a public record filing, is a $1.3M bonus for the CEO. Riiiight.
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
Hear I dance at the edge of the Soapbox: for all the big corportate tax break, very few regular employees saw any of it. Sure - a few big "news" items, like higher minimums at a few places (like Amazon) but that money, as usual, didn't trickle down. I only dare post this here as I'm not blaming either party for what corporate "leader" do: business as usual.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
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 -
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, notJust accept it as part of life and work. One could always strive for perfection, but there's always other people and lack of time coming in the way. Reading your post and previous posts I can say that in my opinion you've done more than what could/should be expected.
Wrong is evil and must be defeated. - Jeff Ello
-
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 -
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
