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.
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 😂😂😂
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.
- JumpDeleted
Permanently Deleted
If you're trying to build a company then stop using Blazor, and start using react/vue...etc for your frontend and make an Asp.Net API.
If you need a web app, then use well known technology to do it. Otherwise you're just playing in the sandbox, not building something that can be built quickly, and can be easily onboarded to.
So many C# devs are scared of FE tech, learning how to use it effectively will only make your work better, and speedier.
Essentially, use boring technologies and be pragmatic.
Kind of sucks that the source is locked away...
Would be a lot more convenient to read it when I don't have the whereabouts to watch a video about it(env, data...etc).
Edit: Finally was able to get the whole thing to load, commented on my thoughts.
If it helps, I've been a visual studio user for the last 9 years.
In order to better support non-C# devs onboarding to C# (who where mostly on Mac, and vs for Mac is terrible) I switched to Rider 6 months ago, so we are using the same IDE and I can help them out.
Holy crap, it's good. There are a few things that aren't quite as nice (no more intellicode, stack traces are kinda shitty), but after fixing some garbage default settings, it's turned into a pretty good IDE.
The visual studio debugger is still better though.
- JumpDeleted
Permanently Deleted
Kind of a weird point to try and make no?