Merge remote-tracking branch 'origin/main'
This commit is contained in:
@@ -1,7 +1,7 @@
|
||||
---
|
||||
id: 2025-07-18T00:00:00-04:00
|
||||
aliases: []
|
||||
title: 2025-07-18
|
||||
title: 2025-07-18 ??:??:??
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title: 2025-11-10 06:53:??
|
||||
tags:
|
||||
- original-format/typewritten-print
|
||||
- topic/mindfulness
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-11-10 06:53:??
|
||||
|
||||
_Monday Morning Before Work_
|
||||
|
||||
I've been trying to be alone with my thoughts more
|
||||
recently. It's almost bizarre how working in silence
|
||||
for an hour makes the thought of music or an audiobook
|
||||
seem overstimulating, It feels right, though.
|
||||
|
||||
To want to converse with myself rather than let my
|
||||
superego be drowned out by appealing sounds or a
|
||||
fantasy story I've already heard, or obscure facts
|
||||
about a game I've never played and never will.
|
||||
|
||||
I still relapse, of course, a lifetime (albeit
|
||||
a short one) of unhealthy interaction with computers
|
||||
will do that, but I'm making quick progress.
|
||||
|
||||
I watched a video yesterday that suggested that
|
||||
it might be my growing understanding of computers
|
||||
rather than my self discipline that's lead to this
|
||||
change in the dynamic between me and them. That,
|
||||
in understanding _how_ they function, I've turned
|
||||
them from _devices_ into _things_, which lack
|
||||
the mystical allure of the former. Whatever
|
||||
the reason, it's good progress as far
|
||||
as I'm concerned. It feels good to be introspective
|
||||
and to have time to build skills people care about,
|
||||
like music and style and... birdwatching...
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/estimating
|
||||
- occupational
|
||||
- original-format/digital-text
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-11-10 10:40:??
|
||||
|
||||
A significant change from Ace to PDI in my mentality during takeoff
|
||||
is that I now tend to expect that (within reason)
|
||||
"holes" in takeoff scripts are _intentional omissions_,
|
||||
not holes in cost coverage.
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
- occupational/takeoff
|
||||
- original-format/digital-text
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-11-10 11:14:??
|
||||
|
||||
I was updating my notes,
|
||||
filling in gaps in scripts based on Joel's,
|
||||
when I noticed a strange paragraph:
|
||||
|
||||
> [!quote] `OneNote`/`Joel Take-off`/`Misc. Notes`
|
||||
> Drop Down Ceilings vs. GWB (Gypsum Wall Boards)
|
||||
>
|
||||
> Drop down ceiling is technically "Exposed" (the real term should be accessable),
|
||||
> so Romex and SER is not permited. Will need to use MC.
|
||||
>
|
||||
> > [!image]
|
||||
> > ### 334.12 Uses Not Permitted.
|
||||
> >
|
||||
> > #### 334.12(A) Types NM and NMC.
|
||||
> >
|
||||
> > Types NM and NMC cables shall not be permitted as follows:
|
||||
> >
|
||||
> > 1. In any dwelling or structure not specifically
|
||||
> > permitted in 334.10(1), (2), (3)
|
||||
> >
|
||||
> > 2. ==Exposed in dropped or suspended ceilings==
|
||||
> > in other than one- and two-family and multifamily dwellings
|
||||
|
||||
This analysis of 334.12(A)(2) is flawed.
|
||||
|
||||
Based on the [[nfpa-70_100_definitions|Article 100]] definitions
|
||||
of [[nfpa-70_100_definitions#Exposed (as applied to wiring methods).|exposed]]
|
||||
and [[nfpa-70_100_definitions#Dwelling, Multifamily.|dwelling]],
|
||||
[[nfpa-70_334_nm-cable#334.12(A) Types NM and NMC.|334.12(A)(2)]]
|
||||
can be paraphrased as follows:
|
||||
|
||||
> [!cite] NEC 334.12(A)(2), pp.
|
||||
> Types NM and NMC cable are not permitted to be installed
|
||||
> in accessible spaces above suspended ceilings,
|
||||
> _except in buildings containing one or more dwelling units._
|
||||
|
||||
The prohibition of 334.12(A)(2) _never_ applies to apartments or condos,
|
||||
And only applies to hotels and dormitories on a basis of AHJ interpretation
|
||||
(See [[multi-family-dwellings#Are Hotels Multifamily Dwellings?]]).
|
||||
|
||||
It's unclear to me if this a genuine misunderstanding
|
||||
or just a [[heuristics|rule of thumb]] to cover the case
|
||||
that guestrooms are not interpreted to be dwelling units.
|
||||
If it's the latter, I believe it's far too conservative
|
||||
to be used whole-cloth on all estimates.
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/construction/electrical
|
||||
- original-format/digital-text
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-11-10 15:15:??
|
||||
|
||||
### "Feeder"
|
||||
|
||||
The NEC definition of feeder is quite strict.
|
||||
I'm certain I misuse it frequently.
|
||||
|
||||
![[nfpa-70_100_definitions#Feeder.]]
|
||||
|
||||
It _does not_ include power conductors to
|
||||
[[nfpa-70_100_definitions#Utilization Equipment.|utilization equipment]],
|
||||
those are [[nfpa-70_100_definitions#Branch Circuit.|branch circuit]] conductors.
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/estimating
|
||||
- occupational
|
||||
- original-format/typewritten-print
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-11-10 20:00:??
|
||||
|
||||
_Monday Evening, Before Bed_
|
||||
|
||||
Today while (a peer) and I were walking, he asked
|
||||
me what I thought of his qualities as an estimator.
|
||||
I told him I think he has the right of it, that having beliefs
|
||||
about what's correct that don't change just because
|
||||
a senior says they should, is a good sign.
|
||||
|
||||
I can't remember now if I knew it before today,
|
||||
but my relationship with Dale, my former manager,
|
||||
while never "good", was much improved when I started
|
||||
pushing back on his direction and feedback. I became
|
||||
an estimator, where before I was just someone who
|
||||
could estimate for him. He hated it, and let me know,
|
||||
but I never felt more sure of my position.
|
||||
|
||||
Estimating is not a field where you get ahead
|
||||
by being more technically skilled or efficient.
|
||||
|
||||
You distinguish yourself by convincing your superiors
|
||||
that you understand the objective and how to achieve
|
||||
it. The best estimators---as measured by compensation
|
||||
package---are not doing takeoff, they're
|
||||
telling other estimators what to take off and how.
|
||||
|
||||
Conquer your self-doubt. Tell your boss they're
|
||||
wrong and stupid and they should feel bad. Profit.
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/estimating
|
||||
- original-format/typewritten-print
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-11-11 06:06:??
|
||||
|
||||
_Tuesday Morning, Before Work_
|
||||
|
||||
One of the most appealing aspects of estimating
|
||||
to me is the dynamic we have with our employers.
|
||||
my experience was at Ace that estimators act like,
|
||||
and are treated like good artists, like loveable
|
||||
little scamps who always get into trouble, but
|
||||
you keep them around because they do good work.
|
||||
There was no other position with a similar reputation.
|
||||
|
||||
I attribute this strange relationship to two
|
||||
facts of our role:
|
||||
|
||||
1. Estimating provides executives with a service,
|
||||
one that they could almost do without, but that they
|
||||
understand the value of paying for.
|
||||
|
||||
2. Estimating is just math-heavy enough that it
|
||||
seems like magic to the uninitiated.
|
||||
|
||||
In these ways we're actually more like court
|
||||
wizards than artists, which is an understandably
|
||||
desirable position.
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/estimating
|
||||
- topic/transparency
|
||||
- original-format/digital-text
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-11-11 14:41:??
|
||||
|
||||
I just saw a post on a construction estimators forum
|
||||
from a user lamenting that their coworkers and customers
|
||||
largely do not understand the difference between markup and margin.
|
||||
|
||||
It made me remember the micro-debates about that I would have with Dale
|
||||
every time we were closing out an estimate.
|
||||
This is the example I would always give
|
||||
while trying to explain it to him.
|
||||
|
||||
![[markup-vs-margin#Markup vs. Margin]]
|
||||
|
||||
***
|
||||
|
||||
The user also stated that they would prefer to list overhead and profit
|
||||
separately from scope line item costs,
|
||||
but that their customers push back when they try.
|
||||
|
||||
I'm not sure where they got this preference.
|
||||
Sure that would be more "transparent",
|
||||
but it's at odds with the purpose of a breakdown.
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/hobbies/writing
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-11-13 08:03:??
|
||||
|
||||
I was thinking about recent critiques of my writing style
|
||||
and how they don't really apply to my speech,
|
||||
even though I don't imagine myself approaching them differently.
|
||||
|
||||
I imagine I _would_ speak like I write,
|
||||
but that to use the same constructions
|
||||
would require a level of forethought
|
||||
that I'm not capable of under the pressure of conversation.
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/estimating
|
||||
- occupational
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-11-13 08:19:??
|
||||
|
||||
I'm still working on articulating
|
||||
my main difficulty in the transition
|
||||
from Ace to PDI estimating.
|
||||
|
||||
At a high level,
|
||||
it's that our process is built on _instrumental_ methods,
|
||||
but that it is frequently judged from a _realist_ perspective.
|
||||
See [[realism-vs-instrumentalism]].
|
||||
|
||||
There may be a more accurate way to state this.
|
||||
[[2025-11-10#2025-11-10 11 14]] may be an example of a similar issue,
|
||||
where instrumental methods are presented as if they were realist,
|
||||
causing confusion when the methods are,
|
||||
as judged from a realist perspective, wrong.
|
||||
|
||||
[[2025-11-13_08-19-01]]
|
||||
@@ -0,0 +1,18 @@
|
||||
## 2025-11-13 ??:??:??
|
||||
|
||||
#occupational
|
||||
|
||||
### Questions for Bid Estimators
|
||||
|
||||
Questions for [[pdi-estimating#Bid Estimating|PDI Bid Estimators]].
|
||||
|
||||
#### Exclusions
|
||||
|
||||
When we send proposals with significant exclusions
|
||||
(no lighting control, no demo, no submetering,
|
||||
even when designed and shown on drawings):
|
||||
|
||||
Is there a conversation happening with our customers
|
||||
before they receive our proposal?
|
||||
|
||||
Is it clear they understand what we're excluding?
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/hobbies/shorthand
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-11-13 20:41:??
|
||||
|
||||
I've decided I've considered learning [[shorthand]]
|
||||
enough times independently
|
||||
that I would likely benefit from it.
|
||||
|
||||
I added [[leslie-et-al_1968_gregg-notehand|a book]]
|
||||
on [[shorthand#Gregg Notehand|Gregg Notehand]]
|
||||
to my calibre library.
|
||||
@@ -6,14 +6,13 @@ tags:
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/periodic/daily
|
||||
- occupational
|
||||
title: 2025-11-20 08:46:??
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-11-20 08:46:??
|
||||
|
||||
### Elliot St. WBS Prep
|
||||
|
||||
#occupational
|
||||
## Elliot St. WBS Prep
|
||||
|
||||
MC multi-circuit homeruns have makeup included
|
||||
($\text{Length} \times 1.1$)
|
||||
|
||||
@@ -8,11 +8,10 @@ tags:
|
||||
- status/complete
|
||||
- topic/estimating
|
||||
- type/timestamped
|
||||
- topic/organization
|
||||
---
|
||||
# 2025-11-21 10:11:??
|
||||
|
||||
#topic/organization
|
||||
|
||||
> [!quote] [ELECTRI's Industry Benchmarking Tool - ELECTRI International](https://www.electri.org/research-overview/electris-industry-benchmarking-tool/)
|
||||
> ### Hours Burned vs. Hours Earned
|
||||
>
|
||||
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/construction/electrical
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-12-02 10:40:??
|
||||
|
||||
> [!cite] [Hysteresis - Wikipedia](https://en.wikipedia.org/wiki/Hysteresis)
|
||||
> **Hysteresis** is the dependence of the state of a system on its history.
|
||||
> For example, a [magnet](https://en.wikipedia.org/wiki/Magnet "Magnet")
|
||||
> may have more than one possible
|
||||
> [magnetic moment](https://en.wikipedia.org/wiki/Magnetic_moment "Magnetic moment")
|
||||
> in a given [magnetic field](https://en.wikipedia.org/wiki/Magnetic_field "Magnetic field"),
|
||||
> depending on how the field changed in the past.
|
||||
> Such a system is called **hysteretic**.
|
||||
|
||||
![[alternating-current#Ferroelectric Hysteresis]]
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-12-02 10:57:??
|
||||
|
||||
### Set Notation Example
|
||||
|
||||
Let $A$ and $B$ be sets
|
||||
sharing some but not all elements.
|
||||
|
||||
* $A \cap B \neq \varnothing$:
|
||||
"The intersection of $A$ and $B$ is nonempty"
|
||||
(They share at least one element).
|
||||
|
||||
* $A \not\subseteq B$:
|
||||
"$A$ is not a subset of $B$"
|
||||
($A$ has at least one element not in $B$).
|
||||
Equivalent to $A \setminus B \neq \varnothing$.
|
||||
|
||||
* $B \not\subseteq A$:
|
||||
"$B$ is not a subset of $A$"
|
||||
($B$ has at least one element not in $A$).
|
||||
Equivalent to $B \setminus A \neq \varnothing$.
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-12-02 13:20:??
|
||||
|
||||
### Panel Schedule Relationship Diagram
|
||||
|
||||
#### Sections
|
||||
|
||||
A panelboard with multiple sections
|
||||
may or may not have multiple schedules.
|
||||
`PANEL A1 SEC 1`
|
||||
|
||||
#### Typical Schedules
|
||||
|
||||
Schedules may be typical of multiple panelboards
|
||||
`PANEL H(2-6)`
|
||||
@@ -7,14 +7,14 @@ tags:
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/timestamped
|
||||
- topic/estimating
|
||||
- topic/transparency
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-12-03 15:54:22
|
||||
|
||||
## Excluding Vs. Ignoring Project Requirements
|
||||
|
||||
#topic/estimating #topic/transparency
|
||||
|
||||
There is a distinct difference between _excluding_ and _ignoring_ requirements.
|
||||
|
||||
If, before award, you communicate to the customer
|
||||
|
||||
@@ -7,14 +7,15 @@ tags:
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/timestamped
|
||||
- occupational/takeoff
|
||||
- topic/ambiguity
|
||||
- topic/transparency
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-12-10 10:45:19
|
||||
|
||||
## ConEst Lighting Controls Meeting Notes
|
||||
|
||||
#occupational/takeoff #topic/ambiguity #topic/transparency
|
||||
|
||||
Related: [[lighting-controls-takeoff]]
|
||||
|
||||
### Minutes
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-12-16 09:20:52
|
||||
|
||||
[Probability Management](https://www.probabilitymanagement.org/)
|
||||
|
||||
[Handbook of Decision Analysis | Wiley Online Books](https://onlinelibrary.wiley.com/doi/book/10.1002/9781118515853)
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-12-16 20:04:??
|
||||
|
||||
### Metalog Distributions
|
||||
|
||||
[Metalog Distributions]http://www.metalogdistributions.com/home.html)
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-12-17 05:39:??
|
||||
|
||||
One aspect of estimating that I find most interesting,
|
||||
but that is criminally understudied,
|
||||
is the effect of building dimensions
|
||||
(footprint shape, floor area, stories, height)
|
||||
on total cost.
|
||||
|
||||
Unfortunately, lack of interest in the subject extends beyond estimating.
|
||||
Discourse on spatial data seems to fall into one of two bins:
|
||||
* civil engineering
|
||||
* n-dimensional mathematics[^1]
|
||||
neither are readily applicable to building construction.
|
||||
|
||||
[^1]: worse still, the "space" studied in such disciplines is
|
||||
[vector space](https://en.wikipedia.org/wiki/Vector_space)
|
||||
where "distance" is a measure of similarity
|
||||
and physical geometry is rarely considered.
|
||||
|
||||
Of the two, pure math would be be preferred---
|
||||
being generally more rigorous---
|
||||
but the first bin far outweighs the second.
|
||||
See the difference in content from
|
||||
[geostatistics](https://en.wikipedia.org/wiki/Geostatistics)
|
||||
to the conceivably far more broad
|
||||
[spatial statistics](https://en.wikipedia.org/wiki/Spatial_statistics).
|
||||
|
||||
> [!quote] [Geographic data and information](https://en.wikipedia.org/wiki/Geographic_data_and_information)
|
||||
> **Spatial data** or **spatial information** is broader class of data
|
||||
> whose geometry is relevant
|
||||
> but it is not necessarily [georeferenced](https://en.wikipedia.org/wiki/Georeferenced "Georeferenced"),
|
||||
> such as in computer-aided design (CAD),
|
||||
> see [geometric modeling](https://en.wikipedia.org/wiki/Geometric_modeling "Geometric modeling").
|
||||
|
||||
### Ambiguity
|
||||
|
||||
New Note: [[ambiguity]]
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/ambiguity
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-12-17 12:32:??
|
||||
|
||||
A while ago I heard a minor coding influencer lament
|
||||
that frameworks, packages, and tools
|
||||
often have ridiculous sounding names[^2]
|
||||
when, he suggests, they ought to just be called what they do.
|
||||
|
||||
[^2]: `bubble-tea` and `ratatui`
|
||||
(libraries for creating CLI's) come to my mind
|
||||
|
||||
Unfortunately some people and organizations agree with him,
|
||||
giving us terms which mean both something very general
|
||||
and something very specific.[^3]
|
||||
|
||||
[^3]: [[project-management-tm|"Project Management"]]
|
||||
was my go to example, but weak
|
||||
because it's difficult for me to articulate
|
||||
the difference from construction project management
|
||||
especially to someone unfamiliar with the specifics of either.
|
||||
|
||||
For lack of a better term I've been thinking of this as an SEO problem,
|
||||
but the bigger problem is that it invites [[ambiguity#Category Mistake|Category Mistake]],
|
||||
whereby the ignorant listener associates traits unique to the example
|
||||
to all things that the name could describe.
|
||||
|
||||
I thought to finally write about this problem
|
||||
while researching [[lighting-controls#Protocols|lighting control protocols]].
|
||||
The two most dominant examples:
|
||||
|
||||
* [[lighting-controls#^dali|"Digital Addressable Lighting Interface (DALI)"]]
|
||||
* [[lighting-controls#^dmx|"Digital Multiplex (DMX)"]]
|
||||
|
||||
while notably different in topology,
|
||||
could both be described accurately with the other's name.
|
||||
|
||||
> It is possible to avoid this problem
|
||||
> without the effort necessary to come up with a clever name.
|
||||
> Just stick an arbitrary, but reasonably unique word
|
||||
> in front of the generic description.
|
||||
> A person's name ("John's Digital Addressable Lighting Interface (JDALI)")
|
||||
> or your favorite animal ("Heron Digital Multiplex (HDMX)") are good options.
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-12-18 08:32:18
|
||||
|
||||
[[uncertainty-in-construction-estimating]]
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/meta
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-12-18 10:38:??
|
||||
|
||||
I definitively think my new approach
|
||||
of putting nascent ideas in [[periodic-notes|daily notes]]
|
||||
rather than separate fleeting notes
|
||||
is superior.
|
||||
|
||||
The unfortunate reality is I'll never look at most of them again,
|
||||
so better that they don't crowd out my main notes.
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-12-18 14:18:??
|
||||
|
||||
### Estimating Golf
|
||||
|
||||
What interests me most in [[construction-estimating]]
|
||||
is an idea you might call "estimating golf":
|
||||
the goal is to produce a satisfactory[^1] estimate,
|
||||
but the estimator can not view the project documents
|
||||
and must instead ask questions about the job
|
||||
(answerable in a sentence or less)
|
||||
of a neutral party ("the reader").
|
||||
The estimator fails if the estimate is unsatisfactory[^1],
|
||||
but otherwise is scored by number of questions asked.
|
||||
|
||||
[^1]: satisfactory in terms of accuracy and precision,
|
||||
according to the standards of the organization.
|
||||
a control estimate must be prepared accordingly
|
||||
by a neutral party ("the control").
|
||||
|
||||
You could further imagine different brackets
|
||||
for required accuracy and precision,
|
||||
whether organization historicals are freely available
|
||||
or must be questioned like project details.
|
||||
|
||||
The most interesting part of this problem is choosing when to stop,
|
||||
since it requires one to estimate their certainty of their estimate.
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-12-18 15:22:??
|
||||
|
||||
PDI has moved up the schedule to transition to Accubid Anywhere
|
||||
and will be signing a contract with Trimble in late January.
|
||||
|
||||
[Drawer AI | Automated Electrical Takeoff & Estimating](https://drawer.ai/)
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-12-18 15:30:??
|
||||
|
||||
[Kip (unit) - Wikipedia](https://en.wikipedia.org/wiki/Kip_\(unit\))
|
||||
[Construction Cost Estimating](https://www.quantity-takeoff.com/index.htm)
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
- occupational/takeoff
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-12-19 10:44:??
|
||||
|
||||
> [!quote] Art Baldwin 2025-12-19, in reference to Howard University East Towers (pp.)
|
||||
> When using PVC slab box assemblies where substantial insulation
|
||||
> (e.g mineral wool, spray foam) is to be applied,
|
||||
> add extension rings to compensate for the thickness
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
- occupational/takeoff
|
||||
dg-publish: true
|
||||
---
|
||||
# 2025-12-19 10:44:??
|
||||
|
||||
This week (2025w51)
|
||||
William Bonn, as part of [[units-takeoff]] for Howard University East Towers,
|
||||
used an `Area` "Typical - Unit Balconies" for `Phase` "UNIT - RESIDENTIAL" takeoff.
|
||||
Our senior Joel Jansen approved of the method.
|
||||
|
||||
I'd like to use the method tentatively for takeoff strictly typical of all units
|
||||
(e.g. master switches, MSDE's, etc.),
|
||||
but there is potential for significant efficiency gains
|
||||
in treating units like panelboards in [[switchgear-takeoff]]:
|
||||
picking one unit type to be typical of many nearly identical types.
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-02 10:10:18
|
||||
|
||||
### Harborside Plaza 4
|
||||
|
||||
#### TODO
|
||||
|
||||
* [ ] [[electrical-takeoff|Electrical]]
|
||||
* [x] [[telecom-takeoff#Backbone Riser|Telecom Backbone]]
|
||||
* [x] [[distributed-antenna-systems-takeoff|DAS]]
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-02 19:21:??
|
||||
|
||||
Without apparent prompt I was reminded of a practical joke
|
||||
that my fellow apprentice Joe used to play often
|
||||
that never failed to get a laugh out of me:
|
||||
|
||||
Mid-conversation Joe would stop suddenly,
|
||||
search in his pockets or tool belt,
|
||||
pull out a random object (usually his lineman's pliers),
|
||||
and act as if he had received a phone call on it.
|
||||
Often the other party had apparently dialed in error,
|
||||
and Joe would say, "Hello?... Hello?"
|
||||
before deciding they'd hung up.
|
||||
Other times he'd step away (only one step)
|
||||
and have whole conversations.
|
||||
|
||||
Try as I might have,
|
||||
I could never pull it off like he could.
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-06 07:47:??
|
||||
|
||||
### _Let Them Theory_ Theory
|
||||
|
||||
1. Person habitually engages in toxic behavior
|
||||
which they consciously believe to be benevolent
|
||||
|
||||
2. Person recognizes that when they stop engaging in said toxic behavior,
|
||||
others appreciate it
|
||||
|
||||
3. Person feels that they are doing a service
|
||||
by not engaging in said toxic behavior
|
||||
@@ -0,0 +1,92 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-06 10:00:??
|
||||
|
||||
Paraphrased Teams conversation with a peer
|
||||
about [[distribution-designations#Terminations]].
|
||||
Peer's messages are in block quotes.
|
||||
|
||||
***
|
||||
|
||||
> Good morning!
|
||||
> Do you add branch terminations to panelboards?
|
||||
> If so, how does your 'distribution' section looks?
|
||||
|
||||
Morning! Yes to the first question, ? to the second
|
||||
|
||||
> As all panelboards on a job don't have the same size/# of terminations,
|
||||
> I assume you would have a plethora of same size boards in the job, with different terms.
|
||||
> How do you list them?
|
||||
|
||||
| | Designation | Status | Quantity |
|
||||
| --- | ----------------------------- | ------ | -------- |
|
||||
| 1 | Generator - 350kW, Diesel | | 1 |
|
||||
| 2 | Generator - 2000kW, Diesel | | 1 |
|
||||
| 3 | ATS - 200A | | 2 |
|
||||
| 4 | ATS - 250A | | 1 |
|
||||
| 5 | ATS - 400A | | 2 |
|
||||
| 6 | ATS - 600A | | 2 |
|
||||
| 7 | ATS - 800A | | 1 |
|
||||
| 8 | ATS - 1000A | | 1 |
|
||||
| 9 | Panelboard - 50A, 1-Section | | 1 |
|
||||
| 10 | Panelboard - 100A, 1-Section | | 18 |
|
||||
| 11 | Panelboard - 125A, 1-Section | | 26 |
|
||||
| 12 | Panelboard - 150A, 1-Section | | 2 |
|
||||
| 13 | Panelboard - 225A, 1-Section | | 11 |
|
||||
| 14 | Panelboard - 225A, 2-Section | | 5 |
|
||||
| 15 | Panelboard - 400A, 1-Section | | 2 |
|
||||
| 16 | Panelboard - 400A, 2-Section | | 3 |
|
||||
| 17 | Panelboard - 400A, 3-Section | | 5 |
|
||||
| 18 | Panelboard - 600A, 2-Section | | 1 |
|
||||
| 19 | Panelboard - 800A, 1-Section | | 1 |
|
||||
| 20 | Panelboard - 1200A, 1-Section | | 2 |
|
||||
| 21 | Panelboard - 1200A, 2-Section | | 1 |
|
||||
| 22 | Panelboard - 3000A, 1-Section | | 1 |
|
||||
| 23 | CT Cabinet | | |
|
||||
| 24 | Power Monitor | | 82 |
|
||||
| 25 | SPD/TVSS | | 2 |
|
||||
|
||||
> Ah, so you just chuck in a lot # of terms per board and call it good?
|
||||
|
||||
Essentially.
|
||||
Ben's direction was to pick a schedule
|
||||
on the upper end of terms for each size panel
|
||||
to be representative of the rest.
|
||||
At my old place I would have made a designation for each panel,
|
||||
I'm not upset to leave that behind.
|
||||
I see no reason you couldn't just make each size once
|
||||
and keep it in a temp job.
|
||||
I would, but I usually extract the schedules anyway
|
||||
so I just use the actual average.
|
||||
|
||||
> Thank you for that.
|
||||
> Joel wagged his finger at me about missing terms this morning---
|
||||
> I wanted to see how it's preferred.
|
||||
> I was told terms are captured by feeders/mech connections
|
||||
> and have never added them to panelboards.
|
||||
>
|
||||
> That would be the best way, finding the actual average.
|
||||
|
||||
The mech connection assemblies have the load side term,
|
||||
the feeder assemblies have both sides,
|
||||
the branch assemblies don't have either,
|
||||
that's why he got you, I think.
|
||||
|
||||
I don't think my way is best
|
||||
unless you already have all the circuits in a big table for other reasons.
|
||||
Lot of effort for a marginal increase in certainty above a heuristic like Ben's.
|
||||
|
||||
I'm working on a job Noah started now,
|
||||
he made certain panels separate from what I assume is the average
|
||||
and labeled them with the name of the panel.
|
||||
If I had a job where some were significantly more full than others
|
||||
I _might_ do something similar,
|
||||
but I'd probably name them
|
||||
"... 1-Section, ~25% Fill"/"... 1-Section, ~75% Fill" instead.
|
||||
But that's a lot of mental overhead.
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-06 10:57:??
|
||||
|
||||
Tracking contractor growth by project square footage
|
||||
rather than contract value dollars.
|
||||
Account for market shifts and regional differences.
|
||||
|
||||
Problematic for other than new residential construction.
|
||||
Do you count site area?
|
||||
Out of contract building area for renovations?
|
||||
|
||||
Maybe the sum of in-contract building area and other areas prorated somehow.
|
||||
|
||||
Seems imminently gameable.
|
||||
See [[incentives#Perverse Incentive]]
|
||||
and [[estimating-culture#Incentives]].
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-07 06:41:??
|
||||
|
||||
> [!quote] _The Shadow of the Torturer_, Chapter 17: "The Challenge"
|
||||
> No intellect is needed to see those figures who wait beyond the void of death---
|
||||
> every child is aware of them, blazing with glories dark or bright,
|
||||
> wrapped in authority older than the universe.
|
||||
> They are the stuff of our earliest dreams, as of our dying visions.
|
||||
> Rightly we feel our lives guided by them,
|
||||
> and rightly too we feel how little we matter to them,
|
||||
> the builders of the unimaginable,
|
||||
> the fighters of wars beyond the totality of existence.
|
||||
>
|
||||
> The difficulty lies in learning that we ourselves encompass forces equally great.
|
||||
> We say, "I will," and "I will not," and imagine ourselves
|
||||
> (though we obey the orders of some prosaic person every day) our own masters,
|
||||
> when the truth is that our masters are sleeping.
|
||||
> One wakes within us and we are ridden like beasts,
|
||||
> though the rider is but some hitherto unguessed part of ourselves.
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-07 10:03:??
|
||||
|
||||
At Ace, "residential" always meant single-family/duplex construction,
|
||||
but I think now we were the outliers.
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-07 10:05:??
|
||||
|
||||
See [[pdi-breakdowns#Location]].
|
||||
|
||||
I have---for some time now---
|
||||
been trying to figure out the purpose of the non-system breakdowns.
|
||||
|
||||
[[location-vs-scope]]
|
||||
|
||||
Perhaps there is another dichotomy
|
||||
in that an estimator may use the area classifications of the design
|
||||
or according to their own understanding of each term.
|
||||
For lack of a better example,
|
||||
whether a "101 - KITCHEN", without provisions for cooking,
|
||||
would be broken down under "Kitchen".
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-07 10:42:??
|
||||
|
||||
When I got to work today Art admonished a fellow estimator
|
||||
for not uploading _all_ of a project's drawings,
|
||||
even those they did not intend to take off, to Trimble Connect.
|
||||
Art suggested that the estimator should upload all the drawings,
|
||||
but only add them to LiveCount as needed.
|
||||
|
||||
I take issue with the suggestion on principle
|
||||
since doing so would not benefit the estimator or their senior
|
||||
(if they aren't added, the estimator can do nothing with them),
|
||||
but would require not-insignificant effort.
|
||||
Effort that would ultimately benefit no one:---
|
||||
|
||||
Trimble Connect's ham-fisted approach to version control
|
||||
means that the fewer times it must be used, the better.
|
||||
|
||||
> I'm currently dealing with the headache of an estimate
|
||||
> where such caution was not applied.
|
||||
|
||||
The probability that any construction will be performed
|
||||
according the drawings that we take off
|
||||
(or even their immediate successors)
|
||||
I suspect is slim to zero.
|
||||
That Ops would have the patience to add the revisions,
|
||||
fighting with Trimble Connect as they would be,
|
||||
I suspect is even less.
|
||||
|
||||
> On my current project, after trying in vain to play by Trimble's rules,
|
||||
> I started by deleting all the drawings I could
|
||||
> (those without takeoff associated with them)
|
||||
> then reuploaded the revised set.
|
||||
> I'm confident that this would be the dominant strategy.
|
||||
|
||||
***
|
||||
|
||||
It's curious to me that the possibility of scope revisions
|
||||
doesn't seem to be at the front of every estimator's mind
|
||||
when doing takeoff or considering process changes,
|
||||
like it was for my mentors and peers at Ace.
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
- occupational
|
||||
- topic/estimating
|
||||
- topic/organization
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-07 12:13:??
|
||||
|
||||
Just now Jorge admonished another peer
|
||||
for using insulated wire for pool bonding,
|
||||
his rational was flawed beyond saving
|
||||
(something about the difference between bonding and grounding),
|
||||
but stemmed from a frustratingly common misunderstanding
|
||||
that our Accubid assemblies are intended to be an accurate list
|
||||
of the material to be installed.
|
||||
|
||||
They are not.
|
||||
If they were intended to be accurate,
|
||||
there would need to be several times as many.
|
||||
They are a compromise between accuracy and estimator effort.
|
||||
It should be assumed that for common scope,
|
||||
at least one assembly should be acceptable as-is.
|
||||
|
||||
Pool bonding is required for at least a quarter of our jobs.
|
||||
We have no bonding assemblies with bare wire.
|
||||
Therefore it must be assumed that it was determined
|
||||
that it would be acceptable to represent bare wire bonding with insulated wire items,
|
||||
because otherwise it would be necessary to have double the assemblies,
|
||||
or to expect estimators to substitute each size of wire
|
||||
everywhere bare was necessary.
|
||||
|
||||
See [[realism-vs-instrumentalism]].
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
- occupational
|
||||
- topic/estimating
|
||||
- topic/organization
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-07 16:03:??
|
||||
|
||||
There is a palpable animosity for [[pdi-estimating#Bid Estimating|Bid]]
|
||||
in [[pdi-estimating#Construction Estimating (ConEst)|ConEst]],
|
||||
stemming---I believe---from an lack of buy-in on Bid's part.
|
||||
Their lack is easily explained by their [[estimating-culture#Incentives|incentive structure]]:
|
||||
Since throughput is systematically prioritized over accuracy,
|
||||
ConEst has a strictly antagonistic role
|
||||
because it slows down the bid process.
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-08 13:33:34
|
||||
|
||||
### 2100 Crystal Drive Takeoff Review
|
||||
|
||||
#### Generators
|
||||
|
||||
> [!failure]
|
||||
> Generators were erroneously broken down in switchgear.
|
||||
|
||||
[[switchgear-takeoff#Generator|Generator]]
|
||||
|
||||
#### Switchgear
|
||||
|
||||
Switchgear cost comp
|
||||
"\\EgnyteDrive\Shared\Estimating\11 Bid Estimating Spreadsheets\Switchgear Pricing Tool Version 2 (2.02.2024) (Template) - Copy.xls"
|
||||
|
||||
Includes
|
||||
* submetering
|
||||
* coordination study
|
||||
|
||||
#### Composite Cleanup
|
||||
|
||||
1 day per week
|
||||
|
||||
$$
|
||||
\text{Average Weeks Per Month} =
|
||||
$$
|
||||
|
||||
> It occurs to me I don't know all the rules of our calendar
|
||||
> [Gregorian calendar - Wikipedia](https://en.wikipedia.org/wiki/Gregorian_calendar)
|
||||
|
||||
#### Temp Power
|
||||
|
||||
$10,000 per [[heavy-equipment#Swing Stage Scaffolding|swing stage]]
|
||||
|
||||
[[temp-power-takeoff]]
|
||||
|
||||
#### Unit Typicals
|
||||
|
||||
I asked Joel about using unit typicals as described in
|
||||
[[2025-12-19#2025-12-19 10:44]].
|
||||
He stated that would be acceptable.
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-09 10:00:03
|
||||
|
||||
### 2100 Crystal Drive
|
||||
|
||||
`#600 ? WHITE ?` had incorrect sort codes.
|
||||
|
||||
#### Lighting Control
|
||||
|
||||
I took off lighting per plans (E510)
|
||||
in spite of proposal stating "local control".
|
||||
Will have to be changed.
|
||||
|
||||
#### Labor Factor
|
||||
|
||||
Fire Alarm
|
||||
Switchgear
|
||||
Feeders
|
||||
Subfeeds
|
||||
Corridors
|
||||
Amenity
|
||||
Retail
|
||||
Units
|
||||
|
||||
#### Fixtures
|
||||
|
||||
> [!failure]
|
||||
> Several fixtures were erroneously based on NM cable.
|
||||
|
||||
I built some fixtures with \#12/3 in areas with emergency lighting
|
||||
to be an unswitched hot.
|
||||
Joel is having me change them to \#12/2.
|
||||
|
||||
#### Units
|
||||
|
||||
> [!failure]
|
||||
> One unit type typical was missing `Area` quantities.
|
||||
> Another had no takeoff.
|
||||
|
||||
#### Labor Plan
|
||||
|
||||
$$
|
||||
\mathbb{E}\left[\frac{\text{Hours Per Unit}}{\text{Openings Per Unit}}\right] \approx .75~\text{Hours Per Opening}
|
||||
$$
|
||||
|
||||
High Rise .110--.120 hr/sqft
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-09 12:00:??
|
||||
|
||||
$$
|
||||
\begin{gather*}
|
||||
\frac{146097}{400} = 365.2425~\text{Days Per Year} \
|
||||
\frac{20871}{400} = 52.1775~\text{Weeks Per Year} \
|
||||
\frac{6957}{1600} = 4.348125~\text{Weeks Per Month}
|
||||
\end{gather*}
|
||||
$$
|
||||
|
||||
$$
|
||||
\frac{365.2425~\text{Days Per Year}}{7~\text{Days Per Week}}
|
||||
= 52.1775~\text{Weeks Per Year}
|
||||
$$
|
||||
|
||||
$$
|
||||
\frac{52.1775~\text{Weeks Per Year}}{12~\text{Months Per Year}}
|
||||
= 4.348125~\text{Weeks Per Month}
|
||||
$$
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-09 14:45:??
|
||||
|
||||
[[bid-price-modeling]]
|
||||
|
||||
Suppose a true cost model,
|
||||
accounting for all relevant information available at time $t$.
|
||||
|
||||
$C(t)$ returns a distribution whose [scale](https://en.wikipedia.org/wiki/Scale_parameter)
|
||||
decreases with $t$, and $C(0)$ maps to a single value.
|
||||
$t>0$ is time until the final payment.
|
||||
|
||||
> 
|
||||
>
|
||||
> Figure: lognormal distributions with the same [location](https://en.wikipedia.org/wiki/Location_parameter)
|
||||
> varied by [scale](https://en.wikipedia.org/wiki/Scale_parameter).
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-09 16:28:??
|
||||
|
||||
### Occam's razor
|
||||
|
||||
> [!info] Also Known As
|
||||
> * the principle of parsimony
|
||||
> * the law of parsimony
|
||||
|
||||
recommends searching for explanations constructed with the smallest possible set of elements.
|
||||
Attributed to William of Ockham, 14th-century English philosopher and theologian.
|
||||
|
||||
> _Entia non sunt multiplicanda praeter necessitatem_
|
||||
> ("Entities must not be multiplied beyond necessity")
|
||||
|
||||
> "Of two competing theories, the simpler explanation is to be preferred."
|
||||
|
||||
> [!quote] [[klugman-et-al_2019_loss-models#4.2 The Role of Parameters]]
|
||||
> The principle of parsimony states that the simplest model
|
||||
> that adequately reflects reality should be used.
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-11 09:00:??
|
||||
|
||||
[[2026-01-09#2026-01-09 14:45]]
|
||||
|
||||
[[bid-price-modeling]]
|
||||
|
||||
[[decrease-in-sigma]]
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-11 11:00:??
|
||||
|
||||
![[favorite-quotes#"It Takes an Engineer to Build a Bridge that Barely Stands"]]
|
||||
|
||||
The value that estimators provide for a contractor
|
||||
is in modeling project cost.
|
||||
If the goal were simply to present a number the cost will not exceed,
|
||||
than anyone could be an estimator.
|
||||
If the goal were only to present a reasonably accurate figure,
|
||||
with no other constraints,
|
||||
then there are few who in the world who couldn't,
|
||||
given infinite time for a single bid.
|
||||
The _true_ value of an estimator, then,
|
||||
is in their ability to model project cost _efficiently_, that is,
|
||||
to achieve _acceptable_ accuracy and precision as quickly as possible,---
|
||||
much as the engineer's is in building a bridge that _meets_ the requirements
|
||||
as cheaply as possible.
|
||||
|
||||
Estimating "as accurately as possible"
|
||||
is akin to building a bridge "as strong as possible";
|
||||
it sounds nice, but ignores the actual objective of _optimal cost-efficiency_.
|
||||
|
||||
I think that most estimators believe this to be the case,
|
||||
but, whatever they believe in mind, they believe in practice
|
||||
that the goal is to model cost as accurately and precisely as possible,
|
||||
_given the time allowed for bid_.
|
||||
Estimates tend always to take exactly as many weeks as until the bid due date,
|
||||
even those of significantly different turnaround but equal scope and complexity.
|
||||
This behavior is objectionable,
|
||||
since if an acceptable estimate _could_ be provided in two weeks,
|
||||
it is not cost-effective[^1] to allow it to take four.[^2]
|
||||
|
||||
[^1]: "Cost" referring both to estimator salaries and the opportunity cost of declined bids.
|
||||
|
||||
[^2]: Supposing a contractor maintained a modern portfolio theory styled record of estimates
|
||||
including pending bids, and projects ongoing and completed
|
||||
(each with confidence estimates),
|
||||
uncorrupted by [[estimating-culture#Incentives|perverse incentives]],
|
||||
they may have reasonable basis to set sliding standards for estimate precision
|
||||
to be specifically determined at consideration of the opportunity for bid
|
||||
according to current climate (i.e. their transient risk appetite).
|
||||
I believe my use of the absolute is still fair:
|
||||
No contractor is doing that, so they lack a competent measure of risk tolerance
|
||||
besides continuing to tolerate what they have historically.
|
||||
|
||||
> [!important]
|
||||
> Objectionable as it is,
|
||||
> it is to be expected that estimators will use all time allowed them
|
||||
> when the standards for _acceptability_ are inadequately defined.
|
||||
@@ -1,11 +1,13 @@
|
||||
---
|
||||
id: 2026-01-12T10:00:00-05:00
|
||||
title: 2026-01-12 10:00:??
|
||||
tags:
|
||||
- type/timestamped
|
||||
- occupational
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-12 10:00:??
|
||||
|
||||
#occupational
|
||||
|
||||
### ECH3 Executed Contract Revision WBS
|
||||
|
||||
For Executed Contract Revisions, Bid GP% must be maintained.
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
---
|
||||
id: 2026-01-12T10:42:30-05:00
|
||||
title: 2026-01-12 10:42:30
|
||||
tags:
|
||||
- type/timestamped
|
||||
- occupational
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-12 10:42:30
|
||||
|
||||
#occupational
|
||||
|
||||
### Woodbrook Executed Contract Revision Takeoff Check
|
||||
|
||||
#### Unit Dishwasher/Disposal
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
---
|
||||
id: 2026-01-12T12:23:00-05:00
|
||||
title: 2026-01-12 12:23:??
|
||||
tags:
|
||||
- type/timestamped
|
||||
- occupational
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-12 12:23:??
|
||||
|
||||
#occupational
|
||||
|
||||
Travelling with Brian Smarslok and Joel Jansen on [[2026-01-15]]
|
||||
to visit [[#Woodbury Heights|an awarded project]] in New Jersey.
|
||||
Flying from TPA to PHL, departure @ 7:00AM.
|
||||
|
||||
@@ -1,31 +1,12 @@
|
||||
---
|
||||
id: 2026-01-12T13:02:00-05:00
|
||||
title: 2026-01-12 13:02:??
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/construction
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-12 13:02:??
|
||||
|
||||
#topic/construction
|
||||
|
||||
**Dry utilities:** utilities other than "wet" utilities (water, sewer, stormwater),
|
||||
namely power, data, and natural gas.
|
||||
|
||||
# 2026-01-12 13:02:??
|
||||
|
||||
#occupational
|
||||
|
||||
Joel attributes the [[#GP Variance|apparent variance]] to
|
||||
1. missed Polaris lugs for feeders for one building,
|
||||
2. insufficient budget for equipment rental, and
|
||||
3. upfront costs already paid (construction is 50% complete).
|
||||
|
||||
He also said that operations accused ConEst
|
||||
of providing insufficient length for subfeeds,
|
||||
which he said was true,
|
||||
but not to the extent accused
|
||||
(only ~600ft missed total).
|
||||
|
||||
The award WBS shows $32,382 for equipment rental
|
||||
|
||||
I'm dubious of all these explanations,
|
||||
but I don't have another one.
|
||||
I can't find the ConEst folder or Accubid file.
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
# 2026-01-12 13:02:??
|
||||
|
||||
#occupational
|
||||
|
||||
Joel attributes the [[#GP Variance|apparent variance]] to
|
||||
1. missed Polaris lugs for feeders for one building,
|
||||
2. insufficient budget for equipment rental, and
|
||||
3. upfront costs already paid (construction is 50% complete).
|
||||
|
||||
He also said that operations accused ConEst
|
||||
of providing insufficient length for subfeeds,
|
||||
which he said was true,
|
||||
but not to the extent accused
|
||||
(only ~600ft missed total).
|
||||
|
||||
The award WBS shows $32,382 for equipment rental
|
||||
|
||||
I'm dubious of all these explanations,
|
||||
but I don't have another one.
|
||||
I can't find the ConEst folder or Accubid file.
|
||||
@@ -7,12 +7,11 @@ tags:
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/timestamped
|
||||
- occupational
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-13 11:28:14
|
||||
|
||||
#occupational
|
||||
|
||||
### 2100 Crystal Drive ConEst Manager Review
|
||||
|
||||
#### Josh's Review Order
|
||||
|
||||
@@ -7,12 +7,11 @@ tags:
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/timestamped
|
||||
- occupational
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-14 13:27:20
|
||||
|
||||
#occupational
|
||||
|
||||
Follow-up to [[2026-01-13#Lighting Control]]
|
||||
|
||||
Conversation between Joel Jansen and Christian Pereiro
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-15 08:11:10
|
||||
|
||||
Follow-up to [[2026-01-12#2026-01-12 12:23|2026-01-12 12:23]]
|
||||
|
||||
Left Apartment at 05:30, at terminal around 06:10.
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
id:
|
||||
aliases: []
|
||||
title:
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-15 08:15:??
|
||||
|
||||
[[2025-11-13#2025-11-13 08:19]]
|
||||
I spoke to a peer about this yesterday.
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
id: 2026-01-19T11:57:39-05:00
|
||||
title: 2026-01-19 11:57:39
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-19 11:57:39
|
||||
|
||||
|
||||
@@ -1,11 +1,14 @@
|
||||
---
|
||||
id: 2026-01-19T12:32:00-05:00
|
||||
title: 2026-01-19 12:32:??
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/construction
|
||||
- topic/estimating
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-19 12:32:??
|
||||
|
||||
#topic/construction #topic/estimating
|
||||
|
||||
Real example of [[location-vs-scope]]:
|
||||
|
||||
450-460 James Robertson Parkway Phase II (fka James Roberston Pkwy Mixed Use Development)
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
id: 2026-01-19T18:13:00-05:00
|
||||
title: 2026-01-19 18:13:??
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-19 18:13:??
|
||||
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
id: 2026-01-20T09:09:12-05:00
|
||||
title: 2026-01-20 09:09:12
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-20 09:09:12
|
||||
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
id: 2026-01-20T10:10:00-05:00
|
||||
title: 2026-01-20 10:10:??
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-20 10:10:??
|
||||
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
id: 2026-01-20T14:25:00-05:00
|
||||
title: 2026-01-20 14:25:??
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-20 14:25:??
|
||||
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
---
|
||||
id: 2026-01-22T09:55:42-05:00
|
||||
title: 2026-01-22 09:55:42
|
||||
tags:
|
||||
- type/timestamped
|
||||
- occupational
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-22 09:55:42
|
||||
|
||||
#occupational
|
||||
|
||||
The lighting drawings for
|
||||
450-460 James Robertson Parkway Phase II
|
||||
(fka James Roberston Pkwy Mixed Use Development)
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
---
|
||||
id: 2026-01-22T11:58:00-05:00
|
||||
title: 2026-01-22 11:58:??
|
||||
tags:
|
||||
- type/timestamped
|
||||
- occupational
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-22 11:58:??
|
||||
|
||||
#occupational
|
||||
|
||||
### 463 Davison Contract Dates
|
||||
|
||||
[[463-davison-ave-ne]]
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
---
|
||||
id: 2026-01-22T14:56:00-05:00
|
||||
title: 2026-01-22 14:56:??
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/estimating
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-22 14:56:??
|
||||
|
||||
#topic/estimating
|
||||
|
||||
### Accurate Budget Vs. Accurate BOM
|
||||
|
||||
#### Quote
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
id: 2026-01-23T08:18:53-05:00
|
||||
title: 2026-01-23 08:18:53
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-23 08:18:53
|
||||
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
id: 2026-01-23T12:34:00-05:00
|
||||
title: 2026-01-23 12:34:??
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-23 12:34:??
|
||||
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
---
|
||||
id: 2026-01-25T18:46:00-05:00
|
||||
title: 2026-01-25 18:46:??
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/finance
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-25 18:46:??
|
||||
|
||||
#topic/finance
|
||||
|
||||
### Calculating Monthly Principal & Interest Payment
|
||||
|
||||
For a **fixed-rate, fully-amortizing mortgage**,
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
id: 2026-01-25T21:02:00-05:00
|
||||
title: 2026-01-25 21:02:??
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-25 21:02:??
|
||||
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
id: 2026-01-25T22:59:00-05:00
|
||||
title: 2026-01-25 22:59:??
|
||||
tags:
|
||||
- type/timestamped
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-25 22:59:??
|
||||
|
||||
|
||||
@@ -7,12 +7,11 @@ tags:
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/timestamped
|
||||
- topic/hobbies/reading
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-27 17:31:??
|
||||
|
||||
#topic/hobbies/reading
|
||||
|
||||
### BLAME! Coelacanth
|
||||
|
||||
Follow-up to [[2026-01-26#BLAME! Coelacanth]]
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
---
|
||||
id: 2026-01-28T09:51:08-05:00
|
||||
title: 2026-01-28 09:51:08
|
||||
tags:
|
||||
- type/timestamped
|
||||
- occupational
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-28 09:51:08
|
||||
|
||||
#occupational
|
||||
|
||||
### ConEst OneNote Template
|
||||
|
||||
The ConEst OneNote template concept
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
---
|
||||
id: 2026-01-28T10:02:00-05:00
|
||||
title: 2026-01-28 10:02:??
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/meta
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-28 10:02:??
|
||||
|
||||
#topic/meta
|
||||
|
||||
I'm tempted to replace \[\[daily-notes\]\] with timestamped notes
|
||||
from core plugins Unique Note Creator,
|
||||
however the utility of the calendar widget is hard to concede.
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
---
|
||||
id: 2026-01-29T10:07:37-05:00
|
||||
title: 2026-01-29 10:07:37
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/estimating
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-29 10:07:37
|
||||
|
||||
#topic/estimating
|
||||
|
||||
A peer's senior, expressing frustration,
|
||||
told them that it if they disagree with an instruction,
|
||||
they must have a reason,
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
---
|
||||
id: 2026-01-29T17:57:00-05:00
|
||||
title: 2026-01-29 17:57:??
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/finance
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-29 17:57:??
|
||||
|
||||
#topic/finance
|
||||
|
||||
### Calculating Utility of Above-Minimum Mortgage Payment
|
||||
|
||||
See [[2026-01-25#Calculating Monthly Principal & Interest Payment]].
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
---
|
||||
id: 2026-01-30T08:44:29-05:00
|
||||
title: 2026-01-30 08:44:29
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/meta
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-30 08:44:29
|
||||
|
||||
#topic/meta
|
||||
|
||||
Follow-up to [[2026-01-28_10-02-00]].
|
||||
|
||||
I really would like to implement timestamped notes,
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
---
|
||||
id: 2026-01-30T09:06:00-05:00
|
||||
title: 2026-01-30 09:06:??
|
||||
tags:
|
||||
- type/timestamped
|
||||
- topic/meta
|
||||
dg-publish: true
|
||||
---
|
||||
# 2026-01-30 09:06:??
|
||||
|
||||
#topic/meta
|
||||
|
||||
I tried the Smart Connections community plugin.
|
||||
I can't imagine who it could be useful for.
|
||||
It seems to just identify large blocks of similar content,
|
||||
|
||||
@@ -1,6 +1,11 @@
|
||||
---
|
||||
id: 2026-01-30T13:42:00-05:00
|
||||
aliases: []
|
||||
title: 2026-01-30 13:42:??
|
||||
tags:
|
||||
- authorship/original
|
||||
- topic/personal-productivity
|
||||
- type/timestamped
|
||||
---
|
||||
# 2026-01-30 13:42:??
|
||||
|
||||
@@ -25,4 +30,4 @@ _and the will to contradict you_
|
||||
is worthless.
|
||||
If the effort to _communicate_ your instructions
|
||||
exceeds the effort to perform them,
|
||||
you will always do the task yourself.
|
||||
you will always do the task yourself.
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
---
|
||||
id: 2026-01-30T16:29:00-05:00
|
||||
aliases: []
|
||||
title: 2026-01-30 16:29:??
|
||||
tags:
|
||||
- authorship/original
|
||||
- topic/math/statistics
|
||||
---
|
||||
# 2026-01-30 16:29:??
|
||||
|
||||
#topic/math/statistics
|
||||
|
||||
### Laplace's Rule of Succession (LRS)
|
||||
|
||||
> [!info]
|
||||
@@ -29,4 +31,4 @@ $n$ times in a row.
|
||||
|
||||
There is a 93.75% chance that the median of a population
|
||||
is between the smallest and largest values
|
||||
in any random sample of five from that population.
|
||||
in any random sample of five from that population.
|
||||
|
||||
@@ -1,11 +1,14 @@
|
||||
---
|
||||
id: 2026-01-30T18:33:00-05:00
|
||||
aliases: []
|
||||
title: 2026-01-30 18:33:??
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- topic/personal-productivity
|
||||
---
|
||||
# 2026-01-30 18:33:??
|
||||
|
||||
#topic/personal-productivity
|
||||
|
||||
Why is it that I find it so easy, even compulsory,
|
||||
to clean my house while working from home,
|
||||
even after returning from work on-site?
|
||||
|
||||
@@ -12,7 +12,7 @@ dg-publish: true
|
||||
---
|
||||
# 2026-01-31 12:48:00
|
||||
|
||||
Follow-up to [[2026-01-19#2026-01-19 11:57]]
|
||||
Follow-up to [[2026-01-19_11-57-39]]
|
||||
|
||||
a **natural-language parser**
|
||||
could easily determine where hyphens should be replaced with em dashes.
|
||||
|
||||
@@ -15,6 +15,8 @@ daily: "[[2026-02-04]]"
|
||||
|
||||
## Questions for ConEst
|
||||
|
||||
[[pdi-estimating#Construction Estimating (ConEst)]]
|
||||
|
||||
### Purpose of ConEst
|
||||
|
||||
What is the purpose of ConEst?
|
||||
|
||||
@@ -14,7 +14,7 @@ daily: "[[2026-02-04]]"
|
||||
|
||||
## Time Interval Conversion
|
||||
|
||||
In [[2026-01-09#2026-01-09 12:00]]
|
||||
In [[2026-01-09_12-00-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.
|
||||
|
||||
@@ -16,7 +16,7 @@ yearly: "[[2026]]"
|
||||
---
|
||||
# 2026-02-17 13:13:06
|
||||
|
||||
Relevant to [[2025-11-21_10-11-00#2025-11-21 10:11:??|2025-11-21 10:11:??]]
|
||||
Relevant to [[2025-11-21_10-11-00]]
|
||||
|
||||
Today I spoke to a peer about
|
||||
[[earned-value-management#Earned Value Management|earned value management]]:
|
||||
|
||||
Reference in New Issue
Block a user