The weather’s great outside right now, but you can’t go to the beach! What to do, what to do… why not pick up a new skill, say… programming? Many members of the AEC industry have discovered that now is an opportune time to expand their technical knowledge, and this is a great field to explore.
A road map of what the article will cover
Programming has become increasingly relevant in AEC over the past decade or so. Such programs as Dynamo and Grasshopper have brought programming to the mainstream users (not just developers) and this can provide growth pathways to those that were previously on the outside.
Design and technical aspects of what we do, particularly in architecture and engineering have the potential to be streamlined and even automated by introducing scripted and coded methods to our work. Good examples of such banal tasks we can automate include placing views onto sheets, placing dimensions and printing out drawings - this gives us more time to actually do our job!
Where to begin?
Of all the questions we receive at BIM Guru (typically via our LinkedIn), the most common is 'which programming language should I learn first?'. Whilst there are many starting points available, it all depends on what you aim to achieve through your programming journey - context is the key.
A common mistake I notice in most learners is that they learn to code 'because it is the next big thing' or 'because it will get me a better job'. This outlook is fundamentally flawed; programming is a skill that requires dedication, passion and a genuinely curious mind. It is important that before you even begin, you research your options and set clear goals of what you want to get out of learning these new skills.
Find the 'why' to your 'what'.
A choice: Grasshopper or Dynamo?
For most people working in the AEC industry, one of these two programs are the best place to begin. Both programs belong to a paradigm known as visual coding - instead of writing code line by line, we connect blocks of data together using strings from left to right. The flow of data is visually understandable without the user needing to spot and identify variables buried in lines of written code.
The second most common question I receive is which of these two a user should begin with, or even aim to learn at all. My answer is always dependent on the user's skill set, as well as the workflows they use on a day to day basis - again, it's all about context.
In the case of Grasshopper, if the user focuses on design exploration (space planning or form molding) then this is the right choice to begin with. Until recently, Grasshopper was constrained to the Rhino 3d platform, but now even Revit users can access it via the Rhino Inside add-in for Revit. Grasshopper excels when it comes to complex and rapid form generation through the power of the Rhino 3d NURBS engine - something Dynamo does not handle particularly well.
In the case of Dynamo, if the user is primarily a Revit user this is probably the right choice. Such concepts as families, views and sheets are foreign to Grasshopper, but Dynamo is specifically built to work hand in hand with these - most of its nodes are built to directly interact with Revit based elements.
Dynamo is the perfect way to use Revit as a driver for the context to your coding journey, and it focuses more heavily on the processing of data - something which will aid you further down the line when you explore object and list based languages. Whilst Grasshopper excels geometrically, its tree based method of data structuring is quite abstract for new users (unless they're a seasoned arborist!).
Ultimately, I always recommend users should explore both at some point - you may find yourself finding use out of both programs (as I have), as they compliment each others weaknesses well.
Transitioning beyond visual coding
As users explore visual coding platforms, various limitations and barriers will be encountered - these usually lead users away from visual environments into object based environments such as Python and C#. Behind the scenes of each 'block' in a visual coding environment, these languages are usually doing the heavy lifting.
Some good steps to take in Grasshopper to transition include:
- Making more use of clusters
- Mastering tree and sub-list manipulation
- Making more use of functions
- Studying exposed clusters by other users
Some good steps to take in Dynamo to transition include:
- Beginning to use code blocks
- Mastering list and sub-list/level manipulation
- Beginning to use design script
- Studying exposed custom nodes by other users
- Building your own custom nodes/packages
Python has quickly become one of, if not the most popular entry level programming languages for users entering the coding paradigm. Its list and object based nature is easy for new users to grasp and experiment with. Such concepts as variable assignment have a rather forgiving degree of flexibility and there are some great IDE's out there to assist with the learning journey as well.
In the case of Dynamo and Grasshopper, both support Python coding (particularly in Dynamo, which features an IronPython shell). It is not common for Python to be used for actual application development, for this you will need to look beyond again - but take it a step at a time: walk before you run.
If you're looking to learn Python, be sure to check out the learning series we're currently releasing on our Youtube channel.
Do I need C#?
Surprisingly, I usually have to tell people that they often do not need to go beyond Python, they probably won't have the context to necessitate this step. There are already so many developers out there using this language to enhance AEC workflows - chances are someone may already have done what you are thinking of doing that requires C#, such as developing an add-in available for public use.
The main reasons most users transition to C# include:
- Developing more efficient clusters or nodes
- Developing add-ins for their company
- Developing add-ins for the market
- Developing web/interface based applications
The key word you should notice above is develop. C# requires an enhanced skill set far more complex than Visual coding and Python, where the goal is no longer linear - instead you need to learn more about interface development using WPF, relinquish your dependency on custom packages and compile your code via multiple resource types - you are the developer behind the solution now.
Conclusion: Context, context, context!
As you've probably found through reading this article, it's a long and difficult journey to get all the way from the basics to developing your own programs in C#. You must constantly assess your aptitude and goals throughout your journey to ensure you do not rush, nor that you go beyond where you need to end up in your exploration of programming.
We hope this helps others identify new opportunities, and always welcome you to reach out to us should you have any further queries or seek mentoring (which we offer as a service to our clients).
Stay safe, and remain productive!
- Gavin Crump @BIM Guru