11 ms·
How Stripe teaches employees to code
- alexpetralia 9y agoI'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.
- barrkel 9y agoFlipping 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 9y agoWhat'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 9y agoIf 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 9y agoYeah, that's what I mean by "or their representatives".
- tyingq 9y agoAh, 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 9y agoYeah, representatives" is not the best word.
- deleted 9y ago[deleted]
- ozim 9y agoI don't like to fix first line problems but I really like to watch how users are actually using what I have built. Some eye opening moments come from that.
- thirdsun 9y agoI couldn't agree more. As someone who develops internal applications in a non-tech company I consider it essential to have a different, non-developer perspective on the subject as well as direct, frequent communication with the the actual users of the product, which includes me. Potential problems and room for improvements are easily discoverable that way.
- parennoob 9y agoThis. While I have come around to the concept of "It's probably better if more people learn to code", I rarely see other parts of the company so eager to share their knowledge. 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.
- azernik 9y agoI'm not so sure every engineer needs to know that. I think the important thing is for everyone to have some understanding of the core business. 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.
- joatmon-snoo 9y agoThe company I was at this past summer took a few days where everyone (this was a cross disciplinary place, so the technical employees didn't just consist of developers but also mech e's, chemists, jack-of-all-trades, etc) was invited to shadow someone with sales for a few hours. Just seeing the sheer amount of data that they have to keep track of and stay on top of was really eye opening.
- djaychela 9y agoThis, indeed. I'm currently teaching in schools in the UK, and nearly all the IT departments I deal with are solely interested in IT for its own end. I've heard IT managers (at different schools) refer to it as "[my] network" or "[my] machines" - totally missing the point that they're all there for one reason, to facilitate learning. While this certainly isn't the case in all schools, the majority of the ones I've worked at have IT departments who really have no interest in or knowledge of what teachers really need/want to do, and simply put their own pre-decided processes and systems in place. 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.
- Iv 9y agoOK, maybe this is a case of engineering bragging, but I get the feeling that this will happen more naturally without a class this way. As an electronic and software engineer, I have been repeatedly told that while my electronic and software skills are important, what really made a good engineer was their capacity to solve problems, therefore their capacity to understand them, which often means to learn about the whole domain of the problem. 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.
- diek 9y ago> 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 9y agoI 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 9y agoAs 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."
- pseudalopex 9y agoCross-functional feature teams are something entirely different. 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.
- lojack 9y agoAgreed. I sit next to a manager who is on the phone all day and all I can think is how much I wish he had his own office so I could get actual work done.
- bballer 9y agoThis 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.
- jaboutboul 9y agoHow about opening the course and sharing on github so other can benefit/help improve as well?
- Myrmornis 9y agoOpen 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.
- rectang 9y agoWhen 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.
- korzun 9y agoI'm genuinely curious if this was pre or post firesale to CBS?
- rectang 9y agoBoth pre and post acquisition. I always had the support of Eventful CTO Chuck Norris (who is great to work for). Support from the business side varied over time. I got around that to a certain degree by scheduling most study sessions over lunch break and providing lunch. 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 https://wiki.apache.org/lucy/LucyBookClub
- jorblumesea 9y agoTake 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 9y agoI 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 9y agoDefinitely 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).
- shostack 9y agoI can speak from a marketing perspective. For context, I myself am somewhat technical (enough to be dangerous, but hopefully know when I'm at risk of being dangerous) and work closely with many incredibly talented engineers. . 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. [1] http://www.goodreads.com/book/show/44882.Code http://www.goodreads.com/book/show/44882.Code
- partycoder 9y agoThere 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 9y agoTeaching 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.
- cultofmetatron 9y agodepends how big n gets in the context of that particular function. a O(2^n) can be faster real world that O(1) if the overhead of the O(1) is bigger than the O(2^n) version. Its important to remmeber that big O is a measure of worst case as n grows. If N is bounded by the realities of the business case, it might not be so bad.
- korzun 9y agoA 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 9y agoThe 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 9y ago> 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 9y ago> 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.
- throwaway2016a 9y ago> For example, “==” is used at Stripe to mean you’re in agreement Is this normal? I have never heard this before.
- theparanoid 9y agoIt'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.
- bluetwo 9y agoIs this better or worse than people who start lists with "0"?
- soneca 9y agoThis 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.
- andrewflnr 9y agoAside from what soneca said, putting forward English as some sort of standard for excellence is hilarious. Your company probably is smarter than a thousand years of haphazardly agglomerated syntax, vocabulary, and spelling.
- p4lindromica 9y agohave you never used an emoticon or an abbreviation in IM before? To me this is as innocuous as replying "ack" to someone.
- OJFord 9y agoI came back to comments to ask that too. I wondered if it meant on IM, or as a sort of placard used in stand-ups like there was a post about recently using pseudo sign language for some reason. 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'.
- deleted 9y ago[deleted]
- imron 9y agoNext can they teach their web designers about contrast?
- twoquestions 9y agoIndeed, I had trouble reading that. Good stuff getting programmers familiar with the domain they work in. http://contrastrebellion.com/ http://contrastrebellion.com/
- jjcm 9y agoI'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 9y agoThis 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 9y agoI 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.
- neon_electro 9y agoWhen you say "atomic", do you mean atomic design as popularized by Brad Frost? [1] Are you using atomic design or some other design system? [1] http://bradfrost.com/blog/post/atomic-web-design/ http://bradfrost.com/blog/post/atomic-web-design/
- barking 9y agoI would humbly suggest that they cease and desist from calling their workers stripes.
- bhultin 9y agoSeconded.
- timlod 9y agoEverytime 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 9y agoDid 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 9y agoNo, 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 9y agoIt'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 :/
- douche 9y agoSounds like they have really good PR people working for them.
- sidchilling 9y agoPerhaps 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!
- hasenj 9y agoIt'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?
- lemonsqueeze 9y agoThis. The article reads like a feel good story about helping the less fortunate, or something. It would be great to personal success stories, from the words of the employees themselves. Objective measures of performance and outcomes: - pay increase % - vacation increase days - hours worked - stress level - level of claimed satisfaction - $ spent per employee - $'s returned per employee That would be better than techno utopia propaganda from Stripe et el
- rectang 9y agoDepends 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.
- CodeSheikh 9y agoIt 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 9y agoPeople 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.