_t0du
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.
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?
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 going to debate you because there isn't a debate.
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".
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.
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.
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.
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.
Clojure is the language that I have always wanted to learn, but the benefits never seemed very apparent. I'm hoping your response will make them clear.
How does it hold up for those of us that really love static typing and compilers?
I had a candidate in a few months ago that was interviewing for Software Development Manager, so he got an initial phone screen and then a face-to-face with myself and another dev on the team he'd be managing. I was impressed with how little he knew about programming.
"Name some data structures." "What does MVC stand for?" "Name some design patterns" etc. All of which were unanswerable. Generally when it becomes clear someone was dishonest about their skillset, the ability to get hired for any position becomes impossible.