Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

Keeping, and advancing in, your job

by Tanktalus (Canon)
on Mar 03, 2005 at 18:15 UTC ( #436319=perlmeditation: print w/replies, xml ) Need Help??

One major difference between the open-source zealots on some other sites, and the open-source advocates here seems to be one of employability. In other views of open-source software, all software should be free - and often that means that programmers should not be paid for programming, but for everything around programming (services). That's a fine view, but as a person being paid to develop software, it's one that my family's mouths find hard to swallow (pun not fully intended).

Here, we like our software free, but we like our efforts to be paid, too. The bottom line is getting the job done, and we have a multi-purpose software tool which we like using to get that job done. Some people may get a bit religious about whether that tool is "perl", "Perl", or "PERL", but a rose by any other name would still have just as many oddities.

It's not that the perl community seems to be averse to open source, or to commercial source. As long as we get to finish our jobs, look like superstars (sitting on the shoulders of giants), get paid, and go home to spend time doing what we really want, we're happy. Too often, that still seems to be programming in perl, but hey, off the clock, it's whatever you like.

So, in the spirit of this employability, I offer:

Key things to keep in mind when working for others.

One of my many duties is to bring junior members of the team up to speed. Junior here can involve temporary employees (contractors), intern students (whether 4 month, 8 month, or 16 month terms), new graduates, other new hires, or even simply members of the team who have not been on the team as long as I have. So I get asked for a lot of advice. Some of the advice is specific to our company, and thus is probably of very little interest to a wider audience. However, much of it is likely just as applicable to PerlMonks who are in those junior positions wondering what they need to do to get ahead.

  • Performance. Your boss wants to look like his/her team is ahead of the curve. You want to look like you're ahead of the curve, too. Even if you are the hardest person in the company to talk to, if you consistantly get what needs to be done faster, cheaper, and more reliably than anyone else, you'll be invaluable.

    My personal method of accomplishing this means that I only do things twice: the first time to learn it, the second time to teach the computer to do it for me, and after that, I should never need to do it again.

    This also ties in closely to using the right tool for the job - in my work, that's usually perl, but sometimes it's shell scripting.

    Note that this actually has very little to do with the performance of your code, unless your job explicitly is "to improve the performance of the code." And note that jobs are rarely going to say "to write ultra-fast code", but "to improve the performance of existing code." In other words - "It works, now speed it up." So focus on your actual job, getting actual requirements accomplished, before you worry about things outside of the scope of your job. That is the core of the performance your boss wants. The goal here is to get everything your boss wants so that you have time to get what you want. Many bosses will be happy to see you expand your role, as long as it isn't at the expense of the role you started out with.

    Theoretically, in a positive company, high performance equals regular (and larger than average) raises. It's all about the money.

  • The next biggest thing is communication. This is primarily dealing in the language of the community you're in. At PerlMonks, that means English. At work, that may mean English still, or it may mean another language. You need to express your ideas in a way that others can interpret to mean what you are trying to convey. Simply - say it properly, so that I get what you mean. That said, if you say something improperly but the person you're talking to understands you anyway, communication still has been acheived. If, however, you make the listener work to figure out what you mean, they're not going to stick around any more than they have to to get their work done - possibly even less.

    Grammar is important. Spelling, too - so much communication is done via email nowadays that you can't get around it. Relying on a spellcheck may work, but it is slow. It's much better to be able to get spelling right without the spellcheck (see "performance" above). I'm not trying to advocate purism in language - just communication. The odd spelling mistake (or typo) or grammatical error is not an impediment to communication. A complete lack of punctuation, proper capitalisation, and l33t sp33k - these are show-stoppers for communication.

  • In my experience coding, debugging is more important than coding. Anyone with a mail-in degree can write code. Getting it to work right, and understanding why it works right, are the difficult parts. This plays into the performance requirement above - you need to be able to get working, reliable code out quickly. And if you're stuck for a day or two trying to figure out why one ten-line sub isn't working, your performance as a whole is going to suffer.

    If you have a star debugger on your team, ask him/her for tips. Don't think that they will treat you badly and thus be scared to open up your weakness in debugging to them. They'll be happy to teach this skill, as long as you're a willing and honest student. Why? Because it will help their performance in that they won't need to help you debug every other problem you encounter. It's still about the money - for you and for them. They aren't doing it for your money - they're doing it for their money. But that's ok. (Also in this, you need to be able to communicate with this person where your problems lie so they can help you.)

These are some of the more obvious work-related issues I've seen with new hires where I work. Anyone have some other key points to add?

Replies are listed 'Best First'.
Re: Keeping, and advancing in, your job
by dragonchild (Archbishop) on Mar 03, 2005 at 19:29 UTC
    This is for everyone:

    You are hired on at a multi-billion dollar company - their daily profit is higher than your lifetime gross pay. You are assigned to an older system that is a major service for a large, very profitable system. Surprise, surprise - they don't use strict. Do you

    1. Just do your job within the restrictions and keep your mouth shut
    2. Make a huge stink about strict and refuse to make any changes because "it's too dangerous"
    3. Do your job for a few months, then quietly mention to your immediate supervisor while you're having lunch that using strict would be a good idea

    Less than 10% of all developers will do the latter option. Remember - this program was working long before you go there. It makes lots of money. Therefore, it's got to be doing something right.

    Furthermore, change is expensive, especially without strict, testplans, and the other trappings that good developers like to have around them. Management is right to be wary of you. If you owned the company, you'd be wary, too.

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

      Less than 10% of all developers will do the latter option. Remember - this program was working long before you go there. It makes lots of money. Therefore, it's got to be doing something right.
      So I take it that option 3 is what you are advocating as a reasonable approach, while option 1 and 2 are less reasonable. I think that all of those options have upsides and downsides:

      • Option 1 upside: Get paid while it works.
        Downside: uncaught system bugs get you fired, perhaps.
      • Option 2 upside: Low stress at work.
        Downside: No job.
      • Option 3 upside: Get paid while it works.
        Downside: uncaught system bugs get you fired, perhaps.

      So I don't see a lot of difference in 1 and 3 until after your discussion with the boss. Even then the defacto corporate programming methods/policy isn't likely to be changed by your middle manager. After all you said it has been working the old way making $$$ so why change?

      OTOH, making changes to the Modules you modify, and applying more sane programming practices yourself, quietly, over time, would seem to be an option 4 which would be compatible with option 3 and perhaps more likely to change the defacto corporate programming practices? No?

      Nothing is too wonderful to be true
      -- Michael Faraday

      I'd prefer to add a fourth option. Go IMMEDIATELY to my supervisor and say something along the lines of, "You asked me to look at this. Mummy always told me never to leave 'strict' out, but my guess is that it would mean a complete rewrite, taking x months. Do you want me to do that, and if so, when?" This means that the supervisor is in a position to balance resources and projects, which is what I would expect a supervisor to be there for. The answer might tell you a lot of things, for example,

      "Bleep off & mind your own bleeping business": this is good advice to follow. Another employer should be sought ASAP!

      "What's strict?": you have an opening to become the indispensible perl guru in this firm.

      "We can't afford the time": it'll be more expensive later.

      Granted, I'm a beancounter, but I do seem to spend a lot of time on computer projects. Even in the beancounting world, the general approach is appropriate. Tell the man who makes the decisions what you think should be done and what resources it will require. Then let him do his job and decide. If you're worried about CYA, put it in writing. But I don't like 1 or 3, because you are keeping quiet about something other people need to know, and I don't like 2, because you are criticising other people's work, and they won't like it. You are painting a target on yourself.

      One final point, & I'll shut up. Always over-estimate the resources you will need. Not wildly, but leave a margin for things to go wrong. They will!

      4. Quietly make a copy of the system. As part of normal maintenance work, modify this copy to use strict and be 'safe' for testing. Run perl tidy on it and add comments as needed.

      Any script I receive goes through this process. For me, it's the most efficient way to adopt and start maintaining a system.

        Have you ever modified a 10_000 line module to use strict? You literally have to rewrite it, and everything else that uses it, from scratch. (This can easily get into the 100's of thousands of lines of code.) There is often no other way.

        Oh - does your quiet time also include writing the test cases? Refactoring without a test suite is like getting very drunk then tightrope-walking across the Niagara falls. Not something most of us feel is safe ...

        Being right, does not endow the right to be rude; politeness costs nothing.
        Being unknowing, is not the same as being stupid.
        Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
        Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

        Quietly make a copy of the system.

        Yeah, and then later get charged with "felony theft", by some executives trying to cover up their "secret sale" of the scripts.

        I'm not really a human, but I play one on earth. flash japh

      From my view, there is one more option that you didn't mention here. That, IMHO, would be:

      4. Use strict in your own programing and quit worring about others programs (since it works) until the software breaks or you are required to modify it.

      You do make a very valid point.

      UPDATE: Sorry, this was in response to dragonchild's response above. Seems that his node has brought about much good debate! Luv, it.


      You're so sly, but so am I. - Quote from the movie Manhunter.
      I've been there. But I recommend a somewhat different path:
      • Add use strict;
      • Write a one-liner that takes all of the resulting error messages and converts them into one massive, insanely ugly our ($x, $Time, @Names, $CurrentId, ...); statement and paste it into the top of the code.
      • Add lexical blocks beginning with no strict 'refs' around the remaining problem spots.
      • Go make the changes you needed to make in the first place.
      • Whenever you get stuck on a problem, convince yourself that it's somehow caused by reusing variables or some other idiocy that use strict would detect if you hadn't added that monstrosity to the top of the file.
      As a result, whenever you get frustrated from struggling endlessly with a nasty problem, you'll waste half an hour or so eliminating those awful global variables. Eventually, you'll get to the point where you're more sick of cleaning up that crap than you were sick of chasing after the original problem, and you'll go fix it. Over time, all those globals will gradually disappear.

      The bad side of this is that cleaning out the global variables will never fix the problem you're facing at the moment.

      The good side of this is that you'll discover and repair dozens of potential problems, and actual problems that people have learned to live with or assumed were intentional (albeit stupid) design decisions.

      The so-so side of this is that once you've made everything properly strict-safe, you'll realize that your new version really isn't substantially better than the original. The mindset that produced that many stricture violations is unlikely to have done a great job with the other parts of the system. But you will have a good understanding of what those problems truly are, much better than the initial knee-jerk reaction of disgust that you started out with. And that will enable you to start intelligently refactoring pieces without breaking the overall script (or needing to introduce so many adapters and bandaids that your "improved" version won't be.)

      At the risk of offending the fanatical refactoring devotees, I will also assert that even if you manage to refactor the crap out of the code, it's never going to be pretty. It is possible to turn a chicken into a horse by changing one piece at a time, but any sane programmer will start by throwing out the gizzard. As a result, he'll end up with a two meter tall winged herbivore that sleeps standing on one foot and outruns a greyhound -- but dies of starvation. Doing it right requires designing pretty much the whole horse in advance, and if you're going to do that, it'd be less work to just build the damn horse.

      But if you do, you won't have time to feed the chicken.

Re: Keeping, and advancing in, your job
by husker (Chaplain) on Mar 03, 2005 at 20:57 UTC
    Even if you are the hardest person in the company to talk to, if you consistantly get what needs to be done faster, cheaper, and more reliably than anyone else, you'll be invaluable.

    This is a dangerous generalization. Some corporate cultures will accept a higher level of eccentricity (and anti-socialism) in exchange for higher productivity. Other corporate cultures consider ability to communicate and work as a team as part of the definition of productivity.

    In short, if you can't work with others, you put yourself at a large disadvantage. There are very few places where you can get away with being an "island unto yourself", whether that's because you are a boor, a chauvinist, smell bad, are pathologically shy, won't or can't communicate well, or what-have-you. Other co-workers will not be able to trust you, so why would they consider you a teammate or mentor?

    And that's not even getting into the "political" ramifications of being non-communicative. Many decisions made by your employer will have other factors besides just your productivity. "Works well with others" is always a positive thing to have on a review.

      You're right - I did state that a bit more extreme than I meant to. That said, one of the most uncommunicative contractors we've ever had, was also among our most productive. He would be nearly impossible to talk to, but he'd come back 15 minutes later with the solution implemented. He was amazingly productive. The only reason why he's not here anymore is that our company has a policy of not holding on to a contractor more than 2 years. He was so productive, we had him for 3, fighting for an exemption from the rule. Each additional year takes the fight higher up through management, and is thus that much harder, so 3 was all we could do. Uncommunicative, and extremely productive.

      At the time, I had a student working with me who went to the contractor with a problem with the contractor's code (the student was testing it). The student asked a simple question, and the contractor said, "Why do you ask me these things? You might as well ask yourself!" The student left the contractor's office with his tail between his legs. 15 minutes later, the contractor came to our office (the student and I shared an office) and said he had a fixed version put up on the network. Needless to say, it worked. That was seven years ago - we still all laugh about it to this day (the student is now a permanent employee - he was very productive as well, and had the added benefit of better communication skills :-}).

Re: Keeping, and advancing in, your job
by johndageek (Hermit) on Mar 04, 2005 at 14:44 UTC
    One additional point is attitude.

    Be positive! Everyone likes to work with an upbeat person. (ok ok I accept the whipping for the generalization for saying everyone). You can still pick holes in plans, just be sure to offer options. Remember to play by the "rules" e.g. If the team, group or gang agrees to select a solution by majority, and your idea is not selected, YOU USE THE TEAM SOLUTION, it doesn't matter how much better you think your solution is. "b...b...but whhhhyyyyyyyy?" the new (hire, grad, contractor) asks, lower lip atremble.

    PAY ATTENTION HERE - because many times the old guys with their old slow to change mentality understand the system they have been working with MUCH better than you do, so they understand things like ramifications of a given change. Learn from them - professional paranoia can be taught in school, but the lesson rarely hits home until a production system you were entrusted with craps out because of a quick fix

    I lied, there is a second point. ROI (return on investment). A company, your company, exists to make a profit. Remember if they do not profit, you do not profit. So, how does that affect me? If this question makes sense to you - Read on, please.

    You are an investment. (don't trust me, speak with a couple of people to find out what you cost, just to hire. Records set up , payroll and government reporting, corporate portion of your taxes etc. accounts set up. Oh yeah, remember to factor in benefits). Most new hires do not result in a gain for six months to a year. "But I am writing code right away, so I must be creating profit for the company!", new hire comment. "Ahh grasshopper, you also need guidance and advice (please note the word need, get the guidance and advice this is part of the corporate investment in you) which uses your time as well as the time of some of the most experienced people we have for non-direct gain. After six months to a year, you will be sufficiently versed in your company's systems to be able to start making better decisions with less dependence on others, in other words you will, hopefully, be close to pulling your own weight and improving.

    Sorry, I was going to discuss ROI. Return on investment is simple. For the money (as used as a measure of time, resources, effort and so on) I invest, how long will it be before I recoup my investment, and begin to see a return beyond that. A good rule of thumb for management - if your roi is a year or less, it is a no brainer, go ahead and do it, 1 to 2 years, the long term gains must be carefully evaluated, and longer than 3 years the potential gains must be huge and carefully investigated.

    A simple example:
    We have 2 employees a secretary (pay is $10 per hour) and a programmer (pay is $20 per hour). Rough rule of thumb, employee cost is approximately double their hourly pay.

    The secretary spends 2 hours per week doing a repetitive boring task. The programmer sees that they can automate the process so it will only take the secretary 1 hour a week, and it will only take 80 hours to program (we will leave the art of estimating time for another discussion).

    Oh, oh, math time.

    Cost of secretary to do the job as it is now per year: $20 per hour times 2 hours per week times 52 weeks in a year = $2080 per year.

    Cost of programming time for the gain: $40 times 80 hours = $3200.

    Value of secretaries time to be saved (about half) = $20 times one hour per week times 52 weeks in a year = $1040

    ROI = Cost of programming $3200 divided by $1040 annual gain for the investment = 3.08 years

    This project will be scrapped. The rational is as follows: You - our programmer investment can be put on projects with a MUCH higher rate of return than this. We can continue to pay the secretary to do the work, while the programmer works on a project with higher returns.

    Now let's take a slightly different view - what if there are ten secretaries that do this task at the same frequency and duration, all other variable stay the same.

    Value of secretaries time to be saved (about half) = $20 times one hour per week times 52 weeks in a year TIMES 10 secretaries = $10,400

    ROI - Cost of programming $3200 divided by $10,400 annual gain for the investment = .308 years

    This project will likely be approved, because after four months, this project will have paid itself back and start to earn money for the company.

    It sure sounds like it is all about the money, doesn't it? Remember, money is only our agreed upon medium of exchange, so as long as the company makes more, presumably it will pay you more and so on.


      Rats, you beat me to it. I can't agree more, John. The days of coding geniuses who are jerks being tolerated are vanishing rapidly, especially in broader organizations. Being a misanthrope or a 'hole is a mistake in today's world.

      There are many programs available for those who want to improve their attitudes. I recommend the Landmark Forum, although I will agree with many that their self-congratulatory feed-us-more-students attitude gets old. I got a huge boost from the Forum back in 1985, and I'm much better for it. There are other programs with similar self-improvement foci, such as Darshan Shanti's <plug: a personal friend>.

      The key to all of them is that you are in charge of your attitude, and your attitude is the filter through which the world and its other denizens shows up for you. Computers are much easier to debug than ourselves, but the task is worth doing! For yourself, for your cow-orkers, and for your coding productivity and creativity.
      Be positive! Everyone likes to work with an upbeat person.

      But make sure you do not exagerate. If you move from the states to the old continent, calm down! If you move to one of the ex-socialistic countries calm down even further. It's OK to be positive, just don't make too much fuss about it. Even if you are the boss, calm down. We've acquired alergy to the prophets of bright future, your boasts about the company's profit and future will not go down well.

      We'd like to help you learn to help yourself
      Look around you, all you see are sympathetic eyes
      Stroll around the grounds until you feel at home
         -- P. Simon in Mrs. Robinson

Re: Keeping, and advancing in, your job
by g0n (Priest) on Mar 04, 2005 at 11:34 UTC
    A couple of other points I'd like to suggest

    • A lot of people in this business jealously hoard information to themselves, apparently thinking that if someone else learns what they've learned their job will be threatened. Obviously this doesn't apply to perl monks, or they wouldn't be here! The opposite is true - sharing what you know is the only way to enhance your reputation. Don't worry about losing your advantage, just make sure you're constantly learning.
    • Following on from that, its always worth learning something new. A different programming language, a different methodology, project management skills, a different programming area (database, network, web etc etc etc).
    • Learn to make realistic estimates of the time needed to do a piece of work, even if you're currently in a job where you don't need to, and always factor in some contingency time.
    • Following on from that, make the distinction to yourself and others between elapsed time and effort time. If you say a piece of work will take 3 days, you'll be expected to finish by thursday. If you say a script will take 3 days effort you won't be made to look stupid by unresolved dependencies like, for example, access to a particular machine, completion of a spec etc.
    • Both documentation and commenting are important. One is not a substitute for the other. Getting a good reputation depends at least as much on other people being able to read and maintain your code as writing clever, fast, bug free solutions, if not more

Re: Keeping, and advancing in, your job
by Mugatu (Monk) on Mar 03, 2005 at 20:28 UTC

    Good post, I only have a small comment on the following:

    all software should be free - and often that means that programmers should not be paid for programming, but for everything around programming

    I noticed you said "often" there, which takes some of the wind out of my sails, but I still think this is a common chain of logic, and I think it's slightly wrong. There is nothing inherent in free software that prevents a programmer from being paid to develop it. The common licenses simply require the software to be modified and redistributed freely.

    Likewise, a company who paid a programmer to develop free software still gets a return on their investment. Namely, they get to use the software that programmer developed. Keep in mind that not all companies who need software are in the business of selling software.

    Thus, I do not see any reason that it is neccesary to develop proprietary software in order to be paid for the time of developing it. That is not to say that market forces are currently in favor of a paid-for-free-software type arrangement. I have not taken a survey, nor do I really have any experience to back it up. I am merely talking about theoretical possibilities. :-)

Re: Keeping, and advancing in, your job
by holli (Monsignor) on Mar 04, 2005 at 03:43 UTC
    Many bosses will be happy to see you expand your role, as long as it isn't at the expense of the role you started out with.
    I have different experiences. Rule No. 1 in my current workplace (and in other companies, too - from what I hear from colleages) is:

    Keep a low profile! Don't do anything you have not been told. The more you do, the more likely is that you make an error somewhere. The more you invent, the more likely is that you fail at some point.

    One negative impression the management gets about you weighs far more than ten positive. It's sad, but inevitable.

    holli, /regexed monk/
      I would not enjoy working in a place that discourages innovation and reasonable risk-taking. How does anything ever get done in that environment?

      I hope that being in that environment does not squash all the creativity out of you, holli. If it begins to, get out!

      My condolences. I did put in the next sentence "in a positive company" ;-)

      I've been explicitly told not to do things (then I usually do them in perl). They end up on my next yearly review as positives (one example was that I was told explicitly not to start a website for our department, it's now running using CGI::Application, HTML::Template, and XML::Twig - and I've had it as positives on my yearly review more than once). I've been not told to do things (that is, no one said anything about having to do them, often no one knows I'm doing them), I do them (again, usually in perl), and, again, positives in my yearly review. That's called "a positive company". Funny thing is that my manager is an extreme pessimist.

      My justification for all this extra work? I'm Lazy. I tell my manager how much time it took to do it, and how much time I've saved because of it (I put our frequently asked questions on the site, and every time someone asks one of the questions, I don't answer it: I point them to the site. Saves hours of retyping). When he sees it in pure resource cost, and sees the cost savings, he likes it and is happy. My experience may be more abnormal than I hoped. :-(

Re: Keeping, and advancing in, your job
by idsfa (Vicar) on Mar 04, 2005 at 18:16 UTC

    <peeve type="pet">

    (sitting on the shoulders of giants)

    If you're going to allude to a quote, be aware of the context. Newton was not being humble when he wrote that -- he was flaming Hooke (a short man). Not a good example for a thread about keeping your job. ;-)


    The intelligent reader will judge for himself. Without examining the facts fully and fairly, there is no way of knowing whether vox populi is really vox dei, or merely vox asinorum. -- Cyrus H. Gordon

      Thank you for your educational post. I will keep this in mind for the future (I did try googling it to find more about the phrase before I used it, but did not come upon anything similar to your link). That said, just because I use "to be, or not to be" in a post that has no angst to it, or that is not suicidal, doesn't mean that those words aren't appropriate. Newton may have meant them sarcastically, with arrogance. I meant them more literally (hey, it's a great term, even if it can have many meanings). Of course, for the more arrogant among us (say, ... ME!), we may mean them more the way Newton did: building upon the work of others, we're geniuses. ;->

        Off-topic, but since you mentioned googling for more info and failing to find the given link, here are a couple of other links I thought you would find interesting:
        1. The Amazon page for the book "An Underground Education", mentioned as the source in the given link:

        2. The Wikipedia page on Robert Hooke. There's a section at the bottom mentioning Newton and the famous quotation:

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://436319]
Approved by Corion
Front-paged by herveus
[LanX]: It seems that PHP's official docs use "closure" and "anonymous function" interchangeably, even though their closures don't capture surrounding state without using the 'use' language construct.
LanX explains much cargo bla ...
[Eily]: what? I thought PHP was known for its reliable and consistent behaviour and documentation!
[LanX]: ... and a lot of pseudo Perl experts
[Eily]: though honestly, I'm sure I have seen people use closure to mean anonysub for perl as well
[stonecolddevin]: good morning friends
[LanX]: yes, mainly pseudo Perl experts
[Eily]: good morning stonecolddevin

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (11)
As of 2018-02-23 17:15 GMT
Find Nodes?
    Voting Booth?
    When it is dark outside I am happiest to see ...

    Results (304 votes). Check out past polls.