vault backup: 2026-04-10 13:57:01
This commit is contained in:
@@ -48,7 +48,7 @@ Create and use cross-topic notes for complex thoughts:
|
||||
* [[estimating-culture#Incentives]]
|
||||
|
||||
* [[project-management-for-construction-estimating]]
|
||||
* [[separating-estimating-concerns]]
|
||||
* [[separation-of-concerns-for-construction-estimating]]
|
||||
|
||||
* [[ambiguity-in-construction-estimating]]
|
||||
|
||||
|
||||
@@ -30,4 +30,4 @@ consistent with ignorance of consumer need.
|
||||
[[ai-in-estimating]] is a depressing example
|
||||
of how little estimators can expect for innovative features from these companies.
|
||||
|
||||
[[separating-estimating-concerns]]
|
||||
[[separation-of-concerns-for-construction-estimating]]
|
||||
|
||||
+5
-1
@@ -77,6 +77,10 @@ because any recognized wiring method must include the
|
||||
necessary of a complete wiring installation,
|
||||
each of which has countless options.
|
||||
|
||||
It may be more consistent with NEC phrasing
|
||||
to say that each component is _a_ wiring method,
|
||||
but this is less consistent with common use.
|
||||
|
||||
### Appropriate Use
|
||||
|
||||
It may be appropriate to refer to "MC cable" as _a_ wiring method
|
||||
@@ -84,7 +88,7 @@ if you and your audience understand the name as shorthand
|
||||
for a more specific, standard framework.
|
||||
|
||||
In a robustly implemented specification-based takeoff software,
|
||||
an assembly's specifications would describe it's wiring methods.
|
||||
an assembly's specifications would describe its wiring methods.
|
||||
A 20A and 30A branch circuit may utilize identical "wiring methods".
|
||||
|
||||
## Takeaways
|
||||
|
||||
+1
-1
@@ -18,7 +18,7 @@ designed to facilitate faster transcription.
|
||||
It is known by many other names,
|
||||
and may be more accurately called _stenography_,
|
||||
but [[stenography]] is more widely understood
|
||||
as the method practiced by modern court stenographers,
|
||||
as the method practiced by modern court stenographers:
|
||||
typing using a special chording keyboard.
|
||||
|
||||
[[gregg-notehand]]
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
id: 2026-04-10T08:28:18-04:00
|
||||
aliases: []
|
||||
title: 2026-04-10 08:28:18
|
||||
tags:
|
||||
- authorship/original
|
||||
- destiny/permanent
|
||||
- status/draft
|
||||
- type/periodic/timestamped
|
||||
- occupational
|
||||
- topic/organization
|
||||
dg-publish: true
|
||||
date-created: 2026-04-10T08:28:18-04:00
|
||||
daily: "[[2026-04-10]]"
|
||||
weekly: "[[2026-W15]]"
|
||||
monthly: "[[2026-04]]"
|
||||
quarterly: "[[2026-Q2]]"
|
||||
yearly: "[[2026]]"
|
||||
---
|
||||
# 2026-04-10 08:28:18
|
||||
|
||||
I tend to think I have more to contribute to [[conest]] than to Bid.
|
||||
I need to know more about the executive philosophy of both
|
||||
before I could decide to switch or stay.
|
||||
|
||||
> Moreover, what about estimating coordinators and "estimating solutions"?
|
||||
|
||||
I know very little now,
|
||||
but it doesn't seem many are more certain.
|
||||
I think that's a problem,
|
||||
but at the very least I'd want it explained to me.
|
||||
|
||||
Only yesterday I learned about the ConEst budget,[^1]
|
||||
and with that I feel my understanding has doubled.
|
||||
|
||||
[^1]: According to [[christian-pereiro]]
|
||||
the ConEst budget for [[the-huehub]] was ~$240,000.
|
||||
At 5,976,038 sqft per BPM
|
||||
that comes out to almost exactly $0.04 per sqft.
|
||||
|
||||
If ConEst is budgeted per square foot
|
||||
then it should follow that ConEst effort
|
||||
should be proportional to building area,
|
||||
but this is not usually the case in practice.
|
||||
Since larger jobs tend to have more typical work,
|
||||
jobs of every size tend to take about two weeks.
|
||||
In order for ConEst to estimate as budgeted,
|
||||
we would need standards for acceptable takeoff
|
||||
at multiple levels of estimating detail.
|
||||
Reference in New Issue
Block a user