-
This week, Don and I discuss our history with in-office and remote work, why junior devs might reconsider working outside the office, and how requiring folks to work in your proximity is a trait of managerial vanity
-
I couldn’t find it in the show notes and I can’t listen right now, but I’m curious about your reasoning why junior developers would want to consider in-office work. I agree 100%, I’m just curious what you think about it.
As an aside, my wife’s work has a system where she basically gains 1 remote work day every 3 months (well, up to 2 days, but it’s a Big Old Company), which I think is a pretty reasonable way to onboard people to the company and business while also allowing freedom.
-
Two reasons, for me:
-
Learning. Pairing face-to-face with someone, or being able to ask questions in-person, is a much faster way to learn things. The ability to interrupt the more experienced person is a big advantage to the learner, and remote interruption is harder to do. The fidelity of the conversation is stronger in-office, rather than remote, as well.
-
Politics. The ability to maneuver office politics, get a promotion, move up the ladder, etc, is much easier to do with a lot of firms face-to-face. There’s a bias that so many managers have with a person being in front of them instead of through a chat program.
You’re right, there’s nothing wrong with your wife’s approach of remote and in-office mix, but for folks trying to break into a career, I think there are certain advantages that on-site gives them.
-
I’m in total agreement. #1 applies not just to technical learning, but about business domain learning, as well. I hadn’t thought of #2, though, that’s a great point!
-
I mean, #2 is kind of gross, right? Why shouldn’t advancement be strictly on merit? But if only things worked that way…
I love working remote, so I think it’s a great goal for folks to go after. However, when I was talking to my students about it, I wanted them to consider the side effects of trying remote for their first gigs, which are usually critical for future success.
-
It is gross, but being aware of and understanding the problem lets you engage with it instead of tripping over it, unawares. Politics is gross, in general, but educating ourselves and engaging in the process helps mitigate nasty surprises in the future, which is why I’m glad you mentioned it.
-
-
-
-
-
-
We speak with our first guest, Mark Thompson of Trilogy Education, about his approach to creating a productive learning environment both on the job and in a classroom setting. First key point: encourage questions.
- Create a culture where senior members of the team are open to being interrupted and asked questions constantly
- Compliment people for taking the initiative to ask a question in the first place
- Have students/juniors explain back what is going on with the code, which will likely force them to ask questions
As I’m building prototypes or products for clients, I’m constantly concerned that the standard tools I’m using for auth (Devise for Rails, Passport for Node, etc) are just not enough over the long haul to keep user data secure.
Storing user data and handling most of the auth service seems risky as hell to me, but I don’t see quite as many strong opinions from the dev crowd about identity management as I do people sniping about where to put spec files in their codebase.
I guess I’m openly curious: Are folks using services like Firebase, Auth0, Okta to manage their user persistence, authentication, and authorization? Or are folks just rolling their own or subscribing to open source projects and crossing fingers?
Personally, the Auth0 docs are not hitting the mark regarding the delivery vs complexity. It’s near to impossible for me to quickly get a ReactNative -> Auth0 -> API Server routine going. Okta seems easier, but I haven’t dug in. Firebase seems easiest, but then I don’t trust it because of the simplicity.
Fishing for opinions and experience on this one, I guess.
For all of my stuff, I roll my own authn and authz. It’s really not terribly hard to get right, it invariably deals better with the growth of weird business cases, and most importantly it means that I can make guarantees about user privacy and security that relying on a 3rd-party service would preclude.
We are responsible for our own uptime–ultimately, we’re responsible for the privacy and security of our users.
I guess I don’t feel as confident about auth being “not terribly hard.” There are a lot of hacks being done against folks that I assume consider themselves smart enough to roll their own.
That’s a totally fair point!