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, 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 -
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
