Thanks @Kent!

Emacs. Forever Emacs. :-)

In all seriousness, it depends on what I'm doing. Like Kent said, PayPal does allow you a fair amount of autonomy in what software you use to do your job. Lately my main tools have been Atom, Chrome, and iTerm2 -- but I also keep a copy of things like SoapUI, Eclipse, Android Developer Studio, Xcode, and XMLSpy for doing other, more specialized tasks.

First, I use a Mac :) Then I use Visual Studio Code (with a bunch of extensions) as my IDE for all development, and exclusively use the Google Chrome developer tools for all client-side stuff. For one-off huge files/logs, I use Sublime. For design I use Sketch. I also use iTerm as my terminal replacement, and can't live without the zsh shell. For general computer productivity, I use Alfred for searching through files/apps, and Better Snap Tool to give me window snapping capabilities. Oh, and Bartender is really great for hiding all the status bar icons.

:D

Personally speaking, I don't think it's going to happen in the near future. Until something is really mainstream, it's a pain to get merchants to start accepting something -- and even then, some seem to hold out longer than others. I commend the handful of sites that have started accepting it, but I think that there needs to be some huge push to get the rest of the world to use it -- and I don't know that there's really any driving force that's pushing people to accept Bitcoin right now.

Hi, @matt It's ture, but companies like Ripple are trying there best to tie up with as many banks as they can on to there blockchain. For online merchants i guess, kim dotcom's MegaUpload 2 built on top of bitcache is really appealing.

Hi James, See my answer to Dylan hashnode.com/ama/with-paypal-developers-cj793fn2q…

I would say the biggest internal "conflict" was that eBay (Who owned PayPal at the time of the transformation), was also developing it's own Node framework. We spent quite a bit of time doing pros/cons analysis of both frameworks, trying to decide which features would be more useful.

Some of the early meetings felt a bit like the Thunderdome: Two Frameworks enter. One Framework Leaves

I think you'll get a different answer from everyone. Mine is a bit unique because I'm a full-time remote developer (not super common at PayPal).

For me, I wake up when my kids wont let me sleep anymore (7:30), I take care of home and family stuff and start work at around 9:00. I work on at platform team in my org (peer-to-peer payments mostly), so I have a pretty flexible schedule and just work on the most important thing I need to work on (my last team has 2 week sprints, standup, etc.). I have a few meetings a week. I help other folks be successful with the technology they're using, and I'm building tools for folks. I normally take about an hour or so for lunch to send my daughter off to kindergarten and put my son down for his nap, then it's back to work until around 5.

Right now I'm working on a tool called paypal-scripts which is a lot like kcd-scripts (which is a lot like react-scripts) except that's specific to the teams I support at PayPal. It's a ton of fun 😀

I think you will hear a slightly different story from each one of us about how the typical working day looks :) I lead a small team. We all have staggered working hours since we all have different kinds of personal commitments. But we do have core hours at office that overlaps during when we have a stand-up to sync up on our day-to-day tasks as well as any dependencies that blocks us. As a manager I try to keep my team as much out of meetings as possible, so they can have some peace at their desk to work on exciting stuff. Our product and design teams sit right by us. SO we do have regular brainstorming sessions which covers a variety of things: from what goes into an immediate release to a long term vision for the team :))

I'm a frontend dev primarily, so I've not looked at implementing GraphQL, and I've only used GraphQL a little bit on the side. I LOVE it and I'd love to be able to use it more! So eh... Those are my opinions 😅

We have a team pioneering GraphQL for one of our Paypal Checkout products. GraphQL is being used on node.js as an orchestrator (mid-tier service) for one of our mobile SDK clients. It is yet to be released, but so far consuming it has been great!! The developer on this project is not online today. But I will definitely bring to his attention, to answer your question in more detail. Cheers!!!

I agree with Kent. Even within Paypal, you may hear differing opinions from developers. Today node.js reigns the front tier. But I have heard murmurs, GO is being experimented for some midtier services.

Thanks, no wonder why Ryan Dahl and TJ both switched to GO. But again "Change is the only Constant". Rest we all love JS, but also should embrace other technologies... :D

For me, I'm head-over-heels in love with JavaScript and all that it stands for. Since PayPal really made an effort to push forward the adoption of Node.js, we have a lot of solid full-stack engineers that can write it back to front.

I think one recurring challenge we have though is migrating our legacy systems over from Java/C/C++ over to JavaScript and Node; we have to do a lot of work to ensure that legacy migrations go smoothly and without a hitch.

Personally, I don't think that NoSQL is a fad. It's simply a tool that solves a specific set of problems.

The real trick to them is recognizing when you're actually facing a problem that they solve. Sometimes, as developers, we get caught up in the excitement of a new technology, and as the saying goes... When you have a hammer, everything looks like a nail :)

Hi Nivesh! I don't know the answer to your question, but I just wanted to say you're welcome 😊

Big fan :D

PayPal is a company that cares deeply about Work-Life balance, and personal wellness.

Occasionally, there will be a project or a site issue that requires you to burn the midnight oil, but for the majority of us, those are few and far between.

From what I've observed (and have caught myself doing on occasion), most cases of burnout are self-inflicted. When people bite off more than they can chew, they need to be able to recognize and correct it. Failing that, it falls to the managers to point it out, and ensure that work is spread evenly.

Moreover, we're on the laid-back side, and enjoy benefits such as untracked vacation days, and the ability to work from home on occasion. It's very important to point out that our culture does not penalize you for asking for help, nor for enjoying these benefits.

Sometimes burnout simply means boredom with your current role. Our culture also respects people moving laterally to new roles. We have internal tooling for job searches, and managers tend to be supportive of these moves.

We'd rather have a good employee remain here, and be motivated, even if that implies moving to a new team.

My managers and co-workers(@tituswoo is one of my favorites) are my great resources that helped me go through my burn out most of the times. I talked through my difficulties with them, and they gave me different ways to perceive things. I like workout a lot and it definitely helps to release the stress. Our San Jose office has a great indoor gym, soccer field, and tennis court. I try to use as many times as I can :D Also, it's very important to give yourself some unplugged times. We have a great vacation policy, so as long as it's the reasonable/no conflict with works, my manager always give me enough vacation times

Great question! To refactor is to apply what you've learned today for the problems of both today and tomorrow. Since we write lots of code and are always learning, we constantly take a step back, clean up, write (and rewrite) frameworks, and throw away huge portions of our tech stack for better stuff. Naturally we have to produce functionality too, so as with any software team, it is a balancing act to know when to stop and revisit some code, or produce new features or bug fixes. Since PayPal's codebase is so huge, you could confidently say that a significant portion of it is being refactored at any given time.

We are also trying to figure out the way to utilize cryptocurrency's technology to build a better payment system. Our innovation lab hosted a couple internal talks related to Bitcoin and blockchain's technology.

Pretty much everything we have runs on Oracle. We've been using them since the beginning of PayPal -- in fact, we only recently phased out one of the databases that traced its roots all the way back to Confinity. We figured out pretty early on that Oracle connections are expensive to open, so we actually wrote a thing called the Oracle Connection Cache (or OCC for short) -- it keeps a cache of open connections to our Oracle servers and speeds up DB queries quite a bit.

As far as NoSQL databases...I'm not aware of any that we use on our production systems. I think there might be some that we use for doing analytics on our back-end.

Hi Dylan, I was part of the team that started the Node @ PayPal transformation. I arrived towards the end of the prototyping stage, so I was heavily involved in the evangelism and educational aspects of the transformation.

Long story short, there's nothing inherently wrong with Java (other than being verbose :) ), however, we had painted ourselves into a corner by building very cumbersome and inflexible frameworks on top of Java.

The front-end development cycle was very slow because of it, so we saw Node as a way to hit the reset button, and start fresh with a framework that would incorporate all the lessons learned from the Java days. (Mostly, what not to do with a framework)

This resulted in the rebirth of our open source program, starting with http://krakenjs.com, our nodeJS framework,

Here's a more in-depth look at the history of our change that I presented at jQuery Conf a couple of years ago. https://www.youtube.com/watch?v=qJVk6KiOEBA

All that said, we still do plenty of work in Java, mostly for midtier / backend services. Our newer frameworks use Spring3/Java8, and are much easier to use than those in the past.

Hey Dylan, Thanks for your question. I used to be a part of the core node.js team as well in the past.

To reiterate on what Lenny said

• We wanted to move away from building heavy in-house infrastructure around web app development and try out newer technologies. Earlier Java was used heavily in web-tier. Today, Node.js predominately dominates the web-tier. While we have small mid-tier orchestration services in node.js, Java is still used predominantly in the mid-tier.

• With node.js we have been able to extend expertise of our webdevs to full stack from just being on the client side.

• Node.js also enabled us to experiment to much more savvier front end and native technologies.

• NPM ecosystem was a big win to enable tearing down silos within teams and share work across :))

Here is a talk I gave at Intuit as part of Kraken team which focusses on our decision to move to node :) https://www.youtube.com/watch?v=YNtY5ObDJ8c So far it has been a big win...

Hi Walter 👋

It's a pretty common question and the answer is a bit nuanced, but at a high level glamorous uses objects for authoring the CSS and styled-components uses tagged template literals (strings) for authoring the CSS.

You can read about why I created glamorous in the intro blog post. Basically it came down to performance, size, preference, and the ability to apply RTL conversion on the CSS. Also, with styled-components you have to give a name to every element you want to style (by creating a component) whereas with glamorous there are the built-in components which allow you to add the styles directly to the elements and not have to give them a name (like Wrapper or Container). I also think that the glamorous APIs compose a little better than styled-components.

Good luck to you!

This is actually quite a common question from friends and relatives alike! Honestly, those two, as well as others from the PayPal Mafia, have been absent from the company for many years. Speaking to the tech stack, vestiges include ancient code, names of frameworks, databases, files, etc. Most of this has since been gutted and replaced with new platforms that fit the changing needs of the business.

Hi Charlie, See my answer to Kati Franz

hashnode.com/ama/with-paypal-developers-cj793fn2q…

Hi there, thanks for the question! This is mostly a duplicate of the tech stack question above, which Poornima provided a pretty comprehensive answer to the unit test frameworks in use here at PayPal. However, I will also clarify that APIs are mostly written in Java, while the the front-end stack is written in Node.js. Outside of standard unit testing, there are functional tests, sandbox tests, and live tests, using a combination of off the shelf Java or Python frameworks and our own scripts.

Hey Shahid, Thanks for your interest in Paypal.

I think the answer to the question below might answer your's as well. hashnode.com/ama/with-paypal-developers-cj793fn2q…

We're generally going to be looking at a lot of different factors (depending on what the API is going to do exactly), but -- speaking from experience -- I can tell you that some of the things we look at are:

• What does the API do?
• Is it going to have access to any customer data or PCI-sensitive data?
• What data is it going to expose to the outside world? (We have to pay close attention to applicable privacy laws...especially in places like the EU, where privacy is more strict than in the US)
• Are there going to be legal or compliance impacts?
• Is the application serving this API properly isolated? (e.g., it should only have as much access as it needs to function properly)
• Is the application using prepared statements for any DB queries it's doing?

Depending on the answers to those questions, we tend to do a deeper dive into what the API is doing and how it's doing it to make sure that not only is PayPal going to be safe, but our customers as well.

This is a broad question that can be answered by lots of industry standard information on API development. PayPal is a leader in this space, and is an active member in the OpenAPI Initiative. We have all the same concerns as many other API developers: building developer-friendly APIs with consistent standards, onboarding new users, authentication, app management, SDKs, documentation, sandbox, dashboards, up-time and other *ilities, partners, community engagement, and sunsetting old APIs. All of these require attention to ensure the developer experience is pleasant and meets the needs of your business.

Specifically regarding security concerns: as a financial company, we have to ensure extra effort is placed on ensuring APIs and data behind them are safe and secure behind a solid authentication mechanism. You can read more about it on our REST APIs Getting Started documentation.

I like that they're very developer focused. I mean, heck -- they have the code right on their home page showing you how to run a credit card transaction, and it's not very long. I wish all of our products were that easy. But...there's a couple of growing pains to being a big payments company: (a) regulators look at you with more scrutiny, and (b) you really have to do everything you can to prevent fraud losses. We're handling that pretty well today. I'm not sure Stripe is there just yet.

Who?

I love how easy their integrations are. Although I'm not sure about their Risk detection and support system. Paypal has a pretty solid system in place for that.