vault backup: 2026-02-05 07:18:20
This commit is contained in:
Vendored
+6
-6
@@ -27,7 +27,7 @@
|
||||
"copyCommands": [
|
||||
{
|
||||
"name": "Quote",
|
||||
"template": "> ({{linkWithDisplay}})\n> {{text}}\n"
|
||||
"template": "> [!quote] {{linkWithDisplay}}\n> {{text}}\n"
|
||||
},
|
||||
{
|
||||
"name": "Link",
|
||||
@@ -110,8 +110,8 @@
|
||||
"recordPDFInternalLinkHistory": true,
|
||||
"alwaysRecordHistory": true,
|
||||
"renderMarkdownInStickyNote": false,
|
||||
"enablePDFEdit": true,
|
||||
"author": "ZaneMeyers",
|
||||
"enablePDFEdit": false,
|
||||
"author": "",
|
||||
"writeHighlightToFileOpacity": 0.2,
|
||||
"defaultWriteFileToggle": false,
|
||||
"syncWriteFileToggle": true,
|
||||
@@ -221,9 +221,9 @@
|
||||
"clearSelectionAfterAutoPaste": true,
|
||||
"respectCursorPositionWhenAutoPaste": true,
|
||||
"blankLineAboveAppendedContent": true,
|
||||
"autoCopy": true,
|
||||
"autoCopy": false,
|
||||
"autoFocus": false,
|
||||
"autoPaste": true,
|
||||
"autoPaste": false,
|
||||
"autoFocusTarget": "last-active-and-open-then-last-paste",
|
||||
"autoPasteTarget": "last-active-and-open-then-last-paste",
|
||||
"openAutoFocusTargetIfNotOpened": true,
|
||||
@@ -236,7 +236,7 @@
|
||||
"autoPasteTargetDialogTimeoutSec": 20,
|
||||
"autoCopyToggleRibbonIcon": false,
|
||||
"autoCopyIconName": "highlighter",
|
||||
"autoFocusToggleRibbonIcon": true,
|
||||
"autoFocusToggleRibbonIcon": false,
|
||||
"autoFocusIconName": "zap",
|
||||
"autoPasteToggleRibbonIcon": false,
|
||||
"autoPasteIconName": "clipboard-paste",
|
||||
|
||||
+5
-5
@@ -4,30 +4,30 @@
|
||||
"hasMigratedWeeklyNoteSettings": false,
|
||||
"daily": {
|
||||
"folder": "",
|
||||
"template": "templates/daily",
|
||||
"template": "templates/daily.md",
|
||||
"enabled": true
|
||||
},
|
||||
"weekly": {
|
||||
"format": "",
|
||||
"template": "",
|
||||
"template": "templates/weekly.md",
|
||||
"folder": "",
|
||||
"enabled": true
|
||||
},
|
||||
"monthly": {
|
||||
"format": "",
|
||||
"template": "",
|
||||
"template": "templates/monthly.md",
|
||||
"folder": "",
|
||||
"enabled": true
|
||||
},
|
||||
"quarterly": {
|
||||
"format": "",
|
||||
"template": "",
|
||||
"template": "templates/quarterly.md",
|
||||
"folder": "",
|
||||
"enabled": true
|
||||
},
|
||||
"yearly": {
|
||||
"format": "",
|
||||
"template": "",
|
||||
"template": "templates/yearly.md",
|
||||
"folder": "",
|
||||
"enabled": true
|
||||
}
|
||||
|
||||
+14
-18
@@ -11,7 +11,7 @@ dg-publish: true
|
||||
---
|
||||
# 2026-01-31
|
||||
|
||||
## 2026-01-31 12:48
|
||||
## 2026-01-31 12:48:00
|
||||
|
||||
Follow-up to [[2026-01-19#2026-01-19 11:57]]
|
||||
|
||||
@@ -35,21 +35,17 @@ could easily determine where hyphens should be replaced with em dashes.
|
||||
|
||||
- **-ee** (often recipient rather than doer, but related): _employee, trainee_
|
||||
|
||||
## 2026-01-31 17:49
|
||||
## 2026-01-31 17:49:00
|
||||
|
||||
[Linux Bash Shell Script Error: cannot execute: required file not found - Unix Stack Exchange](https://unix.stackexchange.com/questions/721844/linux-bash-shell-script-error-cannot-execute-required-file-not-found)
|
||||
|
||||
> [!quote] [ctrl-alt-delor](https://unix.stackexchange.com/users/4778/) 2022-10-21 08:16
|
||||
> Note: use of back ticks e.g. `... ``command`` ...` is deprecated. Use the newer easier to use `"$(command)"` (but yes this simple use with echo is hoop jumping). Use of `.sh` at the end of file names is not Unix. And it violates the principle of abstraction, as it leaks implementation detail. Just name them by what they do, not how they do it.
|
||||
|
||||
> [!quote] [Kusalananda](https://unix.stackexchange.com/users/116858/) 2022-10-21 08:22
|
||||
> @ctrl-alt-delor They are most definitely not deprecated, only awkward to use and should be avoided. In this particular case, any type of command substitution would be inappropriate. As for naming files, that's really up to the user. If you are concerned with abstraction, you could suggest the user uses the `hostname` command directly rather than via a nonsensical script with a function.
|
||||
|
||||
> [!quote] ctrl-alt-delor 2022-10-21 08:29
|
||||
> `deprecate` : express disapproval of. I disapprove. You say should be avoided. Thus deprecated. As for up to the user. I agree, it is the same for drug use. And the best abstraction is no abstraction (it depends). However I assume the examples were minimum non-working examples.
|
||||
|
||||
> [michael](https://unix.stackexchange.com/users/7832/) 2023-01-07 03:48
|
||||
> fwiw, this error is _usually_ a bad shebang, see also [stackoverflow.com/a/18818809/127971](https://stackoverflow.com/a/18818809/127971)
|
||||
|
||||
> [Ed Swangren](https://unix.stackexchange.com/users/597584/) 2024-09-28 07:46
|
||||
> @ctrl-alt-delor `deprecate(3):` to withdraw official support for or discourage the use of (something, such as a software product) in favor of a newer or better alternative" you're right, but only accidentally, so no credit given and mockery warranted. Citing a dictionary definition in a technical context is always wrong, citing the wrong one is lazy and stupid, and citing your opinion as evidence is in line with what I'd expect after #1 and #2. No one cares.
|
||||
> [!quote] [Linux Bash Shell Script Error: cannot execute: required file not found - Unix Stack Exchange](https://unix.stackexchange.com/questions/721844/linux-bash-shell-script-error-cannot-execute-required-file-not-found)
|
||||
> > [!quote] [ctrl-alt-delor](https://unix.stackexchange.com/users/4778/) 2022-10-21 08:16
|
||||
> > Note: use of back ticks e.g. `... ``command`` ...` is deprecated. Use the newer easier to use `"$(command)"` (but yes this simple use with echo is hoop jumping). Use of `.sh` at the end of file names is not Unix. And it violates the principle of abstraction, as it leaks implementation detail. Just name them by what they do, not how they do it.
|
||||
>
|
||||
> > [!quote] [Kusalananda](https://unix.stackexchange.com/users/116858/) 2022-10-21 08:22
|
||||
> > @ctrl-alt-delor They are most definitely not deprecated, only awkward to use and should be avoided. In this particular case, any type of command substitution would be inappropriate. As for naming files, that's really up to the user. If you are concerned with abstraction, you could suggest the user uses the `hostname` command directly rather than via a nonsensical script with a function.
|
||||
>
|
||||
> > [!quote] ctrl-alt-delor 2022-10-21 08:29
|
||||
> > `deprecate` : express disapproval of. I disapprove. You say should be avoided. Thus deprecated. As for up to the user. I agree, it is the same for drug use. And the best abstraction is no abstraction (it depends). However I assume the examples were minimum non-working examples.
|
||||
>
|
||||
> > [!quote] [Ed Swangren](https://unix.stackexchange.com/users/597584/) 2024-09-28 07:46
|
||||
> > @ctrl-alt-delor `deprecate(3):` to withdraw official support for or discourage the use of (something, such as a software product) in favor of a newer or better alternative" you're right, but only accidentally, so no credit given and mockery warranted. Citing a dictionary definition in a technical context is always wrong, citing the wrong one is lazy and stupid, and citing your opinion as evidence is in line with what I'd expect after #1 and #2. No one cares.
|
||||
|
||||
@@ -10,90 +10,3 @@ tags:
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-02-02
|
||||
|
||||
## 2026-02-02 06:50
|
||||
|
||||
I'm considering including management scripts in this vault,
|
||||
but I'd generally prefer to keep it content only.
|
||||
Ideally I could do anything I'd use a script for with a plugin,
|
||||
but they have their limitations.
|
||||
Eventually I should [[learn-to-write-obsidian-plugins]],
|
||||
but for now here's a useful cmdlet I wrote a while ago but misplaced.
|
||||
|
||||
```powershell
|
||||
function Import-Markdown {
|
||||
[CmdletBinding()]
|
||||
param(
|
||||
[Parameter(Mandatory)]
|
||||
[string]$Path
|
||||
)
|
||||
try {
|
||||
$command = Get-Command ConvertFrom-Yaml -ErrorAction "Stop"
|
||||
}
|
||||
catch {
|
||||
throw "no YAML conversion module installed. Try ``Install-Module powershell-yaml``."
|
||||
}
|
||||
|
||||
$content = Get-Content -Path $Path -Raw
|
||||
$pattern = [Regex]'(?ms)^---\s*(.*?)\s*---\s*(.*)$'
|
||||
$match = $pattern.Match($content)
|
||||
if ($match.Success) {
|
||||
$frontmatter = $match.Groups[1].Value
|
||||
$body = $match.Groups[2].Value
|
||||
}
|
||||
else {
|
||||
$frontmatter = ''
|
||||
$body = $content
|
||||
}
|
||||
|
||||
return [pscustomobject]@{
|
||||
frontmatter = $frontmatter | ConvertFrom-Yaml
|
||||
body = $body
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
That match expression is bizarre,
|
||||
and the whole thing needs better error handling,
|
||||
but it works.
|
||||
|
||||
A `Where-Markdown` for filtering by tags
|
||||
and a `{Verb}-Markdown` for modifying tags
|
||||
would be idiomatic.
|
||||
|
||||
## 2026-02-02 12:18
|
||||
|
||||
### Sleeving Takeoff Breakdown Direction
|
||||
|
||||
Updated [[sleeving-takeoff#Breakdowns]]
|
||||
per clarification with Joel.
|
||||
Previous direction below.
|
||||
|
||||
> * `Area` = "01 - Feeders/Risers ..."
|
||||
> * `Phase` = "Feeders"
|
||||
> * `System` = "FRR - Feeders and Risers"
|
||||
>
|
||||
> For all sleeving, regardless of application.
|
||||
|
||||
I feel certain I received this from someone I trust
|
||||
because I've been doing it against my better judgement,
|
||||
but either it wasn't Joel (Ben maybe?)
|
||||
or he was referring to a different scenario
|
||||
(which my notes no longer cover).
|
||||
|
||||
***
|
||||
|
||||
I asked Joel if he could think of any direction
|
||||
that I might have misinterpreted
|
||||
to get to that above,
|
||||
but he said he could not.
|
||||
|
||||
***
|
||||
|
||||
I spoke with Willie about it,
|
||||
he says he's always put sleeving in each relevant system.
|
||||
I told him I knew it had to have been spoken
|
||||
because I remember it being justified as WBS allocation thing,
|
||||
but I think now Joel told me correctly at the time,
|
||||
that is, gave me the same direction he gave me today,
|
||||
I just somehow heard the complete opposite.
|
||||
|
||||
@@ -0,0 +1,49 @@
|
||||
# 2026-02-02 06:50:00
|
||||
|
||||
I'm considering including management scripts in this vault,
|
||||
but I'd generally prefer to keep it content only.
|
||||
Ideally I could do anything I'd use a script for with a plugin,
|
||||
but they have their limitations.
|
||||
Eventually I should [[learn-to-write-obsidian-plugins]],
|
||||
but for now here's a useful cmdlet I wrote a while ago but misplaced.
|
||||
|
||||
```powershell
|
||||
function Import-Markdown {
|
||||
[CmdletBinding()]
|
||||
param(
|
||||
[Parameter(Mandatory)]
|
||||
[string]$Path
|
||||
)
|
||||
try {
|
||||
$command = Get-Command ConvertFrom-Yaml -ErrorAction "Stop"
|
||||
}
|
||||
catch {
|
||||
throw "no YAML conversion module installed. Try ``Install-Module powershell-yaml``."
|
||||
}
|
||||
|
||||
$content = Get-Content -Path $Path -Raw
|
||||
$pattern = [Regex]'(?ms)^---\s*(.*?)\s*---\s*(.*)$'
|
||||
$match = $pattern.Match($content)
|
||||
if ($match.Success) {
|
||||
$frontmatter = $match.Groups[1].Value
|
||||
$body = $match.Groups[2].Value
|
||||
}
|
||||
else {
|
||||
$frontmatter = ''
|
||||
$body = $content
|
||||
}
|
||||
|
||||
return [pscustomobject]@{
|
||||
frontmatter = $frontmatter | ConvertFrom-Yaml
|
||||
body = $body
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
That match expression is bizarre,
|
||||
and the whole thing needs better error handling,
|
||||
but it works.
|
||||
|
||||
A `Where-Markdown` for filtering by tags
|
||||
and a `{Verb}-Markdown` for modifying tags
|
||||
would be idiomatic.
|
||||
@@ -0,0 +1,36 @@
|
||||
# 2026-02-02 12:18:00
|
||||
|
||||
## Sleeving Takeoff Breakdown Direction
|
||||
|
||||
Updated [[sleeving-takeoff#Breakdowns]]
|
||||
per clarification with Joel.
|
||||
Previous direction below.
|
||||
|
||||
> * `Area` = "01 - Feeders/Risers ..."
|
||||
> * `Phase` = "Feeders"
|
||||
> * `System` = "FRR - Feeders and Risers"
|
||||
>
|
||||
> For all sleeving, regardless of application.
|
||||
|
||||
I feel certain I received this from someone I trust
|
||||
because I've been doing it against my better judgement,
|
||||
but either it wasn't Joel (Ben maybe?)
|
||||
or he was referring to a different scenario
|
||||
(which my notes no longer cover).
|
||||
|
||||
***
|
||||
|
||||
I asked Joel if he could think of any direction
|
||||
that I might have misinterpreted
|
||||
to get to that above,
|
||||
but he said he could not.
|
||||
|
||||
***
|
||||
|
||||
I spoke with Willie about it,
|
||||
he says he's always put sleeving in each relevant system.
|
||||
I told him I knew it had to have been spoken
|
||||
because I remember it being justified as WBS allocation thing,
|
||||
but I think now Joel told me correctly at the time,
|
||||
that is, gave me the same direction he gave me today,
|
||||
I just somehow heard the complete opposite.
|
||||
@@ -10,25 +10,3 @@ tags:
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-02-03
|
||||
|
||||
## 2026-02-03 08:34
|
||||
|
||||
Drawings bookmark colors
|
||||
|
||||
- Lighting: Yellow
|
||||
- Power: Green
|
||||
- Riser/One-Line: Light Blue
|
||||
|
||||
## 2026-02-03 15:04
|
||||
|
||||
It is possible, even common,
|
||||
to be _confident_ in an _uncertain_ estimate.
|
||||
Confidence is a measure of the potential for an estimate to vary from reality,
|
||||
but an estimate can (and _should_ where possible)
|
||||
include respect for uncertainty.
|
||||
|
||||
## 2026-02-03 16:17
|
||||
|
||||
Valued in [[pdi-estimating#Construction Estimating (ConEst)|ConEst]] estimators:
|
||||
* **consistency**
|
||||
* **humility** --- willingness to say "I don't know that, please teach me"
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: 2026-02-03 08:34:00
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-02-03 08:34:00
|
||||
|
||||
Drawings bookmark colors
|
||||
|
||||
* Lighting: Yellow
|
||||
* Power: Green
|
||||
* Riser/One-Line: Light Blue
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: 2026-02-03 15:04:00
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-02-03 15:04:00
|
||||
|
||||
It is possible, even common,
|
||||
to be _confident_ in an _uncertain_ estimate.
|
||||
Confidence is a measure of the potential for an estimate to vary from reality,
|
||||
but an estimate can (and _should_ where possible)
|
||||
include respect for uncertainty.
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: 2026-02-03 16:17:00
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-02-03 16:17:00
|
||||
|
||||
Valued in [[pdi-estimating#Construction Estimating (ConEst)|ConEst]] estimators:
|
||||
* **consistency**
|
||||
* **humility** --- willingness to say "I don't know that, please teach me"
|
||||
-187
@@ -10,190 +10,3 @@ tags:
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-02-04
|
||||
|
||||
## 2026-02-04 08:07
|
||||
|
||||
### Questions for ConEst
|
||||
|
||||
#### Purpose of ConEst
|
||||
|
||||
What is the purpose of ConEst?
|
||||
To comb for requirements Bid missed?
|
||||
To create the CBOM for Ops?
|
||||
Anything else?
|
||||
How do they rank in importance?
|
||||
|
||||
Why are other departments so confused about ConEst's purpose?
|
||||
(Ops stakeholder auditing CBOM to Joel: "missing screws")
|
||||
If we don't know, and Ops doesn't know, who does?
|
||||
That is, who defines our purpose?
|
||||
|
||||
#### ConEst Organization
|
||||
|
||||
What freedom does ConEst have to change its process and deliverables?
|
||||
suppose a plan to have Bid, with their request for ConEst,
|
||||
articulate certain requirements which they must have possessed to produce the bid estimate.
|
||||
Who would be involved in the change?
|
||||
Who would be the one to deny the request?
|
||||
|
||||
If Bid's proposals are audited,
|
||||
why do they still cause ConEst constant headache?
|
||||
("local lighting control")
|
||||
|
||||
Estimators and seniors are biased towards imprecision
|
||||
because its tolerance reduces monotonous work,
|
||||
but the logical conclusion of such bias is a Bid estimate.
|
||||
Obviously there is an ideal compromise
|
||||
between 1:1 takeoff to install and a square foot budget
|
||||
that ConEst is intended to produce.
|
||||
Who is ultimately responsible
|
||||
for defining the position of that point on the spectrum?
|
||||
How is it defined?
|
||||
How is it expected to be communicated to seniors and estimators?
|
||||
|
||||
##### Process Variation
|
||||
|
||||
What is an acceptable level of process variance senior to senior?
|
||||
To my mind the answer ought to be "none"
|
||||
or at least "as little as possible",
|
||||
since our process benefits greatly
|
||||
from every bit of consistency we can maintain,
|
||||
saying nothing of the fact that there usually _is_
|
||||
a better option between two.
|
||||
What's being done to address the variance which exists?
|
||||
What's being done to prevent it from re-emerging?
|
||||
|
||||
It's my belief that the most practical solution
|
||||
is the frequent rotation of estimators in senior teams.
|
||||
It's in the interest of estimators
|
||||
that their personal heuristics not depend on who they're working for,
|
||||
so they can be expected to call attention to inconsistency
|
||||
allowing it to be addressed permanently.
|
||||
|
||||
The only other option I can imagine
|
||||
is to document exact procedures for every scenario,
|
||||
which is obviously foolhardy.
|
||||
|
||||
#### Less Important
|
||||
|
||||
##### Proposal Transparency
|
||||
|
||||
Am I alone in feeling that our proposals are deceptive
|
||||
beyond reasonable explanation?
|
||||
Would I be better of keeping my mouth shut about it?
|
||||
|
||||
##### Incentives
|
||||
|
||||
Bonuses based on awarded profit
|
||||
incentivize problematic (hare-hunting) behavior.
|
||||
Has such behavior been observed,
|
||||
or has chief strategy been organization-aligned
|
||||
in spite of the incentive?
|
||||
|
||||
## 2026-02-04
|
||||
|
||||
### T-Shirt Sizing
|
||||
|
||||
"T-shirt sizing" or "T-shirt size estimation"
|
||||
is a method of project estimation
|
||||
characterized by the use of T-shirt sizes
|
||||
representing project scale buckets.
|
||||
|
||||
> [!example]
|
||||
> * **XS (1-2 days):** Simple UI changes or minor bug fixes
|
||||
>
|
||||
> Example: "Update button color on checkout page"
|
||||
>
|
||||
> * **S (2-3 days):** Feature enhancements with minimal complexity
|
||||
>
|
||||
> Example: "Add product sorting by price"
|
||||
>
|
||||
> * **M (5-7 days):** Features requiring moderate integration
|
||||
>
|
||||
> Example: "Implement basic search filters"
|
||||
>
|
||||
> * **L (8-10 days):** Complex features affecting multiple components
|
||||
>
|
||||
> Example: "Create shopping cart functionality"
|
||||
>
|
||||
> * **XL (2+ weeks):** Major features requiring breaking down
|
||||
>
|
||||
> Example: "Implement payment gateway integration"
|
||||
>
|
||||
> --- [T-Shirt Sizing in Agile --- Project Management Pathways](https://www.projectmanagementpathways.com/project-management-articles/tshirt-sizing-in-agile-projects)
|
||||
|
||||
The buckets chosen should be wide enough
|
||||
that scale can be confidently estimated
|
||||
after minimal investigation.
|
||||
|
||||
## 2026-02-04 13:42
|
||||
|
||||
[[fire-alarm-takeoff]]
|
||||
|
||||
> [!quote] Art Baldwin 2026-02-04 (pp.)
|
||||
> Fire, smoke, and combination fire/smoke dampers
|
||||
> may require 120V power, and thus electrical takeoff,
|
||||
> or only 24V, in which case mechanical will own the scope.
|
||||
> Assuming 120V is a budget-conservative estimating convenience,
|
||||
> which is generally considered acceptable
|
||||
> in lieu of determining specified requirements,
|
||||
> but further investigation may be expected
|
||||
> if more than a few per floor are shown.
|
||||
|
||||
## 2026-02-04 17:02
|
||||
|
||||
While observing takeoff for
|
||||
[[electrical-takeoff#Unit Condensing Units|unit condensing units]],
|
||||
the project engineer expressed confusion
|
||||
at the process of calculating average horizontal length,
|
||||
expressing that it was more complicated than they expected
|
||||
considering takeoff procedure for similar processes.
|
||||
The PE asked why we would not simply use the maximum
|
||||
so that we would not risk having too little overall.
|
||||
|
||||
Their expectation surprised me,
|
||||
since it is intuitive to me
|
||||
that there must be some limit to the logic of "covering it"
|
||||
since it is always within our power to add contingency,
|
||||
and especially because, if anything,
|
||||
I feel that our procedures tend towards
|
||||
the upper end of reasonable ECI.
|
||||
(see [[value-of-information.jpg]])
|
||||
|
||||
My response was not well formulated.
|
||||
|
||||
## 2026-02-04 18:05
|
||||
|
||||
Expected value of sample information (EVSI)
|
||||
must define acceptable takeoff.
|
||||
If not, we are---by definition---
|
||||
throwing money away
|
||||
in the form of wasted estimator hours
|
||||
and missed bid opportunities.
|
||||
|
||||
## 2026-02-04 19:35
|
||||
|
||||
### Time Interval Conversion
|
||||
|
||||
In [[2026-01-09#2026-01-09 12:00]]
|
||||
I defined time intervals according to averages
|
||||
which are true of the Gregorian calendar for $\lim\limits_{t\to\infty}$,
|
||||
but which are not so appropriate for a human lifetime scale.
|
||||
|
||||
True of the Gregorian calendar (and its predecessors)
|
||||
for all time scales:
|
||||
|
||||
$$
|
||||
\begin{align*}
|
||||
1~\text{Year} &\equiv 12~\text{Months} \\
|
||||
1~\text{Week} &\equiv 7~\text{Days}
|
||||
\end{align*}
|
||||
$$
|
||||
|
||||
In 2001--2099 leap years occur exactly once in four years.
|
||||
|
||||
$$
|
||||
\begin{align*}
|
||||
1~\text{Year} &= 365.25~\text{Days} \\
|
||||
\end{align*}
|
||||
$$
|
||||
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: 2026-02-04 08:07:00
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-02-04 08:07:00
|
||||
|
||||
## Questions for ConEst
|
||||
|
||||
### Purpose of ConEst
|
||||
|
||||
What is the purpose of ConEst?
|
||||
To comb for requirements Bid missed?
|
||||
To create the CBOM for Ops?
|
||||
Anything else?
|
||||
How do they rank in importance?
|
||||
|
||||
Why are other departments so confused about ConEst's purpose?
|
||||
(Ops stakeholder auditing CBOM to Joel: "missing screws")
|
||||
If we don't know, and Ops doesn't know, who does?
|
||||
That is, who defines our purpose?
|
||||
|
||||
### ConEst Organization
|
||||
|
||||
What freedom does ConEst have to change its process and deliverables?
|
||||
suppose a plan to have Bid, with their request for ConEst,
|
||||
articulate certain requirements which they must have possessed to produce the bid estimate.
|
||||
Who would be involved in the change?
|
||||
Who would be the one to deny the request?
|
||||
|
||||
If Bid's proposals are audited,
|
||||
why do they still cause ConEst constant headache?
|
||||
("local lighting control")
|
||||
|
||||
Estimators and seniors are biased towards imprecision
|
||||
because its tolerance reduces monotonous work,
|
||||
but the logical conclusion of such bias is a Bid estimate.
|
||||
Obviously there is an ideal compromise
|
||||
between 1:1 takeoff to install and a square foot budget
|
||||
that ConEst is intended to produce.
|
||||
Who is ultimately responsible
|
||||
for defining the position of that point on the spectrum?
|
||||
How is it defined?
|
||||
How is it expected to be communicated to seniors and estimators?
|
||||
|
||||
#### Process Variation
|
||||
|
||||
What is an acceptable level of process variance senior to senior?
|
||||
To my mind the answer ought to be "none"
|
||||
or at least "as little as possible",
|
||||
since our process benefits greatly
|
||||
from every bit of consistency we can maintain,
|
||||
saying nothing of the fact that there usually _is_
|
||||
a better option between two.
|
||||
What's being done to address the variance which exists?
|
||||
What's being done to prevent it from re-emerging?
|
||||
|
||||
It's my belief that the most practical solution
|
||||
is the frequent rotation of estimators in senior teams.
|
||||
It's in the interest of estimators
|
||||
that their personal heuristics not depend on who they're working for,
|
||||
so they can be expected to call attention to inconsistency
|
||||
allowing it to be addressed permanently.
|
||||
|
||||
The only other option I can imagine
|
||||
is to document exact procedures for every scenario,
|
||||
which is obviously foolhardy.
|
||||
|
||||
### Less Important
|
||||
|
||||
#### Proposal Transparency
|
||||
|
||||
Am I alone in feeling that our proposals are deceptive
|
||||
beyond reasonable explanation?
|
||||
Would I be better of keeping my mouth shut about it?
|
||||
|
||||
#### Incentives
|
||||
|
||||
Bonuses based on awarded profit
|
||||
incentivize problematic (hare-hunting) behavior.
|
||||
Has such behavior been observed,
|
||||
or has chief strategy been organization-aligned
|
||||
in spite of the incentive?
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: 2026-02-04 09:00:00
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# [[2026-02-04]] 09:00:00
|
||||
|
||||
%%
|
||||
Exact time of writing unknown.
|
||||
Between [[2026-02-04_08-07-00]] and [[2026-02-04_13-42-00]]
|
||||
%%
|
||||
|
||||
## T-Shirt Sizing
|
||||
|
||||
"T-shirt sizing" or "T-shirt size estimation"
|
||||
is a method of project estimation
|
||||
characterized by the use of T-shirt sizes
|
||||
representing project scale buckets.
|
||||
|
||||
> [!example]
|
||||
> * **XS (1-2 days):** Simple UI changes or minor bug fixes
|
||||
>
|
||||
> Example: "Update button color on checkout page"
|
||||
>
|
||||
> * **S (2-3 days):** Feature enhancements with minimal complexity
|
||||
>
|
||||
> Example: "Add product sorting by price"
|
||||
>
|
||||
> * **M (5-7 days):** Features requiring moderate integration
|
||||
>
|
||||
> Example: "Implement basic search filters"
|
||||
>
|
||||
> * **L (8-10 days):** Complex features affecting multiple components
|
||||
>
|
||||
> Example: "Create shopping cart functionality"
|
||||
>
|
||||
> * **XL (2+ weeks):** Major features requiring breaking down
|
||||
>
|
||||
> Example: "Implement payment gateway integration"
|
||||
>
|
||||
> --- [T-Shirt Sizing in Agile --- Project Management Pathways](https://www.projectmanagementpathways.com/project-management-articles/tshirt-sizing-in-agile-projects)
|
||||
|
||||
The buckets chosen should be wide enough
|
||||
that scale can be confidently estimated
|
||||
after minimal investigation.
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: 2026-02-04 13:42:00
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# [[2026-02-04]] 13:42:00
|
||||
|
||||
[[fire-alarm-takeoff]]
|
||||
|
||||
> [!quote] Art Baldwin 2026-02-04 (pp.)
|
||||
> Fire, smoke, and combination fire/smoke dampers
|
||||
> may require 120V power, and thus electrical takeoff,
|
||||
> or only 24V, in which case mechanical will own the scope.
|
||||
> Assuming 120V is a budget-conservative estimating convenience,
|
||||
> which is generally considered acceptable
|
||||
> in lieu of determining specified requirements,
|
||||
> but further investigation may be expected
|
||||
> if more than a few per floor are shown.
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: 2026-02-04 17:02:00
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# [[2026-02-04]] 17:02:00
|
||||
|
||||
While observing takeoff for
|
||||
[[electrical-takeoff#Unit Condensing Units|unit condensing units]],
|
||||
the project engineer expressed confusion
|
||||
at the process of calculating average horizontal length,
|
||||
expressing that it was more complicated than they expected
|
||||
considering takeoff procedure for similar processes.
|
||||
The PE asked why we would not simply use the maximum
|
||||
so that we would not risk having too little overall.
|
||||
|
||||
Their expectation surprised me,
|
||||
since it is intuitive to me
|
||||
that there must be some limit to the logic of "covering it"
|
||||
since it is always within our power to add contingency,
|
||||
and especially because, if anything,
|
||||
I feel that our procedures tend towards
|
||||
the upper end of reasonable ECI.
|
||||
(see [[value-of-information.jpg]])
|
||||
|
||||
My response was not well formulated.
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: 2026-02-04 18:05:00
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# [[2026-02-04]] 18:05:00
|
||||
|
||||
Expected value of sample information (EVSI)
|
||||
must define acceptable takeoff.
|
||||
If not, we are---by definition---
|
||||
throwing money away
|
||||
in the form of wasted estimator hours
|
||||
and missed bid opportunities.
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: 2026-02-04 19:35:00
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
daily: "[[2026-02-04]]"
|
||||
---
|
||||
# 2026-02-04 19:35:00
|
||||
|
||||
## Time Interval Conversion
|
||||
|
||||
In [[2026-01-09#2026-01-09 12:00]]
|
||||
I defined time intervals according to averages
|
||||
which are true of the Gregorian calendar for $\lim\limits_{t\to\infty}$,
|
||||
but which are not so appropriate for a human lifetime scale.
|
||||
|
||||
True of the Gregorian calendar (and its predecessors)
|
||||
for all time scales:
|
||||
|
||||
$$
|
||||
\begin{align*}
|
||||
1~\text{Year} &\equiv 12~\text{Months} \\
|
||||
1~\text{Week} &\equiv 7~\text{Days}
|
||||
\end{align*}
|
||||
$$
|
||||
|
||||
In 2001--2099 leap years occur exactly once in four years.
|
||||
|
||||
$$
|
||||
\begin{align*}
|
||||
1~\text{Year} &= 365.25~\text{Days} \\
|
||||
\end{align*}
|
||||
$$
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: 2026-02-05
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/daily
|
||||
dg-publish: true
|
||||
weekly: "[[2026-W05]]"
|
||||
monthly: "[[2026-02]]"
|
||||
quarterly: "[[2026-Q1]]"
|
||||
yearly: "[[2026]]"
|
||||
---
|
||||
# 2026-02-05
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: 2026-02-05 06:20:00
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# [[2026-02-05]] 06:20:00
|
||||
|
||||
I believe I have improved significantly
|
||||
in my ability to explain myself verbally
|
||||
in the past few months,
|
||||
and since I am my own worst critic
|
||||
there must be some truth there.
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: Learn to Write Obsidian Plugins
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/fleeting
|
||||
- status/not-started
|
||||
- topic/software
|
||||
- type/task
|
||||
---
|
||||
# Learn to Write Obsidian Plugins
|
||||
|
||||
[Build a Plugin - Obsidian](https://docs.obsidian.md/Plugins/Getting+started/Build+a+plugin)
|
||||
+7
-5
@@ -1,14 +1,16 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: {{date}}
|
||||
title: {{date:YYYY-MM-DD}}
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/daily
|
||||
- type/periodic/daily
|
||||
dg-publish: true
|
||||
weekly: "[[{{date:gggg-[W]WW}}]]"
|
||||
monthly: "[[{{date:YYYY-MM}}]]"
|
||||
quarterly: "[[{{date:YYYY-[Q]Q}}]]"
|
||||
yearly: "[[{{date:YYYY}}]]"
|
||||
---
|
||||
# {{date}}
|
||||
|
||||
## {{date}} {{time}}
|
||||
# {{date:YYYY-MM-DD}}
|
||||
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: {{date:YYYY-MM}}
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/periodic/monthly
|
||||
dg-publish: true
|
||||
quarterly: "[[{{date:YYYY-[Q]Q}}]]"
|
||||
yearly: "[[{{date:YYYY}}]]"
|
||||
---
|
||||
# {{date:YYYY-MM}}
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: "{{date:YYYY-[Q]Q}}"
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/periodic/quarterly
|
||||
dg-publish: true
|
||||
yearly: "[[{{date:YYYY}}]]"
|
||||
---
|
||||
# {{date:YYYY-[Q]Q}}
|
||||
@@ -1,12 +1,17 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: {{date}} {{time:HH:mm:ss}}
|
||||
title: "{{date:YYYY-MM-DD}} {{time:HH:mm:ss}}"
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/timestamped
|
||||
- type/periodic/timestamped
|
||||
dg-publish: true
|
||||
daily: "[[{{date:YYYY-MM-DD}}]]"
|
||||
weekly: "[[{{date:gggg-[W]WW}}]]"
|
||||
monthly: "[[{{date:YYYY-MM}}]]"
|
||||
quarterly: "[[{{date:YYYY-[Q]Q}}]]"
|
||||
yearly: "[[{{date:YYYY}}]]"
|
||||
---
|
||||
# {{date}} {{time:HH:mm:ss}}
|
||||
# {{date:YYYY-MM-DD}} {{time:HH:mm:ss}}
|
||||
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: {{date:gggg-[W]WW}}
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/periodic/weekly
|
||||
dg-publish: true
|
||||
monthly: "[[{{date:YYYY-MM}}]]"
|
||||
quarterly: "[[{{date:YYYY-[Q]Q}}]]"
|
||||
yearly: "[[{{date:YYYY}}]]"
|
||||
---
|
||||
# {{date:gggg-[W]WW}}
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: {{date:YYYY}}
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/periodic/yearly
|
||||
dg-publish: true
|
||||
---
|
||||
# {{date:YYYY}}
|
||||
Reference in New Issue
Block a user