_t0du

Is the prostitution on their resume?

What if the job they were "just" doing exists in a legal grey area? Or, more realistically, is flatout illegal?

Live in a tech hub, get a good recruiter, say yes to everything. 60 is probably extreme, and a good recruiter would probably actually turn you down for this type of behavior, but it's def possible.

No, we're all pretty average people. Mediocre colleges with mediocre degrees and mediocre working histories.

It's less me, and more the experience of myself, my close friends and professional colleagues. But as with everything, I would assume it's a mix of both.

I have less than 20 years experience (less than 10 even) and I have gotten/seen a bunch of offers/jobs/etc with remote-only or remote-first over 100k

First company: My manager met with me once over two years. It was 18 months into my just over two years stay, and all she told me was "We don't know eachother at all so I can't really judge your performance." She gave me the standard 7% and we never spoke again.

Second company: It was a huge joke. The CTO invented KPIs that were unattainable and didn't matter, and we were given raises purely because our contract was profitable.

Third company: We had such a ridiculous process of "Write three goals and go over them with your manager", which turned into "Just write anything so HR doesn't complain." The goals were totally useless. Engineers did not have the ability to decide what they worked on or how it went, but the goals implied they did. It was awful and, luckily, did not effect bonus targets.

I honestly think that "performance management" at most companies is a huge joke. I haven't seen it, and none of my peers have seen it, run successfully or be taken seriously. Companies want to pretend they care about your career trajectory and goals only until an employees goals require any legitimate effort from the company's side. The goals/KPIs are pretty much only successful if an employee sets those goals to be "Do whatever their manager thinks they should do", which I would argue isn't a goal at all.

Because it's ridiculous to decide that the bottom of the decision graph should be held responsible for the poor decisions made from above.

Engineers should only be held accountable for decisions they made personally. The unfortunate reality is that, a terrifying amount of the time, terrible decisions are handed to engineering teams as required implementation details from managers, executives, product directors, etc. So should engineers be held criminally accountable for their product manager demanding MD5 hashes on passwords?

"Everyone" in this post is being defined as "Everyone in my extremely small tech bubble"

I've often found that an internal function might have a parameter that goes unused in any of the external tests,

It seems that you're still thinking about "code". What if you thought about "functionality"? If an external test doesn't test internal functionality, what is it testing?

But sometimes it's just too difficult to set up an external test to guarantee that a deep-down race condition gets triggered in a certain way, but you can test that explicitly internally.

I would argue that if you're choosing an orders of magnitude worse testing strategy because it's easier, your intent is not to actually test the validity of your system.

while internal tests can capture much of that.

We can agree to disagree.

And if your test suite takes 3 hours to run, there are many types of organizational solutions for that... but this is the first I've everd heard of "write less tests" being one of them.

I was speaking about a real scenario that features a lot of the topics that you're describing. My point was not that it was good, my point was that testing dogmatism is very real and has very real costs. To describe writing/running lots of (usually unnecessary) tests as "cheap" is a big red flag.

I'm not sure why you feel the need to say this, as the purpose of my post wasn't to challenge any of the other assertions in this thread - rather to provide more information.

I'm not going to debate you because there isn't a debate.

I had a therapist a while ago that spent a lot of time talking with me about how discipline and motivation aren't real. His point was that lots of people lose before they start by feeling like they aren't disciplined or motivated people inherently. And ultimately, the only way to measure motivation or discipline is to measure something else - "I was motivated to stay fit because I went to the gym"

He also spent a lot of time with me on understanding that motivation and discipline are most times just thin wrappers around what people actually want. Thinking less about "If I were just more disciplined I would be able to do this" and more about "If I actually wanted to do this I probably would", and then focusing on what you actually want, or why you don't want something, is probably a much more valuable of a use of time for some people than thinking about motivation or discipline.

I am not posting this to say "If you're a disciplined person, you're wrong" - but moreso "If you're a person that believes you struggle with motivation/discipline, maybe you can rethink those concepts".

One thing I've found throughout my career is having Senior in your title is sometimes totally unrelated to your ability to write code or design solutions.

Thanks, I could've explained better, but that is exactly my point.

The most fulfilling area I've ever worked was with wind turbines. Making software for things that actually mattered, as opposed to dumbass ad tech for ad tech's sake, was very enriching for me.

With respect to algorithms - nobody starts out good with them (except Knuth), it takes practice. Don't give up. Also recognize Leetcode for what it is - practice. It's okay to do a problem poorly/not figure something out. It doesn't actually determine anything about your intelligence or trajectory in the field.

CS is less about coding and more about thinking analytically about coding. I started coding at 11, but some of my college classes were still pretty difficult. I wouldn't assume your classes will be a cakewalk - definitely put the time into studying your material even if you think it's easy.

With respect to getting a job - I would think about programming as a tool. What industry do you want to use that tool on? I would think long and hard about that and consider double majoring/minoring in that new thing. Physics, math, business, whatever. Computer Science + some area of study where you can use CS for the betterment of an industry (outside of CS) will leave you in the best position to do well.

I would also suggest really focusing on Data Structures/Algorithms. Worst case, you'll be good at whiteboard interviews and can get a job at a FAANG company.

Network, hard. Your professors probably know lots of people, and your classmates (in your major) will go on to get jobs you might be interested in. Develop connections with the people around you, and become a person they want to work with in the future.

Above all, don't waste your college time. Actually give a shit about what you're learning. Try new things, make mistakes, have fun, but also work hard on your degree.

I'll be working on moving to Vancouver, BC in the next few years. Small house not near people. I'd like to heavily customize the interior - a thing that I don't do while I don't own.

My question isn't whether you can test enough to catch all bugs. My question is whether time spent wrangling types gets you more value than time spent writing tests.

Yes, by a tremendous amount, in my experience.

Are they? How so?

Tests are only as good as the person writing them. I could see a model working where the person that wrote the code isn't the person that writes the test, but that's definitely not how most development orgs work. If a dev is good enough/capable of writing comprehensive enough tests to accurately test the correctness of their code, that's great, but almost none are (I say almost because I actually mean "actually none" but am leaving room for my own error). If you're an average dev, you'll write average tests (neither of these are insults), but that means you still won't catch everything (by a lot).

I think another comment of yours on my posts actually summarizes the core disconnect between your thinking and mine.

But in the vast majority of modern software, it mostly just matters that you catch and fix bugs quickly--whether you catch those bugs at compile time or runtime is usually not as critical.

I couldn't possibly disagree more with this statement.

Yeah. You formulated my opinion much more elegantly than I could've - in my experience it's always the "Well if the tests didn't catch this, we just aren't testing enough." Which in my experience is a losing strategy, you'll never test "enough" in languages like Ruby.

In my experience this idea always brings a strawman, "Well in statically typed languages you still have to test", which is obviously true. But the type of tests and the content of the tests is very different.

My personal real life experience with Ruby developers disagrees with you, but I accept that I could just have experienced a set of developers that weren't very good at testing.

I see that language parroted all the time - "With thorough enough testing a dynamic language shouldn't be a problem", and I have never understood it. Arguing to build what is essentially a build-time type checker in the form of automated tests seems twice as cumbersome for half the benefit. Instead of building tests that check each branch of a program's types, why not use a language that forbids dynamic typing? You should still have tests, but IMO tests that are just checking that a string is a string are A.) Time consuming, and B.) largely useless beyond type validation.

I am not an expert, but 75k seems disproportionate from the effort and time the requirements seem to be looking for. For the lofty goal of "Fix the internet", 75k seems more like "An extra few weeks of runway." What am I missing?

Daily standups are not a solution to people not caring about what their peers are doing, is my point. You can't make people care, even if you make them show up.

In my experience, async standups mean everyone posts their status and does not read any other status.

Counterpoint: In my experience, at synchronous standups, people totally ignore everyone until its their time to speak, and then share an update, and then go back to not listening.

Because lots of people are still using it. In Q1 2020 they 89m in revenue, up from 50m in Q1 2019. Just because something is bad technically doesn't mean people will immediately abandon it. See: php.

Lemme check with my higher ups, but I think so? We would use this functionality a lot.

I have desperately avoided K8s since it became popular, but this seems to be pretty opposite of everything else I've read? Can you share what specifically makes plain docker so terrible?

I encountered _so many_ "I was a teacher and I wanted a new career" types that quit their jobs and moved in with parents/family/friends to attend bootcamps, only to find that they actually hated programming, and afterwards couldn't find a job and had to return to their original industry.

Of course, the schools don't care, they make their money either way.

Caps are way more common, but every monday morning the front stoop at my old office would have a handful of used needles on it. I suppose the hyperbole would be implying "hundreds" of dirty needles all in one place. When I walk to work, I see many, but rarely are there more than 2-3 in one spot.

I think we're very similar. I've been pretty successful in my life (I'm only 29 so there's plenty of time for critical failure), but the way I observe the value that I add to my workplace and peers is totally different from what I see others doing. I know that I'm smart, that I'm creative, and that I can solve complex problems. I struggle with a lot of "basic" things, like reading a whole paragraph before diving into solving a (the wrong) problem, or speaking so fast I mix up or jam words together.

I also have just a crippling fear of failure, so bad that I just never do anything that really tests my abilities. I failed an Amazon interview 10 years ago and I can't bring myself to give a fair shot to most tech companies.

It's also rough knowing as I type these words on this website that they may come back to haunt me, but I suppose in this moment I'm willing to commit to being honest.