[HN Gopher] Optimizing your talking points (2018)
___________________________________________________________________
Optimizing your talking points (2018)
Author : compiler-guy
Score : 180 points
Date : 2024-05-25 03:13 UTC (19 hours ago)
(HTM) web link (rachelbythebay.com)
(TXT) w3m dump (rachelbythebay.com)
| rkachowski wrote:
| I agree this righteous "one" stuff is toxic. There is something
| very liberating and wholesome about a senior developer being able
| to discuss the mistakes and fuckups they've made. It's not just a
| learning opportunity, it also demonstrates a culture of openness
| and works against imposter syndrome.
|
| A perfectionist attitude stands in opposition to this - just try
| harder and stop making mistakes. There's nothing to learn, just
| more individual effort to apply.
| tetha wrote:
| Most of us are hopefully also improving at what they do. Our
| config management has a bunch of stuff written by me that's
| perfectly functional and works overall. But after a year or two
| working with the tool, I would call it pretty bad quality for
| various reasons.
|
| But that's fine. If I have a reason to change it, I'll clean it
| up. Until then, it stays around as an example to show some bad
| practices and why other approaches are better.
| otherme123 wrote:
| I immediately recall at least two big fuckups that the "one"
| (two different persons) didn't acknowledge, even if that meant
| to lose a good client, and I would guess bad mouthing.
|
| Once I ate a small fuckup from one of my juniors (we put a
| wrong software version in a report), and instead of fixing it
| with the client by simply saying "we had a mistake, here is the
| fixed report", my superior only could think about "could we
| hide this, and keep the face that we are perfect?". Of course,
| this same person takes _any_ mistake from other people as an
| opportunity to ask for discounts, compensations and freebies.
| evrydayhustling wrote:
| If you can't find things to criticize about yourself, it means
| you aren't improving. Sharing these critiques helps others both
| learn from your mistakes, and that it's ok to learn from their
| own.
| dclowd9901 wrote:
| Why is this person feeding trolls? Don't we all know people who
| think they're infallible are full of shit anyway and just ignore
| them?
| bjackman wrote:
| You can't just divide the world into people who believe
| fallacies and people who don't. They are rooted in fundamental
| cognitive biases, everyone falls for the "just try
| harder"/"just be better"/"just don't put any bugs in the
| code"/"just have excellent test coverage" thing sometimes.
|
| Certainly all the most experienced engineers I work with, who
| should definitely know better, still haven't fully internalised
| the fact that all code is broken.
| 8n4vidtmkvmk wrote:
| They really should. I've been programming over 20 years and
| don't think I've seen a program without at least a few
| defects. A couple have come close, those are impressive, but
| bugs always happen.
| gravescale wrote:
| Show me a program that has no bugs and I'll show you a
| program that does nothing at all!
|
| Even most Hello Worlds don't check the pipe was written to
| correctly. And now we get into "well actually that's
| technically not a bug because it is not in the spec" and if
| we're finding the need to split _that_ hair, we can hardly
| be talking about some mythically perfect software.
| richardw wrote:
| You're not wrong but Knuth's programs have very few bugs
| and do a shitload.
|
| "The reward for coding errors found in Knuth's TeX and
| Metafont programs (as distinguished from errors in
| Knuth's books) followed an audacious scheme inspired by
| the wheat and chessboard problem,[10] starting at $2.56,
| and doubling every year until it reached $327.68."
|
| https://en.m.wikipedia.org/wiki/Knuth_reward_check
| re-thc wrote:
| > Show me a program that has no bugs
|
| They're features!
| epr wrote:
| > Even most Hello Worlds don't check the pipe was written
| to correctly.
|
| The word for this is not "perfect", but "overengineered"
| npsimons wrote:
| > Show me a program that has no bugs and I'll show you a
| program that does nothing at all!
|
| "Every program has at least one bug and can be shortened
| by at least one instruction -- from which, by induction,
| one can deduce that every program can be reduced to one
| instruction which doesn't work."
| throwaway4233 wrote:
| I do not believe that most of these `perfectionists` are
| trolls. Some have just very bad experiences either in their
| career or childhood that make them feel that making mistakes is
| not normal.
|
| I was a `perfectionist` for a while due to certain bad
| experiences at work, and it was only through the help of really
| good teammates that I was able to slowly get rid of it. And
| that required pointing out things like what the author has done
| in their blog post and once someone sees that mistakes are
| things that anyone could make, they get more comfortable the
| concept.
|
| The harder part is understanding why a perfectionist is so, and
| then not getting frustrated while you try to help them improve.
| akoboldfrying wrote:
| >malloc("HTTP")
|
| I'm reminded of a Simpsons episode where Homer tries to assemble
| a barbecue by pressing a brick and a piece of pipe together.
| pavlov wrote:
| Because I am the one, my custom malloc checks a given size
| against the list of known constant string pointers and if it
| matches, it calls strdup instead.
|
| So easy to program defensively in C.
| lambdaxyzw wrote:
| I guess you could check if the pointer points inside a data
| section of your program, and if yes, call strlen on it. It's
| all so easy!
| jrockway wrote:
| "That's one fine looking barbeque pit."
| philbo wrote:
| I've received a few nasty comments in response to blog posts,
| both here and on reddit. When it happens I update the post to
| link to the nasty comment, without judgement, just to shine a
| light on it. Usually nothing happens but sometimes it steers the
| discussion to a healthier place.
| rulalala wrote:
| This is great. I wish all humans could think that way.
| ChrisMarshallNY wrote:
| I've received quite a few. Some, probably deserved; most,
| likely not. In a few cases, it was -sort of- deserved, but not
| helpful, or directly harmful to the community. Saying the right
| thing, in the wrong way, is still saying the wrong thing.
|
| _> When it happens I update the post to link to the nasty
| comment, without judgement, just to shine a light on it._
|
| Not a bad idea. Not always possible, if the comment gets
| dead'nd. In any case, I do not respond in kind. I'm quite
| capable of it (recovering troll), but I won't go there. It's
| not being a "snob." It's just that I've learned that gasoline
| is an ineffective fire suppressant.
|
| If I'm wrong, I've learned to promptly admit it; in the same
| venue as the mistake (a pet peeve is private apologies for
| public attacks).
|
| There is a line though. I feel that I do really good work. I've
| been doing this for a _long_ time (like, 40 years), and have
| learned quite a bit, in that time. I 've also worked some
| pretty tough rooms, and for folks that wouldn't accept crap, so
| I have learned to habitually do decent work.
|
| My general policy is to avoid casting judgment onto others in
| public. It doesn't help; even if I'm right (not always the
| case).
|
| But if we're working together, or I am using your stuff, then
| it might be a different story. I have had people savagely
| attack me, because I won't accept garbage. Guilty as charged,
| but I don't go Torvalds on them. I just tell them that their
| work is not acceptable to me, in a respectful manner, if
| possible.
|
| Nevertheless, I have found that I can always improve, and learn
| new stuff; sometimes, from the most unexpected places, and
| being open to these lessons is basic good policy. I become
| right, by being wrong, and learning otherwise.
|
| _" Good judgment comes from experience. Experience comes from
| bad judgment."_
| kortilla wrote:
| Saying that you won't accept "garbage" is a pretty toxic way
| of phrasing things. If you say that around the people you
| work with (especially junior people), they have a habit of
| interpreting any negative feedback on code as you calling it
| garbage. Then they start avoiding feedback from you when
| possible and then everyone suffers.
|
| I've seen this pattern play out over and over. It makes what
| could be a great lead senior engineer just a lone wolf only a
| few people want to work with.
|
| > feel that I do really good work. I've been doing this for a
| long time (like, 40 years),
|
| Never substitute tenure for competence, particularly when you
| are convincing yourself that you do good work.
|
| One of the biggest red flags in hiring is when people defer
| to tenure as a reason for anything technical. It is very easy
| to do things wrong or poorly for a long time without even
| knowing it. So falling into the trap of "I've been doing this
| 40 years and people have paid me for it, so it must be good"
| is a death sentence.
| xandrius wrote:
| Got the same vibes when reading their comment, basically
| self identifying as "the one" without admitting it.
|
| The funny thing is that if someone has been doing IT for 40
| years, I'd expect them to be generally aware that they
| might be good at big picture stuff but less so on minute
| things, as technology, philosophies and approaches change
| every few years but the general concepts stay the same.
| ChrisMarshallNY wrote:
| Cool. I didn't mean it that way, but if you wish to
| perceive it as such, it's a free country.
| ChrisMarshallNY wrote:
| Well, a stint working for one of the top-quality companies
| in the world taught me to develop a fairly thick skin. The
| Japanese are not gentle, when criticizing each other, and I
| had the honor to be considered worthy of Japanese-level
| evaluation.
|
| But be that as it may, I don't "harsh out" on people;
| _especially_ in public venues. I may _think_ "garbage," but
| I'm much more likely to _say_ "this won't fit into the
| framework in that form." It's my experience that many of
| today's folks get _very_ nasty (and personal), when
| confronted with even mild rebuke. I can understand why
| Torvalds goes nuclear, although I won't go there, myself (I
| consider it unprofessional).
|
| I remember once, denying a patch (SVN), because the "fix"
| would have addressed the submitter's particular issue, but
| also would have broken the functionality for, literally,
| hundreds of others. I told them that it was a good idea,
| but I couldn't implement it, as provided, because of that,
| and suggested that we figure out some changes.
|
| The response was a long, public excoriation, complete with
| genealogical evaluations of my ancestry, back to the
| Pliocene.
|
| I decided that, even though they had a point, and we
| probably could have figured out how to give them what they
| wanted, after some give-and-take, it wasn't really
| possible, because of their attitude. I did end up applying
| part of their request; just not the part that broke it for
| everyone else (I did credit them in the comments). I
| blocked them, and we have never worked together since.
|
| I remember a post here, some time back, where a fairly
| talented young chap, was complaining about not being made a
| core Linux Kernel contributor, simply because he submitted
| a good PR.
|
| If we want to be above-average, then we need to be
| _willing_ to put ourselves into positions, where we _will_
| get criticized; and, quite frequently, the ones doing the
| criticism are far from gentle. It 's been my experience
| that folks at the top of their game, frequently fail to
| accomodate those that are not at their level. They aren't
| always right, but they are often worth listening to,
| anyway, and we don't do ourselves any favors, by reacting
| badly.
|
| There is definitely something to be said for earning our
| stripes.
| lelanthran wrote:
| > One of the biggest red flags in hiring is when people
| defer to tenure as a reason for anything technical.
|
| You know what the great thing about years of experience is?
|
| It's usually _" I hold this $TECHNICAL opinion because it
| is the result of careful refinement over 20 years."_
|
| In some cases it is _" I formed this $TECHNICAL opinion 20
| years ago, and haven't come across enough evidence to
| change my mind"_
|
| It is VERY RARELY _" I formed this $TECHNICAL opinion 20
| years ago and dismissed any evidence to the contrary over
| the last 20 years, while still managing to retain gainful
| employment"_.
|
| TBH, if you are seeing people from the third group often
| enough to use it as a heuristic, chances are it's a poor
| (or poorly correlated) heuristic that you haven't yet seen
| for the poor quality it is.
|
| IOW, you are holding an opinion based on your experience,
| about others who hold an opinion based on _their_
| experience.
|
| Holding on to this opinion _might_ even make you part of
| that third group I listed above.
|
| Very ironic.
| BillFranklin wrote:
| I don't disagree that some engineers have bad attitudes! Everyone
| is capable of writing bad code, and there is something to be said
| for the argument that all code is bad and a liability.
|
| This article is an interesting companion to "No more pink
| mustache" [1] wherein Lyft is described as "broken at a scale
| that is hard to believe" - often the explanation for quality is
| the org, not the human in the chair :-)
|
| [1] https://rachelbythebay.com/w/2020/02/29/poof/
| surfingdino wrote:
| I could not disagree with the point made, but there is a flip
| side to this--being able to take feedback.
| jasonlotito wrote:
| Most people can take feedback and apply it. I find some people
| just give feedback poorly and equate that to others not taking
| feedback.
|
| These people usually think there preferred feedback is the best
| way so therefore everyone should feel the same way and if they
| don't the other person needs to change.
|
| They are of course wrong. But if you tell them this, they
| demonstrate why I use the word "most" in the opening sentence.
| npsimons wrote:
| > I find some people just give feedback poorly and equate
| that to others not taking feedback.
|
| Too true! I find it helps if I think of it as an engineering
| problem: "what can I say that will make these people not
| commit the same error again?" A bit dehumanizing and
| manipulative, but can be super effective at shifting away
| from blaming and belittling (almost never works), and towards
| mentoring.
| red_admiral wrote:
| (2018), but still worth reading.
| tanelpoder wrote:
| I can't find the blog/article anymore, but its message was that
| "when you see something suboptimal in the code, do not assume
| incompetence". As people who wrote the code may have had tight
| deadlines, different priorities set for them and other factors
| that may have prevented the developers from "doing the right
| thing" immediately...
| lambdaxyzw wrote:
| There's also chesterton fence - maybe this dumb thing in code
| actually was important some time ago. Or, even worse, maybe it
| is still an important for a rare edge case and you just don't
| see how, yet.
| brazzy wrote:
| That as well is "not doing the right thing", namely adding a
| comment that explains the need for it.
| kqr wrote:
| The Chesterton fence in my book is only about something that
| is still meaningful only in non-obvious ways. In evolutionary
| theory I believe "used to have a sensible explanation but no
| longer does due to changing circumstances" is known as
| _discordance_.
| MrJohz wrote:
| The fence is about all things that you might want to
| change, whether or not they're still useful. Both of the
| characters in Chesterton's parable are reformers, and the
| assumption is still that the goal should be reform. The
| question is more about the motivation for reform.
|
| The first character wishes to remove the fence because they
| don't see a good reason for it. The second takes a
| different approach: first show that it isn't necessary,
| then remove it.
|
| Plenty of things are made useless over time. But there are
| also lots of things that look useless but aren't. We don't
| know, a priori, which is which, hence the need to be
| cautious.
|
| (That said, I think there are also cases where ignoring
| Chesterton, removing the fence, and seeing what will happen
| is the best option. It just requires good planning and good
| testing so that you can be confident that a bull doesn't
| suddenly appear out of nowhere!)
| npsimons wrote:
| > you just don't see how
|
| Always, _always_ assume this is the case - it might frustrate
| you to no end, but until you have conclusive evidence
| something is "wrong", it's best to ignore it and toodle
| along with whatever you're _supposed_ to be working on (I
| always encounter these head scratchers when working on legacy
| code, my tasking being something unrelated).
| YZF wrote:
| I would soften this to always consider that possibility.
| The probability that something is just wrong, or the
| requirements have evolved in a way that makes it wrong, is
| probably not that different than the probability the
| original author had a very strong reason for doing
| something a certain way and that really did survive the
| test of time. Considering everything preexisting to be
| perfect is overly conservative and almost certainly wrong
| in most real world software engineering scenarios. The
| history of software engineering is full of examples of
| things that got replaced with much better things because
| the original was just not good enough.
| pornel wrote:
| Even if the code has been absolutely perfect at the time of
| writing, growth of the codebase, and changing requirements
| could make it bad.
|
| e.g. if you have 10 items to store, then a simple file may be a
| pragmatic choice. When it grows to 10,000 items you may need a
| database. But if you started with a database for just 10 items,
| people would complain it's overengineered.
|
| If you have 2 classes, an if/else can do, but at 20 you need
| some Factory pattern, which would be an architecture
| astronautics if done from the start.
|
| And when you try to anticipate such growth, you'll create
| overcomplicated code whenever you guess wrong.
|
| A continuously developed project will systematically keep
| outgrowing itself.
| NBJack wrote:
| Or just that errant refactoring automation that moved a
| proverbial (or literal) bit out of place.
|
| It's good to learn from our mistakes. But if there's one
| thing I have learned from working across teams and orgs, it
| is that basically everyone works with imperfect information.
| And oftentimes, you just have to make do, write the code, and
| try to make room to course correct in the future.
| 1penny42cents wrote:
| fwiw I've written about that here:
| https://camhashemi.com/posts/building-through-uncertainty/
| auggierose wrote:
| And how can this be? Because he is the Kwisatz Haderach!
| cushychicken wrote:
| The Mahdi is too humble to admit he is the Mahdi!
| Sammi wrote:
| I regularly have codevs who say similar things to "why don't you
| just not make that mistake?" and "why not just do <insert crazy
| complex thing here> instead?".
|
| I've taken to responding with: "Because you probably have more IQ
| points than me. I have fewer IQ points than you, so therefore I
| must do dumber and simpler things than you."
|
| It's made some of their faces turn red in embarrassment, as they
| finally realized what unreflected belittling little dorks they
| were being.
| dmichulke wrote:
| An alternative is to plainly agree with them: "I know, that was
| dumb, wasn't it?" or "You're right, I probably shouldn't"or
| just "I'll think about it"
|
| This means they can't shame / guilt you for doing something
| suboptimal and I believe this is often their goal - establish
| superiority by inducing guilt or shame.
|
| It's like opting to not play the game with them. And usually,
| that's the winning move.
| kortilla wrote:
| This gives them what they are looking for though (public
| praise). It quickly ends the interaction but doesn't prevent
| future ones.
| npsimons wrote:
| > "I'll think about it"
|
| Unless you're being totally earnest, this one reads like
| "I'll take it under advisement"[0]
|
| [0] - https://getyarn.io/yarn-
| clip/ed82da6b-db48-49aa-a105-f190e63...
| juliushuijnk wrote:
| If it is said in ignorance, there is no need to view it as an
| attack that you need to make them pay for with embarrassment.
| viraptor wrote:
| Very nice application of grug brain https://grugbrain.dev/
|
| > given choice between complexity or one on one against t-rex,
| grug take t-rex: at least grug see t-rex
| AgentOrange1234 wrote:
| Thanks. That was a delightful read.
| OJFord wrote:
| That seems really combative to me, like you're just escalating
| the situation. I hope I phrase it better than that (but you're
| presumably paraphrasing so it's a hard thing to self-assess),
| but I point out mistakes and suggest (what I think is) a better
| alternative all the time in code review, that's the point of
| it? If you replied to me like that I'd probably just disengage,
| not bother to look at your PRs any more.
| slowking2 wrote:
| Barring it being a joke, the first question is unhelpful and
| likely a jerk move. Everyone makes mistakes sometimes.
|
| The second question seems like the type of feedback that would
| usually be fine. People's skills and knowledge don't always
| overlap. What is crazy complex for A may not be for B and what
| is crazy complex for B may not be for A! And that doesn't have
| to have anything do with A or B being smarter. A might not know
| SQL and B might not know pandas. But sometimes it really does
| make sense to move some code from SQL to pandas or vice-versa
| (assume for the moment that both SQL and pandas are already in
| the tech stack). Some people find it simple to write in object
| oriented style and others in a functional style. What makes
| more sense to do is not always obvious. So the question could
| be a good one. If the suggestion is bad, explain why it's bad.
| If the suggestion is good, maybe consider if it's worth doing
| at current point. If it's somewhere in the middle or there's no
| time, acknowledge and move on.
| dahart wrote:
| I'm a bit allergic to questions that begin "Why not just ...".
| With those three words, I can usually already tell what's
| coming before they tell me their idea, not because the
| suggestion is crazy complex but because almost invariably it's
| the first thing that popped into the person's head, because
| it's the most obvious thing one could do, and has already been
| carefully considered or already tried. The question itself
| isn't bad, it's the underlying assumptions that makes it
| irritating and/or insulting, the assumptions that 1) their idea
| is so easy, and 2) you didn't think of this obvious & easy
| idea.
|
| And when I'm on the other end of this asking someone else why
| they didn't do it in some way that looks obvious to me, I try
| hard to avoid "why not just". Sometimes I will ask "I assume
| you didn't X for some reason?" But maybe the best is to ask why
| nicely without making any suggestions.
|
| When the question comes because they were lacking context, this
| can sometimes be headed off at the pass by announcing why the
| most obvious things didn't work before explaining what you did
| do, or by highlighting the confounding requirements or
| problematic inputs. If the question comes from already-
| committed code, the goal would be to have commit or MR code
| comments that prevent post-facto second-guessing. Sometimes
| it's useful to accept the question without retort and just
| answer it directly, by explaining that their idea was tried and
| didn't work, and what the reasons are, and ask if they'd like
| to share any other ideas, earnestly not sarcastically. :P
|
| If the suggestion really was something I didn't think of and
| seems like it might solve a problem, which might be rare but
| does happen to me on occasion, then I do like to tell them it's
| a good idea and recruit them to help me implement it. In that
| case, pushing back on their assumptions or tone is tempting to
| me, but I will try to let it roll off and just take the
| feedback and be momentarily embarrassed.
| h2odragon wrote:
| When someone offers advice about "it might have done better"; it
| not always an assualt on you, an insult of your abilities, and so
| on.
|
| The person offering the advice may be an idjit, just at dealing
| with others or maybe even completely.
|
| It's OK if the some of rest of the world fails to agree with you.
| People voicing contrary opinions, failing to agree with you, etc;
| doesn't threaten you in any way.
| philk10 wrote:
| "You shouldn't hire bad programmers" - I did work at a company
| where the CEO did say that he wished they had programmers who
| didn't write bugs
|
| He did also not want me to do any testing as "the customers were
| better at finding bugs than we are"
| lelanthran wrote:
| > He did also not want me to do any testing as "the customers
| were better at finding bugs than we are"
|
| He's not wrong about that quoted bit, though :-/
|
| Paying customers are uncannily better at finding bugs than
| _anyone!_
|
| [Note: I am not advocating for removing testing from your
| process.]
| avensec wrote:
| I read this in 2018 and I'm glad to see it posted again. It was
| one of those posts that made me ask myself a question. I can't
| remove the absolutism or extremes, so how can I create a filter
| for when I hear these conversations/people? I have my model,
| but...
|
| What strategies do people employ here?
| sdwr wrote:
| These people are claiming emotional territory that doesn't
| belong to them. Usually, they have precalculated that they can
| "get away" with it, which means they see you as weak.
|
| Three options:
|
| - Give up, cede the ground, and move on with your life. The
| less sleep you lose over how unfair it is, the better.
|
| - Confront them head-on. They are ready for a fight, but their
| position is inherently unreasonable. The less you get dragged
| into their headspace, the more you "win".
|
| - Come down from above. Bring social proof that they are wrong
| into their space. In the OP, this would be programmers who
| mutually respect each other's work, and are productive without
| nitpicking.
| mgkimsal wrote:
| Couple of stories about 'bad code':
|
| I've often worked solo, but have been on teams where I've written
| code that was... not great. Worked, but... suboptimal. Various
| reasons, but it is what it is. To remedy that, I would try to
| refactor old stuff in conjunction with new work. That was often
| rejected. So... I'd take to documenting needed refactorings/fixes
| in tickets. Those would rarely ever get attention - generally
| deprioritized or ignored. This led to - for me - constant low-
| level frustration. When working solo, I can prioritize what I
| need to; in teams... you can't ever make a suboptimal decision
| because it will live forever. Or until a 'system is down' moment.
| Those would lead to "post mortems", in which I would point to
| tickets requesting to fix ticking time bombs months earlier,
| explain they were ignored by leadership, and... that came across
| as 'blaming' or 'antagonistic'. The 'fix' is to just never write
| suboptimal code, which leads to more frustration and anxiety when
| writing.
|
| Secondly, in 2017, I got a call to fix something I'd written in
| ... 2003/2004. That code was still in production (with minor
| patches by others along the way). It's quite humbling to have to
| review broken code and corners cut, and realize that you were the
| one responsible for it (and no one else). That (and a few other
| incidents) have given me a big change in perspective on writing
| maintainable code (and documentation, etc).
| thadt wrote:
| You either die a hero or live long enough to see _your_ name in
| the decade old git blame.
| mgkimsal wrote:
| 2003... svn all the way :)
| marcosdumay wrote:
| Joke's on you, our repositories do not live for that long!
|
| But yeah, the experience of having somebody asking you "Hey,
| you know about X! Do you know anything about this system
| here? What am I doing wrong that my program always gets a
| different result?" when it's your code, it's because your
| code was always obviously wrong, it's the first you ever
| notice it, and that person's boss is complaining because
| their code is correct... It's not nice.
| SoftTalker wrote:
| "Works but suboptimal" is often an acceptable tradeoff when you
| have more work than you have time to implement in an optimal
| way. "Perfect is the enemy of good" and other slogans that MBAs
| learn in school are phrases you can use when something falls
| through the cracks.
| mgkimsal wrote:
| My phrasing may have been better in some cases. "Works but is
| going to cause a problem when XYZ happens" may be more
| accurate. I was actually told by a PM once "how about you
| just say 'I told you so' after something breaks instead of
| always complaining about wanting to fix stuff?" which was
| truly bizarre.
|
| My foodservice days had "if you got time to lean, you got
| time to clean" drilled in to me, but it's not always the same
| in software. What constitutes "clean" may be the core issue.
| sitkack wrote:
| 1) You need to foster a culture where those improvements
| are allowed in
|
| 2) Codify norms of how a shared goal is worked on
|
| 2a) refactor tests as part of separate PR
|
| 2b) realign code with refactoring in mind (this is the
| begin transaction portion)
|
| 3) commit work
|
| 4) merge everything into main
|
| It might take 3x longer, but it is more controlled.
|
| The larger the team, or the more consumers, the more
| important it is to get the interfaces right. And if you can
| refactor the interface ahead of the code itself, the
| refactor isn't even noticed.
| YZF wrote:
| It depends on the team/company. I've worked on many
| teams/companies where:
|
| - Developers were encouraged to put in time to maintain and
| refactor code. (including forcing them to take time to focus on
| that and do nothing else)
|
| - Engineering-centric work was prioritized over random product
| management asks.
|
| - Schedules were adjusted to make sure the engineering work is
| done properly.
|
| I'd say this was my typical experience, including S&P-500
| multi-billion dollar companies, 100M-$1B companies, startups. I
| would also say that in all these cases there were experienced
| software engineers and managers that could be trusted to make
| reasonable tradeoffs and also pay attention to business needs.
| Often engineers interacted/worked directly with customers.
|
| There has to be balance and that balance is typically achieved
| through people that can apply a balance. Striving for "perfect"
| can lead to never ending refactoring and never shipping.
| Ignoring technical debt or shipping garbage can lead to the
| collapse of the business over time. Neither of these extremes
| are the right thing. Where exactly you land on that spectrum
| also depends on the specific product, industry, customers,
| business.
| npsimons wrote:
| To play Devil's advocate, I'd like to point out that many of
| these egotistical assholes are "trying" to "help" - by "trying" I
| mean their communication skills are poor, and by "help" I mean
| they are trying to encourage people to improve. I know, I've been
| one of these assholes. What I've tried to do to be less of an
| asshole is leverage my empathy and hone my communication skills.
| But I also recognize the anger and frustration with things that
| seem like they should be no-brainers - and recognize that what we
| despise in ourselves is often what we attack others for.
|
| Nobody's perfect, but there are ways people can get better. Or
| just take advantage of tools that can help automatically catch
| these sorts of errors. This is precisely why people create
| regression tests and set them up to run in the CI/CD, to reject
| changes that break them.
|
| As for being less of an asshole, no shortcuts with that - just
| exercise your empathy, put yourself in their shoes, take a deep
| breath, then go to bed. Tomorrow morning, if you still feel the
| need to pen a blog post, maybe write out a technical solution
| without assigning blame.
| OliverJones wrote:
| Dang, Rachel, you must have had a rough day at the orifice that
| day. Condolences.
| isaacremuant wrote:
| Weird post. Sounds like a tweet. Says little and the title seems
| clickbait because it doesn't reflect what it says.
___________________________________________________________________
(page generated 2024-05-25 23:02 UTC)