Todayâs newsletter features the flocode podcast. Iâm still figuring it all out so please bear with me.
If you would prefer to read rather than listen, the article below contains mostly the same content as the audio version, with the exception of a few additional tangents exclusive to the podcast.
This discussion (with myself) highlights the similarities between problem-solving in engineering and coding, focusing on efficient, iterative, and pragmatic approaches. It advocates for simplicity and continuous learning, underscoring the value of interdisciplinary insights in engineering problem-solving.
These are my opinions based on my own experiences so take it easy.
Some of the books I mentioned:
The Pragmatic Programmer by Andrew Hunt and David Thomas Goodreads Link
Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin Goodreads Link
The Lean Startup by Eric Ries Goodreads Link
Structures: Or Why Things Don't Fall Down by J.E. Gordon Goodreads Link
The Feynman Lectures on Physics by Richard P. Feynman Goodreads Link
Thoughts on the podcast?
I have a rough plan for many topics I plan to cover in these episodes but the main goal is to enjoy the process.
Please let me know if you have suggestions/feedback or requests for topics. I want the Flocode Project to become a collaborative community of engineers growing together and sharing ideas and perspectives. Pull no punches, assassinate me.
See you in the next one đ
James đ
Problem-Solving: A Practical Methodology for Engineers
This guide is crafted for anyone out there navigating the complexities of modern engineering problems and seeking insights that transcend the usual boilerplate stuff. It's a weird amalgamation of lessons learned thus far on my engineering journey.
The aim is not to prescribe an infallible method or to diminish the tried-and-true practices honed over years of collective experience. Rather, it's to share a collection of principles that have proven their worth in my own personal and professional growth.
This is a delicate topic. Engineers by definition solve problems so far be it from me to tell other engineers how they should go about their business. I would likely have the same success rate as if were to ask my wife to âcalm downâ.
Readers should consider this post as a peer's perspective, offered with humility, acknowledging the vast ocean of wisdom that the engineering community has accumulated and continues to build upon. Every project has its unique context and constraints, and this post is not a one-size-fits-all solution but a starting point for reflection and, perhaps, discussion.
Programming Principles in Engineering
At the intersection of engineering and programming best practices lies a shared commitment to precision, and efficiency. Both disciplines involve constructing systemsâbe they of concrete, steel or codeâthat must perform reliably under various conditions. This guide explores how the methodical approach inherent in software development, with its emphasis on clean, maintainable code, parallels the planning and execution required in structural engineering.
The value of pragmatic and efficient problem-solving cannot be overstated. It is the engine driving projects to completion on time and within budget, ensuring that structures not only stand but endure with minimal need for intervention. Efficiency in engineering translates directly into cost savings, safety, and longevity of structures, reflecting the same principles that guide the creation of robust and scalable software.
While pragmatism is a widely acknowledged virtue in engineering, its practical application is more challenging than it appears. It requires a disciplined adherence to simplicity and functionality, resisting the allure of over-complication, and focusing on what truly works within the constraints of the project.
Framing the Problem
Every project begins by confronting a problem that demands a solution. To clearly define the problem, engineers must go beyond the surface symptoms and understand the underlying issues. The questions behind the questions. I often think back to my squeakier 6-year-old self asking my dad a conveyor belt of âWhy?, But Why? But How? And then what? Why?â, until he was on the verge of an aneurysm and straining with every fibre of his being to calmly asked me to shut up while he was driving. A fine testament to his patience.
A problem well stated is a problem half-solved.
Breaking down complex challenges into smaller, more manageable parts is the divide-and-conquer strategy. This approach can simplify the problem and enable parallel development. It makes immense projects, which can seem intimidating at first glance, approachable and executable.
Assumptions are the Achilles' heel in problem-solving. I've blindly followed poor assumptions many times in the past. Questioning every hypothesis and commonly accepted 'truths' ensures that solutions are not just innovative but also grounded in reality.
"The first step to solving any problem is to understand that it exists," - Seneca
The psychology of accepting unproven realities is an interesting one, especially when you start to consider authority bias, social proofs and information cascades.
The quality of inquiry often dictates the innovation in response. The best engineers ask the best questions. And everyone loves a good question.
In my best Donald Trump voice - âNobody loves a good question more than me, believe meâ.
Planning
The planning and design phase is where the foundation for success is laid. Establishing clear requirements and constraints is imperative. It's a principle borrowed from lean startup methodologies that instructs one to be clear about the 'must-haves' and the 'nice-to-haves'. This clarity in requirements helps in crafting a roadmap that is focused and lean, devoid of unnecessary complexities.
Iterative design is at the heart of agility. Starting with a minimal viable solution and refining it through successive iterations is a strategy that builds resilience into the design process. This allows for adjustments based on real-world feedback, enhancing the suitability and functionality of the final product. It's a process of evolution, where each iteration is an opportunity to learn and improve.
Over-engineering is a common pitfall that can lead to increased costs, extended timelines, and systems that are cumbersome to maintain.
"Simplicity is the ultimate sophistication" - Leonardo da Vinci
Leoâs quote holds true in engineering as much as it does in art. The simplest design often leads to the most robust solutions.
Execution
Execution is the stage where plans and designs materialize into tangible outcomes. Writing codeâor in the case of an engineer, creating designsâas if one has to maintain it for a lifetime instills a mindset geared toward quality and sustainability. It calls for a vision that looks beyond the immediate completion of a design deliverable toward constructability, long-term utility and reliability.
In software development, test-driven development (TDD) represents a paradigm shift towards ensuring reliability from the get-go. This concept, when adapted to structural engineering, can lead to the implementation of proactive validation through simulation and modelling before physical construction begins. It mitigates risks and ensures that the structure will perform as expected when subject to real-world forces.
Continuous integration and delivery, staples of modern software development practices, are becoming more commonplace in large engineering projects. The ideas of incremental progress and continuous assessment, enabling teams to identify and address issues promptly are standard practice now, think of BIM coordination on any major project. This approach ensures that the final product is refined through continuous feedback and improvement, embodying the thought "We cannot control the wind, we can direct the sail."
This is easy to say and sounds like a standard corporate marketing video but it is the correct way to approach execution, especially in a complex multidisciplinary engineering project where scope changes can have significant domino effects. I have mixed feelings about this personally, with the right team, itâs a fantastic approach but there are times when I felt like there were too many cooks in the kitchen along with backseat drivers and armchair quarterbacks all in my office at the same time.
My advice is to be ruthlessly pragmatic with your execution. Idealize constraints and the limits of your scope, let it be known so that stakeholder expectations are crystal clear. If the goalposts move, adapt and refocus but maintain transparency on all challenges and effects. Easy to say, hard to do.
Review and Refinement
The iterative cycle is incomplete without review and refinement. In the world of programming, code reviews are essential to quality assuranceâanother practice that finds its parallel in engineering as peer reviews. This collaborative process not only helps in catching errors but also facilitates knowledge sharing and collective ownership of the project's success.
Refactoring is as vital in engineering as it is in coding, described in "Clean Code". It's about revisiting and revising the design to improve its structure and efficiency without altering its external behaviour. It embodies the spirit of continuous improvement and the strive for excellence.
The feedback loop is the heartbeat of the lean startup model and is just as crucial in engineering. It ensures that the project adapts to new information and evolves in response to functional requirements and constraints.
Books
Three excellent books that have profoundly impacted my ability to both frame and solve problems include:
âThe Pragmatic Programmer' by Andrew Hunt and David Thomas has been pivotal. It transformed my perspective on coding practices and embedded the core philosophy of pragmatism, enhancing the flexibility and effectiveness of the solutions I develop. Itâs for programmers but at least half of the concepts are perfectly applicable to project management and engineering. Itâs a fantastic book and easy to read.
"Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin - This book profoundly influences the pursuit of clarity and simplicity in writing code, which has an obvious correlation with structural and civil engineering. I might be heavy lifting for beginners. I recommend having 6 months of programming under your belt.
"The Lean Startup" by Eric Ries - This book introduces principles of agility and iterative learning that can be extrapolated to engineering, emphasizing the importance of adaptability and efficient solution-finding in project development. Every project is a startup.
While the books above are not specific to structural/civil engineering, I found tremendous value in the ideas presented and found so many reflections of the common pitfalls I have encountered throughout my career as an engineer.
One engineering-specific, yet casual book that I highly recommend is Structures : Or Why Things Don't Fall Down by J.E. Gordon.
And as a bonus, the Feynman Lectures on Physics by the Richard P. Feynman is the most incredible set of explanations of the basic principles of physics. I recommend this to anyone interested in the nature of reality. The clarity of Feynmanâs delivery is inspiring.
Conclusion
In conclusion, the journey through problem-solving in engineering is a continuous learning process, enriched by insights from various disciplines. While this path is often fraught with unexpected challenges, like trapdoors, wild goose chases, and moments of wheel spinning, these hurdles are integral to the process.
As you continue to push the boundaries of what is possible, let us remember that at the heart of every great engineering feat lies a simple yet profound truth: the best solutions are often those that simplify complexity, harness efficiency, and adapt to evolving needs. Let this be a guiding principle as you forge ahead in your quest to solve the engineering challenges of today and tomorrow.
See you in the next one.
Jamesđ
