[HN Gopher] The worst programmer I know
___________________________________________________________________
The worst programmer I know
Author : zdw
Score : 810 points
Date : 2023-09-02 14:41 UTC (8 hours ago)
(HTM) web link (dannorth.net)
(TXT) w3m dump (dannorth.net)
| slowhadoken wrote:
| The business mindset wants employees to be contestants in a
| reality tv show. The process of creating things doesn't look like
| a commercial though. Progress doesn't care how you feel, it's a
| functional process that produces a clear perspective. Greed
| always obscures that vision.
| _mc wrote:
| A very relatable story. Of course, we all feel sorry for those
| other Tims out there who were not lucky enough to have such a
| good manager. Partly, because we see the Tim in ourselves.
|
| I think this is what we can do to help: Remember sometimes we are
| also those co-workers who took help from Tim around us and
| conveniently forgot to Thank their contribution in success of our
| project. A simple thank you note in the right meeting, slack
| channel or in the project delivery mail goes a long way.
| Measuring the indirect impact of an employee is hard, even if you
| were the manager at any level. Taking help is not a sign of
| weakness or acknowledging the contribution of a co-worker doesn't
| make your effort any smaller.
| jimkoen wrote:
| > I explained all this to the manager and invited him to come by
| and observe us working from time to time. Whenever he popped by,
| he would see Tim sitting with someone different, working on
| "their" thing, and you could be sure that the quality of that
| thing would be significantly better, and the time to value
| significantly lower--yes, you can have better and faster and
| cheaper, it just takes discipline--than when Tim wasn't pairing
| with people.
|
| BREAKING NEWS: Pair programming improves software quality, more
| at 5!
| Trasmatta wrote:
| Extensive pair programming can also be massively draining and
| burnout inducing for certain types of people. I hate it when
| companies mandate pairing. Some people's brains just don't work
| effectively in that type of environment.
| mberning wrote:
| I find it amusing and very telling that the organizations with
| the most burdensome and unnecessary overhead are always the first
| to take an interest in developer productivity. A metric which
| their own structural inefficiencies are in direct opposition to.
| just_dan wrote:
| [dead]
| gloryless wrote:
| I have been this person and I'm trying to move away from it. It
| really is a great skill to enjoy lifting others and to be the
| glue of a team. But there are multiple slippery slopes inherent
| to that role that make it difficult. You can begin to confound
| the knowledge of others as your own, and almost certainly your
| own IC skills will atrophy if not purposefully maintained. I
| think it also requires the explicit buy in of the team, or at
| least other seniors who understand the benefits and can help keep
| balance.
|
| It just takes one jealous colleague or one "efficiency minded"
| manager type to completely rug pull you. I know it's valuable
| because I have benefitted from that person many many times, but
| it takes empathy and a lot of balance.
| nittanymount wrote:
| clearly, Tim is a coach/mentor in this team, try to measure his
| work a wrong way ?
| redbell wrote:
| Evaluating someone's performance, especially, software engineers
| by non-tech people might produce dramatic results.
|
| Let me tell you a story about a friend of mine, codenamed
| _tommy_. Tommy was an IT guy with incredible skills in
| networking. He moved to an energy company, fully-owned and
| operated by the government. Just a few weeks from his arrival,
| they had to rebuild the entire network from scratch with new,
| modern, equipments as well as extending the network to all the
| buildings of the company's headquarters. They started to look for
| external contractors to outsource this project but Tommy was
| shocked by the price the financial department was willing to pay
| to get this work done, obviously, some non-tech people made the
| estimates. Tommy interrupted the operation and told the
| appropriate department he can do the work and needs only the
| physical equipments (routers, switches, cables) and two guys who
| can do the _cabling_. They agreed, and he took the challenge and
| delivered the work as expected within just a few weeks within
| _less than a tenth_ of the initial budget. All that he got was a
| _"Thank you, you did good work"_ oral endorsement by his boss.
|
| What a time to be an IT techie when your boss(es) are just old-
| school, who will never understand your true value.
| paulcole wrote:
| Was Tommy upset?
| redbell wrote:
| Absolutely! But after a while he knew why there was no kind
| of reward whether in the form of a financial compensation, a
| promotion or even additional days of vacation. Simply because
| the law of work does not have a section for _exceptional_
| performance /achievement.
| paulcole wrote:
| must've been Tommy's first rodeo lol
| [deleted]
| ajmurmann wrote:
| We all know Goodhart's Law: "When a measure becomes a target, it
| ceases to be a good measure". Quantitive measure done't work well
| and especially not for something as complex as software
| development. They might tell you were to look more closely at
| best. Qualitative assessments work much better, but those require
| trust. As soon as going gets tough for a company or department,
| trust weakens, doubt increases and higher management, especially
| if they don't understand software dev well, will require
| quantitive metrics. It's bad, but we'll never get rid of the mess
| because of organizational dynamics.
| [deleted]
| idontunder wrote:
| [flagged]
| mgaunard wrote:
| The worst programmer I knew never had any productivity problem;
| if anything he produced too much code, outpacing the others'
| ability to maintain certain levels of quality.
|
| He ended up promoted; in many organizations, people that hack the
| code rather than properly design and build sustainable solutions
| are highly valued.
| astrange wrote:
| Was he promoted to a job where he did more of that, or a job
| where they could make him stop writing code and do something
| else?
| ChuckMcM wrote:
| When I've been asked to coach someone on "technical leadership" I
| always ask them to be on the lookout for "facilitator" employees,
| those whose help makes another employee more productive or
| effective. I am convinced there are "service oriented"
| personalities where people get more job satisfaction out of
| helping someone else do a great job than getting all of the
| credit for doing something amazing. As the author points out they
| often "score poorly" and yet losing them will create net decrease
| in team productivity. I always try to give folks the tools to
| help distinguish between people who aren't productive because
| they aren't, and people whose productivity is exhibited in the
| success of others.
|
| It is never good to measure the "one" metric and manage to that,
| it results in people who game the metric "winning" and fosters
| the promotion of such behavior. I pointed this out to Google
| leadership and to quote Lazlo, "This is the system we have, it
| isn't perfect but we're going with it, either work within it or
| don't, it is up to you." :-). That meeting told me everything I
| needed to know about whether senior leadership was trying to have
| a better engineering environment or not.
|
| To many new managers come into the job (especially if they were
| engineers individual contributors before) with the idea that if
| they keep the "best" members, and move out the "bad" members both
| team morale will be great and so will the teams output. But they
| miss that their understanding of "best" is not based on managing
| people, its based on getting their original job done. As a result
| they favor people who mirror their skills and habits and disfavor
| those who have different skills and habits. Getting them to see
| this and having their eyes go wide with realization is always
| interesting.
| 88913527 wrote:
| Have you ever seen an organization filled with service-oriented
| employees and no doers? Zero-interest rate policy has lead to
| having more Senior Director of Jira Board Management and Lists
| of Tasks type roles and not enough people that can do the work.
| I'm not opposed to the idea that others can be a catalyst for
| the productivity of others, but you need the others for
| anything to get done, otherwise it's necrosis.
| ChuckMcM wrote:
| > Have you ever seen an organization filled with service-
| oriented employees and no doers?
|
| Yes, but to be fair it was an IT organization which had
| settled on a metric of "tickets processed" for their quality
| metric. As a result people who processed a bunch of tickets
| but never addressed root causes were seen as "good" vs people
| who wanted to fix fundamental problems that would reduce the
| number of tickets. It was, for me, a pretty classic case of
| picking the wrong metric. And to be fair the "best"
| IT/Service org is one that looks like it has nothing to do
| because it is always ahead of the curve of upcoming issues,
| and upper management has a hard time with that.
| hi_dang wrote:
| [flagged]
| mynameisvlad wrote:
| "Didn't happen to me anecdotally so must be fake news" is not a
| compelling argument.
|
| Also to say it couldn't happen at tech companies is pretty
| bold. There's nothing special about tech companies. They can
| hire incompetent managers just as well as other companies.
| hi_dang wrote:
| [flagged]
| AtNightWeCode wrote:
| Metrics. I used to work on a team with skills in agile
| development. The process was evaluated at every retro and
| everything was tweaked. One member of the team however continued
| to put tasks into states that was not even in our agile board.
| Meaning. You could not drag a task into that state. You had to
| set it. Turned out that the idiot CTO used an unknown report to
| evaluate staff. One metric was putting a task into a specific
| state no longer used by our team. The idiot CTO had told his
| favorite pet dev about this metric.
|
| Too bad I quit before the CTO, CEO and most of the board members
| got fired. Would have enjoyed sitting there and going. Yes, yes,
| yes.
| igama wrote:
| "Tim wasn't delivering software; Tim was delivering a team that
| was delivering software. The entire team became more effective,
| more productive, more aligned, more idiomatic, more fun, because
| Tim was in the team." - This happened years ago to me, with a
| manager pulling me aside and asking why my Tickets resolved were
| so low... They only cared about the number of tickets worked
| on...
| watters wrote:
| The title is a fairly harmless form of click-bait.
|
| What the author describes is the effect on a solid senior
| engineer working in a terrible organizational system for a not
| very skilled or savvy manager.
|
| Such managers (and directors and VPs) are common, even in the top
| tech companies. They may occur less frequently in those
| companies, but skilled, savvy managers are much rarer than
| excellent engineers, so the dysfunction described continues
| unabated in all companies.
| csours wrote:
| I've asked this question a number of times now: What is the unit
| of work for software development?
|
| If you work on a factory line, you can measure widgets per hour
| and quality. In construction, you can measure distance or area
| completed. But in programming, you are not making a repeatable
| product like the factory line. You can say that developers
| deliver story points; that is the product, not the work.
|
| I invite you to come up with your own answer before you read
| mine.
|
| ----
|
| ----
|
| ----
|
| I think the inner cycle of development is learning and trying.
| You learn about a system, make a theory, try that theory out, try
| to extend that theory, then you test. That test will let you
| learn some more - was I right or wrong, was there some side
| effect. Then you repeat.
|
| I don't think this learning and trying is a good unit of measure
| for performance, but I do think it's a good basis for an
| engineering notebook, which may be reviewed with a manager.
|
| Non-junior developers are essentially managing themselves when it
| comes to getting the work done. So how do you manage a manager,
| when that manager is not responsible for widgets?
| johndhi wrote:
| Nice story. It's unfortunately really hard for higher management
| to see something like this. I guess it's on the middle manager to
| convince upper management of this.
|
| Unfortunately in my current experience my manager is not at all
| like Tim.
| ncruces wrote:
| This worst programmer sounds eerily similar to the best one (from
| the Twitter thread).
| mattlondon wrote:
| Personally I want the seniors on my team actually delivering on
| the really hard stuff.
|
| Helping juniors do their job is great and all, but you still need
| experienced people to work on the hard and complex stuff that
| juniors _can 't_ because they don't have the
| knowledge/experience/people-skills. No amount of pair programming
| can replace that.
|
| You don't want to be in a situation where you have _really really
| well implemented_ low-value features, but the high-impact and
| high-priority hard stuff was not done because some of your most
| experienced folks were helping the less-experienxed people write
| effective unit tests or whatever.
| spyhi wrote:
| A senior engineer can work through a hard problem assigned to a
| junior engineer, resulting in a well-implemented hard feature
| and a less junior engineer. Just because a junior engineer is
| working on it doesn't mean by default it's an easy problem--how
| are you going to grow your engineers otherwise?
| wizerdrobe wrote:
| Some firms simply hire nothing but Seniors. You trained up a
| Junior-Mid-Senior? Cool, well offer him 20k more and call it
| a day.
| nathias wrote:
| If I worked somewhere where a guy would shadow me, hover around
| and 'support' me that would make me quit very fast.
| Waterluvian wrote:
| I've met a lot of project managers who are competent and see the
| bigger picture. They actually pay attention and understand why
| the numbers are what they are. They respect that the numbers are
| a very flawed tool and cannot be utilized without context or
| understanding.
|
| I've also met a lot of project managers who are there because
| they're incompetent. They lean heavily on "agile" and "best
| practices" and say moronic stuff like, "can you show me how many
| lines of code each developer has added this month?" (this
| happened to me. I fought it hard, explaining that it's not a
| meaningful metric. I showed him a month that I wrote -1500 lines
| of code).
|
| I feel like I could say the same about managers, coders,
| executives. The incompetent exist everywhere and they lean
| heavily on bureaucracy to protect their existence.
| liquidpele wrote:
| Ive even seen good managers hold a few incompetents on purpose
| in preparation of layoff cycles in larger companies that do
| them consistently.
| earljwagner wrote:
| As half of the pair programming team, why not just give him half
| of the story points?
| GuB-42 wrote:
| Maybe the tool doesn't support that.
|
| Or maybe Tim didn't care about story points, he knew his worth,
| and he felt that if the company wanted to fire him on such an
| arbitrary metric, it wasn't a company worth working for
| anyways. In the end, he did well because he kept his job and
| the company dropped an inappropriate metric.
| shultays wrote:
| Tim's productivity score was zero
|
| I also have a Tim in my team but he is a net negative.
|
| Most of the time he would try to pair up. He just make noises
| that implies he is following your work. But you can see that is
| not the case when he tries to make a comment or a suggestion, he
| is clueless. Trying explaining things to him is a waste of time.
|
| Rarely he decides to work on a task himself. No matter how
| trivial the task is, he needs someone to spell out what to do
| step by step. Even then when he sends a code review, you can find
| some surprises. He becomes a net negative because he can take a
| task that should take 2-3 hours top for a regular dev and then
| spends 1-2 week on it while also wasting more than 2-3 of someone
| else's time.
|
| It is always fun to see him grab an easy looking task that is way
| beyond his capabilities and then struggle for weeks and tries to
| weasel himself out of it.
|
| I never saw someone so immune to learning. He is in the team for
| over 2 years yet has a productivity of zero. I don't understand
| why companies keep such people
| [deleted]
| andrewmcwatters wrote:
| Bad management
| xena wrote:
| That person manages to stay because he plays political games
| correctly.
| thereisnojesus wrote:
| I have struggled to find work my entire life, but people like
| this get jobs. I hate life
| astrange wrote:
| You live in a different country probably.
|
| Or, the past isn't the present. It was very difficult to get
| a job in the US in 2008 and now it's easy because it's 2023.
| (slightly harder for some kinds of tech)
| jokethrowaway wrote:
| In Europe firing people is not always straightforward.
|
| There are so many people doing jackshit which make me go
| insane. I guess, good for them and I'm glad I'm not a
| shareholder.
|
| Management handle the most blatant cases in 6 months. There are
| so many people who are not completely clueless at pretending to
| do something and they go undetected for their entire career.
|
| From previous experiences, in a US startup they would be fired
| in 2 weeks.
| jonhohle wrote:
| What value to society does making companies carry dead weight
| provide? It raises the company's costs, lowers productivity
| and morale, all to protect someone unfit for a particular
| role?
|
| The unpredictable layoffs and terminations of US companies
| are their own issue, but companies pay unemployment insurance
| to let people go with some safety net. I can't imagine UI is
| more expensive than keeping an underperforming employee.
| SlightlyLeftPad wrote:
| Unfortunately, I have seen many of these types of people pass
| by management. The worst ones are the ones who do play
| political games correctly because they're the ones who either
| get away with it at the very least or worse, make the talented
| engineers want to leave. Basically, the latter can completely
| destroy good teams.
| ryandrake wrote:
| Yup, I've seen many people like this in engineering. They
| "put all their skill points" into Charisma. Then they go on
| to build long, prosperous careers by bullshitting and
| charming senior management, until they themselves are
| promoted to senior management. It is a reliable, proven
| career progression for the incompetent.
| holoduke wrote:
| They need to fire his manager first and then assess this guys
| capabilities. Maybe he is not guided enough. Maybe he is plain
| stupid. Full responsibility of his manager.
| brundolf wrote:
| > You see, the reason that Tim's productivity score was zero, was
| that he never signed up for any stories. Instead he would spend
| his day pairing with different teammates.
|
| Pretty clickbaity title. This isn't a story about a bad
| programmer, it's a story about a bad metric, and an even worse
| manager who followed it blindly
| avar wrote:
| It's entirely possible that the subject of the article is a
| terrible programmer, if he were to sit down and write or
| maintain something as an individual contributor.
|
| I've worked with people like that, who were pretty bad
| individually, but brilliant when part of the right team.
|
| Writing code and directly enabling the productivity of others
| who are writing code are _different skillsets_.
|
| Obviously there's some overlap, but you're most productive in
| Tim's role in you're complimenting the skillset of the person
| writing the code.
| thatwasunusual wrote:
| > Pretty clickbaity title.
|
| Good. I hope it made you read the article and learn from it.
| voxl wrote:
| It made me immediately go to the comments, find this comment,
| and decide to definitely not read the article.
| davidmurdoch wrote:
| Ignore the others. It's a quick read and a good story, and
| I think most engineers or engineering managers could take
| away something from it, even if just reinforcing that your
| already know.
| adhesive_wombat wrote:
| > worse manager who followed it blindly
|
| And apparently has zero idea of the team's internal working
| patterns.
| nine_zeros wrote:
| > Pretty clickbaity title. This isn't a story about a bad
| programmer, it's a story about a bad metric, and an even worse
| manager who followed it blindly
|
| The clickbait is made so that this document can be shared with
| a future shitty manager. If you send them a link titled "The
| Worst Manager" - I assure you their first reaction will be to
| figure out how to get rid of you.
|
| Managers are the bane of this industry and sadly, engineers
| have to spend an immense amount of time dancing around shit
| managers.
| psunavy03 wrote:
| Bad managers who want to control instead of empower are the
| bane of this industry.
| volkk wrote:
| a manager that truly relies on story points as a direct
| metric of productivity wouldn't be reading blogs like this in
| the first place to make themselves better. the article is
| preaching to the choir of engineers and at a minimum half way
| decent managers nodding and upvoting. the ones that truly
| need to read this and embody it will never see it
| jacoblambda wrote:
| You say that but even in this thread you have tons of people
| claiming he was actually a bad programmer precisely because he
| wasn't also shipping code.
|
| Yes it's a bad metric but so many engineers (not just managers)
| fail to understand that.
| protonbob wrote:
| It seems like the easy solution here would be to give this guy
| partial credit for stories completed.
| hardwaregeek wrote:
| It's like Draymond Green. Individually his statistics suck. He's
| jokingly called Mr Triple Single (a triple double is a major
| achievement, a triple single not so much). But he's such a
| fantastic defensive coordinator and playmaker that his impact
| metrics on the team are massive. Like practically comparable to
| Steph, his more lauded teammate, in some stretches.
|
| A common refrain in basketball is that people forget it's a team
| sport. Doesn't matter how good you are individually if your team
| sucks (see Michael Jordan in 1988 or Lebron most of his career).
| Similarly programming is a team sport. Individual stats are not
| the same as team success.
| rcarr wrote:
| Came here to say something similar.
|
| In this case, Tim from the blog post is a football defender or
| a linebacker if you're an American. Measuring them based on the
| amount of goals they scored or a touchdowns they caught is
| stupid. Instead they're stopping costly errors and providing
| the foundation that allows others to go on and score. You're
| probably not going to win very much if you field 11 strikers or
| 11 wide receivers.
| KSS42 wrote:
| That impact should show up in the plus/minus score?
|
| https://www.espn.com/nba/statistics/rpm
|
| For 2022/23 Green ranks 38. His defensive impact is very high
| but it is offset by his negative offensive impact.
| hardwaregeek wrote:
| Yeah that's what I meant by impact metrics. In the 2015-2017
| playoff runs Green's impact is almost on-par with Curry. But
| for most people who watch basketball, they just look at the
| box score and don't look at advanced stats.
| Given_47 wrote:
| Not even just playoffs either, I think his rank in that
| three year RAPM range was fourth or something staggering,
| after Curry, Lebron, and I think Kawhi? My go-to RAPM site
| that did all the calculations was taken down so can't
| currently cite the numbers
| Given_47 wrote:
| Standard plus minus is pretty crude since it obviously
| doesn't filter out any context, and the ones that _do_ [0]
| tend to be a better reflection of a player's impact in their
| given _role_ , not their overall _quality_ , which is
| something that drives me up a wall with the nba analytics
| crowd.
|
| It's easy to fall victim to the McNamara fallacy (I've
| certainly been guilty of it), before you start understanding
| the innumerable intricacies in the domain. And basketball is
| the only domain I probably know better than 99% of HNers lol.
|
| That being said, GP's general point about Draymond is very
| true. Yes he's one of the best defensive players of all time
| and one of the smartest as well. I think the main point is
| his incredible self awareness (yes get the jokes off). On
| defense it's more subtle, such as not over committing and
| leaving his man etc but on offense is where it's obvious. As
| his own shooting has fallen off a cliff, more and more when
| he's dribbling unguarded he frantically looks around for
| Steph or klay to flow into a dribble hand off to pry them
| free for a shot.
|
| He's talked extensively about the criticism he's faced for
| lack of shot attempts, with his rational being why would he
| ever shoot if he can instead try to get Steph a shot. He's
| also mentioned if Klay hasn't touched the ball in a few
| possessions, he makes sure to get Klay the ball with at least
| a decent look; otherwise the next time Klay gets the ball
| he's shooting it regardless of how bad the shot is. He also
| frequently pushes the break[1] to catch the defense off guard
| and before they can set up.
|
| He _is_ still a negative offensively, but why I appreciate
| draymond so much is for the above reasons and the myriad
| other subtleties he does to maximize his benefit to the team
| and diminish the detrimental elements of his.
|
| And lastly, standard plus minus is still a hell of a lot
| better than box score garbage, I don't mean to crap on it.
|
| [0]: https://squared2020.com/2017/09/18/deep-dive-on-
| regularized-...
|
| [1]: http://stats.inpredictable.com/nba/onoff.php?season=2022
| &tea...
|
| (Steph actually ranked higher than Dray last year in pace
| (seconds per possession) on/off which is why separating
| Draymond himself is so difficult. Their relationship is
| certainly symbiotic, but Draymond is the one that optimizes
| for best interplay of their skills)
| psunavy03 wrote:
| And similarly to sports, there are devs who understand this,
| and devs who actively refuse to do things like pair, mob, or
| collaborate and just want to be handed work pellets so they can
| pick up their headphones and go to la-la land.
| refulgentis wrote:
| I don't buy it and they sound like a very annoying coworker. If
| he's 100% devoted to pair-programming and makes such a massive
| difference, promote him to a lead. Programming is the only
| profession that acts like it's literally impossible to ever
| measure productivity at all without committing some obvious
| wrong. Drives me nuts, coming from a blue collar background. It's
| cargo cult thinking used to justify many negative outcomes.
| ChrisMarshallNY wrote:
| _> Tim wasn't delivering software; Tim was delivering a team that
| was delivering software. The entire team became more effective,
| more productive, more aligned, more idiomatic, more fun, because
| Tim was in the team._
|
| This was the money quote.
|
| Teams do big stuff.
|
| Good teams do good big stuff (very good).
|
| Bad teams do bad big stuff (very, _very_ bad).
|
| It seems that the hyper-competitive nature of today's workplace
| means that engineers consider _their own teammates_ to be
| "competition," and we never really get a good team. This is
| especially true, with the mayfly tenures of most engineers, these
| days.
|
| I'm fairly happy with the fact that I was able to keep a stable
| team of experienced, high-performing, senior C++ image pipeline
| engineers together, for _decades_.
|
| Other managers would bust my chops for being a "Santa Claus"
| manager, because I refused to burn them out, and often
| intervened, when other managers were being too hard on them.
|
| It seemed to work. When my team was finally rolled up, in 2017,
| the engineer with the _least_ tenure had a decade.
| [deleted]
| tnel77 wrote:
| In my experience, the best raises are from getting a new job.
| What were raises like for your engineers that stuck around for
| 10-20 years?
| ChrisMarshallNY wrote:
| Not very good. These were highly skilled engineers that could
| easily have commanded better salaries, elsewhere.
|
| That meant they stayed for other reasons.
|
| I wonder what those reasons could be?
| arrjayh wrote:
| This is brilliant. I'm a mid-level engineer with decent
| C/C++/Rust background. Have yet to find a team like this.
| I'm inspired by your story to keep searching!
| notyourwork wrote:
| Will be five years with my current manager. Team has
| shifted some but money is not the only reason to stay
| somewhere.
| liquidpele wrote:
| ... So you let them enjoy work but fucked them on salary?
| astrange wrote:
| FAANG type compensation doesn't come from "raises", it comes
| from good yearly performance bonuses.
|
| (Although in my experience the raises you get from changing
| between smaller companies are still worse than just staying
| at one FAANG.)
| hermannj314 wrote:
| It is also possible if they fired this guy, and replaced him with
| another developer that only did points that the organization
| would be more productive.
|
| Without quantifying it or comparing to an alternative, this is
| just feel good commentary. If you deliver any value, that does
| not consequently make you a good business decision. You have to
| pit your value against your cost and the companies best
| alternative option.
|
| Also, if a company measures my value in widgets, I have found my
| career does quite well assuming widgets is the right way to
| measure my value. Assuming you know better than everyone in
| management is prideful and not good teamwork.
| nottorp wrote:
| Your last paragraph just said that if you hire people and tell
| them their earnings depend on $METRIC they will optimize said
| metric.
|
| The argument here is which metric, or are metrics good for
| anything? [1]
|
| [1] Except ditch digging and children. It is well known that 9
| people will dig a ditch in 1/9 the time one person will, and 9
| women will make a baby in 1 month instead of 9.
| AugustoCAS wrote:
| The answer to your scenario is `yes` with a high probability
| (taken from my magician's hat), but only in the short term.
|
| People like the one described in the article prepare a pipeline
| of good engineers, who also have experience in the domain and
| in the organization.
|
| So if one cares about fast delivery, get a good number of sr
| engineers who work on their own thing, share little and are not
| encumbered by each other. If a company needs to deliver
| urgently this works, but is an (expensive, short term) option.
| charcircuit wrote:
| Having this person help others 100% of the time likely is not the
| best use of his time.
| hibikir wrote:
| This is also why the most hilarious anti-feature of Jira,
| supposedly a tool to manage agile teams, is how every ticket has
| one person assigned to it. If you do sufficient pairing, the
| person assigned to a ticket is completely useless. Also why
| performance measurement from the outside of a team is always
| going to be dubious.
|
| Every team knows their best performers, and their lowest
| performers. The number of points aren't going to line up with
| performance most of the time, precisely because time helping
| others is never going to show up. And if suddenly getting help
| lowers your review, you are going to ask for less help, not more:
| Trading accuracy in external performance tracking for lowered
| team performance sounds really dubious.
| voytec wrote:
| > supposedly a tool to manage agile teams, is how every ticket
| has one person assigned to it.
|
| It's whoever owns the issue. You can make it an epic and assign
| particular sub-tasks to team members if it's a teamwork.
| desbo wrote:
| And if there's pairing on a sub-task...?
| ChrisLTD wrote:
| Not sure how that solves the pair programming issue. What
| you'd need is a way to split the points for a single task
| among 2+ people without the overhead of duplicating the
| ticket.
| fragmede wrote:
| It's, what, two clicks to duplicate a ticket, and another
| to assign one to other person? Sure a "this person paired"
| button would be easier, but sometimes you just gotta do
| jira chores.
| ChrisLTD wrote:
| Then the status has to be tracked in two places. It's
| certainly not impossible, but as a programmer I'm
| allergic to unnecessary busywork.
| [deleted]
| Aperocky wrote:
| Smells fishy.
|
| Senior engineers in my knowledge and experience are all
| delivering on something relatively high impact while contributing
| massively to the team by occasional/often "pairing".
|
| I've seen rare examples who don't "pair" but just deliver by
| themselves.
|
| I've never seen an example where they don't deliver on anything
| (planning, design, architectures included) but only "pair" as
| their job every day.
| siva7 wrote:
| You do realize that pairing is also delivering in everything
| you mentioned? Just because you hadn't the luck to experience
| this in your career so far doesn't invalidate this
| asveikau wrote:
| More cynically, perhaps they _have_ experienced this but
| labelled the person as a non-performer.
| loeg wrote:
| I agree that it seems like a weird distribution of time for
| someone senior. It's fine and good to mentor juniors or pair
| some of the time but I think that in general pairing is net
| less effective than two people working individually. Seniors
| certainly and usually team leads are expected to deliver _some_
| individual work product. You can definitely help make teammates
| more effective without spending all of your time on their
| shoulder.
|
| Also: the business established a metric it wanted ICs to meet,
| the guy in the story refused to participate in it at all. At
| the very least, he's demonstrating resistance to following the
| expectations of leadership. He might be a good team player at
| the smallest scope, but great engineers can do that and
| simultaneously play along with management/biz interests.
|
| (I'll also agree with the article that measuring "story points"
| or whatever is probably a bad metric, like most measures of
| software productivity.)
| twic wrote:
| The team being described here was one where all work was done
| paired. Senior engineers were never delivering by themselves.
| It sounds like you have experience of teams which are not like
| that, which makes comparisons ineffective.
|
| The real reason Tim showed up as having zero productivity was
| because he always let his pair put their name on the ticket,
| and so get the credit for it. This is really a story about how
| things go wrong when a ticket tracker designed for solo work is
| used by a team which pairs.
| mi_lk wrote:
| This^^ The article depicts it like it's an either-or when in
| real world capable engineers can consistently do both
| johnnyanmac wrote:
| Too lazy to track down the exact company, but the author does
| link to Tim's LinkedIn. He has many titles as "Agile coach" and
| his lede is
|
| >Enabling technology teams to operate at their full potential
|
| Sounds like he is a very particular type of developer focused
| precisely on enabling teams in this manner.
|
| -----
|
| also, I can just post the obvious here but: he may be doing
| work but not tracking it. I've never been perfect at creating
| stories for every task I get, especially retroactive ones that
| pop up in the middle of the week.
| pizzafeelsright wrote:
| Hi. I barely deliver anything of value from my perspective.
|
| I asked to swap teams. Two levels up both said "no way you
| can't be replaced. "
|
| I have a reputation and didn't know.
| oytis wrote:
| In orthodox agile environment planning, design and architecture
| might not result in any "story points".
|
| Also these activities might not always result in a lot or any
| artifacts. E.g. being in a meeting, making sense of messy
| stream of requirements and using institutional knowledge to
| help set the right priorities on a project or prevent team from
| spending months on a dead end idea might not leave any paper
| trail at all.
| loeg wrote:
| Seniors are usually expected to do these things and also
| produce tangible artifacts. At the principle / architect
| level maybe you aren't producing code artifacts but you
| should easily be demonstrating 7+ figure impacts to the
| business from your efforts.
| suzzer99 wrote:
| It's a great deal for Tim. He never has to work overtime to
| deliver something, and never has to fix bugs on stuff he built.
|
| That said I believe the author that Tim was a huge net
| positive.
| MarioPython wrote:
| I feel that the article is talking about the same thing as what
| is described in this talk
| https://www.youtube.com/watch?v=YyXRYgjQXX0 - "disagreeable
| givers", which the host of the talk argues are one of the most
| valueable employees to have in a company while also being the
| least understood and often let go.
|
| I am a disagreeable giver myself and I have experienced a lot of
| backlash by the higher ups inside companies for being one, while
| also being praised a lot by my colleagues that were working
| alongside me.
|
| A previous discussions about it:
|
| "The best employees are not the agreeable ones" -
| https://news.ycombinator.com/item?id=17386640
| xena wrote:
| I'm this kind of person most of the time and it really sucks come
| review time. I'm also a mentor type and that is also very hard to
| account for in most systems. It means I do an essential role that
| is seldom rewarded because there's no number associated with my
| meddling.
| pydry wrote:
| I sometimes wonder if developers should do an end run around all
| this bullshit and come up with and start measuring management
| productivity metrics.
|
| I dont see a downside to doing this.
| ruined wrote:
| it's called a labor union
| commonlisp94 wrote:
| unions don't measure productivity. They group people based on
| credentials + experience, and treat everyone as
| interchangeable within those buckets.
| rexpop wrote:
| That's one possible union architecture, sure, but you're
| missing the forest for the trees. A union offers job
| security to reduce the risk of "managing up."
| commonlisp94 wrote:
| > one possible union architecture
|
| It's the one used by all the major ones: airlines, auto
| manufacturers, and teachers. What institution do you know
| of that has a greater emphasis on measuring performance?
| pydry wrote:
| You're thinking of management.
|
| I'm sure most unions would _love_ performance based pay
| where union reps decide what constitutes good performance.
| For some mysterious reason management is as keen on unions
| exercising their judgement as unions are on management
| deciding.
|
| Where unions agree policies that treat members as
| interchangeable (e.g. age based pay) it is usually as a
| result of a compromise brooked with management who would
| _love_ to have the latitude to give pay raises to scabs,
| kiss asses and spies.
| criddell wrote:
| That's not generally how it works in professional sports
| with player unions. Nor does it work that way in the film
| and television industries where there are unions
| representing writers, directors, actors, etc...
|
| The shape of the union is whatever the membership wants it
| to have.
| commonlisp94 wrote:
| Both of those examples have weaker unions that play less
| of a role. Also the poster above suggested that the union
| as opposed to the management could measure performance.
| That doesn't happen in sports or TV.
| rgblambda wrote:
| Managers don't stay in the same role long enough to have their
| productivity measured.
| Cerium wrote:
| Really? From my manager and up at least 4 levels has been
| unchanged for at least 8 years. Titles changed some, but the
| same people are in the same effective roles.
| throwaway92837 wrote:
| They measured by the perceived output of the team. Give them
| credit for being self-serving, at a minimum.
| omoikane wrote:
| Management also have their own metrics, measured by even higher
| management further up the chain. Even if there is a manager or
| director that I really liked and would like to keep, they have
| to answer to the metrics of their VPs and SVPs above. It's
| metrics all the way up.
|
| People at the top of the hierarchy probably do care about
| people at the bottom, but it's difficult to care about a large
| number of people as individuals, so they resort to metrics that
| probably models what's going on. Unfortunately, the metrics
| don't always work.
|
| Instead of measuring and gaming numerical metrics, enforcing a
| particular culture might be a better way to go:
|
| https://apenwarr.ca/log/20190926
| h2odragon wrote:
| How would coming up with good metrics for "management" be any
| easier than coming up with good metrics for "programming"?
|
| At least programming has some verifiable realities that can be
| witnessed objectively by multiple observers. Not that such
| things are often used on "metrics", but they _could_ be.
|
| The quality of someone's management is hard to assess from
| outside, much less objectively verify. Has your manager
| increased or decreased your productivity today? Was it
| necessary that they do so for a larger goal you're not
| considering? Were they just power tripping?
| pydry wrote:
| That's exactly my point. Managers who protested the use of
| metrics on them would inadvertently undermine the argument
| for using them on developers.
|
| Measuring is an aggressive act intended to invoke control
| that has a veneer of innocence.
|
| That said I'm now wondering if there wouldn't be some metrics
| which might prove useful to workers either way.
| TheDong wrote:
| "Hey, boss who can fire me, I just thought you should know that
| we on the team have started keeping metrics. I want you to know
| that your 'times you made the only girl on the team
| uncomfortable with a sexist joke' metric is unusually high this
| month, and your 'unblocked the team by speeding up an external
| request' metric is 0 for this month, down from 3 times last
| month"
|
| Let me know if you find any downsides.
|
| Anyway, management will of course argue that developers under
| them are incapable of seeing everything management does. After
| all, management's job is to shield developers from other
| managers, so if the developers think all the managers at the
| company are worthless, that's actually a sign of how well
| management did their job of shielding each other's teams from
| each other.
| tjpnz wrote:
| The logical conclusion to that argument is that we should do
| away with the lot of them.
| bee_rider wrote:
| We all feel like management contributes nothing, right? But
| they seem to always be around successful companies. I
| dunno, correlation isn't causation, but I think there must
| be something there.
| TheDong wrote:
| Weirdly enough, many unsuccessful companies I know of had
| management too. Correlation isn't causation, but maybe
| there's something there.
|
| There are also plenty of successful companies and
| projects without management too. Basically every
| 1-to-5ish-man consulting shop has zero managers and some
| of those do wildly well. Some of the best indie games,
| produced by teams of 3 or 4, had zero dedicated
| management. Most open source projects have effectively 0
| management.
|
| Valve, famously, kept a flat organizational structure for
| a long time, and certainly was somewhat successful.
| chaxor wrote:
| AI is actually now shaping up to replace these jobs much
| more simply than blue collar work.
|
| So, yes absolutely, administrative work now can finally be
| replaced, and we can free up all the tormented souls in
| these managerial positions to do something more meaningful
| with their lives.
| pydry wrote:
| In many workplaces middle management has already been
| automated. Algorithms manage Uber drivers. Algorithms
| manage Amazon warehouse employees.
|
| These companies are even more stratified than before with
| the lumpenproletariat doing human-mechanized tasks while
| executives program their lives using software we write in
| exchange for the unbridled luxuries like the chance to own
| a roof over our head one day.
|
| It's not exactly the future I wanted.
| pydry wrote:
| >Anyway, management will of course argue that developers
| under them are incapable of seeing everything management
| does.
|
| What a coincidence! Thats one of the first thoughts that
| crept into my head when code metrics started being used on
| me.
|
| This "voyage of discovery" you've alluded to is exactly what
| I meant by no downsides.
|
| If managers feels threatened by being measured by their
| employees after their _employees_ start measuring _them_ ,
| well, that's also an interesting reflection is it not?
| [deleted]
| 38 wrote:
| > He would not crowd them or railroad them, but let them take the
| time to learn whilst carefully crafting moments of insight and
| learning, often as Socratic questions, what ifs, how elses.
|
| I do not like people who do this. just tell me the answer. this
| is such a gigantic waste of everyone's time. you figured
| something out months/years ago, great for you. give it to me NOW,
| so I can get on with my day. if we BOTH run into something
| unknown, we can tackle it together. but dont force me to go
| through the same painful learning process you went through. YOU
| suffered, because at the time no one knew how to do whatever it
| was. now that someone knows (you), your job should be to spread
| that knowledge across the business as quickly as possible, not
| hoard it to yourself until someone is deemed "worthy" of knowing
| it.
| mynameisvlad wrote:
| Quite simply, no.
|
| You're not going to learn from being handed an answer on a
| silver platter.
|
| You'll implement it, get on with your day, and not at all think
| about why the answer is what it is.
| 38 wrote:
| > You'll implement it, get on with your day, and not at all
| think about why the answer is what it is.
|
| this is an incorrect assumption. some people (like me) have
| an analytical mind. if I am given an answer, I will usually
| reverse it back to the question, so that I understand how it
| came about. or I will ask follow up questions until I have
| that understanding.
|
| all this method is doing is forcing multiple people to go
| through the discovery process, when all that should be needed
| is for one person to do so. its a waste of business
| resources. person A can share with person B, then person B
| can go on to make their own discoveries. we dont need to
| force every employee to discover EVERYTHING on their own.
| thats just a huge waste of time. it would be like forcing
| everyone to discover Pythagorean theorem on their own,
| instead of giving them that tool and letting them use it to
| create other stuff.
| mynameisvlad wrote:
| [flagged]
| 38 wrote:
| [flagged]
| qdog wrote:
| I've worked with several types of people. For me, the best
| mentors were the ones who would answer questions I had with
| the full answer, often with details. Then they got on with
| what they were doing while I went back to my desk and tried
| to understand/retain some of what they told me.
|
| I'd personally find someone shadowing me and asking questions
| super annoying.
|
| I don't think this would work with all teams, the takeaway I
| got from the article is about artificial metrics.
| shigawire wrote:
| You are thinking of something different than this is
| describing.
|
| Your situation is a waste of time where no one grows. The
| article is describing growing skills which is a net
| productivity benefit.
| jader201 wrote:
| The moral of this article seems to just point out what we all
| already know, and what has already been discussed on HN countless
| times: don't measure performance solely by things that should
| never be measured in a vacuum (like story points, lines of code,
| etc.).
|
| Not sure why this is the #1 article on HN right now, other than
| maybe the (what I would consider) click-baity headline. But I
| wish there was an acceptable way for HN to use more fitting
| titles for articles (especially since most articles always use a
| click-baity headline). E.g. would it be at the top if the title
| was "Don't measure performance by story points"?
|
| I guess some interesting anecdotes have resulted in the post, but
| the message of the article itself doesn't seem to share anything
| particularly new or enlightening.
| johnnyanmac wrote:
| >E.g. would it be at the top if the title was "Don't measure
| performance by story points"?
|
| TBH it's a non-zero chance here on HN. "Don't measure by story
| points" is still preaching to the choir to a community like
| this after all.
|
| >I guess some interesting anecdotes have resulted in the post,
| but the message of the article itself doesn't seem to share
| anything particularly new or enlightening.
|
| 1. Lucky 10k. Especially if it involves some managers who may
| in fact be doing this stuff as we speak
|
| 2. Generally, I come to the comments because some anecdotes are
| more interesting than the article.
| the_af wrote:
| Agreed, but also: enough people are disagreeing with the
| moral of the story that I think we can no longer assume
| anything in the article is preaching to the choir.
| tomtheelder wrote:
| I actually don't think that's what the author is arguing. They
| are arguing that certain metrics that are valuable to measure
| at a team level become less useful or even misleading if you
| zoom in too far to an individual level. Story points being a
| good example. Useful when talking about a team, not useful when
| talking about individuals. That's a more nuanced point, and one
| that I definitely don't think is obvious to everyone.
| the_af wrote:
| > _I guess some interesting anecdotes have resulted in the
| post, but the message of the article itself doesn 't seem to
| share anything particularly new or enlightening._
|
| Enough commenters here on HN are disagreeing with the article's
| conclusion that I think we can infer this is not a point
| everyone here agrees on, and the article was needed after
| all...
| _gabe_ wrote:
| Now when you Google "Tim Mackinnon programmer", the 5th or 6th
| result for me is a link titled "The Worst Programmer" and the
| little descriptive blurb below that says "His name is Tim
| Mackinnon...". I know the author was click baiting and flipping
| the story on its head, but I would be a bit annoyed if Googling
| my name + programmer surfaced something like that.
| twic wrote:
| Tim thinks it's awesome:
| https://twitter.com/iterex/status/1697927494479777844
| owenmarshall wrote:
| Annoyed? I'd _love_ it: it would be an incredible door opener
| anywhere you went.
| tchaffee wrote:
| Get your resume. HR looks up your name. Throws out the
| resume. It could be fun if you can get an interview. It might
| hurt you though.
| ted_bunny wrote:
| If HR is going to throw it out because of the title alone,
| they're going to be obnoxious to deal with even in the
| scale of HR departments.
| tchaffee wrote:
| Or they are just busy. A pile of a hundred resumes and
| two open positions usually means you disqualify quickly.
|
| Sometimes we need to pay rent and deal with obnoxious HR
| departments.
| twic wrote:
| This is just not something that actually happens.
| tchaffee wrote:
| Can you reassure me then with the data that backs up your
| claim? Because in my very long career I've seen a lot of
| people use heuristics when deciding who to follow up
| with.
|
| "According to a 2018 CareerBuilder survey, 70% of
| employers check out applicants' profiles as part of their
| screening process, and 54% have rejected applicants
| because of what they found."
| twic wrote:
| _HR_ are not going to reject an incredibly experienced
| senior guy with a CV as long as your arm because of the
| _title_ of a blog post. Your quote doesn 't even suggest
| they would, and I'm not going to cite any evidence
| because it's honestly just a patently absurd proposition.
| tchaffee wrote:
| HR will definitely reject someone because of the title of
| a blog post. When you have a pile of a hundred CVs and
| two openings, you disqualify quickly.
|
| I'm basing this on real world experience.
| softfalcon wrote:
| Yeah, this is a great opener to break the ice with during an
| interview.
|
| You can even add some prestidigitation by having them take 30
| seconds to Google it and your name comes up. Play it off as a
| joke and now everyone has a little smirk/chuckle over it.
|
| Now they know you have a good personality and can tell a
| funny joke about yourself. Goes a long way to putting you in
| that "I can work with this person" category.
|
| Also, if they can't appreciate the joke, that's an easy red
| flag for you that you probably don't ever want to work for
| that team.
| _gabe_ wrote:
| You both make good points, on second thought it's all about
| how you spin it :)
| gardenhedge wrote:
| My thoughts too. Sucks for him.
| jamestimmins wrote:
| Reminds me of an anecdote about Bell Labs. Someone calculated who
| the most productive employees were (based on things like patents
| received), and found that many of them would eat lunch with the
| same person. That person wasn't individually very productive, but
| he would always ask thoughtful, compelling questions that in turn
| made his coworkers measurably more productive.
| psunavy03 wrote:
| For all a lot of people dump on Scrum Masters and Agile Coaches
| . . . this is part of who the good ones are supposed to be.
| agumonkey wrote:
| That kind of people was somehow mentioned in Peopleware. A
| group of people is a subtle structure, and good team spirit,
| good questions can improve things "invisibly".
| closeparen wrote:
| Do people honestly think this kind of thing replicates with
| formally scheduled Zoom 1:1s? I don't.
| lizard wrote:
| I don't know about you, but I don't tend to have breakfast
| and lunch over Zoom.
|
| While I did go out to lunch with coworkers more often while
| working in the office it was almost exclusively with direct
| teammates, and other groups I occasionally saw where also on
| the same team.
|
| Now that I'm fully remote, I will typically do a few "hacking
| sessions" over Zoom every week. Its much easier and more
| comfortable than standing over their shoulder in tiny cubes
| we used to have.
|
| That said, especially now that i am fully remote, I've been
| trying and mostly failing to get developers especially across
| teams to talk and collaborate more. But its not too
| suprising: I was recently in a call and I was introduced to
| another developer who I replied, "Yeah, I know you. I was in
| the cube next to you for 2 years and on your team for 6
| months."
|
| Remote creates some new challenges, but its a culture thing,
| not a technology thing.
| andai wrote:
| That is a catalyst!
| ldjkfkdsjnv wrote:
| This type of person needs to start a company, they never get
| paid a fair wage otherwise
| jongjong wrote:
| 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.
| sshine wrote:
| > _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.
| varispeed wrote:
| 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...
| 3np wrote:
| 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 wrote:
| > 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....
| thefaux wrote:
| [flagged]
| closeparen wrote:
| 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.
| Gibbon1 wrote:
| 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.
| arrjayh wrote:
| I'm working through this exact situation right now, I really
| appreciate this insight!
| andai wrote:
| "Negative 2000 Lines of Code"
|
| https://www.folklore.org/StoryView.py?story=Negative_2000_Li.
| ..
| ZeroClickOk wrote:
| nice, thanks for the link
| yourapostasy wrote:
| 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.
| yodsanklai wrote:
| > 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.
| ChrisMarshallNY wrote:
| _> 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 wrote:
| _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 wrote:
| 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_
| 88913527 wrote:
| 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.
| willcipriano wrote:
| Idea people really overestimate their contributions.
| closewith wrote:
| Maybe, or maybe human endeavour is more complex than
| individual efforts.
| 88913527 wrote:
| 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 wrote:
| 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".
| mynameisvlad wrote:
| 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 wrote:
| 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.
| manicennui wrote:
| Quickly shipping a thousand lines of buggy code that you
| then spend the next month fixing (by writing thousands
| more lines of code) is a good way to fool everyone into
| thinking you are productive.
| mynameisvlad wrote:
| > 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 wrote:
| 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.
| mynameisvlad wrote:
| Well that software you sell them is fundamentally better
| and more maintanble because a person like Bob is around
| to give directions.
|
| > The people that can do this without needing Bobs around
| are the people that will be rewarded.
|
| Unicorns are few and far between, but sure, you do you.
| alwaysbeconsing wrote:
| The part that's often missed is the _future_ outcome,
| when someone returns to this code to fix a bug or add a
| new feature. I believe it 's incumbent upon those of us
| with some experience to ensure maintainability is part of
| the considerations.
| EVa5I7bHFq9mnYK wrote:
| 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.
| mynameisvlad wrote:
| I can whip out 100 lines of bullshit in a few seconds. I
| can just paste in whatever Copilot gives me and as long
| as it builds call it a day.
|
| It will take me far longer to come up with the correct
| 100 lines that is both maintainable and can be worked on
| by others down the line.
|
| I can pad my lines of code in seconds if I wanted to
| before pushing the changes. That padding provides no
| business value and might even introduce bugs.
|
| And how do you handle refactoring? If I come in and
| refactor everyone else's shitty padding by combining
| helpers and optimizing code, I'll have negative lines of
| code. Am I an unproductive worker?
|
| Sure, most code is not some complex algorithm but lines
| of code is a stupid metric that is not representative of
| the work done and can be gamed by anyone knowing what
| they're doing.
| manicennui wrote:
| Nonsense. Most people write pretty useless unit tests.
| Gotta get that test "coverage" high though!
| astrange wrote:
| Unit tests are useful if you write them alongside new
| code, but then become not useful since if you never
| change the code, they never break, and so are wasteful.
|
| It's better to have tests more sensitive to failure, like
| integration or regression tests.
| naasking wrote:
| 100 lines of integration tests are worth a lot more than
| 100 lines of unit tests, so it's not a simple matter of
| counting LoC.
|
| Also, solving the same problem with less code is a lot
| more valuable than many think. Not only are there fewer
| code paths to test, the system probably has fewer
| unnecessary constraints and edge cases to consider. How
| do you account for negative LoC?
| vGPU wrote:
| 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.
| [deleted]
| mike_ivanov wrote:
| Given that DRY is out of fashion, 2000 lines of code per week
| looks pretty modest.
| closewith wrote:
| In a remote world, can that person exist?
| scruple wrote:
| 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 wrote:
| 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!
| Longlius wrote:
| 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.
| mellavora wrote:
| 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.
| dharmab wrote:
| 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 wrote:
| 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]
| Aperocky wrote:
| > 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 wrote:
| > 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.
| l33t7332273 wrote:
| >Managers always love a developer who can consistently write
| 5000+ lines per code per week
|
| What managers care about this at all?
| hinkley wrote:
| 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.
| DiabloD3 wrote:
| The ones that work at companies that promote incompetence.
|
| You know, most companies.
| goalieca wrote:
| 5000 lines is silly, but all managers love that coder who
| closes tickets faster than anyone.
| datavirtue wrote:
| 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.
| AStellersSeaCow wrote:
| 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.
| mlhpdx wrote:
| 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.
| teirce wrote:
| This was my experience as well. It's completely up to
| management to recognize these kinds of engineers
| regardless of role name or leveling.
| whstl wrote:
| 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.
| onion2k wrote:
| 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.
| 3np wrote:
| [delayed]
| whstl wrote:
| I never said one _should_ be fighting. My point is that
| POs /PMs should know the domain at least as much about
| the domain as TLs do.
|
| The problem is not needing discovery work or
| understanding the problem. The problem is when the Tech
| Lead is the one who's providing all the data for that
| discovery, or helping them understand the problem better,
| because of lack of expertise of PO/PM. Or having to push
| back because of incomplete knowledge.
|
| If there is lack of information or incorrect information,
| POs should be able to get that information themselves. If
| a TL is the sole source of that info, then it becomes an
| issue.
|
| IME this is very common. And it takes too much time of a
| Tech Lead's day.
| TheRealPomax wrote:
| It also doesn't get people promoted to that position just
| because that's what they're doing. Because politics.
| AdrianB1 wrote:
| 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?
| Arainach wrote:
| 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 wrote:
| 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.
| [deleted]
| 8n4vidtmkvmk wrote:
| 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.
| cratermoon wrote:
| > 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.
| ..
| beebmam wrote:
| 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.
| jacobsenscott wrote:
| 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?
| Sivart13 wrote:
| 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"
| b800h wrote:
| I prescribe a viewing of "Carry On at your Convenience" to
| cure that sentiment:
|
| https://en.m.wikipedia.org/wiki/Carry_On_at_Your_Convenienc
| e
| Pamar wrote:
| (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 wrote:
| A union would provide the sort of employment protections
| much of Europe alreadys enjoys.
| no_wizard wrote:
| 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
| astrange wrote:
| That is because of historical circumstances, but it
| continues to this day because it's encoded in the law; we
| don't have codetermination or sectoral bargaining.
| jokethrowaway wrote:
| Unions always end up doing more evil than good costing
| money to everybody involved. It's political bullshit.
|
| It's been a net negative to workers for ages. All my blue
| collar friends hate them.
|
| Besides, developers have power in the market, they can
| negotiate quite a bit without paying money to some
| political useless figures.
| lostlogin wrote:
| 71% of Americans support unions - though you may not live
| there.
|
| https://news.gallup.com/poll/398303/approval-labor-
| unions-hi...
| zlg_codes wrote:
| 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.
| gemstones wrote:
| It's funny you mention it as a charisma roll, because
| it's not really a roll, is it? High charisma is high when
| it's with your interviewer, when it's with your peers,
| when it's with your business stakeholders. High charisma
| is useful in getting a job, in arguing for addressing
| tech debt, in pushing back on unreasonable timelines. Why
| would you not consider charisma in a job interview?
| astrange wrote:
| Why should you have to spend your time on being
| charismatic with your own management if your job duties
| require doing it with everyone but them?
| SeanLuke wrote:
| 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.
| droopyEyelids wrote:
| 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.
| benreesman wrote:
| 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.
| tempodox wrote:
| 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 wrote:
| 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]
| nine_zeros wrote:
| > 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 wrote:
| 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
| jonathanlydall wrote:
| This sounds like possible malicious compliance.
|
| Regardless, it's an important life skill to learn that
| it's generally not enough to ask people to do what you
| want, you need them to actually "buy in" to what you
| want, and then they'll actually care enough to at least
| try make it happen.
|
| This applies to managers and their employees, or also
| when trying to get on the ground employees to adopt a
| product initially sold to their manager/execs.
| nine_zeros wrote:
| "Buy in" is what you use for people acting in good faith.
| But managers aren't acting in good faith. They just want
| it done so that they look good to their own bosses. They
| don't actually care about the product/service. Their ask
| to "go faster" is a bad faith argument where there is no
| real need to go faster except for the manager to look
| good.
|
| I don't feel the need to get "buy in" for bad faith
| managers.
| cjaybo wrote:
| > but managers aren't acting in good faith
|
| An overly broad statement which, my experience, is not
| true. Managers come in many shapes.
|
| Although, I suppose ironically, if you act in bad faith
| as a response to this perception, then I think that
| perception will quickly become true.
| gremlinunderway wrote:
| Why is asking for requests to be in writing an "act of
| bad faith"? Literally cna't see a single outcome that
| would be an act of bad faith here.
|
| If the project fails, and the manager tries to blame it
| on you, they are de facto acting out of bad faith given
| the request. Documenting it just identifies this. If the
| project succeeds or fails, but no one blames you, then
| the documented request is just there for the record.
| ebiester wrote:
| 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.
| tilne wrote:
| But you can't have the technical foundation later because
| you've already built on something else.
| adolph wrote:
| > 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.
| hnfong wrote:
| 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.
| kagevf wrote:
| > Besides the infamous Javascript framework churn
|
| reactjs came out in 2013, so it meets the 10y metric, but
| it has some internal churn, such as classes, hooks, etc
| adolph wrote:
| "If you choose the right frameworks" is a big if. Even
| within a framework, there is versioning and dependency
| management to account for. Consider the log4j
| vulnerability. The cost and risk of patching something
| untouched for 10 years is higher than something touched
| more recently.
|
| In part, this is due to the risks inherent to change have
| been spread out over 10 years instead of backloaded to
| the end.
|
| Practicing mitigating risks by proactively taking them
| has value of its own. The parable of ergodic cakes shows
| this.[0] What % of cakes will fail if 10 people each bake
| one, versus one person baking 10 over time?
|
| https://luca-dellanna.com/what-is-ergodicity/
| bitwize wrote:
| 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.
| adolph wrote:
| That is a great example. By not taking account of risk on
| the front end by embracing change, the system gets
| progressively more expensive to maintain (extended
| support contracts) and the risk of eventual inevitable
| change grows higher. Further, the system becomes
| progressively less valuable compared with newer systems.
| dharmab wrote:
| 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 wrote:
| 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.
| [deleted]
| dharmab wrote:
| 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 wrote:
| I remember times at a few of my jobs, just absolutely
| cheering for someone's PR that was filled with red. Good
| times.
| esafak wrote:
| At my last company we had an architect whose only direct
| coding contributions were deletions, because nobody gets
| credited for cleaning up code.
| jongjong wrote:
| 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.
| hnfong wrote:
| 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.
| throwaway92837 wrote:
| 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.
| dharmab wrote:
| 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.
| cratermoon wrote:
| > "This change is hard for me to read and understand"
|
| Believe it or not, I consulted at one place where the
| manager decided I was the problem because I was
| consistently assessing problem code and team processes in
| similar ways. She asserted that "everyone else
| understood", even when they plainly didn't understand but
| where just going through the motions.
|
| Said manager had a number of other issues as well. Worst
| gig I can recall having in the last couple of decades.
| ido wrote:
| I would start being less diplomatic once I get the hunch
| polite phrasing isn't getting through - "this code is
| badly structured, brittle and will make debugging
| harder". As programmers being tactless is expected so
| might as well use it to your benefit.
| cratermoon wrote:
| In this case, I could have, but I felt my time was better
| spent thinking about why things were complex and hard to
| understand and made notes on that, mostly for my future
| self. Whenever I found the opportunity, I would include
| some of the reasoning and explanation, in written form,
| in my feedback. I didn't get much out of that gig, but I
| did end up with several thousand words of ideas and
| observations. I wouldn't be surprised if some future
| programmer on that project ran across something I left
| behind and found it useful, or at least comforting.
|
| Edit to add: in 1:1s with the manager I was more direct.
| About the best I can say about that is "at least I
| tried".
| jongjong wrote:
| I can relate though I wish I could get into a position
| that I could say such things and not get fired. In some
| circles "This change is hard to me to read and
| understand" would be interpreted as "I'm an aging
| dinosaur who doesn't understand this new tech; you
| youngsters are too clever for me." (though I realize how
| completely wrong it is).
|
| I'm 33 but I feel like I already have to make an effort
| to avoid the dinosaur label. I disagree with a lot of
| modern tech trends but I simply cannot express my view
| about them even though I could explain the problems very
| clearly and logically and can provide far better and
| simpler alternatives. Unfortunately, hype does not yield
| to reasoning... And sometimes, you're too far into the
| tech debt and it doesn't make financial sense to rewrite.
| padjo wrote:
| I'm 10 years older, my experience has been that getting
| to ask stupid questions is one of the joys of
| age/seniority/security. Very often everyone else in the
| room has the same stupid question but you get to look
| like a stone cold genius because you were willing to risk
| looking silly.
| marcosdumay wrote:
| Don't mislead yourself, that benefit comes exclusively
| from security. Age and seniority only contribution is
| some weak correlation to security.
| jongjong wrote:
| I guess maybe in 10 years I'll be working with 30 year
| olds who understand and value of that approach as I do
| today.
|
| My current reality is that I'm a 33 year old working with
| 20 year olds who think they're geniuses who are going to
| take over the world in 5 years; from that viewpoint, I'm
| essentially a failed engineer because I didn't build a
| Facebook, Uber or AirBnB even though I had 10 years to do
| it.
| hgsgm wrote:
| From seeing your posts, I think you have a psychologica
| lock that under mines your self-confidence.
| reneherse wrote:
| I'm curious what type of company has these team
| demographics. Startup, agency, SMB, bigcorp, academia,
| or?
| [deleted]
| [deleted]
| erik_seaberg wrote:
| My secret weapon (rarely needed) is "I got this
| eventually, but someone may have trouble quickly figuring
| it out during a 3 AM outage."
| [deleted]
| pc86 wrote:
| 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.
| jongjong wrote:
| I didn't have enough leverage in that company to say such
| things and the project had already been running for a
| couple of years when I joined (not greenfield).
|
| The last greenfield project which I managed from scratch,
| we didn't have this problem because all developers shared
| the same mental model of what we were building before we
| wrote any code. We had a lot of discussions beforehand to
| get to this shared understanding. There was literally not
| a single PR which surprised me throughout the entire
| project and I'm sure none of my PRs were a surprise to
| any of my team mates either. There was plenty of
| disagreement throughout but it was always fully resolved
| through discussion before we started coding each major
| feature.
| nerdponx wrote:
| In my experience it pops up when company politics get
| involved, or somebody gets attached to their idea about
| how certain things should or shouldn't be done. In that
| case often the safest thing you can do for your own
| reputation and appearance is to leave some very gentle
| notes that a certain thing maybe could have been done
| differently, but approve it anyway on the grounds that it
| works for now. That way you're not seen as an
| obstructionist, but if things do go wrong you at least
| have a written record so you can say "I told you so".
| hn72774 wrote:
| "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 .
| ted_bunny wrote:
| The imperative can rankle too. I like passive voice or
| "let's" statements.
| marcosdumay wrote:
| 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.
| tengwar2 wrote:
| 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);
| ResearchCode wrote:
| 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.
| krmboya wrote:
| 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.
| namaria wrote:
| 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 wrote:
| 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-...
| marcosdumay wrote:
| > 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).
| Erikun wrote:
| It might be from the great book The Idea Factory by Jon Gertner
| (p 135). 'In the midst of Shannon's career,
| some lawyers in the patent department at Bell Labs decided to
| study whether there was an organizing principle that could
| explain why certain individuals at the Labs were more
| productive than others. They discerned only one common thread:
| Workers with the most patents often shared lunch or breakfast
| with a Bell Labs electrical engineer named Harry Nyquist. It
| wasn't the case that Nyquist gave them specific ideas. Rather,
| as one scientist recalled, "he drew people out, got them
| thinking." More than anything, Nyquist asked good questions.'
| avanai wrote:
| The most impressive thing about this story is that _they
| figured out the answer_. They did the research, and nailed
| down that it was Nyquist who was was the productivity
| booster. It's the exact opposite of the OP's story, where
| management tried to fire the Nyquist-equivalent.
| Strilanc wrote:
| Honestly, I'm kind of skeptical of the answer. I'm not
| saying that talking with Nyquist wouldn't be useful,
| probably it was, but what's stopping a dozen other things
| at least that useful from being part of the answer?
| Tarq0n wrote:
| They found an answer that felt right to them. The
| reseachers weren't blinded to the context they were working
| in, and their hypothesis is essentially unfalsifiable so I
| would take it with a grain of salt.
| liquidpele wrote:
| All they figured out was that the smart people hung out
| together.
| sound1 wrote:
| IMHO this is the right answer :)
| jamestimmins wrote:
| Yeah that's the one! Thanks for finding the reference.
| agumonkey wrote:
| You also need a fertile soil. In many many places, curiosity,
| exploration is passively frowned upon.
| tfgg wrote:
| Harry Nyquist isn't exactly an unknown engineer who doesn't
| have his own achievements, though - not sure why people are
| saying he would be fired in a modern company!
| smallerfish wrote:
| DORA seems ok as a big company framework, where different teams
| of similar sizes can be roughly compared using the scores, and
| the CIO or CFO can have some satisfaction about being able to
| avoid spending money on non-producers, without engineers feeling
| like they're being individually spied upon. Without this
| accountability, engineering managers may let non-performers coast
| for a variety of reasons.
|
| For small companies, engineering managers & direngs should be
| aware enough through working with the team members individually &
| through PR review who is performing and who isn't, and not need
| to deploy metrics.
| peter_retief wrote:
| I often wondered why s/w development is always a rush at the
| expense of quality.
|
| Well I do know why just don't agree with the principle of seeing
| how much the company can get out of a developer in x hours.
| JKCalhoun wrote:
| Having been in the industry since the around 1990, I can tell
| you that in the first half of my career we had no code reviews,
| no scrum, no story points, no unit tests.
|
| How on earth, you might wonder, did we ship software that
| worked?
|
| I then saw all these things come down the pike one after
| another during the last half of my career.
|
| Clearly to me every one of these benefit management who found
| themselves apparently unable to function without numbers,
| graphs, data of some sort. It has been a very obvious (to me)
| power struggle: management trying to get the upper hand and
| wrest any and all power (and autonomy, and decision making)
| from engineering.
|
| It has been sad to me to have heard some new engineers come on
| board who like these things. It's just as well I retired when I
| did: it's probably me that is the odd man out now.
| notpachet wrote:
| Scrum and story points I agree with, but unit tests? You'll
| have to pry those out of my cold, dead hands!
| JKCalhoun wrote:
| That's fine. Myself I have little use for them, I prefer
| functional testing. (Also, before unit tests we leaned on
| parameter checking in the live code -- a kind of always-on
| unit test I guess).
|
| Management though use the "percent coverage by unit tests"
| as some sort of safe/buggy software metric.
|
| Management at one team I worked on was pushing for minimal
| 95% coverage with unit tests. I thought it was odd that
| they were so singularly focused on this issue. The
| impression I had was a that they felt that if you have full
| code coverage with unit tests, and the test pass -- you can
| lay off the QA team because you are assured that you are
| shipping perfect software.
| throwaway92837 wrote:
| I would be interested to know your career history in more
| depth.
|
| To my understanding even IBM in the 70s had stupid ways of
| measuring productivity (KLOCs?).
| JKCalhoun wrote:
| I wrote games until 1995, then started at Apple. I worked
| at Apple until 2021 when I retired.
|
| Apple very much was engineer-driven when I began. That
| changed when Steve Jobs returned.
| whstl wrote:
| I'm pretty sure there were companies doing stupid things in
| the old days but in my experience, back then managers were
| supposed to know what developers were doing, and if they
| were delivering value or not.
|
| They did all that by walking around, chatting with
| everyone, helping devs, assigning tasks depending on the
| expertise level, sometimes doing boring work (like manual
| testing) to help devs, etc.
|
| Of course, if a manager that has to handle Jira and Scrum
| meetings all day, then it gets difficult to do that.
| datavirtue wrote:
| Definitely cultural. I have been watching engine teardown
| videos. The difference between the Japanese motors and
| American motors is stark if you know what to look for.
| Engineers were clearly in charge of designing every aspect of
| the Japanese motors. American engines have so many
| compromises and they flip-flop on internal parts and designs,
| that look whilly-nilly in comparison.
|
| It's obviously cost cutting niggling and get-it-out-the-door
| histrionics causing this chaos. There is significant impact
| to longevity and durability, and required maintenance. Very
| wasteful from a global warming perspective.
|
| Watch out for these late model ICE engines...do your
| research. If it's "newly redesigned!" step back and dig in.
| throwaway92837 wrote:
| Management doesn't always know what they are building is
| correct.
|
| They are going to manage risk of low quality with risk of wrong
| product.
| nine_zeros wrote:
| If management doesn't understand what is being built, maybe
| they are not fit to be a manager?
| Philip-J-Fry wrote:
| I wish I could pair program more. I have so much knowledge to
| give other members of my team. Domain knowledge, programming
| knowledge, common pitfalls, etc. You get a code review pass at
| the time of writing the code, and it means you have more
| opportunity to change things for the better. Once it's written
| there's not much appetite for drastically changing working code
| during code review unless there's a really good reason.
|
| But it's usually contained to someone like a junior calling me up
| and saying "can you help me?". The answer is always "yes of
| course!" and I share as much as I possibly can. But it ends
| there.
|
| I just want to sit down and show them things. Teach them in a way
| that makes things "click" the way I found they clicked with me.
| But I don't think management really values this approach. We get
| siloes of knowledge and then when someone leaves it's all hands
| on deck to transfer that knowledge.
|
| I'm often brought onto projects as a firefighter because I'm seen
| as productive. But I think the more important thing for the team
| would be to have me upskill everyone else below me. But for
| whatever reason, it's hard to get that point across to
| management. I can see myself in a few people and that they have
| potential, they just need encouragement.
| sodapopcan wrote:
| Pairing gets a lot of hate and is very misunderstood. It can be
| terrible, though, if the org doesn't encourage and teach it.
| There are also lots of things about pairing that are
| misunderstood, especially that things take more time.
|
| I was on a team that paired all the time and it's sort of
| ruined me for anything else. We switched pairs daily and
| everyone would pair with everyone else (on the team). When a
| junior joined the team they would very quickly lose their
| junior status.
| rjbwork wrote:
| Apparently I am pretty lucky. My managers are explicitly asking
| me to help rescue a project AND get the dev who did most of the
| work upskilled and following some of our patterns from some
| other successful projects. It is hard to know whether they are
| actually taking my advice and changes to heart and integrating
| them into their knowledge base and mindset, or just accepting
| that they're being asked to make changes by me and doing them.
|
| Mentorship is hard, regardless of management buy in :/
| foolfoolz wrote:
| this post is really strange because it actually describes a
| good environment
|
| - code isn't changing in code review except for really good
| reasons
|
| - people who need help are reaching out
|
| - projects that need help get additional help brought in
|
| what else are you looking for? this example is about as pair
| programming as it gets at most places. they're called silos
| when people don't like them and layers of abstraction otherwise
| but they're the same thing: no team will have 100% shared info
| on all parts and knowledge transfers on exits are a decent step
| to bridge this
|
| if you want to teach the team more, teach them more. usually
| the best way to do this is in code review. it's direct comments
| on code. write a good review you want more people to see? post
| it in the chat. set up additional time to share ideas with the
| team. all of these things you can do as an IC while producing
| code
|
| sorry but this post comes off as "i'm smarter than everyone."
| i'm guessing the reason management hasn't gotten your message
| is the message isn't clear. what exactly do you want to do? and
| what do you need their help for?
| Philip-J-Fry wrote:
| I don't think code reviews are the _best_ way to teach.
| Because for a start, you're usually working with a complete
| task. Someone can have a perfectly fine pull request that
| implements the feature or solves the bug, but it might not be
| the best way of going about it.
|
| Now, as a reviewer your spidey sense tingles and you get the
| feeling there's a better way. But now it's significantly more
| effort to pull that change apart or start from scratch and
| experiment with a new approach, then write this all up on the
| pull request with the caveat "but what you've written works,
| so in the interest of time we can merge this".
|
| Pair programming would get you on the right track from the
| start. You are able to assist an inexperienced dev and guide
| them through the process step by step. Imbuing your
| knowledge, raising questions, suggesting fixes. This is
| exactly what the blog post describes. The developer was seen
| as unproductive because their time was spend pair programming
| rather than directly doing the work themselves.
|
| I don't see how my post comes across as "I'm smarter than
| everyone". I know things that less experienced developers
| don't know, and that's a fact I know from talking to them and
| reviewing their code. But the culture just isn't there to be
| able to spend significant portions of my day effectively
| being their teacher (which I would love to do!). Instead it's
| often "the blind leading the blind" while the more senior
| members of the team are off delivering important projects and
| not having the capacity to imbue their knowledge onto the
| less experienced members of the team.
|
| It's a culture thing and I wouldn't say it's a good
| environment for nurturing new staff. Spending 2 hours in a
| Teams call or at someone's desk is uncomfortable for both
| parties in a company that doesn't encourage this sort of
| collaboration. And so there's a sense to not "waste someone's
| time". The person you're helping sees themselves as a burden
| rather than seeing themselves as a student. And as a teacher,
| you're conscious of the other work you're supposed to deliver
| because it's not expected for you to be spending significant
| parts of your day pair programming.
| liquidpele wrote:
| Have juniors plan out work first in design doc form and broken
| up into small deliverables. Helps to catch things early when
| they start down a rabbit hole.
| raincom wrote:
| In almost all companies, even seeking help is frowned upon. One
| ex-Microsoft manager, now a senior Manager at Atlassian, called
| that 'hand holding'. Some actively don't want to help out
| others, due to PIP/bonus culture. At Amazon, some team members
| explicitly give bad advice when asked for help. That's why we
| have this culture of "lone rockstars", who spend a lot of time
| to learn without being mentored.
| BirdieNZ wrote:
| > One ex-Microsoft manager, now a senior Manager at
| Atlassian, called that 'hand holding'.
|
| Which senior manager is this, out of interest?
| jonhohle wrote:
| If someone is intentionally giving bad advice, that sounds
| like they deserve some anytime feedback. (is that still a
| thing?) That is definitely not thinking like an owner.
| rawgabbit wrote:
| Seeking help isn't the problem. It is priorities. Usually the
| best developers are tasked with the more impactful tasks
| whose deadlines must be met at all costs. As a manager, I
| would view my task is to shield said developer from
| distractions so he can save my butt because my job is also on
| the line.
| segfaltnh wrote:
| Frankly it sounds like you need to make this happen. I don't
| know your company culture but at places I've worked Staff+
| engineers aren't meant to wait around for permission to be
| catalysts and mentor other engineers.
| Philip-J-Fry wrote:
| I'm usually the catalyst for change, but that's usually
| around tech and process. It's more effort for me to try and
| change my managers mind on what our development culture
| should be. The company I work for has a reputation for being
| a bit of a grinder and I've managed to help reduce that
| reputation in my team gradually at least.
|
| But at the moment I have work to do and deadlines to meet, so
| it's a hard sell to suggest stepping back from active
| development and focusing more on incubating our less
| experienced devs. Even though it's better in the long term,
| and my manager would even agree on that, important short term
| projects just take priority.
| nevertoolate wrote:
| Optimizing team efficiency is a team effort. It is a false
| dichotomy that you either work on "important project with
| deadline" or do mentoring. There are deeper structural
| problems that you need to solve first imo.
| politelemon wrote:
| Yes very similar. It makes me very happy when I'm called over
| by a junior proactively. Not mainly because I'm able to help
| them, the real reason is that they sensed something about the
| problem that needed a second pair of eyes, and they didn't
| waste time. That's them gaining intuition and experience and I
| get really happy for them.
|
| I don't actually say it though because I don't know how to
| express it.
| jimmaswell wrote:
| Pair programming sounds so stressful and unproductive to me.
| You can't read someone's mind. Any interjections while someone
| is in the middle of coding can't be more than distracting noise
| most of the time. And I would constantly feel self conscious
| that I'm taking too long to write something, googling or asking
| Copilot stupid questions, etc. Reviewing _after_ the programmer
| believes it 's ready to review makes much more sense to me.
| Though Copilot can be very helpful as an artificial pair
| programmer.
| teirce wrote:
| The point of pair programming isn't really to be talking to
| someone while they are coding a known solution. It's to work
| through and discover a solution together to an unknown. In
| this sense, you're kind of both in the same headspace
| together, and can have a conversation without necessarily
| breaking focus. And I would venture that almost any question
| that comes up in pair programming would either come up later
| in code review, or could be hand-waved with "yeah, I plan to
| fix that with X" and move on.
|
| The important part of pair programming isn't really the
| programming per se, it's the discussion.
|
| It also requires some amount of conversational art. As for
| being self conscious about things, you would have poor
| coworkers who make you think that or some unfounded worry. A
| good pair programmer can have a discussion without making you
| feel like an idiot - much the same as a good code review.
| psychphysic wrote:
| [flagged]
| yjftsjthsd-h wrote:
| Yes, that is what was written. Would you like to say
| something about it?
| psychphysic wrote:
| [flagged]
| awithrow wrote:
| Just say whatever point it is you are trying to make
| instead of making people guess
| psychphysic wrote:
| I'm actually quite enjoying how divisive a simple quote
| can be.
|
| I wonder how often I've made a comment and gotten no
| engagement. This quote seems to have gotten more
| engagement than the original comment. And quite emotive
| engagement.
|
| Makes me wonder what that means. Is it genuine curiosity?
| Or is the quote saying something that the original
| commenter couldn't see themselves? It's interesting they
| suggested if I was insinuating something negative about
| them.
|
| Importantly, they did not ask me. They told me. That too
| tells us something about what pairing experience with
| them would be.
| yjftsjthsd-h wrote:
| > I'm actually quite enjoying how divisive a simple quote
| can be
|
| The word for that is "trolling".
|
| > Importantly, they did not ask me. They told me. That
| too tells us something about what pairing experience with
| them would be.
|
| I asked and you avoided answering. What does that tell
| us?
| psychphysic wrote:
| > The word for that is "trolling".
|
| Oh that is fascinating, so highlighting a verbatim quote,
| in context can be trolling?
|
| What that makes me think of is that people are in denial
| about what the quote tells us and have displaced those
| feelings on to me! Amazing stuff.
|
| > I asked and you avoided answering. What does that tell
| us?
|
| This is interesting because no you didn't ask me what it
| tells us. You asked if I wanted to say something and I
| answered that the quote stands alone.
|
| Really interesting stuff in this thread!
| johnnyanmac wrote:
| >I think the quote stands alone.
|
| I disagree.
|
| >People are free to draw inferences about how it would be
| to pair with this programmer and why they are rarely
| paired.
|
| you could. but there's not much to work with. could be
| helpful but "too valuable" to be a mentor compared to a
| director or pitching sales or doing conferences. Could be
| overly pompous and makes things worse. Could simply be
| office culture and pair programming for more than 15
| minutes isn't a thing (like all my previous jobs).
|
| All are extreme assumptions that aren't productive to
| talk about. Personally: I don't know if I'd want to be in
| those cultures that enforced pair programming X times a
| week, but I wouldn't mind , say, a day a month where I
| could shadow a lead or vice versa and get some intimite
| knowledge, be it in correcting some pitfalls in my coding
| or seeing how a more experienced mind ticks. But the
| chance hasn't come up yet.
| Philip-J-Fry wrote:
| I'm rarely paired because pair programming just isn't
| something we do in the company outside of just helping
| people with their little issues. It's not an encouraged
| practice. There's nothing deep about it. It sounds like
| you're trying to insinuate something negative about me.
| sodapopcan wrote:
| I assume they are insinuating that you are coming off as
| arrogant and only interested in teaching. They should
| definitely just say so, though.
|
| In a good pairing environment everyone is learning from
| everyone. You didn't explicitly say you were looking to
| learn for others though you also didn't explicitly say
| you weren't. As far as I'm concerned, in the best pairing
| environments everyone is always pairing with everyone
| else, not just seniors with juniors. There is the idea
| that seniors can actually learn from juniors too since
| juniors will question things seniors haven't thought
| about in a long time and are living with "I do it like
| this because it's the way I've always done it" syndrome.
|
| PS, love the username :)
| Philip-J-Fry wrote:
| >In a good pairing environment everyone is learning from
| everyone. You didn't explicitly say you were looking to
| learn for others though you also didn't explicitly say
| you weren't.
|
| Well that's the thing. The only reason I'm in a senior
| position at this company is because I never stopped
| asking questions and I still don't stop asking questions
| and learning from people more knowledgeable than me. I
| used to spend hours sitting at one guys desk just asking
| questions and listening to rants and just gathering
| knowledge.
|
| I learned that this was the fastest way to progress and
| get better at the job, but I'm not finding that juniors
| and other less experienced devs are doing the same thing
| because they're worried about wasting people's time. And
| people are less likely to encourage this behaviour
| because they have high priority work. I got away with it
| when I joined the company because the rate of change was
| so much lower and so things generally just took longer.
| sodapopcan wrote:
| Yep, I feel this is a general broken thing about our
| industry. I'm very against the whole, "let juniors do
| easier stuff," mentality. I'm also very against the "you
| must make big disruptive changes in order to get ahead,"
| as well. The latter often results in people just looking
| in the wrong places to try and improve things, often by
| introducing complexity instead of removing it.
|
| I'm pretty jaded by it all. These days I work for a
| company whose primary business isn't technology and I'm
| much happier.
| Stratoscope wrote:
| Some 20 years ago, I worked at a moderately large software
| company that sold a desktop application for Mac and Windows. The
| team had mostly Mac experience and they were just getting their
| feet wet with Windows. So naturally the Windows version had some
| problems.
|
| At the time, I was known as a "Windows expert", so they hired me
| to help improve that version and help the team get more familiar
| with Windows programming.
|
| I would often spend the first part of the day on what I called
| "house calls": visiting other developers' offices to either pair
| program or troubleshoot bugs or just talk about Windows API best
| practices and the like. (Yes, we all had private offices!)
|
| After a while, one of my colleagues asked a question that stuck
| in my mind: "How can you afford to be so generous with your
| time?"
|
| Sure enough, a few months later I got a review with a mediocre
| rating and a comment: "Your productivity hasn't been quite we
| hoped, especially considering that the rest of the team has
| gotten more productive lately."
|
| Which was exactly what I thought they had hired me for!
| fabianholzer wrote:
| What happened after the mediocre performance review? Did leave
| for greener pastures asap? Did you start to optimize for their
| performance metrics, and stop being generous with your time? Or
| could you manage to convince somebody high enough above you in
| the org-chart that they actually hired you for what you thought
| they did?
| kvirani wrote:
| I hope that feedback didn't discourage you from continuing with
| your approach to software development and teamwork.
| shortrounddev2 wrote:
| I am the same way with my coworkers. I spend a lot of time
| helping juniors with their code and doing code review. My
| boss talked to me and told me to stop helping out so much and
| focus on my own tickets.
| elliotec wrote:
| It's a balance. Sometimes it is worth spending a ton of
| time leveling up your team (teaching them to fish), and
| sometimes it's much more helpful to have you do the work
| yourself (we ran out of food and you're our best
| fisherman).
| uxp8u61q wrote:
| It's easy to say that until it affects your paycheck.
| bullen wrote:
| "ideally as tangible business impact expressed in dollars saved,
| generated, or protected"
|
| Then exclude non-export numbers and divide that by the number of
| KWh used to generate that revenue.
|
| Edit: Please comment on down vote, otherwise we learn NOTHING!
| Octokiddie wrote:
| What's the metric for programmers who prevent the team from
| building the wrong product?
| mlhpdx wrote:
| Wonderful. In rowing there is a practice called "seat racing"
| where different combinations of people are rotated in and out of
| the eight positions to determine the combination that is the
| fastest. Individual strength is an indicator but it's the team
| speed that determines who is in the boat for races. The
| inevitable result is that the fastest combination rarely includes
| the eight strongest rowers. There is very often one or two
| "magical" people who don't look better "on paper" but make almost
| any boat faster when added to the mix. They have subtle ways of
| improving the set, rhythm and power of others. Not all coaches
| take this happily and resist it, with the obvious result of fewer
| wins.
|
| This is very, very analogous to software teams. It's the mix and
| results that matter most.
| gerdesj wrote:
| "This was cascaded through the organisation, and landed in our
| team in terms of story points delivered."
|
| Bingo.
|
| If I ever hear anyone in my company attempt to deliver a sentence
| like that then I will go postal.
| gumby wrote:
| One really good developer I worked with wrote excellent code and
| also terrible code that had to be replaced immediately -- and
| both made him great to work with.
|
| The value of writing good code is self explanatory. You probably
| use some of his code today.
|
| But he was also great in a firefight: customer is dead in the
| water and it might be our fault. He'd show up cold and "jam his
| fingers in the holes in the dam": quickly figure out what was
| wrong and then rapidly write and install the most hideous
| spaghetti code that cot the customer up and running. Code that
| could not be checked in, or be refactored. Eye-bleeding stuff.
| Someone would have to take the time to engineer a proper fix, but
| the immediate crisis was averted.
|
| I was actually much more impressed by the latter skill -- among
| other reasons it's simply rare. Also he was just a nice guy and
| everybody loved him.
|
| (Won't name him since I described some of his code as hideous)
| johnnyanmac wrote:
| >I was actually much more impressed by the latter skill --
| among other reasons it's simply rare
|
| Not exactly something to encourage, but it sounds like he has
| experience in competitive competitions, where generating code
| to a problem on the fly is necessary. It's not something you
| can't learn yourself, but rote memorization of common problems
| and solutions (to the point where you can mechanically type
| down some algorithm from memory) is the bane of my existence
| prerok wrote:
| The only 10x coder I knew was the one that managed to deliver
| stuff (almost) on time but also took the time to explain things
| to other (junior, me at the time) programmers. Such Tims are
| sadly rare and I think I should start working towards becoming
| like one.
| ironman1478 wrote:
| It's interesting reading this because this has been my role for a
| few years. I've also had similar problems with management wanting
| to pip me and things like that. Luckily, my company does peer
| review in addition to top down review and that has shown that I
| provide value even if it's not always coding.
|
| I think the managers who don't understand this type of role are
| the ones who were largely mediocre engineers, but were able to
| get to that position regardless. They just don't understand the
| process of engineering and that's it's not just churning out
| tickets or doing the bare minimum if you're working on something
| non-trivial.
| roenxi wrote:
| I dislike the just-so aspect of these sort of stories. I'd expect
| exceptional programmers to do unusually well on most metrics.
|
| But that is balanced by the threat of people trying to use
| metrics to measure developer productivity. It doesn't seem to be
| possible, any metric falls apart. If people are focusing on a
| metric, the greats aren't going to be leading any more. It'll be
| some junior who has misunderstood the system and has accidentally
| trained themselves to game metrics.
|
| Metrics do not drive good software. Repeatable processes love
| metrics. Repeatable software suggests bad development practices
| because that is a big hint of a library or bigger opportunity
| that nobody on the ground properly identified.
| kstrauser wrote:
| > I'd expect exceptional programmers to do unusually well on
| most metrics.
|
| ...when they're actually hands-on-keyboard writing software.
| The best programmers I know write as little code as possible.
|
| Product team: Hmm, we need to do a thing that looks very
| complex and difficult.
|
| Senior dev: I'll start making a project plan and story
| breakdown.
|
| Very senior dev: That sounds like a special case of a thing we
| already have. That should take about an hour.
|
| Of course that's a generalization, but I think the trend holds.
| The most illustrative metric for the best engineers wouldn't be
| "lines written" but "lines avoided".
| OnlyMortal wrote:
| In my experience, the best programmers write the least amount
| of code they can get away with.
|
| I don't mean they use the latest fashion library, I mean the
| amount of code they type is less simply because they
| understand the problem and know how to write a minimal
| solution.
|
| This makes their code easy to read and therefore easier to
| debug.
|
| It's worth noting that the less you type, the fewer bugs
| you'll create.
|
| To be fair, this is often due to the coder having significant
| experience.
| Fluorescence wrote:
| > Very senior dev: ... that should take about an hour.
|
| Red flag!
| nevertoolate wrote:
| Why do you say red flag? It is an exaggeration, of course,
| nothing is purely 1 hour. Rather it is 1 hour work in flow
| state, which is about 2 pomodoros, which is about 6
| bulletpoints, which is about 1/4 of a day's programming
| effort. Just about right for a 1 point card by a senior who
| only sit down to code when they kinda exactly know what to
| write
| ChoHag wrote:
| [dead]
| Fluorescence wrote:
| Talking about flow state and estimates? The red flag just
| gets bigger. You are asking me to show you that Santa is
| not real.
|
| A "very senior dev" will not be handing out "1 hour"
| estimates to a product team. An hour of what? Billable
| hours? Wall-clock time? It's just not the right framing.
| You will notice a good senior dev will be incredibly
| cautious about any commitment and not hand out "ego
| estimates" like one hour. They will make commitments that
| they can keep and it will be terms of releases.
|
| They will have experienced a decade of "one hour jobs"
| that have exploded so they know that even the error bars
| on a slam dunk 1 hour of butt-in-seat time means it's not
| a 1 hour estimate. An hour of butt-in-seat coding time is
| not a 1 hour of employee time - they've got that training
| course, those interviews, they need to support that
| thing, oh the presentation, the intern to look after.
| That feature you are copying? What is it copy-paste or
| some refactor generalisation? Measure that shit in weeks.
| Oh and there are 6 feature branches overlapping that area
| already. You also have a policy to improve the tech debt
| of this crusty code. There is also the documentation,
| training material, translations, the test suite, code
| review, the issue tracker... But hey, you can do it, you
| are x10, you boot up your machine and... your IDE is
| crashing because of some security update. Doesn't count
| in that one hour eh?!
|
| That's not even the main issue, odds are the first over
| the shoulder demo of this new feature will be just the
| start of eliciting the real requirements.
| kstrauser wrote:
| That sounds nightmarish.
|
| If I say 1 hour, I mean that I know exactly which knob
| needs to be twiddled, perhaps because I wrote it in the
| first place, and that there'll be a pull request ready
| for review an hour from now.
|
| That's clearly not always possible. Sometimes it is. If I
| say that it is, then I can deliver it.
| Fluorescence wrote:
| Scale ruins everything but that's where you will find
| "very senior devs".
|
| > Sometimes it is.
|
| What's the worst case of the other times? These "one
| hour" estimates are the golden path, nothing goes wrong,
| minimum. It's not the average of horror shows or an
| amortisation all the related support work required to
| sustain efficient development over time. They are often
| too coding-focused and ignore the level of interpersonal
| work to agree and sign off features or to change code in
| collaboration with others. Talking through a demo can
| take more time than the code.
| nevertoolate wrote:
| You are both right and need to take a break :)
| eesmith wrote:
| > I'd expect exceptional programmers to do unusually well on
| most metrics.
|
| Not if they game the metrics, as a way to force change.
|
| A classic example of an exceptional programmer doing worse on a
| (bad) metric is at
| https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
| , titled "-2000 Lines Of Code".
|
| "Some of the managers decided that it would be a good idea to
| track the progress of each individual engineer in terms of the
| amount of code that they wrote from week to week. ... Bill
| Atkinson ... thought that lines of code was a silly measure of
| software productivity. ... [He] made region operations almost
| six times faster. As a by-product, the rewrite also saved
| around 2,000 lines of code. ... when it was time to fill out
| the management form ... he thought about it for a second, and
| then wrote in the number: -2000. ... after a couple more weeks,
| they stopped asking Bill to fill out the form, and he gladly
| complied."
| erickf1 wrote:
| All I had to do was read the title of this article and the first
| sentence to understand that this is an example of what's wrong
| with the software development industry. I would rather work with
| people that act like good people and are human, than to work for
| the idiots measuring your every breath looking for a reason to
| fire you.
| [deleted]
| bighoki2885000 wrote:
| [dead]
| vikramkr wrote:
| So basically he just had the wrong title? Sounds like a great
| engineering manager or lead (in a company where that involves
| less code writing) or something. But his title is an IC role. But
| if he's spending all day pairing and not writing code then yeah -
| that manager seems to be correct, that's not his job? Why isn't
| he taking on any stories?
| orpheansodality wrote:
| pairing is taking stories, it's two people working on one task
| together.
| vikramkr wrote:
| So then he hasn't been taking zero, "literally zero" stories
| like the article says.
| sodapopcan wrote:
| The article said zero stories according to Jira.
|
| This is, of course, rectifiable in Jira by allowing a
| ticket to have multiple people assigned to it.
|
| ...unless they aren't using Jira and some tool that doesn't
| allow this.
| tetha wrote:
| The thing is: Different levels of experience need different
| measures of success, up to the point of leeway from the normal
| measurements of success.
|
| Like, for someone in tier 1 / tier 2 helpdesk, or the regular
| developer pushing relatively normal tickets through, simple
| ticket or story throughput is one indicator of productivity. As
| long as you pair it with some success measurement, like re-
| reports from people within a short time, or work caused by the
| implementation. Or just feedback from the rest. Someone has to
| put down code to make the feature work in the end.
|
| But this changes when you get more specialized and overall more
| experienced. If we bring a new technology into the team, my
| productivity based on the first metric will drop to zero. I'll be
| busy supporting other people. Or, the incidents on my desk will
| be far more weird ones. Other people get clear click paths and an
| exception. I had to debug JVM crashes due to faulty hardware.
| That took a bit longer than an afternoon in a debugger and adding
| an if-statement, if I may embellish a bit.
|
| But that's why soft skills become important. It's concerning how
| little that manager knows about his team. But it's also
| concerning how Tim didn't make sure his manager knows what's
| going on. For example if we're bringing in new tech, I'm
| informing superiors first that I'll prioritize support of team-
| members with the new tech just below business critical incidents
| and I most likely won't do any regular work for some time.
| chasing wrote:
| Alternate lesson: If your manager is telling you to complete
| tickets, don't go months and months _not doing that thing_ until
| you're on the verge of being fired because -- despite being a
| valuable member of the team -- your manager is all confused.
|
| Communication skills. Week 1 Tim could've brought up the issue of
| overall developer productivity with his manager and his manager
| would've at least been aware that Tim wasn't just playing
| Minecraft all day.
| _boffin_ wrote:
| Maybe Tim could have also added his name to the tickets as he
| was pairing and helping the others complete them...
| gardenhedge wrote:
| Certain tools (Ahem MS) don't allow more than one person to
| be added to a ticket
| chasing wrote:
| Yup. This idea that a developer can work his or her genius in
| a dark corner is flawed.
|
| If you aren't communicating what you're working on, it's hard
| to get credit or recognition. And it's not an ego or bragging
| thing: It's just fundamental team communication.
|
| For example, there may have been constraints that the manager
| knew about that sheer velocity was key for some reason. Or
| maybe the manager disagreed that Tim was adding enough value
| floating around all day. Who knows. But if Tim and his
| manager were in open communication, at a minimum there
| wouldn't be confusion _so great_ that a good engineer almost
| got shit-canned.
| sjtgraham wrote:
| This is not an argument on the merits of story points or metrics
| but Tim could have just put his name on the stories alongside the
| folks he helped. Problem solved.
| wonderwonder wrote:
| I worked at a company for a couple years where you had to produce
| 10 points a week or you got pipped. Didn't matter if you were a
| jr or sr. I worked on a few teams there and you could immediately
| tell how the teams measured points by the stress level of the
| developers.
|
| Teams that attempted to measure the points in good faith were
| stessed and most of them showed signs of burn out. They regularly
| worked 60 hours a week.
|
| Teams that gamed the system and understood the impossible task
| they were assigned always gave the highest points total to a
| ticket they could or broke it down into smaller achievable
| tickets that continuously added to their points totals. These
| teams were filled with happy stress free developers.
|
| In an environment like that playing by the rules is a suckers
| game.
|
| When I eventually quit, every sr engineer at the company; 7
| total, followed me within 4 months.
| throwawaysleep wrote:
| We called that Scrumflation at a past company. Didn't finish
| everything for the week? Claim the ticket was done and open a
| bug for the uncompleted work.
| vegetablepotpie wrote:
| The ironic thing is that may have generated exactly the
| outcomes management wanted.
|
| I've worked at places where it was more important for
| management to know what to expect than to achieve raw
| productivity towards a goal.
|
| The people who were estimating in good faith may have assumed
| that management was acting in good faith. Whereas a lot of
| projects are created aspirationally or have artificially short
| deadlines to "motivate" people. The stress they incurred may
| have just been for the emotional satisfaction of a manager and
| not have provided any more value than that.
| [deleted]
| snarf21 wrote:
| Goodhart's Law - "When a measure becomes a target, it ceases to
| be a good measure"
| crazygringo wrote:
| > _...or broke it down into smaller achievable tickets that
| continuously added to their points totals. These teams were
| filled with happy stress free developers._
|
| But that is part of the _point_ of scrum. To break down stories
| into consistently stress-free achievable stories, rather than
| big risky ones filled with unknowns.
|
| I'm not saying this was a good workplace, it doesn't sound like
| it at all. But to me, it sounds like the devs who you think
| gamed the system, were mostly behaving the way scrum is _meant_
| to incentivize. Happy, stress-free development that delivers
| _consistently_ improving software.
|
| (Minimum point totals per week leading to inflated point values
| is terrible management, though.)
| liquidpele wrote:
| You're missing the point, it's not about scrum it's about
| making the work look like it's way more than it is to pad the
| metric.
| epanchin wrote:
| The point of scrum is to provide employment for consultants
| and non-engineers.
|
| I left engineering for an engineering job in finance. No
| scrums, no POs, just trader driven development and I haven't
| looked back once. Glorious.
| wonderwonder wrote:
| OP here. You are right, but the minimum point totals
| eliminates any benefits that can be achieved from scrum, it
| forces engineers to incentivize survival over project
| momentum. If a story is really a 3 pointer but I know that if
| I close 2 3 point stories in a week then I am pipped,
| suddenly those 3 point stories are 5 point stories.
|
| On the teams that played fair, it was a mix of sr. and jr.
| and the sr. measuring that story at a 3 meant the jr. was
| working the weekend. Over and over again.
|
| Note: On the happy team, we had almost no supervision, not
| even a scrum master. We just looked out for each other. That
| 3 point story often suddenly became an 8 as the end of the
| week approached and no one blinked. That team incidentally
| was the only one that consistently got good reviews from
| management.
| [deleted]
| [deleted]
| backendanon wrote:
| When there's a good, engaged PO then Scrum can work.
| vegetablepotpie wrote:
| I think what the GP means by "gaming" the system is that the
| teams did all the technical activities of scrum without
| providing much or any business value.
|
| The issue with scrum or any process that involves estimating
| is that every software project will inevitably have some
| risky element or difficult to estimate task that is essential
| to the execution of the project. Scrum will incentivize teams
| to avoid the essential work and guide them towards work that
| is easier to estimate.
|
| Certainly having a good product owner can mitigate this
| because she can do the work of identifying and breaking down
| the intractable to something more actionable.
|
| But in that case you're depending on the people on the team
| to make good choices. Smart people can do that regardless of
| the development process they're using. It's unclear what
| value scrum brings to teams at all. It doesn't make bad teams
| work any better and it restricts how smart teams can operate.
|
| One thing that scrum does give is it provides management
| _metrics_ they can use to measure performance.
| wonderwonder wrote:
| "every software project will inevitably have some risky
| element or difficult to estimate task"
|
| You are exactly right here. At this company though, that
| risk on a personal level could mean a pip. So the happy
| teams inflated the story points massively to ensure that
| any or no risk was accounted for and they survived to code
| another day.
| Consultant32452 wrote:
| >Teams that attempted to measure the points in good faith were
| stessed and most of them showed signs of burn out. They
| regularly worked 60 hours a week.
|
| I read this as the teams that attempted to measure in good
| faith did a poor job at estimating. If management tells you
| that you are required to deliver 10 points per week, then 10
| points should take you 40 hours with rare exception. Whatever
| other idea you had in your head of what 10 points "should" mean
| is simply incorrect.
| fnimick wrote:
| > Teams that attempted to measure the points in good faith were
| stessed and most of them showed signs of burn out. They
| regularly worked 60 hours a week.
|
| So in the short term, the company benefited, yeah? They got
| more work out of the same people than they would have if they
| didn't apply the pressure.
|
| Reminds me of an old boss I had who would flat-out say that to
| get a project done we would "hire someone and burn them out" -
| he planned to only get six months of useful work out of
| someone, and if they were stupid enough to stick around for
| high stress and low pay, that's just a benefit to the company.
|
| (I didn't last very long there either)
| johnnyanmac wrote:
| Sure, if they were going to do layoffs in 6 months anyway, I
| guess this anti-pattern was coporate's wet dream. them
| quitting means they don't even have to bother with severance
| packages.
|
| But it sure is a shame we're past the days where you actually
| want to retain and nurture tribal knowledge. imagine if other
| engineering disciplines simply hopped companies every 2
| years, or if they cut half their civil engineers for a better
| earnings call (thankfully, he government doesn't have
| "shareholders". just taxpayers to disappoint).
| ResearchCode wrote:
| I don't think they did. If churning out low-quality code for
| 6 months was good project management, the Linux Foundation
| would be doing it.
| wonderwonder wrote:
| "So in the short term, the company benefited, yeah" In hind
| sight, they did not. The company is publicly traded and
| recently sold itself for parts to avoid bankruptcy. They are
| in a very niche industry and are notorious for their
| production environment going down, and massive data
| corruption in their clients data set. There are worse things
| as well but I am trying to be at least a little anonymous
| here.
| acdha wrote:
| The question is whether you get more volume but lower
| quality: a team doing 60 hour weeks on a regular basis tends
| to be a team baking in lots of technical debt and skipping
| "slow" things like "do we really understand what our users
| really need?" or "did we correctly architect this?"
| Everywhere I've seen this there's been a lot more rework and
| things like high infrastructure bills because people have
| [correctly] learned that the business doesn't care about
| quality.
| icambron wrote:
| The horrifying part of this is
|
| > Instead we would measure stories delivered, or it may have been
| story points (it turns out it doesn't matter), because these
| represented business value. We were using something like Jira,
| and people would put their name against stories, which made it
| super easy to generate these productivity metrics.
|
| I have never worked anywhere where middle management measured
| individual engineers via issue-tracker metrics. That seems almost
| implausibility dysfunctional. It's not just measuring a
| hilariously wrong thing at the wrong level of granularity, it's
| also disempowering the line manager from evaluating their own
| people. Is this a real thing companies do?
| wetpaws wrote:
| [dead]
| 3pt14159 wrote:
| Well, I like the story here, but it's kinda against a bit of a
| strawman. Don't get me wrong, I'm not losing the overall point of
| the piece, a point I agree with, but that said a metrics focussed
| manager could have simply added an "adjunct" label to the stories
| and had this "worst programmer" add themselves to stories as the
| non-lead developer.
|
| Ultimately the best way of measuring programmer productivity is
| by the assessments of the programmers on the team. This isn't as
| easy as it seems. For example, I once worked on a team where the
| best Heroku guy just had the absolute wrong idea about "easily
| understandable python code" since he would prefer to raise and
| catch an exception instead of rely on a built-in to test
| attribute existence or type compatibility. But nobody could get
| around large scale Heroku deployments like this guy. The juniors
| understand this nuance less well than seniors do, but even so, it
| does sorta come out in the wash. Your team does know its best
| people and they're usually happy to say it in a private one on
| one.
| jmull wrote:
| > a metrics focussed manager could have simply added an
| "adjunct" label to the stories and had this "worst programmer"
| add themselves to stories as the non-lead developer.
|
| The story includes a part where they dropped the crappy metric
| and changed to a better one.
| lcuff wrote:
| <Ultimately the best way of measuring programmer productivity
| is by the assessments of the programmers on the team. >
|
| Maybe ... Productivity itself is difficult to define. Different
| people will value aspects of the work differently
|
| At one Internet Advertising company I worked for, the founder
| had written most of the original code. Written in the late
| 1990s, it was Perl, JavaScript, HTML, and SQL jumbled together.
| Completely ignoring the notion of 'separation of concerns'.
| Huge amount of code duplication. Source code control? Phhht!
| Nary a test in sight. Ran programs as root to work around
| permission problems. Self modifying code ... you betcha. He
| worked right on the production servers. He could and would push
| out a feature the same day a customer asked for it. VERY quick
| to make the customers happy. The company was being bought out
| at the time I came on board. Pocketed his millions, headed down
| the road, yay for him.
|
| My own take is that the company would never have 'made it', if
| a software team had been hired to 'do it properly'.
|
| After his departure, as we rewrote our code base to
| 'professional' standards, much time was spent refactoring that
| produced few or no new features. How productive was that? A
| very complex question.
|
| As a digression, I sometimes found his original code easier to
| maintain that the stuff done 'the right way' because there WAS
| no 'separation of concerns'. I didn't have to hunt in a
| different part of the source tree for where something was done.
| It was all 'right there'. YMMV.
|
| In the end, 'productivity' is way more subjective that we'd
| like.
| rightbyte wrote:
| > I didn't have to hunt in a different part of the source
| tree for where something was done. It was all 'right there'.
| YMMV.
|
| This is my take too as I have gained experience. The way I
| did code from the get go, was the overall best way. Long
| function that did the stuff one thing at a time. Like no
| functions called from different parts of the call tree. I
| breeze to debug and understand or modify.
| bee_rider wrote:
| I believe that's the conventional approach in Python, though?
| It is a duck-typing language, try-except is a legitimate way of
| seen if an operator works on an object, and objects should do
| sensible things with operators.
|
| The funny example is that the hasattr built-in just tries to
| getattr, and then catches the exception to tell if it has the
| attribute.
| 3pt14159 wrote:
| If you are calling something immediately, a try-except is ok.
| If you are calling with a try-except just to simulate hasattr
| or getattr then why do we have the built-ins in the first
| place?
| bee_rider wrote:
| "Just try and then handle the exception" is a pretty weird
| paradigm for this sort of thing, to those of us who come
| from more typical languages. So I suspect they just
| included hasattr to make us more comfortable.
| corethree wrote:
| Conventions are changing. Modern python is shifting to type
| checking with external type checkers.
| [deleted]
| nickserv wrote:
| The two are not incompatible. I'll type all class
| properties and functions, but still use try/except on dict
| access or function calls.
| corethree wrote:
| It's not about incompatibility it's about safety. You
| drive with air bags or you don't, those two concepts are
| NOT about incompatibility. It doesn't even make sense.
|
| If there are situations where you have no choice but to
| drive without airbags, those are holes in safety.
|
| Essentially if you have to have runtime checks to prevent
| the program from full on crashing those are holes. Not
| everything is checkable with static checks but the way to
| go is to move as much of your code away from runtime
| checks as much as possible.
| eesmith wrote:
| I agree. In Python terms "Easier to Ask for Forgiveness than
| Permission" (EAFP) is preferred over "Look Before You Leap"
| (LBYL).
|
| https://docs.python.org/3/glossary.html#term-EAFP comments:
|
| > Easier to ask for forgiveness than permission. This common
| Python coding style assumes the existence of valid keys or
| attributes and catches exceptions if the assumption proves
| false. This clean and fast style is characterized by the
| presence of many try and except statements. The technique
| contrasts with the LBYL style common to many other languages
| such as C.
|
| and there are any number of essays on the topic, like (random
| DDG search) https://programmingduck.com/articles/lbyl-eafp .
| sdfgioafnui wrote:
| Exceptions are for exceptional circumstances. An object being
| a certain type is not an exceptional circumstance, not even
| in a dynamic language. You should never be surprised by the
| type of an object unless your program has serious design
| flaws.
|
| The fact that the language doesn't have your back means you
| need to be _more_ careful about types, not less. The type of
| the arguments is a function precondition. It 's the callee's
| responsibility to document preconditions and ideally recover
| cleanly from a violation, but the caller's responsibility to
| ensure preconditions are met. Illegal states should be caught
| early, not allowed to percolate until an exception is thrown.
|
| I don't much care if what I just wrote is "Pythonic" or not.
| I don't think too much careful design up front is responsible
| for every Python codebase I've ever seen reading like
| Finnegan's Wake.
| bee_rider wrote:
| You aren't required to like the conventional way they do
| things in Python.
|
| I dunno. I don't love Python for big projects either. If we
| want to go around and tell all the people using this very
| popular language to stop shipping their successful products
| because they look messy to us, I'll happily take the second
| shift (after you), haha.
| zug_zug wrote:
| So I used to kind of think like you, but I think that's just
| not a practical approach. Yes, you could alter the system in
| this 1 exact situation if you know exactly what to change, but
| there will be dozens of other failure modes too (engineer
| releases code that breaks in 2 months, engineer deliberately
| mis-estimates story points, engineer doesn't comment their code
| so that nobody else on team can do certain work, etc)
|
| So if you have a manager who is a dialed-in coder who's going
| to keep updating the jira-point formula based on spending more
| than 1 hour a day reading code, and keep tuning it around the
| ever-more creative loopholes engineers employ, then yes, you
| may end up with a workable system. But never yet in my long
| career have I seen that.
| 3pt14159 wrote:
| No, no, you misunderstand. I _agree_ with the point. I just
| think it was made against a strawman and could have been made
| even stronger. I 'm not for metrics on stories to award
| productivity points. I'm for one-on-ones and success-as-a-
| team evaluations.
| ww520 wrote:
| Stories like this happened is because managers want to treat
| software development as a manufacturing process.
| TuringNYC wrote:
| I heard stories from past employers where they wanted bi-
| monthly increases in scrum velocity.
|
| "OK, last sprint the team did 150 points, so we should do 160
| points this sprint."
|
| The funny thing is that point estimates just went up to
| compensate for productivity gain demands. "More productivity"
| yay!
| ozim wrote:
| Well I think that is the worst that can be.
|
| Maybe best as well because you quickly know to pack things up
| and look for a new job.
| yabbs wrote:
| Stories like this happened is because managers
| convolvatron wrote:
| ok. most managers suck. but ultimately you have to have at
| least one adult in the room.
| olddustytrail wrote:
| Indeed. To keep the manager in check, right?
| solarmist wrote:
| And usually it isn't the manager, even if they want to be.
| They're managers because they're good at projecting to
| their boss's wants and needs.
| ryeguy_24 wrote:
| If you don't own your company, you are always measured on optics.
| If the person who employs you does not optically see your value,
| you don't stand a chance working there. If employment is the
| measurement, optics will always be important. For those who
| disagree, I would argue they are arguing on what would be ideal.
| Sure, it would be ideal to have a fully meritocratic performance
| system but if someone else is in charge of your employment or
| performance evaluation, your success is 100% based on their
| opinion of you. How do they get that opinion? It's the optics
| whether valuable for the company or not.
|
| Just to be clear, I'm not talking about programming skill or
| value. I'm talking about employment and evaluations which I think
| most people are commenting on.
|
| And also, it's not mutually exclusive. I know many people who are
| very productive and also manage their optics well.
| tastysandwich wrote:
| When I joined my company, I was introduced to this dev who'd been
| there since the start.
|
| His English wasn't great. His Javascript wasn't "modern" - he
| kept using callbacks etc. He often poo-poohed ideas the younger
| wizz-bang devs had. And so I was warned - basically he's an old
| curmudgeon, set in his ways, he can't take any criticism but
| he'll dole it out, a pain to deal with.
|
| I quickly learnt how untrue that all was. OK, his code isn't
| great. BUT he's 100% committed to delivering customer value. He
| understands the ins-and-outs like no one else. He thinks through
| every scenario from the customer's perspective, and absolutely
| NAILS it every time. The young devs didn't like him because he
| didn't give a shit about "GraphQL versus REST" or "Hapi.js vs
| Express vs Koa vs whatever".
|
| Where the other teams would avoid involving him in design
| conversations, I'd pull him in straight away. And our team reaped
| the rewards of integration projects that delivered right out of
| the starting gate, rather than customers kicking them right back
| with complaints.
| m3kw9 wrote:
| Had this same issue, new young devs adding the latest
| programming tricks and saying yes to every fking thing as if a
| no will get hurt their "I can do anything" mentality. Others
| were not pushing back as it may make them look stupid or
| something, they treat the project like a social event.
|
| A lot of these little things came back to bite hard
| obiefernandez wrote:
| I was a colleague of these guys at Thoughtworks and my favorite
| most relatable tidbit was telling client managers "no".
|
| High performance teams at Thoughtworks really had almost full
| autonomy over how they worked. At a particular credit card bank
| in Delaware circa 2006, Jay Fields and I demanded (and got) flat
| screen monitors, our own conference room to use as a dedicated
| bullpen and most importantly, unfettered access to the open
| internet via custom holes in their firewall. Crazy times.
| andy_ppp wrote:
| I worked with a copywriter who did similar stuff and made the
| team tick. It was great to watch him effortlessly get everyone
| doing the right thing for the project and it worked both ways,
| he'd communicate effectively with the dev why we needed to hack
| things and with the business about getting us extra time for
| certain things. It lead to a better project with a manageable
| amount of technical debt.
|
| He was let go and the project became a lot less successful and
| enjoyable, once he was gone a large group left soon afterwards...
___________________________________________________________________
(page generated 2023-09-02 23:00 UTC)