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.
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.
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?
> 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".
Selecting a tech stack is 75% about your developers skillsets and 25% about how easy it is to hire for that skillset, IMO. Anything else is just hype.
HEY picked their stack because their founder is literally the creator of Rails, so obviously they're going to use Rails and its related tie-ins (MySQL, Redis). This isn't really interesting as DHH has been a proponent of "Rails good everything else bad" for quite some time, and will probably only continue to double down on that stance.
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.
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.