Things to think
- Engineering productivity can be measured is a bold statement, after so many years of trying to quantify software development. In this article, the author states that most metrics you try to get from a team, can - and will be challenged by engineers. The most simple example is to measure lines of code. Engineeres will find ways to improve the number of lines of code tremendously, without affecting effectivity. On the other hand, not measuring at all won't help either. The bottom line of the article is to measure blockers:
Engineering should instead be about effectiveness: "How able is this engineer to effect positive impact?"
- Quality of developer tools
- Frequency and quality of internal activities (like meetings or code reviews)
- Focused maker time (free from disruptive meetings)
- Easy access to documentation
- Psychological safety on the team
- Work-life balance
- Presence of other high-performers
- A fair system of rewards
-
LoRa two-way pager a concept I even once realized on a breadboard. This project goes a few steps further in terms of portability and reproducability.
-
Modern retro computer terminals A collection of self-made 3-D printed computer housings.
-
Analogrechnen (German) Fun and entertaining talk about analog computers, especially electronic analog computers. A quick way to calculate otherwise hard to implement operations like integrations on digital computers. Requires special hardware though. (The speaker mentions CORDIC)
-
Blogger Peer Review Thoughts and links about peer reviews for blog articles. Also mentions knowledge graphs
-
My Second Year as a Solo Developer Main take-away for me is that having less income than spendings is okay for a while because it makes the savings last longer
-
Many Strategies Fail Because They Are Not Actually Strategies
-
First You Make the Maps Visualization of Map history (see Books - Mapmakers)
-
The Tao of HashiCorp Patterns inspiring me to use in software development
-
Simulating identification by zip code, gender, birthdate Seemingly not very personal data can be used to identify persons (also see Differential Privacy for Dummies for a solution)
-
Engineered Materials Arrestor System – Wikipedia Systems to stop rolling objects, for example airplanes overshooting the runway
-
Hype Tech Presentation from fefe
-
Sales Deck Five steps for a sales narrative
-
Label Schema | Bringing Structure To Labels Organize labels and tags. Standard to make collaboration easier
-
Apple’s New Map and their path to a better looking, better working digital map
-
iPhones Are Allergic to Helium Helium has so small particles, that it can travel through a membrane. A story of a weird bug discovery
-
David Patterson says its time for new computer architectures and software languages, talking about the RISC architecture
-
You don't need stand-ups "My advice for all teams is to not start by complicating things."
-
The open-plan office is a terrible, horrible, no good, very bad idea Underlying what I dislike about open offices
-
BATNA Best Alternative to a Negotiated Agreement
-
Are interruptions really worse for programmers than for other knowledge workers?
-
Admin Anti-patterns Presentation from fefe
-
Superellipse – Wikipedia Basically the "round corners" Apple uses
-
Over 150 People Tried To Draw 10 Famous Logos From Memory, And The Results Are Hilarious
-
DuckDuckGo: The Former Solopreneur That Is Beating Google at Its Game
-
The Evolution of Trust Interactive game theory
-
Complexity of the immune system (Also see books -> Complexity by Melanie Mitchell)
Screenshot from a talk Gunter Dueck gave about Intrapreneuring
Documentation done right
There are four categories of documentation:
- Tutorials (learning oriented)
- How-to guides (problem oriented)
- Reference (information oriented)
- Discussions (understanding oriented)
These categories need structurally be kept apart.
Tutorials
Tutorials are supposed to be the hardest part of a documentation to create. Let a beginner do an exercise to learn using the software. The point is practical knowledge, not theoretical knowledge. Tutorials need to be concrete and not abstract. There should be no explanation. There should be no options or choices of the path. The tutorial writer is in charge of that path. The tutorial must be reproducable under all circumstances.
How-to guides
Recipes to solve a problem to achieve an outcome. In contrast to a tutorial, the learner would not even be able to formulate a problem to solve. How-to guides do not need to start at the beginning. They can assume basic knowledge of the domain. Again, no explanations. They get in the way of actions. Choose practicability over completeness.
Reference
References are purely descriptive. They are supposed to describe the machinery. A reference should not explain what can be assumed as general knowledge of the topic. The reference’s structure should resemble the code base. The wording should be consistent.
Discussions / Background material / Explanation
Clarify and illuminate a topic. Give context and discuss alternatives. Outline conflicting opinions. Make connections. It should not contain guides or technical reference.
Reference
- YouTube Video about this topic
- The documentation system — Documentation system documentation