Comment by jongjong
2 years ago
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.
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.
Tech Lead is a very difficult role. :/
If you are immature or competitive, you cease being a force multiplier to be a morale destroyer.
If you are more of a domain expert than your Product Managers, you will spend your time fighting and refining tasks to build features the right way.
If you don't have enough time to code, you'll go obsolete.
I'm the frontend lead in a company of about 200 people (mostly devs) these days, and the idea of being a force multiplier is spot on. I'm not there to be the best dev or the most knowledgable; I'm there to lead the conversation and amplify people who are saying good things. Having a pretty deep understanding of the tech is useful so I can tell what those good things are. I am absolutely not in the company to show off or take credit for what my teams do.
Where I disagree is with the idea of fighting with product owners. If there's a disagreement around approach or tech choices that's a sign we don't have enough information. Fighting or refining won't solve that. It's a signal that we need to do more discovery work and understand the problem better.
2 replies →
> If you are more of a domain expert than your Product Managers, you will spend your time fighting and refining tasks to build features the right way.
If you are more of a domain expert than the product managers, argue for the product managers to be fired - they serve no purpose.
It also doesn't get people promoted to that position just because that's what they're doing. Because politics.
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.
1 reply →
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?
1 reply →
The TL role is a little restrictive IMHO. I’ve worked with very junior people who have a very effective ability to pair and improve others’ effectiveness. Perhaps as they learn they also teach.
This was my experience as well. It's completely up to management to recognize these kinds of engineers regardless of role name or leveling.
"Negative 2000 Lines of Code"
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
nice, thanks for the link
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.
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-...
> 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).
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.
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);
Those are not important at all, or the top software projects would be using them. Linux kernel is doing fine without the velocity point story tickets. Agile "planning" which is used in worse software projects is snake oil.
It may be useful to collect metrics to get insights, but if they are publicized as a measure of performance, it's likely they'll be gamed, making them less useful.
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.
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.
> 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.
8 replies →
> 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
This sounds like an improvement over the opposite, a code base that is rarely touched and uses eol frameworks. Software is a living thing and if you don’t act as a ruthless gardener you wind up a museum curator with 1990s DEC hardware running in the 2010’s.
The right balance of staying current and not reinventing the wheel is not trivial.
If you choose the right frameworks which have sufficient momentum to last you say 10 years, you don't have to put yourself in the dilemma.
And yes, 10 years is quite possible these days. Besides the infamous Javascript framework churn, things are moving quite a bit slower in recent years.
2 replies →
Hey, if the 1990s DEC hardware still works, and it'd be more expensive to change it...
There are PDP-11s running nuclear plants today with support contracts to keep them running until 2050.
PDP-11s.
2 replies →
It depends on “when” along the timeline of the project.
If we don’t know if anyone will want the product, the quality of the product is less valuable than validation of product market fit.
Later, I care much more about avoiding accidental complexity and having a great technical foundation.
But you can’t have the technical foundation later because you’ve already built on something else.
3 replies →
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.
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.
I'm honestly not familiar with this "I had no choice but to approve" mindset. In the greenfield projects I've worked on there was always at least one person, sometimes several, who had the authority to just say "no, this is far too complex, scratch it all and we'll meet tomorrow to discuss next steps." Sometimes it ended up with breaking the PR into several more manageable pieces, sometimes it ended up with a wholesale rewrite / refactor of that component.
2 replies →
I sometimes use my job title as a higher level senior or lead to say vulnerable things like:
"This change is hard for me to read and understand"
or
"This is a large PR, and it may be difficult for me to schedule time to review it. Can it be split up into a series?"
I also configure linters and code quality tools to automatically flag some of the more egregious problems.
14 replies →
"You don't need to add an external dependency for that" "You're violating separation of concerns"
I've found that kind of feedback to be useful actually. And when giving similar feedback it is received better with a small change in wording to make it more about the code and not the person. Even if that is the intention the wording does matter. For example:
"An external dependency isn't needed here, try implementing with XYZ instead." "Split this function into x and y for better separation of concerns"
Removing the "you" removes some resistance to receiving the message .
3 replies →
Somewhat unrelated, but it's true that it's sometimes hard to give a reason to reject code that has a "funny smell".
Without going into specifics, there was a case where I reviewed a PR, asking "this isn't usually how people do file operations, are you sure this is really fine?" To address my concerns, they even wrote a specific test program to "prove" that there weren't any problems with the code. I reluctantly approved the PR since I couldn't just ask them to rewrite the whole patch due to just a hunch.
Lo and behold, after a kernel upgrade and file system change, that weird piece of code caused a multi-week panic for the whole team. The extra funny thing is that the test program above made it trivial to confirm and reproduce the issue once we identified this was the cause.
Right. This is where you would think the AI assistance could play an important role:
Warning: it looks like you’re trying to pack too much crap into a single PR and your peers are unlikely to understand what they are accepting.
1 reply →
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.
I remember times at a few of my jobs, just absolutely cheering for someone’s PR that was filled with red. Good times.
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
At my last company we had an architect whose only direct coding contributions were deletions, because nobody gets credited for cleaning up code.
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.
(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.
Unfortunately union / labor movements in the US suffer from a big problem: due to historical circumstances they’re very combative. The labor movement here never grafted the idea of being business oriented on behalf of workers into the movement (like in Germany) rather, they treat the business as the enemy pretty much from the outset.
Some of that is indeed earned by the businesses reputation, but ultimately this is what I think spurred the decline of union membership in the US because businesses don’t get a lot if any value out of having a union around and the organized workers often find the benefits stagnant after some time
2 replies →
A union would provide the sort of employment protections much of Europe alreadys enjoys.
1 reply →
A union doesn’t have the power to change management, and is just as likely to advocate to retain low performing ICs in the name of “solidarity”
When you can get a bootcamp certificate, and then get two remote jobs and coast at both for 12 months, and then repeat, what could a union do for you?
Are you currently doing this? Living in an expensive region like Western Europe/North America? If this first or second hand, let's hear more about it.
1 reply →
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
[flagged]
Unions may be different in your part of the world. In America, it's one of the only ways for blue collar or other production-oriented workers to have any degree of leverage at the negotiation table. We are treated like cattle in the workplace, and though unions come with their fair share of problems (due to it being yet another leadership structure to work within), the idea of workers holding power as a group is essential, because it reflects reality. None of that VC money is getting a return without workers to do the work. Most places in America are not unionized, but the ones that do pay better than other work in the area, even after union dues.
I see it as very much a union-by-union thing, much like you would an employer.
Now, some programmers may be able to negotiate good terms for themselves, but the vast majority of that stage is simply how silver your tongue is. Why should you be paid better because you got a better charisma roll with the interviewer? I would want my coworkers to be paid the same as me for the same experience. A senior with 10 years in the field, naturally, would be paid much more.
It's strange you say developers can negotiate, when there've been quite a few layoffs as of late and we see plenty of stories of people having trouble staying in tech. Which is it? The only thing that can give you credible sway is learning rarer or more in-demand skills, and putting together projects that show you understand how to use them. And for how long will that last? A union is a lot harder to fight than an individual.
But yes, there are bad unions. If they're as bad as your alleged blue collar friends say, let's name them! Sometimes their politics or dues or seniority system sucks. Those systems deserve to be put on blast.
But strangely, no unions listed in your comment as bad.
3 replies →
I have seen first-hand the negatives of unions in Italy: there are downsides of powerful union control. But in the US, a strong argument can be made that unions played a very major part (along with the GI Bill of course) in the growth of the the middle class from 1950 to 1980, and their busting, starting with Reagan, likewise was instrumental in the dwindling of the middle class and the dramatic rise in wealth inequality.
71% of Americans support unions - though you may not live there.
https://news.gallup.com/poll/398303/approval-labor-unions-hi...
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.
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...
> 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.
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.
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.
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.
> 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....
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...
>Managers always love a developer who can consistently write 5000+ lines per code per week
What managers care about this at all?
The ones that work at companies that promote incompetence.
You know, most companies.
5000 lines is silly, but all managers love that coder who closes tickets faster than anyone.
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
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.
> 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_Li...
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.
> 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.
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.
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
4 replies →
Some of that is the fact industry never really evolved OOP approaches and they tended to trend to toward heavy and complex. Peers aren’t great with the power OOP can have.
I’ve also seen composition go sideways too.
Sometimes it feels like nobody takes software engineering seriously anymore, if I’m being honest
Yeah, I remember that "Write a story. The nouns are objects, and the verbs are methods." school of thought.
I never warmed to that. In my experience, it resulted in unholy messes.
In a remote world, can that person exist?
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.
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.
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.
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!
Yes.
I assume you mean the thoughtful person whose probing questions unlock and unblock everyone else.
Lunchtime conversation is only one enabler of this.
I suspect the person is Hamming, as he makes reference to this in his book The Art of Doing Science and Engineering.
This aspect of what it takes to be a Hamming is curiosity about what other people are doing; you can track this by reading shipped emails or lurking in slack channels, then reaching out individually to the people/teams involved when you wonder about something.
Hamming was intentional about doing this at lunch. The magic isn't lunch, it is in intentionally seeking the information and then acting on it.
Yeah the main thing I've found helps is if there's a regular Teams/Zoom meeting where everyone just pops in for like 30 min to ask questions. Then you can use that as the springpad to launch into one-on-one sessions.
You do need to cultivate a culture in the team of people being willing to lower their guard and ask questions though. And I think the key to this is just staying humble so people feel comfortable approaching you.
> 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.
> 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.
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.
> 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.
We detached this subthread from 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.)
Given that DRY is out of fashion, 2000 lines of code per week looks pretty modest.
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.
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.
I'm working through this exact situation right now, I really appreciate this insight!
I want to frame this comment somewhere
[flagged]
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.
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.
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.
5 replies →
why? most code is not some complex algorithm where 100 lines of code can take years of genius work to figure out. Unit tests, for example, have near linear proportionality between LOC and utility. Same for comments, same for standard business logic.
5 replies →
Maybe, or maybe human endeavour is more complex than individual efforts.
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.
1 reply →
Idea people really overestimate their contributions.