Skip to content
Humble Beginnings (feat. Les McCutcheon) episode artwork

EPISODE · Mar 13, 2017 · 0 MIN

Humble Beginnings (feat. Les McCutcheon)

from Inspect

In this week's episode I'm joined by Les McCutcheon where we talk about our backgrounds with details about where we grew up, how we got into the tech industry and some anecdotes along the way. Mentioned in the show .NET A beautiful friendship, Casablanca Ajay’s personal Goals Les’ company, Code Octopus Ruby Swift Jekyll Inspect.fm Ajay’s personal website Travis CI Sketch

Episode metadata supplied by the publisher feed · Published Mar 13, 2017

Embed this episode

Ready to play

Humble Beginnings (feat. Les McCutcheon)

0:00 0:28
of MATCHES

TRANSCRIPT · AUTO-GENERATED

Welcome to episode one of Inspect. My name is AJ. And I'm Les. Inspect is a show about web development, design and technology.

So today, just going to be a bit of an introduction about us, where we're from, how we go into the industry, a little bit about backgrounds, plans for this year, plans for the future, just so that the listeners can get to know us a little bit. So I guess, do you want to kick it off, Les? Let us know a bit about you. So as I've already said, my name is Les.

I've been a software developer for about six years, started off in front end and slowly moved into the dark side of the technologies. I'm a recent father of two beautiful twins. And that's me. What about you AJ?

So yeah, my name's AJ. I'm a front end developer working on UI development. I started off as a designer. And then I've been doing front end designs since around about 2008, also a father.

But yeah, that's me and I'm not sure. But I suppose we're probably going to be more depth. So do you want to start from the beginning, like where you grew up and how you got into the industry and take it on there, really? So I was born and bred in Chirtsy, south east of England.

And sort of, well, I didn't actually live there with my parents, but I always stayed there with my grandparents. And while growing up, it was pretty rural. It was farmland, rudimentary sort of construction, sort of industries for the family and for what was growing up around. And there was not really much any, well, there's no tech at all, really, into it.

And that sort of was pretty common, even throughout school, until I was about 1718, in which I did a multitude of different jobs. But before eventually finding my calling, calling one out in South Africa as a frontline developer. Bit of a long way to travel to find out what you're going to do for work, right? Well, yeah, true.

I mean, one of the jobs I was doing at that time was a choreography for the music industry. So what I was doing is the master records and that sort of stuff is I had to have the whole briefcase hand off to your wrist, going to the different distribution warehouses, factories, manufacturing plants, and really jet-saying around the world. Not really seeing any of it at all. But that was sort of my role.

My dad immigrated to South Africa, where he owned a hotel. And I went out to visit him. And the set mum was like, oh, you're your direct generation. You can build a website.

Being one I was up for a challenge, I said, why not? And then he was like, yeah, I actually quite enjoyed this compared to everything else. So that's been my life since I've been 21. OK.

All right, interesting. Quite a big change. And so when did you move to where we are now? Where are you living now?

So I'm living pretty, actually, very close to where my parents brought me up. So I'm in Binfield, still in the South East, quite close to London. And very recently, I've always worked for the traditional agencies and software houses, local. But now I've recently started my own company.

So it's pretty much, oh, you can hear the little one there. So yeah, that's me. Where did you grow up? And how did you end up in web development?

Right. So I grew up around West London in Hanslow, did most of my schooling around there. And then I got into web development quite late, actually, after university even. But before that, while I was at high school, I was quite interested in all the creative subjects there.

So I studied art. I studied graphic design, music throughout the year. And I was always quite interested in the creative side of the subjects. And I really wanted to actually take on music in university as well.

But I don't know. There's one thing to do another. I didn't really work out that way. I ended up going to university and doing computer science, which wasn't really my original choice, but it was just where I ended up.

And I didn't really like it very much. I never liked programming. I didn't really have the head for it at that time. So I did, obviously, I finished my degree.

But in the back of my mind, it was always like, I really don't want to do this. I want to do this. I want to pursue one of the creative arts, as much as I can. And then I got a job just after university.

But it was working for this company in Hemhams, that it was actually a payphone company, not the most exciting. But they were going through this transition where they're converting their payphones into internet kiosks. So I was getting to work on computers quite a lot, and learning a bit more about software and the way it was all being put together. And that was quite interesting.

And then at that same time, my brother at the time was working for an agency. He's a web developer. He's a dot net developer. So he was working for an agency.

And then he was approached by someone to do some freelance work. And then the freelance work involved some design. And he's not a designer. He knew that I had a passion for these sorts of things.

So me and him sort of joined forces, and we formed a company. So myself, him and a friend of ours. And we were just working from home in our spare time and working on this freelance project that he had. And then things took off from there.

And after university, he just realized that I actually got quite good. I'm really liking the design now. And it's something that I definitely want to pursue. So after that, we formed a company, the three of us.

And that grew, actually. We did it for about 10 years until I exited it around 2010, I think it was, 2010, 2011-ish. So is that company still going? Yeah, the company still exists.

So it had a few years of growth. And it reached a peak of about 15 people, I think it was. And then as the sort of projects became, the number of projects reduced, we started focusing on just one or two clients and focusing all the engine on those. The headcount slowly reduced as well.

And now there's just a few people just running it and servicing those clients. But there's sort of big projects as well. But it was just something that I agree with myself. Like career progression, myself.

Yeah, so when I then exited the company that I started, I had a few jobs out, a few different agencies. I worked for BT for a little while. And then I worked for another brand on the client side. And then I joined the agency where I met you.

So that was about a year ago now, wasn't it? Yeah, that was about it. Yeah, I think I've been there probably about five or six months before you joined. But no, yeah, that was the start, quite in the Casablanca film of a beautiful friendship.

Yeah, lovely, isn't it? But yeah, that was good. I mean, I really enjoyed the job. And then it just obviously just ended in a bit of a bit of a crout way.

So for the benefit of people listening, me and Les used to work together at a digital agency. And back in November last year, in 2016, depending on when you're listening to this, it, the company went into liquidation and the whole company became made redundant. So it wasn't a huge team. It was about 30.

Wasn't it about 30 people? Yeah, it was about 30 people. Yeah, but it wasn't great. Obviously, we all all been made redundant all at the same time.

And it was quite a bit of a difficult time, actually. It was towards the end of last year. But yeah, I suppose it was the sort of shop because it was quite out of the blue. The, unfortunately, a couple of clients were holding payments and that sort of stuff to the company.

Unbeknown to the workforce. But the, what made it so shocking and out of the blue was that everyone was an expert in the iron field, really likable, really friendly. Everyone got out of the way to do anything for everyone else. It was one of the best places I've ever worked.

And for it to end under such circumstances was just, well, you said it, pretty crap. Yeah, because that's what makes your job worth while listening to people you work with. It's not really about the company or the natural clients. It's the team that you're part of.

And yeah, we had a really good team there. But it's been good because obviously, a lot of people have kept in touch. And I mean, you're still working on this project together. And yeah, it's been quite a supportive team, isn't it?

Yes, yeah. So I mean, pretty much everyone's kept in touch. And everyone's looking out for each other. But even now, I believe it's fourish months, four or five months after the event.

The WhatsApp group's still going strong. Comments on it every now and again. And no, it's, once you meet good people, once you've got professionals and stuff, it makes everything so much easier. But you're completely right.

At the end of the day, what we do in technology normally boils down to pixels or ones and zeros. And you can be doing that for anyone, anywhere, and just doing it for money. But what really makes it worth getting up in the morning and interacts on those projects is the people who are hands down. Yeah, absolutely.

Definitely. So what do you think about these sort of designers, developers, or developers to designers? It's quite a hot topic that's based quite a lot where some people say that you need to be a specialist. A jack of all trade is a master of none.

That's all coming. All you have other people say that to know both actually and power you to make the right decisions. I think it depends on the type of mind that you've got. If your mind works in a very calculative way, then maybe you ask to just to be a developer.

Whereas if you more of a creative problem solver, then being a designer is probably quite a good skill to have, especially as a front end developer, it's handy knowing about designers all, because a lot of the time I can make decisions or I can make assumptions about what designers are trying to do with their designs. Whereas if you're a designer and you know how to code a zoll, that could also maybe stifle your creativity a little bit, because you know what's possible and what's not. At that moment in time, as we all know, tech is always marching forward. Especially now, I've seen a few designs recently which baffled me that they actually don't actually have any videos playing in the background.

It's been really cool stuff. Yeah, yeah, so if you know how to create that sort of stuff, then you've got the freedom to design that as well, right? If you don't know how to build something like that, then you're never going to think of it. Yeah, you might not, as a designer developer, you might not even attempt to design something that's got that level of creativity if you personally don't know how it can be built.

Whereas if you're just a designer and not a developer, you may design something which is completely out of quite left field, not knowing whether it's possible to be built or not. And if it's not possible, then your ideas may be pushed back. Yeah, yeah, I mean, I think that flows into some sort of concept for sort of the more back end sort of dev roles is as a junior and actually for whatever stage you create you are. If you don't know tools or technologies exist for a certain problem, you don't use them and you end up having to try creating your own and doing all that sort of stuff, just because you don't know of it.

So if you don't know it, you can't use it. As a example, it's one of the first things I did as a backend developer is I recreated the entire model validation for the web forms, just because I didn't know it existed at the time. Yeah, I suppose as a designer, if you don't know what exists, you can dream up the world. But if you do know or your full process is limited by what you know, you're like, you said the creativity is stifled.

Yeah, exactly. That's what I mean. You said it a lot better than I did. But yeah, I think essentially, I think overall, I think, is good to have experience in both, if possible.

But I've got no qualms with people who are just designers and don't want to touch any code. I've got no qualms with programmers who have no interest in doing any design. Be a specialist in your field. And that's great.

If you can do both, great. If you can't, or if you don't want to, or if you can't, just focus on what you've got to do it to the best of your ability and let other people worry about the other bits. Yeah, it's really interesting. I'm sorry.

I'm by no means am I a backend developer, but I'm happy to get involved and dip into the backend code as much as I can. But it's not my core skill. So I'll leave it to the experts. Yeah, you can sort of, you can help out and you can, without being a derogatory, you can monkey patch the bits.

But when it comes down to the true experts, and what they can do is they know their stuff because it's their domain. Yeah, I know enough to know what is probably possible and is probably the right answer. But I'm not going to be the one to actually figure out the right answer if you know what I mean. Yeah, yeah.

Well, for funny enough talking about that, as we're sort of front back end, as a sort of false stack developer, the reason why I've gone more back end in recent years is purely down to the fact of the front end is moving much, much, much faster than the backend technologies and code. And I'm sure people would disagree. But also at the same time is you don't have to get the backend absolutely perfect. As long as it works and it's performant, you know, you can, there's a million five ways it's going to cap.

But on the front end, especially with, you've got like a website profile, and speed analysts and SEO marketers and the new meta data and all that sort of stuff is that it normally sees to be only one way and unless you're an expert in all of those areas and that's discounting design from which is another big part, then you're user experience and that sort of stuff. It's just a huge domain to be trying to keep a float off. Yeah, I mean, just look at any recent job spec. You look at front end job spec these days and they'll ask you for, they'll obviously have HTML, CSS JavaScript on there as your core three skills.

But then they'll listen to every other framework that's available just as a requirement. But then you know, you wonder like, are these companies actually using all these frameworks or do they just want someone who could cover all bases? And you'll see things like, oh, in minimum five years of Angular two, but it hasn't been around for five years or they'll just just a ridiculous reading. Yeah.

But it's worth a minute. Well, that's the thing. It's the entry we live in. It's, I mean, front, back end, system admin, or cloud specialist, whatever type we want put yourself to is at the end of the day, we're all geek slash technology minded.

And the industry we're in is pretty much just one of constant learning and progression. You can't really box yourself in too much. I mean, of course, design and front end is it has clear boundaries. And you can either muddy the waters or you can be on or to one of the sides.

But when you're in technology, like you're saying, it's pretty much as if you're a front end developer, no doubt you'll end up start playing with web services, moving more into the sort of the back end of the server side and stuff. Or as common trends are, you do everything in the client side and the server becomes more and more redundant. Or vice versa, as a back end developer, you're always going to end up writing a bit of JavaScript, putting out some HTML markup, editing, element attributes. We all work in the same ecosystem.

And again, we've given ourselves labels to sort of find the technologies that we use. But it's all the same, really. All that's my opinion anyway. OK.

Yeah. It's hard to keep up with it. Have you any goals for this year? Anything that you're trying to focus on this year?

Well, every year I've had goals. I'm like, this year I'm going to learn a new framework. I'm going to achieve this. I'm going to release an app or all that sort of stuff.

But this year, with the arrival of the twins and the unfortunate ending of the company that I was working at as it went into liquidation, 2017 has been pretty much blown out of the water in terms of goals. I mean, I've set up my own company now. It's doing really well. And I'm trying to get that work-life balance or work-to-in balance in order.

But apart from that, really, it's learned as much as I can, have as much fun as I can. And hopefully, as soon as I get some sort of sanity, start actually putting some proper goals in. What about you? Yes, I've actually got for you, actually.

I've written a few down. And I've got this repo set up on GitHub, which has a list of long-term goals that I'd like to achieve this year. I'll put it on GitHub because I thought, well, it's actually an idea I got from someone else about being transparent about your goals and making yourself accountable by putting them public. So just a checklist, basically, on GitHub.

And yeah, it's got a few things on there. I mean, I'd like to double with a different programming language. I was thinking maybe Ruby or Swift. I had been playing around with Swift a little bit, but I just haven't had enough time to dedicate to it.

But one of my main goals for this year was to get involved with the podcast, or to actually start with myself. And obviously, that's one that I can take off the list now, because things have started. So I definitely obviously keep this podcast and help make sure it grows and stuff like that. But the main reason for actually wanting to do that in the first place is because one of the other goals I've got is to do some more public speaking.

So I figured that this would just give me a bit of a grounding of just talking about top-cent topics and just some practice, basically. Without the pressure of having to do it on the stage straightaway, it's just something that I've never really been great at, talking in front of the crowd. So that's something I'm trying to work on for this year. But yeah, so I've got a list of goals that I'm trying to achieve.

And yeah, there's a few other stuff like be more healthy and things like that. But work-wise, I'd like to get involved in it and try and learn a different programming language, something that I haven't worked with before. I'm leaning towards Ruby. I think that's something I'd like to try.

I've got a little bit of a start with it because I've been playing around with Jekyll, which is Ruby-based. So I've got, I've started on that goal, but not enough to take it off yet. So what's all the aspects of Jekyll? Are you using?

And what is it for those that might not know? Okay, so Jekyll's static site generator. So it's basically, it's kind of like a hybrid between a dynamic website and a static website. So you're using like CMS-style templates to generate static HTML files.

So the website for the podcast, inspect.fm, that's built using Jekyll, my own personal website is built using Jekyll as well. And I mean, it's good for sites which probably don't need updating very often or are going to be updated by the developer. So I wouldn't use Jekyll for a client's project where they're expected to update the site themselves because once the site is being built with Jekyll, it always needs to be updated. We have maintained using Jekyll to generate the site.

But it's pretty good. It's quite quick to knock out a site and the end result because it's all static HTML files with no databases or anything like that. The site generally runs a lot faster, I've noticed. Well, yeah, I believe the BBC website, the news part uses static site generators to circumvent the whole database sort of stuff.

So they've got a CMS in the backend and then it all just compiles static code and that's what's deployed. Well, okay. Well, if the BBC are using it, then it'll definitely be an advocate for it as well. Yeah, we should probably do some research into it in the talk about it in a bit more depth in another show.

There are alternatives, there are other state generators, state site generators as well. There's Hugo, there's Jekyll's domain one that I use. There's probably others, I haven't looked into any others. Middleman is another one, I think.

Middleman. I've tried to build my own with Omrico as a base. So it's basically using Omrico as a CMS on a publishing platform and then it stack-lit generates all the files and stuff and then you do that's what you deploy. It's not as easy as they will make it seem but it's a really interesting topic and probably definitely one for an episode.

Yeah, so the way I've got my website working and the inspector website is that I've got Travis doing the build and so I've got it all synced up with GitHub so you make your changes, commit to the GitHub repo, then Travis watches the GitHub repo for changes, runs the build and deploys it. So it's all automatic and it's quite a good system. It may not be perfect, I mean I'm not an expert in this yet but it works for now. So.

That's the most important thing to take isn't it, is everything changes, best practices today can become anti-patterns tomorrow. But as long as it works and it does the job too and adequate or better standard, we can sort of pat ourselves on the back and move on to the next. Yeah, exactly. So, so far I'm quite enjoying it.

So that's why I'm thinking that might delve into Ruby a bit more so I can maybe understand how Jekyll is working and how is what he's doing in the background. So is that your main drive for learning Ruby? Yeah, it's just something that I haven't tried. I've got exposure to PHP in the path.

I've had exposure to .NET. I've never really had any exposure to Ruby. So I just want to try something different just to get out of the compass a little bit. Yeah, yeah.

I'm also learning Sketch at the moment as well. I've always been a Photoshop user but in the past few weeks I've met some around Sketch. So that's another one of the things I'm saying. How are you doing?

It's good, but it's slowing me down a lot. I've just not used to it. I've been using Photoshop and illustrated for so long. I'm so used to them.

And I'm just having to sort of reset all my muscle memory now and try to learn a new tool. But I will stick with it. I will stick with it for a little bit. Cause I know it's got a lot of potential.

It is a really good tool, but it's just slowing me down. Okay, well, yeah, maybe we should leave it there. It's been a good chat. I think that's been quite a good first episode.

And yeah, if you guys are listening, have enjoyed what you've heard so far, hit the subscribe button wherever you're listening to this in iTunes or in your RSS feed. And we will catch you in the next episode. What I did, catch you later. Later.

Bye.

No similar episodes found.

Inspect and Adapt Construx World-class software development requires far more than language/platform expertise and steady sprints. Join us as we describe time-tested, industry-proven software best practices at the team, organization, and leadership levels, sharing examples from recent engagements with software teams of all sizes. Construx is led by industry leader Steve McConnell, author of Code Complete and More Effective Agile. Software experts first and software trainers and consultants second, our team has seen what works and doesn’t work in hundreds of software organizations. Host Mark Griffin spent the first half of his career as an electrical engineer doing silicon hardware design and leading software automat Fire Protection Podcast Inspect Point, Drew Slocum The Fire Protection Podcast dives deep into topics of the fire protection industry. Fire alarm, sprinkler, suppression, extinguishers and other life safety systems are discussed. Leaders from all over the world talk about new technologies and processes that are helping improve the fire safety community. The Construction Shared Pains Podcast ConstructionProgress.org Hear from experts across the Architecture, Engineering, and Construction (AEC) industry looking to improve productivity and advance data interoperability standards. Join host Sasha Reed [@AlohaSasha], field reporter Nathan Wood [@nathancwood], and show producer Dan Smolilo [@Construct_Techy], as they interview industry and technology professionals to digest current integration challenges, debate necessary changes in contract and culture, so that you can decide the best strategy to invoke positive change and deliver streamlined collaboration between design, build, inspect, and operate stakeholders.

Frequently Asked Questions

How long is this episode of Inspect?

This episode is 0 minutes long.

When was this Inspect episode published?

This episode was published on March 13, 2017.

Is there a transcript available for this episode?

Yes, a full transcript is available for this episode. You can read the complete transcript on the episode page.

Can I download this Inspect episode?

Yes. Use the download control on the episode player to save the publisher-provided media file.
URL copied to clipboard!