5 ms·

This article clearly missed the point. He didn't make a huge mistake, he made a very tiny one. The company/CTO made the huge mistakes.

• shirian 9y ago
  To be fair, the article states that the junior dev made one mistake, whereas the company made several. However, I agree with you in that it should emphasize that the mistake made by the junior dev is lesser in both size and quantity.
• Avenger42 9y ago
  He made a tiny mistake that, due to the mistakes made by the company/CTO, had huge consequences. As a first-day developer, he shouldn't really have had the ability to make a mistake with any consequences beyond lost time.
• protomyth 9y ago
  A old supervisor of mine told me that "You treat a new developer like a duckling near a pond with Northern Pike". There is no way you let them have access to production (or frankly, anything past a development environment) until they have been there a while and gotten the hang of it. On a tangent, I was paranoid enough in one position to have all my production terminal windows have a red background with yellow text. That brought the proper, serious attitude towards my work.
  • zaphod12 9y ago
    That's not paranoid! That's a fantastic thing to do and one that I highly recommend for anyone. It's terribly easy to forget which environment you're working in when you get distracted for a moment and that's how mistakes happen.
    • protomyth 9y ago
      I went the whole nine yards on that project. I had white (black font) for my own machine, green for development, blue for integration test, yellow for system test, and red for production. I liked the green / white text theme the most with blue being my second favorite to write code in so those got the ones I would use the most. I was never a lover of the old amber terminals and red is just plain painful to write on. I guess the more pain your terminal causes you, the more dangerous the environment.
      • wsinks 9y ago
        Was it automated? If so, how?
        • rocky1138 9y ago
          It doesn't help the terminal itself, but changing your ~/.vimrc to use different themes can help.
        • tbirrell 9y ago
          I have a similar setup, and it is relatively easy to set up using .bashrc and terminal color variables.
          • throwanem 9y ago
            I did something similar with a shell script for MySQL databases, both to support shorthand invocation (i.e. "mysql foo-bar-baz" to look up the named configuration, expand it into whatever set of arguments is defined therein, and invoke mysql(1) accordingly), and to allow for detailed and environment-specific prompts which warn me when I'm targeting production. It's hideous, of course. But it works very well for me, and I don't suppose I'd be averse, if interest becomes evident, to sharing it somewhere for others to benefit from and/or peruse in horrified fascination.
            • throwanem 9y ago
              It's more hideous than I remembered! But for anyone interested, here you are: https://gist.github.com/anonymous/8ec128e88dac85d93ed58fb518b2c705 https://gist.github.com/anonymous/8ec128e88dac85d93ed58fb518... Outside GNU coreutils, the only dependencies are mysql(1) (of course) and jq(1), which is more or less "awk for JSON" and which I strongly recommend to anyone who regularly deals with that file format. Share and Enjoy!
        • toomuchtodo 9y ago
          Use config management to render the proper shell config per user.
  • jt2190 9y ago
    Indeed. The difference between an experienced person a naive one is not that the experienced person doesn't make mistakes, but that they fully expect to make mistakes so they take precautions to mitigate their effects, take measures to prevent them, and minimize doing work that is mistake-prone.
    • protomyth 9y ago
      Inexperienced folks really haven't had that "oh hell" moment of contemplating what could go wrong and the experience to know how bad it can go wrong. I was at a site when a truck hit the power main and the UPS (diesel if I recall) for the server room failed to work. The new people were in the "It shouldn't take too long to reboot the servers" where the experienced people were "this is going to be a very long day". The later group was rewarded with a 36 hour day.
  • blackaspen 9y ago
    An old team did a similar thing! A terminal window with a skull and crossbones when you log into anything that's ".prod.X.com".
  • larrik 9y ago
    I definitely color my production terminals orange (and QA/staging get purple), and it's saved me a few times. I wouldn't consider NOT doing that.
  • Teknoman117 9y ago
    And here I was just put "(production)" in $PS1...
    • throwanem 9y ago
      Try this: export PS1=$(tput bold; tput setaf 1;)'(production)'$(tput sgr0)' \u@\h: \W $ ' and get something a little more lively! (For many more things you might be able to do with "tput", refer to "man 5 terminfo" on your local Linux machine.)
  • pfranz 9y ago
    I really like having a strong, visual indicator when you're doing something dangerous, as well. I had a job where we would often sudo as other users and ssh into other boxes. I kept trying and trying to find a way to change the terminal when sudoed as someone else because occasionally I would execute something in the first terminal I could grab. At the time I couldn't find anything or think of a way.
  • Zhenya 9y ago
    Apparently Northern Pike can eat ducklings https://www.youtube.com/watch?v=2_E4BUt1z8Y https://www.youtube.com/watch?v=2_E4BUt1z8Y
    • protomyth 9y ago
      Yep, fairly horrific. They will also attack a swimmer for no apparent reason other than they are an evil, foul-tempered fish. The bigger ones can make you bleed quite quickly. River barracuda is a name I heard once.
  • lgas 9y ago
    DBVisualizer has a setting that lets you designate different color schemes for different databases. It's saved me more than once.
    • reitanqild 9y ago
      I think TOAD has as well.
• Florin_Andrei 9y ago
  It's really, really simple. Just restrict access to the production databases. Structure the access in such a way that this kind of honest mistake simply cannot happen. Add an extra hoop to jump through to access prod. Easy as that. Better yet, prod should be in a different "cloud universe" (root account, etc) from dev. > The company/CTO made the huge mistakes. Absolutely.
• kafkaesq 9y ago
  The company/CTO made the huge mistakes. Indeed. To capitalize on a meme in current circulation, "One does not simply 'accidentally destroy' a production database." When things like this happen, they happen because someone who almost certainly did, in fact, know better -- at some point made a conscious decision to allow them to happen, by consciously cutting corners in certain matters of due diligence that we all know about. Things like backup systems, database roles, and hiring the right people to set up and maintain these things. Not because of something a junior dev did.
• snambi 9y ago
  The CTO is incompetent. Don't blame the junior engineer.