The problem with structural engineering is incentives. It is one of the reasons that I left. Most structural engineering companies are filled with conservative, boring engineers that prefer to look up pre-designed segments and don't make full use of the steel design handbook or building codes.
For example, in Canada if you have a non-load bearing brick outer face (most brick buildings in Canada) you're allowed to reduce the wind load by 10%. I was the only person I knew that knew this because I actually read the steel, concrete, and wood design handbooks front to back while I made notes. Furthermore almost nobody has read the building code "just because" they might hop to a section here or there when they need it, but they're generally not going to just sit down and read the thing.
So when I would design buildings I would be able to take advantage of a lot more things than most people. This lead to my buildings being cheaper / easier to build, which of course lead to our engineering fees looking like a larger portion of the job.
The problem with reinforced concrete is the same. Engineers have no financial incentive to make alterations to their designs to make the buildings last longer. It is almost trivial to make sure steel wont rust (or to double or triple a buildings life) but it makes construction costs go up 0.01% and makes engineerings fees go up 0.1% so nobody does it. Regulators are to blame too. There are amazing concretes (Ultra High Performance Concretes) we should be using in our buildings that completely lack even needing steel because they are so ductile and strong (MPa 200 for the one I was familiar with, Ductal by Lafarge), but it's impossible to use in construction in Canada because the code is so rigid.
I dare say the same is true of software engineering. I, nominally a backend engineer, know (and apply) more about HTTP than most front-end devs and architects I've met, simply because I sat down one day and read the HTTP spec. (It's not a difficult read!)
However what I eventually found out is that the HTTP "rules" were not faithfully followed by many implementations. For example, extra care taken to make sure HTTP headers were correctly parsed just caused headaches. The trouble was that headers received from many origins were "malformed" despite specs saying what a header "MUST" contain or what characters are not allowed.
I know servers are supposed to be "tolerant" of non-compliant clients (and vice-versa), and realistically there's little choice but to go along with "loose" compliance. I've often wondered to what extent that reality contributes to less than optimum security that's so often been an issue.
The secret was really easy: RTFM.
The most important skill here is being able to diagnose a problem and fearlessly, relentlessly employ the engineering discipline of solving whatever problem/task is at hand, and not because of observed symptoms ("hey, I turned that knob and everything was OK! I don't know why, but I can close this JIRA ticket and move on with my life. I'm a 10X engineer!") but because you understand precisely what's happening. I made the mistake of the first decade of my software engineering career learning from trial/error and observations, and while those skills are useful in some cases, the best engineers are extremely disciplined about understanding the full depth of a problem before writing a line of code.
In a nutshell, I guess what I'm advocating for is do not blindly study man pages. The reason is because without a practical application for the knowledge, it seeps out of your brain and you forget it quickly. The exception (case in point, GP's example) is when what you're studying does have a practical application or is relevant to what you spend your time doing. This has always been my problem with academic curricula (sure, some people can learn well this way, and there's definitely a minimum foundation necessary that must simply be committed to memory). Even in basic subjects like maths -- the work is rote, and we maybe get a passing grade, but often without the understanding (or the depth of understanding) that is really the most important aspect of learning the subject matter.
It's not about knowing the minute details so much as understanding what's going on well enough to model it in your head.
PS: Assuming you are operating on lots of data, a small scale test can and did go the other way.
I left with a strong laziness view on optimization. Profile based on what the business needs and ignore everything else or you will never escape the rabbit hole.
But if you can ignore the pressure and stick to your guns, you end up saving time in the long run, sometimes making orders of magnitude more work possible. Most managers should appreciate that.
But it's difficult to have the nerve to do it, and it can be difficult to explain in the short term. Like most opportunities there's a cost to pay up front.
for all I know, historically there must have been a lot of masons asking the same question when stacking bricks: "people have time to do that while building a wall? to carefully put mortar between the bricks??"
but nobody remembers those masons because all their walls have fallen apart by now.
("... wait seriously, even the inner walls?? but the boss never checks those anyway")
Is this a typo? I can't imagine a day of working with computers where I spend less than 5 minutes reading a manual.
It's not a hard science, but I think the two important elements are 1. Being willing to deep dive and 2. Monitoring how much time I spend to allow for reasonable stops. I come back to unsolved issues when they come up repeatedly. That tells me those are more important.
First, remembering the fact that certain information is out there is a lot easier to remember than the actual details of that information. Bits like "zsh has this crazy advanced globbing syntax that obsoletes many uses of `find`" or "ssh can do a proxy/tunneling thing and remote-desktop things with the right options, also it sometimes doesn't need to create a login session and sometimes it does" or "ffmpeg has these crazy complex video filters that allow you to do real cool tricks (therefore maybe the same for audio filters though I haven't actually read about that yet)".
Some of this is man pages, some of this is blog posts or stackoverflow answers. I keep my bookmarks well-organized using tags (in Firefox, Chrome doesn't seem to have tagged bookmarks for some reason, last time I checked). Whenever I find something that seems it may be useful some day, I bookmark it, tag it properly and sometimes I add a few keywords to title that I am likely to search for when I need the info.
Then, given the knowledge that some information is out there, I allow myself to look it up whenever.
I've never been very good at rote memorization, at least not doing it on purpose. I often lack the motivation to muster up the will and focus required. So I don't force myself, but somehow still remember stuff any way.
There's so many tiny things in such a wide field of interests, I don't even really want to memorize all :) So I cut it down to knowing the existence of information (and sometimes, classes of information).
Then maybe some day I'm working with some particular features of ssh or git, and I notice myself looking up the same commands or switches a few times over again. So apparently I'm not memorizing these. Then, I make a note. That's not a very organized system, it can be a post-it, a markdown/textfile, an alias, a shellscript, a code comment, a github gist. I used to try and keep one textfile with "useful commands and switches and tricks and and and", but I found myself never looking at it, so I stopped doing that. Instead I try to put the note somewhere I'm likely to come across when I need it in context.
The way Sublime Text just remembers the content of new untitled textfiles and then allows you to organize these groups of files into projects, quick-switch between projects using ctrl-alt-P, is just perfect (or shall I say, "sublime"?). It allows a random short note evolve organically from temporary scratch to a more permanent reference note.
I also download some reference manuals, so I have access offline, which is often significantly faster to quickly open, check and close. For instance there's a link to the GLSL 4 spec in my start menu, which instantly opens in katarakt by just pressing "alt-F1, down, right, enter" -- a leftover from a project where I was reading that thing all the time. After a while I added a shorter webpage-converted-to-markdown reference to the sublime project file, and now I use it less.
I guess the shorter summary is: Yes I do have tips, but they are what work for myself, but the more generally applicable advice is: yes there are tips and there are tricks and they are whatever works by any means necessary, but most importantly: yes, there are tips and tricks, and some of them will work for you too! :)
ps: I was just on www.ecmascript.org/es4/spec/, historical artefact but full of surprises.
You need to know at least nominally how the sub-components interact, or you can't predict how something will perform when you use it. Even the strongest abstractions leak a little bit.
I'd just like to mention one counter argument, which the rigidity of the code in some cases will help to protect against developers from using cheaper materials, or new materials that on paper seem better, but in reality may not be better.
An example I've heard of but am having trouble searching for the exact name, is in condo buildings here in Canada they started using a new piping material, to do the water deliver inside the units. The problem was, while I think in theory the material was better, it has the property that when it fails it fails catastrophically, due to either a manufacturing or installation defect. So instead of just having a small pinhole leak, the piping will split when compromised, and you have many thousands of dollars in damages to multiple units. Buildings with this material can no longer be insured in Canada.
So I don't know that I would really trust giving developers a wide latitude in selecting materials, even if they sound great on paper.
I don't know what the solution is, because I agree we need to be more flexible, and have a way to introduce new and better technologies, but we also have to be diligent, in ensuring that the new technologies and processes work the way we expect them to, and have the desired effects.
In terms of construction materials in condos failing (glass and piping) I actually put the blame for those two failures on the individual testing companies. Engineers in Canada don't understand statistics properly because most aren't taught materials testing properly in university. But we don't live in a utopia either. It is expected that things will go wrong sometimes and that we'll have to update our building codes to address those shortcomings. My issue with Canada is that we don't have a (or at least I'm not aware of there being a) structured materials testing code.
Sure we'll regulate materials and connections for our main structural elements, but there will always be that last mile where someone will want to do something weird (like build part of the building under railway or if someone over bent some reinforcement bar and you need to authorize them rolling it back) and you're pretty much out on your own once you come to those scenarios. It's doubly unfortunate because most of the engineers that just look things up in tables are basically helpless because they don't remember or use the basics day-to-day. So they end up being extremely conservative - unnecessarily wasting money and material for all of us.
I don't understand how your third paragraph's thrust follows from your second paragraph - what does materials testing have to do with site specific (railway) or field changes (bent rebar)?
How long did you practice in Canada? Your viewpoint of engineers meshes well with the opinion that I've heard from a lot of junior level engineers who are just making the adjustment to a mid-level position but are still interacting with the lower level staff who are, as you say, typically helpless. They are supposed to be - they are still learning.
The two examples I gave were two examples that I dealt with personally. I was extremely dismayed at the rigour the firm I was at used. To test the bent rebar I think we used a sample size of 6 and then tested to failure. For the railways example they just used the weight of the train. Then when I reviewed the designs and brought up that the train could apply the breaks and thereby increase the downward force they just multiplied everything by 2.
In my experience the low level staff was useless, with a couple people that knew what they were doing. The medium level staff had two groups of people, the people that still knew advanced math and the people that got good at AutoCAD, and the senior people, while good at sales or general guidance; had basically completely forgotten all but the most basic structural engineering principles. I've literally had to explain crushing vs bending moment to a 20 year structural engineer before. I've (accidentally) designed a structure that was already designed by a senior person that forgot to put it in the tracking system. I used one sixth the steel and mine could handle more load.
I will grant you, however, that I may have just been at a substandard firm. We had some large projects, but we weren't designing new skyscrapers or mega-structures.
I'm not familiar with the specifics of your rebar example so I can't comment. Your example with the train makes no sense - the design loading for railway is codified in the design manual (AREMA in the USA) and includes dynamic forces. Braking forces are applied longitudinally to the track so unless you were in a curve there is no downward force. I find it hard to believe that your boss agreed with a fictitious force and then just multiplied everything by 2 to get around it.
Your opinion on your colleagues is concerning to me and is probably more indicative of your lack of experience than the other staff's incompetence. Your experience reads like someone suffering from 200th hour syndrome, I wouldn't be surprised that if you stuck with it another 3 years you would have realized your initial impressions were way off base. At worst, it sounds like you may have been working at a firm that did commodity work and didn't attract top tier talent. If you are as good as you seem to think you are then you should have jumped ship when you got "fed up".
I don't intend for this post to sound dismissive but it will probably come off that way.
As an aside, knowledge of advanced math is not necessary for structural engineering in my opinion, nor is it common.
Think of a motorcycle doing a "stoppie" i.e. read wheel is in the air under braking, all weight is on front wheel.
A motorcycle performing a stoppie experiences rotation because the inertial force couples with the braking force to create a moment about the front axle of the bike (this isn't technically correct language but you get the gist). While this idea holds true for the train, we have to take into account the differences in mass and contact between the two systems. Train cars typically ride on more than 2 axles and this provides stability from front or rear tipping. Train cars are also typically very heavy meaning that the braking force is not sufficient to 1) move the center of forces of the system ahead of the front axles and 2) tip the car. Increases in load because of this are, therefore, not sufficient to double the load on the front axle as you would see with a stoppie.
In general I agree with the idea that is put forth; however, it is important to note that what we are discussing is the BRAKING force. The inertial forces that result in differential axle loads is not a braking force (certainly, it is a result of braking in this case but this force also exists when a train begins pulling). These loads are DYNAMIC loads and are already considered in another part of the analysis. Dynamic loads also include consideration for bumps, etc. Because of this, the code is explicit that braking forces are applied only longitudinal to the track so that the forces are not counted twice.
"Enough experience to be confident, enough to screw up real good." is how a nice TV show put it.
For example, when my house was built I wanted something better than fiberglas insulation. After research, I settled on icynene foam. The contractor refused to use it, because he'd be to blame if it went wrong, it would be an enormously expensive retrofit. He finally agreed after I formally agreed to accept the risk and not blame him.
15 years in, and the icynene has been great. No troubles at all.
The only problem I see is a marketing issue - being able to get the message out to your customers of the advantages of going with your firm.
So there you go. Mismeasurement is 99% of all business problems. I've been laid off before because I didn't generate the (apparently) required level of software defects and missed a gate or two by a day or two doing it. I was actually told I didn't look busy enough.
And yes, it is good practice to cite the code as appropriate but it isn't necessary - any questions by the agency will be sent as comments and approval will not be granted until they are satisfied.
I wonder what's the MVP?
The AI doesn't need to be so good it can replace the doctor/engineer/lawyer. It just needs to be a helpful tool for finding relevant documents. NLP and QA is just starting to get good and available to the public, so I think this will be a big thing soon.
After a few decades, the once great regulations are often way out of date.
Suppose a oil tank farm is incorrectly built, a tank breaks, and the oil gets into the nearby river, killing fish and preventing it from being used as drinking waster for 100 miles downstream for the next week.
Who gets to sue if the insurance company decides to not pay? How much does each lawsuit cost just in lawyer time? How long does it take to get through the legal system?
If the insurance company doesn't have the funds, what happens? This can easily happen because the company has every incentive to find the least expensive insurance company, or the company might be overstretched, like Lloyd's in the 1980s and 1990s with the asbestos, pollution and health hazard suits.
Or it can be more perverse, like an insurance company set up as a front, working with unsafe companies, and where a significant problem or payout simply triggers bankruptcy, and no remuneration.
If different companies have different rules, how easy will it be to switch insurance companies? Because that sounds like a great way to get lock-in. Can I bring my own building inspector in or do I need to depend on the insurance company inspector? Will the codes be public information?
Insurance companies are usually themselves insured. If they go bankrupt, e.g. a natural disaster or something unexpected happens, another insurance company has to cover it. This is possible because they insure multiple industries and geographic regions, so can take a few hits.
The details will need to be worked out, but I don't see why it would be anywhere near as complicated as working out the details of building codes. Regulations are complicated, we already accept that. This is just a way to significantly simplify it.
One of the results was a stricter and statewide building code instead of piecemeal codes. Successive hurricanes helped give evidence for the usefulness of the new code.
Another was state trust fund to ensure sufficient insurance capacity.
As a side note, I really wish more of these sorts of alternate regulations existed. They would be very useful fallbacks for when regulations become outdated or overly restrictive. Another concrete example of this is automobiles. Right now in the US, you can't bring a consumer car to market without extensive crash testing from the NHTSA and fuel economy tests from the EPA. These high fixed costs eliminate enthusiast and niche manufacturers. If the law said, "Any model that doesn't pass these tests incurs a $10k (or 25% or whatever is onerous enough) tax on each vehicle.", it would allow for new manufacturers to enter the market with far less capital.
Historical note: Has this ever happened anywhere?
You can build better there's no reason you can't (cost obviously) but most people just aim to barely pass minimum building code.
I propose you could start a consulting gig and maybe your own firm. Can't be that there aren't people who want their buildings to be cheaper for the same quality.
I take special issue with the article's use of pseudoscientic false analogies.
> This means that concrete structures, for all their stone-like superficial qualities, are actually made of the skeletons of sea creatures ground up with rock. It takes millions upon millions of years for these sea creatures to live, die and form into limestone. This timescale contrasts starkly with the life spans of contemporary buildings.
This is utter drivel.
There is a valid point in that for smaller scale constructions other techniques may be applicable which are otherwise ignored; also that there are alternatives to steel as the reinforcing material, both for prestressed structures and not.
Reinforced concrete is costly to demolish, and nearly impossible to recycle. Crushed concrete can be used as a filler, but in order to be used for fresh concrete it must be free of contaminates, which is rarely the case, and no one wants to risk the integrity of a new structure of any importance.
The percentage of all concrete structures even built, that are still standing must be quite large. This will not be a great legacy to leave future generations.
When I traveled to Philippines earlier this year I was struck by how they use masonry in situations that in USA would be reinforced concrete. Granted, the blocks are all CMUs, but the technique is masonry. I think it's because very few roads (at least in the places I traveled) would be suitable for standard 6-yard concrete trucks, whereas you can always throw a few dozen blocks on the back of a motorcycle. Of course labor costs are also a factor. However, concrete in block form is totally recyclable, while as TFA notes when poured it is not.
There was an article on HN some time ago on how we are running out of the type of sand necessary for concrete. There is apparently a big black market for sand stolen from rivers and beaches, leading to violence and environmental problems.
I was surprised the article didn't mention this.
It's utter drivel to point out that nonrenewable resources are being squandered at a shocking rate on structures that can't even last a century?
The problem with fiberglass reinforcement is that it does not undergo ductile failure like steel does. Steel will yield and, in addition, has strain hardening behavior. Fiberglass just fractures and that's that. Extra precautions must be taken when using fiberglass in failure critical members.
Using straw for anything that is loaded in flexure will be a disaster. Reinforced concrete theory relies on the reinforcing to act as a crack stopping mechanism which will yield in a ductile manner. Straw's variable strength and inability to place it at critical sections means that it cannot perform the function of reinforcement as it will be possible to encounter localized weak reinforcement which will not prevent cracking and loss of section leading to progressive and sudden failure.
From my own experience, I saw that wood rots quickly for about 1cm (1/2") when it contacts with concrete or cement stucco, but remains intact when enclosed in cement-lime mix. IMHO, lime is important to save wood/straw from rotting.
I'm just so happy that people had different perspective back then.
It's sad that we don't understand - unsustainable growth, scaffolding and prototyping phase is long overdue.
However, if you go to Rome, most of the surviving bits are millions upon millions of stacked and mortared bricks, and most of what has survived are uninteresting walls.  For some reason, our collective memory of Roman ruins is that they're all aged concrete or stone. But when in Rome, you end up seeing lots of this , which when built probably had a layer of facade material on it.
And it makes sense, stacked, weather resistant, often covered in a prettier facade, baked bricks should last more or less forever until the elements wear them down.
The widespread reintroduction of concrete as a building material really didn't happen until around the turn of the 20th century. And reinforced concrete didn't find widespread use until a few decades after that. Not particularly confusing, the first generations of buildings built with these fairly new and only partially understood materials are the buildings that the author is mostly writing about.
The real culmination of exposed, reinforced-concrete-everywhere, finally happened in the 50s with the advent of the eye cancer called brutalism. Today a tremendous number of brutalist buildings today are absolutely falling apart, and I blame that on a lack of understanding of how reinforced concrete should be used and the availability of more modern materials and perhaps an overenthusiasm and misuse of materials where they shouldn't have been.
But still, if we fast forward a thousand years, there's bound to be a percentage of those structures still around and survivorship bias in the future will lead some to speculate that the engineers of the 20th century were geniuses unrivaled by any in the future.
1 - http://previews.123rf.com/images/13th/13th0902/13th090200009...
2 - http://farm6.staticflickr.com/5185/5762585618_10a11f5a38_z.j...
Here's a walk around the structure , it's virtually all brick.
The rest of the article seems to be, if you think on different time-scales and use different cost-benefit criteria (e.g. include or exclude environmental effects), you get different answers about the suitability of various materials. This is indisputably true.
(IANAPE, but I took a grad level concrete course in school)
addition/edit: Quick primer. When concrete cures, it's a chemical process that converts free water into an electrostatic gel in the cement crystals. That interlocks the small and large aggregate to make a solid. If concrete dries rather than cures, then that gel doesn't form and you don't get the gel holding it together. If you heat up cured concrete enough, you'll drive out the water and make it a powder again.
If you cure something under water, it can technically continue to cure for a very long time. Normally you keep it moist for 24-48 hours, and standard testing is done at 28 days. That will get you something like 90% of the final strength, if it can continue to cure indefinitely. I've tested concrete that was semi-submerged for 40 years where the design strength was 4ksi, and it tested out at 14ksi.
I also see several commenters (myself included) wholeheartedly agreeing with the point it makes.
I think bluthru hit the nail on the head somewhere below (which will soon be above?)
> The point is that longer-lasting structures should be cheaper, but because we don't factor in environmental harm and lifecycle cost into the price of things we end up with cheap buildings that exist to generate ROI ASAP.
Factoring in those kinds of costs runs contrary to mainstream economic doctrine, so the question really is whether you think that capitalism (in its current form) is doing more harm than good for our communities and/or for our species as a whole, especially including future generations.
The website also says:
> Basalt rebar does not conduct electricity
Which got me thinking about electrical codes. In some cases, a concrete building's electrical wiring system uses the rebar in the concrete structure as an electrical ground.
But, I guess for buildings constructed with basalt rebar, conductive copper rods would have to be specifically built in separately, for purposes of electrical grounding.
They claim it's better and cheaper than steel rebar. No word about disadvantages, which I assume exist (edit: found, see below).
Edit. Oh, they carry a price: http://nano-sk.ru/price-list/ -- 1m of d=14mm rebar costs ~$0.60. But I don't know the price for the regular steel rebar, though :)
Edit2. There's a list of disadvantages here (sorry, in Russian): http://www.tdbazalt.com/category/materiali_dlia_stroitelstva...
1. Can't stand high temperature, as basalt rebar has polymer as a binder for basalt fiber.
2. Can bend easier than steel; will break easier than steel
3. Can't stand alkaline environment (there're claims that some newer types of the basalt rebar don't carry this issue)
If you could figure out a systematic way to cut the cost and the lifetime of such lowbrow, mass-produced concrete structures in half, developers wouldn't hesitate, they'd jump on it immediately.
We revere longevity only in retrospect.
For laypersons http://www.dailymail.co.uk/sciencetech/article-2877547/Why-C...
In europe we have EuroCodes that account for this problems and to my knowledge concrete cancer is not related with steel corrosion but with a long term chemical reaction between some aggregates and cement. Remember that concrete is cement with sand and stones and the hardning chemical reactions are complex and can last for decades.
It's called carbonatation, it reduces the concrete's pH which leads to rebar failure, and it's only going to get worse with climate change.
Buildings made out of earth are also better heat insulators compared to concrete. My grandma's house was always cool in the summer, while my appartment which is part of a building made out of concrete wouldn't be livable in the summer without AC.
To solve these problems with mud/clay walls, wood and straw are used. To date, G.R.E.B. technology is most advanced, cheap, and easy to use.
Ongoing maintenance is an important energy and money sink for any society. I find it doubtful that concrete (at least, the modern versions and usage of it) will be sustainable beyond the fossil fuel era, simply because it will be too expensive to maintain.
EROEI for a given bit of infrastructure (ie how much energy is conserved or produced for a given energy expenditure in construction/maintenance) isn't as sexy, but it's just as much a thermodynamic constraint on sustainability as overusing the CO2 capacity of the oceans and atmosphere.
But how can this be done when the steel is enclosed within the concrete? What can be done once it started to rust?
0) Build using appropriate materials/design/construction. It's mostly a solved problem, it just takes wanting to spend enough money to do the process right.
1) Use epoxy coated rebar. It's commonly used in places where there's a large risk of cracking and rebar corrosion (e.g. roadways)
2) Use prestressing/posttensioning to put an overall compressive force on the concrete to prevent cracking.
The author suggests we build structures to stand the test of time and addresses structural, economic, and environmental needs, but not societal ones. The Moai referenced are not artifacts because they weren't engineered well enough, they're artifacts because they outlived the societies that built them.
They'll definitely start crumbling in a few decades and not many people will be able to afford a new home as well as deprecation of their main asset. Have no idea how this might ever resolve, frankly.
Rammed earth has great thermal mass which has huge benifits if controlled.
Elsewhere in the US, brick would probably be a good choice, but it's more expensive than slapping together another bargain-basement wood-frame house. On the other hand, for some reason, Europe has a lot of brick buildings and even still puts in brick streets sometimes.
Also the postwar construction boom dominated by big projects killed the industry for higher end brick.
Even with the hassle, structural brick buildings are great.