I recently completed an intense 9 weeks coding bootcamp called FireBootCamp at SSW’s office in Sydney and today I wanted to share my experience about how it changed my perspective about software development as well as to hopefully encourage people out there (who are looking for ways to improve their skills) to go ahead and join one.
Why join a bootcamp?
Technology in general changes at a very rapid pace and specially if you are a developer you need to be ahead of the game, some of the things I’ve done to try to achieve this are:
- Read blog posts and tutorials about -insert language here- and new frameworks -insert framework name here-.
- Watch hours of Pluralsight videos.
- Follow influential people on Twitter.
- Attend different usergroups.
- Work on personal and open-source projects.
- Practice, practice and more practice.
While all the above has greatly helped in my short career I felt that something was missing, I knew I could build things that worked but I was mostly copying someone’s code without fully understanding what was going on or why things were the way they were.
This is where the bootcamp fitted perfectly in, it did not only break things down so I could digest them easier but it also showed me the big picture and provided me with enough exposure to problems (and ways to solve them) that everything clicked and started to make more sense.
What is SSW’s FireBootCamp?
SSW’s firebootcamp is the best way to increase your skills in an incredibly short amount of time, it’s 9 weeks where you’ll learn better ways to build maintainable and scalable software, better ways to improve as individual and enhance your communication and presentation skills and better ways to collaborate with your co-workers, clients, product owners, etc; and all that while using the latest and coolest technologies!
A rough overview of what we saw during those 9 weeks is below:
- Scrum: This was probably one of the biggest take away for me, we learnt how to inspect and adapt to the ever-changing software requirements, how to deliver software faster and continuously by getting early and regular feedback from the product owner and stakeholders, and by following the Scrum guide and all its events.
- Enterprise architecture: We developed a real application using the Onion Architecture, but most importantly we looked into why it was important to have an architecture, its pros and cons and how to future-proof your applications.
- Patterns and best practices: We covered a great deal of patterns and best practices aimed at building more robust applications, some of them were Inversion of Control and Dependency Injection, the repository pattern and SOLID principles.
- Full stack development: Not only did we dive into ASP.NET MVC 5 as back-end framework but we also covered Web API and Entity Framework as well as AngularJS and Kendo UI on the front-end, oh and how to forget TypeScript !.
- Continuous Integration and Continuous delivery: Deployments were one my biggest pains of all time but we learnt the right way to do it by integrating TFS (Visual Studio Online) as a tool to automatically build our code and run unit tests against it with Octopus Deploy to automate our deployments to Azure.
- Soft skills: also one of my most improved areas as I realised how important this is for our success. The days were developers sat on a dark corner are long gone so if you want to be successful you need to be able to communicate effectively and clearly (we had a lot of practice on presentation skills and how to market ourselves as developers; that is why I started writing this blog after we watched a video by John Sonmez).
- Talks by industry leaders: Once a week we would have speakers come and talk to us about different technologies, we had Andrew Coates talking about Azure, John Bristowe from Telerik, Paul Glavich talking about WebAPI and SSW’s Duncan Hunter with TypeScript, Adam Cogan with Scrum and last but not least our awesome mentor Gerard Beckerleg from whom I learnt the most.
I’m sure I am leaving a lot of interesting stuff out but you’ll hopefully get the idea of what this bootcamp is about and how it can help you increase your skills.
Final day and presentation
As if 9 weeks of coding and learning better ways to craft software was not intensive enough we were also asked to give a talk on the last of day of the bootcamp about a topic we really enjoyed and which had been beneficial (and it was in front of potential employers!). I chose Continuous Integration and Continuous Delivery with TFS and Octopus Deploy as it really took the pain out my deployments, below is a picture of my presentation !
So if you are serious about your career and are looking for a way to increase your skills then SSW’s firebootcamp is the best way to achieve it!.
I’d love to hear your comments or if there is anything you’d like to have included in this blog post let me know.
Continuous Integration (CI) is one of the software practices/techniques I recently had the chance to learn and play with at the SSW’s FireBootCamp and which has completely changed the way how I see software development and how I want to craft it moving forward.
If you feel yourself identified with some of the below items you should be looking into incorporating CI practices into your software development pipeline:
- You don’t have a source control system.
- You get a copy of a project from your control system but it won’t run because there are missing files or the build is broken.
- You rarely check-in your code.
- You never get the latest version from your source control system before checking in your code to make sure any new changes made by other developers don’t break your code (or even worse, to make sure YOUR code won’t break the build)
- You don’t write unit tests
- You don’t write integration tests
- You do write unit/integration tests but don’t run them against your code AND the code that sits on the source control repository.
- You check in a task/feature only when fully completed (after days/weeks of working on it) only to realise it won’t work on UAT/staging/production
Any of the above will result in painful integrations, poor quality code (usually off-schedule), with many many bugs and with the overall experience that software development sucks (without mentioning what the end user/customer will think about the product/us).
Is there a way out?
Yes !, its called Continuous Integration and it’s relatively easy to implement (I haven’t personally had much experience to be honest but I can see the many benefits from it and the steps seem simple enough)
It’s whole concept revolves around the idea of improving your development practices by encouraging you and your team to:
- Get the latest version of the shared code before checking in your code.
- Run unit and integration tests against your code.
- Check-in your code regularly (at least daily).
- Have a build automation system.
- Have the shared code built by your build automation system
- Have the shared code verified by running automated unit and integration tests against it
- If any of the above steps fail then have the build automation tool inform you so you can fix it and start the process again.
Simple, huh? to me the greatest advantage of following this process is that you don’t need to spend separate time trying to integrate a newly built feature into your system; by checking in your code and fixing problems along the way the ‘integration’ becomes an inherent task that of the process, i.e. no need to wait for months to realise that two complex features that you and your team were working on did not integrate properly and now you have now to stay back and fix it rather than going to the pub with your friends :(.
Some others (equally important) advantages are:
- You always have a working version of your product (which could potentially be a shippable product)
- You get immediate feedback about any problem that arose as a consequence of the new code checked-in.
- Greater visibility of the current status of the product
- Isolating and tracking bugs becomes easier as it’s often related to the new code.
- Reduces the number of bugs in your application as you fix them sooner rather than when the customer rings you a month later.
- Improves communication with your team
There you go, start incorporating a continuous integration process in your software development practices if you haven’t already done so.
By the way, there are some great blog posts about this subject that I have listed below:
Do you know of any other advantages that Continuous Integration provides?
Today at the Week 2 Day 3 of our bootcamp we had Microsoft developer Evangelist Andrew Coates talk about building cloud solutions with Azure.
Some of the big takeaways from the talk were:
- Developers need to be lazy: don’t reinvent the wheel, instead add value to your company by coding only what you can code (for instance don’t spend too much time working on form validation as you can have a libraries or someone’s code to do that, instead spend it coding stuff that only you know, such as solutions to your business needs etc)
- Microsoft Azure offers this huge range of solutions / services that span across Infrastructure as a Service IaaS, Platform as a Service PaaS or Software as a Service SaaS (not only Microsoft but companies such as Amazon too) so you can concentrate on the important stuff and let them worry about keeping everything else up to date.
- You can scale up/down or scale out according to your needs (this can be automatically triggered if certain conditions are met, such as the processing power of a machine X reaches certain threshold etc).
- You can have Continuous Delivery done by combining an Azure website with Visual Studio online so that anytime you check-in your code Visual Studio will create an automatic build for you and if it passes (including running unit tests if available) will deploy it to your Azure environment (UAT, Staging, production, etc)
We also had a practice lab where we could put all that theory into practice, the screencast of a continuous delivery with Visual Studio Online in Azure can be watched below:
Thanks for reading / watching