hamasho

> “does the company optimize for focus time/flow time during the workday”

I like this rephrase too. I've recently joined a new team, and having several synced meetings helped me onboard quickly.

I hate if we need to have meetings or synced work often in the future. I don't want to be interrupted when I focus, so I like communication should be asynchronous by default.

Still, depending on the situation of team members and the project phase, synchronous communication is sometimes much more productive than completely asynchronous work. Functional teams should be able to choose better communication each time. (I know some people like synced communication too much, and it's often more problem, though...)

> ...especially within a country (same pay for California or Nebraska) because movement is so easy.

I can't entirely agree with this.

Yes, it's easier to move if your job is completely remote. But for many people, the most significant barriers are not financial problems but mental ones.

Even though I'm single, I have few friends near my house and am satisfied with my current living environment. It's a bit scary to move to somewhere I don't know. And if I lived with a family, it would be much harder.

That's why the house prices are skyrocketing even though more people have started working entirely remotely. The majority of remote workers are still living in a big town and don't plan to move to the countryside in the near future.

My favorite is `ts`! It adds a timestamp at the beginning of each input line.

I often use it with tee to save the log output of any command.

  $ ping google.com | ts '[%Y%m%d-%H:%M:%.S]' | tee /tmp/ping.log
  [20220416-21:57:20.837983] PING google.com (172.217.175.78): 56 data bytes
  [20220416-21:57:20.838391] 64 bytes from 172.217.175.78: icmp_seq=0 ttl=53 time=6.028 ms
  [20220416-21:57:21.817189] 64 bytes from 172.217.175.78: icmp_seq=1 ttl=53 time=9.621 ms
  [20220416-21:57:22.818339] 64 bytes from 172.217.175.78: icmp_seq=2 ttl=53 time=9.443 ms
  [20220416-21:57:23.823126] 64 bytes from 172.217.175.78: icmp_seq=3 ttl=53 time=8.921 ms

I'm a web person defending web things but providing something on the web has a significant advantage. I know you've heard this again and again, but I can't emphasize it enough.

You can use the site from most platforms, including PCs and mobiles. You don't have to install software, a single click is enough. Of course, browsers have considerable limitations, and serious users will eventually choose other tools, but providing such an accessible software is a really huge advantage for me.

edit: words

Yeah... It's dangerous to accept random YouTubers' content as fact mindlessly.

I'm not sure all he says are correct, but at least he uses the target companies' engineer blogs, external articles, and some open-sourced part of systems (and list them in the video's detail section). His main targets are often big techs like Twitter, Uber, and Netflix, so I guess such documents are often available.

> Other than some very high-profile companies (like Netflix, github) ... it's hard for me to find easily digestible (20-60 mins) examples

So I think this doesn't meet your requirements, but I like Tech Dummies Narendra L's YouTube videos [0]. He introduces big tech companies' systems in 30-60min videos and it's not difficult to understand.

[0] https://www.youtube.com/playlist?list=PLkQkbY7JNJuBoTemzQfjy...

For reference [0].

It should be tough to have such a name. The most important systems like tax/insurance/airline booking are often the most unkind systems. If you're not familiar with computers, it's almost impossible to imagine the potential cause of problems is your name.

[0] https://www.bbc.com/future/article/20160325-the-names-that-b... > These unlucky people have names that break computers

> The problem is at this point I have been on the team too long to ask any basic questions, one of the senior engineers even pointed out they shouldn't be helping me with certain processes at this point.

The senior dev is toxic. Any member should feel easy to ask any questions, no matter how experienced they are. It's almost always better to ask questions immediately.

I've also made mistakes by not asking questions.

I joined a team as a senior dev and worked there for more than ten months. Sometimes, I felt like I didn't understand very basic contexts in the meetings. I couldn't ask what they were talking about because I was afraid of being seen as an incompetent dev.

It turned out that they forgot to invite me to one of the most important Slack channels, where the product owner, the marketing team, the executives, and devs had discussions on important business decisions and the direction of the entire dev team. I was the only member who didn't follow the channel, so know nothing about the important decisions.

We found out that after ten months, and they apologized for the mistake. And they even prized me for being productive despite not knowing the decisions made in the channel. But I was really ashamed of myself. I felt like I lacked some basic context a dozen times but never asked "sorry, what are you talking" even a single time. Instead, I pretended to understand what they said.

Once I followed the discussions there, I became more productive due to much fewer communication errors on the business decisions and direction of the dev team. Since then, I've tried to ask any questions as soon as possible.

Fantastic!

I feel really superior when I succeed in clicking immediately after the previous click. I clicked on the target arc and was relieved. But I immediately realize the next arc is right there, or I'm even on the arc now! Then adrenaline kicks in, and I click again immediately! Don't think, feel! And it continues because I haven't missed it.

Like I was a top F1 driver...

I guess they don't like it. If the device is not broken, but the user is dead, they have fewer consumers and more good devices in the secondhand market, no profit. But if the user survives and the device is broken, he or she continues to buy Apple products, at least the next one immediately, profit!

I'm sure "Nintendo Router" would be much more terrible product...

Somehow, I too see a lot of features that exists solely to increase the company's profit and only annoy customers. I always wonder why they think this is a good idea.

But then I remember I often implement those features as a developer. And sometimes, when I ask the marketing people or product manager, even they look to think it's a terrible idea. They are also forced to release something BS but can increase some KPI.

I think it's good that well-founded institutions publish well-crafted datasets for everyone else. It helps small teams develop their model.

The problem here is, though, most publishers don't accept papers if the new proposal isn't backed by benchmarks by the well-known datasets. Even though it can be a competitive approach for a specific field, they reject the paper anyway if it's not performed well on the datasets.

I agree with that.

But it's worth noting that we need to spend more time on task management with a shorter development cycle. In waterfall or scrum or whatever, one development cycle often comes with listing tasks, prioritizing, planning, developing, retrospection, or something similar. If the cycle is long, we can spend more time on each process. But if the cycle is short, we rush to complete each process and can't spend enough time understanding each process's meaning. So I focus more on consuming as many stories as possible. I never think about the product's goal and how I can contribute to it.

So we have to spend more time teaching the purpose of each process. Or we end up as a failed agile development.

Additionally, as a start-up, we rarely know what the product should be. We have a first vague idea of the product but don't know what it exactly is. Commonly, the ideal product is different from the initial design, and we only know that after the actual design, investigation and development. If it's the nature of software development, the development framework should be capable of design change in short terms. Agile development styles are trying to solve it. Unfortunately, many projects failed to adopt it because they don't understand the purpose of agile soltware develoment.