How Stripe teaches employees to code
stripe.com
stripe.com
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.
I also had strong support from the rest of the Eventful engineering team. Before leading the beginner study groups, I'd already been leading engineering study groups for years. Some of that overlapped with open source community study groups: https://wiki.apache.org/lucy/LucyBookClub
A: No way, why should I change? I'm the one who's a badass.
- Bob.
Also, these training courses are great, but ultimately it costs $ to the company.
To reproduce this success, though, you shouldn't ordinarily look to someone in a line engineering role. Organizing these sessions is more of a management or onboarding and training task.
I think "ultimately" is an interesting choice of word here, because spending the money is actually more of a beginning than an end (which is why people do it).
You're increasing individual engagement, generating social capital within your team, and creating opportunities to benefit from untapped creativity... all of which are valuable, potentially extremely valuable.
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.
Talking directly with the users is fine. But if that is your sole input, something is probably broken.
In particular, I'd like more training on law and finance. For some reason, I have never seen any lawyers or accountants being eager to teach me about interpreting laws, or balancing books.
If you're Stripe, that's coding, APIs, and finance/payments (that last is the bit engineers should be taught).
If you're Google, that's ads and ad-buying - hence the company practice of giving engineers (and maybe other employees?) some free ad credits so they can see what the customer perspective looks like.
When trying to get something changed, a brick wall of technobabble is presented to school management who generally don't know any better and defer to this 'higher power'. Unfortunately I know enough to have seen through many such reasons (such as "You can't have more than 10 Apple devices on a Wi-Fi network, it will crawl to a halt", and "Firefox? I'm not having that rubbish on my network - we're sticking with Internet Explorer"), but there's no way to convince anyone in management that they're being sold a dummy, particularly when it was they who decided to hire the IT manager in the first place. I've got a room of machines where it takes 5 minutes to run the software I use to teach (Cubase) because the machines have mandatory profiles enforced that have been taken before the plug-in scanning has been done, so it does this scan (5 minutes or so) every time you run it. Think of the learning time lost over the 5 years that's been in place.
I really think a plan of getting these people out of their offices and into the workplace to shadow people who use what they maintain would make a world of difference. Instead of being some whiner who creates 'frivolous' support requests, they would see that a bad decision can drastically impact the experience of everyone who uses their tools. I think I say this as someone who has been on the other side of the fence; I do support for some IT installations (including a first school with 400 pupils), so I'm tech savvy enough to be able to do what's needed, but try to approach it from a function-first rather than ideological approach.
Maybe that is just anecdotal evidence but I have found that engineers are often far more open and confident about learning new things in a totally different domains than other specialties.
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).
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.
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.
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.
After a few weeks, they understand more about what it's like to craft instructions for an incredibly powerful but incredibly stupid machine. That doesn't understand what you want it to do and always takes you literally.
After that experience, they understand the rhythm and routines of engineering more intuitively and are better prepared to collaborate effiiciently with engineers.
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.
To be successful in digital marketing these days, you absolutely need some of these skills. Knowing how marketing analytics and tracking work at a technical level opens up valuable new ideas to me as a marketer. These are critical things in an age where something like audience data can easily be a double (or even triple) digit growth driver. So knowing how and when to collect it, pipe it to the various places it needs to live, common pitfalls, and how to best act on it enables me to accomplish things those who are less technical may not be aware or capable of.
It also enables me to have both business and technical conversations with everyone involved in the process. This means less friction, more easily built consensus, and more successful outcomes. Life gets a lot easier when you can translate business needs to technical logic.
Plus, if it comes down to it, I can roll up my sleeves and be a direct contributor when needed for many common marketing chores like: adding new tags to the site, dealing with event data, coding emails, tweaking the code of marketing assets, and troubleshooting tracking. I am versatile and can be a one-man-show for essentially any area of marketing at this point.
For many of these tasks, the level of development experience needed is relatively low when you have appropriate guard rails and guidance. So if people get slammed, I am not overly dependent on my teammates for many areas core to my responsibilities, and can thus be more self-sufficient while enabling them to focus on much more technically difficult challenges. Plus, let's face it--not too many engineers get excited about setting up yet another tracking tag, so win-win right?
Last but certainly not least is the personal side. Working on a daily basis with engineers has let me grow my knowledge of various back and front-end things. This in turn has helped uncover a buried interest in wanting to get more technical in general. I've been reading Code[1] because I'm now genuinely interested in learning how computers work from first principles. As someone who grew up playing D&D and too many RPGs, it is just amazingly cool and mind-blowing how we are able to harness electricity to perform modern day magic. So I think there's something to be said for kindling new interests and growth in people--I wish more companies did things like this.
Really. I like Stripe, I dislike Uber, and none of this is warranted.
Is this normal? I have never heard this before.
I suppose it's a character shorter than 'ack', but no different to 'OK' - and arguably slightly confusing given the use of '+1' for agreement, to me '==' seems like it should mean 'meh, I feel neutrally about this'.
Good stuff getting programmers familiar with the domain they work in.
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.
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.
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.
At the studios I worked at, these were called "meetings."
Having a developer spend a day with the support team every so often is a great idea. Putting them within earshot just leads to the developers wearing headphones all day.
I own/tenant a small co-working space and we try to filter out the types of freelancers and small businesses who need to take or make an unreasonable amount of calls that might distract others. Surely Stripe would have considered this sort of basic open office stuff.
However, what I think I am great at, is making non-developers understand what it is I'm doing. I think this is a real skill, undervalued on a lot of teams. For this reason I actually enjoy and am more productive sitting next to the sales/AM/PM cohort. I like being tossed questions re: scope/SOWs because I know it'll pay dividends down the line when the team knows that a number was vetted before going out the door. I like it when I can explain why it's not a quick job, and they understand, and more importantly they can make the client understand. But I also understand that this isn't a role a lot of devs are comfortable filling - and they really, really shouldn't be forced to.
Now, you could argue none of this would be necessary if the team/agency/company had proper systems in place - and you'd be right. But I've yet to work for an agency that had it all figured out.
In my first job, We had separate infrastructure and development. Infrastructure had DBAs, Sys admins and specialists in random tooling, but nobody could code to save their lives. I managed to get myself sitting with infra, and not only I learned things that back then they'd not share with application programmers, but I could use my programming skills to deal with a lot of low hanging fruit. Today nobody in their right mind would train someone to know SQL and DB administration and know no general programming at all, because of how much power you lose by not coding... but there, it was a life saver.
At my next job I spent time programming from the back room of a retail store, stints in warehouses, and even with accounting. Then I could not just write code for them that made more sense, but even keep their goals in mind when working at a project with someone else.
At another job the company was doing heavy waterfall. The project I landed on had been going on for 2 years, but no developer had EVER talked to anyone in the user's department. It all went through business analysts and project leads. Needles to say, the internals of the system had nothing to do with the user's mental model, and the business analysts, which had no special training, were designing screens and answering questions, while they were badly informed. I used a fortuitous maternity leave by one of the leads to just spend a few days a week in another campus: One that had people that were not my users, but understood them far better than any analyst I had, and broke all protocol, redesigning some pieces of the system. When management came back, I told them that I wanted to show my changes to users, and they were ecstatic, as the changes were right on. A month later, my team was embedded with real business units, and management decided that, since we had better results than anyone else, that we could get away with not doing waterfall. All because I actually cared about what other people in the company were doing.
So sure, if you are sitting next to recruiting in an open office, and recruiting doesn't go into any closed booths to take calls, it's probably not so productive, but I have never worked at a place where getting to know what other departments are doing didn't multiply my chances of having more impact.
Once, we have success stories, more companies would be interested in implementing such programs.
Kudos to the initiative!
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.
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.
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.
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.
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.
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.
It doesn't matter when someone does their work. It matters that they did it, and did it well. Poisoning the water because someone is consitebtly 10 minutes late every morning is a signal to me that it's time to move on.
Instead, I recommend showing the advantages of flexibility. "I worked overtime to give you this thing which would not have been possible under your rules, how about cutting me some slack as a reward?" Somebody has to budge first. Now, if they are only interested in sucking up as much of your time as possible and paying you as little as possible -- then they are being abusive. As in any abusive relationship, your top priority should be to get the heck out of there. As a fall back position, of course, you should protect yourself as much as possible, but having an a priori position of being just as petty as your boss will really only result in unhappiness for everyone.
Your post reads as an uncharitable brag about how you're better than me, even though you conclude by agreeing with me.
It's not my duty to go above and beyond for people who are trying to abuse and take advantage of economic needs to treat me as a work animal, not a person in hopes they learn a lesson. You can if you want to, but I think that attitude is what enables that behavior, not mine.
It's not going to work all the time. Some people are jerks and there is no way to convince them to work together with other people. They just take everything they can and give nothing back. My experience is that these people are pretty rare, though. The vast majority of people who act like jerks do it because they are convinced that there is no other option. I'm not saying that you are being a jerk, but the attitude that you espouse just reinforces their view. They believe that they must take everything, or there will be nothing left for them. They believe that they can't give anything back because it will all be taken from them.
Give something back for free, even if they give nothing back. How much you give is still under your control. It won't always improve the situation, but my experience has been that it will sometimes improve the situation.
You're also taking a single action to generalize to all my behavior -- for example, you're ignoring the possibility that I would both "forget" the out of hours idea, but present them with studies about how treating "knowledge workers" better leads to increased output or other similar "during work" activities that might influence their behavior.
You're also ignoring a slew of other concerns, ranging from my emotional health to my willingness to lock IP up with someone I perceive to be a negative actor in society.
All because you want to brag about how you're better than me and be "right".
I am pulling that number for 7 years of management experience and talking with other people with similar experience.
And I don't know for sure it will come from unproductive time but I feel comfortable saying that if the teacher is any good they will be very engaged during that 2.5 hours because it is so different than what they do day to day.
But my hunch is it will come from the unproductive time. Studies have shows that shrinking the work week does not mean employees do less work. They do the same amount of work more efficiently.[1]
People will stretch to fill the allotted time. And if they know that they don't have as much time they will work to compensate.
> 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.
The company is getting concrete value from that. Having cross discipline knowledge allows teams to communicate more effectively, communicate with customers better, and appreciate other job functions more. Never-mind as another person wrote they might be able to automate the tedious parts of their job using scripts they learned how to write. But assuming for a second you are right and the ROI is negative. The ROI of having them browsing Facebook during that time is even more negative.
> 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).
Absolutely not true at all. These people are not on a break. They are learning. It is work. A different kind of work than they do day in and day out sure but still work. Not only that but they are getting a free (to them) education. Which has a predictable value on the market (look at the cost of a code bootcamp or college credit)
I'm not following the logic: someone is getting training so I deserve to work less? If I was in that scenario I wouldn't demand a 2.5 break. I'd demand 2.5 of training because I know how valuable that is.
I have a word for people who slack off for two hours while their peers are hard at work learning a valuable new skill: fired.
I have never heard of anyone putting so little value on training. You talk like they are playing foosball for 2.5 hours.
[1] https://www.nytimes.com/2016/05/21/business/international/in...
And yet, you want to fire people who let their brains relax for a couple of hours.
> You talk like they are playing foosball for 2.5 hours
Not a big difference. A lot of those people will forget most of the stuff they "learned" in a few months time.
Not at all. I did not mean to say that if that's what it came out as. My intent was I would fire someone who intentionally works less because they feel they are entitled to because of something another employee is doing.
It's also how they do it. If they come to me and say "I don't think this is fair... here's what I think we should do" I would never punish them. Punishing people for expressing a concern to management is a terrible idea. But if they just start doing it because they decided that's what is fair... all the sudden they disappear for hours on end... that person is not a team player.
I would never fire someone for taking a break unless it became a problem with the work quality. Heck... one of my team just went and took a nap in the break room for an hour and I'm completely OK with that. He's probably exhausted (he has a kid at home) and will come back more productive. Context matters.
> Not a big difference. A lot of those people will forget most of the stuff they "learned" in a few months time.
They might forget the technical details but they will retain some of the vocabulary and now know what the developers are talking about. But if even 5% of them is able to save or make their department money because of what they learned in the class it's probably worth it. You don't need 100% success rate to see net positive returns.
Ben Horowitz has written on the importance of training:
http://www.businessinsider.com/why-its-crucial-to-train-your...
I go completely the opposite of this dude, if you're not learning and not sharing, you're not working. Good employers know its better to have happy employees who grow than to have disgruntled employees who have far less productivity and enthusiasm to delivering anything of value
And I mean the biggest joke here is that we're talking about Stripe ... hugely successful with an awesome engineering culture. K bro.
When you work at a startup you should strive to understand every aspect of the business. That applies to Engineers and non-Engineers alike.
Teaching everyone about the tech stack and some basic coding skills isn't the #1 priority by any means, but it surely ranks in the top 10 things you can do to improve productivity.
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?
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.