Thanks so much for the explanation. As they say, when a measure becomes a target it stops being a good measure.
Relevant XKCD for good measure.
How can these businesses keep running? Storing and distributing documents isn’t exactly the most technically challenging product to build. I’m not in the field though so I’m absolutely certain I’m missing a lot of the nuances here. Can you shed some light on why you think nobody new comes along to our compete these folks?
I think it’s pretty useful, be interested to hear your hangups with it though because it’s definitely not perfect.
If something goes wrong and I have a stack trace, that plus the type of exception will almost always be enough for me to figure out what’s wrong at least as a starting point. I’ve worked mostly with JVM languages in my career though so maybe I just don’t know how bad it actually is.
Then a year or two later you quit/get fired/move to a new team and that code is underpinning a business critical task. Everyone responsible for the code is scared to do any major refactoring because of how important it is but it seems to be working ok. Hopefully they’ll have time for a big refactor next quarter when they can afford to take some time and manage the associated risk.
Seems legit to me typeof 🎈=== "spaceship"
is probably true
in JavaScript after all
One interesting thing I read was that commenting code can be considered a code smell. It doesn’t mean it’s bad, it just means if you find yourself having to do it you should ask yourself if there’s a better way to write the code so the comment isn’t needed. Mostly you can but sometimes you can’t.
API docs are also an exception imo especially if they are used to generate public facing documentation for someone who may not want to read your code.
Agree with you though, generally people should be able to understand what’s going on by reading your code and tests.
Very true and completely agree with your post. I didn’t mean a test in the exam sense more like a COVID test in terms of test design.
I actually think in some ways it’s a good thing to overlook the technical side to a degree as well because technical skills are generally a lot easier to teach than the people skills. Assuming the fundamentals are there at least.
An interview is just a test. Like any tests there are false positives and false negatives. There is a trade off between having more false positives/negatives and generally when it comes to hiring, a false positive is much more expensive than a false negative so many interview processes will end up rejecting good developers.
An interview can’t tell the company whether or not you are a good developer or a bad one. It can only say you can demonstrate certain skills to a certain level under interview conditions which means you are pretty likely to be a good developer.
It’s tough when you get rejections but because of the above factors, unfortunately it’s not enough to be a good developer to pass interviews a lot of the time. You also have to be good at interviewing. The good news is like any skill it can be practiced and if you’re already a good developer it shouldn’t really take much effort to become good at interviewing but it does require practice.
That’s my take anyway. Keep your head up, practice interviewing and you’ll be alright.
Sounds like you need to add some sleep statements somewhere in your deployment scripts if you want to deploy in 10 seconds