> Some product manager/project manager/engineering manager already broke things up into user stories. Those user stories were further broken down into tasks. The tasks were then evenly divided amongst all the engineers. Each engineer didn’t have much of a say in it. Some might call this slave work. It was the most unproductive time of my life.
This is one of the central dilemmas. To some people, it sucks -- they'd rather be programming rockstars, solving big problems in a way that's interesting to them.
But in most of the real world, when you've got various stakeholders, a big project, lots of programmers whose work needs to be coordinated, with standards, and you can't get bogged down in n-to-n communication, this is just how it often has to be. Face it, most work in this world is "slave work", if that's how you want to call it (although I think that sounds rather insulting, when you think about how an unfulfilling office job you're free to quit is a million times better than actual slave work).
And part of being a professional and mature programmer is realizing that, look, that's life. Sometimes you will get a job with a big say in how things are done, be super-independent, and it will be amazing. And sometimes you'll look back five years later and realize how it was a great learning experience for you, but you over-engineered it in a language or with a library that nobody could use afterwards, the whole system was replaced a year later, and you effectively wasted a lot of time and money of the company's.
But at the same time, sometimes you do need rockstar programmers, who are talented enough to be given free reign, and they'll produce amazing results, as long as you don't micromanage them, or even barely manage them at all. Different projets are different. And different employees are different, too.
But this is also hacker news -- where people don't settle on normal work. They're bold enough seek out only meaningful work. Either by starting their own company or joining one where they can make a huge impact without the typical fluff.
thats a bit broad - define meaningful work? - why is it more meaningful to go work at say a YC funded startup - than it is to go work for a larger corporation working in the same space? Lets face it - most startups dont make a huge "impact" - on anything other than the pockets of investors and founders - and that too in a small percentage of the successful cases that get overly romanticized!
He didn't define meaningful, because it's subjective and unique individual, so it might well be working for a larger corporation. His point was that the attitude around HN is to look for meaningful work as opposed to work that just pays the bills.
why cant "just pay the bills" be meaningful? - for more than 70% of the world thats very meaningful. Its also flawed to assume that everyone on HN is someone sitting in the valley with a bunch of job offers.
You wouldn't call it "just paying the bills" if it was meaningful. Meaningful in this context means something that you would do for free. At least, that's how I define it.
That's not to say that 70% of the world's struggle is meaningless. It means survival.
Also, you don't have to be in the valley to wish for meaningful work. I'm not and I do look for work that I enjoy doing.
You got to make up your mind ;) - either he didn´t define meaningful - which makes this entire thread of you´re argument flawed (or diverging from the original topic which was the post by sherm8n) - or he did define it - similar to how you did - in which case your original comment is moot.
That doesn't mean they don't need structure in their daily work. If it wasn't for those kind of people, those who are neither entrepreneurs nor risk-averse worker drones, start-ups wouldn't be able to get any development staff because "less meaningful" usually pays better.
The key word is coordination. Unfortunately to some it means making a list and making sure every one knows what to do. Here's the goal, here's what you need to do, "make it so."
In reality, coordination takes place in the face of constant change. Goals are critical, but purpose and trust are primary. When we know WHY we're doing work, and we trust the people we're working with, then coordination becomes two explicit acts. It is distribution of responsibility as widely as possible, and assignment of the right authority to carry out the responsibility.
If you trust the people you're coordinating with, then what and how they meet their responsibility doesn't matter. You can rely on their individual creativity/talent. When change happens, everyone has enough authority to adjust to the change in their own area of responsibility. If you don't know WHY and you don't trust the people you're coordinating with, then slave-labour tactics and task lists will be required, which means the effort is very likely to fail anyway.
I'm glad you brought this up. Trust is a big thing in the workplace. Take cross-department coordination for example. You're supposed to trust that another department will deliver what they promised so your project can succeed. I've been in situations where the manager did not trust the other department to deliver. So it was required that we implement our own solution "just in case".
The key problem here is "lots of programmers". Even on a big project, there should only ever be "enough programmers", just enough to get the job done under budget (hopefully) and on time. It's easy to put the burden on the programmer to carry on soldier! But a lot of the burden of productivity is often on the managers themselves. Mangement needs to manage, not cause strife and yet that's what some do.
Erik Lukas seems like a guy who's had his act together from very early on and whether he read up or not, he knew how to manage his people. That's a key skill.
There's also been a complete cultural overhaul in the community. Programemrs have been spoiled, for better for worse, and maybe we're expecting too much. Jeremy Morgan wrote a post last year that really illustrates this. Well worth a read :
I don't think programmers are spoiled at all. They just know there exists a huge market of opportunities for them. Why shouldn't they benefit from this and find the best possible working situation that would make them happy?
"...Knowing how to actually write code will someday be as rare as those who know how to use a slide rule now..." Well, maybe then they will start paying actual real money.
This is the exact philosophy that businesses use to promote perfectly good specialists to "management."
Some people _need_ structure. Some people don't want to define the plan because they take it personally and any minor failure is, to them, a personal catastrophe.
Not wanting to be "the boss" is a perfectly acceptable way to be productive. Some of the brightest developers in the world are the most productive when you let them sit in front of their workstation and code on something that flexes their brain.
The key is identifying how each individual is wired and what their motivating needs are. Not everyone wants to be promoted to tell people what to do, or have more control.
Would you want a developer who needs to be told exactly what to do? Or would you rather have a developer can define what to build in the product and then build it.
I don't understand why you want to promote people so they can tell other people what to do. As a manager, it's more beneficial to have an employee who can tell me what they want to do.
There's a middle ground: developers that need to be told what problem to work on, but who are smart enough to take it from there.
It's very useful to have a few of those on the team, because as a manager it allows you to ensure certain priorities are met, whilst giving those that thrive on freedom the space they need.
So, to answer your question: I'd rather have both.
The key thing when working with engineers is to give them a problem to solve - but don't tell them how to solve it. As a programmer I relish the challenge of problem solving. But I hate being told how to think.
In this case I was part of a scrum team at a large company. Some product manager/project manager/engineering manager already broke things up into user stories. Those user stories were further broken down into tasks. The tasks were then evenly divided amongst all the engineers. Each engineer didn’t have much of a say in it.
This is definitely a management mistake that I've been on both sides of. Getting everyone involved during with architectural process accomplishes several things: 1) Everyone comes away with a bird's-eye view of the project. 2) Everyone has input into the decision making process. When done properly no one feels out of the loop or under another's direct control.
Some might call this slave work. It was the most unproductive time of my life. I spent an hour at the gym every day. Another hour eating lunch. Several hours surfing the internet. I was really bored sitting under the fluorescent lighting. It felt like a chore to write code.
I can understand this attitude, but only up to a point - as a professional programmer you should be able to handle an assigned problem, figure it out and complete it. Instead of taking a long lunch take a few minutes to talk to your boss and voice your concerns. There's no excuse for half-assing it.
I never said I was slacking off. In fact I got more done than anyone else on the team. It just felt like I was there only to work.
I openly told everyone how I felt. That's when I decided I didn't want to be a professional programmer anymore. I talked to boss man and we mutually agreed that there was no way for me to be happy being a cog in the wheel.
You can be a "professional programmer" without being a "cog in the wheel" so directly. At the end of the day though, we're all cogs in the great machine of society. The sooner you accept that, the sooner you can be happy in your work
I'm a little delusional. I believe that having the ability to choose what I work on makes me happy. This is why founders like being founders. They don't want to accept things the way they are. They just want to make it better for everyone else.
You are spot on about this one. If you're playing the politics game you never talk about being unhappy. In 1-1s almost all employees will tell you they're having an awesome. I'v been on both sides of this.
Wow, psychological reactance.. there's a name for my illness! I thought I was the only freak who procrastinated immensely on a task just because someone ordered me to do it--especially if I was just about to do it anyways. Since I was a kid I would get bummed because if I did as ordered, the person would think I was only doing it because I was told, and self motivation has always been my biggest driver. Luckily I love my day job exactly for the lack of direct pressure from superiors.
I thought it was only me too. I didn't understand why I hated being told what to do. I would purposely start new skunkworks projects instead of doing what I was supposed to.
When I hear stories about how someone successfully broke into the highly competitive <insert name> industry without any previous experience the quote from IT Crowd comes to mind: "When i started Renholm Industries I had just 2 things in my possession. A dream and 6 million pounds."
This is highly contextual. If the US were to go to war with China, can anyone imagining the USN being more productive by saying to its sailors "Choose what you want to do and how you want to do it".
Or on a smaller scale, professional sporting teams are much more effective when they're able to work to a common plan than just being a bunch of individual stars. The teams of individual stars may feel better because they each get to behave the way they want to, but overall they're less productive.
I was speaking on behalf of personal productivity. Not team productivity. But there are definitely failures in professional sports too. When one player doesn't feel like he's not being included enough then communication breakdowns ensue.
Much of this debate centres around whether you define 'being productive' as 'enjoying your work' or 'providing value'. I've certainly done work which was enjoyable and progressed quickly in it due to that fact, but in the overall scheme of things had negligible value for the company - that's not productive work, in the sense that most people would use.
'Productivity' is the efficiency of creating product. You'd be drawing a pretty long bow to suggest that most people would call 'having fun' product over 'something that provides value'.
i think its a lot more to do with how you're told to do something. Additionally - this effect strongly varies from person to person - you might be better off titling your post "the pysch....impacts MY productivity". Working in the corporate world and on startups I've seen 3 types of people -all equally productive (mind you im not talking about how happy they were or how much fun they had - but since your point is productivity lets stick with that).
Type 1 - entrpreneurs/intrapreneurs - these were the kinds who figured out their way within organizations to make their own niche - do whatever they truly felt like doing - and people typically let them do their own thing - because they delivered results. Of course they had to play the occasional bit of politics - but that is a part of any job or field, and you're never working in a vaccuum where this wont affect you.
Type 2 - the 50/50s - these are people who can overtime become Type 1s - they like beign given some goal or target and a genera framework / project to work on - and then take it from there - checking in every now and then but mostly figuring their way out - and being allowed to figure their way out.
Type 3 - the TaskRabbits - these are the folks that make up i'd say 60-80% of a company (depending on the industry and company culture it can vary.. a creative agency might have a lower percentage as opposed to say ..a bank). They work with strictly defined rules, have goals and targets defined for them. They usually (atleast the non mediocre ones) try had to get their goals met within that time frame - and wouldn´t be able to perform as well without having all that structure set up for them.
If you're an engineer doing scrum, and the product owners are "telling you what to do", imo you're doing scrum wrong. Engineers should be involved in turning user stories into tasks.
Even outside scrum, even in a traditional workplace, good managers don't "tell you what to do", because they know it's demotivational. Good managers explain to you why something needs to be done, that is, how it will benefit the enterprise, and let you do it.
I was once in the room when one of the guys who wrote the book on Scrum described how many companies implement it. For those who don't know, Scrum says that team members should answer three questions each working day:
1. What have you done in the last day?
2. What are you doing today?
3. Are you experiencing any impediments to your work?
Here is how he said these questions get implemented:
1. Did you do what I told you to yesterday?
2. Here's what I want you to do today.
3. Fuck the third question.
There's already a barrier if a manager has to tell you why something needs to be done. Usually that means you disagree. Naturally you don't want to do it anymore.
People frame things in a different way to make it sound good all the time. "If you can crank out this code by EOD you're going to be a hero." versus "If you can crank out this code by EOD you still won't get a raise until next year."
This is one of the central dilemmas. To some people, it sucks -- they'd rather be programming rockstars, solving big problems in a way that's interesting to them.
But in most of the real world, when you've got various stakeholders, a big project, lots of programmers whose work needs to be coordinated, with standards, and you can't get bogged down in n-to-n communication, this is just how it often has to be. Face it, most work in this world is "slave work", if that's how you want to call it (although I think that sounds rather insulting, when you think about how an unfulfilling office job you're free to quit is a million times better than actual slave work).
And part of being a professional and mature programmer is realizing that, look, that's life. Sometimes you will get a job with a big say in how things are done, be super-independent, and it will be amazing. And sometimes you'll look back five years later and realize how it was a great learning experience for you, but you over-engineered it in a language or with a library that nobody could use afterwards, the whole system was replaced a year later, and you effectively wasted a lot of time and money of the company's.
But at the same time, sometimes you do need rockstar programmers, who are talented enough to be given free reign, and they'll produce amazing results, as long as you don't micromanage them, or even barely manage them at all. Different projets are different. And different employees are different, too.