IT/Software career thread: Invert binary trees for dollars.

Mist said:

I need the Eternal Sunshine treatment. I wanna go back to when I didn't know how phones work.

Click to expand...

if you gaze into the abyss, the abyss gazes also into you

Rangoth said:

Yes it does, but as alavaz said below. The problem is ultimately need them to have a user in my DB so I can provide proper claims/roles based on my system and then return a corresponding token.



This is exactly what I thought, but wasn't sure on. So basically I have to figure out whatever payload Google/Microsoft return upon a successful login and then be willing to receive that on my backend. I'm sure there is some type of "Google/Microsoft" unique ID that I can add as a property to my user.

Then once I get the login payload, if it is of type MS/Google, check for a user in my system with the matching unique ID(or email perhaps?) and if it exists, log them in basically skipping the password verification check. If it does not exist, create that user and also skip the password verification checks. Instead storing the MS/Google unique payload information and associate it with the account.

Again I thought the process made sense to me, but for the life of me I cannot seem to figure out what payload I would get back from those services and if/what there is anything useful in there I should store...for example to maybe get their little image for display in my page as well.

Click to expand...

They will return the unique userid on their system of that user. It is up to you to get any other information in your system.

Basically when someone wants to integrate with facebook, your system still has to create an internal user for that guy and assign it the facebook id.
There are templates you can use that show this behavior under the OATH authentication part.

Udemy is the Steam of online classes. Buy a shitton of stuff on sale, but never actually do them.

ShakyJake said:

/rant

Some of you may recall I had applied for a senior UI developer position at a company that does federal contract work. I accepted the offer and just this past week was able to begin dev work.

And wow, what a mess. It is truly amateur hour. Granted, visually the application looks pretty good. Albeit, it's using Bootstrap CSS so that's not hard to accomplish. And this isn't some old legacy application either -- it is green field development starting a couple years ago using one of the newer UI frameworks. But it's super clear whoever architected this had no idea what they were doing. It's not necessarily spaghetti code, but you do have code files that are hundreds of lines long, components and methods have no documentation, and no unit tests written that I've seen. Application structure doesn't follow the recommended best practices. Right off the bat I've spotted truly egregious mistakes like not unsubscribing to events so you know this thing has memory leaks and side effects all over the place.

The thing is, I've seen this repeatedly in my 10+ years of software development. I don't think I've ever come across an enterprise application that I thought, "holy shit this is elegant". Maybe this it's a myth?

Anyway, I'm debating if I should raise these concerns at the next dev meeting. But I know I'll come off as a know-it-all asshole, especially being the new guy.

Click to expand...

This is the best advise I can give you.

For everything, there is a reason.
You may think everything is junk now that you are looking at it, completly removed from the development process, and with the benefit of hindsight. And it may well be trash.

But be cognizant that you were not part of the meetings and thought process that lead to that code. You were not involved in the trade off that took place when it was designed implemented or debugged.
It is easy to look at code that was written months or years ago and see patterns that now completely discarded but at the time were all the rage.

Always keep on the back of your head that the people before you that touched that code were not mumbling idiots, but simply developers that hopefully made decisions with the best information they had at the time, and within the business contrains they had, which are unknown to you now months or even years apart.

Everything is elegant, well design and perfect when you do it in paper, and if you are lucky you can do it in code once..... then the requirements change on you. Things that you did not thought off pop up. Your business side starts requesting thing that do not fit your elegant design.
And you see yourself changing your once elegant design into a Frankenstein version that resembles very little to that thing you design 3 months ago. Business keeps adding features, introducing bugs, giving you conflicting requirements, and make all of them work into your thing, but by then it is no longer the elegant thing it once was. You traded off certain functionality in the name of development speed, you made deals with them, delay features, were forced to add new ones with a time crunch.

Then a new developer comes along looks at everything you did and calls it a piece of shit, badly design and not elegant. And you look at that new developer into his eyes.. into his soul and think.... what a piece of uninformed garbage that guy is.


Before you criticize a piece of code, learn the context of it. Always give the guys who put it there the benefit of the doubt.

you can't expense the course? That sucks.

Is this negotiable?