3 ms·
There are roughly 3 phases in your career. In the first, you don't know much and do things simply, naively. In the second, you know quite a lot, and like it or
by javajosh 7y ago
There are roughly 3 phases in your career. In the first, you don't know much and do things simply, naively. In the second, you know quite a lot, and like it or not you will be quite attached to your own expertise, it will be part of your identity. Your solutions tend to be complex, but you believe they must be that way, and you have evidence this is so. In the third phase, you begin to perceive systems as ephemeral results of some causal chain, and have a sense of how they became the way that they are. This depth of understanding allows you to embrace simplicity again, but this time you understand precisely the limits of that complexity.
I think a lot of professionals (not just programmers) get stuck in phase 2. This is where, in our field, most of the code comes from: capable, smart people writing new code furiously, and with the not incosequential fact that it provably works. Sure, it has bugs, but you can get to those eventually. It also happens to be the most "defensible" phase, where you get to speak down to others - you have concrete experience, real knowledge, so you are justified. I would guess this is also the bulk of working programmers.
So, the OP's solution could be coming from a phase 1 or phase 3 place. You are certainly coming from phase 2. I would encourage you to stretch a bit and consider when the OP's simple solution makes sense, and when it doesn't. I would hope you would do this in an interview as well, because you'll find phase 3 people saying all kinds of whacky things, which might not make sense to you unless you ask.
(A careful phase 3 will make sure to preface his simple solution with his limits, and to not do so is a little bit sloppy, but personally I don't think that's a deal-breaker.)
- swat535 7y agoFair enough, but if you have reached phase 3, you would undoubtedly know that Auth logic is fairly complex and rolling your own half baked solution will put your users at risk? I can't think of a situation where OP's solution makes sense. Except for the obvious cases (app will never be in production, will never have real users or contain valuable data, etc)
- javajosh 7y agoThe OPs soln makes sense for an intranet application with a small-ish user base (e.g. an internal app used by startup personnel) In this case, the likelihood of threat models like brute-force attacks, XSS, etc are all dwarfed by other threat models (social, physical, etc). I think it's a good compromise; and at least they aren't storing passwords in the clear, and picked a good hash function! These are really low-hanging fruit and you'd be surprised how often even this goes wrong. In any event, I also believe there is a generally better approach to auth that avoids a lot of the complexity of traditional approaches. It's speculative, but see my other comment in this thread: https://news.ycombinator.com/item?id=22157951 https://news.ycombinator.com/item?id=22157951