sugar_in_your_tea @ sugar_in_your_tea @sh.itjust.works

Mama told me not to come.

---

Read more

Posts

9

Comments

14,035

Joined

2 yr. ago

Idk, their population is pretty brain rotted...

That, and doing all they can to eliminate romance in their population. I wouldn't be surprised if they had the highest incel rate per capita in the world.

A few dozen people don't make a product viable, tens or hundreds of thousands (if not millions) of people do.

It's a natural byproduct though. Assuming a free enough market, you should have several people all supplying the same good. Some will compete on price, some on quality, and some on overall service.

The problems happen when competition evaporates, either from regulations raising the barrier to entry, acquisitions, or resource scarcity. Capitalism assumes people are greedy and pits them against each other to provide better services to everyone. A lack of competition isn't "capitalism functioning as intended," but instead the opposite, it means something is preventing capitalism from working as intended.

Well, it does cost less and less every year. I bought two 8TB drives for $300 each or so, and today a 24TB drive is about that much.

And they do have more Seagate failures than other brands, but that's because they have more Seagates than other brands. Seagate is generally pretty good value for the money.

Honestly, when I first got into forums, I thought they were literally talking about Linux distros, because at the time, that's literally all I was seeding since that's what I was into.

bstix's mom, has got it going on.

I bought 8TB for something like $300. 36TB seems quite attractive.

And those candidates are usually trash, especially in a company like mine where there are maybe a few dozen software roles and many hundreds of other roles. They just don't know how to recruit devs, they usually recruit marketing or domain specific people.

I know what a Smith's chart is, but I never needed to actually use one. I'm a software guy who knows some random details about RF, and that sometimes helps with random things like identifying issues with WiFi or whatever.

I see no problem in people buying what they want over what they need.

Neither do I, I just don't like it when people excuse their choices by using terms like "need." People make a lot of silly choices because they claim to "need" something.

I just want people to be more honest with themselves and others about needs vs wants. If we classify things properly, I think people will naturally be more efficient with their resources and we'd have less consumer debt and whatnot.

I guess my point is that it's harder to suss out the actually competent people if they're able to build a good portfolio using tools. AI makes this harder, since they can sound more competent than they are, and them a few months down the line we need to discuss them leaving the org.

Exactly! If you know enough foundational principles, you can quickly rule things out and develop ways to narrow down what remains. If you rely too much on diagnostic tools, you'll miss out when the tools fail to catch something odd.

I'm a software engineer and we had a problem where our corporate laptop wouldn't allow us to install our dev tools (needed to debug a windows specific integration and we dev on macos). Instead of waiting a week for IT to come fix it, I realized we just needed it to look like a service was running locally, and we had ssh through the git bash shell, so I set up an SSH tunnel between the windows system and the dev machine and they were able to keep working while waiting for IT to get time to help us. We rarely use SSH at work, but I understand enough about how networks and sockets work so I was able to quickly help them solve the problem.

You don't get that type of intuition if you don't understand how the underlying tech works, and that's true regardless of your field.

Yup, look for "user agent switcher." This isn't something you should try to DIY in the settings, because user agents are complex and a small deviation can mean looking like Chrome or being unintelligible.

I 100% agree.

The best mechanics can track down an issue by reasoning about what could be causing it, and understanding how pistons work can help deduce whether that knocking is actually the engine or something else entirely. They probably didn't learn that from their official training, but instead worked with some guy who used to work at a car manufacturer or something and picked their brain.

The best engineers are curious and jump on opportunities to learn more.

Instead of hiring gurus, I think you want a diverse set of curious "regular" people. Maybe one person is really good with working in different number bases (and 0xD6 in decimal is something they know off the top of their head), another is really good w/ databases, etc. None of those would know everything, but they're all curious and picked up random stuff from their career because they asked a lot of questions.

Hiring the right guru is hard, having the equivalent of a guru across a diverse time is a lot more tractible, and maybe one will become that guru you need after cross pollinating with the team.

I somewhat disagree here, but also somewhat agree.

In my org, we get a lot of requirements that require very different skillsets. For the first 2-3 years, our task list was mostly CRUD stuff with some domain specific logic, but otherwise a boring web app. In the last 1-2 years, we have:

• ported a Fortran simulation to Python
• embedded a C++ simulation in Python
• created a 3D UX for our previously 2D only app (lots of 3D logic on both FE and BE)
• implemented a machine learning algorithm to train our simulations

If I hired only for the work I'd seen in the past, we'd be completely unfit to handle this workload since we'd mostly have people who are really good at building CRUD apps (so DB optimization and quick UX building).

On the flipside, we cut off huge swaths of work so people don't need to wear too many hats. We have:

• dedicated devOPs - handles everything from trst pipelines to prod deployments
• dedicated QA - manual and automated app-level testing - devs still do unit testing
• dedicated product teams who handle feature requirements and documentation
• dedicated UX team to produce designs for FE engineers to implement

So our devs only need to worry about development, but they also need a broad skillset in that domain, from everything from local tooling to working in different domains. We hire a diverse set of candidates, some with a heavy math background, some with design experience, and some with low level programming experience, because we never know what projects we'll get or who will suddenly leave the org.

I disagree. On paper that sounds good, but I firmly believe good engineers are curious, so they'll learn a lot more than necessary to do the job.

For example, when I worked at a company that designed antennas as a software engineer (built something tangentially related), I didn't need to know anything about electrical engineering, but I was curious so I asked a ton of questions and now I know a fair amount about EE. These days I work in a very different domain and still ask a ton of questions to our domain experts. In my own field, I look into all kinds of random things tangentially related to the tools I use. In each case, that curiosity has come in handy at some point or another.

In each role, I can tell who's there to clock in and clock out vs who is genuinely curious and looking to improve, and it's the latter group who tend to produce the best work and go on to great roles after leaving our company, while the 9-5 warriors who just focus on the requirements tend to do pretty mediocre when it comes to advancement.

When I hire, I look for that curiosity because you never know what you'll need to know to fix a prod issue quickly. My esoteric knowledge about SSH helped keep my team productive for a few days when IT was being slow revolving our issue, and likewise we've had quick resolution to prod bugs because someone on the team knew something random that ended up being relevant. That's what I mean when I say I look for a diverse team, I want people with different strengths who all actively seek to improve so we'll have a good shot at handling whatever comes down the pipe (and we get a lot of random stuff, from urgently needing to embed 3D modeling tools into our reporting app to needing to embed complex C++ simulation code or rewrite Fortran code into our largely CRUD Python app).

Most of these cases of "focus on one niche" are often symptoms of lacking curiosity and just wanting to tick boxes to quality for a role. I'd much rather someone miss a few important boxes but tick a lot of random ones because they're curious; they'll take longer to on-board, but they'll likely be more useful long term.

I don't work in the security space, but I think the same applies to most technical fields. Breadth of knowledge in an individual provides depth of knowledge in a team.

Ours is really simple, like something any somewhat competent engineer could complete in half the time we provide after going through the tutorial on the framework's website. Yet so many people fail, even when they claim to have years of experience with the framework.

There are a ton of terrible applicants out there.