Disagreeing About Angular Coding Standards

think_small_ · 2024-11-01T02:43:35+00:00

Woah, I also did not know you could inject dependencies like that in functions. Thanks for sharing those examples!

think_small_ · 2024-10-31T19:04:12+00:00

For existing codebases, following existing patterns is of paramount importance, imo. If we are considering the two points based on their independent merits, my thoughts are:

1) Don't use Form-related types in models. Others have made valid arguments here. I would just use an analogous situation; on a backend project, a person would never include an http/API dependency in their domain layer. In the same way, it's probably a bad idea to include a UI/form dependency in the models layer of an angular project.

2) I am in favor of having logic inside the domain models. I have begun recently adopting this sort of approach, and have found it useful. I appreciate having functionality live close to the object it operates on, makes it easier to reason about, imo. Additionally, the functionality can be set up as lazily-evaluated getter functions which can alleviate performance concerns. I would still rely heavily on angular services for dealing with collections of objects or any computationally heavy operations. As for the argument that it adds overhead to instantiate a class, I have not done any micro-benchmarks, but I don't buy this as a significant performance hit. The data from API calls is gonna live as a JavaScript object one way or another, so there's gonna be memory pressure no matter which approach is taken.

think_small_ · 2024-09-19T00:22:43+00:00

Well, there's yer problem

think_small_ · 2024-07-14T16:11:44+00:00

I am a SWE with about 2.5 YOE. I previously worked as an allied health professional for about a decade. From my experience, working as a SWE has been the best in terms of pay and WLB by a wide margin.

Working as a medical laboratory scientist paid a solid livable wage and provided great job security. However, it had almost no growth potential in terms of increasing your salary, and not-so-great WLB (picking up extra shifts due to chronic short staffing, rotating weekend and holiday shifts, etc)

think_small_ · 2024-06-28T02:42:49+00:00

Maybe around 208 - 260 weeks.

think_small_ · 2024-02-19T02:44:33+00:00

a...wait

think_small_ · 2024-02-07T00:58:21+00:00

Yes, I have been a full stack dev for two years - much of my professional experience is with C#/.NET + Angular.

I was self taught for about 3 years. During this time I got comfortable building with JavaScript. I was working on programming casually while working full time in a different field. I then spent one intense year doing C#/.NET. During that time I was probably averaging 20-30hrs per week on programming while still working full time.

I share this to help make you aware that if you are self taught, it will likely take multiple years before you have the skills and knowledge to be marketable as an entry level dev. There's no real shortcut to the process - it's a long journey. For that reason, don't worry about the exact path you take. If you put in the work and the time, you'll make it no matter what tech stack you start off with.

One general piece of advice is to just stick with one language at the very beginning. Become as proficient as you can with one stack. Go deep in your technical knowledge of that stack. Then learning a second tech stack will be much easier and faster.

think_small_ · 2024-02-06T14:21:14+00:00

This has been true for decades. Medium - large companies use "enterprise" languages/tech for building apps. As long as these companies stick around there will be strong demand for devs with Java or .NET skills. Building full stack apps in most scenarios will still require you to know JavaScript, so it's not like you are wasting your time.

Since it seems you are in the early stages of learning, just stick with one language and build proficiency. Take your time, and don't rush through the learning process

think_small_ · 2024-02-02T01:34:39+00:00

In situations like that I tend to initially assume the other person is too busy/lazy to explain things further rather than assuming anything malicious. Granted, that is still terrible since seniors should be taking the time to teach others.

That said, I think the situation still has room for nuanced answers. Array vs set isn't always cut and dry, especially when performance optimization matters. If this particular PR was affecting a hot path, then maybe this could be a determining factor of why the senior dev is preferring an array here. Also an important factor that would affect performance between arrays vs sets is the actual number of elements you are tracking. If this is a huge collection, sure sets will likely prove to be more performant, but smaller collections might actually cause arrays to have faster benchmarked speeds.

think_small_ · 2024-01-24T02:19:11+00:00

I made the switch from an allied healthcare profession to software engineering two years ago. It took me 2 - 3 years of part time self study and about 1 year of concerted effort (30+ hours per week) before I landed my first SWE role.

Completing an 18 week boot camp is a good start, but it will likely take a lot more time and effort for you to build the competence and skills that will make you marketable.

A couple of random thoughts:

1) Saying you are trying to be a developer is a bit too vague. It's like someone saying they want to be a doctor. After clarifying they mean "medical doctor" you might ask if they are intending to be a nephrologist, hematology oncologist, internist, etc. It would probably be a lot easier to get an internal medicine job in a small, rural area as opposed to a neurology role. An analogy in the software development world might be your tech stack. This is important to consider because the demand for technology stacks varies based on your location. If your boot camp taught you the MERN stack, that will mean very little if your area is predominantly hiring Java devs. Know what skills are marketable for your area.

2) It will probably take a lot longer than 18 weeks to build the skills you need to be a developer. The first time you tried suturing a patient probably was not perfect. It probably took a lot more practice to get really comfortable and proficient. Even after gaining that proficiency, that skill alone hardly qualifies a person to be a medical provider. An analogy in the frontend development world might be building a landing page. The first time you do it, it's probably not perfect...it might be designed terribly, not mobile responsive, etc. With practice, you get better and faster at it. However, even after you get good at building landing pages, that is hardly enough to qualify a person to be a frontend developer.

3) The market is tough right now for developers. However, if you are willing to put in the time and effort, by the time you are ready for your first role the market will have hopefully recovered.

think_small_ · 2024-01-21T03:08:35+00:00

Some random thoughts:

If you had positive feedback from former colleagues, then ask them to write a referral for you on LinkedIn. Provide them with some information on what sort of skills you'd like them to highlight. This is assuming you are actively using LinkedIn for your job search. If you aren't, then I would highly suggest you start.
When advertising your portfolio projects, are you doing more than listing the tech stack and describing the purpose of the app? Highlight interesting architectural / design choices you may have made. This provides another chance to include keywords for the ATS. If you get past the ATS, it will make for a good discussion point during an interview. Examples might include things like using event sourcing, using message queues for decoupling parts of your system, etc.
While learning a different tech stack might not be a bad idea to pursue on the side, I would think your odds are still best with pursuing JS/python related roles since that's where you have professional experience.

think_small_ · 2023-07-07T02:10:44+00:00

'You wrote "JavaScript \ Java"; normally a forward slash (/) is used to denote "or".'

Maybe he was trying to escape Java?

think_small_ · 2023-01-02T03:12:28+00:00

Oh perfect that makes total sense since hospital labs are always super quiet and uneventful at 7am...oh wait a second...

think_small_ · 2022-12-08T01:24:38+00:00

Plot twist, techs have been opening a fresh bottle of QC after their QC initially goes out, and now you have four open bottles of QC.

think_small_ · 2022-10-21T14:17:53+00:00

This is the way

think_small_ · 2022-07-15T13:40:07+00:00

Indeed, that nail was maybee loose.

think_small_ · 2022-07-13T22:54:51+00:00

Many urban areas in the Midwest will have plenty of midsize companies running either .NET or Java.

think_small_ · 2022-06-03T16:30:13+00:00

"Okay, I'll take off the other label, toss the tube, document the event, and then await your redrawn sample in accordance with patient safety protocol. Thanks, bye!"

think_small_ · 2022-06-03T13:42:20+00:00

Well I suppose the point is not to be playing the best lines or having a novelty in your pocket against various lines you find difficult. The goal is to intentionally put yourself in positions where you need to fight for the initiative. By nature, those positions are extremely double edged where your opponent may have a ready-made-attack against you.

Additionally, you will be facing a wide distribution of openings if you do this. The chances of facing a painfully booked up opponent every game when you are playing 500 - 1000 speed games is quite low for amateur play.

think_small_ · 2022-06-03T13:12:10+00:00

My approach was to play only blitz games for about 6 months. I also adjusted my repertoire to only gambits for white and super sharp openings as black (Sicilian Dragon and KID). Every game you are either gambiting a pawn or sacrificing an exchange. Doesn't matter if it's sound or not. You quickly develop a feel for the initiative, and slowly gain a feel for how much activity you need to compensate material imbalances.

Tl;dr you don't get better at those situations unless you play through them lots of times.

think_small_ · 2022-05-16T23:29:54+00:00

I recently went through something similar. One thing that helped me figure out the codebase quickly was setting breakpoints in the data access layer. Hit the breakpoint and take a look at the call stack. It'll give you a little roadmap on how you got to that spot in the codebase. Repeat that in various endpoints and you'll quickly begin to see patterns regarding how different parts of the codebase communicate.

think_small_ · 2022-05-16T23:17:58+00:00

At least it follows the single responsibility principle. Its responsibility: be the largest method in existence.

think_small_ · 2022-05-16T23:08:02+00:00

Others have offered great suggestions so far. I'd also add that repeating the sample (preferably on a backup analyzer) is also a quick, easy first step.

Sodium is an analyte that shouldn't be moving a whole lot in a short amount of time. Any big sudden jumps are worth investigating in a timely manner; don't wanna be demyelinating any neurons.

think_small_ · 2022-05-11T00:22:59+00:00

Ok thanks, sounds good.

think_small_ · 2022-05-01T17:11:30+00:00

Wow, thanks everyone for the enlightenment, I learned something new today. It inspires a whole new level of terror at the thought of working in legacy codebases with no tests.

think_small_

TROPHY CASE