10 ms·

It sucks being that person today because everything is about optics and that person will get purged. I know from experience. Team players, mentors, software ar

It sucks being that person today because everything is about optics and that person will get purged. I know from experience. Team players, mentors, software architects; they tend to be tossed aside to make room for coders who can churn out large amounts of code, even as the company's capacity to deliver and maintain features declines over time due to tech debt. Managers always love a developer who can consistently write 5000+ lines per code per week, regardless of how many features they actually ship and how many bugs they introduce. As a team lead and engineer who has managed some complex projects, the idea of someone writing over 2000 lines of code per week terrifies me... That's over 100K lines of code a year. Think of the unnecessary complexity. There is a very good chance that the same feature set could have been implemented with just 10K lines of code, less buggy and in half the time though that would only amount to 380 lines of code per week! Management won't like that. I tend to think that the dev who can churn out thousands of lines isn't thinking deeply enough about the long term direction of the project; all the code they're writing is essentially throwaway code.

88913527 3y ago
Because it's a bogus argument. The productive person doesn't need a paper weight at lunch to act as a shower thought generator. Management can get it wrong sometimes, but in broad strokes, they're right.
- closewith 3y ago
  Maybe, or maybe human endeavour is more complex than individual efforts.
  - 88913527 3y ago
    It's tough, but what I've seen is low performers weigh the team down. They constantly ask for the high performer's time, and if we give them bug tickets, new feature work, they constantly stumble and always report status as blocked. They don't add value. They can't get to the finish line with anything. It's not a kind thing to point out, but trying to angle it as "oh there's this other benefit you're just not seeing" is trying to work around the fact they can't competently fulfill the job function after exhausting all of our options (training, pair programming, etc). They might be friendly people, but the social boosts don't counteract the losses incurred, it's still a net loss.
    - jodrellblank 3y ago
      You've turned the story round from "Tim MacKinnon is a good programmer and asset to the team which the simple metrics were not tracking" into the strawman "defend people who cant do their jobs and are not an asset to the team by claiming that they are nice people".
- willcipriano 3y ago
  Idea people really overestimate their contributions.
- mynameisvlad 3y ago
  Define "productive". Because lins of code churned out is not and has never been a good measure of productivity. That "shower thought generator" might very well be more productive than the person they're sitting next to churning out tens of thousands of lines of unmaintainable code if their shower thoughts are causing people to find better ways to solve a problem. Which is basically the entire point of the article.
  - 88913527 3y ago
    It's more about measuring outcomes. We have a goal, did we meet the goal. There are many paths to the goal, so measuring things like lines of code is incorrect. But so is measuring Bob's ability to ask Alice a good question. Management can't, at scale, consider such factors. We don't have the counterfactual where Bob didn't ask the questions, and Alice did great anyways. Performance reviews would become even more subjective if we had to place a value on the impact of asking questions. All forms of measurement are flawed, so I stick with outcomes.
    - mynameisvlad 3y ago
      > Management can't, at scale, consider such factors. Why not? Peer feedback is a prime component of most performance/rewards discussions at companies. Work outside of points is certainly not a new concept. A manager's job is to distill this information amongst others to their own management chain at the right time. > We don't have the counterfactual where Bob didn't ask the questions, and Alice did great anyways. Bob's time isn't unlimited. There are surely instances where he was helping out Joe, Suzie, Darren, and James and had no time for Alice. Based on your other comment, you seem to think someone being an unblocker/idea generator/dev lead is a "low performer" who weighs the team down. That's just fundamentally wrong.
      - 88913527 3y ago
        It isn't wrong, it's right; because pontification of things (in a vacuum) yields no results. I cannot sell my customers Bob's ideas. All I can sell them is software that does something. The people that can do this without needing Bobs around are the people that will be rewarded.
deleted 3y ago
[deleted]
closewith 3y ago
In a remote world, can that person exist?
- dharmab 3y ago
  I am one of those people and work a fully remote job, but I had to earn that credibility with years of being a top contributor first. It would be difficult to just walk into the role.
  - scruple 3y ago
    I wrote a sibling comment alluding to the same, having been that person across a few different employers now. The struggles I had certainly, to a large degree, boiled down to a lack of trust (walking into a new team/department/company is hard on both sides!), but that wasn't the full story. IMO, management needs to have the right mindset to establish culture, too.
- deleted 3y ago
  [deleted]
- scruple 3y ago
  Yes and no, depends on the engineering culture and the management. I was successful in this sort of position as a full-time remote senior and then a team lead from 2016 til 2022. I changed employers and found myself in an environment that simply did not understand pairing, mentoring, etc. Management was oftentimes directly in the way, confused about loss of "velocity" and other trivial bullshit, despite the fact that the team was shipping in overdrive. I left at the start of this year and am now back in a position where these things are valued, encouraged, and happening remotely.
- greenyouse 3y ago
  That would depend on the culture of your team and larger workplace. Healthy teams should be checking in frequently to talk about ideas, reviewing big things, scoping upcoming work, etc. If there's time reserved for deeply technical but loosely structured discussion like that, then everybody takes turns being that person. In that env someone could "specialize" in it and help inspire others to do great work. It's the team that creates that kind of opportunity for feedback though. If the team has dysfunctions like rejecting deeper discussion or not working beyond jira tickets or checking out at meetings, etc. then it's not going to work. Someone that's good at that kind of supporting discussion will feel push back when fostering those discussions so it will fall off over time. The teams that do the best work and are the most fun to be on can host those types of discussions though, even remotely. It's worth experiencing if you haven't!
dharmab 3y ago
I've written several 100ks LOC/year at points in my career- but exclusively when working on new projects. When maintaining projects I might go a week at a time without writing any code solo, or I might spend a week trying to _reduce_ LOC.
- dmoy 3y ago
  I think my net contribution of lines of code at my current company is still negative. It was for a long time, but I haven't checked in awhile so I'm not sure if it still is.
  - dharmab 3y ago
    Usually I end up adding more lines of documentation and tests and removing lines of application code so it's not easily measurable- on theme for this thread, heh
  - allenrb 3y ago
    I remember times at a few of my jobs, just absolutely cheering for someone’s PR that was filled with red. Good times.
  - deleted 3y ago
    [deleted]
  - esafak 3y ago
    At my last company we had an architect whose only direct coding contributions were deletions, because nobody gets credited for cleaning up code.
- jongjong 3y ago
  My problem in my last role when I read large Pull Requests is that they tended to be way more complicated than they should have been but because they worked and I couldn't single out a small number of specific problems, I had no choice but to approve. Still, I knew it would slow us down in the medium and long term but this bloat is completely invisible to management. It has become taboo to say things like "This code is too tightly coupled", "You don't need to add an external dependency for that", "The inputs to those methods are too complicated; your components are micromanaging each others' state", "You're violating separation of concerns", "The cyclomatic complexity of this code is too high; you could simplify all your if-else statements"... When it's not my company, it's impossible to dismiss code when it works right now, even though it is likely to break later.
marcosdumay 3y ago
It sucked being that person back then too. The idea of measuring everything and acting on the numbers you can get is from the 19th century. Managers have been doing that same kind of practice since then, with the same kind of result (it's a very reliable result), without a change.
- namaria 3y ago
  Being superficial wasn't invented in the 19th century. People are very oriented to things they can see, measure and touch, when the most impactful and insightful people are often the silent care takers, the teachers, those keeping things running smoothly. When you do things right, people won't be sure you've done anything at all.
- vegetablepotpie 3y ago
  A lot of that is from Frederick Taylor, who invented “scientific management”. He did experiments where he would have workers shovel piles of ash from one side of a line to the next, giving them a new shovel size each day. Found that the ideal shovel size holds 21 pounds [1]. The ideological assumption of his work is that management exclusively does the thinking and the workers exclusively do the doing. This falls apart when the workers have unique knowledge and insight that management does not have. [1] https://www.mentalfloss.com/article/63341/frederick-winslow-taylor-patron-saint-shovel https://www.mentalfloss.com/article/63341/frederick-winslow-...
  - marcosdumay 3y ago
    > when the workers have unique knowledge and insight that management does not have. AKA every time. AFAIK, Taylor himself wasn't nearly as radical about doing measurements and only acting on them nor about managers deciding everything and not listening to the workers as Taylorism preaches. His work was one of the many, many management theories that was completely modified to appeal to incompetent power-hungry wannabe dictators (and yet blamed on the person proposing the original theory).
- tengwar2 3y ago
  Acting on the numbers you get is not intrinsically a problem: it's what the action is. Looking at how fast stories, function points or whatever get closed is important for planning what you can get done in a given time, and that can be crucial for project management and managing customer expectations. It's not acquiring the information which is a problem; it's not using the metrics which is the problem. The problem is not understanding what the metric can be used to represent (project velocity), and what it cannot (individual productivity);
datavirtue 3y ago
Yeah, you have to do it all. Churn out stories AND mentor AND knock down "desk-side" work (random infra bullshit). I have been at big companies where no one lasts very long. Thier mental health suffers to a point where they have to leave so that they can go work at some other sweatshop for a while. The lull between giving their notice and the honeymoon at the new company is their only break.
tempodox 3y ago
The saddest thing is that some bosses want throwaway code. I had a short stint once in a company where the owner wanted the web service rewritten from scratch every 6 months so they could use the newest web framework and follow the current fashion. He would hire a 5000 LoC per week hero on the spot.
- andai 3y ago
  Tangential but I was doing a web app for a client and gave a time estimate, which accounted for doing things properly (i.e. learning a frontend framework first). He asked "can you do it faster" and I agreed, thinking I'll make a throwaway version first and fix it later. Needless to say the project was a disaster, rapidly became unmaintainable. That's how I learned my job isn't to do what the client asks, it's to make sure their project succeeds even if it means making them (temporarily) unhappy.
  - deleted 3y ago
    [deleted]
  - nine_zeros 3y ago
    > That's how I learned my job isn't to do what the client asks, it's to make sure their project succeeds even if it means making them (temporarily) unhappy. And I learned that doing it my way will get me fired because the manager has asked to do faster. The way I have learned to get around this is by making the manager publicly document the request to go faster. If they don't document, I don't see or act on it. Once they document it, I happily go faster and let it all crash and burn. Then when they inevitably try to blame me, I point at the public documentation of the request to go faster and let the blame fall on the person responsible.
    - jareklupinski 3y ago
      that's great for covering your a, but the project will still fail and no one will get value / praise for all that time spent if time is the only actual concern for the project's success, a good approach is to explicitly re-scope the feature list and start asking managers things like: "do we really need feature X to release? can feature Y wait until after beta? did the request for feature Z come from a user or a stakeholder?" document all that too of course ;) but then at least there is a chance for safety _and_ success
3np 3y ago
On an individual level: So what? I stopped giving a f. I'd rather do what I believe is right than earn another $100k a year at a certain point. If it gets to the point of being laid off, hey, maybe it's the nudge you needed to find a better place anyway. Meanwhile, you could play the game all you want and still have your entire business unit shuffled away next year. I'm not going to drive off a cliff just because the OKR tells me there's actually a road there but I wonder about some people...
nine_zeros 3y ago
> It sucks being that person today because everything is about optics and that person will get purged. I know from experience. This is my company. Engineer skills, tech-debt, teamwork, camaraderie don't matter. Do as the management says, in the time they've promised to others or else....
andai 3y ago
"Negative 2000 Lines of Code" https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
- ZeroClickOk 3y ago
  nice, thanks for the link
AStellersSeaCow 3y ago
Depends on the company and management. Google codifies this role to some extent as Tech Lead, which is an engineer expected to act as a force multiplier and mentor more than an individual contributor. It doesn't always work as designed (ok, maybe rarely works as designed), and TLs can get too bogged down in cat herding, planning, and bike shedding to actually work as an engineer. But at least the spirit of the role is sound.
- TheRealPomax 3y ago
  It also doesn't get people promoted to that position just because that's what they're doing. Because politics.
  - Arainach 3y ago
    My experience at Google has been that TLs were generally strong engineers who were doing that kind of mentorship and product leadership, so to the degree that it's a "promotion" (same money, more responsibility isn't a promo in my book) it does seem to go to those who are doing it. Now TLM (Tech Lead + Manager), however......there's a role that's set up for failure. Be a manager but be judged entirely on your technical contributions.
    - nobodyandproud 3y ago
      I have to manage up, gently, reminding my manager and his peers that we’re managers first. Any meaningful contribution or engineering is extra credit.
  - AdrianB1 3y ago
    Is that a higher level position ("promoted" suggests that)? In my FMCG IT department I am the TL & "technical architect", but I am on the same level as a senior developer, just having in the top 3 priorities the coaching and mentorship of all technical people in the department and no code expected (I do write some as examples or templates). What is the TL level in Google vs developers and architects?
Aperocky 3y ago
> I tend to think that the dev who can churn out thousands of lines isn't thinking deeply enough about the long term direction of the project; all the code they're writing is essentially throwaway code. This is a strong statement. There are both people who are writing throwaway code and people who are writing essential code that match the description. And one will never get to be the latter part without going through a phase where they are doing the first.
- legends2k 3y ago
  > one will never get to be the latter part without going through a phase where they are doing the first. The parent comment doesn't contest this. I think it's about the throwaway code author being valued more than the other.
cratermoon 3y ago
> Managers always love a developer who can consistently write 5000+ lines per code per week Managers love metrics. There's nothing wrong with metrics, of course. It's when metrics become targets that things fall apart. https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
l33t7332273 3y ago
>Managers always love a developer who can consistently write 5000+ lines per code per week What managers care about this at all?
- DiabloD3 3y ago
  The ones that work at companies that promote incompetence. You know, most companies.
- goalieca 3y ago
  5000 lines is silly, but all managers love that coder who closes tickets faster than anyone.
  - no_wizard 3y ago
    If they can keep them closed. One sign I see if a healthy workplace is one that tracks bugs and QA issues downstream against the same unit of work. You quickly get a sense for what teams and even individuals are introducing the most bugs and issues. If you can close tickets fast and your bug rate is low: that’s key, but I have found often that the people introducing the most bugs and issues into the codebase that others have to spend time dealing with are those that seemingly close their tickets rapidly every sprint
- hinkley 3y ago
  The first project I was on that hit half a million lines of code, 2/3 of it was generated. It was a bit ridiculous.
beebmam 3y ago
If your leadership is tossing these incredibly valuable engineers aside, then it's time for you to toss that leadership out. You can do that by leaving, or talking to management about this, or unionizing. It's crazy to me tech workers aren't unionizing anyway.
- b800h 3y ago
  I prescribe a viewing of "Carry On at your Convenience" to cure that sentiment: https://en.m.wikipedia.org/wiki/Carry_On_at_Your_Convenience https://en.m.wikipedia.org/wiki/Carry_On_at_Your_Convenience
- Pamar 3y ago
  (I am from Europe, so I have a fairly good idea of what Unions can do, also thanks to having lived and worked in two different countries). I am not against Unionizing "per se" but the role of Unions has never been "tell the management how to run their business". There has been some cases of (smallish) company being "acquired" by their own workforce, and the Unions might have helped with formalizing the deal, but this is rare, and anyway happens only when the company goes bankrupt or decides to shut down. So I do not understand exactly what you mean here.
  - CapitalistCartr 3y ago
    A union would provide the sort of employment protections much of Europe alreadys enjoys.
    - Pamar 3y ago
      I know how Unions work. The OP stated: ...it's time for you to toss that leadership out. You can do that by leaving, or talking to management about this, or unionizing. A Union can organize and sustain a strike. But they cannot "toss leadership out". Not the CEO, the Board or any manager at any level. They could theorethically "blackmail" a company saying "strike will not end until X is fired" where X is a PM or manager or whatever but I never really heard of anyone trying this tactic, not to say actually succeed...
droopyEyelids 3y ago
This is the “sorting hat” the makes sure that person ends up at the right company. Its not fun to lose your job, but that can be better than being stuck just getting by at a company where your work isnt appreciated.
closeparen 3y ago
I don’t know. I’ve met several people who see themselves like this and who are seen by senior leadership as being like this, but nothing they say tracks, even a little bit, with what I know about the system and problem space from my time actually immersed in working on it.
mike_ivanov 3y ago
Given that DRY is out of fashion, 2000 lines of code per week looks pretty modest.
8n4vidtmkvmk 3y ago
I love writing code. I usually "score" on the higher end for LoC which managers like to praise me for while simultaneously saying LoC isn't everything but there aren't many good measures. Lol. But! In my defense, I delete as much code as possible. Love deleting code. Not sure if that counts in the LoC. I see lots of others copy and pasting and leaving little bombs everywhere. I refactor, clean, delete. So.. hopefully my LoC is mostly that and not adding fluff.
thefaux 3y ago
[flagged]
arrjayh 3y ago
I'm working through this exact situation right now, I really appreciate this insight!
ChrisMarshallNY 3y ago
> There is a very good chance that the same feature set could have been implemented with just 10K lines of code, less buggy and in half the time A significant part of my personal code review process, is going back through my code, and factoring out complexity. It takes time and humility, but is very much, in my opinion, worth it. Documenting my code is a trick that helps. When I am writing why I did something, I sometimes reflect, and say to myself "Didn't I just do this a few lines back?" My code tends to be complex, by necessity, but it should be no more complex than absolutely needed. A big, big tool for that, is OOP inheritance, which is considered "bad coder" smell, these days.
- Chris_Newton 3y ago
  A big, big tool for that, is OOP inheritance, which is considered "bad coder" signal, these days. Is it? I’d agree that there’s increasing awareness of the limitations of OOP, and I’d agree that using inheritance excessively can be one of the limiting factors, but I don’t think I’ve ever personally seen anyone criticised or penalised for using inheritance appropriately.
  - ChrisMarshallNY 3y ago
    Just using OOP is considered bad. There is no "appropriate" way to use OOP. I see people being criticized for that, all the time. I have run into folks that don't understand polymorphism. It seems that it is not even being taught. Old Boomer Yells at Sky
    - 3np 3y ago
      I've done a lot of OoP and my opinion these days is that if the reader needs to understand polymorphism properly to understand your inheritance, it's too complex. (Exceptions exist, of course, like libraries inherently dealing with reflection)
      - ChrisMarshallNY 3y ago
        Well, to each their own. I like to understand everything I do, at a very deep level, and I really enjoy learning that kind of stuff. I started as an EE, so my understanding sinks down into the FET junction. My first software was machine code, so it’s been a long, strange trip. One thing that geeks love doing, is telling other geeks they are bad at what they do. It gets a bit grating, but I’ve come to the realization that I need be true to myself, because it’s a losing proposition, hanging my self-respect on the opinions of others. I do what I do, and get the results I get. I don’t spend much time, worrying about how I compare to others. One of the benefits of working at the direction of my own muse.
yourapostasy 3y ago
This is why software craftsmanship is rarely recognized. When you build with craftsmanship so features are easy and fast to add on top of what you built because you thoughtfully the most likely ramifications of the current requirements within reason, operational excellence is easy to accomplish because you sat down with front line operators and took the time to understand their incentives and daily operations pain points from a first-person perspective, and so on, you aren’t the one who is recognized with the commensurate credit, those who benefit from your work in the future are the ones who grab the limelight as if they did your work, unless the leadership are themselves highly technical (and many times, not even then). Incentives currently in most of my clients are mostly aligned to the fulfillment of keywords and not an outcome. “Produce a procedure documentation” gets keyword fulfilled into “here is a document with some steps”, instead of “here is a procedure we wrote, used spelling and grammar checker upon [I’m still shocked so few take the few seconds to correct as they go], run through an automated editor, then iterated through random people from the user population until someone who never saw it before accomplishes the procedure without assistance”. Some startups succeed because they’re forced into conscientiously thinking through these ramifications in just the right contexts because they’re so close to the coal face. It is also possible to overdo this in the wrong context and end up bikeshedding.
Gibbon1 3y ago
Friends of mine worked at a place were they got a rock star programmer that churned out thousands of lines of code a week. And they eventually found themselves relegated to the role of cleaning up the mess. So they all quit. Edit: Take rock stars 3000 lines of code a week and divide by one rock star + six experienced developers now doing nothing but bug fixes and it doesn't seem so super.
deleted 3y ago
[deleted]
sshine 3y ago
> sucks being that person today because everything is about optics Not everywhere. I’ve casually suggested five big changes to the startup I’m currently working for that others ran with. I’m proud that my ideas even make sense, and my reward is that others come to me for leadership. I would get more glory if I had also carried them out. But I’d rather do the things that others can’t, than what shines the most. > 2000 lines of code per week terrifies me... That's over 100K lines of code a year That would be incredible (and scary). But productive people I’ve seen the contributor metrics for who write vastly more than they read, still have a number of deleted lines growing with their added lines in some proportion. There is a style of less re-use, more copy-pasting that just grows faster but also needs constant refactoring in trivial ways.
yodsanklai 3y ago
> That's over 100K lines of code a year. Think of the unnecessary complexity. I've got a colleague like that. It's all good and management praises him, but this is a time ticking bomb. When he leaves, someone will have to maintain that code.
vGPU 3y ago
I could be brief. Or I could elaborate, expound, simplify, and expand my solution. It depends what I’m getting paid for. If I’m getting paid for lines of code, guess who’s going to re-implement functions that could have been a single line of code? Why bother writing a loop function when I could just copy-paste the same code as many times as needed? Turning one line of code into 3,000 - easy. Turning 1,000 lines into 100 - that’s when you know you’re working with a professional.
benreesman 3y ago
You’re largely correct but I think your comment might not nail the root cause (not saying you don’t know this, just that your comment doesn’t emphasize it). When a market is competitive, the things that matter are roughly: hard work, candlepower, and optics/neurotypicality/maneuver in that order. When a market is fairly sewn up that order becomes roughly: optics, candlepower, ethical flexibility, hard work in that order. The hard-ass nerds who don’t give a shit about corporate culture du jour are treated like royalty when someone might fuck your business up. While “purged” is a strong word, I take your meaning, and whatever we want to call it, it happens when competition is largely pro-forma. Human beings will do anything to avoid selecting on merit except lose. That’s just human nature. Being mad about it is like yelling at the wind, but compared to even a decade ago, I’m not sure how high I’d be holding my head in today’s competitive landscape for high-prestige achievement.
varispeed 3y ago
I worked at companies where de facto lines of code were a metric of performance. Then when I moved to first company where "how" was more important I had a heavy anxiety where I didn't write a line of code for a couple of weeks. I was worried I'll get fired. We were just having meetings and just talking about problem at hand and throwing ideas, without actually trying to implement anything. Then when the ideas how to tackle the problem matured, we would try to turn it into code, like a proof of concept thing (tested with people looking for solution) which could be thrown away. Eventually we would get the solution to the problem and most of the time it was flawless. In the code heavy approach, company would have ton of bugs, support requests, fixes on top of fixes, sometimes it turned out the feature was misunderstood, but it was already so embedded in the system, it was difficult to remove. So things were piling on. The other approach? Boring. We had some bugs here and there, usually when something was not covered by the tests or some edge case we didn't think of. But I never forget the anxiety...
baby 3y ago
I want to frame this comment somewhere
dang 3y ago
We detached this subthread from https://news.ycombinator.com/item?id=37362066 https://news.ycombinator.com/item?id=37362066. (There's nothing wrong with it but it's a bit generic and I'm trying to make the thread less top-heavy.)

88913527 3y ago

Because it's a bogus argument. The productive person doesn't need a paper weight at lunch to act as a shower thought generator. Management can get it wrong sometimes, but in broad strokes, they're right.

closewith 3y ago
Maybe, or maybe human endeavour is more complex than individual efforts.
- 88913527 3y ago
  It's tough, but what I've seen is low performers weigh the team down. They constantly ask for the high performer's time, and if we give them bug tickets, new feature work, they constantly stumble and always report status as blocked. They don't add value. They can't get to the finish line with anything. It's not a kind thing to point out, but trying to angle it as "oh there's this other benefit you're just not seeing" is trying to work around the fact they can't competently fulfill the job function after exhausting all of our options (training, pair programming, etc). They might be friendly people, but the social boosts don't counteract the losses incurred, it's still a net loss.
  - jodrellblank 3y ago
    You've turned the story round from "Tim MacKinnon is a good programmer and asset to the team which the simple metrics were not tracking" into the strawman "defend people who cant do their jobs and are not an asset to the team by claiming that they are nice people".
willcipriano 3y ago
Idea people really overestimate their contributions.
mynameisvlad 3y ago
Define "productive". Because lins of code churned out is not and has never been a good measure of productivity. That "shower thought generator" might very well be more productive than the person they're sitting next to churning out tens of thousands of lines of unmaintainable code if their shower thoughts are causing people to find better ways to solve a problem. Which is basically the entire point of the article.
- 88913527 3y ago
  It's more about measuring outcomes. We have a goal, did we meet the goal. There are many paths to the goal, so measuring things like lines of code is incorrect. But so is measuring Bob's ability to ask Alice a good question. Management can't, at scale, consider such factors. We don't have the counterfactual where Bob didn't ask the questions, and Alice did great anyways. Performance reviews would become even more subjective if we had to place a value on the impact of asking questions. All forms of measurement are flawed, so I stick with outcomes.
  - mynameisvlad 3y ago
    > Management can't, at scale, consider such factors. Why not? Peer feedback is a prime component of most performance/rewards discussions at companies. Work outside of points is certainly not a new concept. A manager's job is to distill this information amongst others to their own management chain at the right time. > We don't have the counterfactual where Bob didn't ask the questions, and Alice did great anyways. Bob's time isn't unlimited. There are surely instances where he was helping out Joe, Suzie, Darren, and James and had no time for Alice. Based on your other comment, you seem to think someone being an unblocker/idea generator/dev lead is a "low performer" who weighs the team down. That's just fundamentally wrong.
    - 88913527 3y ago
      It isn't wrong, it's right; because pontification of things (in a vacuum) yields no results. I cannot sell my customers Bob's ideas. All I can sell them is software that does something. The people that can do this without needing Bobs around are the people that will be rewarded.

deleted 3y ago

[deleted]

closewith 3y ago

In a remote world, can that person exist?

dharmab 3y ago
I am one of those people and work a fully remote job, but I had to earn that credibility with years of being a top contributor first. It would be difficult to just walk into the role.
- scruple 3y ago
  I wrote a sibling comment alluding to the same, having been that person across a few different employers now. The struggles I had certainly, to a large degree, boiled down to a lack of trust (walking into a new team/department/company is hard on both sides!), but that wasn't the full story. IMO, management needs to have the right mindset to establish culture, too.
deleted 3y ago
[deleted]
scruple 3y ago
Yes and no, depends on the engineering culture and the management. I was successful in this sort of position as a full-time remote senior and then a team lead from 2016 til 2022. I changed employers and found myself in an environment that simply did not understand pairing, mentoring, etc. Management was oftentimes directly in the way, confused about loss of "velocity" and other trivial bullshit, despite the fact that the team was shipping in overdrive. I left at the start of this year and am now back in a position where these things are valued, encouraged, and happening remotely.
greenyouse 3y ago
That would depend on the culture of your team and larger workplace. Healthy teams should be checking in frequently to talk about ideas, reviewing big things, scoping upcoming work, etc. If there's time reserved for deeply technical but loosely structured discussion like that, then everybody takes turns being that person. In that env someone could "specialize" in it and help inspire others to do great work. It's the team that creates that kind of opportunity for feedback though. If the team has dysfunctions like rejecting deeper discussion or not working beyond jira tickets or checking out at meetings, etc. then it's not going to work. Someone that's good at that kind of supporting discussion will feel push back when fostering those discussions so it will fall off over time. The teams that do the best work and are the most fun to be on can host those types of discussions though, even remotely. It's worth experiencing if you haven't!

dharmab 3y ago

I've written several 100ks LOC/year at points in my career- but exclusively when working on new projects. When maintaining projects I might go a week at a time without writing any code solo, or I might spend a week trying to _reduce_ LOC.

dmoy 3y ago
I think my net contribution of lines of code at my current company is still negative. It was for a long time, but I haven't checked in awhile so I'm not sure if it still is.
- dharmab 3y ago
  Usually I end up adding more lines of documentation and tests and removing lines of application code so it's not easily measurable- on theme for this thread, heh
- allenrb 3y ago
  I remember times at a few of my jobs, just absolutely cheering for someone’s PR that was filled with red. Good times.
- deleted 3y ago
  [deleted]
- esafak 3y ago
  At my last company we had an architect whose only direct coding contributions were deletions, because nobody gets credited for cleaning up code.
jongjong 3y ago
My problem in my last role when I read large Pull Requests is that they tended to be way more complicated than they should have been but because they worked and I couldn't single out a small number of specific problems, I had no choice but to approve. Still, I knew it would slow us down in the medium and long term but this bloat is completely invisible to management. It has become taboo to say things like "This code is too tightly coupled", "You don't need to add an external dependency for that", "The inputs to those methods are too complicated; your components are micromanaging each others' state", "You're violating separation of concerns", "The cyclomatic complexity of this code is too high; you could simplify all your if-else statements"... When it's not my company, it's impossible to dismiss code when it works right now, even though it is likely to break later.

marcosdumay 3y ago

It sucked being that person back then too. The idea of measuring everything and acting on the numbers you can get is from the 19th century. Managers have been doing that same kind of practice since then, with the same kind of result (it's a very reliable result), without a change.

namaria 3y ago
Being superficial wasn't invented in the 19th century. People are very oriented to things they can see, measure and touch, when the most impactful and insightful people are often the silent care takers, the teachers, those keeping things running smoothly. When you do things right, people won't be sure you've done anything at all.
vegetablepotpie 3y ago
A lot of that is from Frederick Taylor, who invented “scientific management”. He did experiments where he would have workers shovel piles of ash from one side of a line to the next, giving them a new shovel size each day. Found that the ideal shovel size holds 21 pounds [1]. The ideological assumption of his work is that management exclusively does the thinking and the workers exclusively do the doing. This falls apart when the workers have unique knowledge and insight that management does not have. [1] https://www.mentalfloss.com/article/63341/frederick-winslow-taylor-patron-saint-shovel https://www.mentalfloss.com/article/63341/frederick-winslow-...
- marcosdumay 3y ago
  > when the workers have unique knowledge and insight that management does not have. AKA every time. AFAIK, Taylor himself wasn't nearly as radical about doing measurements and only acting on them nor about managers deciding everything and not listening to the workers as Taylorism preaches. His work was one of the many, many management theories that was completely modified to appeal to incompetent power-hungry wannabe dictators (and yet blamed on the person proposing the original theory).
tengwar2 3y ago
Acting on the numbers you get is not intrinsically a problem: it's what the action is. Looking at how fast stories, function points or whatever get closed is important for planning what you can get done in a given time, and that can be crucial for project management and managing customer expectations. It's not acquiring the information which is a problem; it's not using the metrics which is the problem. The problem is not understanding what the metric can be used to represent (project velocity), and what it cannot (individual productivity);

datavirtue 3y ago

Yeah, you have to do it all. Churn out stories AND mentor AND knock down "desk-side" work (random infra bullshit). I have been at big companies where no one lasts very long. Thier mental health suffers to a point where they have to leave so that they can go work at some other sweatshop for a while. The lull between giving their notice and the honeymoon at the new company is their only break.

tempodox 3y ago

The saddest thing is that some bosses want throwaway code. I had a short stint once in a company where the owner wanted the web service rewritten from scratch every 6 months so they could use the newest web framework and follow the current fashion. He would hire a 5000 LoC per week hero on the spot.

andai 3y ago
Tangential but I was doing a web app for a client and gave a time estimate, which accounted for doing things properly (i.e. learning a frontend framework first). He asked "can you do it faster" and I agreed, thinking I'll make a throwaway version first and fix it later. Needless to say the project was a disaster, rapidly became unmaintainable. That's how I learned my job isn't to do what the client asks, it's to make sure their project succeeds even if it means making them (temporarily) unhappy.
- deleted 3y ago
  [deleted]
- nine_zeros 3y ago
  > That's how I learned my job isn't to do what the client asks, it's to make sure their project succeeds even if it means making them (temporarily) unhappy. And I learned that doing it my way will get me fired because the manager has asked to do faster. The way I have learned to get around this is by making the manager publicly document the request to go faster. If they don't document, I don't see or act on it. Once they document it, I happily go faster and let it all crash and burn. Then when they inevitably try to blame me, I point at the public documentation of the request to go faster and let the blame fall on the person responsible.
  - jareklupinski 3y ago
    that's great for covering your a, but the project will still fail and no one will get value / praise for all that time spent if time is the only actual concern for the project's success, a good approach is to explicitly re-scope the feature list and start asking managers things like: "do we really need feature X to release? can feature Y wait until after beta? did the request for feature Z come from a user or a stakeholder?" document all that too of course ;) but then at least there is a chance for safety _and_ success

3np 3y ago

On an individual level: So what? I stopped giving a f. I'd rather do what I believe is right than earn another $100k a year at a certain point. If it gets to the point of being laid off, hey, maybe it's the nudge you needed to find a better place anyway. Meanwhile, you could play the game all you want and still have your entire business unit shuffled away next year. I'm not going to drive off a cliff just because the OKR tells me there's actually a road there but I wonder about some people...

nine_zeros 3y ago

> It sucks being that person today because everything is about optics and that person will get purged. I know from experience. This is my company. Engineer skills, tech-debt, teamwork, camaraderie don't matter. Do as the management says, in the time they've promised to others or else....

andai 3y ago

"Negative 2000 Lines of Code" https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

ZeroClickOk 3y ago
nice, thanks for the link

AStellersSeaCow 3y ago

Depends on the company and management. Google codifies this role to some extent as Tech Lead, which is an engineer expected to act as a force multiplier and mentor more than an individual contributor. It doesn't always work as designed (ok, maybe rarely works as designed), and TLs can get too bogged down in cat herding, planning, and bike shedding to actually work as an engineer. But at least the spirit of the role is sound.

TheRealPomax 3y ago
It also doesn't get people promoted to that position just because that's what they're doing. Because politics.
- Arainach 3y ago
  My experience at Google has been that TLs were generally strong engineers who were doing that kind of mentorship and product leadership, so to the degree that it's a "promotion" (same money, more responsibility isn't a promo in my book) it does seem to go to those who are doing it. Now TLM (Tech Lead + Manager), however......there's a role that's set up for failure. Be a manager but be judged entirely on your technical contributions.
  - nobodyandproud 3y ago
    I have to manage up, gently, reminding my manager and his peers that we’re managers first. Any meaningful contribution or engineering is extra credit.
- AdrianB1 3y ago
  Is that a higher level position ("promoted" suggests that)? In my FMCG IT department I am the TL & "technical architect", but I am on the same level as a senior developer, just having in the top 3 priorities the coaching and mentorship of all technical people in the department and no code expected (I do write some as examples or templates). What is the TL level in Google vs developers and architects?

Aperocky 3y ago

> I tend to think that the dev who can churn out thousands of lines isn't thinking deeply enough about the long term direction of the project; all the code they're writing is essentially throwaway code. This is a strong statement. There are both people who are writing throwaway code and people who are writing essential code that match the description. And one will never get to be the latter part without going through a phase where they are doing the first.

legends2k 3y ago
> one will never get to be the latter part without going through a phase where they are doing the first. The parent comment doesn't contest this. I think it's about the throwaway code author being valued more than the other.

cratermoon 3y ago

> Managers always love a developer who can consistently write 5000+ lines per code per week Managers love metrics. There's nothing wrong with metrics, of course. It's when metrics become targets that things fall apart. https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

l33t7332273 3y ago

>Managers always love a developer who can consistently write 5000+ lines per code per week What managers care about this at all?

DiabloD3 3y ago
The ones that work at companies that promote incompetence. You know, most companies.
goalieca 3y ago
5000 lines is silly, but all managers love that coder who closes tickets faster than anyone.
- no_wizard 3y ago
  If they can keep them closed. One sign I see if a healthy workplace is one that tracks bugs and QA issues downstream against the same unit of work. You quickly get a sense for what teams and even individuals are introducing the most bugs and issues. If you can close tickets fast and your bug rate is low: that’s key, but I have found often that the people introducing the most bugs and issues into the codebase that others have to spend time dealing with are those that seemingly close their tickets rapidly every sprint
hinkley 3y ago
The first project I was on that hit half a million lines of code, 2/3 of it was generated. It was a bit ridiculous.

beebmam 3y ago

If your leadership is tossing these incredibly valuable engineers aside, then it's time for you to toss that leadership out. You can do that by leaving, or talking to management about this, or unionizing. It's crazy to me tech workers aren't unionizing anyway.

b800h 3y ago
I prescribe a viewing of "Carry On at your Convenience" to cure that sentiment: https://en.m.wikipedia.org/wiki/Carry_On_at_Your_Convenience https://en.m.wikipedia.org/wiki/Carry_On_at_Your_Convenience
Pamar 3y ago
(I am from Europe, so I have a fairly good idea of what Unions can do, also thanks to having lived and worked in two different countries). I am not against Unionizing "per se" but the role of Unions has never been "tell the management how to run their business". There has been some cases of (smallish) company being "acquired" by their own workforce, and the Unions might have helped with formalizing the deal, but this is rare, and anyway happens only when the company goes bankrupt or decides to shut down. So I do not understand exactly what you mean here.
- CapitalistCartr 3y ago
  A union would provide the sort of employment protections much of Europe alreadys enjoys.
  - Pamar 3y ago
    I know how Unions work. The OP stated: ...it's time for you to toss that leadership out. You can do that by leaving, or talking to management about this, or unionizing. A Union can organize and sustain a strike. But they cannot "toss leadership out". Not the CEO, the Board or any manager at any level. They could theorethically "blackmail" a company saying "strike will not end until X is fired" where X is a PM or manager or whatever but I never really heard of anyone trying this tactic, not to say actually succeed...

droopyEyelids 3y ago

This is the “sorting hat” the makes sure that person ends up at the right company. Its not fun to lose your job, but that can be better than being stuck just getting by at a company where your work isnt appreciated.

closeparen 3y ago

I don’t know. I’ve met several people who see themselves like this and who are seen by senior leadership as being like this, but nothing they say tracks, even a little bit, with what I know about the system and problem space from my time actually immersed in working on it.

mike_ivanov 3y ago

Given that DRY is out of fashion, 2000 lines of code per week looks pretty modest.

8n4vidtmkvmk 3y ago

I love writing code. I usually "score" on the higher end for LoC which managers like to praise me for while simultaneously saying LoC isn't everything but there aren't many good measures. Lol. But! In my defense, I delete as much code as possible. Love deleting code. Not sure if that counts in the LoC. I see lots of others copy and pasting and leaving little bombs everywhere. I refactor, clean, delete. So.. hopefully my LoC is mostly that and not adding fluff.

thefaux 3y ago

[flagged]

arrjayh 3y ago

I'm working through this exact situation right now, I really appreciate this insight!

ChrisMarshallNY 3y ago

> There is a very good chance that the same feature set could have been implemented with just 10K lines of code, less buggy and in half the time A significant part of my personal code review process, is going back through my code, and factoring out complexity. It takes time and humility, but is very much, in my opinion, worth it. Documenting my code is a trick that helps. When I am writing why I did something, I sometimes reflect, and say to myself "Didn't I just do this a few lines back?" My code tends to be complex, by necessity, but it should be no more complex than absolutely needed. A big, big tool for that, is OOP inheritance, which is considered "bad coder" smell, these days.

Chris_Newton 3y ago
A big, big tool for that, is OOP inheritance, which is considered "bad coder" signal, these days. Is it? I’d agree that there’s increasing awareness of the limitations of OOP, and I’d agree that using inheritance excessively can be one of the limiting factors, but I don’t think I’ve ever personally seen anyone criticised or penalised for using inheritance appropriately.
- ChrisMarshallNY 3y ago
  Just using OOP is considered bad. There is no "appropriate" way to use OOP. I see people being criticized for that, all the time. I have run into folks that don't understand polymorphism. It seems that it is not even being taught. Old Boomer Yells at Sky
  - 3np 3y ago
    I've done a lot of OoP and my opinion these days is that if the reader needs to understand polymorphism properly to understand your inheritance, it's too complex. (Exceptions exist, of course, like libraries inherently dealing with reflection)
    - ChrisMarshallNY 3y ago
      Well, to each their own. I like to understand everything I do, at a very deep level, and I really enjoy learning that kind of stuff. I started as an EE, so my understanding sinks down into the FET junction. My first software was machine code, so it’s been a long, strange trip. One thing that geeks love doing, is telling other geeks they are bad at what they do. It gets a bit grating, but I’ve come to the realization that I need be true to myself, because it’s a losing proposition, hanging my self-respect on the opinions of others. I do what I do, and get the results I get. I don’t spend much time, worrying about how I compare to others. One of the benefits of working at the direction of my own muse.

yourapostasy 3y ago

This is why software craftsmanship is rarely recognized. When you build with craftsmanship so features are easy and fast to add on top of what you built because you thoughtfully the most likely ramifications of the current requirements within reason, operational excellence is easy to accomplish because you sat down with front line operators and took the time to understand their incentives and daily operations pain points from a first-person perspective, and so on, you aren’t the one who is recognized with the commensurate credit, those who benefit from your work in the future are the ones who grab the limelight as if they did your work, unless the leadership are themselves highly technical (and many times, not even then). Incentives currently in most of my clients are mostly aligned to the fulfillment of keywords and not an outcome. “Produce a procedure documentation” gets keyword fulfilled into “here is a document with some steps”, instead of “here is a procedure we wrote, used spelling and grammar checker upon [I’m still shocked so few take the few seconds to correct as they go], run through an automated editor, then iterated through random people from the user population until someone who never saw it before accomplishes the procedure without assistance”. Some startups succeed because they’re forced into conscientiously thinking through these ramifications in just the right contexts because they’re so close to the coal face. It is also possible to overdo this in the wrong context and end up bikeshedding.

Gibbon1 3y ago

Friends of mine worked at a place were they got a rock star programmer that churned out thousands of lines of code a week. And they eventually found themselves relegated to the role of cleaning up the mess. So they all quit. Edit: Take rock stars 3000 lines of code a week and divide by one rock star + six experienced developers now doing nothing but bug fixes and it doesn't seem so super.

deleted 3y ago

[deleted]

sshine 3y ago

> sucks being that person today because everything is about optics Not everywhere. I’ve casually suggested five big changes to the startup I’m currently working for that others ran with. I’m proud that my ideas even make sense, and my reward is that others come to me for leadership. I would get more glory if I had also carried them out. But I’d rather do the things that others can’t, than what shines the most. > 2000 lines of code per week terrifies me... That's over 100K lines of code a year That would be incredible (and scary). But productive people I’ve seen the contributor metrics for who write vastly more than they read, still have a number of deleted lines growing with their added lines in some proportion. There is a style of less re-use, more copy-pasting that just grows faster but also needs constant refactoring in trivial ways.

yodsanklai 3y ago

> That's over 100K lines of code a year. Think of the unnecessary complexity. I've got a colleague like that. It's all good and management praises him, but this is a time ticking bomb. When he leaves, someone will have to maintain that code.

vGPU 3y ago

I could be brief. Or I could elaborate, expound, simplify, and expand my solution. It depends what I’m getting paid for. If I’m getting paid for lines of code, guess who’s going to re-implement functions that could have been a single line of code? Why bother writing a loop function when I could just copy-paste the same code as many times as needed? Turning one line of code into 3,000 - easy. Turning 1,000 lines into 100 - that’s when you know you’re working with a professional.

benreesman 3y ago

You’re largely correct but I think your comment might not nail the root cause (not saying you don’t know this, just that your comment doesn’t emphasize it). When a market is competitive, the things that matter are roughly: hard work, candlepower, and optics/neurotypicality/maneuver in that order. When a market is fairly sewn up that order becomes roughly: optics, candlepower, ethical flexibility, hard work in that order. The hard-ass nerds who don’t give a shit about corporate culture du jour are treated like royalty when someone might fuck your business up. While “purged” is a strong word, I take your meaning, and whatever we want to call it, it happens when competition is largely pro-forma. Human beings will do anything to avoid selecting on merit except lose. That’s just human nature. Being mad about it is like yelling at the wind, but compared to even a decade ago, I’m not sure how high I’d be holding my head in today’s competitive landscape for high-prestige achievement.

varispeed 3y ago

I worked at companies where de facto lines of code were a metric of performance. Then when I moved to first company where "how" was more important I had a heavy anxiety where I didn't write a line of code for a couple of weeks. I was worried I'll get fired. We were just having meetings and just talking about problem at hand and throwing ideas, without actually trying to implement anything. Then when the ideas how to tackle the problem matured, we would try to turn it into code, like a proof of concept thing (tested with people looking for solution) which could be thrown away. Eventually we would get the solution to the problem and most of the time it was flawless. In the code heavy approach, company would have ton of bugs, support requests, fixes on top of fixes, sometimes it turned out the feature was misunderstood, but it was already so embedded in the system, it was difficult to remove. So things were piling on. The other approach? Boring. We had some bugs here and there, usually when something was not covered by the tests or some edge case we didn't think of. But I never forget the anxiety...

baby 3y ago

I want to frame this comment somewhere

dang 3y ago

We detached this subthread from https://news.ycombinator.com/item?id=37362066 https://news.ycombinator.com/item?id=37362066. (There's nothing wrong with it but it's a bit generic and I'm trying to make the thread less top-heavy.)