When I worked for Eventful, I organized several study groups for beginners similar to this.<p>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.<p>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.<p>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.
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).
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: <a href="http://prototype.guide" rel="nofollow">http://prototype.guide</a> - also includes a small electron server to help dynamically compile stylus/pug.
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.<p>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.
There is substantial domain knowledge you require to code safely.<p>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.<p>Or maintainability, security, configuration, construction for verification, performance, scalability, concurrency, thread-safety... and all non-functional requirements.<p>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.
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.
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!
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.
> In seating, we mix engineering teams with non-engineering teams<p>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.
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.<p>Once, we have success stories, more companies would be interested in implementing such programs.<p>Kudos to the initiative!
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.
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?<p>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.<p>Wait until individuals who came there to work get fed up with carrying the rest of their team and start looking elsewhere.
It's all nice and everything, but I have few "questions"<p>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.<p>Maybe instead they should try to come with specific things to measure before and after the course?