markshead

Too often a daily standup is really just a way to try to make sure everyone is busy. Asking everyone what they did yesterday, what they are going to today, and if they have any blockers, doesn't usually help the team coordinate their work. As you point out, it just puts people on the spot to try to say something that makes them sound important.

But if you ask the team, "What can we do today to make the most progress delivering this next tiny slice of functionality for the customer?" the discussion is centered around the work. Usually introverted people can participate in that conversation without being uncomfortable.

That is an excellent point. If everyone knows exactly what the next most important thing is for the customer, and they are already working collaboratively to deliver it, maybe the meeting only takes 5 minutes. Or maybe the coordination happens informally just in the way they are working.

If you are trying to "do Scrum" it doesn't matter. You have a formal standup meeting because Scrum says to. That is how you end up with teams going around answering three questions that have absolutely no impact on anyone's work for the day. If you are trying to deliver the software, then you should be free to mix things up to better deliver.

Now in practice, most teams do benefit by spending a few minutes making sure everyone is on the same page for how they are going to work together efficiently for the day even if it is very short. I've seen some teams where most of their standups take 90 to 300 seconds...but the team felt it was a valuable way to collaborate. If the people in the daily standup don't feel it is a valuable use of their time, then it probably needs to change.

I haven't ever seen an organization focused on "doing Scrum" that gets good results. However, some teams trying to deliver working software iteratively for their customers do find Scrum lets them deliver better than what they were doing before. But when Scrum becomes the goal and takes precedence over delivering software, it becomes a liability.

Getting everyone together for 15 minutes each day to ask, "How can we coordinate our work to make sure we are all doing our best to deliver the next piece the customer wants?" is valuable. Showing the customer what you built over the last week and asking if it needs any changes is also really valuable. Occasionally taking time as a team to discuss ways you can improve? Again, very valuable.

But the value comes from the collaboration each activity enables. Just because you have a 15-minute meeting you call a standup, a demo, or a retrospective doesn't mean people are actually collaborating in a valuable way.

> Video was supposed to be the future. Instead, it’s just another way to pick up the phone.

If you are using it to replace a phone call, then yes. It is just another way to pickup a phone.

On the other hand, I've worked with teams that use video as a virtual team room where a small team (3 to 5 developers) hangs out most of the time just like they would in a physical team room. They tend to mob or pair program most of the time. Sub groups break out occasionally if they need to work on something in parallel. Business owners just "drop in" to ask questions or provide feedback. Other teams that need to coordinate just jump into the room instead of trying to setup meetings.

Not every one wants to work like that, but video can provide a way of enabling highly collaborative environments that typically would only happen by giving the team their own room and requiring everyone to come into the office.

There are few better ways to increase your learning on a technical topic than to write a post about it and get lucky getting traction on HN. I wrote a post on State Machines a few years ago and the feedback I got from the HN community was incredible in helping me refine the post and deepen my understanding of the topic.

(https://blog.markshead.com/869/state-machines-computer-scien...)

Back in the early 2000s I had a blog where I would try to post multiple times each week. While I wasn't a poor writer before, it was amazing how much I learned about overcoming writers block and being able to quickly get ideas from my head into a text file. (https://www.productivity501.com)

Later I had a blog post answering some key questions about Agile on a different site. That post didn't get much attention, but it was a good exercise in articulating part of what I'm trying to convey when coaching software engineering teams. (https://blogs.harvard.edu/markshead/what-is-agile/)

After reworking the post into a concise PDF, I sent it to a few people at a potential client. Later, after I had been awarded a contract, I found that the PDF had gotten emailed around within the organization and many people knew me as the "guy who wrote that PDF about Agile."

I then took the contents of the PDF and reworked it as a script for an animation that I posted to YouTube. That video now has 2.7 million views and has given me quite a bit of recognition in the industry...or at least recognition of the cartoon version of me. I hear he is much better looking anyway. (https://www.youtube.com/watch?v=Z9QbYZh1YXY)

I think took the general ideas from the blog post, the paper, and the video and put it together in a book that I generally give away like business cards to potential clients. (https://www.amazon.com/Starting-Agile-Finding-Your-Path/dp/1...)

The practice of writing on a blog has been key to my career, even though a lot of the benefits are a bit indirect and not something people would recognize from the outside.

A few books that I've found useful:

The Goal - Eli Goldratt - It is a novel about optimizing a factory, but it is immensely valuable in thinking through what are the actual constraints on your team's ability to deliver software and how do you fix it without making other things worse. The Phoenix Project is kind of a modern retelling, but I'd start with The Goal.

The Principles of Product Development Flow - Reinersten - Great for thinking deeply about how you deliver value through your system and the tradeoffs you are making in what you choose to focus on next. Once again it isn't specific to software, but very relevant.

The 5 Dysfunctions of Teams - Lencioni - Common team problems and what to do instead.

Influence: Science and Practice - Cialdini - How to get people into agreement so you can move forward--a skill that can be used for both good and evil.

The Little Schemer - Friedman and Felleisen - It is kind of hard to describe why this would be useful, but I felt it made me think more deeply about what it means to program a computer in ways that indirectly supported the topics you mentioned. Or maybe I just happened to work through it at a point in my life when I was growing in those other areas too.

A decade ago Harvard Extension School's ALM in Software Engineering was a good match for what I was looking for as a self taught programmer with a Bachelor's and Master's degree in another field. There was a good blend of computer science fundamentals along with classes in modern (but not necessarily trendy) technologies. At the time it was also fairly inexpensive relative to other comparable options.

Programs vary widely, but if you can find one with a degree plan that aligns well with your goals it can be valuable. While there are definitely ways to learn everything on your own, I've found the credential helpful as a foot note to a track record demonstrating skills.

My biggest recommendation would be to work on a Master's degree part time in order to be able to do "real" work while studying. A Master's degree with 4 years of real world software engineering experience is going to be so much more valuable than a Master's degree from two years of just focusing on school.

> "Jira is the worst project management tool, except for all the others"

This is key. The problem with Jira is less about Jira as a tool and more about how we approach project management.

I've seen some teams thrive with Jira. I wouldn't say they "loved" Jira but they had a light weight project management structure that let them get work done and enough control over Jira to set it up to stay out of their way. They didn't give Jira credit for their ease of working because it was their processes that were good. Jira just gave them a way to not have to write everything down on paper.

I've seen other organizations create a horrible project management structure and then use Jira to "enforce" those structures in ways that magnify all the worst aspects of what they are doing. In those situations it is usually more politically palatable to blame Jira rather than the management processes. Those type of organizations usually blame the tool while hoping that a different tool will force the organizational changes that are needed to make life better.

I was once looking for a solution to some technical problem, clicked on a promising web result, and found myself at my blog. I had posted a solution several years earlier but had forgotten about it.

Felix Mendelssohn wrote a collection of pieces called Songs without Words for the piano. This might suggest that the term "song" can be more nuanced than simply whether or not there are vocals.

> Those with extreme views certainly do exist but they tend to be pushed to the front by those who have vested interests against homeschooling.

On the flip side, many homeschoolers have encountered public school teachers with extreme views. Extreme views may be fairly well distributed throughout society.

I've had good luck with video team rooms vs. having lots of video meetings scheduled. With a video team room you basically "hang out" like you would in a real team room. You might have 4 people with one sharing while another helps work through the current issue and the other two are working on related things and just being present to help if needed. In that type of setting the informal self seems to work about the same as it does when working together in a physical team room.

I own a home in a very rural part of the US, but do a lot of work with people in large cities. I was talking with some people in NYC about our 5 bedroom home that we bought for $120,000 and how most of the houses for sale in our town are about half that price. The people from NYC couldn't imagine such a thing. One said, "So does that mean that no one needs to take out a loan to buy their home?" I explained that the people in my town weren't making NY level wages either.

The idea that there were parts of the US where you could buy a house for $60k was just as foreign as the idea of someone making $25k per year. They simply had no frame of reference for what wages and cost of living look like in places that weren't big cities.

Just having a book that you've written on any topic listed somewhere on your resume is nearly always a positive. It is kind of like having a college degree in that it shows you can start something and finish it.

If you like the idea of a small lisp machine, you should look at uLisp. Last time I priced out the components they came to somewhere in the $20 to $40 range.

Do most people think that autopilot is used to avoid other planes and obstacles like mountains? I always assumed autopilot was basically like cruise control for planes and just kept it level, at a fixed direction, and constant speed. Same thing as autopilot on a sailboat.

If that is the case, autopilot on a plane seems to be more like cruise control expanded to maintain pitch, yaw, and roll than autonomous flying.

Also dramatically different than the low cost $13.95 time-of-flight sensors. (https://www.adafruit.com/product/3316)

Obviously, this can be used to simply lie about not having a dog. On the other hand, it is also the way you deal with any objections that might be raised if you are dealing with a claim that is wrong on many different levels. Say that someone posts what they claim is a video showing a Tesla roadster wrecking on autopilot while the driver was watching a movie.

It is very logical for Tesla to point out if it isn't actually a roadster in the photo. Further, they can say that even if it was, the roadster doesn't have autopilot. Even if it was a roadster and the roadster came with autopilot and the driver was using autopilot, the driver is still responsible for paying attention to the road and keeping hands on the wheel.

Nand2Tetris was very good. I think Coursera has it listed as "Build a Modern Computer from First Principles: From Nand to Tetris." The course does an incredibly good job of walking you through building a CPU starting with NAND chips.

Keep in mind there is a whole spectrum of what constitutes thought leadership. Several times, I've had clients say, "Last night I was looking for X and I found a great article on it. Turns out it was something you wrote!"

Another organization was going through their contracting process with me. One of their managers later told me that when they Googled for my name they were blown away by the size of my online footprint. Most of that was simply 10 years of blogging a few times each month about whatever topics I was finding interesting.

Also based on my blogging, I've had fairly well-known companies interview me for their blogs or webinars while using descriptions like "one of the worlds leading experts in X." This was all based on years of blogging on the topic.

Another great way to be viewed as a thought leader is to write a short book. Imagine you are looking at hiring two candidates that both look good, but when you search for their names you find that one has a book for sale at Amazon on a topic of interest to your company. It is a very strong way to market one's expertise.

So where would you put what we call "determination?" When someone has 9 businesses/jobs/experiments/etc fail and gets "lucky" with the 10th one, it seems like there is another aspect other than luck and talent.

I have. It is interesting but didn't really stick for me when I tried it. I've found some techniques that didn't work well in one period of my life work incredibly well in a different period when I'm working on different types of tasks, so I should try it again sometime.

I don't flip it over. Usually I'll go beyond the timer for some period of time because once I get some momentum on a task, I'll want to finish it up. I also use it to timebox activities that can consume the entire day. For example, if my office starts getting messy I may decide I want to spend 7 minutes a day just straightening things and organizing. In that situation, it becomes more of a notification of when to stop and get back to other work.

I have a 7-minute sand timer I picked up for a few dollars. Whenever there is a task I keep putting off, I'll commit to doing the task at least until the timer runs out. It probably sounds silly, but it really helps me get things done that I'd avoid otherwise.

I was just saying that curves of how much is forgotten seem to look similar to a caching mechanism.

I've heard something similar, but I think it had to do with the fact that we tend to "fill in the gaps" if we can't remember something about a situation. So we just make up information. I'm not sure if there are ways to combat this by recalling the information before it starts to decay or not, but it has a lot of implications for eyewitness testimonies.

Our memory is a cache and each timed repetition increasingly delays the purge date of a particular memory.

> Modern agriculture is a highly skilled job done with millions of dollars of capital equipment.

While there is definitely truth in this statement, there is still a spectrum of work to do on modern farms and plenty of it isn't highly skilled. This is especially true on farms that are optimized for high margin vs. volume. For example, organic or local farm to table places.