Yegor Bugayenko:

Only weak managers need daily stand-up meetings to coordinate the team, while strong ones use more formal instruments to organize the flow of information. However, as someone noted, morning meetings are not supposed to be used by managers to coordinate anyone, but “to discuss progress, impediments and to plan.” I’m not buying it.

We had a lively discussion on this very topic on yesterday’s recording of The Changelog. Stay tuned for that episode coming next week. 📻

Some time ago I wrote a blog post An Open Code Base Is Not Yet an Open Source Project where I suggested a few important qualities of a good open source repository/project. One of them was the well-written README file. Here I will try to give a few hints on how to create a good README file and what mistakes to avoid.

A solid README is a must-have for all open source projects. Thankfully, many folks have been taking their READMEs more seriously as of late. If you’re one of ‘em, check out this post and see if there’s anything you can improve.

Yegor Bugayenko:

As you most probably know, I advocate for a dictatorship role of a software architect. All decisions are made by the architect must be final and non-disputable. However, the obvious question is: What happens if the architect is wrong? Does it mean the entire project is at risk of failure? And isn’t it better to make the whole team responsible for the result, instead of having one single point of failure?

On the other hand, if the architect happens to be Will Ferrell…

Yegor Bugayenko:

Now here is a simple, plain list of recommendations for you: what you should do if you want to be a more successful programmer. Not a better algorithm designer, even though that’s important. Not a funnier team player, even though that’s also important. But a more successful software engineer, both financially and socially.

Of the 14 recommendations, I’m happy to report that I regularly engage in 10 of them! The only one that I’m diametrically opposed to is Earn Certificates. No thanks!

What do you think of Yegor’s recommendations?

Yegor applies a kitchen metaphor to code:

The kitchen is clean when there is no dirt in the oven. But if its electric panel speaks French, I can’t use the kitchen. Even if it’s perfectly clean. It’s not clear how to use it—that’s why it’s useless.

Sounds good to me, but how do you know if your code is actually clean and clear? He provides a heuristic:

If a stranger can modify your code and fix a bug in less than an hour, it is maintainable.

The entire post is well worth a read.

Yego Bugayenko:

Here is a simple principle for naming methods in OOP, which I’m trying to follow in my code: it’s a verb if it manipulates, it’s a noun if it builds. That’s it. Nothing in between. Methods like saveFile() or getTitle() don’t fit and must be renamed and refactored. Moreover, methods that “manipulate” must always return void, for example print() or save(). Let me explain.

Naming objects well has been a career-long struggle for me. I just might give this a try…

Laziness is one of the three great virtues of a programmer (laziness, impatience, and hubris) Larry Wall talked about in Programming Perl.

The “deep thinking,” as they call it, which is always required before even a small issue can be resolved, seriously turns me away from programming. Or did turn me away. Until I started to think differently and encourage myself to be lazy. Here is how.

Iteration! It’s so freeing to operate on the basis of iteration — knowing that today’s version is shipping with flaws that can only be resolved through the feedback loop. In this case, incremental is an alias of iteration.

Software development is perfect territory for cutting corners, being lazy and remaining calm, because our work is often discrete and can be very incremental.

Yegor Bugayenko:

Thread-safety is an important quality of classes in languages/platforms like Java, where we frequently share objects between threads. The issues caused by lack of thread-safety are very difficult to debug, since they are sporadic and almost impossible to reproduce on purpose. How do you test your objects to make sure they are thread-safe? Here is how I’m doing it.

Great details on a particularly difficult aspect of testing. ✨

Yegor Bugayenko:

Fluent interface, first coined as a term by Martin Fowler, is a very convenient way of communicating with objects in OOP. It makes their facades easier to use and understand. However, it ruins their internal design, making them more difficult to maintain. A few words were said about that by Marco Pivetta in his blog post Fluent Interfaces are Evil; now I will add my few cents.

Yegor uses his own HTTP library as an example where the interface designed is fluent (which looks nice and readable to use) and shows how that design goal made the internal code a mess. My gut tells me it’s worth the trade-off to provide a better user experience, but Yegor’s real-life experience punches me right in the gut:

Fluent interfaces are perfect for their users… However, the damage they cause to object design is the price, which is too high.

He suggests decorators and smart objects as an alternative. Lots to ponder here, and the conversation going on in the comments is lively as well. 👌