Another LONG Work Rant (N/A, for those who might otherwise think it's somehow aviation related)

Gerhardt

Gerhardt

En-Route
Joined
Aug 20, 2006
Messages
4,534
Display Name
Display name:
Gerhardt
I like my job, I do. Actually, I love it. But that's not to say that there aren't days we do things so stupidly I wonder how we stay in business. A few examples.

1. We have someone contracted with us who, in a period of 3 years, lost us $2M, in addition to the amount we paid her. She lies and cheats constantly, yet we keep the contract in place. I started keeping track of and reporting her misdeeds a few years ago but stopped at the end of last year. My boss asked about it. "If she's still on the payroll in 2016 we deserve everything we get." He thought about it and I think silently concurred.

2. I've reported a number of IT system problems, and the number is growing at an increasing rate. I was asked last week to stop because they already have a backlog of over 300 major problems reported and they're struggling to prioritize them and don't want the burden of adding more to be prioritized. We are not an IT organization, but our IT department is the largest in our company.

3. Last week I received a call from someone trying to submit an order, but was unable to do so. I reported the problem to the support center (Help Desk) and received a return call from them this morning. She said a business analyst told her that I should be able to help the person. "If I could help him, I would have. The system won't let the order go through. Can you send me a copy of the email Mary (the bus. anal) sent you?"

"No, they've asked us to keep those confidential."

"Ah, national security. So what's this magic I'm supposed to work to get the system to place the order?"

"uhh..." *don't tell anyone, but she forwarded the email to me on the sly*

I emailed the bus. anal. "Can you contact the customer and assist him in getting the order placed because I am unable to get it to go through?"

Two hours later I received an email reply. "I didn't realize that is for an order not yet placed. Please contact the customer and have them create a new account and let's hope that works."

WTF. She wasn't even paying attention.


But somehow we thrive. Last year was our best year ever, I think around $1.3B. Maybe I'm wrong, but I think the larger you are the more things like this can happen. It certainly couldn't happen with a smaller company and the place survive.
 
To hijack your thread with my own tale. I work for a big red beverage company and recently they decided to get all frontline sales and merchandising employees the newest galaxy note to replace our blackberries. So we are all called into the plant given some corporate speak about how they love us and want us to have the best tools, productivity, synergy, best practices, work life balance, zzzzzzz. So anyway we get our new 700+ dollar notes. Yay! hmmm it appears to be locked down you cant even access the clock app, you can't even pull down the notification shade to read text or clear them. You can only use Contacts, verizons text message app, our corporate app and google maps. We can't even open excel, docs, or view pictures in email. I can't even use my phone to send pictures of displays cause I can't use the camera app. I use this 700 dollar phone to clock in and then it sits in my glovebox till I clock out.

To borrow the white girl phrase "I can't even...."

Though this is the same company, that in the land of iPads, gave sales guys laptops with 512 mb of ram that would crash if you used their program to connect to get your sales and account info cause it would run out of memory. Corporate IT rode with one of my account managers and asked why he wasn't using it. My guy told him it would take to long to connect and it would be quicker to run home and use his desktop. IT didn't believe him and tried all through lunch to get it to work before begrudgingly admitting it was perhaps limited by the hardware. Now we get some huge low res laptop with a touchscreen that requires a pen. All we've ever wanted is an iPad mini like pepsico.... No one listens to frontline employees.
 
I feel bad for the folks that have to use the crap companies call "IT". We're about to knock 20% of the speed and responsiveness off of all of our company Windows machines to turn on a feature for "security" that the business unit that signed the contract that requires this company-wide change, didn't factor into their budget nor the pricing for this new large customer. Their answer when we told them the machines won't keep up and everyone will hate it, "Let's give it a try anyway..."

In other words, most of my "customers" will have a significantly worse experience with my "product" through the business decisions of one business unit.

When the business unit that started this also told us a different business unit (software development) wasn't exempt according to the new customer's rules, and that software builds might take DOUBLE the amount of time as before, they essentially shrugged and didn't care. They got their new contract.

I suspect the other business units will find a way to charge back bigger hardware to handle the stupidity and they won't have made a business deal that got them even one red cent in more profit after all this is done. And their own staff will HATE their desktop machines soon enough.

^^ This... Is why I'm taking time off starting in May to get all my flight ratings. I may go broke flying and teaching part time, but purposefully designing things to suck, isn't why I got into the IT biz. We'll see if they figure it out before they cause a mass exodus of employees who WILL talk about their bad experiences... "That place only buys computers that take ten minutes to boot..." I've seen this before.
 
I could post a long email from 'Managerman who works far away' from this morning as to why our main production system doesn't do what it is supposed to do.

For maybe two years we are going through cycles of 'we are going to upgrade the servers and that will fix the problems' and 'we are going to upgrade the workstations and that will fix the problems', but neither action does.

Nobody ever seems to grasp the obvious: That we are working on a legacy system that hasn't changed in 10 years.
 
man... i love my job... lol

I left a place that was absolutely horrible.... far worse than any of your stories above.. this is a place that sent 2 people to buy an 89 dollar parts washer, because the maintenance man that was there for 3 years couldnt be trusted with the credit card....oh and then... the skinny "accountant" wasnt authorized to by the solvent... so guess what... they got a new parts washer and for 4 months havent used it because they have no cleaner. LMAO... oh this is only the beginning...


my new job.. man.. first week in the boss gave me 3 grand and told me to build the computer I needed ( im a designer/cam programmer) and thats just and example of the total opposite way of thinking. they trusted me , and I spent their money as effectively as i could..

now about that contract IT guy... well... hes a nice fellow.
 
Are you sure that these problems wouldn't exist even if someone else were in her position? I've worked for companies that refuse to change because "that's how we've always done it" or some BS political reasons. Several people have tried to change things at these companies to no avail.
 
Stories like this are why I have a job.
 
New manager guy asks in a meeting, "What has [name of company] done right to survive since the 1970s?" Front line employee who has been there for 25+ years answers, "We have survived in spite of ourselves."
 
Everskyward said:
New manager guy asks in a meeting, "What has [name of company] done right to survive since the 1970s?" Front line employee who has been there for 25+ years answers, "We have survived in spite of ourselves."
Click to expand...

Hahaha. That's so often true.
 
Given the description of things it sounds like you work for a very large company, that has been around for quite a long while, and is probably in a rather regulated space. With that in mind -- all I can really say is that you wouldn't believe how complex of a mess the "IT" problems are to resolve. Making any change requires semi loads of red tape, stamps, and pens for signatures.

That's not an excuse, but it's just the reality of what you have to expect when you work for companies that fit my initial description. There are some exceptions but they're rare. That's why I like working for new companies. Much easier to do things right from scratch then try to fix 50+ years of someone else's incompetent decisions.
 
It's amazing how money hides inefficiencies. And often it's either HR policies/processes or the manager's desire to maintain headcount (never to be replaced if the resource leaves) that causes tolerance for ineffective resources. When a company is profitable, it's easy to throw money at these problems. When a company is struggling for every dollar... different story.

Regarding FalconKidding's tale of the Galaxy smartphones... I think you're seeing the "mobile device management' implementation. You can blame your security team for that (which sometimes is in IT, sometimes not.) It's amazing how they want to control devices and ensure that they have the ability to remote wipe and track your smartphone. It's for this reason I've gone to carrying two phones - my personal phone, and my company phone that rarely (if ever) gets used for phone calls, and is used to for reviewing emails only. I made the proposal at my workplace to virtualize all desktops and go agnostic on device (basically open a corporate Windows desktop on any PC (Apple, Windows, Linux, whatever) or smart phone or tablet to control the environment but maintain security via two-factor authentication. I was shot down for arcane reasons... most of which were posed by Security who feared for a reduction in their span of control and team size.

The closer I get to retirement age (note "age", not that I'm financially ready for retirement) the more I realize how accurate Dilbert really is.
 
rtk11 said:
The closer I get to retirement age (note "age", not that I'm financially ready for retirement) the more I realize how accurate Dilbert really is.
Click to expand...

Dilbert always has been a documentary, not just a cartoon. And it's no surprise at all that Scott Adams was inspired to first create it when he worked in the ISDN engineering group at PacBell.
 
bflynn said:
Stories like this are why I have a job.
Click to expand...

Same here. Much of my job is picking up where other contractors have dropped the ball. Sometimes not just dropped the ball, but having dropped the ball, proceeded to stab it repeatedly with a large knife to make it nearly impossible to inflate... I currently work for a small company, but have observed all of the above behaviors, and more, at large companies I've worked for. I will never work for a large company again.

To those who think it is even worse in government - no, it is about the same. Keep in mind that many of the onerous government policies now in place exist largely because of lessons learned from the government getting screwed over by companies, both large and small, in the past. Just like pilots continuing to think up novel ways of screwing things up, companies keep coming up with novel ways (some likely intentional, some not) of screwing up.
 
Jeff Oslick said:
Office Space is a documentary as well.
Click to expand...

I've actually had the conversation with "The Bobs". And yeah, multiple places had banners similar to the "Is it good for the company?" one in that movie.

The only thing they didn't harp on enough was that nerevenending BS about how we're all a "big family".

I tell ya what, if anyone in my family ever put someone out of a job three weeks before Christmas so they could maintain their six figure salary and make $3M in cash in three years by destroying their lives, we'd get all the cousins together and physically beat their ass.

Which is probably the kind of thing that makes me want to release my inner Alice when some of the places I've worked made us sit through mandatory meetings to listen to that depraved crap presented by a guy who just cashed out $1.2M in stock options *per quarter* for two years into his "Foundation" for his kids and is finishing the speeches with "work smarter, not harder, we love you all, we really do!"

Of course when same guy is escorted from Corp HQ for embezzlement and the standard announcement that he's leaving to "spend more time with family" hits the email, we all aren't too surprised.

I think I'll stick at the small place I'm at now for as long as they'll have me. No retarded "family" talk. We go to work, do stuff to make a profit, and go home. Once in a while we have cake or pizza. Once a year we have a day where everyone goofs off with silly games and they BBQ. Way better than the HR-approved events at the big shops.

Moo. I'm a "Human Resource".
 
All software sucks. Some not as much, but it all sucks. That's just the state of the art.
 
Sundancer said:
All software sucks. Some not as much, but it all sucks. That's just the state of the art.
Click to expand...

They tell me that it's not art, though. Their title even says "software engineer". Hehehe.

I've never seen an engineer do less empirical measurements or know exactly what they're going to use to build something in my life, as a "software engineer" does. Even in the largest most organized shops, the documentation level of most "engineered" software is abysmal.

The standard answer for "How is this supposed to work" outside of a very few software disciplines is, "I don't remember. Let me look at the code." Not even, "Let me get out the specs and the blueprints and see what it was supposed to do."
 
I'd hate to see how some of you would deal with working on an aircraft out on a ramp at night during freezing rain and high winds. Life in cube farms is a piece of cake.
 
SkyDog58 said:
I'd hate to see how some of you would deal with working on an aircraft out on a ramp at night during freezing rain and high winds. Life in cube farms is a piece of cake.
Click to expand...

BTDT worked the ramp for Continental in the early 90s. Hated the MD-80, loved pushing the A300 out and blocking the aisle for United, hardly ever used my travel bennies. Snow suit was the only way to go home dry when they were deicing on the gates. Strip it off and roll it up inside out to not get deicing fluid all over everything in the car. Peoples bags? They usually didn't fare so well on those nights. Always go steal the fast tug from whatever gate the day shift left it parked at. Never go anywhere near the break room on a bad weather night when short staffed. Guaranteed way to get assigned more flights. Hide somewhere else between flights or look busy. Fuel the tug or the beltloader, anything.
 
denverpilot said:
They tell me that it's not art, though. Their title even says "software engineer". Hehehe.

I've never seen an engineer do less empirical measurements or know exactly what they're going to use to build something in my life, as a "software engineer" does. Even in the largest most organized shops, the documentation level of most "engineered" software is abysmal.

The standard answer for "How is this supposed to work" outside of a very few software disciplines is, "I don't remember. Let me look at the code." Not even, "Let me get out the specs and the blueprints and see what it was supposed to do."
Click to expand...
Been doing it and managing it for decades, and calling it "engineering" is a vanity. Ratting out my own tribe, but it's true. More discipline has been brought to it, but the platforms and tools are still mickey-mouse, and the hidden costs of half-assed implementations are seldom admitted. Yeah, the new whiz-bang ERP is up and running! Yay us! And massive work falls onto the end-users to deal with the bad business decisions, non-intuitive interfaces, and poor alignment with real-world business. Cloud? Just another place to host the same crud solutions, albeit more efficiently. But still the same operating systems, same apps, same dev environments. We'll be able to save a few bucks visible in the IT budget, for sure. Won't matter a whit to the user community.
 
Sundancer said:
Been doing it and managing it for decades, and calling it "engineering" is a vanity. Ratting out my own tribe, but it's true. More discipline has been brought to it, but the platforms and tools are still mickey-mouse, and the hidden costs of half-assed implementations are seldom admitted.
Click to expand...

I create both software and hardware. It's not that software has worse tools, or is less of an engineering discipline than anything else.

People go all ooh and aah over how well hardware design is documented as opposed to software. Because when somebody on an assembly line screws up and uses a wrong component, you can refer them to the schematic and compare against that. And since problems with hardware are generally 99% manufacturing error, the process seems to works - and seems well documented. And in the 1% case that I've screwed up something on a schematic, I fix that, people snicker a bit and move on. But otherwise, drool... documentation works! Need more of this stuff!

Software on the other hand has virtually 0% manufacturing error, so ALL of the defect opportunity lies over on the design side. So people are quick to judge software design with not having the same kind of discipline than hardware design and not having the same level of "documentation" in the same way hardware have schematics.

But the code IS the schematic. There isn't some magical better model that describes the product better than the code, even though managers love to thrust ones down coders throat sometimes. In hardware design there isn't something at a higher level than the schematic either, but people seem ok with that. (Yeah, you have requirements specs and interconnects and so on, but you have that in software design as well).

So why doesn't the software design process work as well as the hardware design process? It's simply because software is orders of magnitude more complex. For hardware I may have to make about a 500 correct decisions on a board, and I can pretty much keep them all in my head. For software, I often own over a million lines of code and I can memorize maybe 10'000 lines of that at a time before I have to go back and re-read stuff.

If you ask a structural engineer to build a bridge that has 500'000 individual onramps that all work differently, he's going to make mistakes as well.

The stuff is just nowhere near the same level of complexity. The only reason that the software design process works at ALL is because mistakes are relatively harmless and cheap to fix.
 
Well said, great points; I'm thinking more about at the higher level of abstraction, at the business process level, where the big picture design doesn't match the real world of work. Not that business software is terribly buggy, but more that it's been implemented such that it fails to serve the need, doesn't advance the cause. So, so often missing that clarity of vision needed to do
"do it right".
 
There's a lot of "developer assumptions" in this that don't hold up in the real world.

deonb said:
I create both software and hardware. It's not that software has worse tools, or is less of an engineering discipline than anything else.
Click to expand...

Wrong. Other engineering disciplines have dedicated design and build documentation systems that -- and here's the kicker -- ANYONE can read. Blueprints and text descriptions.

deonb said:
People go all ooh and aah over how well hardware design is documented as opposed to software. Because when somebody on an assembly line screws up and uses a wrong component, you can refer them to the schematic and compare against that. And since problems with hardware are generally 99% manufacturing error, the process seems to works - and seems well documented. And in the 1% case that I've screwed up something on a schematic, I fix that, people snicker a bit and move on. But otherwise, drool... documentation works! Need more of this stuff!
Click to expand...

And software coders do not take the time to write anything they can refer others to, most of the time. Why? We see it below...

deonb said:
Software on the other hand has virtually 0% manufacturing error, so ALL of the defect opportunity lies over on the design side. So people are quick to judge software design with not having the same kind of discipline than hardware design and not having the same level of "documentation" in the same way hardware have schematics.

But the code IS the schematic. There isn't some magical better model that describes the product better than the code, even though managers love to thrust ones down coders throat sometimes. In hardware design there isn't something at a higher level than the schematic either, but people seem ok with that. (Yeah, you have requirements specs and interconnects and so on, but you have that in software design as well).
Click to expand...

Because coders can read code. They assume everyone else can, which is ridiculous. Their job is to take a text description and a design and make that INTO code, not point at code they write and say, "Just because you business people can't read it, doesn't mean it's not documented. Just read what we wrote!" Totally ridiculous, but more importantly for this discussion: NOT ENGINEERED.

deonb said:
So why doesn't the software design process work as well as the hardware design process? It's simply because software is orders of magnitude more complex. For hardware I may have to make about a 500 correct decisions on a board, and I can pretty much keep them all in my head. For software, I often own over a million lines of code and I can memorize maybe 10'000 lines of that at a time before I have to go back and re-read stuff.
Click to expand...

Software often does NOT need to be that complex. But the ridiculous number of languages and methods to simply handle a string conversion, for example, shows a lack of discipline and a selfishness that is created by the never-ending churn of languages and even methods inside those languages. How many libraries does one need to parse say, an HTML POST string? There's thousands. And the coder will still write their own, and maybe even shove it out onto Github as the "next great thing". Evidence has been that code reuse simply doesn't happen. Which also kills reproducibility in quality of final product, and standardization.


deonb said:
If you ask a structural engineer to build a bridge that has 500'000 individual onramps that all work differently, he's going to make mistakes as well.
Click to expand...

You've hit the same reason I've given above. There's no professional need for the on-ramps to behave differently at all. The issue is, it's not ENGINEERING where someone says, "This is the standard on-ramp..." nor does software coding lend itself to needing a standard. Why? In the analogy of on-ramps, if they fail, people expect them not to. Using standard ones and inspectors making sure they're standard creates a much better chance of not failing than your "multiple types of on-ramp" scenario.

But... people EXPECT computers to fail. Nobody expects their computers to run right anymore. They don't even know what a non-buggy and non-annoying computer system looks like anymore.

deonb said:
The stuff is just nowhere near the same level of complexity. The only reason that the software design process works at ALL is because mistakes are relatively harmless and cheap to fix.
Click to expand...

An engineering staff's job is to REMOVE complexity and build to a standard.

But without a commercial impetus to drive higher quality, it'll never happen. The industry is headed the other direction -- rental software and "continuous improvement". But there's no actual objective measurement of whether or not "improvement" is happening, nor is there any penalty for not improving. The user is still going to pay their monthly rental bill.

The items you said are true, but that also means it's not engineering. There's nobody holding code and results to a standard or even holding it to a monetary goal of making or saving the organization money with each "continuous improvement" release. Sometimes now literally pushing changes to production within minutes of uploading to a code repository.

By the way, the idea that there's no "manufacturing errors" from code is also ridiculous. Projects that use frameworks often build or run the real time interpreter against the wrong versions of those frameworks in various environments, or allow development to be done on newer libraries and frameworks than production can afford to run on. Entire projects to simply build and set up the right environment are well entrenched in the sysadmin world these days. Ansible, Chef, etc.

Writing the code to create even a consistent environment in the shifting sand of software is a whole discipline that was ignored for most of my career except by solid sysadmins who wrote scripts to do it. Now it's the realm of "DevOps".

Most coders want nothing to do with details like "the OpenSSL library has a big security hole in it". That's left up to sysadmins and systems engineers to design around and fix for them. There's 50-100 patches to even the most stripped down OS per month at this point.

Claiming that those patches are "cheap and easy" flat disregards the cost of creating a way to introduce those to every environment from Dev to Production. And it's caused by hundreds of teams with that same assumption... "oh my one little change is quick and easy and cheap to distribute"... until a hundred teams do that and they all affect a well planned system.

Time is the most valuable commodity on Earth. Wasting it with a hundred patches a month shows how little effort is made to get things closer to "right" up front.
 
Acrodustertoo said:
I see we have a nerd fight brewing !!!
Click to expand...

LOL. Not really. Devs breaking stuff with all their "it's an easy change, just read the code for the documentation" keeps me pretty well paid. But I don't pretend I'd have a very interesting job if I didn't have to figure out how all those "innocuous" little changes would threaten a multi-million dollar system that nobody wrote any docs or blueprints to build it from.

Doesn't bother me at all waking up a Dev to fix their bad assumptions at 2AM with a hotfix. LOL. Or rolling their mess back and saying "try again next week". :)
 
denverpilot said:
LOL. Not really. Devs breaking stuff with all their "it's an easy change, just read the code for the documentation" keeps me pretty well paid. But I don't pretend I'd have a very interesting job if I didn't have to figure out how all those "innocuous" little changes would threaten a multi-million dollar system that nobody wrote any docs or blueprints to build it from.

Doesn't bother me at all waking up a Dev to fix their bad assumptions at 2AM with a hotfix. LOL. Or rolling their mess back and saying "try again next week". :)
Click to expand...
My father retired with IBM, my whole life he has talked about work and my mother and I have not understood one word of it. Ha ha ha. These threads about this fancy dancy computer thingamajiggys always remind me of him and his buddies sitting around spewing all that jargon.
This must be what it is like when we talk airplanes to the common folk?
 
As a end user of software that has more then $40,000 invested into it... I fully agree with denverpilot. and i want to slap the developers sometimes. Dessault systems is notoriously bad at releasing buggy CRAP. The software works, but its full of nuisances. and what really ****es off the end users (ie, the people giving them millions of dollars every year) is that every year they come out with more and more and more useless features with out fixing the underlying engine that drives it all. Loh and a bug fix request? HAHA.. forget about it. I have had one in since 2014 that has affected over 2000 users and it still to this day is not fixed, and wont be. Thats what really erks my nerves. Im paying you at a minimum 6k per year for this software, at least answer the damn bug request. if you cant fix it, then fine....say so.

That said. UML is supposed to be the blue print, but not everyone does it, or does it fully.
 
@denverpilot

Very well written opinion.

Many decades ago, I worked on big waterfall-based overmanaged COBOL-esk projects that were meticulously documented to the tee. Nobody would read the documentation because it's just too much - a simple input form would have 100's of pages of documentation. At the end it's just a burden for the developers to update, and because of the process it would take 3 months to do a simple form update which would be done today in a few hours. And in the end the quality isn't any better than it is today - it just took longer to make a chance.

And I've also worked on extremely high quality codebases. The kind with the $1b/year budget. Some of the codepaths in there that are pretty much as perfect as you can ever get - hardware outfails the software by many many orders of magnitude. But there's no magical process or documentation that caused this. It's money, money, and more money. Money to spend money on high quality developers & testers, and time given to them to do things correctly. But you don't get implementation documentation by itself, because it's not something a developer needs to get his job done. For him the code is the documentation.

Ok, granted not everybody can read code, but if I give you the schematic of oh, let's say, an FPGA-based Layer 4 Load Balancer. If you're not trained in reading schematics, you won't be able to read that anymore than you can read code. And there isn't anything higher - sure there are functional specifications, input/output specifications, operating specifications etc. but very seldom would you see a higher layer implementation specification unless that specification forms part of what you're selling.

So if you want implementation documentation, write a check for it. But nobody ever does anymore.

PS: I've never in my career heard a software engineer utter the words: "This is ready to ship". Shipping happens because management is trying to beat someone to the market, not because the product is ready for it. Every single process in place today, like Scrum/Agile/Six Sigma is just a way to get stuff out of developers that are not ready to ship. That's just the reality of the world we live in where end users complain about the price difference between a $2 and $1 app.
 
JC565 said:
That said. UML is supposed to be the blue print, but not everyone does it, or does it fully.
Click to expand...

UML is a myth. No developer on the planet uses it. If anybody tells you they're using it for their day to day job, they're lying to you.

UML serves two purposes:

a) To show off to other people. This is especially frequently done by junior developers who don't know anything about the codebase yet, but it's very easy for them to take some tiny little thing and draw a UML diagram about it and talk about it for hours. So it makes them seem knowledgable... but they're really not.

b) For managers that take an interest in 0.0001% of the codebase. So you appease them by keeping UML models up to date for that tiny sliver. But you dare not do more that that because then management will complain about the code being "too complex". No, it's not too complex, I can understand my 1 line range-based for statement just fine - you just have a dumb visualization tool.

UML is one of those "negative" keywords that I look for on a resume that will eliminate candidates for me. It's in the same line as Mongo, and people who think JavaScript has any redeemable qualities in the world except for "that's where the jobs are".
 
deonb said:
UML is a myth. No developer on the planet uses it. If anybody tells you they're using it for their day to day job, they're lying to you.

UML serves two purposes:

a) To show off to other people. This is especially frequently done by junior developers who don't know anything about the codebase yet, but it's very easy for them to take some tiny little thing and draw a UML diagram about it and talk about it for hours. So it makes them seem knowledgable... but they're really not.

b) For managers that take an interest in 0.0001% of the codebase. So you appease them by keeping UML models up to date for that tiny sliver. But you dare not do more that that because then management will complain about the code being "too complex". No, it's not too complex, I can understand my 1 line range-based for statement just fine - you just have a dumb visualization tool.

UML is one of those "negative" keywords that I look for on a resume that will eliminate candidates for me. It's in the same line as Mongo, and people who think JavaScript has any redeemable qualities in the world except for "that's where the jobs are".
Click to expand...

I LOLed at this. ;)

Writing a spec in yet another language nobody understands isn't helpful.
 
You must log in or register to reply here.
Back
Top