|
Thanks 
Full Reset
|
|
|
|
|
Full Reset
|
|
|
|
|
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: Cleanup comments 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.  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 C# development.) In hindsight, I wish I'd set up monthly code reviews with her. At least monthly. She knows the craziness of the processes that generate the XML (which has its own warts that would send you screaming out of the building) and has honed in on the warts that are the result of numerous refactorings instead of rewrites during this development process.
But on the gripping hand, I'm also pissed off. Management promotes a very silo-based development environment -- people work on their own thing and there's no collaboration. There's no training to bring juniors up to more senior levels. There's no concept of code reviews -- see my posts in the weird and wonderful. The way source control is used, it's only there to separate development, quality, and production code -- no branching, no pull requests where someone reviews your commits, etc.
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. Heck, I should have done better to begin with.
As to why I didn't, I would have to say that my disappointment in management, practices, and processes, which sounded great during the interview, created the psychological "I don't really give a sh*t" mood -- promoted by the punch clock mentality of management (yes, for salaried employees), lack of flexibility, and that everyone has been browbeaten into this mentality -- how many times have I heard "it's a paycheck?" from my coworkers? And besides, I truly have no passion for the insurance industry.
If there's a lesson to be learned here, the main one is, I shouldn't have allowed myself to get into that "I don't give a sh*t" mentality, nor should I have let my lack of passion for this industry to get in the way of doing a good job. I failed. I should have left the company early (I almost did, 2 weeks in as a contractor, but I needed that damn paycheck) or I should have been "professional" about my work irrespective of the crappy management style, tools, equipment, and work environment.
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
|
|
|
|
|
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
|
|
|
|
|
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.
modified 20-Nov-18 8:50am.
|
|
|
|
|
raddevus wrote: Everything placed under a microscope looks so different than when people just look at it normally.
Not just different but unrecognizable! 
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
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
|
|
|
|
|
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. 
if (Object.DividedByZero == true) { Universe.Implode(); }
|
|
|
|
|
That was my take-away from the whole thing, hadn't experienced the full force of Business Analysts before then.
|
|
|
|
|
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
|
|
|
|
|
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 sh*t 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.
|
|
|
|
|
I would kill for a forever job like that as long as the projects varied enough to keep it interesting.
if (Object.DividedByZero == true) { Universe.Implode(); }
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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;
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
