|
I’m still not convinced that anyone talking about AI in general at this point isn’t a grifter or a rube.
|
#
¿
Apr 9, 2023 16:41
|
|
|
|
| # ¿ May 12, 2024 02:40 |
|
|
Cugel the Clever posted:I certainly don't want to be whiteknighting our corporate overlords, Then don’t
|
|
#
¿
Apr 9, 2023 22:38
|
|
|
Comb Your Beard posted:Getting back into Java. Why create an interface and an Impl class where it's just 1:1 and you don't even implement the interface a second time? Always drove me nuts back in the day, seemed so stupid. Is there a way to get my IDE (VSCode) to go to the actual impl of the method? Getting this on a take home assignment. In spring and other bean-heavy frameworks it’s a lot easier to just @Autowire an interface with a single impl bean registration than it is to instantiate and pass around instances of the impl.
|
|
#
¿
Apr 19, 2023 14:28
|
|
|
We have that distinction too although some leads do have reports. Lead/manager is this fuzzy area where you determine whether you want to move to staff+ or management. It’s not uncommon for folks to try out management and decide they’d rather be on the IC track.
|
|
#
¿
May 17, 2023 22:05
|
|
|
Love Stole the Day posted:Isn't this way of thinking is the entire reason why knowledge silos and poor confidence in Production deploys occur in the first place? Reducing the risk of a bad deploy affecting revenue or reputation is not as compelling a motivation as the chance of a new Product feature's soft launch going well. Unfortunately that has to be born out in the sales cycle or the development process for it to affect change. If you can identify areas of a codebase whose improvement will lead to faster feature delivery that’s a compelling argument to make to product to ensure it’s addressed. Similarly if there’s a defect or quality issues in a codebase that’s affecting sales or renewal then product is incentivized to hopefully want to address those problems. But, at the end of the day, in an organization of sufficient size, you don’t hold the decision making power of whether to address these concerns. The best you can do is make the argument. Stealth edit: it’s worth noting that engineer attrition is a lever you can pull in terms of incentives for product to want to do something about quality as well.
|
|
#
¿
Jun 24, 2023 16:42
|
|
|
I don’t think the principle here is inherently wrong but the statement that the “more talented and effective IT engineers are the ones most likely to leave” is pretty much the definition of confirmation bias. Just because a person is less comfortable with trying to affect organizational change doesn’t mean they’re talented and effective, it only means they have less tolerance for a certain type of work; and that’s ok! It also means that the contrapositive is also ok and fits a certain type of personality irrespective of talent or effectiveness.
|
|
#
¿
Jun 25, 2023 16:14
|
|
|
ultrafilter posted:It's definitely true that more talented people have better options for leaving This yes quote:and that correlates to some degree with them exercising those options. This unfounded It presupposes that talent is incompatible with focusing your career on affecting organizational change and kind of comes back to the "there's only one right way to be an engineer" attitude that's imo pretty rife in the industry.
|
|
#
¿
Jun 25, 2023 16:58
|
|
|
StumblyWumbly posted:Sure, but managers are responsible for making sure other people do good work, and IC literally stands for Individual Contributor The higher up you get the more your contributions are focused around enabling your teams to do high quality work. It’s very similar to management in a lot of ways except without the hiring/firing/development/etc.
|
|
#
¿
Jul 19, 2023 12:26
|
|
|
Making the actual product is easy mode compared to getting a group of people (or a group of groups of people, etc) to work well together and build products.
|
|
#
¿
Jul 19, 2023 13:20
|
|
|
Achmed Jones posted:it is not appropriate to interview people based on vibes. you certainly have the best intentions, but that's how people end up hiring folks just like themselves. interviews need to have clear success criteria that can be met or failed. I'd love to see how orgs do a rubric for non-technical skills. Those are the places I always worry about and beyond having a script of questions with expected answers and having multiple rounds where interviewers use the same question bank I can't think of a good way to evaluate a candidate that's not somewhat based on vibes.
|
|
#
¿
Aug 4, 2023 13:42
|
|
|
wilderthanmild posted:Curious of the broader experience with on call because I loving hate on call/pager duty/etc. 1. Yes, in every team I've been on we've all carried the pager. On my current team we have an escalation system where ICs and team managers are tier 1, senior managers are tier 2, and the product director is tier 3. Past teams have had a similar setup. 2. 1 week primary, 1 week secondary. Our rotation is comprised of all the teams in our product area so on-call is usually the 2 weeks every 5-6 months or so. I just checked PagerDuty and my last primary shift was August 2nd - August 29th and my next one is scheduled for February 14th to February 21st. 3. Handle pages, triage alerts, etc. We used to do a system where secondary would handle internal escalations but it just ended up being a "bug the secondary for tech support rather than reading the docs" so we moved that escalation process through product management and low and behold the number of requests dried up overnight. 4. Lately it's been worse for on-call folks because of issues mentioned in this thread. A lot of acking pages and waiting for error rates to fall without actually solving for the issue. We've got a persistent page around DB load during a particular release type where the resolution would be to tune a worker pool but lol no one seems to care. We also have a DB that's reaching txid wraparound that requires some auto-vacuum tuning but no one cares to fix it. It's maddening to me but not my horse, not my rodeo until I'm on call in which case I'll fix it. 5. Lol I wish.
|
|
#
¿
Nov 3, 2023 14:26
|
|
|
thotsky posted:Unless you're looking to work on legacy systems I would just go with Kotlin if entering the Java world now. Learning Kotlin without Java is like learning TypeScript without JavaScript which is to say that if you're just building fart apps you might be ok but the second you need to understand what the language is doing under the covers you're utterly hosed.
|
|
#
¿
Jan 1, 2024 23:35
|
|
|
There are absolutely startups using Spring Cloud/Spring Boot/Dropwizard
|
|
#
¿
Jan 2, 2024 00:59
|
|
|
|
| # ¿ May 12, 2024 02:40 |
|
|
Mao Zedong Thot posted:Anyone that's telling you there are general rules like '30k TPS and latency > 100ms == lambdas' is a "thought leader" and should probably be ignored
|
|
#
¿
Feb 19, 2024 00:33
|
|