291–300 of 327 posts
I think the only difference is we state that if feel the urge to write comment, write an [equivalent] log statement instead, so then we can use it in production for failure tracing.
Earlier quoted context omitted.
You test the test by mutating the code. Once you have 100% condition/decision branch coverage you can automatically sweep the code with changes and the tests will fail. I have a little harness I use for this steps through each non-comment line of code changes signs, comparison directions, offsets values, swaps variables, adds negations, replaces computations with constants, etc. basically changes that are more or les…
Interesting approach. I hadn't considered actually implementing such "brute force" methods. I guess it's similar to fuzzing. I think the problem is you are then moving your "real" condition/decision branch documentation into your tests. The tests are then basically a guard rail for just in case someone modifies some abstract bit of code and it changes the behaviour of some otherwise opaque decision branch. The approa…
Earlier quoted context omitted.
There are just very few applications that actually need all of this. maybe 1 tot 0.1%, for instance vercel might need it. But 95-99% can just run on several "simple" servers & keep deployment times within minutes and no complicated stuff needed. Yet Kubernetes get's pushed all the time.
I don't know about that, I've found even simple applications need things like blue/green deployments and kubernetes makes that very easy and robust.
There are many ways to solve the up/down issue and depends on which language you are running.
Earlier quoted context omitted.
I don't know about that, I've found even simple applications need things like blue/green deployments and kubernetes makes that very easy and robust.
there is nothing easy or robust about kubernetes. Hence all the tooling around it, having things break down if you don't update. Dependencies not being compatible all the time. Server management should cost as little time, and be stress free. There are many ways to solve the up/down issue and depends on which language you are running.
Earlier quoted context omitted.
Same for me in the Scala vs. Java world, it's hard once you get used to how awesome expressions over statements and algebraic data types/case enums/"discriminated unions" are. But I haven't done much C# (yet) myself, could you clarify for me: does C# have discriminated unions? I didn't think the language supported that (only F# has them)?
The c# team is working on a version of them they are calling Typed Unions, not guaranteed yet but there is an official proposal that I believe is 2 weeks old. https://github.com/dotnet/csharplang/blob/main/proposals/Typ...
Earlier quoted context omitted.
> The space shuttle became obsolete technology after all those years. Would've needed a redesign. Are people aware of how old the technology is that's currently putting objects and people into space? No, the space shuttle was not obsolete. It was expensive... very expensive. To this day, we still don't have a replacement for it's capabilities though.
Dream Chaser wants to fill those shoes. - https://www.sierraspace.com/dream-chaser-spaceplane/ - https://en.wikipedia.org/wiki/Dream_Chaser - https://www.nbcmiami.com/news/local/a-new-space-plane-gets-r... - https://www.youtube.com/watch?v=jVIXI09-AYw - https://www.youtube.com/watch?v=4Q8tGVUnoZg
Earlier quoted context omitted.
Agreed. Explicitness and comments are very useful in understanding the intended functionality and logic, whether or not the code actually implements that intent correctly (an in providing that intent, they can help identify bugs earlier than they would be identified otherwise).
But comments go out of date, and the compiler doesn’t check them against the implementation. To document + enforce the intended functionality, use tests.
Tests go out of date
Tests increase the maintainince burden
The compiler does not ensure code is tested
Tests get duplicated
Mēh! Tests matter, and testing is very important. Good judgment is required
Just like comments.
Writing code requires professional care at every step. The compiler helps of course see, but being professional is more than writing code that compiles
It involves documents too. And tests. Not too many (tests or documents) but not too few
Undocumented code is an enormous burden to maintain (I am eyebrows deep in such a project now). It is not enough to just write code and tests, documents including inline comments, are crucial
Earlier quoted context omitted.
> This made the SRR people angry because they were finding fewer bugs and felt the development team was focusing on competition over bug numbers rather than the code itself. This reminds me of the Quality culture, at my last job, which was a famous Japanese optical corporation. It was deliberately set up, so there was an adversarial relationship between QA, and Development, with QA holding the aces. As a Development…
Reasons why I might not think twice when buying anything built in Japan. I know they care about quality. I rather it be built right, than quickly. I wish we held quality to higher standards in the software industry.
We share a wish.
Earlier quoted context omitted.
Every time some code reviewer comes into my PR and says something along the lines of "you know you can just write it this way" where "this way" means obfuscating the code because "clever" and "shorter," I die a little on the inside. This is from experienced devs who should know better. At one point I wrote a comment write above a section I knew would be targeted by this kind of thinking explaining it must be written…
I’m not a dev, but I manage them. On one team they were spending many hours on code golf and nothing was being built. I pushed the devs to passing testing=PR accepted. In your opinion, what problems might come from removing opinionated code reviews? Why do some reviewers gravitate toward “Here’s how I would have written it?”
But it could be that your team was just divided on approach and style.
They were struggling because they were trying to work out their differences through PR comments. That will be frustrating for everyone. Somebody went and got the PR working "the other way," and now the reviewer is trying to get the author to change the PR to "their way". If it goes on long enough, your devs will head for "the highway"...
If you just mandate "test pass = pr accepted," it will unblock your team short term, but in the long term, the large system will gravitate into many tiny, fiercely defended fiefs, each with different styles. Maintenance will be slow. Debugging will be complex. Wide-reaching refactors will be prone to blockage.
Fix the coding by having the team spend time "not coding." Establish a proposal and design process where an author needs to get team buy-in before they can implement. Establish an accepted standard on coding style. Do wide reviews on critical features and highlight issues where flow needs to go from one end of the system to the other and there are weird boundaries. Do the RCA (root cause analysis) and ask the "five whys". Look for patterns of issues and address them soon rather than pushing them to the back of the backlog. Prefer many small incremental changes over few large changes.
Earlier quoted context omitted.
But comments go out of date, and the compiler doesn’t check them against the implementation. To document + enforce the intended functionality, use tests.
Outdated comments are great, because it means you probably have a bug right there. If the comment didn't get updated, the code change probably didn't look at all the context and missed things. Pretty sure I'm guilty of that pretty often.