About 10 years ago I was working for a game company. Most folks came in a few minutes before 10am when the daily standup was. I would come in at 6am, and generally get all the productive work I would get done before anyone else got there.
But after that, I would generally just circulate and see who was having problems, and help them. And honestly, helping the kids and teaching them was something I really enjoyed. So I see both sides of this debate.
But on the other hand, at one point the manager told me he thought our productivity was a direct result of our open office setup, and I asked him who the top 3 developers were. He named them, and I had to point out that all 3 had noise canceling headphones on to block out all the collaboration.
I feel like open offices are sometimes implemented by oblivious extroverts at the expense of introverts (and real productivity).
I remember working with some extroverts who loved war room calls because it made them feel like they were doing something productive. When there was a problem they insisted on sitting in a conference call for hours. So I was trying to get the work done while they were talking about weather. They were feeling productive because they were on an important call and I felt unproductive because I couldn't tune out the noise and get the actual work done. Made the whole process really painful.
Open offices were implemented because they were cheap. "Collaboration!" was the excuse to sell a far less pleasant working environment for developers.
If you really want to enable collaboration, everyone gets their own office, and there are a few dedicated conference rooms for the team. Collaboration is maybe no more than 20% of the job. Focus is the rest.
I know that's the financial/cynical case (and probably the more common one). However, I know people who genuinely prefer it because you all get to be in the same room and talk all day. They tend to be really extroverted folks.
Most software developers are introverts, though. So that may be fine for UX or graphics designers, but it is less reasonable for software development.
My team would all be on headphones at their desks. It was an actual team rule that discussions were not held at desks, you took them to one of the open areas with white-board walls and hashed things out. Or a conference room. We did that. It would have been much easier with cubicles or offices.
I used to work in cubicles, they were an improvement over open plan. Space for your books, semi-privacy, the white noise speakers didn't need to be turned up as loud (my gosh when those things were off it felt like you were no experiencing auditory suffocation). But a few of the senior engineers had offices. When we needed to collaborate, we'd gather in the office, hash stuff out, and go. It was good stuff.
I've also done the war room thing. We took over an exec's office. I played music for the team at a reasonable level (CDs only, 'twas in the time before YouTube), and we built stuff. But even there we developed a code of behavior of how not to interrupt each other.
Even that was better than open plan, because we could close the door and do our job. Every once in a while a PM would knock for a question or two. Open plan was worse.
Now we all work from home, more or less. In some ways, that's even better for focus, but definitely worse for collaboration.
sounds great for productivity to have someone with your role in any office :) doesn't even matter if the person you are helping is less qualified as you or moreso, pair programming when stuck is one of the great joys of this profession imo and I dont get to do it as much as would be ideal. Maybe I should go to others more but im always stuck with my workload as it is.
On a side note I'd love to go with noise cancelling headphones but im afraid of tinnitus - have you used them much, did you experience it?
I've heard some stories that specifically active noise cancelling can cause it, especially when it's misconfigured so it's not perfectly in sync with sounds. I think I heard about it on a post here on hacker news a few months back?
I agree. Ever since I started working remotely, I've seen an increase in the quality of work I produce. This is partly due to having a quiet environment at home. Also partly due to having more energy to put into work because of having no commute.
I do think people should disable unnecessary notifications and setup blocks of focus time on their calendars.
Semiconductors are at their least efficient when they are neither on nor off, neither here nor there. I think humans are the same. Workplaces (read: managers) have an obligation to foster a culture of deep work - it's unreasonable to expect individual contributors to constantly be fighting a culture of disruption, to be expected to be available to respond to an endless flood of alerts, requests, notifications, interruptions, and direct messages while also maintaining some semblance of productivity. The inevitable result, at least for mere mortals like me, is burnout.
On most days, I spend more time trying to enter 'the zone' than actually in it. At the end of the day, I feel exhausted despite having accomplished very little. It is indeed a miserable experience.
> On most days, I spend more time trying to enter 'the zone' than actually in it.
On a good day, it takes me about 20-30 minutes to enter "the zone", but only about 5 minutes of distraction to be pushed out of it. This is the main reason why I quit my job when they moved to an open-office layout. The constant disruptions were absolutely destroying not only my productivity, but my happiness.
But that should be done on your schedule, not on theirs (most of the time) so that when you are done talking to them and you have a good idea of what to build, you can go crank out a high quality first version. This version will be on the right track, technically: good architecture, usable performance, well-tested, with minimal bugs. This is a first iteration you can go take to users to get concrete feedback and keep iterating.
This is wrong. If you think you can build the right product from the outset, and then just refine it by talking to users, then you'll end up with a garbage product. What good architecture and usable performance look like depends on the user feedback. You need to get something in front of users as soon as humanly possible - if that's something that's well-architected, with few bugs and good perf then you've already spent too long on the app.
This is something that first-time founders find really hard to understand. They're scared of 'losing potential customers' by showing them something that's truly bad. They should actually be scared of wasting time and runway building the wrong thing.
There's every possibility that the first version of an app you show to users is totally wrong. It doesn't matter how good the code is. If you're focused on building good code from day one then you're getting it wrong. High quality code comes waaaaay later in the process.
Have you done this successfully yourself? You’re saying the opposite of what many people with startup experience recommend.
I found out why ‘build something great and they will come’ is usually not true, the hard way, by blowing my own savings along with other people’s investments doing it. Great products almost never go viral on their own, they need tons of iteration and feedback. Most developers who have a truly great idea, including yours truly, don’t understand that their great idea doesn’t appeal to most people, or like in my case that people like the idea but they each have 3 different things they consider much more important, and you can only find out which great ideas have mass appeal by talking to a lot of people.
Normally, the wise startup advice is to listen deeply to a lot of people, to not jump to implement exactly what they’re asking for, but hear more broadly what their problems are and what they need. The advice is not to stop listening and ignore them, and it is not to consider listening a waste of time, the advice is to listen first and then read between the lines.
‘Build it and they will come’ is practically an anti-meme in the startup world, you can find tons and tons of examples of this failing to work, and tons of examples of wise people with experience advising to get this idea out of your head ASAP.
I'm not saying don't market it. But I'm also saying you should have a better vision than "well gee what should we make, world?" That's pretty pathetic. Have passion in what you want to do, it should be personal. If you have a problem, there's countless others with that same problem.
Showing it to them and pointing out the problem is hard, yes.
This isn’t what @onion2k was talking about, so straw man, no?
You’re also talking in platitudes. Having a passion for what you do isn’t a recipe for good business, and isn’t necessary. It might be great for you, if you want. But people with actual experience have learned this repeatedly.
They weren't addressing my main point, so the straw man started earlier, no?
Cliche HN words aside, they started with a personal question, which I can't answer as it would dox me.
Then their main point concerned the lack of going viral, which has nothing to do my point.
They said "Great products almost never go viral on their own". I'm saying build a product you think is great, fuck others bad advice, then market the shit out of it and make people realize how great it is.
> But people with actual experience have learned this repeatedly.
I have experience in this. The real pioneers aren't doing that. It's just a SV meme to maximize their shit product, it's the best they can do without a vision.
They won't stay though, because their opinion is unlikely to be the same as your opinion, and people only spend money on things that they think are good.
You might believe your app is the greatest thing in the world, but that doesn't matter at all. You're not trying to persuade yourself to buy; you need to persuade your customer that the app is good. Clue: They're not looking at the code.
Also, 'good' is a measure of usefulness rather than quality. People will spend a lot of money on absolute trash if it solves a problem that's costing them more money or time than your app, no matter how bad your app is.
I'm not specifically talking about code quality, but usually that goes hand in hand with the product. An engineer that makes quality code will usually also care about the product quality overall as well. Good code quality makes that quality product maintainable and fun to work in.
That being said, your product's traits are phenotypes of your code design. Its performance characteristics, its capable features, how it scales, everything is intertwined. Involve your developers more in the product planning, don't try to plan it for them and just hand them a spec. I've seen too many "product managers" and officers try to be engineers... That's like a real estate tycoon making blueprints for an architect.
You will probably fail if you want to "do high quality code later" as your product will be shit because it's DNA is trash.
And yes, you are trying to persuade yourself, you should be user #1 and your ultimate fan.
Find a problem you have or recognize, and develop a solution you believe in.
Others can barely even recognize there is a problem in the first place, let alone find the optimal solution.
You can listen to others for minor adjustments after the fact, but your product vision is solely on you.
> "If I asked my customers what they wanted they would've said faster horses"
The thing about this saying is that it ignores what the customers actually said they wanted. People who have a need will generally have a solution in their head. Saying they want "faster horses" is saying two things: what they want (faster travel) and their stab at a solution (horses).
Ignoring what a customer says they want is a recipe for missing the mark. Accepting the solution they have in their mind at face value is also a recipe for missing the mark. What should be done is to listen to the customers and take them seriously, then work out a solution. That solution might, indeed, be "faster horses", or it might be something else entirely. But you won't get to a great solution by pretending people don't know what they want.
> Users generally have no idea what they want, especially related to novel things.
This gets uttered like a mantra, and there is a kernel of truth to it, but people often take the idea too far -- so far that it becomes false.
People generally know what they want to accomplish. People generally know what workflows work for them. Around the edges, they may not be aware that a particular change will improve their lives -- but in the main, they're pretty good at telling that.
> If you waste time listening to the masses and have no initial vision of your own
You need both.
> Build something great and they will come.
This is not generally true, and I've seen many, many ventures fail because they believed this. History is jam-packed with objectively great things that were build but were rejected by the masses.
I think this mostly happens because the great thing did not address what people really wanted, and the company did not properly determine what people wanted. You can build the greatest doohicky ever made, but if it doesn't actually meet a real need in people, nobody will come.
You are both right, because you are talking about very different parts of the development cycle.
When you are coming up with product ideas users have no idea what they want. When you show the user what they really want though they can see many useful improvements that can take you from "great idea but useless in the real world" to "great idea that I can't wait to use". You have to go through both phases, first figure out what the users really want and deliver, second figure out what else the user needs in order to make it useful. You learn different levels of detail from the different parts, both are critical.
talking to users != blindly implementing what they say
Users are amazing at indentifying issues, but poor at coming up with solutions to them. User feedback often needs converting to be usable. "I'd like my horse to be faster" -> "I'd like to get to my destination faster".
I like the Slack = open office analogy. One thing that drives me nuts with apps like MS Teams is there is no way to throttle notifications and I have to constantly mute/unmute chats/people. Some of my peers have a hard time communicating in complete sentences and instead send a constant stream of word pellets. This gets really distracting as you then get a barrage of notifications. It would be great if I only got a notification every X minutes.
> Some of my peers have a hard time communicating in complete sentences and instead send a constant stream of word pellets.
I never had a word for this, but word pellets is perfect. You get pinged by someone (breaking your train of thought and forcing a context switch) and then have wait for them to send you 10 messages to get their thought across.
I abide by this rule here: https://www.nohello.com/ Older than the hills, but some people still need to be shown.
I personally don't care much when people do this to me, tho. I just use Slack asynchronously, so I will take up to 30 minutes to answer the first hello, and then 30 minutes to answer the question. ¯\_(ツ)_/¯
If I haven't messaged a person for a long while, I'll say "hello". I just can't bring myself not to do it.
But what I don't do is make it a separate message from the one I really want to send (as that web page suggests). So it's like "Hi Joe! I need to find out about <x>. Can you help me?"
> MS Teams is there is no way to throttle notifications and I have to constantly mute/unmute chats/people.
I have disabled all notifications entirely because of how disruptive they are (not only from Teams, but from all applications). Now I just remember to check the little light on the Teams tray icon when I have space to handle chats.
This one is an epidemic and the worst one. Shipping just to ship.
> Corollary 4: isolation
I disagree with the isolation part, that's subjective. I work better with no human contact, even for long extended times. Humans are distracting, that's why I prefer working at late at night. I assume people are on a spectrum of how much "isolation" is optimal for them.
> You cannot live in a vacuum: you have to talk to users and stakeholders and your teammates and your manager. But that should be done on your schedule, not on theirs
I don't disagree with your post or this part... but this part, you may need to get a reality check on.
You are not the only and most important contributor. Your users and stakeholders have a lot going on too. If you are finding that your throughput is diminished by distractions, that should be quantified and accounted for in your Sprint (or whatever estimation method you are using).
This is hard to actually accomplish IRL, I get it. But just demanding that everyone else adjust to you is not productive.
> You are not the only and most important contributor.
Hardest disagree possible. I don't know where you work or what your role is but many teams have the people in technical roles practically writing the emails back to the clients. There's a huge swamp of talking heads to be drained after the layoffs and other "organizational change" that's occurred over the last few years.
Ideas will always be, and necessarily by definition, less valuable than implementation details. Any attempt at refuting that is insanely delusional. The chickens have come home to roost at so many workplaces.
Who gets to have their meetings at the end of the day instead of first thing in the morning? The execs? Sad.
I think that "first thing in the morning" meetings are the best (after "no meeting") when it comes to interruptions, because it means that you won't be interrupted later during your day. In fact the point of these meetings is usually to know what you will spend the rest of the day doing, so that managers won't have to bother you with that during the day.
Also, as a night owl, the start of the day is mostly dedicated to finishing waking up and waiting for caffeine to take effect, so I wouldn't be very productive anyways.
> it means that you won't be interrupted later during your day
I've never worked in a place like that. What usually happens is that you're getting asked "quick follow up questions" throughout the day as your statements bubble up the rest of the hierarchy throughout the day. Inevitably someone wants to call you and steals 15 minutes and all your flow.
I must be in an unusual company then. I rarely hear about my managers if I have done a meeting in the morning. I get my share of interruptions later, but these are usually technical questions from other developers or testers, or emergencies, but almost never regular project management stuff.
But after that, I would generally just circulate and see who was having problems, and help them. And honestly, helping the kids and teaching them was something I really enjoyed. So I see both sides of this debate.
But on the other hand, at one point the manager told me he thought our productivity was a direct result of our open office setup, and I asked him who the top 3 developers were. He named them, and I had to point out that all 3 had noise canceling headphones on to block out all the collaboration.