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.
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.
These study groups were something I enjoyed and was dedicated to; they wound up being a nice perk for my colleagues -- good for morale and good for hiring. So while there was a cost, good value was generated in exchange and there was solid consensus around our team that the study groups were more than worthwhile.
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.
Both 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
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).
This, 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.
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.
I 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.
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.
I 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.
This. 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.
I'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.
The 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.
OK, 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.
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 - also includes a small electron server to help dynamically compile stylus/pug.
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).
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.
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.
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.
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.
Teaching non-coders to code is not going to produce productive engineers except in the most unusual circumstances. You're introducing people to concepts like a terminal, a file system, source code, a text editor, variables, subroutines, debugging...
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.
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.
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.
depends 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.
Thinking in absolutes doesn’t make justice to your described position. There are certainly at least few people who are self-taught and are better at something that you do.
On the other hand "self-taught" people are often strongly motivated, intellectually curious and adaptable. Moreover, long lists of credentials and degrees don't guarantee that silly mistakes won't be made.
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.
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.
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).
I 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.
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.
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!
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.
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 :/
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.
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.
Aside 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.
I 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'.
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.
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.
> 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.
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.
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."
Cross-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.
In mine, it's been just the opposite: I've been working professionally for 16 years, and extended contact with non developers always helped. It didn't help me code faster, but it helped me code the right things, which is far more important than speed.
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.
This is a real tough one for me. I'm a developer, and I love development. I'd do it even if I wasn't getting paid. That being said, I'm comfortable saying that I'm probably not a great developer. I try hard, I enjoy working with teams, I love producing, but I've worked with a few actually great developers and I'm pretty sure I'm not them.
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.
Agreed. 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.
I find that even noise cancelling headphones don't help drown out nearby conversations - I listen to Apple's Chill radio and use Noizio when I really need to focus.
Noone knows whether you're playing music or not, they'll assume you are. I don't think that's the stigma with headphones though more like gives off the impression you don't want to be bothered for things like helping new engineers.
For all the suggestions of headphones. They're nearly ineffective. and Ive had BOSE QC25s before and i'm pretty sure NC technology is useless for non patterned sounds (language is unpredictable as far as NC is concerned). NC is good for things like motors, fans, rivers etc that have more or less the same sound continuously.
Wouldn't they be implying the non-engineers to be designers or testers rather than staff who need to make a lot of phone calls?
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.
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.
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?
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 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.
> 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.
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.
I am exactly the opposite. What you are saying (as far as I can tell) is "If management is going to be petty and stupid, then I am too". I think it is smart to avoid being taken advantage of, but I think what you are actually doing is enabling your management's stupid behaviour. If both sides have a hard line behaviour, it will never change.
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.
It's not "being petty", it's "asserting boundaries" in an abusive situation. You clearly decided to read only half the hypothetical -- or do you think a workplace timing bathroom breaks isn't abusive?
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.
Let me put it this way: have you been able to improve the situation using your approach? It's not about a person being better than another person, it's about working in a way that is successful. I'm saying that the other side of the equation thinks that they have to treat people poorly or else people will take advantage of them. Your behaviour will only reinforce their belief. My challenge to you is to find a way show them that they are wrong. If you succeed, then life will be better for everyone, not simply tolerable for you.
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 extrapolating an extreme hypothetical back to my baseline behavior in an uncharitable way.
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".
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.
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.
Gotta side with SomeStupidPoint here. If an employer is going to whine about any deviation from the standard working hours on my part, then all extracurricular activity stops. You get the hours exactly and nothing more.
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.
> 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.
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.
> 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]
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.
> And yet, you want to fire people who let their brains relax for a couple of hours.
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.
When I joined a management consulting firm, they started us off with three straight weeks of pure training. And I heard it used to be four weeks long in years prior. Some companies see value in investing their workforce.
Ben Horowitz has written on the importance of training:
I work at a management consulting firm and I'm building a two week course to get anyone who is interested some basic programming skills. If you don't mind me asking, how big were classes and what was the general course about?
The first week was for all new entry-level hires. There were ~35 of us and it was taught by internal folks. The subjects taught were general consulting skills. The next two weeks were business bootcamp for PhDs and other advanced degree holders. There, we numbered around ~65 and were taught by a mixture of internal experts and external business school professors. The subjects there were traditional business subjects like accounting, economics, operations, marketing, valuation, etc.
_investing_ money in teaching to improve employee happiness and foster cooperation between teams seems like a legit way to spend investor money, with positive financial outcomes such as increased productivity, employee loyalty and hiring attractiveness. Companies such as Stripe stay ahead of the competition because they get the best _people_, in every sense of the term, and their investors know it well.
When I worked at PlanGrid, spending an hour talking to a couple of sales people might have seemed like a waste of my time and their time but in reality it was a great way to share and increase collaboration. Every single time I visited a construction site I came away with new ideas and a better appreciation of what affected the users.
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.
That's my take on it.. I'd say the comments are borderline burnout and projecting your pain/suffering on others.
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
Glib response for a stupid comment, but I'll take some time to respond to yours. I also wholeheartedly agree with this, especially for a creative/knowledge intensive field. It is impossible to be nose to the grindstone 8 hours a day doing anything of value that can't be automated. I've listened to artists talk about this as well: a really good workflow for me is really hard thinking for an hour or two with the rest of the day refining/helping/sharing/learning/interacting/reviewing. This sort of garbage mindset leads to shit code, reviewers that only comment on variable names because they only care to focus on their work, inter-specialty prejudice, etc.
And I mean the biggest joke here is that we're talking about Stripe ... hugely successful with an awesome engineering culture. K bro.
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?
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.
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.