Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

OT: Job Advice

by abaxaba (Hermit)
on Jun 25, 2002 at 07:25 UTC ( #177032=perlmeditation: print w/ replies, xml ) Need Help??

So, after almost eight full months of small contracts, I've beat out a boatload of competition (1000+ applicants) and landed a FT position. Small dev shop, highly team oriented, opportunities for prof. growth, new technologies, etc etc...

Some Background: Experience Hath Shown™ that a lot of what passes for perl "code" is poorly written, insecure, homegrown (eg: no use CPAN || die)...in short, a big bucket full of crap. In my last two jobs, I maintained production code that looked like:
require "config_file"; $this_num=$number_from_config_file; $that_num=$this_num; if ($this_num == $that_num) { $that_num=0; } elsif ($this_num != $that_num) { $that_num=0; } #ignore this_num for the rest of the script's life.

If that's not ugly enough -- how about some lovely cgi code, with about 60 form-fields, cgi-lib.pl, and about 60 lines of code that look like:

$this_var = $in{"this_var"}; $that_var = $in{"that_var"}; $some_other_var = $in{"some_other_var"}; $foo = $in{"foo"}; $bar = $in{"bar"}; $baz = $in{"baz"}; . . .


<Rant>Honestly, folks. I'm not making this stuff up, and I'm hardly exaggerating. There really were if/thens in place of simple assignments, (forget ternary), multiple variables assigned to some other variable, and 60 scalars when a single hash (already created/assigned) would've sufficed. These were very large organizations, with pretty large IT budgets. And this was mission-critical production code.</Rant>

The Dilemma: As most people when they start a new job, I'm on some sort of probation, where dismissal can be for any reason. After discussing many of the particulars with my future supervisors, it seems, based upon what I'm hearing, that:

  • CPAN is not being properly utilized,
  • Security is compromised,
  • There exist many coding redundancies (eg change once, retype everywhere), and
  • Lack of sensible development environment (no testing/staging area, no version control, etc)
  • .

    Now I'm no "guru" by any stretch, but I've managed to develop a nose for less-than-ideal code, largely by reading here, hanging out with my local PM group, lots of practice, and working at the above-mentioned IT garbage piles. And I think just about everyone would agree that the above foursome represent some Very Bad Things.

    The Question: At what point do I start suggesting changes? Do I wait until my "probie" status is lifted? Do I drop subtle hints along the way, or come out with guns-a-blazin? Or do I just go with the flow? I don't wish to step on toes, or hurt feelings or anything like that, and I look to those of you who have similar experiences for guidance.

    ÅßÅ×ÅßÅ
    "It is a very mixed blessing to be brought back from the dead." -- Kurt Vonnegut

    Comment on OT: Job Advice
    Select or Download Code
    Re: OT: Job Advice
    by jepri (Parson) on Jun 25, 2002 at 08:41 UTC
      I hate to say it, but you may be in for a rough time. When I worked in a place like that, I faced similar problems. I had to deal with people who couldn't see the point of anything I talked about, and who used to stand around in groups and tell me how their code was self documenting, and how good they were at coding, etc...

      In my case though, I was on a fixed term contract, filling in for someone. There was no chance of renewal although a year later they called me and offered me a job.

      I don't recommend that you try any of the things below if you value your job. What I do suggest is that you gently make your point, if you can do it in a way that doesn't offend people (many people get very offended by critiques of their programming). Then do your own code the right way. When people ask why, explain.

      You might end up being ordered to do something wrongly for a variety of reasons. Mention that you heard of a better way, and if they don't bite, knuckle down and do it wrong. That was a hard lesson for me...

      Onto my experiences... They were bad coders and I knew it. They weren't even using any version control (because they were "good programmers" and their code "always worked"). So one day after a week of bitching at them for not using ANY version control I went and changed the script timeout to 1 second then left for a two day holiday. At the end of the first day, my friend called me to describe his horror day, since all of his scripts started failing randomly, and he couldn't figure out why. After he agreed that having a backup would have saved his arse, I told him the trick. I was glad I was 30kms away at the time...

      After that I tackled the self documenting code fallacy by finding some really nasty code left by a previous programmer. I chose this code because it took the whole morning for me to figure out. It was nasty because it contained a variable (a filename) that was used in three files. In one file some code trimmed off the extension. In the second file tbe code added an extension, saved some data in it, then passed it to the third code file, which read the file back in, trimmed the extension, passed it to another routine which saved it into it's destination directory under - you guessed it - another name.

      The only error checking done was in one routine which checked if the filename was empty. If it was it printed out "Danger, danger Will Robinson", and then quit.

      I sat everyone down with the printouts and encouraged them to explain to me what the code does. After five minutes of them guessing (wrongly) we actually started to talk a little about coding standards and specifications, and documentation. One of the coders acutally went so far as to go back and document some of his code.

      I just realised. I really am a bastard.

      ____________________
      Jeremy
      I didn't believe in evil until I dated it.

    Re: OT: Job Advice
    by cjf (Parson) on Jun 25, 2002 at 09:28 UTC
      At what point do I start suggesting changes?

      Follow standard operating procedure:

      1. Point out what you think could be improved right away. If they don't agree with you, move on to step two.
      2. Do the job as instructed, but consider creating alternatives to the scripts on your own time. Give them something a little more real. "This is the current script, this is how it can be exploited to deface our website. Should I replace it with the new version?"
      3. If step two does not provide the desired results, decide whether or not you really want to work there.

      Best of luck :).

    Re: OT: Job Advice
    by Matts (Deacon) on Jun 25, 2002 at 11:25 UTC
      My advice - find somebody who shares similar ideals for clean code, that way you have an ally. Don't force your ideas upon people, but just suggest small changes at team meetings - start with source code control - suggest that you should have a backed up CVS server (or some alternative revision control engine). And follow it through by simply installing one in your lunch hour - otherwise nobody is going to use it. Show your boss how great it is to get commit emails showing you what has changed and who changed it.

      Once you start to bring improvements like that to the company, you'll soon find that you are both trusted, and that your probation period is very quickly over.

        Of course, that may not work... At my previous employer (R.I.P.), I introduced them to the wonders of CVS and bug tracking systems. I thought they were great. The other linux-friendly programmer loved them in principle, but rarely used them. The Windows-zealot-consultant bitched and moaned about being asked to use something which didn't come from Redmond, even after I showed him how to integrate CVS into the MS IDE. And the QA guy (yeah, we needed more than one tester and I kept telling management to get more of them, but it was a small company and one was all they'd give us) absolutely hated me for insisting that he file bugs in a trackable fashion instead of just walking over and saying, "X isn't working".

        But that company doesn't exist any more... Small wonder.

    Re: OT: Job Advice
    by particle (Vicar) on Jun 25, 2002 at 12:38 UTC
      two words: write tests.

      • test the current functionality of one script
      • once all tests pass, refactor the code. DO NOT add or change functionality.
      • make sure the code passes all tests
      keep a copy of all this work. then...

      • modify/add tests to represent functionality you expect
      • modify your refactored code to pass the tests
      show the team the old code, the tests, and the refactored code. presumably, the tests will show things that shouldn't be. then show them the new tests, and the new code that passes all tests.

      buy a copy of The Pragmatic Programmer for the office, and encourage teammates to read it.

      this is precisely what i've done at my current job, except i'm doing it in ksh. i wrote a test library, and have written test cases (in my spare time) for 1100 lines of ksh. i've successfully refactored the code and passed a full suite of regression tests. i've modified the tests to match expected functionality, and am in the process of modifying the code to pass all tests... all the while making the code more reliable and reusable. and i'm training the team on performing tests and using my test library, so when i leave, they'll continue what i've started.

      if all that doesn't work... i'm out of suggestions.

      ~Particle *accelerates*

    Re: OT: Job Advice
    by husker (Chaplain) on Jun 25, 2002 at 13:21 UTC
      Well, before you do anything, you really need to earn some credibility among both your managers AND your colleagues. They have to feel confident in your competence before they will listen to (or even appreciate, most likely) your suggestions.

      Once you've been "vetted" in this manner, so to speak, then you can begin to nudge change from the inside. If your coding ideas are truly superior, then they will be shown to be superior across the day-to-day toil and grind of the development effort. If your code is more efficient, then YOU will be able to produce code faster. If your code is easier to maintain, this will be evident as others try to maintain it. If your code is more secure ... well you may need to enlist the aid or at least goodwill of whomever in the organization is most concerned about security.

      Whatever you do, I think you must resist the "guns a-blazin" approach. Pattern yourself after the monk: to teach, not accuse; to build up, not tear down; to mentor, not dictate. Perhaps you can find an open mind among the youngest or most junior developer; they are often most likely to accept mentoring / tutoring. Your goal is to provide a better product, to improve your craft, to perfect your art; it is not and should not be to "make everyone code the right way".

      Further, you must tailor your message to each audience. Managers are often swayed by arguments which focus on the bottom line; colleagues are often swayed by arguments which make them appear to be doing more quality work with less effort; a select few may be enticed just by the prospect of Doing the Right Thing. Depending on the culture of your new company (which may take a while for you to discern), it's arguable whether you should start at the top (management) and work down, or start at the bottom (programmers) and work up.

      Also be prepared to be rejected by some no matter what you try. For whatever reason, a handful (hopefully no more) will be immune to your evangelizing. Do not force that issue; after all, there ARE more important things in life than hashrefs and  use strict; . Foster those personal relationships even with those who deny you, since you must work around them each day anyway. Acknowledge the person's overall worth even if they don't agree with what you think is the best documentation style.

    Re: OT: Job Advice
    by redsquirrel (Hermit) on Jun 25, 2002 at 14:30 UTC
      As a former co-worker of yours, still at one of the large organizations you metioned above, my advice to you is to be patient. Change happens slowly, especially in large organizations, but change does happen. There's a lot to be said for doing quality work over a long period of time. Once you earn the trust and respect of your co-workers and superiors, you will be able to shape programming policy.

      What I have discovered since you resigned is that by being respectful to my teammates and working hard to become the best programmer I can be, things have begun to change for the better.

      You and I both know you have excellent programming ability. But your abililties will be wasted if you cannot have the patience to be a river shaping a valley rather than a flash flood.

      --Dave

    Re: OT: Job Advice
    by rattusillegitimus (Friar) on Jun 25, 2002 at 14:38 UTC

      This may be common sense and something everyone here's already thought of, but it could help your situation if you can find some "good" practices, code, etc. to comment on as well as the bad and/or ugly.

      When I was hired for my current position, I was brought in to be the new "Web Guy," as the people currently handling the organization's website had no real web design experience. A lot of what I found waiting for me needed serious improvement, mostly due to inexperience. About a week in, I was asked what I thought of the site, and I was able to truthfully point out several things that had been done right and several stylistic pitfalls that had been avoided.

      I believe this gave me a bit more credibility with the people who had been handling the site before me (one of whom is my supervisor), and combined with constructive criticism of other areas of the site, stopped short of ye olde brown nose. ;)

      -rattus, this'd be my $0.02 if rats carried pocket change

    Re: OT: Job Advice
    by cidaris (Friar) on Jun 25, 2002 at 15:41 UTC
      Well, this is where we get "The programmer who previously worked on your code is always an idiot." Theorem.

      There's really no way around this, as to most businesses see things on a very different plane than coders.
      We're taught to see the bad, change, make better, even add features, etc. from our natural tendencies as programmers (I rarely meet coders who do not love a good challenge and like to help out.)
      To a business, however, a program is a program. To them, if it works, if it's stable, if it does what it needs to do, that's good enough, and revision would almost be a sin.
      If you stand back and look at it from their perspective, it's a bit like OO programming to us. We see an object, we know that if we put in X file and send it through X processes, we're returned what we expect. The inner details can be completely invisible.

      For all of us who ever took apart a broken TV only to find there *really are* no serviceable parts inside, or tried to reassemble an old pocket-watch, there's this "let me fix it, let me make it better" feeling. Especially if it makes our jobs easier in the future.

      Those who aren't 'in the know' often can't/won't see the utility of changing code that works. To them, code quality might be intangible.

      If you can show them on a level that matters to them, value in dollars/manhours of maintaining bad code vs. time to rewrite, you may get your shot. But if the numbers don't add up, well, enjoy wading through that code through the rest of your tenure.


      Jaded? Heh heh, kinda.
      cidaris
    Re: OT: Job Advice
    by drewbie (Chaplain) on Jun 25, 2002 at 15:44 UTC
      I feel your pain. At my current job I am in exactly the same situation. No source control, no seperate development environments, and lots of very crufty, very old, very non-self documenting code. I'm currently 1 of 2 programmers, after the previous crew of 5-6 was let go last year. I inherited code that used libraries rather than modules, lots of if/else constructs, use of no templates or a poorly designed & documented home-grown template system, and worst of all, hard coded paths to said libraries. It is certainly a challenge, but then I like challenges since they keep me from being bored. :-)

      • Move slowly - Start as soon as you feel your thoughts will get traction with your fellow developers. You can't change the world in a day, week, or month. I'm lucky in that I am at a small shop & can effect change more quickly. But remember that you are ONE person among many, and you have the least seniority & reputation being The New Guy. Start with one thing first. I would suggest source control. Anything is better than nothing, so CVS will probably work nicely.

      • Be tactful in your critiques. As many have said, programmers tend to have big egos & if you say "this code just plain sucks!" you are going to get nowhere fast. Constructive criticism is the key here. Give them the good, and then the bad. Always be sure to give praise where appropriate. You will get better results if you build your collegues up before you tear them back down.

      Good luck in your new job. Sounds like you have plenty of challenges and work ahead of you. :-)

    Re: OT: Job Advice
    by feloniousMonk (Pilgrim) on Jun 25, 2002 at 18:20 UTC
      Also remember that the coder who came before you may very well be your current superior now -
      who in today's job market may do what he/she can to keep any threats to his/her position as far away as possible...

      Dealt with this before, it can get very, very ugly

      felonious --
    Re: OT: Job Advice
    by Anonymous Monk on Jun 25, 2002 at 19:01 UTC
      I haven't read "The Pragmatic Programmer", but that sounds like a heck of a good idea.

      That being said, bear in mind that not everyone holds themselves to the same high ideal that you apparently hold yourself. And not everyone has to. Until you become a supervisor or technical lead, you are only responsible for your won work, and that is the best place to focus your energies. I recognize the code you are trashing there, not by having seen that exact code, but by having seen very similar code at my present employer.

      The fact is, we have some great programmers, very talented people who would dearly love to go back and re-work some of the code that they wrote when first learning perl. I'd love to have the luxury of going back and re-doing a lot of my code. Hwever, reality dictates that since "the old code works", we focus on what is before us today,and if we have some spare cycles at some point, we go back and clean up some of that old stuff. Or when the requirements change and we have a chance to get back in there, we clean it up.

      Pick your battles too. I'd say that version control should be the first thing you attack. You can probably enlist the aid of the sysadmins in getting CVS installed on a development server, unless the sysadmins are in on the crappy code conspiracy too. They usually love the idea of not having to restore things from back up if they don't have to. Failing that, install it in a private bin directory and just start using it yourself.

      As to guns-a-blazing, I would never even consider it. Not my style at all. I just try to write the best code I know how, influence not force, and flow over and around the rocks, wearing them down rather than trying to move them. Now after a year on my job, I'm getting promoted and being made technical lead on my team.

    Re: OT: Job Advice
    by Anonymous Monk on Jun 25, 2002 at 20:14 UTC
      You touch it, it's YOURS. If you don't touch it, you can still blame problems on your predecessor. Remember to CYA first, fix the code second.
    Re: OT: Job Advice
    by dwiz (Pilgrim) on Jun 26, 2002 at 07:46 UTC

        Ah, Mr. Spolsky, I don't think I'll ever understand why so many people link to his articles. Quoth the Joel:

        Get better people into the team. Get involved in hiring and interviewing, and recruit good candidates to join the team.

        Okay, if you're involved in hiring people, you probably aren't a grunt. If your grunts are doing your hiring, your company has major problems.

        At some point, one of these geniuses will spend two weeks writing a bit of code that is so unbelievably bad that it can never work. You're tempted to spend the fifteen minutes that it takes to rewrite the thing correctly from scratch. Resist the temptation. You've got a perfect opportunity to neutralize this moron for several months. Just keep reporting bugs against their code. They will have no choice but to keep slogging away at it for months until you can't find any more bugs.

        Does that seem like a bad idea to anyone else? It wouldn't exactly create a good team environment would it? If somebody's code sucks, help them improve it. This can easily be done in a non-threatening way. Don't forget to look at their side of the issue as well, who knows, you might be the "Bozo" programmer.

        Look for ways to get out of this environment. Take a laptop to the company cafeteria, where there are lots of tables that are empty most of the day (and nobody can find you). Book a conference room for the whole day and write code there

        Okay, so if you're new to a company make it very difficult for anyone to find you? Again, great way to build a good environment and get people to listen to you. Not to mention wasting valuable conference room time that could be needed for useless meetings.

        Mind you, his first point wasn't so bad "Just Do It" but I guess Nike wouldn't like it if that was his entire article. Too bad, it would have been far better advice.

          Okay, if you're involved in hiring people, you probably aren't a grunt. If your grunts are doing your hiring, your company has major problems.

          Not necessarily. I've worked with a couple different companies that have their programmers chat for a while with applicants before hiring them. Company gets more data about what the applicant knows, applicant gets a more realistic view of the company, and both sides get more of a sense for personal fit. Everybody wins.

          Good points ++.

          Ah, Mr. Spolsky, I don't think I'll ever understand why so many people link to his articles

          Just for the record I am not a card carrying Joel fan. I had merely read the article a while back and thought it might have provided some food for thought.

          Mind you, his first point wasn't so bad "Just Do It"

          Some of his other points weren't so bad either. The main reason I linked to the article was because I remembered that it addressed the issue in the main post of:

        • Lack of sensible development environment (no testing/staging area, no version control, etc)

        • This hadn't been discussed much in the thread (The article mentions bug tracking, specs, cvs).

          I also think he redeems himself on some of your points in this paragraph.

          None of these strategies work if you're not really an excellent contributor. If you don't write good code, and lots of it, you're just going to be resented for messing around with bug databases when you "should be" writing code. There's nothing more deadly to your career than having a reputation of being so concerned with process that you don't accomplish anything.


          -dwiz

    Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Node Status?
    node history
    Node Type: perlmeditation [id://177032]
    Approved by Albannach
    Front-paged by wil
    help
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others examining the Monastery: (10)
    As of 2014-09-23 13:33 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      How do you remember the number of days in each month?











      Results (221 votes), past polls