How to Build Software like Tony Stark
This article will walk you through a process in which you can either get started with projects and break the cycle of just learning endlessly or change your ways and improve your workflow and efficiency while coding, so that you can stop feeling that this ain’t your thing and decide to learn Excel instead. We’ll do this by drawing inspiration from Tony Stark AKA Iron Man and how he builds things. I’ll also share some tips I follow personally to always be at 100%.
Writing great code these days isn’t really a problem. Everything is just a Google search away, just find the first link from Stackoverflow, find the most up-voted/accepted answer and boom copy paste!
The real challenge I see most people face these days is where to go next, or what to really do with the stuff they’ve learnt. We’re all guilty of watching an entire playlist of videos on the newest framework that does ’n’ things better than that other framework everyone seems to be using, but complains about anyway. Well most just watch, leave a like, a few comments and that’s the end. A few days later, it’s the same case with the next playlist you come across.
People consume these playlists at astonishing rates. There’s nothing wrong in learning new things, but the real mistake is not using them anywhere beyond the demo app/service the video uses to walk you through the framework.
If it’s something like React or Vue, it’s going to be To-Do list app. If it’s something related to Machine Learning like Tensorflow or keras, it’ll be on the MNIST Dataset (Identifying hand written digits) 9 times out of 10.
I get it, it’s hard to come up with a project to apply these technologies into, beyond say extending the sample code provided. Most of us add like 2 or more buttons to the To-Do app and call it a day, update your Resume and done. It’s easier if you picked up the playlist because you wanted to learn new stuff to work on your project, as you know where you want to go from there. Most people don’t take the next step as they’re either confident that they’ve mastered the framework from one course and will be able to use it when needed (big mistake) or they’re not really confident on how to put various frameworks together, as they lack experience(something which is quite common and not wrong). Then you compare yourself to those that came before you, who coded up Google on a simple computer in a garage and feel even more insecure.
By the way, I have a handy guide that helps you decide what languages, frameworks and approaches to pick when you’ve a certain project in mind.
Every programmer has to go through these phases at some point or another. Alright, so we know what you’re here for. You’ve been learning a lot of things and doing nothing with them, probably making you feel like more of an impostor. So what do we do ?
Well, here’s some life advice: When stuck in a mess, always look out for inspiration and you’ll find your way out eventually.
In this case, we’ll draw some inspiration from one of the faces of the MCU, Tony Stark AKA Iron Man…
So let’s get started, we’ll journey through the process that went into the creation of a few major Armors that Tony has donned through his 11 year career as Iron Man.
Mark 1 (Hacking Together)
In the earlier stages, when you’re just learning to code or work with a framework, you do all the work yourself, you google each and everything, somehow piecing together your code so that you can get some HTML page to load or a message to get displayed.
You troubleshoot everything from Stackoverflow answers, and refer back when needed.
This is similar to how Tony pieced together his suit in the cave from scraps and salvages.
Mark 2 (Aesthetics and Quality Control)
While Mark 1 was badass, it was still clunky, hacked together, couldn’t exactly fly, had to be manually equipped. Much like your first attempt to build something, most of the code works enough to display something and serve your basic purpose. Sure clicking on a 90s era button to open a popup that says Hello World is pretty cool, but is that really something you’d put in your Portfolio ?
Surely not. Much like the Mark 2, which was an all rounded upgrade, from aesthetics to automated assembly and flight capabilities, your code needs a second iteration too, or it’s not really something that will impress anyone outside your room.
So you pick some designs from online and try recreating them. Here are a few places where you can find design inspirations to get your creativity pumping:
Now that you’ve some inspiration, the next step is to figure out how to bring that design to reality. Well if you’re building a website/webapp, it’s quite simple. You make use of a toolkit/UI framework that has all the necessary components pre-styled and start customizing from there. Instead of building from the ground up (recommend this to the vast majority who want to build stuff, if you’re really into designing, then feel free to try building it from scratch). A few toolkits/UI frameworks you can make use of are:
- Bootstrap (Use it personally for most and I love it!)
- Bulma
- Daemonite’s Material (based on Google’s Material Design)
You can read up Google’s Case Studies on UI/UX, and guidelines for designing User Interfaces that suit the vast majority of devices and use cases.
Mark 3 (Testing and Bug Fixes)
Now Mark 2 looked nothing like its predecessor (you could say there was a stark contrast between the two) Mark 2 was a step ahead in every way, but it had it’s own flaws. This is lesson number 3 for us. Always Test!
Right after Tony was done designing and putting on Mark 2, he began testing, he jumped straight to a flight test, while the suit flew amazingly. It didn’t survive at higher altitudes due to icing. If he had entered combat without those results in mind, he’d not have won so gracefully.
So always test your code, to the best you can. Here’s a few links to write tests for Python and JavaScript (the 2 most commonly used/paired languages right now)
- Python Unit Testing
- JavaScript Unit Testing
- Additionally Testing for React (yes that’s a thing and very much needed!)
Just lookup videos for your weapon of choice.
The more tests you write, the more confident you’ll be about your code, especially when demoing it, or deploying it.
Mark 3 may have been a minor incremental update compared to Mark 2, but it was necessary, you know why. So don’t skip out on testing.
Mark 5 (Portability)
Mark 5 is a suit that focused heavily on being portable and easy to equip.
This is quite minor, but at some point you’ve to realize that your source files from your project folder are just too big to carry around for a demo, you can’t always hope to demo from the comfort of your laptop/pc. So consider packaging your project into an executable or deploying to a server to make it more accessible to you while you’re on the go and need to brag real quick.
Mark 6 (Major Redesigns and Spec Changes)
Now, from the exterior Mark 4 may again look just like a slight design tweak, but that’s not all. It came with a new Arc Reactor, that was completely rebuilt with a new element, that didn’t really exist till then. He decided to do that, because the previous core wasn’t holding up in the long run.
Time for lesson 4. Identifying things that aren’t working out.
Sometimes, you realize as you work that the effort you put in isn’t really coming to fruition because of the limitations imposed by the environment you’re working in, the framework you’ve chosen and so on. This was the same kind of problem Tony faced. So when a core component like say your PHP scripts (please don’t use PHP) aren’t able to keep up with your needs, it’s time to change tools.
Here’s something I came across during my earlier years as a programmer trying to build my own JARVIS. When I first started out around 6 years ago, I decided to use Windows Forms with C# (Yes I did that, not something I’m proud of, but surely happy about for reasons you’ll see). It provided everything I needed for my design back then. Speech Recognition via .Net, easy drag and drop UI builder (main reason why I chose it back then). I was able to build my first version and make it available for downloads.
It wasn’t exactly the best looking thing out there, but I was proud of it. But soon I realized that WinForms was way too old and outdated already, so I decided to switch to WPF another Windows Technology for UI design, that offered more granular control (compared to WinForms that is)
It came with support for XAML which is basically a glorified way of creating UI like you’d with HTML, by adding tags, attributes, while still keeping the drag and drop aspects. At this point I started appreciating the level of control that something like HTML was offering, the fact that I could do animations, custom themes and what not excited me and made me want to learn more and more. At this point I grew to like Material Design and moved forward with it.
As you can see, I changed my core platforms multiple times during my development journey for SAM, now Braggi. It was a huge pain to constantly change platforms, while the switch from WinForms to WPF was still on C#, once I switched to React, it was JavaScript. Surely all the code turned useless, but these changes helped me shape myself as a FullStack developer today.
So in conclusion for this section, I’d like to say that, be bold enough to consider changing out specs and frameworks that aren’t cutting it anymore. The faster you make the change, the lesser the headaches you’ll have. I’d have never grown to like Web technologies, and switch to React, then Flutter if I hadn’t switched to WPF then despite knowing how much of the UI was to be redesigned from scratch and that I had little to no experience with it.
Tony took the same kind of plunge as well. Always keep a backup of your old work so that in case things don’t pan out as planned, you’ve something to show at least.
Mark 7–50 (Deployment)
One thing all the suits moving forward had in common was the fact that they were getting extremely easier to equip, Mark 7 would arrive as a complete package, while Mark 42 could show up as tiny bits and pieces and assemble.
The key takeaway here is essential for Web Developers.
When your product depends on the user’s internet connection to satisfy them, it’s crucial that each byte of data transferred to and fro is as effectively compressed/organized as possible.
Let’s look at a few things you must do when you’re deploying your website onto a hosting service.
- Minify your JS and CSS. Minifying removes necessary and redundant data from your code to save space. This is crucial when every byte of extra file space can affect website loading time and server loads.
2. Use a CDN. A CDN (Content Delivery Network) stores files like images and videos that are requested frequently (say your logo or promo video that loads on your website), as these are usually larger in size than the entire website, and always on demand, they add significant burden to your server and hence it’s a good strategy to utilize CDNs, which are distributed servers that host your media for you, and make them instantly accessible. These servers are usually much faster than your hosting service and have lower failure rates. Examples include:
3. Use Bundlers like Webpack for WebApps: Bundlers will essentially glue together all your source files, like in the case of React Apps and make them work together, so that they can be served through a server. All files are linked according to your specification, defining entry points and exit points, which page is set to appear when and the like. Bundling again reduces load times and final space utilization on disk and over web, thereby saving you bandwidth and your users waiting time.
Mark 50–85 (Modularity, Automation and Hybrid Approaches)
Mark 50–85 was basically all about making the suit adapt to the situation, creating weapons, support at will which is a very hybrid and modular approach.
Now until these armors arrived, each armor was only so flexible, each one had a set of weapons and it’s own purpose, not all could travel into outer space, take on the hulk and so on.
While writing customized modules for certain use cases is good, you want to be able to reuse as much code as possible. Sure those transition animations you have are cool, and the 100 lines of CSS powering them are a true work of art, but what’s the use if they only look good for the slider on the main page ?
When writing code you should keep in mind of where you can reuse certain components.
Frameworks like React heavily focus on components being reused. Almost two-thirds of your login form can be reused to make your sign up form.
Try to minimize the need to rewrite the same components and logic, reuse wherever possible. Prepare conditions such that, on detecting state changes, certain elements of the form get disabled and hidden. Like in this case if the form state is set to “Login”, then password confirmation and full name fields should not be visible and text must be changed to Login wherever needed. Remember, redundant code avoided is space saved and most of all performance boosting!
Plan out your designs step by step on spreadsheet or on Adobe XD (which is free and amazing also professional to showcase with). Over time you’ll make a habit of planning your designs on paper/sheets and then hacking together your code.
Another useful tip would be to create boilerplate templates for yourself, so that you can start off from those templates for new projects instead of googling everything again. So even if you’re done with this project, you can kick start a new one in no time.
Some good bootstrap repositories I can suggest are:
- For Basic React
- For Advanced React (With Router, Redux, Express Backend)
- Django, Flask and a few others come with their own Boilerplate and are good starting off points.
- For Static Websites, lookup some free templates and try modifying them by mixing and matching them to fulfill your requirements.
Write down your requirements and analyze what more you need to make your dream project a reality, and learn them. Once you’re done learning, integrate them into your project, rinse and repeat till you have a version you’re confident showing the world to.
Remember, your journey as coder will be a continuous one requiring lots of learning, unlearning and relearning. No framework/language is created equally, each has its own learning curve and set of pros and cons. Be sure to always take into account all these factors before making a decision.
As I said earlier, it took me a long time to realize where I really wanted to take my project, the final specifications (for now) only started to materialize after many tear downs. So fear not if you find yourself taking things apart too often. In the end, it makes you more accustomed to building things. So keep building crazy things, breaking them, fixing them and reworking them.
So that’s all from my side, be sure to let me know your thoughts in the comments down below 👇. Would love to hear your experiences and suggestions too 😁.
Until next time, keep at it!
