What version of agile, though?
Team building is pretty constant across all the “flavors” of agile. Building good communication patterns and trust isn’t coupled to the “how we execute” details
Readit Newsdkoston commented on Writing a user manual at work makes teams less anxious and more productive qz.com/1046131/writing-a-... · Posted by u/absolute100
This is a standard agile exercise called “Rules of Engagement”. Should be run with any forming team. I’m always surprised that this knowledge isn’t more commonplace.
dkoston commented on Ask HN: Favorite remote work realtime collaboration tool(s)? · Posted by u/mojomark
Cool, good advice thanks. Could you say roughly. What percentage of the day you'd spend in a collaborative environment vice independant work? I ask because if we were able to physically go into an office, we'd normally easily spend >50% of our time "whiteboarding" our hardware/software system of systems concepts for a few months before we begin the more detailed preliminary design phase that can last many more months.
I want to achieve the same productivity, but I'm very concerned about fatigue. I'm thinking we'll need to break our ideation sessions down into a greater number of shorter sessions.
It depends on the day but not such a high percentage usually. Our design phases don’t last as long (software only).
Virtual meeting fatigue is real because there aren’t as many natural breaks. It is important to make sure that people know they can excuse themselves for water/food/bio breaks.
I’ve also found that virtual whiteboarding is slower for me as I’m used to picking up a dry erase marker. It takes time to adjust to the different work stream but a huge benefit is the quality of the end product (no sloppy hand writing, easy to modify).
I don’t have any direct advice geared towards your situation as our white boarding and planning phases are quite different in my industry.
dkoston commented on Ask HN: Favorite remote work realtime collaboration tool(s)? · Posted by u/mojomark
I’ve recently used https://miro.com/ and overall was a good experience to collaborate
Also using Miro and enjoy it.
In addition to the software, make sure your team has good hardware. A screen large enough with high enough resolution is critical to see the whiteboard. What’s also important is that video from meetings takes up screen real estate and with multiple participants, having enough size and resolution to see them all helps you stay connected. External webcams that can be adjusted are helpful also.
dkoston commented on Show HN: A directory of restaurants with links to buy gift cards to support them givelocal.co... · Posted by u/brentsum
Thanks for putting this together. I’d recommend adding some indicator that the results load async. I thought you had zero restaurants in Austin and left the page after a second because there was no loading indicator. In fact, until I got to Pittsburgh, I thought it was a site with no listings asking for my email (because Pittsburgh loads way faster).
(Adding an index to your database for city or however the queries are formed would probably also help).
dkoston commented on Show HN: A directory of restaurants with links to buy gift cards to support them givelocal.co... · Posted by u/brentsum
In my experience, 90% of locally-owned restaurants have gift cards. So what's the point of a website that attempts to list 90% of restaurants? Why not just use Google Maps?
Sometimes it’s nice to have a list view. Google maps only provides geolocated results in a small list so you’d have to move around the city quite a bit to find the whole list.
It can be useful to be remembered of places you like but haven’t been in a while as well.
dkoston commented on Requirements volatility is the core problem of software engineering stackoverflow.blog/2020/0... · Posted by u/luord
I am reminded of how linguists, when trying to document a language from one of the last living native speakers, don't just ask them to tell them the rules of it. They have to task questions like "how would you say this?" Then they try to reverse-engineer the grammar, syntax, etc.
In most cases, the people who are giving the requirements either: 1) don't actually know them (e.g. they are in upper management but the software will be used by line workers) 2) have internalized the details of the process so long ago that they are essentially subconscious now. They would tell you the real requirements if they could, but they just can't, they will instead tell you what they think the requirements are. Then, once you build it and they try to use it, like the native speaker of a language hearing you speak a sentence in it using the grammar rules they just told you, they will immediately know that it's wrong.
So, the best way to find the _real_ requirements for the software, is to build the software, and have them try to use it. Stop planning and endlessly documenting someone's fantasy or best guess at what the requirements are; the only way to really discover the requirements is to build the thing.
This was essentially the story of how we built a successful software company at cPanel. Our customers would describe things like “I want a button that does this” or “a script that does that” and we had to make many assumptions about what they really wanted. Finally after determine we were spending massive amounts of time on unused features, we developed everything as a workable “beta” feature. The ones that we got a ton of praise or complaints on kept getting developed. The ones with silence stayed the same.
This was before heat map software and click tracking which can do a great job of augmenting customer feedback.
The key part that we found out is that if you take this approach, you have to couple it with high quality software support. We hired and trained folks who knew the entirety of our business and tech (Linux, DNS, HTTP, hosting, etc). Our tech support reps were paid much more highly than others in the industry but it gave us more benefits than just being able to support customers when beta software was ship to prod, it also gave us a training ground for future software engineers, QA folks, SysAdmins, and Product Managers.
What I think a lot of people forget is that software is one piece of the puzzle in solving a problem, it’s absolutely not the whole solution. If you design a process based around connecting with customers on a regular basis and having feedback flow throughout your company, you won’t have to “make perfect features”.
I’ve only worked with a small number of companies since that have understood this. Most I’ve worked with have created communication silos and sit in rooms trying to dream up the perfect set of requirements.
dkoston commented on Ask HN: How do you pay attention to emotions in your remote teams? · Posted by u/altras
Do you not have frequent one-on-ones and regular conversations with your remote employees? How do you learn about their motivations, goals, current situation, or changes?
If you’re trying to replace human interactions and relationships with your employees with single question surveys, you’re going to miss out on all the important context.
Getting good output isn’t about rushing as fast to a goal as possible and not taking time to make sure things are going well. It’s about setting goals that are measurable, coming up with hypothesis about how to get there, and checking in regularly with an objective lens to see if you’re on track or if there’s a better approach.
dkoston commented on Our Tesla Model 3 Suffered a Failure While Parked caranddriver.com/news/a30... · Posted by u/t3f
I am honestly surprised by your blasé reaction. To make an apples to apples comparison, have you ever had a:
1. New car,
2. Which cost almost $60,000, with
3. Fewer than 6000 miles,
4. Suffer a catastrophic failure (i.e. couldn't start with a jump),
5. While parked,
6. And had the manufacturer not communicate the source of failure,
7. Or how long it would take to fix?
That, to me, seems almost unbelievable. I have entertained the idea that our family's next car would be a Tesla, but stories like this make me want to wait another generation or longer.
I bought a VW GTI 20th anniversary (a numbered car) and the transmission broke on my third drive (wouldn’t shift out of third) which was a catastrophic failure. This was about 50 miles deep. Took a few hours to get towed. VW said they would fly in an expert from Germany to diagnose the issue. I opted to get a different car (new number, same model) and that one worked fine. Did I have massive ill will towards VW? no. This was even a numbered car that technically “could not be replaced”. Errors happen.
Statistically, a few hundred thousand model 3s have been delivered and many are well past 6k miles. I think you should wait and hear what Tesla’s reaction is before writing them off.
Things you should consider are:
- they have sold so many cars in the past 2 years that service center growth is struggling to keep up and wait times are long
- Tesla vehicles cannot be serviced easily by third parties so you have no option if Tesla says something you don’t like or wait times are long
Choosing the one broken car out of hundreds of thousands delivered as a reason to not buy one doesn’t make much sense. All manufacturers deliver defective vehicles. Looking at statistics on how many are defective per capita from each manufacturer would be a more reasonable course of action.