It's not game changing because someone else tried to do this and failed
Kind of a weird point to try and make no?
It's not game changing because someone else tried to do this and failed
Kind of a weird point to try and make no?
I think you can have a well tended garden without giving up creativity.
You're not sacrificing creativity by practicing structures, considerations, and methodologies that maintain or improve the developer experience with whatever creative endeavor you're on.
The structure of your garden doesn't prevent you from playing around with new plants, it just outlines a set of patterns and expectations known to drive better outcomes.
I'm not saying that your extension of the analogy is bad I'm just disagreeing with some of the premise.
Pretty much.
For instance focusing on PR size. PR size may be a side effect of the maturity of the product, the type of work being performed, the complexity or lack thereof of the real world space their problems touch, and in the methodologies habits and practices of the team.
Just looking at PR size or really any other single dimensional KPI lead you to lose the nuance that was driving the productivity in the first place.
Honestly in my experience high productivity comes from a high level of unity in how the team thinks, approaches problems, and how diligent they are about their decisions. And isn't necessarily something that's strictly learned, it can be about getting the right people together.
That's not a licence thing, it's a privacy & security thing. Whos APIs are they using? What are their agreements with them? What leaks, what doesn't? Where is our code & context being sent to....etc
There is a lot more there that should be announced with it. Otherwise it's a hard no from security focused orgs unless they have this posted, in detail, somewhere, and it's favorable.
Edit: Looks like they just post who the providers are, and it's OpenAI. So that's gonna be a no unless we can bring our own APIs, since we have Azure GPT-3.5 & 4 access that meets opsec standards.
This is the kinda stuff I expect to find in this kind of community! ADRs are a good topic that can help teams act more mature.
And less general career questions and low-level "what technology should I learn" 🤔
How difficult would you expect it to be to go back and produce ADRs for significant decisions in the past that resulted in the current architecture and structure of a small-medium sized project?
Hard agree.
Less code is not a positive metric to measure your implementation by, and is not a valid premise to justify itself. Often increasing the complexity (again, LOC is not an indicator of complexity), tanking performance, and harming the debugging experience is a common result of the mentality. Things that make software worse.
Not all one-liners are bad ofc, that's not the argument I'm making. It's about the mentality that less code is more good, where poor decisions are made on a flawed premise.
That single line of code may be using a slow abstraction, doesn't cover edge cases, has no caching of reused values, has no optimization for the common path, or any other number of issues. Thus being slower, fragile, or sometimes not even solving the problem it's meant to solve.
More often than not performance and robustness comes at a significant increase to the amount of code you have to write in high level languages... Performance optimizations especially.
A high performance parser I was involved in writing was nearly 60x the amount of code (~12k LOC) of the lowest LOC solution you could make (~200LOC), but also several orders of magnitude faster. It also covered more edge cases, and could short circuit to more optimal paths during parsing, increasing the performance for common use cases which had optimized code written just for them.
More lines of code = slower
It doesn't. This is a fundamental misunderstanding of software engineering and is flawed in almost every way. To the point of it being an armchair statement. Often this is even objectively provable...
each line of code is a millisecond round their neck
My man here thinking performance optimizations= fewer lines of code 😂😂😂
Yep, saw it one day before I had to have surgery, went into it and it gave me a couple day timer before it will vanish. So it timed out and I wasn't able to play around with it.
Oh definitely. I have some gripes with C# as a language that I wish for better. But it's extremely flexible.
If you do this enough you know how to design your solutions to be relatively flexible. At least for your backends.
Your frontend will always churn, that's the nature of the job.