Great developers, on the other hand, are thinking about WHY the solution works, the amount of effort they had to put into getting the solution working, and HOW to reduce the time to a working solution the next time they have to build something similar.
Insightful thinking about solving bugs makes a great boost in programming skills
At last a git workflow site that makes sense for the 21st century!
Print Versions, All the Time
Nice little advise, regular habit.
it is best to limit the number and scope of branches in your repository. Most implementations suggest that developers commit directly to the main branch or merge changes from their local branches in at least once a day.
Actually this is the "agile" motto - release early, so no long feature-branches.
discovering failures as early as possible is important to minimize the resources devoted to problematic builds. To achieve this, prioritize and run your fastest tests first. Save complex, long-running tests until after you’ve validated the build with smaller, quick-running tests.
Build articulated jobs to identify early low-hanging spoiled fruits.
When making these significant decisions, make sure you understand and document the trade-offs you are making.
Leave a coherent trail about the decisions behind the CI machinery.
So while running “all tests” in all builds would be ideal, reality dictates that we prioritize testing and run certain types of tests in certain stages of the dev/test cycle. There are a few ways to achieve prioritized testing:Having one automated build process that runs only the basic set of tests, and trigger additional tests manually.Having several build configurations: one for a basic set of tests, one including some more tests, up to the full production build which includes all tests. These sets of tests create numerous builds that are using almost the same artifacts, creating duplication and room for error. Not to mention maintenance-hell. Also, this approach limits flexibility to some extent. For example, what if a developer wants to execute a specific automated UI test to see if a change broke the interface? That will have to wait for later in the dev/test cycle.
Describe the need for flexibility to select one out of multiple build/test configurations.
Not really providing practical advises.
Here are the impressive detailed statistics from their repository as of 2015, for which more recent data is challenging to obtain.
Interesting statistics (mostly inside diagrams) from 2015 on Google's big [[monorepo]] (which is NOT git).
‘Programs are meant to be read by humans and only incidentally for computers to execute.’
Donald Knuth's famous insight that we use code to communicate to other humans, first.
Give the same task to a junior developer, and they might code it faster because they do not think twice while reading a requirement. Their approach is more like converting English to Java (or whatever programming language they use).
Indeed, not only younger programmers are thinking faster, they have much less mental burden when programming.
Interesting journal on issues like:
If a Thrive employee sends an e-mail to a colleague who is on vacation, the sender receives a note that the colleague is away and the message is automatically deleted.
Completely delete received messages during vacation, while extreme, does work!
oving past the paradigm of associating e-mail addresses with individuals. When an address is instead assigned to a specific client, or to a specific type of request, and monitored by multiple different employees, it can go a long way to relieving the deeply-ingrained anxiety that we are ignoring those who need us.
Multiple assignees in a project relieve pressure on individuals!