Office politics and sh*tty code.
-
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
Everyone's code sucks but mine. It's the battle cry of every developer. On that note, I have seen some stuff that was beyond repair. As for your boss, complaining won't help, and doesn't offer a solution. Initiative to train and/or repair expediently is the only thing he will be receptive to. In the business world, most of the time, tearing down a project for months of downtime is not a feesable option, regardless of the state of the code. If repairing and training are not an option, plant good code where you can, and refactor as time permits, or.... quit. That's the range of options.
-
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
Jeremy: The reason why you have found so much (@#&*#@*(!$!) code is that you are working for a (@#&*#@*(!$!) boss. Nothing you do can change this type of situation. In my last corporate job I found myself in the same position; only this time the boss actually had done much of the existing the coding. The applications were so poorly designed that I had no idea how they even ran. The major accounting application was an MDI Windows Forms application. It was designed entirely incorrectly allowing one to completely throw out 50% of the code-base if it were to be redesigned. I knew if I complained it wouldn't result in anything good in the end so I just did my job and produced professional quality applications when I had complete control over their implementation. By the time I resigned they were the only working applications that had been built in the department. In a job before that I had a boss that was so stupid that even when shown the facts about an issue he refused to believe any of them. In one case, the issue was a 3rd party e-mail validation tool I had implemented since the company was finding that many of their emails were going out to bad addresses before. The 3rd party software worked quite well as I had written a small statistics module for verification. One day, suddenly none of the emails were being sent out from the application, which was used by quite a number of users. I thoroughly tested the issue and found that it was something external to the application. I even proved it to my boss but for three days he kept yelling at me to get the application working. Turns out, the part-time network specialist came back into the office and found that the email server that was being used for the application had been down but yielded no informational messages of the status before it went down to anyone. And no one had checked it on a daily basis. It was a 3rd party server so there was nothing I could do about it even if I had known what the problem was. The lesson from all this and throughout my long career is that the majority of technical management in the Information Technology field is severely incompetent. My advice, keep your head down and get another position...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
You've got to work on how you complain. Taking the direct route ("This is cr@p!" or a paraphrase thereof) might seem the logical route, because it's the truth, but it's not the way to put the point across. You're working with people, not machines, so you have to take feelings into account, just as you'd like others to take your feelings into account. As you said, you (and you are not alone) have written shall we say "less than optimal" code, in the past, so before pointing out errors/problems, think about how you would like people to point out the errors/problems in your own code. Then think of someone you work with whom you don't particularly like, and imagine how you would react to their "negative analysis" of your errors. Take that into account when you want to tell someone that something is "less than optimal" -- e.g. phrase it "Hey, this was a good start, and I think we could build on it!", rather than "This needs to be rewritten!" If you've already developed the rep of being a moaner, you should work very hard on getting things done without making that rep worse. Treating people as you would like to be treated yourself costs nothing more than a little thought.
I wanna be a eunuchs developer! Pass me a bread knife!
Well written, Mr. Wallace! Are you hiring? :)
-
Jeremy: The reason why you have found so much (@#&*#@*(!$!) code is that you are working for a (@#&*#@*(!$!) boss. Nothing you do can change this type of situation. In my last corporate job I found myself in the same position; only this time the boss actually had done much of the existing the coding. The applications were so poorly designed that I had no idea how they even ran. The major accounting application was an MDI Windows Forms application. It was designed entirely incorrectly allowing one to completely throw out 50% of the code-base if it were to be redesigned. I knew if I complained it wouldn't result in anything good in the end so I just did my job and produced professional quality applications when I had complete control over their implementation. By the time I resigned they were the only working applications that had been built in the department. In a job before that I had a boss that was so stupid that even when shown the facts about an issue he refused to believe any of them. In one case, the issue was a 3rd party e-mail validation tool I had implemented since the company was finding that many of their emails were going out to bad addresses before. The 3rd party software worked quite well as I had written a small statistics module for verification. One day, suddenly none of the emails were being sent out from the application, which was used by quite a number of users. I thoroughly tested the issue and found that it was something external to the application. I even proved it to my boss but for three days he kept yelling at me to get the application working. Turns out, the part-time network specialist came back into the office and found that the email server that was being used for the application had been down but yielded no informational messages of the status before it went down to anyone. And no one had checked it on a daily basis. It was a 3rd party server so there was nothing I could do about it even if I had known what the problem was. The lesson from all this and throughout my long career is that the majority of technical management in the Information Technology field is severely incompetent. My advice, keep your head down and get another position...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
If it aint broke, don't fix it. I have to work with some awful code but a) I don't have time to fix it and b) it works (sort of). Rather than wasting my life fixing legacy code I try to make my own efforts as elegant and hygenic as possible. In this way I hope to influence my colleagues to improve. I like to believe it is working... 'Don't tell them, show them' is the best approach IMHO. We're philosophical about power outages here. A.C. come, A.C. go.
-
Why are you still there?
If it's not broken, fix it until it is
-
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
Bad code comes from (lack of) expectations. Most devs are capable of writing good code. But they are human beings, and humans are lazy when there's no penalty for being lazy. It's pretty hard, as a peer, to get people to write good code. You can't just say, "Why do you write such shitty code?" because people will (rightfully) think you're an asshole if you trash-talk their work. You may get slightly more traction with a helpful comment like, "Do you know about RAII? If you use RAII here, you won't have to explicitly delete all those pointers." (Huh, codeproject auto-censors my cuss-words. I thought the authors were doing it...) You could try to get your peers to take up a static checker tool or de-linter. Sometimes even a reformatter helps, to get the whole code base into a common-looking form. You may have more leverage by encouraging your manager to promote the use of these tools. As I said, humans are lazy when there's no penalty. If your manager wants you to write better code, that's a pretty big penalty for laziness. The Holy Grail would be to convince your manager to adopt a code review methodology. When you ask your manager for help improving the code base is generally when you learn if there is any hope. If your manager views any attempt to review or refactor the code base as time wasted, then you're never going to get any traction. It is my sad experience that most managers are this way, making the usual fallacious arguments about efficiency and how the company can't afford to slow down. When you hear this, all you can do is polish your resume. You'll want to get moving.
-
Sander Rossel wrote:
I really hate regions! :sigh: They obfuscate the code, you only get to see parts of it, but I want it all! If your code is really so properly written you shouldn't need regions.
I fundamentally disagree, Sander. First of all, regions do not hide anything -- nobody holds a gun to your head and forces you to collapse them. Instead, they only allow you the option of not having to look at it every time you scroll up or down. Working in SQL all day long, I consider anything which makes navigating between key sections code faster or simpler to be A Really Good Thing. Second, regions are a purely for organizing your code, and outside of a Microsoft demonstration there is no class too small to benefit from a little functional structure (e.g., these functions are for the customer UI, these are for the auditors, and those are for the order-fulfillment folks). If a single-page essay can be more readable by being divided into 3 regions (introduction, body, and conclusion), then what makes you think that a 6- or 7-function class couldn't? Lastly, I question whether code is really any better when you take a 12-step chunk of linear (a.k.a. "spaghetti") code and refactor it into a 3-step process with each step having 4 layers of abstraction in the form of calls to other functions. I would say that there are many occasions where spaghetti code is more readable to both the human and the compiler.
William Clardy wrote:
nobody holds a gun to your head and forces you to collapse them
But the default state is collapsed. I still feel the relief when I open some old class to find out it has only about 100 lines, then notice a region and find out it's more like 1000 lines X| With all the shortcuts like "Go to definition" (F12), Go back (Ctrl and -), and the alphabetical list listing all functions, who still needs regions? If your code is clean you don't need regions, if your code isn't clean it's like swiping dust under the rug. Organized shmorganized. No region I've ever seen helped "organize" the code X| Are you one of those people who also like those awful green comments (I hate them even more than regions)? :D
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
In some cases I find that management don't want to hear that such and such code is crappy, because they probably went to a lot of effort to find the person(s) who wrote that code, and paid them a lot of money. To later hear that the code that was delivered was "sh*tty" probably sounds like you are pointing the finger at them. You need to find a way to turn around their viewpoint - that the code isn't necessarily bad, but there has been improvements in technology, and refactoring this code could lead to improvements in A, B and/or C (as appropriate). Once you have a few successes with such efforts (keeping things as positive as possible), you will find it easier going forward to get approval for cleanups like this. Not an easy task, and sometimes you just gotta vent too.... :)
-
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
-
I'm very meticulous about the code I write. I always use regions, and I use the same regions in the same order in every class. This way I know exactly where code parts are. Also, all of my class members are listed alphabetically in their regions. When I see bad code, I schedule it for a refactor. I'm actually sitting here right now refactoring some offshore code. These guys just throw code in anywhere and its annoying and flat out lazy. Unlike you, my manager is totally on board with me cleaning up the code.
If it's not broken, fix it until it is
This is key - very few will complain about you fixing things on your own. There is no need to complain - just take the initiative to make it better. Complaining is not constructive.
-
Well written, Mr. Wallace! Are you hiring? :)
Only if you'll accept ironing my shirts in your job description.
I wanna be a eunuchs developer! Pass me a bread knife!
-
I see the same problem in a lot of companies with Enterprise development. The biggest problem is not using the right tools for the job, (use the latest fad of the month and rewrite it). OOP is not suited for business applications where databases are involved. refactoring is only needed for shitty programmers, good code does not need refactoring.
pkulek wrote:
OOP is not suited for business applications where databases are involved
absolutely false. It may not be suited for every application, but it's well suited for most.
pkulek wrote:
good code does not need refactoring.
Not being "good code" isn't the only reason to refactor.
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
-
I am with you on the using of Regions. I do not know why more programmers/developers don't use them.
A giraffe is a horse designed by a committee....
I can see using regions to collapse groups of related functions. Regions within functions mean that region should probably be a separate function.
Ed Aymami wrote:
don't use them
Because it makes code hard to read.
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
-
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
This is what's worked for me in a similar situation: lead by example. Rather than say "this is cr@p, we need to change it all", instead work on what's assigned and make changes around the code you touch in order to improve it. Don't talk to anyone about refactoring, just do it in the course of doing the work at hand. That is what refactoring is all about anyway. It's not a separate task. Eventually, hopefully they can see the changes and recognize for themselves the improvement. Then they'll have a template to follow. Improving an existing code base is a marathon, not a sprint.
-
I can see using regions to collapse groups of related functions. Regions within functions mean that region should probably be a separate function.
Ed Aymami wrote:
don't use them
Because it makes code hard to read.
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
I have to disagree. It makes code easier to read, particularly in the case where someone else wrote the code and you are stuck working on it. For one thing it allows you to focus on just the code you want to see, with out having to sift through, and/or be distracted by hundreds of lines unrelated to the problem you are currently working on. It is productivity 101... If you are asked to pull the 3 of clubs out of a deck of cards that have been shuffled thoroughly, it will take you much longer to find it and pull it out than from a new deck in which all of the cards are in order by suit and denomination. It is the same reason databases have indexes. I will take code organized in this manner over code that is not all day every day. Finally, "using Regions to collapse groups of related functions" Is what I was/am talking about. I have no idea how you got "Regions within functions mean that region should probably be a separate function" out of my original reply.
Duty calls.... I wish I was deaf sometimes.
-
I have to disagree. It makes code easier to read, particularly in the case where someone else wrote the code and you are stuck working on it. For one thing it allows you to focus on just the code you want to see, with out having to sift through, and/or be distracted by hundreds of lines unrelated to the problem you are currently working on. It is productivity 101... If you are asked to pull the 3 of clubs out of a deck of cards that have been shuffled thoroughly, it will take you much longer to find it and pull it out than from a new deck in which all of the cards are in order by suit and denomination. It is the same reason databases have indexes. I will take code organized in this manner over code that is not all day every day. Finally, "using Regions to collapse groups of related functions" Is what I was/am talking about. I have no idea how you got "Regions within functions mean that region should probably be a separate function" out of my original reply.
Duty calls.... I wish I was deaf sometimes.
Ed Aymami wrote:
Finally, "using Regions to collapse groups of related functions" Is what I was/am talking about.
Then we're not in disagreement.
Ed Aymami wrote:
I have no idea how you got "Regions within functions
Because you didn't specify, but made a general statement about regions.
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
-
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
Bad code will have bad side-effects because you will underestimate how bad it really is and that little bit of re-factoring will cause you to dig yourself a huge hole because "production" will blow up some time in the future for no apparent reason... There will be a few times in your career when you will get to work on a new, shiny product; most of the time, you will be fixing what the "team" built before going off on a new adventure. ... Unless you happen to be the owner of the company (which should be your goal IMO).
-
I'm just curious to know how everyone else here deals with poorly written code in pre-existing projects. Now, I'll be the first to say in my day I've written crap, so who am I to judge right? But, over the decades of development I've done, I'd like to at least think I've learned what crap is and what's it's not. And as such, I find myself in a position at a job I've been at since mid February, where I tend to complain a lot - because the quality of code is so poor it's just sad. But, I complain because I want to see it improve. Seeing that nobody wants to be told their code sucks (even if it's true), I've been labeled a bit of a complainer unfortunately. And while I get that, the fact remains, the code is actually not that great. Which is pretty evident by virtue of the fact they always have problems with it. Well duh, I wonder why. But who wants to be the party pooper right? Whatever the case, my manager is getting fairly tired of hearing me complain, which is a bit of a downer since I've only been doing it because some things needs to be addressed to make our projects top quality. So, is there some fancy judo mind trick to get my point through, or must I accept you cannot fit a square peg into a round hole, and if people don't care about the quality of their work then you can't force them to?
Jeremy Falcon
I'm kind of in a similar situation. It doesn't have to do with code, but my company can't keep developers very long because they treat them like crap; mules to get stuff done but are given almost 0 respect from the people asking for their help. I started bringing up the problems, being really vocal about them. Management started to listen and I thought it was sincere, until they had a company meeting where they basically said "stop complaining and get back to work". I ignored them and kept at it until I was threatened with disciplinary action because my negative attitude was affecting the company. So, here's what I've done to survive while I look for another job. 1. Pick the most important battles. I think I drowned them with so many problems they didn't know what to do with them. So I decided to ignore some things and tried to focus on a few of the most important things. 2. Talk in detailed specifics. When I told them about widespread general problems, they heard "Everything here sucks"; which was true, but apparently offensive. So I've started talking about specific people or specific conflicts and suggesting a change to this one, specific event that might have a broader effect for the future. 3. Be careful how it's directed. The management team here is thin skinned. They took the accusations personally and heard it as "You're bad at your jobs". They're in top management at a mildly successful firm... so they've done something right. So I'm really careful that what I say to them can't be interpreted as a personal attack, but is more a suggestion on a way to improve this 1 thing about this 1 small event. 4. Support the hell out of what I control. Since management won't support a company change, I made changes where I could. Treats, lunches, drinks, etc are regularly brought in with a message of appreciation and understanding how much they work. I talk about the developers, the kind of crap they go through, how important they are, and how talented they are to anyone that will listen. If management won't make a change, maybe I can convince individual people to change how they work with them. I hate politics and have a hard time with people who get offended by open discussion about differing opinions, so I don't expect to be here much longer. But this has seemed to help shift the perception of me from a negative complainer to a "team player". Maybe we'll even be able to keep a developer around long enough to actually finish a project.
-
My father always told me (don't know whose quote is though): Don't fight with an idiot. Discussions will drop you to his level and he will win due to more experience.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
Much less the entire idiot world headquarters. There is absolutely nothing to be gained and there is no point riding against windmills with them.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
We've all had to work with @rseholes, there's no getting away from that, but most of them can be handled very easily if you just sit down and think of how to handle the situation (and them), rather than lose your temper and quietly simmer. None of us here is stupid; we just have to use our major assets to find intelligent solutions to problems -- use your head to think, not for butting. Think of whom you need to talk to, and what you need to say -- but remember my dear ol' granny's tenet: If you can't say something nice, don't say anything. If you get angry and butt heads with @rseholes, you're as much a part of the problem as they are -- but you make it a problem that someone else will resolve, without consulting you.
I wanna be a eunuchs developer! Pass me a bread knife!
Mark, I know you mean well and I mostly agree, but they were not the peaceful compromising types. I knew there was nothing to be gained by being stubborn. That's why, while I began to look for a way out of there, I had a little fun with them. I agreed to every crazy idea, did what they wanted me to and when the boomerang came back I left it to them to blame each other. Tuned out that they actually liked me more before. Still, in the long term I expect more from a job than keeping such idiots busy with each other.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.
