Distractions Cause Bad Code (2018)
ntietz.com
ntietz.com
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 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.
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.
Specifically because warehouse-type space in downtown SF was cheap right around 1998-2005.
The most productive space is an office with a door that closes. IBM studied this. Bell studied this. Those studies haven't been invalidated.
Could you link to those? Google isn't returning helpful results for me here.
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.
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 do think people should disable unnecessary notifications and setup blocks of focus time on their calendars.
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 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.
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.
If you waste time listening to the masses and have no initial vision of your own you'll end up with a Frankenstein project.
Build something great and they will come.
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.
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.
Take your time and build something you know is great.
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.
Everyone wants faster travel, you don't need to ask anyone for that, it's not a vision.
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.
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".
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.
Showing it to them and pointing out the problem is hard, yes.
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.
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.
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.
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 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. ¯\_(ツ)_/¯
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?"
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.
Corollary 1: rushed insistence on shipping
Corollary 2: unclear requirements
Corollary 3: supporting too many features and systems
Corollary 4: isolation, poor diet, messy surroundings, lack of exercise, work-life imbalance
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.
Nothing like a mid project design overhaul to send a codebase crumbling to the ground.
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.
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.
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.
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.
Hours of silence is very peaceful.