Resume Help Pls



  • I know that there are probably a lot of people here who are involved in
    the hiring process for programmers and such.  I want to get some
    opinions on the following.  I'm just finishing up a project that
    I've been working on for just over a year.  There are only two
    programmers on this project, and the other guy mostly did database
    stuff.  90% of the coding was by me. 



    Well, I downloaded something to count lines of code and found that
    there are 15,000 lines.  Does that seem small for something that I
    worked on almost full time for a whole year?



    They fired my boss for political reasons.  The manager guy they
    replaced him with doesn't like me a whole lot.  I put on my
    performance evaluation that the total project size was 15,000 lines and
    he wrote back: "at 50 weeks a year, 40 hours a week, that's 7 and a
    half lines of code an hour, or about one line of code every 8
    minutes."  So what he's saying is, that's nothing to brag about.



    Well screw him!  There was a lot of design and documentation and debugging and so on.



    But he's got me spooked. I don't want to put on my resume that I worked
    on a project and that the size of it was 15k lines if the people who
    look at my resume are going to think, "so what?"



    So my question is, what should I say as to the size of this project on
    my resume?  Should I say it was a large project?  Should I
    give an exact number?




  • Well, I heard somewhere that the average output for a programmer in the C-related languages (C/C++/C#) is about 30 lines of code per day.  So it sounds like you're ahead of the game.  :)

    But, no, I wouldn't put the size on the resume.  Just describe some of the key features, particularly if you did something "unique".



  • 15.000 LOC in what language? And what type of project? And personally I think this information is quite useless to some manager dude; to the lead coder it might give an estimate of your skills, yes. But if that lead coder is any good then he won't hire/fire you because of the number of LOC you can type out per hour. A programmer is not a secretary.



  • I would be more concerned with the quality of the program than I would be concerned about something as deceptive as linecount.  We've seen countless PBTL WTFs.



  • @GalacticCowboy said:

    Well, I heard somewhere that the average output for a programmer in the C-related languages (C/C++/C#) is about 30 lines of code per day.  So it sounds like you're ahead of the game.  :)

    But, no, I wouldn't put the size on the resume.  Just describe some of the key features, particularly if you did something "unique".

    Agreed. Size doesn't matter. Um, I mean, LOC is a good metric for some things, but determining a programmer's quality isn't one of them. I mean, if you use a code generator to churn out 10,000 lines of WTF in a week for a simple, well-defined project, are you better than a device driver developer working with minimal specs who manages 200 lines of custom code?

    Just describe the features, how you were involved (design, development, documentation), and what it meant to the company (if anything, and if good) and leave it at that.

    And good luck!



  • ok, thanks for the insights.



  • If they want to pay you by the line, don't take the job because they have no clue what makes a good program or a productive programmer.



  • LoC is a dumb thing to base an evaluation upon.



    I spend my days wondering why the people who wrote the code I
    maintain would have spent more time to think and less to write ridiculously complicated and ill-architectured crap...



    Good code is short, simple and straightforward. Whenever it seems you
    cannot achieve this; it means you should stop and think again, which
    will you figure out what to move away to another class/function/level
    of abstraction.



    There is almost always a better way, and it usually not involve bloating the number of LoC but rather reducing it.



  • Second phrase of previous post is obviously ill formed.

    You know the drill ("biggest WTF is...", can't preview, can't edit, why does telligent systems hate us, etc.)



  • I wonder if any refactoring was done at all?  How could the number of lines of code ever be a determination for how much work was actually done?

    I've done my share of hiring developers.  It never occurred to me ask a developer how many lines of code he or she could write per hour.

    Heh.  Freaking managers. [;)]



  • Just to clarify, the issue with my resume wasn't one of LOC/day.  It was an issue of, "how big was the last project you worked on?"  Using LOC to answer the "how big" question seemed reasonable to me.  I wouldn't think of using LOC to answer the "how productive are you" question.  It's just that when I tried to use it to say, "hey look at how big this project is" my supervisor responded with, "you've got nothing to brag about, it took you a too long to write it."

    I just wanted to see if anyone here would have a similar reaction, because I wouldn't want to have that on my resume and turn a lot of people off.  You know, there are a lot of stupid little things that you can have on your resume that just scream, "I'm an idiot!"  Things like, "skilled with all versions of MicroSoft Office"  Would you hire a programmer who would waste space saying something like that?

    So anyway, that's what I was asking.

    A number of people have asked questions about measuring programmer productivity.  I don't think that there is a simple answer, but I would start by reading Fred Brooks, The Mythical Man-Month
    http://www.amazon.com/gp/product/0201835959/104-6138965-0376742?v=glance&n=283155

    And just for reference, if I was ever in a position to hire a project manager, I would ask if they'd read this book and wouldn't hire them if they hadn't.  It's the project management equivelent of Kernighan and Ritchie.  It's what everything else is based on.



  • LOC is loosely related to project size, but there is so much noise in the curve that you can't really rate the project sizes with more accuracy than "tiny", "small", "medium", "large".

    A Large project will likely have more LOC than a Tiny project, but there's probably something like 50% overlap in LOC between Medium and Large, so that Medium projects, judges by LOC, may seem bigger than Large projects, and vice versa.

    So LOC in and of itself really isn't much of an indicator of project size.



  • I good week for me is when I remove 1000 lines of code from a project.  I've seen more WTFs in one project at work than are on this whole site.  Fortunately, all the WTFers don't work here any more, so the count keeps going down.

    As for making lines of code, If I point our code generator at a database and push a button, it spits out few thousand lines of code.  I guess I can take a week off!!!!



  • You could develop a code generator that spits out 5MB of characters that [i]look[/i] like compiled code when read back in with a text-editor. >:)

    - LOOKIT WHAT WE DID.

    - Now run it.

    - OH SHIT



  • @tofu said:

    Just to clarify, the issue with my resume wasn't one
    of LOC/day.  It was an issue of, "how big was the last project you
    worked on?"  Using LOC to answer the "how big" question seemed
    reasonable to me.  I wouldn't think of using LOC to answer the
    "how productive are you" question.  It's just that when I tried to
    use it to say, "hey look at how big this project is" my supervisor
    responded with, "you've got nothing to brag about, it took you a too
    long to write it."

    I just wanted to see if anyone here would
    have a similar reaction, because I wouldn't want to have that on my
    resume and turn a lot of people off.  You know, there are a lot of
    stupid little things that you can have on your resume that just scream,
    "I'm an idiot!"  Things like, "skilled with all versions of
    MicroSoft Office"  Would you hire a programmer who would waste
    space saying something like that?

    So anyway, that's what I was asking.




    How big a project seems will depend on a person's experience.  For
    example, I would think a 15KLOC program is small.  The SLOC count
    of the systems I have worked on is 200K - 1.5M.  Now these are two
    different things and it is comparing apples and oranges.  The
    systems I have worked on have been around for years and many people
    have come before me to work on them and many people will come after I
    am long gone.  On the other hand it sounds like the design and
    development of the 15KLOC program was mostly your responsiblity and
    there is a big difference in the experience gained in both of these
    situations.



    For a resume, I would think that what experienced you gained and what
    skills you have picked up would be of more importance than the size of
    the project.




  • As already made quite clear: KLOC count is useless to measure productivity.
    Yet it's used frequently in especially large organisations anyway, because it's such an easily measured quantity and upper management does tend to think that more == better for everything.

    For example, on one project I was involved in someone'd sold the customer a commitment to deliver 100 KLOC per release (for about 5 KLOC per programmer per 2 months).
    For one release we did a major cleanup of our codebase removing some 25KLOC of dead code, causing a productivity of -15KLOC for our team (which was about 20% of the programmers).
    We immediately got a stern warning from company management that we HAD to become more productive quickly or we'd face disciplinary action. Project management had complimented us on a job well done just days earlier... Obviously someone up high was looking only at the numbers and not at the results.

    Next release we produced tons of code by simply inserting a lot of superfluous commands and statements... Now company management was quite happy, project management never knew.



  • I was told by a CS professor programmers typically write between 5-8 lines of code a day that are sound.  e.g. they're not refactored in anyway, moved, deleted, etc.



  • IMO, 15K lines is reasonably large enough not to count as a "toy project". It's most likely also productive enough for one year of work.



  • LoC would not a good metric.

    I think to ease your evaluation, the person who would be hiring would be interested in

    1. Type of Project
    2. Features (and some design elements)
    3. Delivery or Deployment
    4. Performance



  • I never make reference to the number of lines of code.  I've done projects that have been a few hundred lines all the way up to over 100K lines. If I was being evaluated by the number of lines i'd be in trouble... I have a habit of writing one liners that do what could be broke up into 5 or 6 lines :P



  • @tofu said:



    So my question is, what should I say as to the size of this project on
    my resume?  Should I say it was a large project?  Should I
    give an exact number?


    Well, I could definitely be wrong, but what I'd do is not state the actual size of the project; I'd say something like "designed, coded and implemented a major project; I worked on this project full time for over a year" or something like that. I'm pretty tired and that's a pretty badly worded sentence, but you get the general idea.



  • Just describe the features, how you were involved (design, development, documentation), and what it meant to the company (if anything, and if good) and leave it at that.

    Please add "testing" to that list. Presuming you did some testing. (You DID test your code, right?)

    That makes you look like you care about quality, accounts for your time, and helps justify your debugging time.



  • @Code_Dark said:

    @tofu said:


    So my question is, what should I say as to the size of this project on
    my resume? 


    Well, I could definitely be wrong, but what I'd do is not state the actual size of the project;


    I worked as a Quality Lead for a couple of years and we ran into this sort of LOC babble too often for comfort. One of our pet peeves was that Management kept claiming that QA should be finding N bugs per M lines of code.

    Several things are wrong with concentrating on LOC:

    1) If you tell an engineer something like "we expect N bugs per M lines of code" any competent engineer will comply. If necessary, s/he will insert bugs. Similarly, if you say you expect X lines of code output per day, the developer will figure out how to give you what you expect. The code may not be tight, or tested, but by golly you'll get X LOC/day.

    This is not what you want. Stay away from LOC as a metric.

    2) Management  got that particular bugs per loc "metric" from some research on C code. We were writing C++.

    Language matters. One line of Perl, Python, or Ruby may equal many lines of C or hundreds of lines of Assembler.

    3) Software engineers and programmers have to do many things: Design, Code, Test, Debug, Document, Redesign. And, many times, you have to Stop and Think —  take your hands off the keyboard — think about about design, about algorithms, about the Right Way To Do It. Some days you can churn out code (oh, but that's just a giant case statement). Other days, you write one small, tight, elegant, recursive function.

    LOC is a tiny, nearly unimportant, aspect of what you do.

    Don't tell me how many LOC you wrote. Tell me what you did.



  • @vlb said:

    One of our pet peeves was that Management kept claiming that QA should be finding N bugs per M lines of code.


    I'm not aware of any software reliability growth models that make use of LOC (probably for the reasons you state).  Time is what you want to look at.  Graph failures/time and ignore the size of the system.

    you should tell them that.


Log in to reply