[-] douglasg14b@programming.dev 1 points 11 months ago* (last edited 11 months ago)

Doesn't appear to show any charts on Chrome for mobile...

Seems to be a responsiveness issue, because it goes away in landscape mode, and the charts show.

[-] douglasg14b@programming.dev 1 points 1 year ago

Holy shit that's completely wrong.

It's for sure AI generated articles. Time to block softonic.

[-] douglasg14b@programming.dev 1 points 1 year ago

I have a weird knack for reverse engineering, and reverse engineering stuff I've written 7-10 years ago is even easier!

I tend to be able to find w/e snippet I'm looking for fast enough that I can't be assed to do it right yet ๐Ÿ˜†

[-] douglasg14b@programming.dev 1 points 2 years ago* (last edited 2 years ago)

The follow on. Lots and LOTS of unrelated changes can be a symptom of an immature codebase/product, simply a new endeavor.

If it's a greenfield project, in order to move fast you don't want to gold plate or over predictive future. This often means you run into misc design blockers constantly. Which often necessitate refactors & improvements along the way. Depending on the team this can be broken out into the refactor, then the feature, and reviewed back-to-back. This does have it's downsides though, as the scope of the design may become obfuscated and may lead to ineffective code review.

Ofc mature codebases don't often suffer from the same issues, and most of the foundational problems are solved. And patterns have been well established.

/ramble

[-] douglasg14b@programming.dev 1 points 2 years ago* (last edited 2 years ago)

There is no context here though?

If this is a breaking change to a major upgrade path, like a major base UI lib change, then it might not be possible to be broken down into pieces without tripping or quadrupling the work (which likely took a few folks all month to achieve already).

I remember in a previous job migrating from Vue 1 to Vue 2. And upgrading to an entirely new UI library. It required partial code freezes, and we figured it had to be done in 1 big push. It was only 3 of us doing it while the rest of the team kept up on maintenance & feature work.

The PR was something like 38k loc, of actual UI code, excluding package/lock files. It took the team an entire dedicated week and a half to review, piece by piece. We chewet through hundreds of comments during that time. It worked out really well, everyone was happy, the timelines where even met early.

The same thing happened when migrating an asp.net .Net Framework 4.x codebase to .Net Core 3.1. we figured that bundling in major refactors during the process to get the biggest bang for our buck was the best move. It was some light like 18k loc. Which also worked out similarly well in the end .

Things like this happen, not that infrequently depending on the org, and they work out just fine as long as you have a competent and well organized team who can maintain a course for more than a few weeks.

[-] douglasg14b@programming.dev 1 points 2 years ago

Someone who shares their experiences gained from writing real world software, with introspection into the dynamics & struggles involved?

Your age (or mostly career progression, which is correlated) may actually be a reason you have no interest in this.

[-] douglasg14b@programming.dev 1 points 2 years ago

each line of code is a millisecond round their neck

My man here thinking performance optimizations= fewer lines of code ๐Ÿ˜‚๐Ÿ˜‚๐Ÿ˜‚

[-] douglasg14b@programming.dev 1 points 2 years ago* (last edited 2 years ago)

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.

[-] douglasg14b@programming.dev 1 points 2 years ago

Well, let's start with which ones you have looked at, and why they aren't to your liking.

[-] douglasg14b@programming.dev 1 points 2 years ago* (last edited 2 years ago)

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.

[-] douglasg14b@programming.dev 1 points 2 years ago

A codebase is different than the language itself enabling many ways to do the thing.

You may not think it's likely to cause problems, but have you actually onboarded non c# devs onto new C# projects?

I have been for the last 6 months and let me tell you it really opened my eyes to new problems. One of those is that there are many ways to do the same thing, which has been a consistent pain point for non-c# devs, and has been hurting adoption and general sentiment.

Honestly I didn't think much of it till now, and didn't think it would be that big of a deal. Turns out it is.

[-] douglasg14b@programming.dev 1 points 2 years ago

To be fair it's not a good comparison to compare an IC role against a management role for time breakdown.

view more: โ€น prev next โ€บ

douglasg14b

joined 2 years ago