The Advantages Of Being Self-Taught

At a recent meetup event I was conversing with a small group of attendees, one of whom was an aspiring self-taught mobile developer. He was passionate and enthusiastic, but there was some doubt in his mind. He’d been following our conversation which to that point had been filled with tech-related jargon, and admitted that he was struggling to keep up. He feared that his lack of experience, or of a CS degree, meant that he was at a major disadvantage when it came to finding his first tech job.

Having been in the exact same position a year ago, the conversation led me to a realisation that none of these ‘disadvantages’ ended up being detrimental to my career prospects. To the contrary, I believe there are several advantages to being a self-taught developer.

Communication skills

An agile tech team is rarely made up purely of developers. Not only must you know how to code, but you will often need to explain complex technical problems to product managers, BAs and, depending on the size of your company, sales, marketing and even clients and customers. Within a development environment it’s easy to spend 99% of your time communicating with other developers who already have a deep understanding of your challenges. There aren’t many opportunities to gain experience in adapting your language to fit the vocabulary of your non-dev peers.

If you’re self taught, it’s likely that you’ve spent time in another industry. And whether that was serving customers in a retail outlet or presenting statistics to a room of people, you’ve already gained a huge amount of invaluable experience in being able to empathise and communicate with people from a variety of backgrounds, making it easier to keep the whole team aware of what you’re doing and why, and be able to ask questions so that you can fully understand the requirements of the business.

Learning faster

Author Malcolm Gladwell popularised the theory that it takes 10,000 hours of practice and hard work to become an expert in anything. It’s a shaky and strongly challenged theory, but the mantra ‘practice makes perfect’ has been applied to many subjects. If you apply this to teaching yourself how to code, you would expect that the time you’re putting into learning means that you’re becoming a better coder over time. What might be less obvious is that you’re also teaching yourself how to learn. You’re not following a text book cover to cover, or struggling to meet a submission deadline. You’re developing your own learning rhythm, figuring out how to grasp difficult concepts quickly, learning how to find answers to questions without the benefit of a tutor or mentor. You’re making mistakes, lots of them, and instead of having them pointed out to you, you’re experiencing their consequences and learning how to adapt to those failures.

Once you get your first tech job, you’ll be thrown head-first into things you aren’t prepared for. But the time you’ve invested in learning how to learn means that you’ll adapt quickly and be up on your feet in no time at all.

Vocational skills

I’ve spent a lot of time working with computer science graduates, either during their ‘year in industry’ or as part of a graduate employment programme. What continues to surprise me is that almost none of their university courses seem to teach the fundamental vocational skills that almost every developer needs when working within a company. They learn complex algorithms and concepts such as turing completeness, but they’re not strongly encouraged to learn things like version control, unit testing, DevOps, or how to write clean, maintainable code.

The self-taught approach leaves you without a nice juicy qualification with which to pad out your CV, so the alternative approach is to build a portfolio of published work, either having released apps to production or published your code on GitHub (ideally both). If you’ve published your own apps then you’ve had to learn the entire process, from File -> New all the way to deployment. And to maintain a portfolio on GitHub requires at least a basic level of knowledge around version control. You come up against a lot of the challenges that companies face when trying to bring a product to market, so once you’re in a job, you’ll hit the ground running on lots of these things.

Job satisfaction

The most likely reason for wanting to pursue a career in software development is because you have a real passion for coding. Teaching yourself to code is not easy, and you’ll only stick with it if you enjoy it deeply. If you get to the stage where you want to turn your hobby into your career, then getting that first job is made all the sweeter; You’ve sacrificed so much of your free time to become an awesome coder and now here you are, getting paid for doing something you love. It’s an incredible feeling, and it inspires you to do awesome work. It makes you extremely valuable to employers.

Have I missed anything out? Share your own experiences, I’d love to hear them!

Grouped UITableViews with MVVMCross

I recently had a requirement to implement a grouped iOS table view in a project that was using MVVMCross for its MVVM architecture. MVVMCross provides a very clever way of binding data (as a collection of ViewModels) to a table view source, but neither the official documentation nor Google searches gave any straightforward examples of implementing grouped sections within a UITableView, so here’s how I managed to achieve this:

Notes and assumptions

  • I’ve assumed if you’re reading this then you’re probably keen on using custom table cells, so the examples include the most basic of custom cells with a corresponding .xib and a ViewModel to bind to. You shouldn’t have any problems binding to properties in a basic cell type.

  • At the time of writing, the examples I’m using are buit for and using:

  • MVVMCross 5.6.3
  • Xamarin.iOS 11.6

  • The full example source code can be found here

The code

For this example I’ve added a UITableView to my main view controller .xib, and named it MyTableView:

Main view controller:

using System;
using Foundation;
using MvvmCross.Binding.BindingContext;
using MvvmCross.Binding.ExtensionMethods;
using MvvmCross.Binding.iOS.Views;
using MvvmCross.Core.ViewModels;
using MvvmCross.iOS.Views;
using MvvmCross.iOS.Views.Presenters.Attributes;
using MvvmCross.Platform.Core;
using MvvmCrossGroupedTableView.iOS.Views.Cells;
using MvvmCrossGroupedTableView.ViewModels;
using UIKit;

namespace MvvmCrossGroupedTableView.iOS.Views
    [MvxRootPresentation(WrapInNavigationController = true)]
    public partial class MainView : MvxViewController<MainViewModel>
        public MainView() : base("MainView", null)

        public override void ViewDidLoad()
            Title = "Grouped Table View";

            // Apply a custom MvxTableViewSource to the table view
            var myTableViewSource = new CustomTableViewSource(MyTableView);
            MyTableView.Source = myTableViewSource;

            // Bind the ItemsSource property in the table source to the view model
            var set = this.CreateBindingSet<MainView, MainViewModel>();
            set.Bind(myTableViewSource).To(vm => vm.MyData);


View model for the main view:

using MvvmCross.Core.ViewModels;

namespace MvvmCrossGroupedTableView.ViewModels
    public class MainViewModel : MvxViewModel

        public MainViewModel()

        // A simple collection to provide data for the table view, yours will be more dynamic obviously ūüôā
        public MvxObservableCollection<MvxObservableCollection<CustomCellViewModel>> MyData
                var firstGroup = new MvxObservableCollection<CustomCellViewModel>();
                var secondGroup = new MvxObservableCollection<CustomCellViewModel>();

                firstGroup.Add(new CustomCellViewModel("Section: 0, Row: 0"));
                firstGroup.Add(new CustomCellViewModel("Section: 0, Row: 1"));
                firstGroup.Add(new CustomCellViewModel("Section: 0, Row: 2"));

                secondGroup.Add(new CustomCellViewModel("Section: 1, Row: 0"));
                secondGroup.Add(new CustomCellViewModel("Section: 1, Row: 1"));
                secondGroup.Add(new CustomCellViewModel("Section: 1, Row: 2"));
                secondGroup.Add(new CustomCellViewModel("Section: 1, Row: 3"));

                return new MvxObservableCollection<MvxObservableCollection<CustomCellViewModel>>()
                    firstGroup, secondGroup


View model for my custom cell:

using MvvmCross.Core.ViewModels;
using MvvmCross.Platform.UI;

namespace MvvmCrossGroupedTableView.ViewModels
    public class CustomCellViewModel : MvxViewModel
        string _text;

        public CustomCellViewModel(string text)
            _text = text;

        public string Text
            get => _text;
            set => SetProperty(ref _text, value);

My custom table view cell:

using System;
using Foundation;
using MvvmCross.Binding.BindingContext;
using MvvmCross.Binding.iOS.Views;
using MvvmCrossGroupedTableView.ViewModels;
using MvvmCross.Plugins.Color;
using UIKit;

namespace MvvmCrossGroupedTableView.iOS.Views.Cells
    public partial class CustomCell : MvxTableViewCell
        public static readonly NSString Key = new NSString("CustomCell");
        public static readonly UINib Nib = Nib = UINib.FromName("CustomCell", NSBundle.MainBundle);

        public static CustomCell Create()
            return Nib.Instantiate(null, null)[0] as CustomCell;

        protected CustomCell(IntPtr handle) : base(handle)
            this.DelayBind(() => {
                var set = this.CreateBindingSet<CustomCell, CustomCellViewModel>();
                set.Bind(TextLabel).To(vm => vm.Text);

Finally, we need to create our custom table view source, which is where the magic happens. You need to create a custom source which inherits from MvxTableViewSource as follows:

public class CustomTableViewSource : MvxTableViewSource
        public CustomTableViewSource(UITableView tableView) : base(tableView)

        // # 1:
        public override UITableViewCell GetCell(UITableView tableView, NSIndexPath indexPath)
            var group = ItemsSource.ElementAt(indexPath.Section) as MvxObservableCollection<CustomCellViewModel>;
            var item = group.ElementAt(indexPath.Row) as CustomCellViewModel;

            var cell = GetOrCreateCellFor(tableView, indexPath, item);

            return cell;

        // # 2:
        protected override UITableViewCell GetOrCreateCellFor(UITableView tableView, NSIndexPath indexPath, object item)
            var cell = tableView.DequeueReusableCell(CustomCell.Key) as CustomCell;

            if (cell == null)
                cell = CustomCell.Create();

        // # 3:
            var bindable = cell as IMvxDataConsumer;
            if (bindable != null)
                bindable.DataContext = item;

            return cell;

        // # 4:
        public override nint NumberOfSections(UITableView tableView)
            return ItemsSource.Count();

        // # 5:
        public override nint RowsInSection(UITableView tableview, nint section)
            var group = ItemsSource.ElementAt((int)section) as MvxObservableCollection<CustomCellViewModel>;
            return group.Count();

        public override string TitleForHeader(UITableView tableView, nint section)
            return string.Format($"Header for section {section}");
  1. Override the GetCell() method as you would normally do in a standard UITableView source. First of all, parse your ItemsSource (the default data source which your view model data is bound to, which is IEnumerable) to get the cell’s custom view model. Next, use the GetOrCreateCellFor() override to generate the cell to return.

  2. In a MvxTableViewSource you must override the GetOrCreateCellFor() method, as this is where your cell is set up and data bindings are connected. Because we’ve overridden GetCell(), we can pass the specific cell view model to the cell we’re creating.

  3. This chunk of code is vital to set up the bindings between the custom cell and the cell’s view model that you’ve passed in.

  4. and 5. As with a normal UITableViewSource, you’ll want to override these methods to explicitly control the number of sections and rows for each section.

I hope this guide provides enough information for you to implement your own grouped tables, if there’s anything that’s missing or if you have any questions, comment below or get in touch via Github.

Shrinking your Xamarin iOS binary using the mtouch linker

Submitting an app to the App Store can be tricky business – setting up certificates, provisioning profiles, providing all the necessary assets – it can take hours, if not days to finally get your app submitted for review for the first time. Add to this Apple’s 100mb file size limit and you can end up in a world of hurt.

One way of squeezing the size of your app binary is to make use of the linker, which can be set here:

(iOS Project) > Options > iOS Build

During build time, the mtouch linker will run through every part of your code, stripping out anything that it deems unused, so that your resulting binary is as small as possible. By default,¬†your project’s default setting for ¬†will likely be set to ‘Don’t Link’ for your iPhone Simulator configuration (which means a faster compile time, since the linker doesn’t attempt to strip away unused code), and ‘Link Framework SDKs Only’ for debugging on a device, which means that the linker will only strip unused code from the Xamarin.iOS SDK and leave your code and packages alone.

These settings may be sufficient for your app, but when it comes to publishing to the App Store you might find that your app’s file size is greater than Apple’s 100mb limit, especially if you’re using a lot of embedded media. To help solve this problem you can use the linker to cut down on unused code from all of the packages and assemblies you’ve added to your project, as well as your own code by setting the behaviour to ‘Link All‘. Your compiled binary will be made as lightweight as possible.

Magic, right?

Well, it might not be as easy as all that. Depending on your app, it’s likely that the linker will strip away code that your app actually needs, such as code that your app calls dynamically or indirectly. In these cases, you need to tell the linker to preserve the code that you’re still using.

It comes down to a bit of trial and error – running your app and seeing where it crashes or doesn’t behave predictably, then finding the code that’s no longer executing properly. When you do find the bugs, you can make use of Preserve attributes to make the linker ignore the feature and move on.

Preserving your code

In my latest iOS project, the code I found to be troublesome during linking were the data models I created for using Json.NET parsing. The linker was stripping out the empty constructors, which Json.NET relies on whilst serializing/deserializing Json data.

To overcome this, firstly I created a new PreserveAttribute class so that I could use Preserve attributes in my shared PCL (place this in any namespace you like – the linker looks this attribute by type name):

public sealed class PreserveAttribute : System.Attribute 
    public bool AllMembers;
    public bool Conditional;

Then I used thePreserve attribute to tag all of the models that were causing issues:

[Preserve(AllMembers = true)]
public class Route
    public string Name { get; set; }

    public string Description { get; set; }

    public double Distance { get; set; }


Do this wherever there’s code that you don’t wish the linker to remove. You have the option of using¬†[Preserve (AllMembers = true)] for preserving the whole class, or¬†[Preserve (Conditional=true)] to protect specific members within a class.

Preserving assemblies

If you are having problems with the linker taking useful code away from 3rd party packages that you’ve installed, you won’t have the option of setting attributes like above. To protect an assembly from the linker, you can use the mtouch command-line tool. In Xamarin Studio you can add arguments in the iOS Build settings of your project, for example:

Screen Shot 2017-06-10 at 10.06.33

Finding the troublesome code can be very tricky and time consuming, so in some cases using the linker might not be the best option for you. If you have large media files embedded in your project such as images or video, you could consider hosting them on a server and then downloading them at run-time instead of bundling them into your package file.

If you’re having problems using the linker, more details are available on the Xamarin website, where there is also details about using the Android linker.

Self-taught coder? My thoughts on getting your first tech job

I’m not the only person who learned to code in their spare time and then hoped to start a career in tech. I see more and more posts on forums, and meet more and more¬†meetup attendees who are in the same shoes I was in just a few months ago; No formal qualifications, just a few amateur apps on their phones and a raging desire to break into the industry. I know how it feels to not know how you could possibly stand out to employers whilst large swathes of computer science graduates are¬†applying for the same roles that you are. I felt completely out of my depth and a large part of me had worried that I’d made a terrible mistake, sacrificing so much for an unachievable pipe dream.

Thankfully, my own gamble paid off, and those sacrifices were absolutely worthwhile. I made a few mistakes along the way though. There are lots of things that I wished I had known in advance or could have done better in order to land the right job for me.¬†Having been through this process, I’d like to share a few of the things that I learned that might be useful for fellow DIY-ers.


You have what it takes

The biggest hurdle I had to overcome was the fear that I was so severely under-qualified for the jobs that were being advertised. I didn’t see a single job ad that didn’t have most or all of these requirements, in some form or another:

  • At least 2 years’ commercial experience
  • University-level degree in computer science or¬†similar
  • At least one app on the app store
  • Experience in TDD, BDD, DDD, SQL, TCP/IP, HTTP, HTML, CSS, RESTful API, XML, JSON, CI, CD, etc. etc. etc.

In the meantime there’s surely thousands of recent graduates, or teenagers with unpaid work experience, fighting for the same positions that you are, and probably match quite a lot of the criteria. How do you compete with that?

‘At least 2 years’ commercial experience’

The obvious problem with this is the chicken/egg paradox. How do you get experience without first getting a job? how do you get a job without experience? Employers are actually well aware of this and I’m beginning to see this requirement crop up less and less in junior-level job ads. But even if it’s there, don’t take it as gospel; it’s more of an indication that an employer doesn’t expect to have¬†to teach you how to write simple code, and expects that you’ve spent a lot of time learning as much as you can, with at least a passable amount of skill to be able to do the job. Companies know that when they hire junior-level developers, they’re not going to have found someone who can just turn up on¬†day one and start shipping awesome new features.

‘University-level degree in computer science or similar’ (and ‘Experience in x / y / z…’)

I grappled with this in my mind, and had considered spending ¬£1,000’s on intensive bootcamps or Masters degrees to level-out the playing field a little. That was until I began speaking to developers at some of the free evening meetups around London. It turns out that while students at colleges and universities were being taught how to code (algorithms, data science etc), they’re not actually trained to be software engineers. Anyone can write a ‘for’ loop. Not everyone can spin up an EC2 instance, or set up analytics tools. I realised that as long as I could write good, clean code, and be able to demonstrate my abilities (either through my open source projects, or coding on a whiteboard) I could learn the rest on the job. And it turns out that employers feel the same way.

‘At least one app on the app store’

Fair enough, this is one where I would certainly encourage you to achieve this before approaching employers. Whether it’s a mobile app, website or a plugin/library, build something from scratch, and publish it. It’s hugely advantageous to be able to demonstrate to an employer that you can take an idea from concept – to development – to shipped, because that’s what your job will actually be. Fortunately this is most likely something that you’ll have done as part of your own learning. If you haven’t shipped anything yet, it’s very easy to do so, and there are a lot of free online resources (not to mention platform/store documentation) that will walk you through the processes. Get your code out into the wild!

My main point here is that you probably know more than you think you do, and anything you don’t know, you should be willing to learn either on-the-job or before you start. You most likely have what it takes.


It’s all about Clean Code

After about 12 months of teaching myself to code using books, youtube and online ‘how-to’s, I felt that I had¬†learned enough to call myself a developer. I could build Android apps from the ground up, and had even published my first. I could read other people’s code and more-or-less understand all of what was going on in there, and I had explored various platform APIs. There’s a very popular twice-annual tech¬†job fair in London called the Silicon Milkroundabout¬†and I figured that I’d attend, not to land myself a job but to actually talk to people in the industry and get a flavour of what to expect (and by the way, I’d recommend doing this yourself). I got chatting to a guy at one of the booths and asked him what I should do to take my skills to the next level. He had one piece of advice, which was to read Clean Code by Robert C. Martin (‘Uncle Bob’, as he’s affectionately known throughout the industry):




The code examples in the book are mostly written in Java, but the lessons apply to a heap of languages. I read this book from beginning to end, then went back and re-read quite a few parts. Then I looked back at some of the code I’d written before I bought the book, and was disgusted! It’s certainly one thing to know how to code, but if you¬†write code that’s messy and not easily understood by someone else, then you’re going to struggle. Read this book, and others in the series. Learn about S.O.L.I.D. principles (I was asked about my knowledge of those in every interview I had), and the other lessons that this book contains. Doing so will¬†be hugely advantageous, I promise you.


Your attitude is what really counts

You’ll hear people say this, that attitude is just as important as aptitude, but it’s more true than I thought. In fact if you’re trying to land your very first job in tech, I would say it’s even more important than your ability to code. Why? Because, if you’ve been reading up until now, you’ll probably have realised that your skills are in short supply. Employers know this about you already. What they’ll be looking for is someone with the right attitude; the sort of person who has a real passion for coding, and has enough enthusiasm to learn both on the job and in their spare time. I’m quickly realising that software¬†developers must be life-long students, constantly keeping their skills relevant and up to date as technology evolves and changes. Your skills in C++ or Java might not be as relevant in 30 years’ time as they are today, and you need to have a passion for learning to¬†have a successful career.

Show your passion in your cover letter, and let it flow out of you during your interviews, and you’ll be on to a winner.


You’ll never ‘feel’ ready

My biggest mistake is spending too much time trying to learn as much as I could, and publish loads of apps. I’ll be honest; I began learning to code in late 2014, and I didn’t feel ready enough to throw my already well-established career in media away and take my dream tech career seriously. For all the reasons¬†earlier in this post, I just didn’t think that I was ready to approach employers just yet. I was thinking to myself, just launch another app, contribute to a few more open-source projects, I’ll get there eventually. But two years later I still hadn’t even written a CV. When I finally did, and began applying for job vacancies, I still didn’t feel prepared enough. I thought I’d be laughed out of the interviews. That’s why I was so surprised when the job offers started coming thick and fast…


They need you more than you need them

This might not be so relevant in years to come, but presently, the rumours are true: There is a huge shortage of coding skills, and a huge demand. Tech companies are competing with each other to snap up talent. This was very different to¬†I was used to, since the media industry is the opposite way around (lots of graduates wanting to work in media, but not a lot of jobs available). I don’t think that you should take this to mean that you don’t need a decent skill level before applying for jobs, because that won’t work to your advantage in the future, but believe me when I say that right now, those employers want you, and they’re paying a lot of money for people like you.

Because of this, when you start applying on job boards (Get on as many as you can. I’d recommend Stack Overflow‘s job board, it has a lot of opportunities on there and provides you with a fantastic profile, which can work in favour of people with no experience), don’t be surprised to get flooded with emails from both recruitment consultants and direct from employers. A quick note on 3rd party recruiters, which I may get some challenging comments about, but don’t assume that they’re out to swindle you. I had some very good experiences with most of them, and I learned a lot from what they had to say.


I hope that this helps to allay some of your fears about finding your dream tech job. If you’ve found it useful or if you have stories of your own, then I’d love to hear from you – comment below or get in touch!

My first weeks as a Software Engineer


That’s got a great ring to it, hasn’t it? What a great word.

It’s a¬†badge that I now wear proudly. Six months ago, after a lot of hard work, planning, soul-searching and ball-finding, I made the toughest decision of my life; end my half-decade strong career in media to¬†focus on my dream of becoming a developer. Until that point, I had been nurturing a passion for writing code in my spare time, building mobile apps as a hobby. I had come to realise that I loved building apps more that I loved my job, and I’ve always believed¬†that enjoying your job is¬†incredibly important. So I took the risk, believing it was worth it, and left my job to focus on building my development portfolio and applying for junior roles.

And boy, did it pay off.

After just 3 months of unemployment, coding hard and learning hard for 8-10 hours every day, I finally convinced a handful of tech companies that I had what it takes to work for them, and I accepted an amazing opportunity at a global, well-established and exciting company based in London, as an Associate Software Engineer.

Now the challenge begins.


My First Week

The first thing I did once meeting my new colleagues was set up my new desk. Easy enough; A brand new Macbook Pro with 2 large external monitors, and a bunch of devices I’d be building software for. This is so cool.

A few more introductions later and I find myself pairing with a senior engineer on my team. We’re just 3 minutes into our conversation when I begin to realise: I know nothing.

I’d spent countless hours teaching myself how to write algorithms, how to build UIs, how to build and run code, how to publish my apps through the app stores. I thought I’d at least be able to hit the ground running with those skills under my belt. What I hadn’t realised is that there’s a whole other layer of understanding (and a whole lot of acronyms). Here’s a few things I had little or no knowledge of:

  • CI
  • Deployment pipelines
  • AWS
  • EC2 instances
  • DynamoDB
  • QA environments
  • Kibana
  • Grafana
  • multiple git branches
  • Architecture frameworks
  • APIs
  • Specflow

There’s a tonne more stuff that I had either never heard of or just didn’t spend the time looking into, and a lot of things that I just wouldn’t have been exposed to before.

This was going to be a rough few weeks.


My first month

A month in, things are¬†making a little more sense. The most humbling experience has been discovering that there is no shortage of experienced engineers who are eager to spend as much time as it takes to help you out with what you don’t know. Without actively seeking one, I quickly established several mentors, each of whom enthusiastically¬†passing on their knowledge to the newer generation. As one of them often points out, they’ve all been in exactly the same place that I’m currently in, and they know exactly what it’s like to feel as overwhelmed as I do. Perhaps I’ve just found the right company to work for, but I’d wager that this kind of attitude is endemic within this industry, which is an amazing thing.

I’ve already built features, fixed bugs and have seen my code shipped to thousands of users in six countries, which I’m immensely proud of. As every day passes, I’m getting a better of understanding of the company’s tech stack, and have made a point of working on things that challenge my knowledge in order to learn as fast and effectively as possible.


From here

I took great encouragement from forums, bloggers and people I met at various tech meetups during¬†this journey, and I still do. Perhaps the thing I love most about this industry is the community; there are thousands of people giving out advice, writing how-to’s, sharing code, sharing stories and giving their time away for free, without wanting anything in return, and I find those people to be an inspiration. So through this new blog of mine, I hope to give something back to the community. I’ll use this as a platform for sharing some of the things I learn, reflecting on life in the tech industry, and to¬†help and support others with similar ambitions as much as I can.

If you have any feedback, questions or just want to get in touch, I’d love to hear from you!