|
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;
|
|
|
|
|
|
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
|
|
|
|
|
Youtube blocked! O.M.E.G
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
The art of telling managers what to do, difficult is. Much pain in your future I see.
modified 20-Oct-19 21:02pm.
|
|
|
|
|