Who would ha- wait haven’t I said tha- OK- I’ve even made that joke before!

I‘ve been Being Brunel for four years. The is the 209th time that I’ve shouted out into the void; filling the internet with whatever occurs to me as the last minute deadline approaches.

It’s been enough years now that Being Brunel has a birthday tradition. Actually, it has four. The first is opening with the same terrible joke, the second is a look back at my seven highlights of the year (I know that’s oddly specific), the third is to thank you all (spoiler alert), and the fourth- well, you’ll have to wait to the end of the post for that.

So, let’s take a look back at Bring Brunel (A New Hope):

• 6th of August 2015 – Being Brunel publishes its first interview with the wonderful people at BaseStone. It’s a two parter- the second half of which is still pending!
• 20th of August 2015 – I write my first book review since school; learning a lot about the art of designing structures through approximation in the process.
• 10th  of May 2016 – After an unintentionally long eight and a half month break I nonchalantly return to the keyboard to bring you Being Brunel again.
• 19th of May 2016 – Being Brunel comes to you live for the very first time from the Construct//Disrupt PropTech event; giving you all a chance to see just how much I rely on the spell checker!
• 24th of June 2016 – England votes to make the UK Leave the EU. Despite being on a course, I pen my most read article this year; thanking Europe for all the things it contributed to our built environment.
• 29th of June 2016 – The epic season of daily posts to make up for lost time and bring Being Brunel back up to the promised 52 posts a year comes to an end and I finally get my life back (nearly.)
• 10th of July 2016 – I win a prize at the AEC Hackathon with the Brunel Test; an idea I blogged about live on a bus on the way to the event. It’ll be coming to fruition soon- so what this space!

It’s been fun, and it’s even better to be back (even if I never really intended to leave). I wouldn’t want to even guess what the fifth year will bring (except 52 posts, they’ll always be 52 damn posts). When I was younger I wanted to be a video game composer, then I did a degree and became a civil engineer- these days I’m something between a proper engineer and a software developer, sharing it all with you through the lens of the built environment. Who knows what’ll be next- not me, that’s for sure.

All that remains is to thank you all for coming back week after week, (or eight-and-a-half-months-followed-by-daily-then-weekly.) Despite hating extended writing, I keep on Being Brunel because it’s fun. Thus far it hasn’t won me a job, international fame or even one of those hats Isambard used to wear. So if it wasn’t for all of you glancing at my ramblings, well, it’d all be for naught.

As is the fourth and final tradition, I’ll leave you with a fourth version of this once absurdly prematurely apt song. These days, however, I’m only another 52 posts away…

Click here for your free song.

The post Being Brunel for Four Years appeared first on Being Brunel.

Engineers are so damn practical; give them a problem and they’ll just get on a solve it. The ultimate pragmatists; it’s not too hard to see why it often takes an external force to change the industry. Forever, (it seems), we’ve made do–  “Yeah, the processes/tools/practices being used aren’t the best- but we’re surviving and we’ll get round to sorting them one day”. Our companies are focused on engineering.

So why am I talking about this now? Well, the people behind one of the tools I use for the site- Buffer- have shared their 10 cultural values, and how they’ve integrated them into the company. I found two things fascinating about these- firstly the values themselves, which are pretty far removed from those I’ve seen at most company inductions. Secondly, and more interesting, is how much they’ve been thought about and thoroughly woven them into the way the company functions.

Take a look, and consider- does your company do this, and would it be a better place if they took a moment to reflect on the culture:

Choose Positivity

I nearly reordered this list so that I didn’t start with the one value I thought most likely to make your average engineer’s eye’s role. However, considering you spend most of you time at work, it makes sense that it should be a positive experience for you; not a room full of bitter complaints. There’s more to it than that though, positive environments are those where you’re more likely to feel safe to make a contribution- not shot down, and that makes it more likely that your employees will engage and start to improve the business themselves.

Default to Transparency

Did you know that an unexpected loss makes a much bigger impact than an unexpected gain? Providing people with a full view of what’s going on turns the unexpected into the anticipated. Transparency breeds trust, but it also opens up a process to comment and improvement. Buffer take this surprisingly far, up to and including publishing their salaries and telling their customers where their money is being spent. Exposing everything to your employees seems a risky business; but when I think back to all the times something’s been thrust upon me and I’ve thought “if only I’d been involved at the start”…

Focus on Self-Improvement

Engineering firms are kinda good at this. We have the whole culture of CPD where we focus on our professional development. Where I think company cultures fall down a little, however, is that focus on professional development. I’ve got a whole post about esoteric learning in the works, however the headline is simple: if you want your employees to innovate then you have to allow them to grow personally; giving them the opportunity to draw from outside experience will uncover new opportunities.

Be a No-Ego Doer

Or ‘be objective’; their suggested route is the ‘five whys‘ approach. The trick is to separate people from problems and solutions, thus removing a lot of the friction that can happen when adapting ideas. More importantly, though, it makes it easier to solve problems. This is something the industry as a whole is trying to deal with by establishing collaborative contracts. The fact is that when you’ve got a problem, the focus should be on solving it, not working out who was responsible.

Listen First, Then Listen More

You need to dig a little deeper with this one to realise why it’s important. In the original post the phrases “seek first to understand and then to be understood” and “everything is a hypothesis, and you could be wrong”. I’ve talked a bit about the way engineers talk to one another. However if you focus on creating a culture where people listen and think about how they engage with one and other, then you’re likely to enable the more meaningful interactions that will push your business further. Buffer posted a tone guide, which I thought made an interesting read- especially when I compare it to my time at McDonalds!

Communicate with Clarity

I’m willing to admit I’m not the most concise or clear communicator (and irony that isn’t lost on me). However engineering is all about experience and knowledge, and so engineers are pretty much automatically experts, even when they’re talking to each other (although especially when talking to a client). That means that communication is very important and making sure people are understanding the implications of your conclusions is essential for easy collaboration.

Make Time to Reflect

Those who do not learn from their projects are doomed to repeat them; or something like that. Retrospectives are so amazingly important that I’m surprised that doing them (and doing them right) isn’t built in to the way we work. At best I’ve seen retrospectives exist as a short explanatory seminar with maybe a few ‘discovery’ points; however I’ve never even heard of companies doing regular, disciplined and recorded reflection on their projects.

Live Smarter, Not Harder

This is literally the opposite of most engineering cultures I’ve come across, where people treat their evenings as a time to work without getting interrupted by e-mails. There are, however, tonnes of studies out there explaining why just throwing more of you time at a problem is pretty much the worse way to solve it. Productivity is not a function of time, it’s a function of your state, and taking some time to discover the conditions that make you work most effectively and then being empowered to affect them will help you beat all those weekend workers hands down.

Show Gratitude

‘Showing gratitude’ is a much more active way of saying what I think is the more important message: ensure people are appreciated. Engineering is a job people do because they’re motivated by their contributions, rather than money (else we’d all be investment bankers by now). This means that a culture of appreciation is important; not just being grateful for people that are taking the time to help you, but also those that are taking the time to argue, correct and challenge you.

Do The Right Thing

Out of them all, I think this is a cultural aspect that most engineering firms already value. There’s a lot of responsibility in designing the world around us and it’s something that we’re taking more and more seriously (especially with the advent of CDM, etc. where we’re forcing ourselves to look into the whole life of the structure.) However, we can always be better!

Just something to think about…

The post Engineering Culture appeared first on Being Brunel.

About the Author

Lawrence Smeaton

• Lawrence is a Graduate Engineer based in Glasgow working for Mouchel in the Bridge team. He is part of STEM, a Scout Leader and football fan. He spends his days daydreaming about being the next Telford.
• Find out more: Twitter

As the joke goes at Universities, the Civil Engineering building is always the ugliest. For the University of Glasgow, this is the Rankine Building. A monstrous slab of brutalist concrete towering out of the ground like a mountain.

At this end of the campus, it sticks out like a sore thumb having the Glasgow University Union and Main Building (aka Hogwarts) to compete with in the same field of view.

This is a tacky monolith of grey concrete and screed finishes. Unlike some brutalist buildings, this doesn’t even have the grandeur you would expect such as from the Boston Town Hall (love it or hate it) or even other buildings on Campus. The Boyd Orr is a classic 60s monstrosity and it towers over the majority of the university; The Rankine is almost modest in comparison.

I returned to the Uni for a STEM meeting (get involved!) and found myself with a little free time when it finished earlier than I expected. So I took advantage of my afternoon away from the office to take a few photos of the place. What I found was an appreciation for the building I spent four years in thanks to a year being out in the working world designing nothing but concrete.

Elevation on short face

The first thing you’ll notice once you get out of the head-box where you think everything is a cube is the cantilevers. Every single level cantilevers out from a series of columns located deeper inside the face of the building along the two long edges of the cuboid plan. Also there is a car park on the entrance level (the fourth level) and another 3 levels below this one. This, immediately, is interesting. The levels all cantilever, and halfway up the building is a car park which is situated solely on one cantilevered side of the building. The vast self-weight of the concrete braces the structure. If you look back at the cover photo you will see the dozens of floor beams just peaking out of the wall panels to emphasise the cantilevers.

Detail at entrance level

This is monolithic concrete in its prime and, even if you don’t like the architectural look, is pretty well refined. In fact, I’d go one further to say that this building looks stunning and is simply lacking the correct cladding. The windows are boring, there’s a whole heap of exposed services and does anyone even like these precast aggregate panels? It looks like a gigantisized version of those toddler crafts projects where you cover a bit of card in PVA glue and throw sand at it until it sticks.

Looking down on the 3rd level (and roof of the second)

Other improvements needed include all this junk. Not the best look, I’m sure they could have thought a little more about ventilating the basement levels – which are convenient for avoiding direct sunlight (and people) near the end of the semester.

And this electrical service is badly placed, I originally thought it was some sort of steel bracing in my more naive years at the Uni which means that members of the public will probably think the same thing too. To go through all that effort to create a surprisingly free and open space in the middle of a building to ruin it with that is just frustrating. It needs a facelift, without a doubt, which is such a shame for something that I’m sure the Structural Engineer involved was pretty proud of.

[row padding_top=”” padding_bottom=”” bg=”” bg_light=”true” appear=”false”] [column size=”1-2″ appear=”false”][/column] [column size=”1-2″ appear=”false”][/column] [/row]

Compare and contrast with the new Stevenson Building built next door. It looks pretty but you see nothing. You see nothing of the structure and how the building actually functions which is always a frustration for Engineers who by our very nature like to pull things apart and put them back together! By looking alone, it looks like masonry work (although I’m sure most of us will know this is incredibly unlikely). It’s a much more attractive building but, I would argue is uninteresting. It’s a relatively simple steel frame hidden beneath some very nice windows and a tasteful modern façade.

Now I’ll leave the engineers to argue if they prefer the steel or the concrete design side of things (I’m obviously biased having spent the last few months detailing reinforcement), but imagine they gave the Rankine a modern facelift?

The post In The Defence of Brutalism appeared first on Being Brunel.

For those of you who missed it, there’s something fun happening in London this weekend- and I’m going to be there. Yes, it’s the AEC Hackathon! To make life a bit more exciting (and to allow me to get all the dull things I’d usually do on a weekend out the way), I’ve decided to make a repeat of my last Construct//Disrupt attempt and blog live from the event.

So once again, let me invite you to check-out Being Brunel Live!

Being Brunel: Live

As the event is a two and half days long, expect updates to be a touch more periodic than the steady stream I achieved last time. As always, feel free to drop me a line (perhaps on Twitter) with any questions, comments or suggestions and I’ll try and answer, respond or action them!

The post AEC Hackathon 3.3 appeared first on Being Brunel.

Metrics; measurements with purpose. It’s a term I’d long left associated with those business managers that trade buzzwords with each other; inheriting, instead, the engineer’s standard unit- a deliverable. And deliverables are important; key performance indicators of beams designed per-hour or daily count of piles driven (OK, I’m being a bit facetious) are nothing compared to handing over a complete and functioning bit of infrastructure.

Last week I went to a talk from an enthusiastic young man from everyone’s favourite online takeaway service. The topic- Metric Driven Development. It’s fair to say that software developers have a real fascination with building and analyzing their processes; and in my short working life I’ve already seen the rise (and somewhat fall) of Test and Behaviour (Driven Development) approaches. But that’s what makes it so interesting…

So what is this metric driven development? Would it surprise you to learn that you’re already part of it? You click on the order button- was it always on the right? that took a moment or two to find- and stall for a bit at the checkout; unsure on whether you really need everything in your basket. But there’s that timer going; seems this deal is only for a short while. Best click through. Ahh, this site never remembers you payment details. The saving isn’t that great in any case- let it go. Have you seen that video with the hedgehog in the bath?

Every single step of that process has been measured (assuming this online store is using metrics). And someone is defining insights; goals. They know that 20% of people, like you, have dropped out at the last hurdle. And so they launch a few campaigns to inform a decision- 10% of visitors are now being offered PayPal as a checkout, and another 10% are being offered to save their card details. The monitoring continues- it turns out just offering to save the details only increases conversion by 5% (perhaps people resent all data entry?), but that PayPal link improves things by 10%. Slowly but surely all visitors are being invited to use PayPal…

There’s a lot of talk about in this example. Firstly let’s establish that their ultimate goal is to convert you from a browser into a sale. The metrics they collect are used to inform their design. They’ve targeted aspects that they think can inform decisions; not only watching your journey but also the speed at which you make it. In a previous incarnation people once gave up after spending too long considering their choice at the checkout- thanks to the timer, they no longer do this.

Although people slow down a bit finding the right buttons, the point where they lose the sale is when they ask for payment. So, following a development driven by metrics, it makes sense to target this aspect first. However it’s hard to know exactly how to solve this problem, so they prove their solution by doing something called A/B testing. They try both of the solutions they’ve considered, and see which one performs the best. Building an architecture to store payment data, is expensive so you want to be sure before you invest.

The last manifestation of the metric driven approach is more subtle. Despite PayPal being a clear way to improve conversions- they didn’t just roll it out in one day. Using an approach called feature toggling, they slowly switched it on for users. This allows them to use performance metrics to ensure they don’t bump into any problems; constantly verifying the health and load to inform decisions on how to scale it up from 10 to 100% of their customers.

I hope that the advantages of metric driven development are fairly clear. You get a very clear goal to inform every decision you make; I want to increase the measure of X, will Y do that? It follows a very scientific principle; hypothesise, experiment, evaluate, respond. Failures can be spotted faster, as can changes; by integrating instrumentation it’s easy to spot trends, and verify that what you put in to achieve something continues to do so.

One thing is for certain, civil engineering isn’t software engineering- however I don’t think that means that ideas are mutually exclusive. In my last post I talked about cost and consequences, and hinted at a need for instrumentation (that’s just the technical term for measurement equipment) as part of our infrastructure [Ed. There was even a comment about it.]. These days instrumentation is cheap, as is data processing.

There’s a few spaces where a metric driven approach might help construction. Starting at the most mundane, simply measuring how long it takes to achieve something and setting it as a metric to reduce can be surprisingly powerful. Sure- everyone in construction wants a fast turn around, but unless you make a formal statement of this you’ll just be using anecdotal balances and it’ll be hard to justify and discover exactly what you did that made it so fast/slow.

However, management theory aside, I think there’s some more exciting applications. Consider our infrastructure as one giant system. The goal is to get people from A to B as fast as possible. How do we evolve that system? Every new junction provides an opportunity for massive scale A/B testing– each with it’s own unique feature that either lives or dies based on the relative improvement. Measuring traffic flow is easy; it’s coordinating the results that will be the hard part.

Or one step further. A structure built of metrics. A bridge wired with sensors. Using the responses from the sensors to evolve the design– sending across the first car, measuring the response and strengthening accordingly. Slowly rolling out to more and more traffic and making the adjustments as discovered- entertaining new prospects through the A/B pattern; toggling structural aspects to manage their effect. Sure, a more modular construction approach would be needed, but I wouldn’t be surprised if you ended up with a more efficient structure that was easier to build (as it had to be built as we went along). And, of course, you’d learn a lot.

It’s clear from my most extreme example that the approach is more of a science than a traditional engineering one. Alone it’s much more of a fool doing for a pound than a precision penny; lots of guesswork and learning through feedback. However the role of the engineer in this scenario is to interpret the metrics and suggest appropriate responses. Something, you might argue, that your average civil engineer already does!

Of course, in our current system this is a bit of a pipe dream, however as a thought experiment it’s an interesting one.

The post Metric Driven Design appeared first on Being Brunel.

Those of you who are relatively new to Being Brunel would be forgiven for not knowing that this is a blog this is updates weekly. You might not even be overly clear what it’s about- sure, it says “notes from a civil engineer” somewhere in the tag line; but there’s posts here about building web applications and specifications for the Death Star. So what’s the deal?

I had one rule when I set out to write Being Brunel. That I would write a post every week. However, I knew myself, my work load, and my commitments, and so what I actually signed up to was 52 posts a year. This last month-and-a-half dash has been making up for lost time. However, I have a life and a job and other projects, and so now I’ve caught up we’ll be returning to the traditional weekly Thursday schedule. It’ll also give me a chance to go back and update the 180 articles for the new site layout!

To quote my very first post– “this will be a blog about bridges, and tunnels, and roads, and stuff.” Like me, however, Being Brunel is evolving. When I started writing I was a pure civil engineer- working on the rails; over the last four years I have experienced the heady world of structural engineering tall buildings, taken a deep dive on analysis and am now working in another engineering discipline entirely thanks to my software development skills.

Being Brunel is my love affair with the built environment. It’s always going to be about bridges, and tunnels, and roads, and stuff; about civil engineering and the world we build around us. My fairly random career trajectory means that the lessons I’m learning and the experiences I’m being exposed to aren’t always about our infrastructure. However my aim is to extract those lessons that I’m learning and help provide insights as to how the can be applied back to the civil engineering that I know and love.

So now everything is back on track, I’ll see you next Thursday (or tomorrow, as we call it).

The post The End Of A Season appeared first on Being Brunel.

About once a month my train to work is delayed. There are signal failures, over running works, unexpected weather; the litany of excuses is endless. Only last week I sat in Waterloo and watched hours of trains get canceled because of ‘a lot of rain and some lightning‘. Every time something like this happens my unplanned ‘time to reflect’ on a busy station platform is punctuated with a prerecorded voice that somehow tries to make the current predicament sound like an unpredictable act of God that just couldn’t have been avoided.

As an engineer, I know that’s not true.

Infrastructure is a game of cost and consequences; the built environment- a giant gamble. When my train is canceled due to flooding on the track; it is more correctly canceled because there was more rain than we felt it was worth paying to defend against. The signals fail because of conditions considered too unlikely to be worth the cost of coping. The network grinds to a halt because the rewards of running at a high capacity most of the time are thought to outweigh the penalty of being able to recover quickly when something happens.

Civil engineering is a compromise. We are the insurers against nature. At some point, someone decided that fortifying our rail network against anything above a 1:x storm would be an unjustifiable expense. Engineers took that brief and designed a drainage system that would fail after an acceptable threshold had been met. It would not have been impossible for my journey last week to have been completely unaffected by the storm the night before; just more expensive.

And it’s not just the nature of events that we have taken a punt at. Our structures our built from materials and to loads laced with uncertainty. We expect our steel to be ~5% weaker than it is; our loads to be ~50% more than we specified; the resulting product to be ~25-50mm eccentric from our drawings. Sure, some concrete will be even less than the ~75% of specified strength we’ve accounted for; but we’re satisfied that it’s a risk worth taking- the point where further mitigation is no longer worth it.

What fascinates me the most, however, is that we do very little to verify our forays with chance. Have you ever checked back to see if your 1:50 year drainage scheme survived the last storm? Can you tell me just how underutilised one of your structures was during its life? Is your road already filled with traffic despite it only being 10 years old? And if you had that knowledge; what would you do with it?

Engineers deal in cost and consequence; but in the built environment we rarely investigate either. In many cases the scope and mitigation for risk is mandated to us- through codes; through specifications. A lot of the time this is useful, it saves us a lot of justification. But it also robs us of the chance to learn and adapt. It discourages us from looking further- building risk and reward profiles for our clients: Yes, said track meets the 1:50 year storm requirement- but it wouldn’t be much harder to meet the 1:100 year storm; What’s that worth to you?

Because it might just be worth two hours of my time, every couple of months…

The post Cost and Consequence appeared first on Being Brunel.

It’s about time we did some more Python. Who’s excited? In the last couple of posts I’ve helped you literally get started by setting up a Python environment and then set you down the road of variables and in/output. And we could stop there; it’s enough functionality to write pretty much anything- but it’ll be a long and painful process that none of us will enjoy. So instead let’s continue tooling up.

Touching on Modules

For today’s lesson we’re going to be coping with the effective length of our column, defined as such:

Before we do anything exciting, we’re going to write out these equations in Python. This presents us with a bit of a challenge, because while Python will merrily evaluate brackets and the four standard operators (+-/*), it doesn’t inherently know how to square root.

While we could roll our own square root algorithm using primitive mathematics, I personally feel life is too short. So instead we’re going to call upon the math module. I’m not going to dwell too much on how modules work, at the moment, but instead just introduce you to the concept. A module is a chunk of reusable functionality. In the case of the math module, this functionality is (unsurprisingly) mainly mathematical.

To use a module in Python you need to import it. This tells Python that you want it to go a fetch all the functionality of a named module and bring it in to your program. To let us perform square roots we’re going to be using the sqrt function from the math module. To make code easier to read, Python programmers tend to respect the convention of putting all import statements at the start of a file- so at the top of our rccol.py we want to add import math.

Now we have a square root up our sleeve we can finally put in our braced and unbraced lengths calculations:

import math

l_clear = 7000
k_top = 0.1
k_bot = 0.1

braced = 0.5*l_clear * math.sqrt((1 + k_top/(0.45+k_top)) * (1 + k_bot/(0.45+k_top)))
unbraced = l_clear * max(math.sqrt(1 + 10*k_top*k_bot/(k_top+k_bot)), (1 + k_top/(1+k_top)) * (1 + k_bot/(1+k_bot)))

There’s a few things here. Firstly, note that when using the sqrt function from the math module, we use it’s full name (math.sqrt). The . notation is a way of saying “from” or “that belongs to” in Python. So math.sqrt means, the function sqrt from the math module we imported. The second is my cheeky use of the max() function- this works exactly as it does in Excel, it picks the maximum of two numbers. Note that max() is a built-in function- that is; it’s something you don’t have to import from a module.

Being Conditional

Our column is either going to be braced or unbraced. It’s not going to be both. Therefore we don’t really need to calculate the effective length for both conditions. And thus, it’s time to break out the control flow. These are the statements we use to control the flow of the program– getting it to loop and repeat things a certain amount of time, jump out and run through code defined elsewhere in a function, or branch depending on specific conditions.

In this situation, we need an if statement; if the column is braced then return one value, if it is unbraced then return another. In Python an if statement looks like this:

if customer_name == "James Bond":
    martini = "shaken, not stirred."
else:
    martini = "on fire."

In the above example, our Python Publican has specific instructions: if the customer is called James Bond, then serve a Martini to the classic standard. Or else, if it isn’t James Bond, just set fire to the Martini.

This example also introduces you to some of the finer points of Python. Firstly, did you notice that when I compared customer_name to "James Bond" I used ==? This is because the meaning of a single equals (=) is already taken; it means assign a value to a variable. That means that we have to use something else of equality, and in Python (and the majority of programming languages, in fact) that is ==.

Secondly, did you spot the indentation? What is done for each condition is indented one level. Normally this is just good programming practice, because it makes it easier for you to see what bits of code are dependent on another. However Python is sensitive to white space- for example, it doesn’t know you’ve finished your else until you stop intending your lines. Now is also a good time to point out a Python quirk- indent with either spaces or tabs; doing both in one file will cause errors (spaces are the reigning champion).

OK- so now we have the fantastic if statement, it’s time to use it:

import math

l_clear = float(input("Clear height: "))
k_top = float(input("k (top): "))
k_bot = float(input("k (base): "))
braced = input("Braced? (yes/no): ")

if braced == "yes":
    l_eff = 0.5*l_clear * math.sqrt((1 + k_top/(0.45+k_top)) * (1 + k_bot/(0.45+k_top)))
else:
    l_eff = l_clear * max(math.sqrt(1 + 10*k_top*k_bot/(k_top+k_bot)), (1 + k_top/(1+k_top)) * (1 + k_bot/(1+k_bot)))

print("Effective Length = ")
print(l_eff)

Now when you run the program you get asked to input a few key properties of the column, and asked if it’s braced or not. You then get the effective length appropriate to the support condition of your column. And perhaps more subtly, it means that our program can just use the variable l_eff (effective length), without having to constantly keep testing braced to see if it should be using the effective length of a un/braced column.

Knowing how to load in and use modules is going to open up a lot of pre-written functionality to us, and save us quite a bit of time. In later posts it’s also going to allow us to start spreading our program out across multiple files by writing our own modules. Similarly, writing anything that isn’t completely trivial without being able to set variables to different values depending on specific conditions is pretty awful. However there’s still a good few tools left to add to our inventory before we can really tackle this column designer, so stay tuned…

I’m going to talk about GitHub a bit later on, but if you want to have a look at the “finished” code from this tutorial, checkout:

https://github.com/thomasmichaelwallace/rccol

The post Python for Engineers: Part 3 appeared first on Being Brunel.

Turns out I’ve pumped out 200 [Ed. actually this is the 201st post- I was a bit distracted] ill informed opinions into the internet. At 141’176 words Being Brunel had surpassed 20’000 Leagues Under The Sea in length (if not artistic worth). However the cliche “quality over quantity” still hangs over our heads. Thus the question isn’t how prolific my writing has been, but how much it’s been read. So, once again, allow me to share some insight into the 10 posts on Being Brunel that have enjoyed the largest average views a day…

Predict’ive Text In Word

Born from my, somewhat ironic, hatred of extended writing. I put preDict (my predictive text program for word) together before I’d really started programming professionally. I used it for a good few years, where it taught me that I use certain phrases with depressing frequency. It’s nice to see that I still get a good chunk of visitors every day looking for this solution- maybe I should give it some love one day…

Game of Thrones: Engineering The Wall

Having captured the imagination of Reddit; it’s hard to imagine that I’ll ever write a post that will see such traffic again. The internet is a remarkable place, and I was pretty impressed with the level of scrutiny my thrown-together hypothesis was subjected to. It was this that led me to start thinking about how engineers communicate, and led to the post on the words engineers use to annoy each other.

Is Civil Engineering Boring?

I still can’t decide it it’s a good or a bad thing that this post remains popular long after it was written. It’s a shame that so many people are turning to Google to find out if Civil Engineering is boring. However, I’m heartened that they’re finding their answer (spoiler alert, it’s no) from a blog that sets out to celebrate the built environment and those that engineer it.

Engineering The Tallest Snowman

Do you know what I learned from this article about snowmen? That people are surprisingly opined about the number of balls that make up a snowman. I’ve yet to go back and see what happens if I insist my tallest snowman be made of three balls instead of two; although from researching the article I can say that it won’t be clear cut…

Designing With Your Thumb

One thing I learned fairly quickly into my foray with engineering is that knowing the answer before you start is exceptionally useful. And it’s something that you don’t get taught at university. Yes- experience helps, but there are a good few shortcuts out there to help you approximate a target before you sit down and do some heavy calculations. In fact, a few years after writing this article, I was sent a book to review on just that.

5 Books on Every Engineer’s Desk

I love a good book. And while the rise of the internet is definitely encouraging me to store most of my knowledge on Google- there’s still few things more satisfying than flicking through a trusty book when you’re in need of a reminder. Although I will admit to only buying three of the books I recommended- the rest were forever borrowed.

Finite Element Tetris

This post was the button mashing of finite elements. Unsurprisingly there’s not too much guidance on how to create impacting tetris shapes with enough give to create a satisfying squidge on impact. I remember spending much longer than I really should have done desperately calibrating the material properties and time steps until I finally found something the looked right.

Civil Engineers On Film

Every now and again I consider doing another one of these; and then I realise that I’m not sure I can name another five. There’s one or two omissions from the list (Locke, any one?), however the initial sentiment rings true today- civil engineers just don’t make the movies. If you haven’t seen it, thought, I would recommend you check out this fantastic sketch attempting to make infrastructure into one.

Programming Languages For Civil Engineers

I’m somewhat heartened by the number of engineers who are starting to look into the opportunities the digital age could mean to them. As the blog follows my own development, I’m hoping to not only instill a sense of what can be achieved by tooling, but also an appreciation of code as an art; that a good programmer can do for a penny, what any amature can do for a pound.

What Do Civil Engineers Actually Do

I suppose it is inevitable that this post will always receive attention. When your job title completely fails to describe what you do, it’s only fair that the outside world will wonder “what is a civil engineer?” And although I’d probably never go as far as to suggest we rename the profession, I do think it’s something that holds us back in an already competitive STEM talent market.

The post The 200th Post appeared first on Being Brunel.

At the moment, I’m mostly embarrassed. Sure, I’ll be angry, then sad; disappointed and finally resigned to picking up the pieces. I just can’t believe we did it. Yes- for all of you out there who don’t know; it turns out that 52% of my country decided that we’d be better off without the EU, and so we’re packing up and leaving. Needless to say, I was not part of this fractional majority. And I feel, given the large number of visitors I have “from the continent” that:

I owe you all an apology on Britain’s behalf.

I’m sorry Europe, for those that think we’re just “too full” to keep our borders open.

Engineering is a career that really drives home how much of an advantage the free movement of people across a large space can be. I’ve been lucky enough to be in teams where I’ve been the token english guy. That’s pretty remarkable- the ability to assemble a team of highly qualified engineers from a huge pool (especially with our local skills shortage). It also shouldn’t be taken for granted how amazing it is that they all wanted to work here- I wonder if that’s still true today; I hope so. Yes, England has struggling infrastructure; but where do you think we’ll find the labour, money and skills to improve it?

I’m sorry Europe, for those that think your attempts to improve health, safety and welfare in our nation was just ‘nannying’.

I’ve lost count of the number of times I’ve heard someone defend BIM’s lukewarm effects on “everyone not doing it properly”. However that’s nothing to how important it is that everyone implements a base level of health, safety and welfare. The EU’s attempts to bring us all up to baseline were fantastic; and while I can only hope we won’t drop all of it- it’s fair to say that there’s going to be some temptation to start increasing working hours, and interfering with our regulations. Yes taking CDM all the way down to household level is expensive, but then; are you saying you’d rather just expose all those one man businesses to asbestos so they can remain competitive?

I’m sorry Europe, for those that saw your efforts to define a minimum common specification of products as interferingly onerous.

Being able to require a product to a standard specification, and trust that it’ll meet it, is amazing; it creates a commodity market where the challenge is either to make the minimum conforming product cheapest, or to innovate your product to something better that justifies the price. However it’s not just products- the EU’s Eurocodes gave us the opportunity to learn a standard set of codes and design anywhere in the continent. Yes, sometimes they were a bit heavy handed or slow to adapt- but any large system always is; and isn’t it better that we all do it.

We’ve left now; and I can only hope that we recover and make the best of this brave new world we’re creating (for better, or for worse). However, for me, it’s with a heavy heart that we set out on this journey. So-

Thank you the European Union. There’s no doubt you made a positive contribution to civil engineering.

The post A British Engineer’s Apology to Europe appeared first on Being Brunel.