- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
TRWTF is VSS
Admin
It should be pretty easy, right? The client requests a feature, you make it happen, client is happy. It's more difficult to make excuses why it's not delivered, isn't it?
Admin
A soul-destroyer, this.
I worked as technical design authority on a project for three years, battling away at ensuring design quality, defending my decisions and doing what was by all accounts a pretty good job. Then the management structure was reconfigured so that an entirely new team was brought on board, which meant a completely new infrastructure and design suite was introduced, so they scrapped everything they'd done and decided to redesign everything from scratch.
I walked before I was pushed.
Admin
Ze whole purpose of ze Doomsday Maschine is lost if you keep it a secret. Why didn't you tell ze world about it, eh?
--Peter Sellers, Dr. Strangelove.
Admin
The nice part about Anita's work never hitting QA, staging, or production, is that she never had to work a single bug report on her own code.
The absence of such bug reports over 6 years should have given her a clue that her stuff was being rat-holed for reasons fair, foul, or stupid. Not that she should have greatly minded - all the unpaid overtime in the prior WTF episode and in my own career has been related to bug burndown to meet a time/quality gate. If you have no identified defects you have no time crunch. Hooray for small favors, even if they come from a dumb place.
Admin
It does seem like maybe if she had have done some of that looking into sooner, she might still be employed there.
Admin
6 years with no bug reports, no complaints, nobody breathing down your neck to get things done or fix things yesterday and just generally no noting? Can anyone give me a referral for that job?
Admin
Since she brought it up in the first place, I think it did.
Admin
I've seen this before. This isn't about the software she worked on. Her manager was keeping her around so that when the headcount cuts came to that department, it would be easy to meet the required reduction. Shareholders and Senior management are happy that they met their headcount reduction goals. Her manager is happy that he saved his own job at a reasonable cost (ie: her salary over the years). She should be happy that she got paid for years, encountered little/none of the usual job hassle we see on this site, and she learned a lot which lead to a new/better position elsewhere. Win-win-win.
Admin
It sure is nice, but could be a dangerous trap if you enjoy it too much - it might be difficult to re-learn working in a normal place, and by reimplementing everything you miss out on open-source knowledge.
On the other hand - that's YEARS of stable employment, you're learning a lot of low-level skills at work reimplementing difficult wheels due to the no-OS policy, and you have zero overtime due to lack of bug reports - which means lots of time for own projects, open source participation and learning, learning, learning.
You could really advance your career with this kind of stable support. Used wisely, this job is GREAT for up to maybe 3 years.
Admin
The issue with working in a low stress/expectations job is you have to have the experience/perspective to realize it. My first 5 years as a SW developer were spent that way, but I was too inexperienced to use the lax environment to push myself, instead becoming incredibly complacent.
Admin
This one hits a little too close to home. My employer's new flagship product has been in development for a long time, and they'll be getting a pilot customer on it any day now - just as soon as QA can successfully complete a test run of the core functionality, which they've been trying to do for almost the whole two years I've been with the company. So for all the money they're paying me and my teammates, they're not getting a whole lot of return on that investment. I wouldn't be surprised if they get to the point of having to decide between killing this beast or getting devoured by it.
Admin
My current client, 10 years developing version 2 of their bread and butter software. It needs 32GB RAM in non-prod to run. The database is a mess. It fails every 2 weeks without fail. $15M+ spent developing it. Mixture of full time developers, US consultants and developers in China of all places. They finally moved 1 customer to it, out of 500. Oh and the previous version got no improvements over the years, save for a bug fix here and there. We're at a point where between friendly colleagues, we're seriously questioning the long term viability of the company.
Admin
This is a pattern I have seen more then once. A company has a successful but outdated product. They launch a big project to update the product, which fails. The original product then falls further out of date. This takes even bigger projects to replace it with something current. Leading to a cycle of bigger and bigger failed projects. These big projects lead to multiple internal reorganizations. After this happens a couple of times there are a some small groups in the company that are not really doing anything. They sign off on various projects from time to time but they are reports that nobody looks at, utility programs that nobody runs, maintaining data that nothing reads and dashboards that no user can log in to. Managers keep them around for a couple of reasons. They may be sacrifices for later reorganizations, the manager may not realize how insignificant what they do is or they may be kept so the manager can show completed projects of some sort.
Admin
I call bees. Six years building ships that never sailed and she finds another job in three weeks? From where I sit that would be the end of a career, regardless of circumstances.
Admin
How is she responsible for what management ships? This is actually pretty common in a lot of industries. Even if you think that you are working on something important, it could get killed the next day. That doesn’t mean that the engineers working on those projects did anything wrong.
Admin
HTF can anyone NOT know that NONE of their projects never make it into Production (over the course of 6 years!!!). Ridiculously contrived story.
Admin
How does it matter? Decisions were made and acted on at a previous employer. Who was responsible? Let's look around to see if the previous employer is represented here by anyone. Ah, yes: the candidate. Must have been them. They didn't ship, they didn't use libraries. Next.
Admin
What is this "normal place" whereof you speak?
Admin
You misread. She knew very well that none of her projects made it into production (or even to QA for that matter). The article mentions pretty clearly that she brought it up with her manager regularly and only ever got back ho-hum answers. The declaration at the end is merely the exclamation point on her frustration that she provided no value to the company, during which time she could have been helping out on the flagship product or something else to provide real value (which may or may not have been the difference between the company sinking or swimming - for want of a nail...). Meanwhile, her manager who was keeping her busy working on random projects also knew full well that nothing that she worked on was actually going to be used by anyone. I'll refer to the other comments which covered the possible explanations and motivations in this realm.
Meanwhile, in response to Duke of New York: I think the interview process you describe speaks pretty well about the sort of organization and the quality of engineering staff involved. You describe an organization that is looking for engineers who can satisfy metrics and checklists; and I guess if that's all you're looking for then the candidate really isn't missing out on anything by skipping that offering for the next one that's willing to dig a little deeper to understand the candidate's actual technical competence, problem solving, creativity, work ethic, etc.
Admin
Surely trwtf is staying 6 years when a job at double the pay took 3 weeks to find.
Admin
Enterprisy software isn't like games, there's no credit screen at the end you can point to and say see I worked on that. You have your resume, your references and however well you interview.
Admin
I think it's contrived too, at least the way it's portrayed. My guess is she wasn't that good on the first project, but couldn't be fired immediately for whatever reason, so they transferred her to the sales/marketing/termination doorstep and had her digging holes and filling them back up until enough time passed and they had valid "cause" for termination (i.e. the department wasn't producing valuable work), probably hoping she would voluntarily quit in the meantime. Affordable to do for three reasons: 1) as evidence by the story, she started making twice the salary after she left, 2) she's valuable for meeting equal employment quotas while there, 3) they apparently avoided a lawsuit. Like I said, this is my guess, based on how tragically perfect the protagonist was in the story (and how perfectly tragic the antagonist was).
Admin
Given she doubled her salary at the next gig, that would probably not have been a good thing.
Admin
My thoughts exactly.
Admin
How is it relevant whether the software they worked on shipped?
There are a lot of reasons why a business would choose to spend resources on software that ends up getting thrown away later.
Admin
She shook her head in resignation? Sounds more like shaking her head in being laid off.
Admin
Very much this.
Admin
It's relevant because employers choose among developers who shipped code or didn't, not who has a better excuse for not shipping. The programming job market is not merciful.
Admin
I'm now workingin a company with the same NuGet policy. Everything has to be made from scratch, as the lead Dev doesn't trust external dependencies (expect when made by Microsoft). The difference is that we are releasing our software. So we spend a lot of time fixing typical bugs in production...
Admin
Given two otherwise identical candidates, sure, I would also consider that, but in practice I don’t think that happens much… Maybe it’s just my field, but I would not care at all about how much of a candidate’s code shipped. I would ask them technical questions, give them a programming test, and talk to them to find out how they would fit in the team and make a decision based on that.
Admin
Yeah, I don't know where you are, but around here, developers choose among employers, not the other way around. If you're doing internal projects, who exactly is going to say if something shipped or not? It may be hard and painful, but look at your own situation and think about whether it's actually working for you, because I sense a great deal of justification of maltreatment and exploitation. Your employer is only your employer, you don't have to give him/her control of your life in service of a release date.
Admin
I don’t know where you are either. I questioned the story because my experience of moving on from a dysfunctional organization is being turned away by employers large and small because I don’t have the kind of project stories that they want to hear: used the latest stack. insisted on best practices. did the right technical thing, always. most importantly: a reliable record of shipping projects. The polar opposite of the stories on this site. Someone who has these stories to tell has a solid advantage over someone who has to spin, and someone who has to spin six years is hoping for charity.