• Jay (unregistered) in reply to TenshiNo
    TenshiNo:
    The "non compete" clauses that prohibit you from working for other companies in the same field for X number of years after you leave a company have been repeatedly found (at least in the US) to be unenforceable. I understand the intent behind the clauses, but I have to agree that they aren't really feasible, especially when you're just working for a company that does custom software for clients.

    I think you could make a realistic non-compete clause for computer people more than for many other jobs.

    If you're working in the IT department of, say, a lawnmower manufacturer, it's not unreasonable to say that when you quit you can't go to another lawnmower manufacturer. There are many other types of companies where you could use your software development skills. I've worked in many different industries -- medical, automotive, furniture, military, etc -- all using essentially the same skills.

    But for somebody whose job is designing small engines, saying that when he leaves the lawnmower company he can't go to work for any other lawnmower company could be a big problem. He couldn't easily get a job for a restaurant chain or a pharmaceutical company designing small engines.

  • Klimax (unregistered) in reply to Tux "Tuxedo" Penguin
    Tux "Tuxedo" Penguin:
    Anonalzar:
    Unfortunately such attitude is not uncommon in the IT field.

    A company I previously worked at had no issue seeing horrible bugs in the application, given the fact that support would become valuable. We could just have enforced a few common best-practices and most of the issues would have disappeared "magically". Had "each developer has to test his own code or will be in trouble" been applied, we would have gained hundreds of hours of deployment ping-pong.

    However when I proposed such practices, I got an arbitrary "NO" response back. I no longer work there. After checking out of curiosity, I see that they are still producing questionable work. Good riddance. They have an excellent sales team however.

    Microsoft?

    OpenSSL... You overrate buginess of MS software. (not good joke when it is not even in ballpark of reality, then it is joke on joker)

    By convention MS SW is always buggy even if it is false.

  • TenshiNo (unregistered) in reply to Valued Service
    Valued Service:
    Anonalzar:
    Unfortunately such attitude is not uncommon in the IT field.

    A company I previously worked at had no issue seeing horrible bugs in the application, given the fact that support would become valuable. We could just have enforced a few common best-practices and most of the issues would have disappeared "magically". Had "each developer has to test his own code or will be in trouble" been applied, we would have gained hundreds of hours of deployment ping-pong.

    However when I proposed such practices, I got an arbitrary "NO" response back. I no longer work there. After checking out of curiosity, I see that they are still producing questionable work. Good riddance. They have an excellent sales team however.

    When the business starts with poor design, and develops its cashflow around supporting poor design, it is now forever stuck that way.

    The change has to come from the top.

    That's why I ask these questions in an interview. My first concern is, how much impact can I have on the processes. If I get any indication that I'll have zero impact, I move on. Even IF it's coder's paradise.

    Why?

    Because a management change will screw it all up.

    I look for the companies that ask their developers how development should be done, and get out of the way.

    Amen to that last line. I've worked for managers in the past who would send me functional specs with step-by-step pseudo code in them. Or lots of references to views with no explanation of where the data is coming from. I would much rather you tell me what the application needs to do, rather than how to write it.

    Especially if I'm going to be expected to support it when one of those views returns bad data, or some pseudo-logic in the spec was bad, but I had no way of knowing that. You end up getting chewed out for not knowing that it was wrong.

    I've gotten to where I'm not shy about telling my project manager (or boss) that I think there's a flaw in the design spec. I might do it anyway, if they're persistent, but at least I can say "remember that conversation we had about the design flaw?" when it ultimately blows up.

  • TenshiNo (unregistered) in reply to Jay
    Jay:
    TenshiNo:
    The "non compete" clauses that prohibit you from working for other companies in the same field for X number of years after you leave a company have been repeatedly found (at least in the US) to be unenforceable. I understand the intent behind the clauses, but I have to agree that they aren't really feasible, especially when you're just working for a company that does custom software for clients.

    I think you could make a realistic non-compete clause for computer people more than for many other jobs.

    If you're working in the IT department of, say, a lawnmower manufacturer, it's not unreasonable to say that when you quit you can't go to another lawnmower manufacturer. There are many other types of companies where you could use your software development skills. I've worked in many different industries -- medical, automotive, furniture, military, etc -- all using essentially the same skills.

    But for somebody whose job is designing small engines, saying that when he leaves the lawnmower company he can't go to work for any other lawnmower company could be a big problem. He couldn't easily get a job for a restaurant chain or a pharmaceutical company designing small engines.

    The problem comes in when you work for a company that just does custom software for other companies, because then there is no "specialty". Then it's like you're precluded from working in your field at all.

    Either way, US courts have made several rulings against these clauses over the past few years, so I'm not too worried about it.

  • Dominic (unregistered)
    Log from the sftp package, Dean replied. Y’know, the code I told you to write.

    Aikh gaped at the email chain, having watched this horror show unfold in achingly slow motion. This was just supposed to expose a simple interface to a third party SFTP package. How was it so hard?

    Does anyone else get the impression that underneath all the narrative fluff, we just have a senior dev trying to school the new guy to actually do his job?

  • (cs) in reply to Tux "Tuxedo" Penguin
    Tux "Tuxedo" Penguin:
    Microsoft?

    I'm going to go out on a limb here and guess that you're biased.

  • garaden (unregistered) in reply to chubertdev
    chubertdev:
    Tux "Tuxedo" Penguin:
    Microsoft?

    I'm going to go out on a limb here and guess that you're biased.

    Yeah, they've been a lot less evil lately. I've resigned myself to hating Microsoft for not letting me hate them properly.

  • JJ (unregistered) in reply to QJo
    QJo:
    In a position where I was responsible for maintenance of a whole articful of internal service tools [...]
    "Articful"?
  • Henry (unregistered) in reply to sino
    sino:
    Henry:
    No, exactly because they can write malicious or incompetent code, that's why they can't make their bad code go live.
    But DBAs can also write malicious or incompetent code, so why should they have access to production?
    They shouldn't. That was someone else's comment.

    I assume if you need to ALTER TABLE to add a column, you're going to test that first, right? RIGHT??? Not just go cause an outage because you fatfingered something?

    And then when the changes work perfectly you're going to want to make exactly the same change in production, right? Since that's the change you tested?

    And what can you do to eliminate the fatfinger factor in prod? You have to execute the change from a script -- the same script you tested earlier.

    And you don't need your DBA mucking around in production to execute that script. Ops can do it, just like they deployed the files sent by the developer. And oh yeah the DB change should be reviewed and logged just like the developer's change.

  • I always lie. I never tell tell the truth. (unregistered) in reply to JJ
    JJ:
    QJo:
    In a position where I was responsible for maintenance of a whole articful of internal service tools [...]
    "Articful"?

    Arcticful. Santa's workshop had been anonymized to a bank, but that was missed due to the typo.

  • Null Dereference (unregistered)
    approved the purchase of a fast, supported library for file transfer
    JSch is a pure Java implementation of SSH2. JSch is free.

    Aikh is an incompetent waste of salary who can't even use Google.

  • garaden (unregistered) in reply to Henry
    Henry:
    sino:
    But DBAs can also write malicious or incompetent code, so why should they have access to production?

    You don't need your DBA mucking around in production to execute that script. Ops can do it, just like they deployed the files sent by the developer. And oh yeah the DB change should be reviewed and logged just like the developer's change.

    Huh? I agree with you mostly, but I don't think separation of duties means ops guys perform code reviews. The point of limiting the number of people who can deploy to prod is to make post-mortems easier by narrowing down the ways changes can be introduced, not to prevent bad changes from getting in in the first place.

    I also agree with sino that not every company needs such strict procedures. If your whole (privately-owned) company has one team of six devs, an "ops department" would be overkill.

    I do think DrPepper is underappreciating his ops guy though :)

  • Rat (unregistered) in reply to Dominic
    Dominic:
    Does anyone else get the impression that underneath all the narrative fluff, we just have a senior dev trying to school the new guy to actually do his job?
    The new guy's a useless shit, but he's a young useless shit, so he gets the old guy's job. Underneath all the fluff, there's nothing but age discrimination.
  • (cs) in reply to Null Dereference
    Null Dereference:
    approved the purchase of a fast, supported library for file transfer
    JSch is a pure Java implementation of SSH2. JSch is free.

    Aikh is an incompetent waste of salary who can't even use Google.

    But this may be one of those companies that forbids the use of open/free software. In the story, the business unit ended up paying for a suitable library.

  • (cs) in reply to Jay
    Jay:
    I think you could make a realistic non-compete clause for computer people more than for many other jobs.

    If you're working in the IT department of, say, a lawnmower manufacturer, it's not unreasonable to say that when you quit you can't go to another lawnmower manufacturer. There are many other types of companies where you could use your software development skills. I've worked in many different industries -- medical, automotive, furniture, military, etc -- all using essentially the same skills.

    So what is such a person going to walk away with? Is there something intrinsically different about a lawnmower company compared with, say, a kitchen blender manufacturer?

    For all we know, such a person might have no contact with the lawnmower manufacturing part of the business. He might, say, support the accounting system.

    But for somebody whose job is designing small engines, saying that when he leaves the lawnmower company he can't go to work for any other lawnmower company could be a big problem. He couldn't easily get a job for a restaurant chain or a pharmaceutical company designing small engines.

    But this is the sort of person who might well have confidential information directly related to the company's area of business. I can understand an employer being concerned here.

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to TenshiNo
    TenshiNo:
    Valued Service:
    Anonalzar:
    Unfortunately such attitude is not uncommon in the IT field.

    A company I previously worked at had no issue seeing horrible bugs in the application, given the fact that support would become valuable. We could just have enforced a few common best-practices and most of the issues would have disappeared "magically". Had "each developer has to test his own code or will be in trouble" been applied, we would have gained hundreds of hours of deployment ping-pong.

    However when I proposed such practices, I got an arbitrary "NO" response back. I no longer work there. After checking out of curiosity, I see that they are still producing questionable work. Good riddance. They have an excellent sales team however.

    When the business starts with poor design, and develops its cashflow around supporting poor design, it is now forever stuck that way.

    The change has to come from the top.

    That's why I ask these questions in an interview. My first concern is, how much impact can I have on the processes. If I get any indication that I'll have zero impact, I move on. Even IF it's coder's paradise.

    Why?

    Because a management change will screw it all up.

    I look for the companies that ask their developers how development should be done, and get out of the way.

    Amen to that last line. I've worked for managers in the past who would send me functional specs with step-by-step pseudo code in them. Or lots of references to views with no explanation of where the data is coming from. I would much rather you tell me what the application needs to do, rather than how to write it.

    Especially if I'm going to be expected to support it when one of those views returns bad data, or some pseudo-logic in the spec was bad, but I had no way of knowing that. You end up getting chewed out for not knowing that it was wrong.

    I've gotten to where I'm not shy about telling my project manager (or boss) that I think there's a flaw in the design spec. I might do it anyway, if they're persistent, but at least I can say "remember that conversation we had about the design flaw?" when it ultimately blows up.

    I couldn't imagine working for a place where a developer is not expected to point out where there is a design flaw. I spent many years in an uphill struggle to get the rest of the bloody developers to engage with the project team enough to even discuss the stupid changes with them "Why is it like this?" is the first question to ask when it doesn't look right to you, and the project team member providing the specs will say, "Good question, now you mention it, I'll check back with the customer, make sure we've understood it correctly." Any other approach is a FGBWTF.

  • (cs) in reply to Null Dereference
    Null Dereference:
    approved the purchase of a fast, supported library for file transfer
    JSch is a pure Java implementation of SSH2. JSch is free.

    Aikh is an incompetent waste of salary who can't even use Google.

    So then Java can become TRWTF.

  • Hatful (unregistered) in reply to Auction_God
    Auction_God:
    But this may be one of those companies that forbids the use of open/free software. In the story, the business unit ended up paying for a suitable library.
    Unlikely that open/free software is forbidden, since Dean gave Aikh an open-source library, that Aikh was too stupid to use.

    You some kind of troll, bro? Or are you Aikh?

  • Ralph (unregistered) in reply to garaden
    garaden:
    chubertdev:
    Tux "Tuxedo" Penguin:
    Microsoft?

    I'm going to go out on a limb here and guess that you're biased.

    Yeah, they've been a lot less evil lately. I've resigned myself to hating Microsoft for not letting me hate them properly.

    Hmmm, they fixed 66 security flaws in Windows, Internet Explorer, and Office today. If that's your idea of better I'd hate to see worse. Well I guess at least they are fixing them. How many thousand more remain undiscovered?

  • jfh (unregistered) in reply to sagaciter

    That's why there are background checks--not just for DBAs, but for developers too.

    Captcha: ratis: How come I didn't get "eros"?

  • (cs)

    If you need to have a ton of compliance rules you're too paranoid.

  • Tux "Tuxedo" Penguin (unregistered) in reply to garaden
    garaden:
    chubertdev:
    Tux "Tuxedo" Penguin:
    Microsoft?

    I'm going to go out on a limb here and guess that you're biased.

    Yeah, they've been a lot less evil lately. I've resigned myself to hating Microsoft for not letting me hate them properly.

    Oh, but there's plenty of reasons you can hate M$ for:

    • Their project aren't free (both as in freedom and as in beer)
    • Metro/Modern UI (which by the way, they've stolen from Gnome3 Shell concepts)
    • No Wobbly Windows
    • No ability to easily swap window/desktop manager - you're basically stuck with Explorer/Metro and Aero unless you want to shell out insane money for things like WindowBlinds or Aston Shell
    • C'mon, it was made by Microsoft, it ought to be buggy
    • No repo-like system (except on shitty W8 and even then, not for desktop apps) which means that this copy of Notepad++ that you're downloading may have trojan inside.
    • And many others that I can't think of right now because I'm heat-struck (penguins tends to be heat-struck when exposed to 30C temperatures).
  • Friedrice The Great (unregistered) in reply to Jay
    Jay:
    The in-house IT departments that I have worked for have never had a problem of not having enough to do. They've always had long waiting lists of projects.

    A friend of mine once told me that at his company, every request for IT services was given a "priority" from 1 to 10, with 1 being the highest priority. He said that at meetings people would spend hours arguing about whether a given project should be priority 3 or priority 4, and departments would battle to get their pet project boosted a step or two. And for all that, he said, in all the years he worked there, they never actually worked on any project that was less than priority 1.

    So one month before a project is due, it becomes priority 1?

  • Cheong (unregistered) in reply to Anonymii
    Anonymii:
    A DBA is somebody you entrust with the security of your data (and, in a more general way, the security of your company). That's part of their job, and when you hire one, you need to know they're somebody you can count on and trust.

    A developer isn't in the same position, at all.

    Is it? I think developers have the same level of access the highest ranking staff their code will be used by, most often the accountants, CS supervisors, sales managers or even the "C-O" grade staffs.

    And you dare to hire someone you won't trust to be developer of your company?

  • (cs)

    TRWTF is this story ended with a winner. I haven't seen a winner in here for so long, it's got to be TRWTF.

  • Internet Explorer (unregistered) in reply to Jack
    Jack:
    Hint: if you can keep the CPU pegged for an hour (and it isn't stupid code) you're probably more productive than 50 mouse jockeys.
    Hurray, someone finally appreciates me for what I am!

    Next I'll show you my other skill: using up all your available RAM and thrashing the page file. You'd think waiting for disk accesses would reduce CPU usage, but you're underestimating me again. I'm expert at threading! While some of my threads keep the disk arm moving, other threads burn all your CPU cores.

  • Norman Diamond (unregistered) in reply to Henry
    Henry:
    DrPepper:
    As a developer, I'm tasked with figuring out issues in production... Of course, being a dev, I only have read access to the prod database. So I figure out the problem, write the script that needs to be run, and send it to the ops guy.

    ... That's his entire job -- wait for someone to send him a script, and run it.

    It's called separation of duties. As a developer, you damn well better not have access to run code in production. That's how banks find themselves victims of multi-million dollar frauds.

    Indeed I seriously question your having read access to production data. Can you say "identity theft"?

    You don't need developers to get multi-billion dollar frauds and identity theft. You can do it with data entry clerks. Though maybe it helps to be more powerful than a bank:

    http://www.treasury.gov/tigta/congress/congress_05082012.pdf

    http://www.treasury.gov/tigta/oi_highlights_2011.shtml (and other highlights for other years)

    http://www.treasury.gov/tigta/press/press_tigta-2013-40.htm

    The data entry clerks aren't working alone though. Higher ranking people frame the victims for fraud, block refunds to victims, and impose civil penalties on victims.

  • AnonymousCoward9856 (unregistered)
    TenshiNo:
    The "non compete" clauses that prohibit you from working for other companies in the same field for X number of years after you leave a company have been repeatedly found (at least in the US) to be unenforceable. I understand the intent behind the clauses, but I have to agree that they aren't really feasible, especially when you're just working for a company that does custom software for clients.
    AFAIK these clauses can be enforceable in Germany if written correctly. But they are only enforceable if the employee is compensated for the X number of years with an appropriate amount of money. Appropriate means an amount that is at least equal to the amount of money that he could have made if he worked in this field for this time.

    So the only people who have contracts with clauses that are actually enforceable are employees with very valuable knowledge.

    But I'm not a lawyer and this information is a few years old so take it with a grain of salt.

  • (cs) in reply to JJ
    JJ:
    QJo:
    In a position where I was responsible for maintenance of a whole articful of internal service tools [...]
    "Articful"?
    Yes, an articful. You know, the amount of stuff that fits in an artic.

    (When I were a lad, "artic" was British slang for "articulated lorry", what Americans might call a "semi", so an "articful" would translate as "lorryload" or even "truckload"...)

  • QJo (unregistered) in reply to JJ
    JJ:
    QJo:
    In a position where I was responsible for maintenance of a whole articful of internal service tools [...]
    "Articful"?

    "Articful" as "articulated-lorryful", a (in retrospect pointless) colourful way of saying "lots".

    Pearls before swine. My sympathies are with Erik every time.

  • Dominic (unregistered)

    So is "Aikh" not going to show up to tell us how the story was distorted, and how he didn't sit on his thumb wondering why other people didn't do his work for him, and how he didn't blame irrational "institutions" when the work didn't get done?

  • Rusty (unregistered)

    BTW, nice picture of the John Henry statue at Talcott, West Virginia!

    Just remember that, the man who invented the steam drill, he thought it was mighty fine. But John Henry, he drilled 16 feet, the steam drill only made nine (feet, that is). Lawdy Lawdy!

    --Rusty

  • yeahso (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    JJ:
    QJo:
    In a position where I was responsible for maintenance of a whole articful of internal service tools [...]
    "Articful"?
    Yes, an articful. You know, the amount of stuff that fits in an artic.

    (When I were a lad, "artic" was British slang for "articulated lorry", what Americans might call a "semi", so an "articful" would translate as "lorryload" or even "truckload"...)

    They say you learn something new every day, so... Good night, everybody!

  • Meep (unregistered) in reply to TroelsL
    TroelsL:
    Excellent story, not overly embellished and holds a real WTF and a realistic scenario.

    Thank you for listening, TDWTF!

    Don't let it go to your heads.

  • WorldClass (unregistered) in reply to Mr. AHole DBA Guy
    Mr. AHole DBA Guy:
    DrPepper:
    Where I work, there is one guy who is our "Ops" guy.

    As a developer, I'm tasked with figuring out issues in production. Often, the fix for the problem involves altering values in a table in the production database -- for example, adding a record that would trigger some process.

    Of course, being a dev, I only have read access to the prod database. So I figure out the problem, write the script that needs to be run, and send it to the ops guy.

    Who just opens up a sql window, pastes the script into it, and clicks the run button.

    That's his entire job -- wait for someone to send him a script, and run it.

    It's the same thing again -- his time is billed by his department; so if one of us were able to run the script, his services would not be needed, and his department would lose the revenue.

    Yo DocPepper, you do realize that all sorts of compliance requirements state that devs will never have write access to production, correct?

    Also, that's not his only job, it's the end product that you only get to see. His job is a lot more involved than that. Design and managing solution's that gives you 5 9's uptime, meeting all the SLAs, perform capacity planning and growth, handle DR, and fix bad developer mistakes in prod are just some of the things 'ops guys' deal with on a daily basis.

    Anytime I've had a environment almost go down, you can thank the developers who think they are too good to follow IT best practices since it just slows them down.

    You lost me at "DBA Guy". The tech food chain goes something like this:

    Developer QA Analyst Janitor DBA

  • smoof (unregistered) in reply to Tux "Tuxedo" Penguin
    Tux "Tuxedo" Penguin:
    Oh, but there's plenty of reasons you can hate M$ for: - Their project aren't free (both as in freedom and as in beer)

    You might not choose to run software that isn't free, but hating them for it says more about you than it does about Microsoft.

    Tux "Tuxedo" Penguin:
    - C'mon, it was made by Microsoft, it ought to be buggy

    heartbleed became so big that the OpenSSL vulnerabilities had to finally be disclosed, I wonder what is next.

  • ideo (unregistered) in reply to Gene Wirchenko
    Gene Wirchenko:
    But this is the sort of person who might well have confidential information directly related to the company's area of business. I can understand an employer being concerned here.
    I don't care how "concerned" you are, you don't get to declare that people aren't allowed to make a living.
  • Paul (unregistered) in reply to TenshiNo

    There is a production system, with ssn, medical conditions, insurance information. This is manned by a DBA. He sees it all. It will probably be written out in whatever compliance doc they need.

    There is a test system, why wouldn't the ssn's be faked on sync? Now you have a duplicate system, that you can view and edit?

    There are also some DB systems that can even hide data from Jr DBA (if you have more than one); maybe even DBA, but I do not know of any offhand.

    Note, if shtf, the DBA ass is on the line, not the Devs, for he is on the compliance doc.

  • Dan F (unregistered)

    Good dailywtf features are like good code. They should be abstracted enough that the necessary internals are kept hidden, but not obfuscated to the point where it can no longer be followed.

    Seems like Ellis is the only author in years who understands this.

  • Martin (unregistered) in reply to WorldClass
    WorldClass:
    You lost me at "DBA Guy". The tech food chain goes something like this:

    Developer QA Analyst Janitor DBA

    Only in the mind of some self-styled superstar developers. Most of the world understands that getting systems designed, developed and deployed is a collaborative process that's only as strong as the weakest link.

    In other news, I think Janitors are probably not part of the tech food chain. They taste too dusty really.

Leave a comment on “Manual Automation”

Log In or post as a guest

Replying to comment #:

« Return to Article