It's funny that other programmers feel the same way. I've never discussed it with other developers much, but I also derive a degree of satisfaction when refactoring if I leave the code with fewer lines than it had originally.
I'd say I'd enjoy deleting 200 lines to adding 200. It's like sitting down in a freshly cleaned room once you finally get your chores out of the way.
I had a job interview once where the HR rep asked me how many lines of code I wrote a week. I responded, "On a really good week -1000, I don't remember the exact figure." She was extremely confused by this answer and wanted me to give her a number. So she said, "I'll just put down 10,000."
This is also the interview where they refused to continue unless I told them how much money I made (which I don't do anymore). The justification they told me was that they weren't going to give me a 20K raise if I wasn't making that much right now. I didn't point out that they aren't giving me a raise, they are paying me market value based on what the position is worth (to oversimplify it).
I was offered the job but decided not to take it because that plus the technical interview made me wary.
Ha, I guess the developers they are hiring used to be sci-fi writers! But don't most writers say the hardest part is cutting words out of their book and cleaning up language?
P.S. I don't remember exactly what she put down as my "line-count" I was pretty annoyed at that point, it might have been a much more reasonable 5000. :-)
Are we counting the code my macros produce? As far as git is concerned I might be down a couple hundred to a couple thousand in a good week, but if we count macroexpansion, I'm rolling in the LoC.
Actually the truth is more like "I want to pay you as little as possible for you to work here and be productive." People who're worried about money are really bad at their job. They spend all their time thinking about something else. If someone is willing to accept a job on a salary that isn't really enough to live on (say, because they don't know how expensive the area is) then you should pay them more than what they believe their minimum is. Unfortunately hiring managers quite often fail to understand this.
Don't be so literal about it. I used to get defensive about that question too, but the truth is they aren't asking you how much you are making, they are asking you to start the salary negotiation so they can get a feel for what it's going to take to hire you and describe you adequately to a hiring manager. It's just an opportunity for you both to ballpark the situation and eject early if there's going to be a wide disagreement about comp. It can be equally advantageous to both parties if you use it properly.
No... there are recruiters who are a lot more invasive and pushy (and a couple employers I've run across).
"Proof of previous income" was required at one place I applied years back, and I've heard similar stories from colleagues. No, of course, I don't bother going forward in those situations.
"What are you making now?" is crass. The good recruiters I've worked with phrased it as "what are your salary expectations?" or "the range is $x-$y - are you OK with that?"
I've taken it literally in situations where they actually meant it literally. "We will not pay you $80k until you can prove you were making $80k at your previous job". Insane, but it does happen on occasion. How those companies ever manage to hire anyone... I'm not sure.
I guess you're right, that does happen sometimes. In those cases you also shouldn't be mad, though, because they just gave you a crystal clear sign they aren't worth working for.
I've gotten "I need a number for us to continue" multiple times.
"Considering your obnoxious lack of professionalism and the fact that your approach is apparently acceptable to the company, I'm not sure there's any offer you could make that I'd be excited to accept. But everyone has his price, so write down $500,000 for now and I'll decide how much to increase it after I hear the rest of what you have to say."
Just say "my salary expectations for this position is $XY0,000". I use it as an opportunity to set the ballpark for the negotiation. Sometimes bosses don't know what people are worth so they ask these kind of questions. Once we opened an office in a new country, and when we hired people, we asked them what they expected and gave them that + 20% because we really had no idea how much we should be paying.
Dude, that right there is the problem. They make a commission off your starting salary, so OF COURSE their primary concern is your past and future financials.
I disagree. Recruiters have a conflict of interest that often goes to the candidate's advantage and against their employer's interest. The higher your salary, the higher their commission. And employers are fine with that because a good hire is better than no hire.
For the recruiter, getting you in at 160k is twice as good as getting you in at 80k, and infinitely better than you walking away.
As a candidate that currently earns 100k, an 80k offer is worthless.
(Threatening to) walking away from a deal is one of the strongest strategies in negotiation. But that's the one thing a recruiter will never want you to do.
Candidate: High salary > no deal > low salary.
Recruiter: High salary > low salary > no deal.
You are right, that the recruiter has an even bigger conflict of interest with their employer. But that conflict does not mean the recruiter's interests are aligned with the candidate.
(One way to align any interests is generally to repeat games. That's why internal recruiters are usually less sleazy than the external kind: they are at least clearly on the site of the employer. And honourable employers have a reputation to defend---another repeated game.)
That is what you would expect, but they want to optimise both on commission and on throughput. If a slightly lower salary makes it easier to position you and get you hired fast, the cost of the lower commission is less than the cost of working on your case for a long time. It is the same with real estate agents. From that perspective, their knowledge of the market should theoretically set the price at the optimal short-term, hiring decision point. Nevertheless, for the employee and employer this is a long term relationship and it works out bad on both sides (lower salary than could be achieved for the employee, greater employee turnover for the employer.)
While a fair salary is ideal for all parties, optimizing for job satisfaction would be a wiser decision than optimizing for salary amount. Scoring a high salary may merely mean the new hire will be one of the first to be cut from the crew should the firm hit choppy waters... an outcome that recruiters do not need to care about.
What's really fun about that is that most people I interview, when asked "what are your salary expectations?" answer with "I'm currently at XYZ a year"
Yeah I mean it really depends on where you are applying to work. If you are trying to join as a senior member of an organization negotiations have way fewer rules, but if you are applying to Google etc. below a level 4 position it seems pretty reasonable to not need to assert your individuality as an engineer by disrupting the system since you'll be ending up with a standard package anyway. Sometimes you just need to learn how that game is played and play it instead of changing it.
The actual dollar value is usually literally zero sum, but if you have a family and need a $200k salary with specific benefits as a hard requirement it's going to be helpful to get that out of the way up front. On the same note, if you want a $200k salary and only make $180k it can be useful to say you are currently making $200k. So again, this moment can be advantageous to both parties.
HR people do actually see current income as 'social proof' of your actual worth. This is not necessarily out of a desire to take advantage of employees, but they find it hard to justify to their bosses why they did no negociate a better deal.
I learned it the hard way, by trying to work part time (like 10hrs per week) while studying and then having employers unable to grasp that I was demanding a much higher salary because I was offering my undivided attention in a full time position. This was explained to me by a simpathetic (though probably naive) recruiter, who literally coached me to lie on my application so she could process me as a viable candidate.
I did not get that job anyways, but at least I learned to avoid mentioning the fact that I had been "working for peanuts" in the recent past.
It is, in fact, possible that some aspect of a negotiation can be beneficial to both parties, but not for the reasons the parent suggested.
If we assume that your minimum bid is in fact below their maximum offer, then the market should clear: you should get hired. Under such circumstances, anything preventing a successful conclusion to the negotiations is harmful to both parties, since there exists a price at which both sides would be satisfied that they're getting more value than they're giving. Therefore, anything eliminating or preventing such an obstacle from arising is beneficial to both parties.
The corollary is that employers who insist on "social proof" place themselves at a disadvantage; they're less able to hire, and the people they do hire will likely be inferior. They are giving up value every time they enter negotiations, not by overpaying but by failing to engage in beneficial transactions. Those hidden costs can be, and often are, far greater than overpaying by some small percentage on the transactions in which they do engage.
Under such circumstances, anything preventing a successful conclusion to the negotiations is harmful to both parties, since there exists a price at which both sides would be satisfied that they're getting more value than they're giving.
I am afraid, reality is more complicated than that. There are opportunity costs, and there are threats. (Read up about the latter in "The Strategy of Conflict".)
Threatening to do both parties damage, can give you a better deal.
Depends on the BATNA; failed negotiations can quite easily be negative-sum if it results in not hiring someone and both parties having to spend effort continuing the search.
Getting a salary ballpark out early can save both sides a lot of time.
As a potential employee it's important to phrase it right as "If you are not going to pay at least X we are wasting our time". Where X does not need to be your current salary - but really what would be least it would take for you to work there.
If they insist on current salary be firm on X. Point out that this is based on what it would take you to consider them, and you are already taking into account a lot of factors like company prestige, type of work, location, lost options etc.
It is important to realize that you are not giving away any negotiating power by putting out a lower bound. One easy trick is to mention that you are also talking to other companies that already agreed to the same lower bound.
Also do not ask for or let them tell you an upper bound from the hiring company. If they end up really wanting you it will be harder for them to change that.
Getting a lower bound will help both parties. An upper bound you do not walk away from will hurt your position a bit though.
None of what you say has anything to do with someone's current salary. If I'm in a job paying $50,000 in a market where the typical salary is $80,000 and I want $100,000 then asking for the $50,000 number doesn't help anyone. It's just meaningless data that clouds the issue of what you are willing to pay to hire me. I can understand asking a candidate what salary they're looking for. That's useful. It's got nothing to do with their current situation.
Serious question: Why is asking your salary any less relevant then asking for your previous place of employment? If I say I did X on project Y at Google, that's a pretty incomplete picture of how valuable my coworkers and bosses found my work on project Y. Thus, it seems like a salary is another potentially helpful data point indicating how valuable I've been to previous companies.
Obviously in a better world it would be possible to glean this information from an interview alone, but the bottom line is that interviews generally suck at informing how useful a candidate is going to be. A candidate who claims they've done valuable work is potentially exaggerating, and it's difficult to tell by how much. That's (part of) why we have resumes, and (most of) why an employer wants to know your previous salary.
Note that I'm asking this unironically. I know that "never tell anyone your salary" is a popular point of discussion here, but I have trouble seeing why it's any different from, say, a grad school asking for your GPA.
I live in an area of the US where the cost of living is low (think $1.60/gallon and $725/month to rent a 2-bedroom apartment).
If I'm interviewing for a potential employer in an area with a higher cost-of-living, I'd (in a certain sense) be cheating myself to state my current pay.
What is the current average in a language like C# or Java for a skilled developer? Average that goes into production rather than what's likely thrown away.
In a week long project (some supporting tool, or something similar) it's easy to write 10k lines a week. In a 6 months project, 10-100 lines are more likely, and in an "eternal" software that is already mostly written, 0 is a perfectly fine number.
I dread the day someone starts tracking LOC vs productivity in TFS. I might be switching between C#, SQL, CSS, HTML and Javascript on a busy day. A context switch == a productivity hit.
That was actually one of my favorite moments! Someone pulled up the TFS chart of lines of code added/removed per developer. First, I removed way more lines then I added. But second, the number of lines I removed was (completely accidentally) the same as the number of lines my team lead added. When he saw that, he just kind of looked over at me to make sure I wasn't following him commit by commit to rewrite his code!
"Between Annotation processors & code generation plugins, it already means nothing."
Getting a project of a given size done on schedule means nothing? Your company sounds pretty laid back. That's nice.
"Am I supposed to willingly write horrible and unproductive code just to increase my LOC / time ?"
It's a nice strawman you built there. The metric in your case would be average, custom LOC brought into production. So, it would hopefully be productive, great code at a certain rate. The rate varies among people and programming approaches.
It's a well-known tactics to lowball you. The standard answer is "I'm not allowed to disclose it" and if they push, I just give them what I want them to give me minus 5% regardless of what the actual number is.
If they end up calling my current employer and that this employer gives them the number (which is extremely unlikely), I just tell them "What I'm making right now is irrelevant, I gave you the salary I think I'm worth right now. If you don't agree, I'll just walk, no big deal".
I'd be very tempted to ask the HR person for their salary and/or ask for the CTO/CEO's salary and/or some confidential revenue number or something like that before ending the interview.
It's fairly shady negotiating to anchor the process one sided. If they want your salary they should tell you what the highest paid developer makes as well.
The justification they told me was that they weren't going to give me a 20K raise if I wasn't making that much right now
So you base your salary offer on my current salary, instead of what I would be worth to you guys? Good luck. We're going to be here a while, since I'm not going to disclose my salary.
4 months into a new job, and I realized I had contributed about -4000 lines of code. I thought, how weird it would be to explain (especially to someone less technical), that I'd pretty much just been deleting code since I started. I'd also added a number of important features along the way.
Since then, I've taken some pride in trying to be a "net negative" (by line count), contributor to any code base I work on. Not always possible, but it's a good mindset to strive for leaner designs/implementations.
Show management a picture of the code. Show them a visualization of all of it with its myriad connections. Tell them you just got rid of 4,000 lines of that crap. Show a visualization that's smaller and connected neatly. Promise to continue attempting this incrementally and safely in between new features. New features that are coded similarly neat.
Not sure if it will work but I keep wanting to see someone try it. :)
I've pretty much exactly that, and it did work. Though it was at a company that had a headcount of 15, so in a larger org it might not go down so well.
We've done this as a recap of successes with a few clients, now. It helps that the old stuff was stupid slow and ours has been both understandable and faster.
There was someone at Google whose total code delta over his tenure was something like -2M. Yep, two million lines of code deleted. May we all be that productive.
Stock market indicators in China are reversed in colour from the western world (up=red, down=green). Sometimes I wonder if Github really should be flipping the colours on diffs for Chinese language users for the sake of consistency.
I deleted a couple thousand lines this week. It felt awesome. But you'd have to admit that rewarding based upon deleted lines of code could be even more dangerous than rewarding added lines of code.
I worked at a furniture company where in order to delete code you had to have the head IT guy, the IT Director and an outside consultant sign off on it. Yes, that is right! 2 people that didn't know how to code and an outside consultant that we paid to look over "IT" moves before we made them.
However, I didn't need anyone to sign off on commenting out code and replacing it with something else. :-)
I was one of 2 coders that worked there, but we did different things. We were supposed to do "code reviews", monthly with each other. We did, but we usually went to a Denny's (open 24 hours) and literally hung out there for 15 hours, ate 3 times, etc and reviewed things. We cared about code quality and not having to band-aid.
We had a saying: "Comment in a fix....". This is our way of saying to each other that we needed to re-write code and to get around "red tape" we would comment out and replace the code.
So if comments confused things, we removed them, with a comment that previous comments "were confusing" or "no longer applied" :-)
I finished up a 24-month project earlier this year on a codebase of ~1M lines in which I dropped a net of almost 100k lines of code and reduced the main Visual Studio solution from 325 projects down to 105 projects. Compile times dropped from ~40 minutes to 6 minutes. If only all my projects could be that fun.
One of the most interesting experiences I had very early on in my career was reducing a 12,000 line C program to a roughly 1,000 line version (in C itself) without losing any functionality.
No, it had nothing to do with my prowess as a young coder, but solely due to the fact that my predecessor did not know what a function was nor how to use parameters.
He had written unrolled versions of the same piece of code, with embedded SQL with minor variations in WHERE CLAUSE values which could be easily parameterized.
All I had to do after analyzing the code was move the code into a function and loop through it with different parameters values.
... I remember deleting ~500 C++ files .. they were all classes that differed by a constant, so I just passed in a parameter. Was not popular at all, they liked lots of files.
I've had that exact same scenario about 4 years ago with a very large website (you've probably used them) which was put together in a hurry. The site was written in Java and each and every access to the database contained the exact same pre-amble, a bunch of database interaction with the aforementioned change to the where clause and then a cleanup section. Typically 50 to 100 lines. There must have been 100's of these copies in the code. In the end I moved the db open and close stuff to program startup and shutdown and replaced all the rest of it with a single function with a couple of parameters. The code suddenly became maintainable again.
Similarly, the number of git-commits is also a poor judge of how much work was done. When CI builds automatically build release notes based off of the git-log since the last successful build, this can be deceiving.
I worked somewhere where the support manager somehow managed to get approval to bill his costs against each product group based on the lines of code in their product. We spent part of a week refactoring and reformatting to cut it by 70% before we gave him our numbers.
Negative LOC while retaining those things would be optimal, if you can manage to reduce the size of the overall codebase while fixing issues and/or adding features it's the best possible outcome.
I was surprised when YC asked something similar in their application:
"If you've already started working on it, how long have you been working and how many lines of code (if applicable) have you written?"
My response ... "I personally believe that using "lines of code" is a crude metric as it favors the sloppy programmer who doesn't write compact code and discourages code reuse by utilizing libraries and frameworks."
IMO, the answer to a question like that begins with a number (if applicable) and contains commentary only after the number. (I agree with your commentary, just disagree with the value of not answering.)
It's not just old managers that dislike negative lines of code: Static analysis tools dislike them too, under the right bureaucracy.
At a certain huge company that sells seeds, they decided to start having both a base test coverage target, and a specific plugin that demanded that the coverage never went back more than half a percent from the high water mark on any given project. The engineering managers thought it was a good idea: As time goes by, we'd have better code coverage!
I joined a team that had an application full of repetitive code, because nobody had spent much time thinking about reuse. I decided it was bad for maintainability, and the team let me rewrite a big chunk of repetitive, well tested code. I shrunk the codebase by a good 10K LOC, and it still did the same thing. Teammates liked what I had written, and everyone was happy. But when I pushed it, the build refused to deploy, because now the code didn't meet coverage standards.
The manager was mad at me: you wrote all that code, but I guess your unit tests were sloppy! he said. But when I went and looked at the code changes, I had a 100% code coverage. Since I am not a football player, I just couldn't give 110%. So then we look at the reports, slowly, and saw that while I had full code coverage, the code I was replacing also had full code coverage, but mine was so much smaller, our total coverage percentage went down! 1000 lines of uncovered code, in a codebase with 30K lines, gave us better numbers than the same lines in our shinier 20K LOC codebase. And building tests for some really old, badly factored code just wasn't in our top list of priorities.
The people in charge of this system refused to change it, even though it was really not helping things in our case. So what did we do? Fool the tool, of course. Added a bunch of well tested dead code that was never going to get called in production, and wouldn't even get built into the binary, thanks to some packaging magic. We put it in a separate module, clearly marked as 'dead code to make Sonar happier', and we went our merry way.
And building tests for some really old, badly factored code just wasn't in our top list of priorities.
Really? I always thought that it's the old, ugly and brittle code that needs unit tests the most. Especially right before the moment you finally decide to rewrite it.
Once had a compiler QA gig. Was kinda lazy. So, I wrote a nonsense code synthesizer. Just take the BNF and belch out code. Millions and millions of lines of code. A fun variant was to create a class hierarchy that would run 100's of levels deep. I showed it to marketing. They asked: "Can you do that for <competitors> compiler?" "Sure thang!". Soon, there was an ad showing how our compiler could handle a lot more bloat than their compiler. Not my proudest achievement.
I have absolutely no idea of what my average LOC / week is and I would argue that it is a silly metric.
Last week I deleted 30k LOC from the project (~10% of the code base) :
-we used to have both the old & new version of the UI in the codebase so we could switch between the twos in production. Now that the new version is complete, there is no need for that.
-There were many deprecated parts of the app and unused resources, I did a big cleanup of these and I have even more work in that area.
This has resulted in way cleaner code, easier to apprehend for newcomers. The app is also lighter by 2 mo. Probably a very productive week overall.
I deleted 205 today. Felt good.
I deleted about that many today as well. Cleaner neater more readable code is better.
It's funny that other programmers feel the same way. I've never discussed it with other developers much, but I also derive a degree of satisfaction when refactoring if I leave the code with fewer lines than it had originally.
I'd say I'd enjoy deleting 200 lines to adding 200. It's like sitting down in a freshly cleaned room once you finally get your chores out of the way.
I had a job interview once where the HR rep asked me how many lines of code I wrote a week. I responded, "On a really good week -1000, I don't remember the exact figure." She was extremely confused by this answer and wanted me to give her a number. So she said, "I'll just put down 10,000."
This is also the interview where they refused to continue unless I told them how much money I made (which I don't do anymore). The justification they told me was that they weren't going to give me a 20K raise if I wasn't making that much right now. I didn't point out that they aren't giving me a raise, they are paying me market value based on what the position is worth (to oversimplify it).
I was offered the job but decided not to take it because that plus the technical interview made me wary.
520,000 lines of code per year! :)
Couple that with pay and just tell them to pay you $1 per line of code written.
# Need to increment this count so it matches up with the length of the list we just created.
count = 1
count = count + 1
count = count + 1
count = count + 1
count = count + 1
count = count + 1
Ha, I guess the developers they are hiring used to be sci-fi writers! But don't most writers say the hardest part is cutting words out of their book and cleaning up language?
P.S. I don't remember exactly what she put down as my "line-count" I was pretty annoyed at that point, it might have been a much more reasonable 5000. :-)
This reminds me of a quote I enjoy:
"If I had more time, I would have written a shorter letter."
Some interesting attributions of that and similar quotes: http://quoteinvestigator.com/2012/04/28/shorter-letter/
A good case to use code generators, I guess...
Are we counting the code my macros produce? As far as git is concerned I might be down a couple hundred to a couple thousand in a good week, but if we count macroexpansion, I'm rolling in the LoC.
Time to write yourself a private jet.
Obligatory Dilbert:
http://dilbert.com/strip/1995-11-13
Even after 20+ years in the labor force, I've never understood that justification. "I'm a nosy bastard" at least has a ring of truth to it.
"I want to pay you as little as possible and still get you to come to work here." That's the truth.
Actually the truth is more like "I want to pay you as little as possible for you to work here and be productive." People who're worried about money are really bad at their job. They spend all their time thinking about something else. If someone is willing to accept a job on a salary that isn't really enough to live on (say, because they don't know how expensive the area is) then you should pay them more than what they believe their minimum is. Unfortunately hiring managers quite often fail to understand this.
Don't be so literal about it. I used to get defensive about that question too, but the truth is they aren't asking you how much you are making, they are asking you to start the salary negotiation so they can get a feel for what it's going to take to hire you and describe you adequately to a hiring manager. It's just an opportunity for you both to ballpark the situation and eject early if there's going to be a wide disagreement about comp. It can be equally advantageous to both parties if you use it properly.
No... there are recruiters who are a lot more invasive and pushy (and a couple employers I've run across).
"Proof of previous income" was required at one place I applied years back, and I've heard similar stories from colleagues. No, of course, I don't bother going forward in those situations.
"What are you making now?" is crass. The good recruiters I've worked with phrased it as "what are your salary expectations?" or "the range is $x-$y - are you OK with that?"
I've taken it literally in situations where they actually meant it literally. "We will not pay you $80k until you can prove you were making $80k at your previous job". Insane, but it does happen on occasion. How those companies ever manage to hire anyone... I'm not sure.
I guess you're right, that does happen sometimes. In those cases you also shouldn't be mad, though, because they just gave you a crystal clear sign they aren't worth working for.
It's best to immediately walk away from a situation like this.
Yes; proof that everything that comes out of your mouth isn't a lie suggests a lack of trust.
I've gotten "I need a number for us to continue" multiple times.
"Considering your obnoxious lack of professionalism and the fact that your approach is apparently acceptable to the company, I'm not sure there's any offer you could make that I'd be excited to accept. But everyone has his price, so write down $500,000 for now and I'll decide how much to increase it after I hear the rest of what you have to say."
Just say "my salary expectations for this position is $XY0,000". I use it as an opportunity to set the ballpark for the negotiation. Sometimes bosses don't know what people are worth so they ask these kind of questions. Once we opened an office in a new country, and when we hired people, we asked them what they expected and gave them that + 20% because we really had no idea how much we should be paying.
Threaten to walk away.
42
Dude, that right there is the problem. They make a commission off your starting salary, so OF COURSE their primary concern is your past and future financials.
This is why I hate recruiters.
I disagree. Recruiters have a conflict of interest that often goes to the candidate's advantage and against their employer's interest. The higher your salary, the higher their commission. And employers are fine with that because a good hire is better than no hire.
The conflict of interest is more complicated:
For the recruiter, getting you in at 160k is twice as good as getting you in at 80k, and infinitely better than you walking away.
As a candidate that currently earns 100k, an 80k offer is worthless.
(Threatening to) walking away from a deal is one of the strongest strategies in negotiation. But that's the one thing a recruiter will never want you to do.
Candidate: High salary > no deal > low salary. Recruiter: High salary > low salary > no deal.
You are right, that the recruiter has an even bigger conflict of interest with their employer. But that conflict does not mean the recruiter's interests are aligned with the candidate.
(One way to align any interests is generally to repeat games. That's why internal recruiters are usually less sleazy than the external kind: they are at least clearly on the site of the employer. And honourable employers have a reputation to defend---another repeated game.)
That is what you would expect, but they want to optimise both on commission and on throughput. If a slightly lower salary makes it easier to position you and get you hired fast, the cost of the lower commission is less than the cost of working on your case for a long time. It is the same with real estate agents. From that perspective, their knowledge of the market should theoretically set the price at the optimal short-term, hiring decision point. Nevertheless, for the employee and employer this is a long term relationship and it works out bad on both sides (lower salary than could be achieved for the employee, greater employee turnover for the employer.)
While a fair salary is ideal for all parties, optimizing for job satisfaction would be a wiser decision than optimizing for salary amount. Scoring a high salary may merely mean the new hire will be one of the first to be cut from the crew should the firm hit choppy waters... an outcome that recruiters do not need to care about.
What's really fun about that is that most people I interview, when asked "what are your salary expectations?" answer with "I'm currently at XYZ a year"
In addition to other reasons, it can also be beneficial for any side to postpone this discussion for a later phase.
Yeah I mean it really depends on where you are applying to work. If you are trying to join as a senior member of an organization negotiations have way fewer rules, but if you are applying to Google etc. below a level 4 position it seems pretty reasonable to not need to assert your individuality as an engineer by disrupting the system since you'll be ending up with a standard package anyway. Sometimes you just need to learn how that game is played and play it instead of changing it.
Even at Google you should negotiate: their base is pretty standard, but the stock grants differ. A lot.
There ain't no such thing. Salary negotiations are pretty close to zero-sum.
The actual dollar value is usually literally zero sum, but if you have a family and need a $200k salary with specific benefits as a hard requirement it's going to be helpful to get that out of the way up front. On the same note, if you want a $200k salary and only make $180k it can be useful to say you are currently making $200k. So again, this moment can be advantageous to both parties.
No, please don't sugar coat it.
HR people do actually see current income as 'social proof' of your actual worth. This is not necessarily out of a desire to take advantage of employees, but they find it hard to justify to their bosses why they did no negociate a better deal.
I learned it the hard way, by trying to work part time (like 10hrs per week) while studying and then having employers unable to grasp that I was demanding a much higher salary because I was offering my undivided attention in a full time position. This was explained to me by a simpathetic (though probably naive) recruiter, who literally coached me to lie on my application so she could process me as a viable candidate.
I did not get that job anyways, but at least I learned to avoid mentioning the fact that I had been "working for peanuts" in the recent past.
It is, in fact, possible that some aspect of a negotiation can be beneficial to both parties, but not for the reasons the parent suggested.
If we assume that your minimum bid is in fact below their maximum offer, then the market should clear: you should get hired. Under such circumstances, anything preventing a successful conclusion to the negotiations is harmful to both parties, since there exists a price at which both sides would be satisfied that they're getting more value than they're giving. Therefore, anything eliminating or preventing such an obstacle from arising is beneficial to both parties.
The corollary is that employers who insist on "social proof" place themselves at a disadvantage; they're less able to hire, and the people they do hire will likely be inferior. They are giving up value every time they enter negotiations, not by overpaying but by failing to engage in beneficial transactions. Those hidden costs can be, and often are, far greater than overpaying by some small percentage on the transactions in which they do engage.
I am afraid, reality is more complicated than that. There are opportunity costs, and there are threats. (Read up about the latter in "The Strategy of Conflict".)
Threatening to do both parties damage, can give you a better deal.
If you do strike a deal, that's along a fixed sum border.
But do keep in mind, that either party can always blow up the whole process at almost any time. This is important.
Depends on the BATNA; failed negotiations can quite easily be negative-sum if it results in not hiring someone and both parties having to spend effort continuing the search.
I would say "only if you tell me what you have budgeted for this position"
Has nobody here played poker? You don't just say what your hand is when you start betting.
That sounds a lot like a friendly way of saying "you should lie."
I don't really disagree, but we might as well be honest about it here.
Or give the the answer to what they want to know, not to what they asked.
Either lie or refuse to answer.
Totally agree.
Getting a salary ballpark out early can save both sides a lot of time.
As a potential employee it's important to phrase it right as "If you are not going to pay at least X we are wasting our time". Where X does not need to be your current salary - but really what would be least it would take for you to work there.
If they insist on current salary be firm on X. Point out that this is based on what it would take you to consider them, and you are already taking into account a lot of factors like company prestige, type of work, location, lost options etc.
It is important to realize that you are not giving away any negotiating power by putting out a lower bound. One easy trick is to mention that you are also talking to other companies that already agreed to the same lower bound.
Also do not ask for or let them tell you an upper bound from the hiring company. If they end up really wanting you it will be harder for them to change that.
Getting a lower bound will help both parties. An upper bound you do not walk away from will hurt your position a bit though.
the truth is they aren't asking you how much you are making
Correct. They're just trying to figure out how little you will accept.
they are asking you to start the salary negotiation
Never be the first to give a number.
Always be the first to give a number and conditions.
Setting the stage is too important to let the other party do it.
None of what you say has anything to do with someone's current salary. If I'm in a job paying $50,000 in a market where the typical salary is $80,000 and I want $100,000 then asking for the $50,000 number doesn't help anyone. It's just meaningless data that clouds the issue of what you are willing to pay to hire me. I can understand asking a candidate what salary they're looking for. That's useful. It's got nothing to do with their current situation.
How do you know what the typical salary is?
How do you find out anything at all? Talk to other people in the same profession, glassdoor etc.
Serious question: Why is asking your salary any less relevant then asking for your previous place of employment? If I say I did X on project Y at Google, that's a pretty incomplete picture of how valuable my coworkers and bosses found my work on project Y. Thus, it seems like a salary is another potentially helpful data point indicating how valuable I've been to previous companies.
Obviously in a better world it would be possible to glean this information from an interview alone, but the bottom line is that interviews generally suck at informing how useful a candidate is going to be. A candidate who claims they've done valuable work is potentially exaggerating, and it's difficult to tell by how much. That's (part of) why we have resumes, and (most of) why an employer wants to know your previous salary.
Note that I'm asking this unironically. I know that "never tell anyone your salary" is a popular point of discussion here, but I have trouble seeing why it's any different from, say, a grad school asking for your GPA.
For starters, the grad school won't be giving you a lower GPA depending upon the one you give them.
But the bigger issue is that they rarely ever give their hiring range, so why give them more info that can only hurt me?
I live in an area of the US where the cost of living is low (think $1.60/gallon and $725/month to rent a 2-bedroom apartment).
If I'm interviewing for a potential employer in an area with a higher cost-of-living, I'd (in a certain sense) be cheating myself to state my current pay.
What is the current average in a language like C# or Java for a skilled developer? Average that goes into production rather than what's likely thrown away.
In a week long project (some supporting tool, or something similar) it's easy to write 10k lines a week. In a 6 months project, 10-100 lines are more likely, and in an "eternal" software that is already mostly written, 0 is a perfectly fine number.
Appreciate the reply.
I dread the day someone starts tracking LOC vs productivity in TFS. I might be switching between C#, SQL, CSS, HTML and Javascript on a busy day. A context switch == a productivity hit.
That was actually one of my favorite moments! Someone pulled up the TFS chart of lines of code added/removed per developer. First, I removed way more lines then I added. But second, the number of lines I removed was (completely accidentally) the same as the number of lines my team lead added. When he saw that, he just kind of looked over at me to make sure I wasn't following him commit by commit to rewrite his code!
I have senior in my title so I guess I count as skilled, I work on an Android app (so Java).
I have absolutely no idea of what my average LOC / week looks like and could not care less.
This is a really dumb metric.
Between Annotation processors & code generation plugins, it already means nothing. If you factor in DRY, it is just insane.
Am I supposed to willingly write horrible and unproductive code just to increase my LOC / time ?
"Between Annotation processors & code generation plugins, it already means nothing."
Getting a project of a given size done on schedule means nothing? Your company sounds pretty laid back. That's nice.
"Am I supposed to willingly write horrible and unproductive code just to increase my LOC / time ?"
It's a nice strawman you built there. The metric in your case would be average, custom LOC brought into production. So, it would hopefully be productive, great code at a certain rate. The rate varies among people and programming approaches.
rofl, you are assimilating LOC and actually accomplishing a task on schedule and you talk about strawman ? give me a break.
Sounds like you made a great choice :)
It's a well-known tactics to lowball you. The standard answer is "I'm not allowed to disclose it" and if they push, I just give them what I want them to give me minus 5% regardless of what the actual number is.
If they end up calling my current employer and that this employer gives them the number (which is extremely unlikely), I just tell them "What I'm making right now is irrelevant, I gave you the salary I think I'm worth right now. If you don't agree, I'll just walk, no big deal".
I'd be very tempted to ask the HR person for their salary and/or ask for the CTO/CEO's salary and/or some confidential revenue number or something like that before ending the interview.
It's fairly shady negotiating to anchor the process one sided. If they want your salary they should tell you what the highest paid developer makes as well.
These sound like two very big red flags. You have probably dodged a bullet here.
So you base your salary offer on my current salary, instead of what I would be worth to you guys? Good luck. We're going to be here a while, since I'm not going to disclose my salary.
4 months into a new job, and I realized I had contributed about -4000 lines of code. I thought, how weird it would be to explain (especially to someone less technical), that I'd pretty much just been deleting code since I started. I'd also added a number of important features along the way.
Since then, I've taken some pride in trying to be a "net negative" (by line count), contributor to any code base I work on. Not always possible, but it's a good mindset to strive for leaner designs/implementations.
Show management a picture of the code. Show them a visualization of all of it with its myriad connections. Tell them you just got rid of 4,000 lines of that crap. Show a visualization that's smaller and connected neatly. Promise to continue attempting this incrementally and safely in between new features. New features that are coded similarly neat.
Not sure if it will work but I keep wanting to see someone try it. :)
I've pretty much exactly that, and it did work. Though it was at a company that had a headcount of 15, so in a larger org it might not go down so well.
We've done this as a recap of successes with a few clients, now. It helps that the old stuff was stupid slow and ours has been both understandable and faster.
My favorite OS updates are the one with negative net install.
Keep trimming.
There was someone at Google whose total code delta over his tenure was something like -2M. Yep, two million lines of code deleted. May we all be that productive.
A programming god I'd say
Turns out it was black hat guy (from xkcd) deleting 2M lines of comments.
"Oh, him? That's Chuck. He just runs our commits through a minifier and takes credit for the lost lines. Means well, but he's kind of a jerk."
This is the funniest comment I've read all week.
Lead Google Wave developer I assume.
I wish the output from git diff used red for new lines and green for removed lines...
Stock market indicators in China are reversed in colour from the western world (up=red, down=green). Sometimes I wonder if Github really should be flipping the colours on diffs for Chinese language users for the sake of consistency.
To be fair to the Chinese, whether a price going up or down is alarming or encouraging depends on whether one wishes to buy or to sell.
Do you know if that is because up is generally "bad" for them, or because red means "good" and green means "bad"?
Red is considered good and prosperous. Hence the huge amount of red in Chinese culture.
https://en.m.wikipedia.org/wiki/Color_in_Chinese_culture#Red
"One of my most productive days was throwing away 1000 lines of code."
http://quotes.cat-v.org/programming/
I deleted a couple thousand lines this week. It felt awesome. But you'd have to admit that rewarding based upon deleted lines of code could be even more dangerous than rewarding added lines of code.
the moral here is not to be dogmatic.
Folklore.org has plenty of other great stories from the Mac team. I remember reading some of these long before the Steve Jobs biography was released.
I worked at a furniture company where in order to delete code you had to have the head IT guy, the IT Director and an outside consultant sign off on it. Yes, that is right! 2 people that didn't know how to code and an outside consultant that we paid to look over "IT" moves before we made them.
However, I didn't need anyone to sign off on commenting out code and replacing it with something else. :-)
Could you one week later delete "comments" without sign off?
I was one of 2 coders that worked there, but we did different things. We were supposed to do "code reviews", monthly with each other. We did, but we usually went to a Denny's (open 24 hours) and literally hung out there for 15 hours, ate 3 times, etc and reviewed things. We cared about code quality and not having to band-aid.
We had a saying: "Comment in a fix....". This is our way of saying to each other that we needed to re-write code and to get around "red tape" we would comment out and replace the code.
So if comments confused things, we removed them, with a comment that previous comments "were confusing" or "no longer applied" :-)
I finished up a 24-month project earlier this year on a codebase of ~1M lines in which I dropped a net of almost 100k lines of code and reduced the main Visual Studio solution from 325 projects down to 105 projects. Compile times dropped from ~40 minutes to 6 minutes. If only all my projects could be that fun.
What kind of software takes 1M lines of code and 105 project? Is it one of those Java enterprise software projects?
Even worse, probably one of those C++ enterprise software projects.
Banking software, hospital software, nuclear reactor software. Not all people are writing self-contained web applications.
Late reply, but yes, it's hospital software.
video games codebases are sometimes this large
Well considering Visual Studio was mentioned enterprise C#/C++ project would be a safe bet.
An EPOS application:
At a previous employer, a piece of chip design software got to 1.25m lines of C++ over the course of a decade.
One of the most interesting experiences I had very early on in my career was reducing a 12,000 line C program to a roughly 1,000 line version (in C itself) without losing any functionality.
No, it had nothing to do with my prowess as a young coder, but solely due to the fact that my predecessor did not know what a function was nor how to use parameters.
He had written unrolled versions of the same piece of code, with embedded SQL with minor variations in WHERE CLAUSE values which could be easily parameterized.
All I had to do after analyzing the code was move the code into a function and loop through it with different parameters values.
Such is life.
... I remember deleting ~500 C++ files .. they were all classes that differed by a constant, so I just passed in a parameter. Was not popular at all, they liked lots of files.
That sounds stupid. Did they not know about inheritance or template classes or anything??
I've had that exact same scenario about 4 years ago with a very large website (you've probably used them) which was put together in a hurry. The site was written in Java and each and every access to the database contained the exact same pre-amble, a bunch of database interaction with the aforementioned change to the where clause and then a cleanup section. Typically 50 to 100 lines. There must have been 100's of these copies in the code. In the end I moved the db open and close stuff to program startup and shutdown and replaced all the rest of it with a single function with a couple of parameters. The code suddenly became maintainable again.
Similarly, the number of git-commits is also a poor judge of how much work was done. When CI builds automatically build release notes based off of the git-log since the last successful build, this can be deceiving.
"If we wish to count lines of code, we should not regard them as 'lines produced' but as 'lines spent'."
- Edsger Dijkstra
I worked somewhere where the support manager somehow managed to get approval to bill his costs against each product group based on the lines of code in their product. We spent part of a week refactoring and reformatting to cut it by 70% before we gave him our numbers.
That is genious.
Absolute genious. There are likely to be less problems on a smaller codebase and when there are its much easier to recommend a rewrite of 1k than 10k
That's brilliant.
I would love to know how he reacted and what happened next.
I really hope he was happy that his nefarious plan worked where he managed to make his job easier while improving the product.
Porting a large piece of PC code to a console:
- every deleted line meant we could have more content
- the code ran faster
- there were, axiomatically, fewer bugs (and we fixed a lot of bugs on the way)
- the code was more understandable
This story is about how useless LOC is as a metric.
But negative LOC alone is just as useless a metric as positive LOC. It's easy to come up with examples where deleting unused code is actually harmful:
- Just delete all comments
- Remove platform code you are not using now, but might in the future
- Remove reference code because you are only using platform code
- Remove test code that is just not called yet, but really should be
- Remove code from a copied library that is now harder to keep current
- etc..
Negative LOC while retaining those things would be optimal, if you can manage to reduce the size of the overall codebase while fixing issues and/or adding features it's the best possible outcome.
LOC is not useless since it's just a metric. It's interpretation is what matters.
- Just delete all comments
This is definitely harmful, agreed.
- Remove platform code you are not using now, but might in the future
Definitely. It's in the repo if you want to get it back, so there's no reason why unused code should be in your source.
- Remove reference code because you are only using platform code
Yes. Remove everything you're not using. It's in the repo.
- Remove test code that is just not called yet, but really should be
And again. Remove it if it's not used. Or start using it. Nothing else is acceptable.
- Remove code from a copied library that is now harder to keep current
You should probably be pinning versions of libraries otherwise you're going to see things break in the future. Upgrading them is a feature.
Deleting comments aside, using negative LOC as a metric does encourage people to write better code.
I was surprised when YC asked something similar in their application:
"If you've already started working on it, how long have you been working and how many lines of code (if applicable) have you written?"
My response ... "I personally believe that using "lines of code" is a crude metric as it favors the sloppy programmer who doesn't write compact code and discourages code reuse by utilizing libraries and frameworks."
I think you'd improve your response by answering:
1234 LOC, but I personally believe that....
IMO, the answer to a question like that begins with a number (if applicable) and contains commentary only after the number. (I agree with your commentary, just disagree with the value of not answering.)
Brings to mind the classic:
Writing code is like playing jazz. It's not about the notes you are playing, its all about the notes you are not playing
or with similar sentiment.. "Music is the space between the notes" Debussy
It's not just old managers that dislike negative lines of code: Static analysis tools dislike them too, under the right bureaucracy.
At a certain huge company that sells seeds, they decided to start having both a base test coverage target, and a specific plugin that demanded that the coverage never went back more than half a percent from the high water mark on any given project. The engineering managers thought it was a good idea: As time goes by, we'd have better code coverage!
I joined a team that had an application full of repetitive code, because nobody had spent much time thinking about reuse. I decided it was bad for maintainability, and the team let me rewrite a big chunk of repetitive, well tested code. I shrunk the codebase by a good 10K LOC, and it still did the same thing. Teammates liked what I had written, and everyone was happy. But when I pushed it, the build refused to deploy, because now the code didn't meet coverage standards.
The manager was mad at me: you wrote all that code, but I guess your unit tests were sloppy! he said. But when I went and looked at the code changes, I had a 100% code coverage. Since I am not a football player, I just couldn't give 110%. So then we look at the reports, slowly, and saw that while I had full code coverage, the code I was replacing also had full code coverage, but mine was so much smaller, our total coverage percentage went down! 1000 lines of uncovered code, in a codebase with 30K lines, gave us better numbers than the same lines in our shinier 20K LOC codebase. And building tests for some really old, badly factored code just wasn't in our top list of priorities.
The people in charge of this system refused to change it, even though it was really not helping things in our case. So what did we do? Fool the tool, of course. Added a bunch of well tested dead code that was never going to get called in production, and wouldn't even get built into the binary, thanks to some packaging magic. We put it in a separate module, clearly marked as 'dead code to make Sonar happier', and we went our merry way.
Great story ; I'm gonna use it at work to demonstrate the perverse effects of arbitrary tool-enforced policies!
Great story! You should submit this to http://thedailywtf.com/
Given that all I could think was "wtf?!" as that story went on, definitely!
"You get what you measure."
Really? I always thought that it's the old, ugly and brittle code that needs unit tests the most. Especially right before the moment you finally decide to rewrite it.
Wow, I would try to escalate it or eventually resign. I am so tired of this BS :(
Once had a compiler QA gig. Was kinda lazy. So, I wrote a nonsense code synthesizer. Just take the BNF and belch out code. Millions and millions of lines of code. A fun variant was to create a class hierarchy that would run 100's of levels deep. I showed it to marketing. They asked: "Can you do that for <competitors> compiler?" "Sure thang!". Soon, there was an ad showing how our compiler could handle a lot more bloat than their compiler. Not my proudest achievement.
I guess the management finally realized that deleting codes without breaking existing functionalities is more difficult than adding :)
Imagine being a civil engineer, and your boss says "how much concrete did you use? I'll pay you to use more."
Or an electrical engineer: "How many resistors did you solder? I want them all gone."
Or an aeronautical engineer: "What does the plane weigh? I was expecting a few more tons."
Or a traffic engineer: "Why haven't you put more stop lights in?"
Or a mechanical engineer: "More gears!"
Always hard to get the bean counters to appreciate elegance.
I work on a large Android app.
I have absolutely no idea of what my average LOC / week is and I would argue that it is a silly metric.
Last week I deleted 30k LOC from the project (~10% of the code base) :
-we used to have both the old & new version of the UI in the codebase so we could switch between the twos in production. Now that the new version is complete, there is no need for that.
-There were many deprecated parts of the app and unused resources, I did a big cleanup of these and I have even more work in that area.
This has resulted in way cleaner code, easier to apprehend for newcomers. The app is also lighter by 2 mo. Probably a very productive week overall.