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?
douglasg14b
joined 1 year ago
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 the day before I had to have surgery. 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.
Good up front understanding of your problem space goes a long way. You don't need to waterfall it, but you should at the minimum have a high level view of the problem and your proposed solution(s). With considerations of where the team/domain might go wrong, where we expect to find pain points, and what sort of mitigations should be considered for those.
Your planning will not survive reality, and that's okay. You are already further ahead as a result of some high level consideration than you might otherwise be, and hopefully you have built your software under the assumption that you will be learning and changing as you go.
Human to human interaction is a baseline necessity for any large work for any field TBF. It's also hard failing point full of nuance, and doesn't really have a panacea as humans are the more complex parts of any system.
Software is hard, not treating it as such means devs will build complex systems because they focused too much on "simplicity". Missing the forest for the trees.
You are conflating necessary complexity vs unnecessary complexity. And assuming that all things are the later, without acknowledging that yes there are many applications that must scale, and that most non-trivial applications must deal with real world complexity. Nevermind scaling being a simple example of a complex problem, not a statement about it's necessity...
I would expect devs here to be experienced enough to understand and differentiate those two, as such assuming the worst isn't a good fit and prevents fruitful discussion.
I would suggest you reconsider the premise you are using here, you appear to be here to complain, not to share and learn.
Practice practice practice, always challenge and improve on your foundational skills. Everything else gets easier. Write code and solve problems, struggle through it in whatever way works for you. There's not really a shortcut to getting more experience than to put in the work.
It's especially important to try and do things the "right way" as a learning/growth tool. It will take longer, and you'll rewrite your code multiple times, but the next time you encounter a similar problem you suddenly know exactly what to do and the constraints around the problem.
Do this often enough and you'll find yourself having a general idea of how to solve just about any problem you come across, and how to do it elegantly.
Software has to model the real world, and the real world is complex. Not to mention that software is not a perfect abstraction, you will have to solve hard problems such as scaling.
Software complexity is unavoidable, how you reduce and control the impacts of that complexity is how you build maintainable software.
Are you sure you should be answering questions here?๐ค
Well, let's start with which ones you have looked at, and why they aren't to your liking.
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" ๐ค