BOOK: Beautiful Code (Leading Programmers Explain How They Think)

Using a similar idea used for Clean Code, this book talks about... Beautiful Code. (PS. When will the Fluffy Code book come out?)

Beautiful code » nvie.com


Quoting (nvie.com):

""The book's concept is simple: each of the 33 chapters is written by a well-respected professional programmer who answers the question: "What is the most beautiful code you've ever seen?" after which they discuss elaborately why they think it's beautiful."


Quoting Amazon.com (this is the link to buy it):

"How do the experts solve difficult problems in software development? In this unique and insightful book, leading computer scientists offer case studies that reveal how they found unusual, carefully designed solutions to high-profile projects. You will be able to look over the shoulder of major coding and design experts to see problems through their eyes. This is not simply another design patterns book, or another software engineering treatise on the right and wrong way to do things. The authors think aloud as they work through their project's architecture, the tradeoffs made in its construction, and when it was important to break rules. Beautiful Code is an opportunity for master coders to tell their story. All author royalties will be donated to Amnesty International."

VCS: What is Gitflow? (Introducing GitFlow article)

What is Gitflow? Here's an article (the article) explaining this way of working with Git: Introducing GitFlow
The original blog post can be found at https://nvie.com/ ( https://nvie.com/posts/a-successful-git-branching-model/ ).

Quoting:

"What Is GitFlow?

GitFlow is a branching model for Git, created by Vincent Driessen. It has attracted a lot of attention because it is very well suited to collaboration and scaling the development team. Key benefits include: 

Parallel Development

One of the great things about GitFlow is that it makes parallel development very easy, by isolating new development from finished work. New development (such as features and non-emergency bug fixes) is done in feature branches, and is only merged back into main body of code when the developer(s) is happy that the code is ready for release.

Although interruptions are a BadThing(tm), if you are asked to switch from one task to another, all you need to do is commit your changes and then create a new feature branch for your new task. When that task is done, just checkout your original feature branch and you can continue where you left off.

Collaboration

Feature branches also make it easier for two or more developers to collaborate on the same feature, because each feature branch is a sandbox where the only changes are the changes necessary to get the new feature working. That makes it very easy to see and follow what each collaborator is doing.

Release Staging Area

As new development is completed, it gets merged back into the develop branch, which is a staging area for all completed features that haven’t yet been released. So when the next release is branched off of develop, it will automatically contain all of the new stuff that has been finished.

Support For Emergency Fixes

GitFlow supports hotfix branches - branches made from a tagged release. You can use these to make an emergency change, safe in the knowledge that the hotfix will only contain your emergency fix. There’s no risk that you’ll accidentally merge in new development at the same time."

Management: Amazon and the no-powerpoints meetings

Memo-driven meetings vs. PowerPoint-driven meetings:
https://www.businessinsider.com/bezos-admits-amazon-has-the-weirdest-meeting-culture-2018-4

Quoting:
"During an onstage interview Friday, Amazon CEO Jeff Bezos explained the strange meetings that Amazon holds.

Each meeting requires a well-crafted, six-page memo that the whole room sits and reads at the start.

Bezos banned PowerPoint years ago, and explained why the memo-driven meeting is far superior."

Management: JIRA as an anti-pattern?

Of course. Can you describe [i.e. extract the technical baseline of] a product (information system, etc.) from it? From epics and (overlapping and/or contradictory) user stories? Hardly:
https://techcrunch.com/2018/12/09/jira-is-an-antipattern/

Quoting:
"I’m not saying JIRA has no place. It’s very good when you’re at the point where breaking things down into small pieces and finishing them sequentially does make sense. And, unsurprisingly given its history, it’s exceedingly good at issue tracking.

Let me reiterate: To write elegant software, you must keep both the macro and the micro vision in your mind simultaneously while working. JIRA is good at managing micro pieces. But you need something else for the macro. (And no, a clickable prototype isn’t enough; those are important, but they too require descriptive context.)

Allow me to propose something shocking and revolutionary: prose. Yes, that’s right; words in a row; thoughtfully written paragraphs. I’m not talking about huge requirements documents. I’m talking about maybe a 10-page overview describing the vision for the entire project in detail, and a six-page architectural document explaining the software infrastructure — where the city’s water, sewage, power, subways and airports are located, and how they work, to extend the metaphor. When Amazon can, famously, require six-page memos in order to call meetings, this really doesn’t seem like too much to ask.

Simply ceasing to treat JIRA as the primary map and model of project completion undercuts a great deal of its implicit antipatternness. Use it for tracking iterative development and bug fixes, by all means. It’s very good at that. But it is a tool deeply ill-suited to be the map of a project’s overall vision or infrastructure, and it is never the source of truth — the source of truth is always the running code. "