
How Stripe teaches employees to code - p4lindromica
https://stripe.com/blog/teaching-employees-to-code
======
rectang
When I worked for Eventful, I organized several study groups for beginners
similar to this.

Like the Stripe team, participants in these study groups also found that
cross-departmental collaboration improved. After learning the fundamentals of
coding, people understood better how to work with engineering teams.

We also found a few people out on the edge of the bell curve who had strong
engineering aptitude, including one fellow who eventually became a stellar
engineer for us.

The main difficulty is that you need a lead who enjoys teaching. Personally, I
find the challenge of explaining concepts at varying audience-appropriate
levels fascinating and stimulating. We had one other fellow lead a group, and
he had a good experience too. But as you can see from this discussion, not
everyone wants to take this on.

~~~
dba7dba
One doesn't have to lead all lessons. Linux can be taught by Linux admins.
Setting up personal workstations with Vagrant, etc can be taught by desktop
team. HTML/CSS can be led by FrontEnd dev.

Also, these training courses are great, but ultimately it costs $ to the
company.

~~~
bostik
Even the best investments incur short-term balance sheet deductions.

~~~
rbg246
Sorry to be pedantic, but you are buying an asset with another asset there is
no deduction on the balance sheet.

------
barrkel
Flipping this the other way - a company that works in a particular area,
whether it's law, finance, retail, advertising, anything - it's important to
educate engineers about the specifics of that industry. The alternative is to
forgo bottom-up innovation in the company (with engineers that don't have
enough business context) and risk embedding a command and control approach to
feature development (coming in from sales, through product management, into
engineering design, all the way down to the interchangeable coding monkeys).

~~~
BurningFrog
What's most important is that engineers have contact directly with users or
their representatives and get a grasp of how and why their code is used in
real life.

The more this gets filtered through layers of communication and management,
the worse the software will be to use.

Making the programmers understand the subject area on their own also has a
benefit, but it seems a far more costly way.

~~~
tyingq
If the business side, specifically product management / direction is
reasonably skilled, you're missing out on a lot not talking with them
regularly.

Talking directly with the users is fine. But if that is your sole input,
something is probably broken.

~~~
BurningFrog
Yeah, that's what I mean by "or their representatives".

~~~
tyingq
Ah, okay. Took that to mean customer support or similar. Customers sometimes
describe what they want, not what they need, what they would pay for, what
might change things entirely, etc. There is some amount of product direction
that is made without existing customer input.

~~~
BurningFrog
Yeah, representatives" is not the best word.

------
jjcm
I'm currently running a very similar thing over at Atlassian. I was brought in
to run their prototyping, and one of the things I immediately noticed is many
of the designers didn't have the tools they needed to make proper prototypes.
Rather than just teach them on invision/atomic/principal, I figured it'd be
better to just teach them how to do front end dev. We're now holding lessons
for a 2 hour block every week in 10 week cycles, and that seems to be the best
for people schedule wise. Originally we did all day courses but too many
people had conflicts. Course notes are here if anyone is interested:
[http://prototype.guide](http://prototype.guide) \- also includes a small
electron server to help dynamically compile stylus/pug.

~~~
asperous
This strikes me as the wrong approach. Front End Dev can be but it not usually
that great of a prototyping tool.

Doing it this way they'll end up spending time working on things that aren't
designing (fixing css bugs, etc).

Also Prototyping tools overlap more with how many designers think (the tools
are made for designers), while html/css/js overlaps more with how programmers
think (the technologies are made for programmers).

~~~
jjcm
I think you're right if the designers would _only_ end up using code for their
prototypes. One of the things I really try to teach is to use the right level
of prototyping for what you're trying to test (whether that be paper,
clickthrough, or code prototypes). The reality though is that you don't really
need courses for paper and tool-based prototyping. Invision and other tools
out there have done a great job in being quickly learnable and easy to use.
Front end dev however is a different beast. But if you're designing micro-
interactions and anything with a lot of motion it can be really tricky to do
those without code. By teaching the designers to code, it allows them to cover
all ends of the spectrum when creating prototypes. Also it lets them
communicate with the engineers in a much deeper way - very valuable since
Atlassian has been a very engineering based company for a long time.

------
bballer
This is great! I think every one should have some fundamental knowledge of how
coding works, especially those working at SaaS companies who aren't directly
involved in code. It would definitely be a confidence booster to those who are
in roles where the primary function is supporting software and the processes
(and bugs of course) around the primary product.

The problem we have is that we are strapped and everyone is pedal to the metal
every hour we are at work. We just don't have the time to sit down and layout
these kind of courses for all the employees and then follow through on
properly teaching them. I sure wish we did. I can see how at large stable
companies this can be a huge win, but the reality is for the smaller fish it's
tough to pull this off.

------
partycoder
There is substantial domain knowledge you require to code safely.

Explain someone who hasn't been exposed to how numbers are represented in
memory that doing financial stuff with IEEE 754 floating point numbers
(default in JavaScript and others) can lead to precision errors, with possible
financial consequences. Very hard to do without going all the way to the
basics.

Or maintainability, security, configuration, construction for verification,
performance, scalability, concurrency, thread-safety... and all non-functional
requirements.

You can save money in less skilled people. I have fixed bugs implemented by
self-taught guys. I remember profiling a service experiencing service
degradation (with terrible financial consequences) and finding a O(2^n)
function that could be O(1). That's the kind of risk you expose yourself to.

~~~
patio11
Teaching non-coders to code isn't primarily about getting them to do core
engineering work, although I personally love the idea that that could happen
over time for ones who wanted it. These classes don't have folks implementing
feature requests for our payments APIs; they're largely producing side
projects so that they understand the world their engineer coworkers live in
every day.

Also, if O(2^n) code made it into production, that isn't a failure of the
programmer, that is a failure of the system.

We want to be serious and rigorous about engineering process, because bugs at
Stripe could affect a lot of peoples' livelihoods. Accordingly we implement
things like code reviews, automated testing, and performance monitoring. We
make _substantial_ efforts on all of these, and they improve the quality of
output for all developers, including both ones who picked up coding late in
life and ones who've been coding since age six, have a CS degree, and
certainly implemented an O(2^n) function at their first job [+].

Other companies doing meaningful things should also be placing their bets as
to process improvements as to reduce failure. "Hire only people who don't make
mistakes" seems to be a hard bet to win with.

[+] I'd never point fingers at anyone for this since it is entirely natural
but since it was me I feel less guilty about it.

~~~
partycoder
Learning is good. I am OK with people going outside of their comfort zone and
learning about other disciplines, it helps people empathize, appreciate the
effort of others, it facilitates collaboration, etc.

But we don't say: doctors make a lot of money, I am going to go to a doctor
camp and learn to think like a doctor in 12 weeks! Then I will work as a full-
stack doctor and become rich! But replace doctor with some software engineer
and suddenly it makes sense.

Some people argue that we don't do life and death stuff, just harmless
friendly websites. But one careless mistake can result in personally
identifiable information being leaked for millions of people. Do that in
healthcare and it's a HIPAA violation with only 1 single record instead of
millions and you can get fired with your license revoked.

Then, I am not saying or implying "hire people who don't make mistakes".
Everyone makes mistakes. Even the top 1% of top performers make mistakes.

The difference is how those mistakes happen and why. Mistakes can come in all
forms, because we make assumptions and sometimes those assumptions can be
wrong. The reason we can make fast decisions is because the human brain
simplifies problems by making assumptions. But the assumptions made by a
trained person are different.

~~~
SerLava
Well realistically, someone could become a reasonably _functional, useful_
doctor in 12 weeks, but the problem is they'd kill people pretty frequently.
Bad programmers just write bad code, so if you're building a stupid website
it's a lot less bad when it goes wrong.

------
jorblumesea
Take recruiting for example, would that really allow you to have a more
technical conversation with a prospective employee? If they are any sort of
engineer they'll run circles around you in every sense, so what's the benefit
here? I'd love to see the data breakdown of how/why this benefits certain jobs
or teams.

~~~
tkxxx7
I definitely think the knowledge would help, especially given the rigor in a
course like this one - it's basically a part-time coding bootcamp - but I
don't know if that much is necessary. As a recruiter I think it'd allow you to
get a sense of the degree of nuance involved in replying to technical
questions. You'd have a better idea of how to ask for details from a resume
and maybe jot down some notes, even if you might not grasp the full scope. You
could even ask them to help bridge the knowledge gap a little, and get an idea
of how they interact with non-engineers. Anecdote, my girlfriend worked for a
staffing agency and just hearing me talk about work helped her see tech
resumes a bit more clearly.

~~~
BWStearns
Definitely agree. At the trivial level it could cut down on the
Java/JavaScript equivalency, and at the higher level is that visibility into
how they conduct engineer/non-technical interaction you mentioned (although at
that point I don't think the full meaning of non-technical is a fair label).

------
jaboutboul
How about opening the course and sharing on github so other can benefit/help
improve as well?

~~~
Myrmornis
Open sourcing material from within a company takes a _lot_ of time and effort.
It has to be a reasonably high standard to be something that can represent the
company publicly. Not everything has to be open sourced -- why shouldn't they
feel free to run their coding class internally? Anyway, it would just be
another jumble of intro material and tutorial.

------
barking
I would humbly suggest that they cease and desist from calling their workers
stripes.

~~~
bhultin
Seconded.

------
timlod
Everytime there's a post about Stripe, it is a positive post. Programms they
initiate, people they hire, how they act in their business. To me they seem
like an example of a 'good' company with great culture as opposed to what you
read about Uber [edit: removed caps] and co. these days, very refreshing!

~~~
scrollaway
Did you just comment in a Stripe post just to say "Oh look how bad Uber is
compared to Stripe!"?

Really. I like Stripe, I dislike Uber, and none of this is warranted.

~~~
timlod
No, I meant to praise Stripe (or at least how they appear to me based on what
you read about them in public) first and foremost. As many articles you read
about companies these days highlight negative practices (I mentioned Uber as
the prime example), it's nice to read when companies seem to do good.

~~~
scrollaway
It's possible to praise Stripe without mentioning Uber. I'm mentioning this
because it's really tiresome to see Uber brought up in a thread that has
nothing to do with it :/

------
throwaway2016a
> For example, “==” is used at Stripe to mean you’re in agreement

Is this normal? I have never heard this before.

~~~
theparanoid
It's dumb. If you agree just say it. Every time I've seen corporate speak,
which this is, I want to kill it. Your company isn't smarter than a thousand
years of English usage.

~~~
soneca
This is not about corporate speak, but about social group speak. I am sure you
use words and terms on your own social groups that could be expressed with an
old english word.

------
imron
Next can they teach their web designers about contrast?

~~~
twoquestions
Indeed, I had trouble reading that.

Good stuff getting programmers familiar with the domain they work in.

[http://contrastrebellion.com/](http://contrastrebellion.com/)

------
CodeSheikh
It is nice to see how more and more tech companies are taking this initiative
to hold on-campus intro to programming classes (mostly it is javascript or
python). But before most of these companies decide to teach coding to every
single employee, I would first focus on those god awful "tech" project
managers who get hired because of some fancy MBA degree and most of the time
they have no clue about the complexities of a software project in general.

~~~
rectang
People generally want to do their best, including the project managers you
refer to. Project managers with less tech expertise will often find themselves
frustrated that they can't get what they want. On average, I would expect them
to participate enthusiastically because this will help them be more effective.

At different companies, there will be different pain points: salespeople who
overpromise, pixel-perfectionist designers, etc.

Regardless, having people speak the tech team's language will tend to benefit
the tech team, so it behooves us to take a positive attitude when people are
willing to engage.

------
diek
> In seating, we mix engineering teams with non-engineering teams

In my experience this is a huge productivity killer for engineering teams. No,
sitting us down next to the recruiting guy doesn't make the recruiter better
at technology or the engineers better at understanding recruiting. It mostly
just makes us hate the person who talks on the phone all day while we're
trying to work.

~~~
c0nfused
I think it depends on the industry and needs of the company.

As an example, In video games this is used as a way to get a feature shipped.
Plop a bunch of artists with a coder or two and a couple of QA guys and roll a
feature together. It cuts communications time, keeps everyone focused, and as
long as your feature is encapsulated nicely it should merge back cleanly into
main in a few days.

If you are just applying a blender to the org chart it isn't going to be a
great choice. However, something like putting a developer within ear shot of
Technical Support isn't always a bad idea.

~~~
sillysaurus3
_As an example, In video games this is used as a way to get a feature shipped.
Plop a bunch of artists with a coder or two and a couple of QA guys and roll a
feature together. It cuts communications time, keeps everyone focused, and as
long as your feature is encapsulated nicely it should merge back cleanly into
main in a few days._

At the studios I worked at, these were called "meetings."

------
sidchilling
Perhaps a follow-up blog post on which department the people who attended the
program were from and how did the program help then in their day-to-day work.

Once, we have success stories, more companies would be interested in
implementing such programs.

Kudos to the initiative!

------
alexpetralia
I'm surprised by how controversial this article has been. I think it reflects
the wide gamut of workplaces that continue to exist in tech, despite the
external homogeneous appearance the industry maintains.

------
korzun
A part of me does not understand how start-ups find so many different ways to
burn the inventors money. Another part of me wonders how these people have so
little workload that they can afford to sit in a 2.5-hour class every week and
take projects home / do them at work?

I worked with companies that tried to do something similar, and besides a nice
PR piece for the blog, these types of things are nothing more than a nice
2.5-hour break for people who can't schedule enough meetings to make their day
go by faster.

Wait until individuals who came there to work get fed up with carrying the
rest of their team and start looking elsewhere.

~~~
throwaway2016a
The average employee is lucky to be productive 70% of the time. 2.5 hours a
week is only 6% of a 40 hour week. I think it is a great use of time.

The change of pace between day job and learning can help people be more
productive than they would if they were doing the same type of thing all day.

People are not machines.

~~~
korzun
> The average employee is lucky to be productive 70% of the time. 2.5 hours a
> week is only 6% of a 40 hour week. I think it is a great use of time.

I don't know where you are pulling those numbers from, but you are assuming
that 6% magically comes out from the 'unproductive' time without factoring in
the take home homework and other things that blow up the 2.5-hour mark.

It's not a static number and can't be used to make those claims.

The 2.5 hours will also scale up with the number of participants, 20 employees
who are committing 2.5 each week (at very, very minimum) is a loss of 50 hours
per week.

I can go even further and add people who did not attend the workshop but felt
like they are now entitled to a 2.5-hour break of some sort (and rightfully
so).

If the company can cut more than 50+ hours a week and still function, more
power to them. Usually, that only lasts until the finance guys need to start
cutting costs to improve the bottom line.

~~~
parennoob
> take home homework and other things that blow up the 2.5-hour mark

I would think "take home" implies you take it home, i.e. do it in your own
time. I don't know what your undefined "other things" are.

> The 2.5 hours will also scale up with the number of participants, 20
> employees who are committing 2.5 each week (at very, very minimum) is a loss
> of 50 hours per week.

It is this sort of thinking that is super counterproductive. Even if one of
those employees learns something simple, like how to programmatically create
CSV files and import them into Excel, they will have saved thousands of man-
hours.

You can't nickel-and-dime people's time like this. Philosophies like yours
tend to end up with timing people's bathroom breaks and scathing articles in
the newspaper; rarely successful companies.

~~~
SomeStupidPoint
Also, I have a very simple policy: I'm as strict about work hours as my
employer is.

You want 40 hours, butts-in-seats, timed breaks? Fine, I'm circular filing
that idea that's going to save you multiples of my salary each year because I
thought of it at home during off-hours, and you weren't paying me for that
time.

~~~
aisofteng
You sound awful to work with. It makes me appreciate how lucky I am to work
someplace where everyone has good attitudes towards each other and their
workplace.

~~~
SomeStupidPoint
I'm sorry, that's based on what?

If you honestly think me responding to a terrible work environment by refusing
to do work outside of work hours or go above and beyond for the company makes
me a bad coworker, I think you have a very distorted view of workplace
relationships.

------
hasenj
It's all nice and everything, but I have few "questions"

Is asking people about how they "felt"about the course really a good method of
evaluating the course's effectiveness? It sounds like people would always
makes up a reason to say they felt good about the course, either as lip
service, or because they enjoyed it even though it might have zero effect on
their work.

Maybe instead they should try to come with specific things to measure before
and after the course?

~~~
rectang
Depends on what degree of certainty you require, and how antagonistic a
relationship you have with your employees. (You seem pretty hostile.)

Providing career development opportunities isn't a revolutionary idea. Lots of
companies will pay for external coursework at community colleges and what have
you. The main distinction here is that Stripe is doing the education in-house.

