Steve Rydz – MetaBroadcast https://metabroadcast.com helping millions of people find TV, radio & music quicker Tue, 09 May 2017 23:21:08 +0000 en-US hourly 1 https://wordpress.org/?v=4.7.4 the virtues of a simple editor https://metabroadcast.com/blog/the-virtues-of-a-simple-editor https://metabroadcast.com/blog/the-virtues-of-a-simple-editor#respond Tue, 19 Jul 2016 00:00:00 +0000

It’s common for developers to talk a lot about their tools. Tools are important. If you’re happy with your tools and know how to use them well you’re likely to be more efficient – but can we know our tools too well?

I used to be very much in this camp. I remember getting to grips with Sublime Text and trying to commit every keyboard shortcut to memory. I even took courses and read books on it. As part of that process I became quite efficient with that particular tool and often had people asking me which shortcuts I was using or how I did a certain something.

Not so long ago I made the jump to Atom. With Sublime I used a lot of plugins and used some clever tricks to keep my settings in sync between machines, but with Atom I wanted to start afresh and wanted to avoid becoming dependent on a load of plugins, so decided to keep my instance of Atom as close to default as I could.

I guess it helped that in many ways Atom is similar to Sublime, such as many of the keyboard shortcuts and functionality are identical—but that doesn’t take plugins into account. I use a small handful of plugins now which I’ve installed as and when I’ve needed them, but I am in no way dependent on them.

I guess the point I’m trying to make is that it’s all too easy to get bogged down in learning your tools that you don’t end up getting any work done. For example I have limited time in the evenings for extra-curricular coding, so am I going to spend that time configuring plugins in my editor? or am I going to get my hands dirty with some actual code?

To clarify, I’m not against customising your tools. Making them your own is a good thing and will help you, but most modern tools can be customised within an inch of their lives, tying you down to a specific way of working. I’ve found it’s more beneficial (for me at least) to remain flexible when it comes to these things.

This guy also shares my views on the matter:

I deliberately haven’t shared the plugins I’m currently using because I don’t want to send you dear reader down a rabbit hole, and because it reenforces my point that I’m not dependent on them.

What’s your view on this topic? Are you a fan of customising your tools or do you prefer to keep things simple? Let us know.

If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.

]]>
https://metabroadcast.com/blog/the-virtues-of-a-simple-editor/feed 0
the joy of walking https://metabroadcast.com/blog/the-joy-of-walking https://metabroadcast.com/blog/the-joy-of-walking#respond Tue, 05 Jul 2016 00:00:00 +0000

It’s (mostly) quite easy to get around London on the tube, discounting personal space issues, but who wants to spend all their time underground? I like to take every opportunity to walk around the city.

Some people think I’m mad for walking as much as I do, but unless there’s a good reason not to (e.g. on a schedule, not feeling well etc.) then why not? I didn’t move here just to see the inside of a tube carriage.

For me walking connects the dots of London. I’ve learned where most places are in relation to others. As a result I’m often able to find my way around without resorting to Google Maps.

I’ve covered a lot of the city over the past five years. I’ve walked everywhere from Wood Green to Oxford Street, Manor House to Kensington, and regularly walk from Southgate to Muswell Hill. It’s worth noting that I rarely (if ever) take the most direct route anywhere either. Unless I have to be somewhere at a certain time, which is rare, then there is no rush. Even when I do have to be somewhere I’ll often factor in time to take the longer, (possibly) more scenic route.

Obviously there are health benefits to walking, but for me the benefits are mostly psychological. As well as enjoying the fact that with every walk I get to know the city a little better, I also find it quite a meditative process. When I’m out walking I’m present and observing my surroundings. I’m not thinking about the things that may cause me stress or worry in my day-to-day life. It’s also worlds apart from sitting in front of a computer, which given my chosen career is something I do a lot of.

It’s hard to find any downsides with this pastime. The main one is that you can sometimes feel a bit stiff for a couple of days after a really long walk, but being prone to joint and back problems as it is I actually find the more I walk, the more it helps.

Of course there are times when I just don’t have the energy – or the weather is terrible – but that doesn’t mean I want to sit around all day. In those cases I sometimes opt to get a bus to wherever I might be going. I find this useful because it is often as indirect as my walks would be, and helps me to find new places to go too.

If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.

]]>
https://metabroadcast.com/blog/the-joy-of-walking/feed 0
becoming a polyglot https://metabroadcast.com/blog/becoming-a-polyglot https://metabroadcast.com/blog/becoming-a-polyglot#respond Tue, 07 Jun 2016 00:00:00 +0000

As someone who primarily works with JavaScript I want to be as knowledgable about the language as I possibly can be. This combined with trying to keep up-to-date with all the emerging tools and libraries that surround the language can sometimes feel like a full time job—that’s a rant for another day—but recently I’ve been trying to broaden my horizons and get to know other languages.

I recently spent an afternoon playing around with Haskell and also worked my way through a highly recommended Ruby on Rails tutorial. Whilst not being enough exposure to qualify as an expert in those languages, it was enough to alter the way I think about certain things in JavaScript such as types and testing.

The way Haskell is so strict with types encouraged me to consider this more when writing JavaScript and has led me to look into tools such as TypeScript and Flow. I’ve never had any serious issues with types in JavaScript and don’t intentionally use type coercion, but having now used static types I much prefer working that way.

Working with Rails made me realise how far testing has to go in JavaScript. We certainly have the tools available to us but it’s nowhere near as ingrained into the culture of the language like it is in the Rails world. Rarely if ever do you see a JavaScript tutorial that covers testing alongside the key points of the exercise. This (in my opinion) has led to a generation of developers (myself included) that aren’t always sure what to test and how to go about it.

I’m not looking to change my focus to another language (although I could never rule that out entirely), but I believe the more areas you have at least some experience in the better. In the book The Pragmatic Programmer, the authors Andrew Hunt and David Thomas recommend that you learn at least one new language every year. The thinking behind this is that each language has a different way of solving the same problem. By learning more languages you learn more ways to approach problems which will help to prevent you getting stuck in a rut.

Another language I’d like to become more familiar with is Java, mainly because it is used widely at MetaBroadcast, so that familiarity will enable me to understand more about how our backend systems work. Thankfully Emils has recently started leading a series of Java 101 sessions aimed at getting the whole team familiar with the language, and despite it being early days it’s already proved helpful.

Once I start to feel a bit more comfortable with Java I’m thinking that I’ll spend some time getting more familiar with PHP. I have enough familiarity with it that I can get things done, but I could definitely benefit from learning more. It may be mocked by programmers from other languages but the fact is it’s still everywhere and after JavaScript is the language I find myself dealing with fairly regularly, in part due to the popularity of CMS’s such as WordPress, Perch and Craft.

What languages are you currently learning or hoping to look at soon? We’d love to know!

If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.

]]>
https://metabroadcast.com/blog/becoming-a-polyglot/feed 0
to broader horizons https://metabroadcast.com/blog/to-broader-horizons https://metabroadcast.com/blog/to-broader-horizons#respond Tue, 10 May 2016 00:00:00 +0000

As someone who primarily works with JavaScript, I want to be as knowledgable about the language as I can possibly be. I also want to keep abreast of all the emerging tools and libraries that surround it. Sometimes that alone can feel like a full time job, but that’s a rant for another day.

Recently I’ve been trying to broaden my horizons and dive into other languages. I spent an afternoon playing around with Haskell a few weeks back, and also worked my way through a highly regarded Ruby on Rails tutorial.

I’m not looking to change my focus to another language (at the moment at least), but I believe the more areas you have some experience in the better. In the book The Pragmatic Programmer, the authors Andrew Hunt and David Thomas recommend that you learn at least one new language every year. The thinking behind this is that each language has a different way of solving the same problem. By learning more languages, you learn more ways to approach problems which will help to prevent you getting stuck in a rut.

I’ve found the above to be true for me so far. For example, I feel more confident about unit testing since working through the Ruby on Rails tutorial. In the Rails world testing is ingrained into the culture. Sadly the same can’t be said for JavaScript at the moment (I attribute this to the complicated tooling that surrounds it), but by doing things the Rails way I feel like I have a better idea on how to approach unit testing my code. I’d worked with Rails before, but only touching templates and CSS, so it was good to get into the guts of a typical application and see how the whole thing works, which also gave me some ideas on how to structure node apps.

This year I hope to become more familiar with Java. I’m not looking to become an expert, but it would be great to understand how Java apps are structured, how tests are run and how to confidently make changes to the codebase.

If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.

]]>
https://metabroadcast.com/blog/to-broader-horizons/feed 0
I’m a failure and that’s ok https://metabroadcast.com/blog/i-m-a-failure-and-that-s-ok https://metabroadcast.com/blog/i-m-a-failure-and-that-s-ok#respond Tue, 26 Apr 2016 00:00:00 +0000

Last week I came across the recently published Failed It! by Erik Kessels. There are many books on the creative process and how to be successful, but not so many that encourage you to embrace failure.

The premise of the book is that failure isn’t necessarily a bad thing. In fact many times when we fail, we learn something new or achieve something else entirely. It seems as humans we’re hard-wired to strive for perfection no matter what we do, but in order to succeed we have to fail first.

I have not failed. I’ve just found 10,000 ways that won’t work.

Take learning an instrument as an example. The first few times you attempt to play a new piece of music you are going to get it wrong, but with each try you’ll get closer to what you’re trying to achieve. You can apply this principle to pretty much anything creative.

The concept of failure being a positive thing can also be applied to the world of software development. Both Agile and Lean UX work on the idea that you fail fast, allowing you to find an alternative approach before becoming too invested in something that isn’t going to work.

Coming back to the book, I recommend picking it up. It’s filled with examples on how failure can be a positive thing. It’s a short book—I read the whole thing in less than an hour—and it’s relative inexpensive (around £6) so there’s really no excuse not to.

If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.

]]>
https://metabroadcast.com/blog/i-m-a-failure-and-that-s-ok/feed 0
coming around to angular https://metabroadcast.com/blog/coming-around-to-angular https://metabroadcast.com/blog/coming-around-to-angular#respond Tue, 12 Apr 2016 00:00:00 +0000

Until recently my experiences with Angular had been very unpleasant. The only Angular app I’d worked on wasn’t written in the Angular way, which I wasn’t to know at the time, and was a pain to work with. Then Phil joined and has become somewhat of an Angular evangelist.

Angular meme

Seeing how much Phil enjoyed Angular I figured I must be missing something. He linked me to a styleguide which made it look a lot more appealing. Through various discussions and some experimentation I learned a little bit more about it and can start to see why some people like Angular.

I wouldn’t say I’m completely sold on it as my framework of choice, but I can definitely see use cases for such a framework, such as an admin UI. It seems to have a lot of useful functionality built in such as cookie handling, redirects, data-binding and so much more that would have to be hand-rolled in less opinionated frameworks.

I’ve always tried to be fairly framework-agnostic, but that’s getting harder as frameworks become more complicated. I’m definitely feeling the pressure to pick a side, but I’m still not ready to commit. They all seem to have their place depending on what you’re building, so I think it’s less about personal preference than some people think.

JS meme

So has Angular won my heart? Not really, but then neither has anything else. These frameworks are just tools that are meant to help us get our jobs done. As long as they do that, I have nothing against them.

It’s important to note that a framework needs to appeal to the whole team in order to be effective, but that requires a degree of openness from the team (myself included). In the JavaScript world there are so many choices that people become very religious about what they use, so you have to keep your mind open to other options.

If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.

]]>
https://metabroadcast.com/blog/coming-around-to-angular/feed 0
pay on demand https://metabroadcast.com/blog/pay-on-demand https://metabroadcast.com/blog/pay-on-demand#respond Tue, 29 Mar 2016 00:00:00 +0000

I have a confession to make. I don’t watch live TV. In fact I rarely even watch on-demand TV these days. I go through phases of subscribing to Netflix, but quickly exhaust the few shows that may interest me. I then tend to leave it for a few months before coming back to it.

I don’t have a TV License (as I don’t watch live TV) and I don’t watch iPlayer, All4 or any other catch up services, but at the time of writing I am legally allowed to, but that could all change. I’ve heard rumblings in the news that this “loophole” will soon be closed. I have no problem with that, after all, it’s not exactly fair to make people that watch live TV pay for content and allow people who choose to watch it on demand to get it for free.

My concern stems from the fact that I could be forced to buy a TV License simply because iPlayer is freely available online in the UK, and I happen to have internet access. I have no issue with paying for content that I consume, but being forced to pay for content I don’t wish to consume leaves a sour taste. To me that seems as crazy as forcing people to pay to read my blog, just because they have the ability to do so.

This problem could easily be solved by forcing iPlayer users to log into an account and link it with their TV License. Essentially this would make iPlayer a subscription service which I’m not sure is something the BBC wants to do, but it would solve the problem fairly in my opinion.

I guess only time will tell how this situation will turn out, and with current events as they are it seems a fairly trivial matter, but definitely something to think about.

If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.

]]>
https://metabroadcast.com/blog/pay-on-demand/feed 0
managing oneself https://metabroadcast.com/blog/managing-oneself https://metabroadcast.com/blog/managing-oneself#respond Fri, 11 Mar 2016 00:00:00 +0000

I’m often complimented on the way I manage my time at MetaBroadcast. I try to keep my estimates accurate and make sure my features don’t overrun. I also like to make sure I get out at a decent hour so I don’t burn out. Because of this I was asked to do a demo on how I achieve this.

It was quite interesting to take the time to think about what it is I do and why I do it. I ended up with a list of four things I try to keep in mind when planning my work.

1. expect the unexpected

Things move fast at MetaBroadcast and you need to be prepared for the unexpected. The unexpected can come in a number of ways, such as:

  • You might need to drop what you’re doing so you can unblock someone else
  • An unexpected bug from your previous work might rear it’s head
  • You might have to deal with a support issue

It’s quite likely one of these will happen in a given week/iteration, so make sure you allow for this.

2. expect the expected

As well as the unexpected, there are a number of things we know we have to do every week. The list will vary for different members of the team, but at the very least we all write a blog post every two weeks, and we have a weekly code review which means allowing time to make comments and to attend the briefing on the topic being discussed.

3. tackle the hard problems first

Typically our work will range from a number of tasks of varying difficulty. To me it makes sense to tackle the difficult problems first. This way you have more time to get help if you need it.

Thomas raised a good point about the psychological benefits of starting with a simple task to give you a sense of achievement. This is something I agree with (and have written about before). My point was more related to planning an iteration of work, but on a day-to-day basis I find doing a simple (and hopefully quick) task first thing can get you in the right frame of mind for the rest of the day.

4. be honest

Some say honesty is the best policy, and I couldn’t agree more. In this line of work it’s common to be asked how long a given task will take. Sometimes we don’t know. If that’s the case it’s best to say so. There’s no point in coming up with an arbitrary estimate. If you don’t know there may be some things you can do to help you figure it out.

In the case that you must give an estimate, I would err towards the least optimistic end of the spectrum. Of course people like to hear optimistic estimates, but they’re less enthusiastic about it once that task ends up taking twice as long.

By declaring that a task will take a long time you give yourself the opportunity to potentially come up with a simpler solution. You do this by discussing the requirement with the person who has asked you to do it. Maybe there’s another way to achieve the same goal, or maybe this requirement is actually a bad idea. Give yourself a chance by raising your concerns early.

The final part of this is making it known if a last minute task doesn’t fit into your iteration. In this case you could make a suggestion as to what can be done to accommodate the new work. Maybe something can be de-scoped or moved to the next iteration.

bonus tip: it’s not about the tools

One question that came up after my demo was along the lines of would I recommend any particular tools for this? The answer is no. For things related directly to my work I use Jira so everyone else has visibility of what I’m doing. For more personal tasks I use Wunderlist and I keep notes in Simplenote, but you should use what works for you. Ultimately being productive has more to do with the way you approach things than the tools you use.

In my experience this isn’t specific to MetaBroadcast or the software industry. Back when I was making kitchen units for a living I’d often have to tell my supervisor that cutting those extra panels will push back the job I was working on. Clearly some industries differ though, such as in the medical world an emergency can literally be a matter of life and death so would have to be dealt with immediately.

What are you’re time management/productivity tips? We’d love to know how you keep on task and get things done.

If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.

]]>
https://metabroadcast.com/blog/managing-oneself/feed 0
the importance of unplugging https://metabroadcast.com/blog/the-importance-of-unplugging https://metabroadcast.com/blog/the-importance-of-unplugging#respond Tue, 01 Mar 2016 00:00:00 +0000

Three years ago I had a weeks annual leave coming up and I decided that I wasn’t going to write a single line of code for the whole week. That might not seem so strange seeing as I wasn’t “working” that week, but like most coders I know I spend a decent amount of my personal time writing code too.

When my time off arrived I decided I’d try not to use my laptop at all for that whole week. Ideally I wanted a week offline, but in today’s world that is almost impossible. There’s always something which requires an app or a web browser, but as I could take care of most of that stuff on my phone, I settled for leaving my laptop lid closed.

When I returned to work the following week I was actually excited about writing code again, and I had a fresh perspective on how to approach the challenges I faced on a daily basis. Since then I’ve tried to follow a similar pattern every time I take time off.

I deliberately skipped over something there. Prior to the week off I’d been struggling with burnout. I had no motivation at all. This wasn’t purely caused by coding in my free time. My Sister had been diagnosed with cancer (she’s fine now) and two of our three cats passed away all in a matter of months, so that definitely took its toll, but burying my head in a text editor certainly didn’t help. What I really needed was to spend some time in the real world.

The lesson I took from this was to make the most of my free time. Yes, it’s important to keep my coding skills up-to-date, but not at the expense of everything else. Not only do I try to minimize my time at a computer during my holidays now, I also do the same at the weekends. I have to spend some time with my laptop as not only will it get lonely, but I still have a desire to continue building on my coding skills, but keeping that time to a minimum means I focus more and am eager to come back to it.

I’ve found that if you truly want/need a break it doesn’t really matter what you do as long as it’s different to what you do all week long. It helps to have other interests. For example I’m a keen guitar player and even keener amateur photographer. The great thing about these activities is that they are totally immersive. When I’m running through scales or wandering the streets with a camera my mind is entirely focused on the task at hand, so when I get back to work my mind is clear and focused.

There are other benefits to spending time focusing on other things too, such as developing skills and even expertise in other areas. Some examples for me are that I’ve learned how to do sweep picking by taking the time to focus on that particular technique. I’ve also met two of my favourite photographers: Joel Meyerowitz and Matt Stuart; at recent book signings. I’m also lucky enough to be attending a workshop with the aforementioned Matt Stuart in a few weeks time.

And there we have it, that’s how I keep myself wanting more. For another take on this why not have a read of Tom’s post on the subject? How do you keep the dreaded burn out at bay? We’d love to know!

If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.

]]>
https://metabroadcast.com/blog/the-importance-of-unplugging/feed 0
moving from bower to npm https://metabroadcast.com/blog/moving-from-bower-to-npm https://metabroadcast.com/blog/moving-from-bower-to-npm#respond Tue, 16 Feb 2016 00:00:00 +0000

Luke’s already talked about FESK, our front-end starter kit, and how we use it to standardize our approach to projects, but FESK is a living creature which needs constant care and attention.

We already try to merge as much of our work as possible back into FESK, assuming it’s something that can be used across other projects, but we also revisit it to see if we can improve it in other ways too.

The latest change is moving from bower to npm to manage our front-end dependencies such as lodash, handlebars and moment to name just three.

On the surface it didn’t seem like there was anything wrong with using bower, but whenever we needed to update something like our CSS framework for example, it was just harder than it needed to be. Ditching bower seems to be a common theme, so we’re definitely not alone in feeling this way.

Ultimately it’s just nice to have fewer tools to deal with, and it’s definitely feels good to get rid of config files such as bower.json and .bowerrc, making the root directory a little leaner.

One of my favourite benefits of using npm is that we can now require libraries as we need them rather than having to add script tags to our HTML files, for example this:

<script src="../bower_components/lodash/lodash.js"></script>

becomes this:

const Backbone = require('exoskeleton');
const ProgrammeView = new Backbone.View.extend({});

Have you switched from bower to npm? Or maybe think that bower isn’t so bad? Let us know!

If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.

]]>
https://metabroadcast.com/blog/moving-from-bower-to-npm/feed 0