351–360 of 374 posts
20% meetings is two story points per 2 week sprint. I hope you have a recurring task for this. I do this and does it go down like a lead balloon with project managers.
Why not skip the recurring ticket and reduce your sprint capacity by 2?
Earlier quoted context omitted.
I fundamentally disagree with the notion that design and discussion, of often very detailed technical aspects, is "non-technical work" of any kind, or that sitting down and writing code is the only "technical work".
Doing design and discussion without writing code just feels like deliberately hampering yourself. Code is the best language we have for describing things unambiguously! Weeks of plain-English discussion can save you hours of prototyping.
Just this week I witnessed some team having built feature without consulting another critical team, and now it has to be reworked and shipped at a much later date.
Earlier quoted context omitted.
I’m sorry but this is complete nonsense; there is no pleasure derived from viewing “beautiful” code from the perspective of the consumer such as in your other examples. A program is not like a car, a chair, or a house, and if any of this were brought up in a design meeting for code, you’d rightfully be laughed out of the meeting. But it’s fine to disagree about these things up to the moment where you attempt to slow…
>I’m sorry but this is complete nonsense; there is no pleasure derived from viewing “beautiful” code from the perspective of the consumer such as in your other examples. You're taking it too literally. "viewing" in the case of software is "using". When I'm using a well designed, performant piece of software I can feel the art in it. When I'm using something thrown together I can feel that too.
However what we're discussing here is how the code and otherwise hidden implementation is designed and built. OP is not a UX designer, OP is a software engineer, and should not waste time building things that are "beautiful" in that capacity.
UX and systems design are almost entirely unrelated, and should not spend time in one another's domain.
Earlier quoted context omitted.
So you've listed houses, cars, watches, food. All these things indeed serve a purpose as well as allow for creativity and expression. But the difference is, all those things have sale values that DIFFER based on that creativity and beauty. Code does not. My customer does not care if my backend code is beautiful, and neither does my CEO because it won't make more money. > Is a dish or menu designed by a chef not art?…
> My customer does not care if my backend code is beautiful Apple can only sustain the high margins they do because you’re wrong. Some people care a great deal. Some of those people have deep pockets. If none of your customers seem to feel that way it’s probably because they are Apple customers. But you also have companies like Anker and at certain points in their history Sony, Samsung and perhaps LG. They got it. At…
Are you suggesting that some people care a great deal about how pretty Apple's code appears, despite having zero way of knowing anything at all about that as a consumer?
Earlier quoted context omitted.
it is when the focus is on having 100% coverage and not on test quality. When 100% becomes the metric it tends to get gamed pretty heavily with tests that have such a huge amount of mocks as to make the tests useless, or doing something to make it hit a branch, but ignoring actually verifying it cause that branch is just a log statement.
I seriously doubt it is actually 100%... let's verify that number.
Earlier quoted context omitted.
The mythical portion of the number is that last 0.02%... the stuff that is just extra work for no logical benefit. It does make me wonder why it would take you hours to do that though... was the code that complicated to test for some reason?
Yes, it was. It used a very obscure language feature of JavaScript. I won't get more detailed than that.
Earlier quoted context omitted.
it is when the focus is on having 100% coverage and not on test quality. When 100% becomes the metric it tends to get gamed pretty heavily with tests that have such a huge amount of mocks as to make the tests useless, or doing something to make it hit a branch, but ignoring actually verifying it cause that branch is just a log statement.
I work closely with the CR-time coverage/enforcement tool. The tool expects 70% new line coverage. The number was chosen arbitrarily, but individual teams/managers can choose to avoid the rule or set a different threshold. It's not ridiculous to expect some, *configurable*, amount of test coverage for newly generated code, is it?
Earlier quoted context omitted.
> I just rewrite everything I possibly can in Rust and I've yet to regret it. And hopefully no one else regrets it...
By then you're onto the next thing and it's their problem, right? Thus is the circle of (engineering) life. Just kidding. Please write maintainable code.
Most people don't know how to do this, because it's actually hard, and I don't think it's being taught much in programmer education.
I certainly had to learn "on the job", and probably spent 10 years before I got good at it.
I learned the most by fixing bugs. After a while, I started seeing the patterns of why this bug had occurred, and started writing code do avoid the traps.
Earlier quoted context omitted.
The problem is that he has a big pile of half-working spaghetti code that he never has time to touch except when it malfunctions in the middle of the night The problem behind that is that Amazon is a completely dysfunctional corporate hellscape. Like TFA said, you just don't have time or resources to actually fix things
Also usually it’s in Java in an internal framework based off Springboot and I’m a front-end developer with no experience writing backend services. Totally normal. Not crazy at all. Take ownership.
Earlier quoted context omitted.
Doing design and discussion without writing code just feels like deliberately hampering yourself. Code is the best language we have for describing things unambiguously! Weeks of plain-English discussion can save you hours of prototyping.
That works in mostly self-contained projects. As soon as you interface with other teams, or even hardware that is still in development, you better make sure that everyone is aligned on the critical details before plowing ahead. Otherwise it can get very expensive (in terms of time, money, and motivation) to prototype yourself into a corner. Just this week I witnessed some team having built feature without consulting…
Even then, writing a prototype is often a quicker and more effective way to flush out disagreement than endless discussion.